2.5 INFRASTRUCTURE

We began this chapter saying that metamodels, methodologies and endeavours are all expressed as models, and that a language to represent them needs to be found. Chapter 1, at the same time, established that methodologies must serve as “templates” from which endeavours can be obtained, and metamodels, in turn, must be able to generate methodologies and also represent, to a certain extent, endeavours (Section 1.2.3). Conversely, metamodels themselves need to be defined. The traditional approach here is to introduce a metametamodelling layer that supports the various metamodels. In other words, a high-level model for which the SUS is metamodels. Such a metametamodel would contain a minimal set of concepts from which could be generated metamodels. Of course, this could rapidly become an infinite regression, so the OMG, for example, state that the metametamodel (M3 in their terminology) is its own metamodel, thus introducing ambiguity [18]. As an alternative, and one that supports the non-linear (linguistic versus ontological) hierarchies proposed in [5] and discussed in detail in Chapter 4, Figure 2.21 suggests that there should be a modelling infrastructure, seen as orthogonal to the metalevel hierarchy, that supports modelling at any “abstraction level”. This is called the Xome⁷ Modelling Infrastructure, or XMIS (see Figure 2.22, which also shows the chain of representation relationships between the various software engineering domains). Since the three domains are connected by strong representation relationships, it is expected that using the same modelling language will ease the generation of models in one domain from models in the source domain whenever it is necessary. In this scenario, a different modelling language would require a mapping layer between domains.

Figure 2.21: The modelling layer stack as defined by Xome – the left-pointing arrows show that each meta-level (or domain) is also an instance of the modelling infrastructure (after [18])

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

Figure 2.22: Representation relationships between the Metamodel, Methodology and Endeavour domains, expressed in XMIS (the Extended Modelling Infrastructure language)

This section focuses on describing the XMIS approach, as a prelude to the following chapters.

2.5.1 Basic Modelling Elements

As we have seen above, the XMIS [16; 18] establishes an infrastructure modelling language, i.e., a generic, domain-independent language that is capable of representing models in different domains, from metamodels to methodologies and endeavours. Metamodels and methodologies can be seen as languages as well, since they are used to express other models (metamodels to express methodologies and methodologies to express endeavours), and therefore the expressive power of XMIS focuses on structure rather than dynamics. XMIS uses a very basic set of object-oriented concepts plus a few extra elements, such as powertypes, that extend the object-oriented paradigm beyond its usual boundaries.

Since XMIS provides a formal underpinning to all modelling domains, it is important that the concepts, although generally well known at a low precision level, are clearly defined. The type-level modelling elements used by XMIS are:

• Class. A class is an intensional specification of a collection of objects, which includes a coherent collection of attributes and association ends. For example, a payroll system could define classes named Person and Position. A class can be a subclass of another class using single specialization and can be marked as abstract.
• Attribute. An attribute is a specification of a typed piece of data associated to a class. For example, a Person class could have attributes GivenName, FamilyName and DateOfBirth.
• Association. An association is a specification of a relationship between two classes. For example, the classes Person and Position may be related by the association Occupies.
• AssociationEnd. An association end is a specification of how a class is involved in a specific association. For example, the class Person is involved in the association Occupies (to Position) with a cardinality of 0 to 1 (i.e. zero or one persons can occupy a given position at any moment), while the class Position is involved in the same association with a cardinality of 1 to many (i.e. a given person can occupy any number of positions greater than zero at any point in time). An association end also involves an optional role name, a whole–part flag and a link to the opposite association end, i.e. the association end that represents the same association seen from the opposite end.

As well as type-level elements, XMIS makes tight definitions of several instance-level modelling elements:

• Object. An object is an instance of a class. Objects take a specific value for each of the attributes of the class and may be involved in tuples. In our example, objects of class Person would represent real people and objects of class Position would represent real positions.
• Value. A value is a piece of data associated to an object, corresponding to a particular attribute of the object's class. In our example, the class Person could have an instance (i.e. an object) with values “Isabel” (for the GivenName attribute), “Cobas” (for FamilyName) and 26-Oct-1970 (for DateOfBirth).
• Tuple. A tuple is an ordered pair of objects linked by a particular association between their respective classes. For example, an object of class Person plus an object of class Position may be linked into a tuple for the Occupies association; this tuple would represent the fact that the associated real person occupies the associated real position.

2.5.2 Exotic Modelling Elements

The basic modelling elements enumerated in the previous section can express a wide range of object-oriented models, but cannot solve the categorization problems exposed in Section 2.3. To this purpose, the following modelling elements are introduced formally in the context of XMIS as:

• PowertypePattern. A powertype pattern is a combination of a partitioned class plus a powertype class. The partitioned class represents objects that can be further classified into subclasses, while the powertype class represents each of the particular subclasses. For example, the class Position may be the partitioned class in a powertype pattern that also involves the class PositionKind as a powertype. Each particular kind of position would be represented as a subclass of Position and, simultaneously, an instance of PositionKind.
• Clabject. A clabject is a composite entity that has a class facet plus an object facet, both of which represent the same entity in the SUS. Clabjects are useful to represent instances of powertype patterns. In our example, a particular kind of position (such as ExecutivePosition or TechnicalPosition) is represented by a clabject, comprising a class (subclass of Position) plus an object (instance of PositionKind).

2.5.3 Using the Infrastructure

As an infrastructure language, XMIS is not explicitly used by an individual creating a model. For example, a methodologist putting together a methodology would use the metamodel as an explicit language to express the methodology, not XMIS; if the metamodel included a class TaskKind, for example, the methodology would include instances of this class, thus being expressed in terms of the metamodel rather than XMIS. Notice, however, that TaskKind is a class, and that its instance in the methodology is an object; class and object are notions defined by XMIS. This is how XMIS works, by establishing the foundational ideas on which higher-level models are built. In Chapter 3, we demonstrate more uses of the XMIS infrastructure in various application areas.