Persistence framework change

[GoogleCodeExporter]

Background:
Model data is currently persisted to a single *.mmd (Metric Model Data) 
file. This includes version, class, method and dependency information.

Issue:
Because it is all in one file it requires loading up the entire file. This 
is both slow (for very large systems) and memory inefficient (we can't 
keep the entire model in memory when working on large systems). So it 
doesn't scale well to large systems.

Furthermore, it does not allow for easy plugins to be developed or allow 
other applications to make use of specifc data. Such as a graph plugin 
that utilises dependency data.

Proposed Change:
Separate out all model data into separate files.
*.cme (Class Metric File)
*.mme (Class Metric File)
*.dep (Dependency File)

Each Version, will output a *.cme, *.mme and *.dep file for each version; 
which will be named after the rsn of the version. Version 1 will thus 
output (1.cme, 1.mme, 1.dep). As this will produce 3 files per version, 
they can be kept in a 'data' folder.

Original issue reported on code.google.com by jtha...@gmail.com on 28 Aug 2007 at 4:40

[GoogleCodeExporter]

I should also add that it is important that all file types de-serialize to 
VersionMetricData for consistent use and compliance with Issue 16 (Move to a 
smarter/lighter data loading framework).

The behaviour would be as follows....

Class Metric File (*.cme)
* VersionMetricData constructed with all classes and their respective metrics.

Method Metric File (*.mme)
* VersionMetricData constructed with all classes. However, only the classname 
and 
method metric map is populated.

Dependency File (*.dep)
* VersionMetricData constructed with all classes. However, only the classname 
and 
dependencies are populated.

Advantages:
* Keeps the relational structure
* Allows VersionMetricData to be merged.
* Provides a consistent usage for data loading
* Provides consistent interface usage (always loading version metric data 
objects. 
How heavily reconstructed they are depends on how they were loaded.)

For example, if you had a VersionMetricData object that was loaded with class 
data 
and you later had a VersionMetriData object that was loaded with method data 
the two 
could be merged into one VersionMetricData object.

Original comment by jtha...@gmail.com on 28 Aug 2007 at 7:25

• Changed state: Started

[GoogleCodeExporter]

Fixed:
A new SerializeType was added to distinguish between the files that now exist 
in a 
project.

SerializeType.CLASSES,
SerializeType.METHODS,
SerializeType.DEPENDENCIES;

To facilitate the consistent VersionMetricData usage described in comment 1 the 
MetricDataConverter interface was change to always serialize and de-serialize 
VersionMetricData. Additionally, a concrete converter now accepts a type to 
determine what VersionMetricData is actually serialized or de-serialized.

For example, the main interface now looks like and provides the following...

public interface MetricDataConverter
{
    public void serialize(VersionMetricData component, String path)
            throws ConversionException;

    public String serialize(VersionMetricData component)
            throws ConversionException;

    public VersionMetricData deSerialize(Reader data)
            throws ConversionException;
        // ...
}

Usage Scenario:
VersionMetricData vmd; //....

// To serialize just the class part of a VersionMetricData
MetricDataConverter classConverter = new CSVConverter(
                    SerializeType.CLASSES);

// To serialize just the method part of a VersionMetricData
MetricDataConverter methodConverter = new CSVConverter(
                    SerializeType.METHODS);

etc...

// To de-serialize just the class part of a VersionMetricData
FileReader reader = //...
MetricDataConverter classConverter = new CSVConverter(
                    SerializeType.CLASSES);
VersionMetricData vmd = classConverter.deSerialize(reader);

Original comment by jtha...@gmail.com on 28 Aug 2007 at 7:35

• Changed state: Fixed