Aligning the approach with a standard

The concept of ODM is generic, both in what concerns its mapping to the chosen on- tology specification technology and the formal language that is used to express the specification of the metrics. When defining ontologies (metamodels and models), we will follow an approach aligned with the OMG’s current specification technologies. So, we will specify the metamodels and models in UML, and use OCL for defining and collecting metrics.

A layered architecture

The Meta-Object Facility (MOF) is a platform-independent metadata framework used by OMG and considered a cornerstone of OMG’s Model-Driven Architecture initiative. It provides the basic building blocks for the specification of metamodels, regardless of these metamodels being object-oriented, or not. MOF 2.0 shares a common core pack- age with the UML 2.0 infrastructure library [OMG 06b], represented as Core, in figure 4.1. This Core package acts as an architectural kernel for other OMG metamodels, such as the Comon Warehouse Metamodel (CWM) [OMG 03a], the UML 2.0 metamodel [OMG 06b, OMG 05b], the Corba Component Model (CCM) metamodel [OMG 02a]

and the Object Constraint Language (OCL) metamodel [OMG 03b]. The Core itself is a complete metamodel.

Figure 4.1: OMG’s common Core package and its relation to other metamodels When focusing our attention on the UML 2.0 metamodel, we note the existence of two main parts: the infrastructure and the superstructure. The UML 2.0 infrastructure library [OMG 06b] uses fine-grained packages to bootstrap the the rest of UML 2.0. These packages are useful so that we can build on them to specify other metamodels, using the basic UML 2.0 notation. The main packages in the UML 2.0 infrastructure are the Core package, discussed above, and the Profiles package, where the constructs used for defining UML extensions are defined (figure 4.2).

Figure 4.2: UML infrastructure library

Three key concepts to understand metamodeling are those of classifier, instance, and the ability to navigate from the instance to its classifier. A classifier is a classifi- cation of instances: it describes a set of instances that have features in common. Each instance has exactly one classifier which describes it. Building on these concepts, it is possible to create a layered architecture where the instances at level n have their corre- sponding classifiers at level n + 1. In turn, the classifiers at level n + 1 can be regarded as instances of the classifiers defined at level n + 2, and so on. Several of the OMG’s metamodel specifications rely on 4 levels [OMG 06b]:

• M3. Meta-metamodeling layer, where the language for specifying metamodels is defined. MOF is an example of a meta-metamodel.

• M2. Metamodeling layer, where metamodels, the languages for specifying models, are defined. Examples of metamodels include the UML metamodel, the OCL metamodel, CWM, and the CCM. Metamodels are instances of meta- metamodels.

• M1. Modeling layer, where models are defined. User defined models in UML are among the most typical examples of a model. In general, models are used to define languages that specify the semantics of a domain. The models defined at M1 are instances of metamodels defined at M2. Note that these models also include illustrations, also referred to as snapshots, of instances of model elements (e.g. in UML, the object diagrams represent such illustrations).

• M0. Run-time instances layer, where instances of model elements are repre- sented. These should not be confused with the illustrations of instances defined in level M1. The latter are constrained versions of the M0 run-time instances. Figure 4.3 illustrates the distinctions among the 4 levels, using an example in UML. At the run-time instances layer (M0), we have a run-time instance of a thermometer. This thermometer is modeled at the user model level (M1) both as a class (Thermometer) and as a snapshot of the class (:Thermometer). In turn, the Thermometer class is an in- stance of the meta-class Class, of the UML metamodel (M2). The temperature attribute of the Thermometer class is an instance of the meta-class Attribute. The instance snap- shot is modeled with the Instance meta-class.

Although the typical number of meta-levels ranges from 2 to 4, MOF-based meta- models can have at least 2 meta-levels, and as many meta-levels as one chooses to define. As we have seen, UML is an example of the usage of 4 meta-levels. The MOF specification [OMG 04] provides other examples of configurations, such as 2 meta- levels, for a generic reflective system, with classes and objects, and 3 meta-levels, for relational database systems, with SysTables, tables and rows.

The Object Constraint Language

MOF-based metamodels may include not only meta-elements, but also constraints ap- plied to those meta-elements and to the meta-associations among them. These con- straints are referred to as well-formedness rules, and can be formally specified using the Object Constraint Language (OCL) [OMG 03b]. OCL is a formal language designed to specify expressions on UML models that are typically used either as constraints on the model, queries on its state, or specifications of operations or actions, always in a programming language independent way. OCL expressions are side-effect free, so

Figure 4.3: An example of the layered metamodel hierarchy

their evaluation does not alter the state of the system upon which they are defined, even if they specify operations that, when executed, would change the system state.

As MOF-based metamodels are defined using a subset of the UML language, OCL can be used on these metamodels. So, OCL is not only programming language inde- pendent, but also “MOF-based metamodel” independent.

To illustrate the usage of OCL as a constraint language, consider an extract of the UML 2.0 metamodel concerning the provided and required interfaces of a component. Figure 4.4 presents the associations, provided and required, between the meta-class BasicComponent_{and the meta-class Interface.}

The provided and required associations are derived associations. The well- formedness rules of both derived associations are expressed in the UML metamodel both in natural language and with OCL. For illustration purposes, consider the spec- ification of the derived provided interfaces association. Provided interfaces are “the interfaces that the component exposes to its environment. These interfaces may be Realized by the Component or any of its realizingClassifiers, or they may be the Interfaces that are provided by its public Ports. The provided interfaces association is a derived association” [OMG 05b]. In OCL, these constraints are expressed as in listing 4.12.

2_{This listing is extracted, from the UML 2.0 metamodel specification [OMG 05b]. Understanding all}

its details would require analyzing a larger extract of the UML 2.0 metamodel than the one presented in figure 4.4. Here, our purpose is only to illustrate some of the features of OCL

Figure 4.4: Extract of the UML 2.0 metamodel

Listing 4.1: An example of UML 2.0 well-formedness rules in OCL.

c o n t e x t C o m p o n e n t :: p r o v i d e d deriv e :

let i m p l e m e n t e d I n t e r f a c e s = self . i m p l e m e n t a t i o n -> c o l l e c t ( impl | impl . c o n t r a c t ) and

let r e a l i z e d I n t e r f a c e s = R e a l i z e d I n t e r f a c e s ( self ) and let r e a l i z i n g C l a s s i f i e r I n t e r f a c e s = R e a l i z e d I n t e r f a c e s ( self . r e a l i z i n g C l a s s i f i e r ) and let t y p e s O f R e q u i r e d P o r t s = self . o w n e d P o r t . p r o v i d e d in ((( i m p l e m e n t e d I n t e r f a c e s - > union ( r e a l i z e d I n t e r f a c e s ) -> union ( r e a l i z i n g C l a s s i f i e r I n t e r f a c e s )) -> union ( t y p e s O f R e q u i r e d P o r t s )) - > asSet () def : R e a l i z e d I n t e r f a c e s ( c l a s s i f i e r : C l a s s i f i e r ) : I n t e r f a c e = ( c l a s s i f i e r . c l i e n t D e p e n d e n c y - > sele ct ( d e p e n d e n c y | d e p e n d e n c y . o c l I s K i n d O f ( R e a l i z a t i o n ) and d e p e n d e n c y . s u p p l i e r . o c l I s K i n d O f ( I n t e r f a c e ))) -> c o l l e c t ( d e p e n d e n c y | d e p e n d e n c y . client )

This well-formedness rule illustrates some features of the OCL which are relevant for our work. OCL expressions provide a side-effect free mechanism of extracting in- formation from a model. OCL allows collecting information about the model (in this case, the UML 2.0 metamodel), while navigating through it. In this perspective, OCL can be viewed and used as a model query language. This property is useful for the collection of model elements according to any constraints we may specify with OCL. For instance, in the Component::provided well-formedness rule:

• implementedInterfaces is defined by selecting the collection of implementation associations and, for each of those, collecting all the corresponding contracts.

• realizedInterfaces is defined through an extra function,

RealizedInterfaces(), also presented in listing 4.1.

• realizingClassifierInterfaces is also defined through the function

RealizedInterfaces().

• typesOfRequiredPorts is the union of the interfaces provided by the ports owned (ownedPort by the component.

Depending on the collection process, the resulting collection can be of different types, such as bags, or sets. OCL includes several utility operators on collections that allow, among other things, to make transformations between different kinds of collec- tions. For instance, given a bag of integers, where integer values may be repeated, one can obtain the corresponding set of integers, where no duplicate values exist, using the function asSet(). We can see an example of this transformation in the derived rule provide. We can also flatten (i.e. recursively add elements of nested collections to a single collection) a collection, with the operation flatten(), or compute the number of elements in the collection, with the operation size().

Besides being usable as a query language, the syntax of OCL is similar to that of programming languages, making it accessible for practitioners. Furthermore, OCL was designed to complement UML with a constraint specification language. Practi- tioners familiar with UML may also be familiar at least with some basic usage of the OCL language, e.g., through the definition of guard conditions in activity diagrams. Although historically the support provided by UML tools has been insufficient, UML 2.0 tools (e.g. Together Architect3) are progressively including support for the usage of OCL in their models.

In summary, OCL can be used as a query language for UML models, has a syntax that is accessible for practitioners and is increasingly being supported by UML tools. In our opinion, this combination of features makes OCL a well-suited candidate lan- guage for dealing with the metrics ill-definition problem. Practitioners can use a UML tool to specify the metamodel of the concepts which are relevant for their metrics col- lection, load that metamodel with the model instances representing the artifacts they aim to measure, and use OCL not only to specify, but also to collect metrics on those models. The necessary context for defining metrics is provided by the specified meta- model. The metrics definitions are not ambiguous, as they are specified through OCL constraints. We can also specify the conditions under which the metrics can be com- puted, through pre-conditions expressed in OCL. Finally, the usage of standardized languages for defining the measurement context (a metamodel defined with UML)

and the metrics (through OCL functions) facilitates the replication of metric collection initiatives, thus fostering the independent validation of metrics.