3.5 USING A METAMODELLING INFRASTRUCTURE

As we saw in Chapter 2, XMIS has been proposed [8] as an infrastructural language for the models that we may need to manipulate in the context of methodology definition and usage, as shown in Figure 2.21. This means that these models are constructed of elements that are of the basic building blocks described by XMIS, i.e. by classes, attributes, objects, tuples, etc. This corresponds to the notion of ontological representation, as described in Section 2.2 (but not to the common usage of the word “ontology” in software engineering; see also Section 2.2), since XMIS establishes the ontology (in its philosophical sense) for the representation processes inherent to the modelling phenomena that we are describing.

XMIS clearly differentiates between the set of types that constitute the SUS (subject under study) and the modelling infrastructure. For example, Figure 3.15 shows how an invoice (the object :Invoice) is an instance of a class in the model (called Invoice) but at the same time is represented in the infrastructure domain by the class Object (of which :Invoice is an instance). It is pointed out [8] that this structure can be applied at any metalevel.

Figure 3.15: Dual instance-of relationships of an entity in the user data domain and its representation in XMIS (after [8])

Source: Gonzalez-Perez, 2005, copyright IEEE Computer Society. Reproduced with permission

As proof of concept, XMIS has been implemented in a toolset (the Xome toolset) [8]. As noted in Section 2.5, XMIS does not impose any layering structure in models, so that any Xome model comprises a single namespace a single container for model elements – the most abstract approach that could be taken. However, partitioning models into different areas is sometimes useful, so a tagging facility has been incorporated. A tag is simply a string that is defined within a model and can subsequently be applied to as many model elements as necessary. Multiple tags can be applied to the same model element, and the same tag can be applied to multiple model elements. The Xome Engine fully supports tags and model element tagging, and has some built-in functionality to filter model elements by tag and automatically assign a pre-selected collection of tags (called the “tagging context”) to each newly added model element. In this way, an end-user tool can set up a given modelling context and, from that point on, any new model element added to the model will be automatically tagged accordingly. Furthermore, tags have a simple permission scheme associated with them. At the model level, permissions can be set for each tag in the model to indicate whether model elements can be edited, deleted, tagged or untagged, depending on the tags on them. For example, a model can incorporate a tag named “ReadOnly” and permissions can be set so that any model element tagged with this tag cannot be edited or deleted.

Finally, Xome offers additional functionality related to the following areas:

• Search. Comprehensive search facilities can be used to find text in a model.
• Document generation. Documents are generated by applying XSL transforms to the XML-stored model. HTML reports and other documents can be easily generated from any model.
• Statistics. Simple statistics (such as counts of different kinds of model elements) can be obtained automatically.
• Model merging and importing. A model can be merged with another model, combining the model elements of both in a single model. A model can also be imported: the imported model elements are combined with the receiver's model elements and are automatically tagged with a pre-defined tag for easy identification.

The Xome toolset has been used to create and maintain different kinds of models, including the following models:

• The Australian Standard AS 4651-2004 [33].
• The International Standard ISO/IEC 24744 [20].
• A sample methodology derived from [20], used for illustrative purposes as part of the standard process.
• The OPEN/Metis metamodel and methodology [7].

In the standards arena, XMIS proved a viable alternative to the normal document maintenance that relies on manual assurance of integrity by laborious crosschecking. The document generation features of Xome were used to create a report containing all the relevant details in the model with the appropriate layout. The task of developing the XSL transform for this report was significant (of the order of two days), but trivial when compared with the time and frustration saved by being able to instantly regenerate the specification document by clicking a button after making changes to the model, and knowing that referential integrity was 100% guaranteed. The documentation for successive iterations of the two standards could be automatically generated by Xome in less than 3 seconds and directly pasted into the final document.

Similarly, the example methodologies included as appendices in these standards were generated from the standard's definition of the metamodel using Xome by importing the appropriate metamodel and then using Xome's tag mechanism. Methodology elements were then created by instantiating and subtyping the elements in the metamodel. The resulting model (namely, the methodology) was saved as a new model and a report generated from it. This report had to contain all the methodology elements but not the metamodel elements, so the XSL transform file used had to filter them away by looking at the tag used during the importing process. As discussed above, the tagging facility of Xome provides a simple way of categorizing model elements (metamodel versus methodology, in this particular case) without imposing strict boundaries between them.

As well as the generation of these two simple, small methodological examples, Xome has been used to create a complete methodological framework, called the OPEN/Metis Methodological Framework [7]. This is a public-domain, integral, object-oriented software development framework that includes a metamodel, a ready-to-use methodology, a set of rules and guidelines to customize and extend the methodology, and a collection of resources and additional materials. The OPEN/Metis metamodel can be browsed online; the metamodel, in fact, is stored as a Xome model, and the Xome Engine runs on the web server. The web pages on the OPEN/Metis website make calls to the Xome Engine as the user navigates through them, navigating the network of method elements and generating pages on the fly as necessary. For example, imagine that the user is displaying the web page for the Language class. This page displays the definition of “language” together with some additional properties of the class, its parent class, and a list of associations to other classes in the metamodel. If the user clicks on one of the association names, such as IsComposedOf.ModelUnitKind, the web server will retrieve from the Xome Engine all the details concerning this association and display them on a new web page.

OPEN/Metis also includes a ready-to-use methodology based on the OPEN/ Metis metamodel. This methodology is specified as a Xome model and stored on the web server. In addition to navigating the methodology model, the user can navigate the relationships between metamodel and methodology, i.e. across conceptual layers, since the methodology Xome model imports the metamodel. For example, imagine that the user is browsing the web page for the “High-Level Modelling” activity kind; in addition to seeing the task kinds related to it and the model unit kinds involved, the user can also navigate “up” to the metamodel since “High-Level Modelling” is an instance of ActivityKind, a metamodel class.

Xome has also been used in the method engineering context, in which prototype tools were implemented for the creation, storage and maintenance of method fragments together with complementary tools to create a software development methodology from these fragments as well as to exercise the method on a real endeavour (such as a project). It has also been used in a subset of the specification of the OOSPICE metamodel and method repository [10].

Finally, and in a very different context, it was used to formalize the Behaviour Trees Technique [32] by designing a model of the major concepts of the technique [9]. Once again, Xome allowed a model to be easily created and maintained and a report to be generated for the final specification.