On the OAIS Information Model as a Platform-Independent Model (PIM) in a Model-Driven Software Architecture
by Alistair Miles
This short paper summarises some work done on the possibility of using OAIS information model as a basis for the model-driven design and implementation of components within a digital preservation software architecture. Two model transformations were defined using the Enterprise Architect template language. The first model-transformation transforms a platform-independent UML class model (PIM) into a set of UML interfaces specific to the Java 1.5 platform (here called a Java API model). The second model-transformation transforms a platform-independent UML class model (PIM) into set of UML classes specific to the Java 1.5 platform, implementing the interfaces generated by the first model-transformation (here called a Java implementation model). Both were applied to the OAIS information model as PIM, and the generated models are presented here with discussion.
The CASPAR project aims to design and implement components of a distributed digital preservation architecture, taking the Open Archival Information System (OAIS) Reference Model as the basis for this architecture. Parts of the OAIS reference model are defined using UML class diagrams. Can these UML class diagrams be used in the design of CASPAR software components? Can they be used directly, or do they need to be refined in some way? What design patterns, principles and methodologies should be used to guide this refinement?
A standard pattern for the design of software systems using UML is to define a platform-independent model (PIM), and then to use model-transformations to generate other models, each specific to a given software platform (e.g. Java or C++). These platform-specific models (PSMs) are then used to generate code in the given language. These models and the resulting software system constitute a model-driven architecture. @@REF
This paper presents some work exploring the feasibility of using the OAIS information model as a platform-independent model in a model-driven design and implementation process, with Java 1.5 as one of the target platforms.
Enterprise Architect 7 was used as the primary tool for developing UML models and model-transformations. EA7 supports a bespoke template language, which can be used to define and then execute arbitrary model-transformations. EA7 also includes a number of pre-defined model-transformations for specific platforms, including Java. The pre-defined Java transformation preserves most aspects of a UML class model intact, for example it transforms a class into a class and an interface into an interface; it does, however, convert platform-independent data types to Java primitive types, and it adds public getter and setter methods for each attribute and navigable association of a class or interface, following the Java beans pattern.
Although EA7’s pre-defined Java transform provides some useful functionality, it is not sufficient for the CASPAR design process, for several reasons. Firstly, it handles multiplicities of greater than one poorly. Secondly, it does not make use of Java generics. Thirdly, the approach taken so far in CASPAR has been to define two models: an interface model (an API) and an implementation model (a set of classes implementing that API), each with their own distinct package paths. EA7’s pre-defined Java transformation simply converts package to package, class to class and interface to interface, and so cannot be used to generate CASPAR’s two separate models (API and implementation).
To overcome these limitations, two new model-transformations were defined using EA7’s template language. These transformations were based on the pre-defined Java transformation, with a number of modifications. The first transformation converts classes in the PIM into interfaces in a Java API model, in a fixed package (info.preserveddigital.infomodel). The second transformation converts classes in the PIM into classes in a Java implementatio model, in a fixed package (eu.casparpreserves.infomodel). Both transformations include modifications to handle all multiplicities appropriately, including the use of Java generics with Java collections where attributes or associations have multiplicities greater than one.
All class diagrams from section 4.2.1 of the OAIS reference model were then added to Enterprise Architect as a single package within a platform-independent model (PIM). The text of section 4.2.1 was completely ignored in the construction of the PIM, i.e. none of the informal statements made in the text were added as features of the model, so the PIM was a faithful transcription of the diagrams in section 4.2.1 only.
The pre-defined Java transformation, the custom Java API transformation, and the custom Java implementation transformation were then all applied to the PIM, and the output stored in EA.
To give a flavour for the outputs of the two model-transformations, consider the class diagram illustrated in figure 4-10 of the OAIS reference model. Figure 4-10 defines the relationships between data objects, information objects and representation information. This class diagram, as the PIM used here, is given below.
The diagram below was composed from the output of the custom Java API model-transformation. Notice that each interface in the transformation output has getter and setter methods for each of the associations in which the original class was involved. Notice also that the interface RepresentationInformation has getter and setter methods for associations given in the PIM in another diagram (from figure 4-11 in OAIS).
The diagram below was composed from the output of the custom Java implementation model-transformation. Notice that all of the getter and setter methods implementing the corresponding interfaces are present. Notice also that private members for each of these properties are also now present, allowing generation of Java source code with initial code for getter and setter method bodies.
Finally, compare these with the output from EA7’s pre-defined Java transformation.
In UML, each connector (link) can have a name, and both source and target roles for that connector can also have a name. However, in the OAIS information model, some links have a name, some don’t, and none of the links have role names. If role names are present, these can be used to give more sensible names to getter and setter methods and private members. However, without role names, the class name of the target type has to be used (e.g. getRepresentationInformation). This is fine when there is only one connector between any two classes, but where there is more than one connector between any two classes, role names are needed to disambiguate between them. Therefore, it is suggested that all connectors in the OAIS information model be given a link name, a source role name (if source is navigable) and a target role name (if target is navigable).
Notice that the class
InformationObject has a method
getRepresentationInformation():RepresentationInformation, due to the composition association between
RepresentationInformation. Notice also that the class
RepresentationInformation has a method
getRepresentationInformations():java.util.Collection due to the recursive association on that class. The class diagrams in the OAIS information model do not specify that
RepresentationInformation is a sub-class of
InformationObject, hence this generalization is not present in the PIM used here. However, the text suggests such a generalization. If
RepresentationInformation were a sub-class of
InformationObject, then the class
RepresentationInformation would end up with two methods, both
getRepresentationInformation():RepresentationInformation (inherited) and
getRepresentationInformations():java.util.Collection. This is due to the fact that the two “interpreted using” connectors have different multiplicities in OAIS. This creates an ambiguity, which would have to be resolved.
This is an example of the type of issue that can be revealed by an analysis of the output of a model-transformation on the OAIS information model as a PIM. It is expected that further analysis of other aspects of the transformation output will reveal similar issues with other classes. Therefore, it is recommended that further study be given to the model-transformation output generated using the transformations described here, and that this be fed back into further iterations of the OAIS information model.
There are potential issues with using the OAIS information model as-is as a platform-independent model in a model-driven design process. The output of model-transformations require inspection and refinement before being suitable for implementation in preservation systems. This is not necessarily a shortcoming of the OAIS information model, but does raise an important question: is the OAIS information model intended to serve as a genuine basis for the implementation of software, or is it merely intended as a guide to understanding?
Further study of the outputs of the model-transformations generated here is recommended. This study is likely to complement the findings of any attempt to re-engineer the OAIS information model as a a formal ontology, which has elsewhere revealed potential ambiguities and inconsistencies therein.