Skip to main content
Jump to: navigation, search

Difference between revisions of "MoDisco/Components/Java/Composition/Architecture"

(Java Composition Metamodel)
(Java Composition Metamodel)
Line 1: Line 1:
== Java Composition Metamodel ==
This metamodel aims at weaving a MoDisco Java Model with a MoDisco KDM Source one.
The Java Composition Discoverer uses this metamodel to create liaison between model elements.
In addition to that, some weaving is done to link java nodes to their physical position in the analysed code. Those elements are stored in the JavaNodeSourceRegion.
References java2DirectoryChildren and java2FileChildren should be containment references, but then browsers load all the resources instead of performing lazy loading (see section Benchmark below). This is due to the use of getAllContent() method which retrieve external references.
[[Image:JavaApplicationMetaModel.png|frame|center|JavaApplication MetaModel]]
== Benchmark  ==
== Benchmark  ==

Revision as of 08:31, 18 August 2010

DEPRECATED use Template:MoDiscoTabs and Template:MoDiscoTab as explain here : Wiki Template for MoDisco


Java Composition Model, weaving KDM Model Source and Java Model, can easily become a big model, in terms of XMI size as well as number of model elements.

First implementation resulted in a single XMI file containing all the weaving elements between both models.

Second implementation results in a root XMI file, referencing other xmi fragment

Splitting was done following this repartition :

  • First resource contains the JavaApplication itself
  • Second resource contains all Java2Directory
  • One resource per package/directory

This splitting enable the browser to perform lazy loading when browsing a composite model in the MoDisco Model Browser It has been decided to split after realizing a benchmark on the memory consumption of the MoDisco model browser.

Three levels of resource

Memory usage

This figure shows the memory used by the MoDisco Model Browser on several xmi resources obtained with the Java Composition Discoverer. The gain of memory thanks to the lazy loading is significant.


Saving time

To decide which spliting solution to choose, we made another benchmark on the time spent on serializing the resource on the hard drive. Moreover, serializing plenty of files (one xmi for each java classes) creates a lot of hard drive access resulting in some delay while browsing


Back to the top