- 1 Implementation of MXv2
- 2 The Data Model
Implementation of MXv2
This data model is a version of the Development MXv2 model that is intended for implementation in the current EDNA framework. Please note that the model is currently very incomplete, and more work is required. In particular, it should model the data required to support the following operations:
- spot search
- solution refinement
- indexing solution selection
- prediction generation
Consequences of implementation in the EDNA framework
When work on MXv2 was started, the intention was that any element available in the UML might be used in order to express as correctly as possible the scientific content of the data (hence the description "convention-free"). Now we are aiming for an implementation this is no longer the case. The consequences of implementing an association-rich model like MXv2 using the EDNA framework must be considered.
Generation of XSD
It is no longer possible to generate the XSD in a single step within Enterprise Architect. Instead a two-stage procedure is used:
- The UML model is transformed inside Enterprise Architect into a new model with the <<XSD Schema>> stereotype. This transformation includes EDNA-specific customisations to the UML-to-XSD transformation template.
- An XSD file is then generated from this new model.
For persistence, EDNA uses a trivial transformation of the data model to XSD that has no notion of reference semantics. (This transformation is the default one that is built in to Enterprise Architect, with the intended purpose of maintaining an XSD using UML constructs. Sparx Systems did not intend this transformation to be used to generate an XSD that specifies a persistence layer for an arbitrary UML model.) In this transformation objects are represented by XML elements, and a link (i.e. an instance of an association) between two objects is represented by one XML element containing another one.
Structure of persisted data
The main consequence of persisting links by containment of XML elements is that the persisted data are tree-structured, and graphs cannot be represented. Any object that has more than one "incoming" reference must be persisted by making a separate copy of that object for each such reference. More, it is not just the referred object itself that must be duplicated, but the entire subtree of data rooted at that object. On unmarshalling the data from the persisted XML, there is no general way of knowing whether two objects were created by such duplication and should be considered to be the same instance, or are in fact distinct objects, except by a 'deep' attribute-by-attribute comparison of the entire subtrees.
As an example of this, in order to specify the parameters of a SubWedge instance, it is necessary to make a copy of GoniostatAxis object to specify how the subwedge was collected. The new GoniostatAxis instance must also carry a copy of its calibration data.
Directionality of containment
The tree structure also leads to some highly unnatural structural aspects, for example a SubWedge contains Wedges. Doing it the "natural" way (i.e. that a CollectionWedge contains SubWedges) would still not allow a ProcessingWedge to contain Subwedges.
Containment direction of associations is explicitly modelled, so that it is predictable in the generated XSD. Arrow heads on the associations indicate the direction of containment: the arrows point away from the root, towards the leaves. (This may seem to be the wrong way around, but it is necessary to do it that way because of the way that Enterprise Architect generates XSD.)
Some associations are impractical to implement, in particular where there are cycles in the model. Associations with no arrow at either end are for documentation purposes only: they do not feature in this implementation.
Of particular importance is the fact that the associations between the various instrumental settings classes and their instruments cannot be implemented. This means that any data file in this implementation must not contain more than one instance of each of the RotationalGoniostat, Detector and Beam classes. If this condition is violated, it will be impossible to connect the instrumental configuration data and the data collection conditions.
Implementation of various UML constructs
Overriding of inherited attributes in the UML model results in an invalid XSD being generated by Enterprise Architect (XSD itself does not support feature overriding directly). Attributes with the the <<demoted>> stereotype have been demoted from an ancestor class in order to allow the generation of a valid XSD.
Association classes are not mapped correctly to XSD. Classes with the <<associationclass>> stereotype (shown in the diagrams below with the AssociationClass icon from Enterprise Architect in the upper right corner) have been transformed by hand to conventional classes.
The Data Model
The Development MXv2 data model page contains a lot of information about the scientific thinking behind the structure of this model. It may be helpful to refer to that when interpreting the diagrams below.
These are based closely on the XSDataCommon datatypes. Deprecated types have been removed, and a few minor changes made.