Chapter 1
Metamodeling in Software Architectures
Chapter written by Adel SMEDA and Mourad Chabane OUSSALAH.
To manage the complexity of systems and enhance their understanding, different modeling techniques (e.g. object-oriented, component-based and services-oriented software architectures) often define two or more modeling levels using the definition of a metamodel, or even a meta-metamodel to explain, comment, document, simplify, create and compare models.
In this chapter, we intend to emphasize the importance of metamodeling in the context of software architecture compared to the metamodeling in the object paradigm. This concept helps to abstract architectural concepts (components, connectors and configurations) and facilitate handling, using and reusing, analyzing and developing software architectures.
1.1. Introduction
During the last two decades, several languages for describing software architectures have been proposed to promote the development of architecture-focused applications. These languages provide, in general, formal or semi-formal notations for describing and analyzing software systems. They are usually accompanied by tools to analyze, simulate and, sometimes, to generate the code of the modeled systems. The consensus on the fundamental concepts that architecture description languages (ADLs) must include was achieved relatively late; however, through the efforts of standardization and interoperability, new ADLs (known as second generation ADLs) were introduced.
Moreover, it is proved that the specification of an architecture may go through several levels of modeling, thus reflecting different categories of users (application architects, application developers, builders of software infrastructure, etc., see Chapter 3). One of the most appropriate techniques to highlight these different levels of modeling is metamodeling and, more precisely, the software architecture modeling frame that implements the four levels of modeling proposed by the Object Management Group (OMG) [OMG 03]. The highest level is represented by the meta-object facility (MOF) meta-metamodel [MOF 02]. The goal of MOF is to define a single standard language for describing metamodels. It consists of a relatively small set (although not minimal) of “object” concepts for modeling this type of information. For example, unified modeling language (UML) is one of the metamodels described using MOF. Other notations for object metamodeling also exist, including KM3 [JOU 06], ECORE [BUD 08] and Kermeta [MUL 05].
In software architecture field, very few works have adopted the technique of metamodeling. Architecture Meta-Language (AML) [WIL 99] is the first attempt to offer a base that provides ADLs with a solid semantic base. AML only defines the statements of three basic constructions: components, types and relationships.
In this chapter, we propose an approach to model software architectures at different levels of abstraction using a meta-metamodel called Meta Architecture Description Language (MADL) [SME 05a].
In this context, MADL, like MOF, works as a unified solution for architectural representations. In addition, it allows easy handling, using, reusing and developing of software architectures. It reduces the complexity of software architectures and facilitates the transformation and transition of architectures from one to another. In addition, this meta-metamodel has a minimal core whose purpose is to define the concepts and basic relations, such as metacomponents, metaconnectors and metainterfaces. Based on this meta-metamodel, we describe a strategy for mapping of ADL concepts to UML concepts (particularly UML 2.0). We used UML as an example of mapping because of its popularity in the industrial world. This strategy is carried out in four steps: instantiating MADL by the selected ADL, mapping MADL to MOF, instantiating MOF by UML and, finally, the selection of the most appropriate UML concepts for the selected ADL. This strategy reduces the number of concepts obtained. As an example, we will show how to map the ADL Acme [GAR 00] to UML 2.0.
1.2. Metamodeling, why?
An act of metamodeling has the same objective as an act of modeling with the only difference in the modeling purpose. In all cases, it involves supporting all or part of the lifecycle of a model: (formal or informal) specification, design and implementation. In the case of reflexive models, metamodeling makes it able for models to describe themselves.
We distinguish three different views of metamodeling [BOU 97]:
– Metamodeling as a reflexive technique: metamodeling is an act of modeling applied to a model. It can allow a model to self-represent itself: we refer to this as reflective models.
– Metamodeling as a technical dialogue: a picture is worth a thousand words. This technique is increasingly used to explain, comment upon, document and compare models (in particular semi-formal models used in design methods). It is concerned with describing a model by its conceptual concepts, the result of this is a specification step using a semi-formal (most of the time) metamodel. This mapping therefore constitutes an explanatory document and/or documentation of the model. It can also serve as a means of comparison and unification of models.
– Metamodeling as technical engineering: this is concerned with documenting, explaining and unifying “semi-formal” models. Natural languages, if not so ambiguous, could be used as a metamodel. This is not the case in an objective to support model engineering. It means applying our own engineering techniques to our models. We can model a model for the same reason as application systems are modeled.
1.3. Software architecture metamodeling
Metamodeling techniques have now reached maturity and have been widely used to address real problems in programming languages, databases, engineering models or distributed systems. In this chapter, we will show how these techniques can be applied to the field of software architecture. We will also highlight the need to propose mechanisms of reflexivity in the context of software architectures metamodeling.
In knowledge representation, we talk about meta-knowledge to evoke knowledge about knowledge, metamodel for a model representing a model, etc. [OUS 02]. In the context of software architectures, metamodeling is an act of modeling applied to the architecture. The result of an act of modeling, i.e. using an architecture to establish an abstraction of an application architecture, is called architecture (level A1 in Figure 1.1) the A0 application. Similarly, the meta-architecture of an architecture itself is an architecture that models an architecture. Since the act of modeling applies to software architectures, the process is called meta-architecting. A meta-architecture is therefore a formal or semi-formal ADL that allows the modeling of particular systems, namely architectures. The meta-architecture (level A2) is an architecture itself and therefore, in a more general way, a system can thus be modeled. We then obtain the architecture of the metaarchitecture: meta-meta-architecture (level A3). As with any recurring modeling, this process should stop on a reflexive architecture, that is selfdescription. The number of levels makes little difference, but it seems that three levels of modeling are sufficient in an architecture engineering framework where level A3 will be used to self-model and model ADLs.
Figure 1.1. Four levels of modeling in software architectures
In the context of object-oriented models, this self-modeling is generally implemented by the concept of a metaclass that guarantees the uniformity of concepts and extensibility of the system. This involves designing an architecture by itself or using an architecture to describe or design another architecture.
Metamodeling can also be a means of formalizing semi-formal architectures. Formal ADLs based on mathematical forms ensure unambiguous specification. However, these formal ADLs may seem repulsive to application designers, and they are not easily understood by an untrained person. It is therefore useful to be capable of carrying out transcription of a semi-formal specification using a formal specification. The approach is to specify, once and for all, the concepts of semi-formal architecture in a formal specification. We then obtain a meta-architecture of the semi-formal architecture, which can be used directly. The formal architecture is used as a meta-architecture and produces the meta-architecture of the informal architecture.
To summarize, we can say that the meta-architecture is a good way to:
– Standardize: architectures that are based on well-defined semantics. These semantics are provided through meta-architectures. Each architecture must conform to a meta-architecture, which shows how to define architectures. The description of different architectures using the same meta-architecture gives the meta-architecture a standardization role.
– Use and reuse: the same meta-architecture can be used and reused several times to define new architectures.
– Compare: the meta-architecture is a good tool to compare several architectures. In fact, the description of several architectures with the same formalism facilitates comparison and analysis.
– Define and integrate multiple architectures: the meta-architecture facilitates and supports exchange of architectures between the ADLs.
1.4. MADL: a meta-architecture description language
1.4.1. Four levels of modeling in software architectures
The four levels of OMG metamodeling [MOF 02] (see Table 1.1) can be applied to software architecture. The result is a conceptual structure of four levels: meta-meta-architecture level, meta-architecture level, architecture level and application level, as shown in Table 1.1:
– The meta-meta-architecture level (M2A, denoted as level A3): this provides the minimum components of modeling architecture. The basic concepts of an ADL are represented at this level (e.g. metacomponent and a metaconnector in Figure 1.2).