Model Driven Architecture

Model Driven Architecture (MDA) is an ongoing software engineering effort to standardise model- driven approaches, and is advocated and trademarked by the OMG [243]. MDA focuses on devel- opingarchitecturalstandards for the development and interchange of modelling approaches, and is a MDD approach. At the time of writing, only a draft outline3 of the proposed architectures has been published [243]. In particular, MDA is currently based on two conceptual architectures: a four-layer

metamodelling architecture, and a four-layerviewpoint architecture. These architectures are not mu- tually distinct, but considering both of these architectures simultaneously is useful.

Metamodelling Architecture

The first architecture behind MDA is based on a four-layer metamodelling architecture [243], as illus- trated in Figure3.1; each layer has a practical purpose, as described by Djuri´c et al. [80]. Each layer provides a metamodel for the layer below with an increased layer of abstraction, and the OMG has supplied a relevant modelling standard for each layer. This metamodelling architecture is used for all OMG modelling standards [185].

1. TheReality layer(M0) represents the real-world objects that are being modelled, which can in- clude everything, including non-tangible things such as modelling languages and other abstract concepts. For example, real-world entities such as rocks or trees can be part of M0, as could a running Java application, or its source code.

3_{The technique of publishing a number of drafts before standardisation of a language was also used during the develop-} ment of UML [188] and the HTML standards [333,343].

Metamodel Meta-metamodel Java EBNF [130] SGML ISO 8879 [164] HTML 4.01 DTD [333] HTML 5 English Language [343] XML EBNF [342] DTD EBNF [342] Ecore Ecore [314] EBNF EBNF [165] MOF MOF [251] UML MOF [253,185] English Language English Language

Table 3.1: A list of popular metamodels and their meta-metamodels

2. TheModel layer (M1) represents the model of the real-world object; these models are called

analysis modelsin UML [188]. Individual models are known asmodel instances. For example, a Java application in M0 can be modelled with its Java source code in M1.

3. TheMetamodel layer(M2) represents the model of the models in M1, also known as metamod- els ormodelling languages. For example, all Java source code in M1 must adhere to the Java language specification [130], which would be defined in M2. One OMG standard for metamod- els is theUnified Modeling Language(UML) [254].

4. Finally, the Meta-metamodel layer(M3) represents the model of the metamodels in M2. For example, the definition of the Java language is provided in terms of Extended Backus-Naur FormEBNF [130]. EBNF would therefore be defined in M3. Most importantly, all M3 meta- metamodels are instances of themselves; that is, EBNF is defined formally as an instance of its own syntax [165], and there is no such thing as ameta-meta-metamodel. As a standard for meta-metamodelling, the OMG proposes theMeta Object Facility(MOF) [258].

Importantly, this architecture satisfies the problem on where increasing levels of metamodelling abstraction will end. Since models can themselves be defined in terms of metamodels, it is a realistic question to ask whether this redefinition could continue forever. The maximum number of layers within MDA are restricted to four, by restricting the metalanguage for M3 metamodels to themselves: “The OMG defined that all elements of layer M3 must be defined as instances of concepts of the M3 layer itself” [185, pg. 88].

For comparison, a selection of common metamodels and their associated meta-metamodels are listed in Table 3.1. A full description of each of these models will not be provided here. If the meta-metamodel for a given metamodel is identical to the metamodel, then this meta-metamodel is

M3-compliant according to the MDA, and can be used in the development of an MDA-compliant modelling approach. There are two important relationships illustrated in this table: firstly, HTML 4.01 is defined in terms of DTD, which itself is not M3-compliant; and secondly, HTML 5 had only been defined using the English language at the time of writing [343].

A model instance is not limited to conforming to a single metamodel, and multiple metamodels are usually combined in a logically conjunctive way. For example, HTML 5 is currently defined only in

3.1 Modelling 41

Figure 3.2: The Viewpoint Architecture of MDA, adapted from Mukerji and Miller [243]

terms of the English language, but in the future may also be defined using XML Schema or DTD [343], with each metamodel further restricting the valid range of HTML 5 instances to improve precision. Similarly, the Web Ontology Language (OWL) [351] is defined in three metamodels: EBNF abstract syntax, direct model-theoretic semantics and model mappings [337].

Viewpoint Architecture

A second architecture proposed by the MDA is the four-layer viewpoint architecture [243,185], il- lustrated in Figure3.2. In this architecture, each layer tries to be an independent abstraction of the layer below it, with the intention of simplifying the development of complex model-driven approaches across an entire business, rather than just a software product. Kleppe et al. [185] discuss the imple- mentation of this architecture using a real-world example.

The OMG does not define any standards for any layer, as each layer is instead advocating a partic- ular architecture, although many of these layers could be implemented using existing OMG standards. For example, both a PIM and a PSM can be represented using UML [185].

1. TheComputation Independent Model(CIM) is a software-independent model or business model used to describe a business system.

2. ThePlatform-Independent Model(PIM) is the model of a software system that is independent of any implementation technology, and these models have a very high level of abstraction. It is not possible to automatically translate a CIM into a PIM, because the decision of which parts of the business will be supported by software must be made by a human [185].

3. ThePlatform Specific Model(PSM) is the specification of a software system using a particular implementation technology. In some cases PSMs can be produced from the automatic transla- tion of PIMs, but in many cases the model developer must complete missing parts of the PSM [185]. Importantly, PSMs are only understandable by people who are experienced in the specific implementation technology.

Figure 3.3: The layers of UML under the MDA, adapted from Djuri´c et al. [80]

4. Finally, theCodelayer is the actual implementation of the PSMs. The transformation from PSM to code is relatively straightforward.

Kleppe et al. [185] argue that there are four main benefits from using this MDA architecture. Firstly, by shifting developer focus from platform-specific models to platform-independent models, the abstraction improves the efficiency of development. Secondly, everything specified at the PIM level is completely portable, depending on the automated transformation tools that are available; this also increases the interoperability of models. Finally, Kleppe et al. argue that since the PIM is at a higher level of abstraction than the PSM, the PIM also fulfills the function of high-level documentation.

Meta Object Facility

TheMeta Object Facility(MOF) is an OMG standard that was designed and published as the standard M3 language for all OMG models, and is used to define modelling languages [185]. As a standard defined at the level of M3, the MOF metamodel is defined in terms of the MOF metamodel, and the overall design was heavily derived from UML. The integration of the MOF with other OMG standards like UML is illustrated in Figure3.3. The ambition of MOF – codified as the design goals of the standard – was to simplify the interoperability and communication between different modelling languages, and to clear up some of the definitions used in UML; the full list of design goals is published as part of the MOF specification [258].

The MOF model is also known as the Complete MOF (CMOF) package, which is built upon a subset of the UML 2.0 Infrastructure [253]. MOF also defines a smallerEssential MOF (EMOF) package, which simplifies the complexity needed for compliance4by providing a model focused solely on kernel metamodelling[258]. The Ecore metamodel of the Eclipse Modeling Framework, which also resides at the M3 layer, was built upon EMOF [12] and model instances can be serialised directly to EMOF [314, pg. 40]. A full discussion on EMF is provided later in Section6.2.1.

3.1 Modelling 43

XMI

In order to share models, the XML Metadata Interchange (XMI) standard [250] was proposed by the OMG, which is an XML-based standard for sharing metadata. This standard integrated XML, UML and MOF together into one standard, which is now an international ISO/IEC standard [168]. Many model-driven CASE tools, especially those used for modelling UML such as ArgoUML [286] and Eclipse UML [44], support exporting and importing model instances formatted according to XMI, and a sample XMI model is illustrated in SectionF. In the same way that XML has improved integration between different technologies, XMI can be used to improve integration between different model- driven technologies, and is an important technology behind MOF.

The Big Picture

As the viewpoint and metamodelling architectures in the MDA are not distinct, it can be useful to consider a model-driven approach that uses bothof these architectures at the same time, when try- ing to define the scope of different interacting models. Figure3.4illustrates a range of model-driven technologies that may be used to implement a RIA, and highlights their interaction with the two archi- tectures of the MDA. For example, a RIA may be described in a platform-independent manner, which may then be translated into platform-specific EJB [172] and RIA user interface model instances. These may, in turn, be translated into instances of HTML [343], SQL [186] and other related technologies.

By considering both of these architectures simultaneously, it is easier to understand the interaction between each of these MDA architectures. In the domain of RIA development, it is simple to see how a single model described by a single metamodel (in the PIM) can be implemented using many different RIA technologies, and how every metamodel has an independent meta-metamodel. This figure also illustrates how the PIM model and metamodel should not have any reference to the specific technologies in the PSM or code, highlighting the platform-independence of this layer.

In this example matrix, it is unclear what the PIM M0 for modelling RIAs would represent (marked as ’??’ in Figure3.4), and this remains an unanswered question. Would this represent the real-world mental model of our intentions? Would it represent the analysis or design of the modelling language in this thesis? Both of these appear to be valid answers, as the M0 layer can represent any concept.