Revision as of 03:05, 1 October 2010

Navigation shortcuts: Wiki users:Linda Pettigrew

An Analysis Tool for Log Files

This project looks at the design decisions made during the development of a tool to extract data from XML log files. While this project will be used to extract results for an honours project, the entire tool was developed during this course: there was no code or ideas for this code in existance before the commencement of COSC427.

Background

A tool has been developed to collect event-driven data from developers while they are using eclipse. The data collected contains details about the event which has occurred such as the number of charcters added during an edit, the time of the edit and the file the edit occurred on. An example of the data collected is shown in figure 1.

This project focusses on developing a tool to extract meaningful summary data from these logs.

File:Ljp51xmlExample.pdf

Design Study

Requirements

The tool needs to generate a meaningful model of a user's session before analysing data collected from a user. Factors to consider:

• Initial trials of the collection tool are stored data in a database. There may be a need to analyse this data in the future.
• Xml logs of events are stored in zip files.
• Events will need to be loaded from xml files.
• A meaningful model will need to be constructed from the events. This model may change at a later date.
• The model may contain elements which are derived from more than one event for example a Launch will be composed with the information in a RunProject event and the subsequent Console output.

Information will then be gathered from the model of a user.

• Measurements may be time related such as number of events per 20 minute block or they may be simply counting events - different types of measurement need to be written to different files.
• More measurements will be made at a later date. It must be simple to add a new measurement.
• Measurements will need to be able to be written to both xml and csv files.

Application Design

File:Ljp51-completeUML.pdf

UML Diagram - Complete

Description of Classes

Event Loader - Strategy Pattern

Data collected from eclipse has been logged in a number of different ways (xml log file and to a database in the releases to date). Since the method of logging the data affects how the events will be loaded the strategy design pattern has been used for construction of a list of events.

Strategy pattern components:

• Context => AnalysisApplication
• Strategy => EventLoader
• AlgorithmInterface() => Initialise(), NextSession()
• ConcreteStrategies => XMLEventLoader, ZipFileEventLoader

At a later stage a DBEventLoader will be added to load events from a database for analysis. This will form a third concrete strategy.

FileEventLoader - Decorator Pattern

The collection tool currently uploads zipped xml files to a server. To analyse these zipped files they need to be unzipped. This behaviour would be necessary for the analysis of log file stored in other file formats too (for example tab delimited files) so the functionality for extraction is provided as a decorator. An additional level of abstraction "FileEventLoader" was added since it would not make sence for a ZipFileEventLoader to wrap a DatabaseEventLoader.

Decorator pattern components:

• Component => FileEventLoader
• Operation() => LoadEvents()
• ConcreteDecorator => ZipFileEventLoader
• ConcreteComponent => XMLEventLoader
• AddedBehavior() => ExtractXMLFile()

SessionModel

The session model is constructed from events by the session model itself - the events are passed to the session model and the parts of the session model constructed from these. This current arrangement does not allow for replacement of a SessionModel with another representation of a session.

The session model is designed in a way which allows traversal of elements in chronological order. This will allow a greater range of analysis to be easily performed on the model such as grouping a series of developer actions into a composite event.

The current model will be expanded to include more types of ModelElement's in the future.

ModelElement and DefaultModelVisitor - Visitor pattern

The visitor design pattern is used for collecting data from the SessionModel structure. The visitors currently collect data from the SessionModel for creation of summaries. Currently there is only one visitor for the model however more visitors will be added in the near future.

There are two main advantages of using the visitor model here. Adding the new visitors for collecting more data from the model in the future will require extending DefaultModelVisitor and overriding the methods required. This is straightforward.

The second advantage is that complex computations and logic neccessary for performing analysis is separated into discrete classes: the logic present in each class only has to be enough to complete one anlysis. unrelated anlysis is in turn separated into a separate visitor class.

While adding a new ModelVisitor may have been difficult if a ModelVisitor was defined, including a DefaultModelVisitor makes the addition of new ModelVisitors simple as classes are not required to override every method. This also makes changing the SessionModel to include more elements for which a call back method is required easy. Code in the DefaultModelVisitor needs to be altered to include the additional callback method while the code in teh existing base classes can remain constant.

An unfortunate downside to using the visitor pattern is that the visitor needs to be able to access information about the state of the ModelElement by either getters or public fields. This breaks encapsulation as the internal state of the class is now exposed to outside classes

Design Critique

Files

Source code and working program.