Building families of languages for model-driven system ... - CiteSeerX

Building families of languages for model-driven system development Andy Evans, Girish Maskeri, Paul Sammut, James S. Willans

Abstract

recognition that models rather than code should become the primary artefacts that drive software development, as demonstrated by the momentum gathering for the OMG’s recent Model Driven Architecture (MDA) initiative[3]. MDA concerns the construction, integration and transformation of models (see section 2.1), each of which must be constructed in some language. An important MDA question that arises is whether there a single modelling language that can be used to define all these models. UML is an obvious candidate for that role, particularly since it has been refactored from a one-size-fits-all modelling language into a family of languages. However, a truly flexible model-driven development process should not dictate the language that practitioners should use to construct models, even an extensible one. Instead they should be free to use whichever language is appropriate for their particular domain and application, particularly as many languages cannot be shoe-horned into the UML family[4]. Such a process also needs to support model interchange, integration and transformations - models in one language need to be able to communicate with or be translated to models in another language. Within MDA, this is achieved by defining each language in a common metamodelling language called the Meta-Object Facility[5] (MOF), and by providing mappings between them1 in a common metamodel architecture. MDA is an ambitious vision that relies upon a variety of flexible, intuitive, semantically rich modelling languages. Often a language needs to be extensible or customisable to maximise its potential usage (UML for example) - these language variants together form a language family. MDA itself can

The Model Driven Architecture (MDA) is an ambitious vision that relies upon a variety of flexible, intuitive, semantically rich modelling languages. In order for models to be integrated and transformed between such potentially disparate languages, the languages themselves must be integrated. This motivates the notion of a ’family of languages’, a concept that plays an important role in the MDA vision, but is often too vaguely defined in associated literature. This paper motivates the need for families of languages within MDA, and illustrates how there are multiple ways of interpreting and implementing modelling language families. A set of criteria is presented which illustrates the various considerations involved when constructing families of languages along with the inherent trade-off between those considerations. The paper then provides a brief exploration of a number of metamodelling mechanisms that can be used and combined in the construction of language families, and these are evaluated against the criteria presented earlier. Finally some overall guidelines for constructing language families is presented, which demonstrates the importance of clarifying the requirements before building and integrating modelling languages.

1

Introduction

Recent trends in software engineering have recognised the value of developing systems at higher levels of abstraction. Evidence of this can be seen by the rise in popularity of visual modelling languages and methodologies such as Booch, OOT and OOSE, culminating in the emergence of the Unified Modeling Language (UML)[1], a standard maintained by the Object Management Group (the OMG)[2]. More recently there has been increasing

1 To this end, the OMG is extending MOF with a plugin for describing mappings - this is covered by the MOF Query View Transformations (QVT) RFP[6], the submission process for which is currently underway.

1

be thought of as a large scale family of languages, through the mappings that are provided between the language metamodels. Thus language families play an important part in MDA, and for the vision to work effectively, mechanisms must be in place to enable new languages and language families to be rapidly constructed and properly integrated. A discussion of these mechanisms and how they may be combined and applied is the key focus of this paper. Section 2 outlines the characteristics and architectural features of language families, as well as important criteria and considerations to be taken into account when building language families. Section 3 briefly describes a number of modelling mechanisms that can be utilised for constructing metamodels for languages and language families, which are evaluated against the criteria introduced earlier. Some general guidelines for the construction of language families are briefly presented in section 4, and finally section 5 highlights some overall conclusions to be drawn from this paper.

2 2.1

Abstraction / refinement

s iant Var

Aspects

Figure 1: Dimensions in The Modeling Space. Based on [7].

2.2

What is a Family of Languages?

The concept of a family of languages plays a significant part in MDA, so it is important to clarify what it means. The term was originally coined by Cook et al. in the context of the UML family[8], and the most common interpretation of ‘family of languages’ is that implied by the UML family model. This uses a language core with a set of extensions that define the additional language constructs and relationships for the family members. This interpretation of a language family is depicted in Figure 2(a), and will be described in this paper as a ‘language product line’2 .

Families of Modelling Languages Language Integration

Primarily MDA concerns models of many kinds, and mappings between those models. The most familiar scenario is the transformation (via a mapping) from Platform Independent Models (PIMs) language to Platform Specific Models (PSMs), although the core full scope of MDA is considerably wider. Mappings Language may also be used to relate models that describe dif1 extension extension ferent cross-cutting concerns of a system (such as 1 2 Language persistence, performance monitoring and security), 2 subject areas (marketing, engineering and sales) or Language extension extension 3 1a 1b different variants of a system within a product line or system evolution[7]. Together all these models (a) A language product (b) A language integration and the mappings that allow them to be integrated line framework or transformed can be thought of as the dimensions in a three dimensional modeling space, as depicted Figure 2: Two Interpretations of a Family of in Figure 1. Languages. In order for models to be integrated and transformed across these dimensions, the languages However, this only describes the potential structhemselves must be integrated. This is the moti2 The term ‘language product line’ is chosen to reflect that vation for the notion of a ‘family of languages’, a it is the language equivalent of a software product line. term which is clarified in the following section. 2

ture and not the purpose of a family of languages. The latter is captured in [9]:

used to construct them (see section 3), but they do share considerable commonality, particularly with respect to architecture. Architecture is a crucial issue with any language metamodel (or indeed any system), but much more so when it is integrated with other languages. In fact there are two distinct areas where architecture plays a major role for a member of a family of language metamodels:

A family of languages consists of a set of viewpoint languages that work together to specify a system. The models of a family of languages can be integrated so that the model elements they have in common are connected, providing consistency among the models and facilitating model transformations.

• intra-model architecture, which concerns the organisation of components within the language metamodel;

In order for languages to work together in such a way, they need to share some semantic commonality. Whilst language product lines certainly fulfil that criteria, it is just one implementation of a family of languages. Another implementation is depicted in Figure 2(b). Here languages are captured in independent metamodels, and are integrated by mappings which provide the semantic integration. This results in a looser integration between the family members, but still fulfills the requirements. Under this interpretation (referred to in this paper as a ‘language integration framework’), the whole of the MDA framework can be seen as family of languages.

• inter-model architecture, which concerns the organisation of the overall framework that integrates the language metamodels.

These concepts correspond to the two key activities in building a family of languages: metamodel construction and metamodel integration. These activities at the different levels of decomposition are described in section 4. A simple example of how a family of languages may be decomposed is shown in Figure 3. It depicts the intra-model and inter-model architecture at the language level. However, since components 2.3 Architecture in Language Fami- may be further decomposed into sub-components, they too have an intra-model and inter-model arlies chitecture. In fact it should be apparent that the This paper distinguishes two types of metamodel architecture and activity concepts described above are relative to the level of decomposition within reflecting different levels of decomposition: the language family: intra-model architecture and • language component: the basic building metamodel construction at one level is equivalent blocks of languages and language families. A to inter-model architecture and metamodel integralanguage component can be decomposed fur- tion at the next level down. ther into sub-components; Language family

• language family: a collection of integrated languages and language components.

L1

L2 C2

C3 C5

C3

There is an intermediate level of decomposition which seems to suggest a third type of metamodel, that of ‘language’. However, there is no structural L3 difference between a language and a language comC1 ponent - the difference is purely contextual, in that a component is considered to be a language if it has meaning and is useful to some community in isolation from other metamodels. Language component and language family meta- Figure 3: models are distinguished because they differ guages. slightly in terms of the approaches and mechanisms 3

C6

C2

L4 C5

L2

C3 C4

C3

language language

C5 component

C5 port connector

Decomposing a Family of Lan-

It should be noted that the decomposition in Figure 3 is only intended to be a generic framework, since it does not define or restrict the components or the connectors in any way. The architectural style (a vocabulary of components and connectors, along with a set of constraints on how they can be combined[10]) is determined by the type of language family being built (see section 2.2), and by the mechanisms being used to construct and integrate the language metamodels (see section 3). Which mechanisms are used depends upon the importance placed on certain criteria, which are discussed in the following section.

2.4

tion for model interchange, interoperability and transformations; • expressibility: this concerns the level of control a language developer has over the construction and integration of language metamodels; • scalability: the importance of scalability can be seen in the rise of component-based software development, which recognises that development and reuse at the level of classes and objects becomes increasingly unmanageable as the size of system increases[12]; • tool support: a language is constructed in order to be useful, and that depends largely upon what extra effort is required in order to tailor existing tools or construct new tools to support that language.

Considerations when Building Language Families

Section 3 describes a variety of techniques and mechanisms available to the metamodeller which are appropriate for different situations. The choice of the most appropriate technique to use at any particular stage in building a language component, language or language family depends upon the relative importance of a number of criteria, which are described in this section:

It should be noted that ease of construction, reuse, extensibility and maintainability are naturally synergistic, and are all enhanced when the principles of orthogonality and separation of concerns is upheld. Not all the criteria support each other however. In particular, there is usually a direct trade-off between expressibility and ease of • ease of construction: language metamodels construction, since a mechanism that is easy to use should not have to be developed manually in a usually shields a developer from the full range of bespoke manner each time, as this is not only expressive power that is available within the realm a waste of time, but an approach that is prone of modelling. to introducing errors[11]; In addition, integration by definition also increases coupling between components or languages, • reuse: just as with software reuse, a reuse- thus inhibiting further reuse, extensibility and driven language development process can re- maintainability. It is important therefore to inteduce development time and costs, and produce grate models only where necessary. This is a mishigher quality metamodels through the use of take that is often made in modelling. Specialisation previously tested language components[12, 13]; is often used for reasons of reuse (see sections 3.4 and 3.5), but specialisation also brings with it a • extensibility: a metamodel for a language high level of binding which is not always desirable. family should be designed to allow easy exMechanisms such as templates (section 3.6) bring tension, so that new family members can be reuse without binding, and can thus be used in sitadded; uations where strong binding is inappropriate. • maintainability: all languages change over time, so metamodels of different stages of evolution of a language need to be carefully related for maintenance and backwards compatibility;

3

Mechanisms for Building Language Families

A number of mechanisms are available in the language engineers toolbox. This section briefly explores the common mechanisms with reference to

• integration: section 2.1 highlighted the importance of language and component integra4

3.2

the considerations highlighted in the previous section.3 Section 2.3 highlighted that model construction and integration appear at multiple levels, thus some of the mechanisms below are just as applicable to building languages from components, as they are for building families from languages. It should also be noted that these mechanisms are not necessarily to be used in isolation, many can be used in combination, as described in section 4.

3.1

Meta-metamodel instantiation

One of the key restrictions with stereotyping is that new metaclasses cannot be created, since there is no direct access to the metamodelling language. An undoubtedly more powerful approach would be to instantiate the metamodelling language (i.e. MOF in the context of MDA) to model new languages or language extensions directly. Such a mechanism is often referred to as a ‘heavyweight’ or ‘first class’ extension mechanism. This expressive power comes with an inevitable negative impact on ease of use. Constructing well-architected models is a difficult skill, and metamodelling is generally recognised as being harder still, due to having to move the thought processes to a higher level of abstraction, as well as having to deal with a far wider scope than most system models[16]. However, this burden can be offset by additionally using mechanisms that allow reuse of language components, such as templates or package extension. The flexibility yet complexity of this approach is also demonstrated by the fact that it does not enforce any direct coupling with other language metamodels - such integration must be explicitly provided. If an extension to an existing language is required, this can be achieved through abstract class hierarchies or package extensions. Alternatively, explicit mappings can be provided to integrate a stand-alone language with other languages (see section 3.3). Similarly there is no inherent extensibility, maintainability, scalability or support for reuse using this vanilla metamodelling approach - these also depend upon other mechanisms used in conjunction with meta-metamodel instantiation.

Stereotypes

Stereotyping is a UML mechanism (although the principles could be applied in other languages) that allows limited extensibility to the language. It enables UML metaclasses, such as ‘Class’ or ‘Association’, to be constrained4 , thus restricting the statespace for instances of that metaclass, to meet the requirements of a specific usage scenario[15]. For example, an actor in a UML use case diagram is actually a stereotyped class with a different icon, that is constrained to represent an entity outside the system being modelled. By restricting the statespace that the metaclass represents, stereotyping can be thought of as a restricted form of subtyping, the restrictions being that the stereotyped metaclass cannot be extended with new structure, neither can entirely new metaclasses be added. To reflect this, stereotyping is sometimes referred to as a ‘lightweight’ extension mechanism, as opposed to ‘heavyweight’ or ‘first class’ extension mechanisms, which allow the definition of new and extended metaclasses (section 3.2. This restriction is weighed against the fact that stereotypes are very easy to apply, there is tight integration with the base language being extended, and by the fact that existing UML tools can be used to express models in stereotyped extensions of UML. Stereotypes are also extensible, since stereotypes can be built upon stereotypes. Whilst stereotypes are not inherently scalable, this can be resolved by packaging them into ‘profiles’. This is discussed in section 3.5.

3.3

Explicit mappings

The strength of mappings are in their ability to integrate languages. Given two languages it is possible to define a translations which will enable instances of one language to be viewed as instances of another language - this ability underlies Model Driven Architecture. Mappings between language metamodels must be defined at the same metalevel as the language metamodels themselves; thus any mapping language must be defined at the same metalevel as the metamodelling language, MOF. Thus in the MDA universe, the metamod-

3 It should be noted that in the full version of this paper we will more thoroughly review the mechanisms below and directly reference the criterion of the previous section. 4 In fact stereotypes are semantically vague in the UML definition. Whilst it is common to think of stereotypes as representing restricted metaclasses, it has been shown that they could also be interpreted as the application of templates[14].

5

to the extended class since the new language has no choice but to inherit all the original languages features. As demonstrated in [17] this approach is scalable to real languages, but the resulting metamodel is often difficult to understand since components of a language can be distributed through a class hierarchy.

elling language MOF is being extended with a mappings language known as QVT (Query, Views and Transformations)[6]. The submission process for QVT is still underway, thus it is difficult to evaluate this proposed language against most of the criteria in section 2.4; instead these criteria should dictate the design of the language. The relative ease by which mappings can be constructed is determined not just by the mapping language, but by the source and target languages. If the source and target language share many common features, then a mapping could be constructed rapidly, however if they are dissimilar then a mapping can often be complex.

3.5

Package extension and profiles

Package extension[18] is a recently introduced mechanism motivated by the work presented in [19]. It is similar to class specialisation in many respects, but because it works on packages, rather than classes, it deals with larger grain reuse. Package extension supports a layered approach to lan3.4 Abstract class hierarchies guage definition, as demonstrated in [20], which Abstract class hierarchies involves extending or can help to separate language into components that specialising an existing class to take into consider- have explicit dependencies between them (in conation a new feature of a language (effectively over- trast with the monolithic class specialisation model riding a component) or to define a new language. where multiple languages can be distributed across It is the most common mechanism used in defining a class hierarchy). This results in a scalable apand extending language metamodels, and is used proach to language engineering and reuse which is extensively in the definition of UML itself[1], as de- easier to use and maintain than one based on class picted in Figure 4. specialisation. Element

UML core Real time profile

Model Element

CORBA profile

Real time profile Real time CORBA profile

Feature

My real time profile

Generalizable Element

(a) Profile chaining Structural Feature

Behavioral Feature

(b) Profile merging

Classifier

Figure 5: Chaining and merging UML profiles. Attribute

Operation

Class

UML profiles[21, 22, 8] are packages of stereotyped classes (offering a restricted form of metamodelling) that are plugged into the UML core, providing a variant of UML customised for a particular domain. Just as a stereotype restricts the This mechanism rates highly in terms of reuse, statespace of a metamodel element, a profile resince existing classes characteristics are utilised in stricts the statespace of a metamodel. Profiles can the new language and, by virtue of being a class, be chained and merged (see Figure 5) as well as the resulting language is also extensible. However decomposed into sub-profiles, and are thus quite further reuse can be inhibited by a tight binding scalable. The arrows in Figure 5 represent a form Figure 4: Fragment of UML Metamodel. Based on [1].

6

of package extension, thus the profile mechanism can be seen as a combination of two mechanisms (stereotyping and package extension). An additional advantage, as with stereotypes, is that existing UML tools will support language extension expressed as profiles.

3.6

portant advantage of feature models is that they have a high level of expressibility and flexibility, since they are able to describe a set of languages concisely using a choice mechanism. This choice mechanism also favourably impacts on the scalability of this approach. Whilst feature modelling has been used extensively in describing product lines in software systems, it is as yet a largely untapped approach in language definition. Due to space limitations, this approach is not described in detail here, but will be explored in more detail in a future paper.

Templates

Templates (based upon the notion of ‘frameworks’ in [19]) are a mechanism by which common patterns can be abstracted into reusable packages of parameterised model elements. A substantial example of the application of templates is given in [23]. Using the template approach, a language is ‘stamped out’ by substituting names into one or more templates and merging the result. Templates are an excellent way of achieving reuse, but in contrast to the abstract class hierarchy or package extension approach, there is no binding between the stamped out language and the templates. In this way, templates effectively separate out the means by which language components are reused and the means by which languages are integrated. The flexibility of templates is very much determined by the template library available, but potentially they can be as flexible as metamodelling alone since anything that can be metamodelled can also be captured in a template. Two potential drawbacks however are maintainability, since any changes to a template will not be automatically propagated to any languages stamped out using it, and scalability, due to the often rigid structure of templates which limits their applicability.

3.7

4

Guidelines for Building Language Families

This section presents some overall guidelines for the construction and integration of language families, based upon the evaluation of the mechanisms explored in section 3. One of the most fundamental decisions that has to be made when constructing a metamodel for a language is whether it is to be defined as an independent metamodel, or whether it will be built as an extension to an existing language (see section 2.2 and [21]). This is equivalent to choosing whether to adopt a language product line or a language integration framework approach. When a language shares a common set of abstractions with an existing language, it certainly makes sense to extend that language (such as the extension of UML through profiles), but this should not be attempted where there is little overlap or conflicts with the proposed base language5 . If a language is to be constructed as a standalone language, and that language is to be integrated within the MDA language family, that integration mapping must be explicitly defined. If on the other hand a language is to be constructed as an extension, then it must be decided whether to use lightweight mechanisms (i.e. stereotypes and profiles) or heavyweight mechanisms (i.e. abstract class hierarchies and package extension). Lightweight mechanisms are easier to use and have

Feature models

Feature models and feature diagrams, which were introduced by the Feature-Oriented Domain Analysis (FODA) method[24], capture common and variant features of systems. This mechanism is primarily concerned with the relationship between features rather than defining the features themselves. They are often used as the basis for constructing software product lines, and could thus be very appropriate for representing the language product lines described in section 2.2 and Figure 2(a). Feature models are relatively easy to construct, and if an existing model exists as a basis for a language, then good reuse can potentially be made. An im-

5 Of the first four OMG UML profile RFP’s, only one (CORBA) was built using the UML extension mechanisms. The rest found it necessary to develop their own metamodels, which were then shoe-horned into the UML metamodel in a variety of ways[25].

7

automatic tool support, so should be used where possible, but again, if the new language constructs can not easily be expressed using by constraining constructs of the base language, heavyweight mechanisms must be used. There are some general guidelines that should be applied whichever of the above approaches are used:

have presented some overall guidelines, which highlight the importance of clarifying the requirements of a language before deciding upon the mechanisms used to construct and integrate language metamodels within the MDA family. The authors are grateful to BAE SYSTEMS and TCS who have generously funded the research described here.

• reuse and integration should be treated as separate considerations. Where both are required, abstract class hierarchies and package specialisation can be used, but where integration is undesirable, templates is a preferred reuse mechanism;

References [1] Unified Modeling Language 1.4 language specification. OMG document formal/2001-09-67. On OMG website[2], 2001. [2] The Object Management Group website. http://www.omg.org/.

• many of the mechanisms in section 3 can be used in conjunction with each other, so each should be assessed for appropriateness on a case by base basis;

[3] The OMG Model Driven Architecture website. http://www.omg.org/mda/.

• the easiest appropriate approach should always be used (i.e. use stereotypes where possible rather than full metamodelling).

[4] David S. Frankel. Model Driven Architecture: Applying MDA to Enterprise Computing. Wiley, 2003.

Overall, it can be seen that it is important for any language designer to be clear what the requirements are for a language, language extension or language component, such that an informed decision can be made about which mechanisms are most appropriate for its construction and integration within the MDA family.

[5] Meta Object Facility 1.3 specification. OMG document formal/00-04-03. On OMG website[2], 2000.

5

[6] Request for proposal: MOF 2.0 Query / Views / Transformations RFP. OMG document ad/2002-04-10. On OMG website[2], 2002. [7] Desmond D’Souza. Model Driven Architecture and integration: Opportunities and challenges. On MDA website[3], 2001.

Conclusion

MDA is an ambitious vision and if it is to be suc[8] Steve Cook, Anneke Kleppe, Richard Mitchell, cessful, careful thought needs to be given to what Bernhard Rumpe, Jos Warmer, and Alan it is meant by the term ‘families of languages’ and Wills. Defining UML family members using how that interpretation impacts the architectures prefaces. In Christine Mingins, editor, Proand mechanisms by which they are built. In this ceedings of TOOLS Pacific 1999. IEEE Compaper, we have explored the different interpretaputer Society, 1999. tions of a language family and the role of architecture within language families. We have introduced [9] The Semantic Core group. Requirements for a set of criteria by which some key mechanisms for the Semantic Core. Available on Semantic building families of languages have been assessed. Core website: http://www.semanticcore. We argue that none of the common metamodelling org/. mechanisms can successfully model the complexity and variability inherent in an entire language fam- [10] Mary Shaw and David Garlan. Software Arily, and thus feature modelling would be a valuable chitecture: Perspectives on an Emerging Disaddition to the metamodellers arsenal. Finally we cipline. Prentice-Hall, 1996. 8

[11] Stephen J. Mellor. Make models be assets. Communications of the ACM, 45(11), 2002.

RFP. version 0.2. OMG document ad/200212-23. On OMG website citeomg and 2U Consortium website[27], 2003.

[12] Jan Bosch. Design and Use of Software Architectures: Adopting and Evolving a Product- [21] Philipp Desfray. UML profiles versus metamodel extensions: an ongoing debate. AvailLine Approach. ACM Press/Addison-Wesley able on UML Open Edition website: http: Publishing Co., 2000. //www.umlopenedition.com/, 2000. [13] Krzysztof Czarnecki and Ulrich W. Eisenecker. Generative Programming: Methods, Tools, [22] Requirements for UML profiles. OMG document ad/99-12-32. On OMG website[2], 1999. and Applications. Addison-Wesley Publishing Co., 2000. [23] 2U Consortium. Unambiguous UML (2U) 3rd revised submission to UML 2 infrastructure [14] Desmond D’Souza, Aamond Sane, and Alan RFP. version 1.0. OMG document ad/2003Birchenough. First-class extensibility for UML 01-08. On OMG website citeomg and 2U Con- packaging of profiles, stereotypes, patterns. sortium website[27], 2003. In Robert B. France and Bernhard Rumpe, editors, Proceedings of UML ’99 - The Unified [24] Kyo C. Kang, Sholom G. Cohen, James A. Modeling Language. Beyond the Standard: 2nd Hess, William E. Novak, and A. Spencer International Conference, Fort Collins, USA, Peterson. Feature-Oriented Domain Analyvolume 1723 of LNCS. Springer, 1999. sis (FODA) feasibility study. Software Engineering Institute, Carnegie Mellon Univer[15] James Rumbaugh, Ivar Jacobson, and Grady sity, Pittsburgh, USA[28]. Technical Report Booch. The Unified Modeling Language ReferCMU/SEI-90-TR-021, 1990. ence Manual. Addison-Wesley, 1999. [25] Keith Duddy. UML2 must enable a family [16] Francois-Xavier Lebas. Defining a metamodel of languages. Communications of the ACM, for configuration and deployment of software 45(11), 2002. radio. Available on OMG Software Radio DSIG website: http://swradio.omg.org/, [26] The Semantic Core website. http://www. 2001. semanticcore.org/. [17] UML4MDA. UML4MDA response to the [27] The 2U Consortium website. http:// UML 2 infrastructure RFP. OMG document 2uworks.org/. ad/2003-01-10. On OMG website[2] and Se[28] The Carnegie Mellon Software Engineering Inmantic Core website[26], 2003. stitute. http://www.sei.cmu.edu/. [18] Tony Clark, Andy Evans, and Stuart Kent. A metamodel for package extension with renaming. In Jean-Marc J´ez´equel, Heinrich Hussmann, and Stephen Cook, editors, 5th International conference on the Unified Modelling Language (UML 2002), volume 2460. Lecture notes in computer science, 2002. [19] Desmond F. D’Souza and Alan Cameron Wills. Objects, Components, and Frameworks with UML: the Catalysis Approach. AddisonWesley, 1999. [20] 2U Consortium. Unambiguous UML (2U) 3rd revised submission to UML 2 superstructure 9