[advanced information and knowledge processing] meta-programming and model-driven meta-program...

Chapter 8A Model-Driven View to Meta-ProgramDevelopment Process

8.1 Introduction

The development of modern complex software systems or their parts is impossiblewithout representation of domain concepts at multiple levels of abstraction, wide-range reuse and automatic program generation. Note that this vision for the meta-program development is supported by the framework introduced in Chap. 7.

Currently, two software development methodologies have been widely re-searched and used for this purpose. The first is model-driven engineering (MDE)[Sch06], and the second is product line engineering (PLE) [Bos00]. The PLEmethodology focuses on maximizing reuse in software product lines (i.e. familiesof programs that share common assets) and mainly operates with features (i.e.externally visible characteristics of programs that can be recombined in differentways to achieve different versions of program functionality). First, architectureof the product family is created based on product commonalities and plannedvariabilities. Then, different product variants are derived from this architectureby reusing components and structures as much as possible and using a variety ofcomponent-based and generative reuse techniques [BBCC01].

The MDE methodology, on the other hand, advocates for the use of domainmodels (i.e. abstractions of domain concepts), which are independent upon char-acteristics of technological platforms, as the key artefacts in all phases of thesoftware development process. Such models can be introduced at multiple levelsof abstraction, that is, also above other models, thus leading to the multilevelmodelling hierarchies. Models are created using concepts defined in a meta-modelthat represents domain concepts, relationships and semantics. Domain models arethen transformed into platform-specific models using transformation rules, whichare defined by meta-model concepts: a rule (rules) transforms (transform) sourcemodel elements, which conform to a source meta-model, into target model elements,which conform to a target meta-model [OMG03].

In Chap. 8, we apply the concepts of both methodologies to the developmentof meta-programs. The aim is to describe the already introduced framework at

V. Stuikys and R. Damasevicius, Meta-Programming and Model-Driven Meta-ProgramDevelopment, Advanced Information and Knowledge Processing,DOI 10.1007/978-1-4471-4126-6 8, © Springer-Verlag London 2013

127

128 8 A Model-Driven View to Meta-Program Development Process

level 2 (see Sect. 7.5 and Fig. 7.1, Chap. 7). Level 2 outlines more preciselythe basic technical aspects of the meta-program development process and therelationships among these aspects in order to create a theoretical background forthe automation of the process. At the core of the technical aspects are modelsand abstractions, which belong either to the problem domain or to the solutiondomain. The relationships between meta-models and models are described throughtransformations.

More precisely, we introduce the model-driven view that is widely discussedtoday in many different contexts (e.g. software product line design [Bat06, TBD07],hardware design [MV06] and business processes design [Hru98]) and apply it to thedevelopment of meta-programs. Our approach considers (1) a hierarchy of relatedmeta-models and models that are represented at different levels of abstraction forboth domains and (2) various kinds of transformations of the introduced meta-models and models aiming to lowering the abstraction level of their representationuntil the executable specification is achieved.

To our knowledge, the proposed model-driven framework, when the problemdomain is presented by Feature Diagrams (FD) at three levels (i.e. meta-model,model and model instance), in the context of heterogeneous meta-program devel-opment, is discussed for the first time, though many other authors considerablycontributed to the development and extension of the FD notation and heterogeneousmeta-programming itself in recent years (see related works in Sect. 8.2). We hopethat our framework creates well-grounded preconditions for semi-automatic designof meta-programs.

8.2 Related Works

The overview we present below consists of two parts. First, we analyse the model-driven development (MDD) and transformations (OMG view [OMG03]), and then,we focus on the feature-based models and their transformations.

MDD is based on the principle of separating the description of abstract propertiesand logic of an application from a description of its platform-specific implementa-tion and the automation of the transformation of the former into the latter usingmodel transformation tools (MTTs). At present, the most mature formulation of thisvision is the OMG’s model-driven architecture (MDA) [KWB03], which refers to ahigh-level description of an application as a platform-independent model (PIM) anda more concrete implementation-oriented description as a platform-specific model(PSM).

An important aspect of the MDD approach is the model transformation: atransformation of one or more source models to one or more target models, basedon the meta-models of each of these models. Such transformations are definedby transformation/mapping rules and can be summarized as taxonomy [MCG06]that can help developers in deciding which model transformation approach isbest suited to deal with a particular problem. The models themselves can be

8.3 Framework for Model-Driven Analysis of Meta-Program Development 129

represented differently (using formal, textual, graphical notations), but the mostsuitable formalism is based on graph transformation rules. Grunske et al. provide anoverview about the needed concepts to apply graph transformations in the context ofmodel-driven engineering and show the technical feasibility based on several toolsand applications [GGZC06].

In feature modelling, especially for PLE, formal models of product featuresand different interactions between them are important for further implementationof meta-programs or software generators implementing product lines. Janota andKiniry present a formalized feature modelling meta-model to support reasoningabout feature models, feature trees and their configurations [JK07]. Westfechteland Conradi present a formal description of multi-variant models, describe trans-formation processes on such models including change and product configurationand discuss the construction and representation of models incorporating multiplevariants [WC09]. Ebraert et al. describe a formal model of change-oriented pro-gramming based on FDs, in which features are seen as sets of changes (or high-leveltransformations) that can be applied to a source program [ECHC09].

We can summarize that feature modelling is very well adapted towards thedescription of domain variability, but it lacks structural organization and expressive-ness that is needed for developing complex software systems and that shortcomingmay be provided by using the MDE approach. On the other hand, the MDDnotations such as UML lack capabilities for modelling variability and softwarefamilies (product lines). Efforts to overcome this gap include extension of the UMLmeta-model to include features for variability modelling [ZJ06] or using both UMLand feature models for modelling a domain [PKGC08].

8.3 Framework for Model-Driven Analysis of Meta-ProgramDevelopment

8.3.1 Basic Assumptions and Terminology

First, we need to introduce some assumptions together with the relevant terminologythat enable to receive some validity of the assumptions and better understandabilityof the topic. The assumptions are as follows:

1. The framework focuses on the meta-program design phase only using the model-based approach.

2. We use feature-based models to describe and represent a domain model andproblem domain tasks. The reason is that feature models are suitable to express,analyse and configure variability and commonality [CHW98] of domain tasks tobe implemented using meta-programming.

3. Feature Diagrams (FDs) as a domain model enable to express structural,functional and behavioural variability in the unified way using feature types and


FD MM

FD MM I

E FD MM I

MPG MM

MPG MM I

E MPG MM I

Abstractionlevel

lowering

Encoded specification (meta-program)

raising raising

Problem domainabstractions (feature-based)

Solution domainabstractions (meta-programming-based)

Legend:FD MM – Feature diagram meta-modelFD MM I – Instance (model) of FDMME FD MM I – Elements (patterns) of FD MM IMPG MM – Meta-program meta-modelMPG MM I – Instance (model) of MPG MME MPG MM I – Elements of MPG MM I

Fig. 8.1 Representation of the framework using Y-chart

relationships. An FD, when linked to concrete problem domain tasks aimingto build generators, is seen as a high-level model to specify and create meta-programs. Note that FDs still are an open notation with many proposals andextensions introduced in recent years (for more details see, e.g. [SHT06]).Here, we adopt the FD notation, which we call the canonical form. It has beendevised as an extension of the generic Feature Diagram [SHT06] with explicitlyrepresented context [SD09].

4. As it is not reasonable to build meta-programming-based generators for anydomain that is described by an FD, some restrictions should be introduced tothat model. Restrictions relate to the notation itself and domain scope, that is,complexity of feature diagrams [SD09] and extent of variability that is expressedthrough variation points and variants.

5. The model-based approach to deal with meta-programming directly relatesto program and model transformations. Thus, we need to introduce relevantterminology. We use meta-modelling concepts and techniques inherited fromthe OMG approach [OMG03] to describe the framework for both problem andsolution domain abstractions (see also Fig. 8.1) as follows: meta-model, programtransformation, model transformation, model mapping, vertical transformation,horizontal transformation and model merging.


6. We accept the vision proposed in [MCG06] that the term ‘model transformation’encompasses the term ‘program transformation’ since a model can range fromthe abstract analysis models, over more concrete design models, to very concretemodels of the source code. Transformation is a general term that can be usedeither ‘at design time’ or ‘at run time’ when the transformation context is not es-sential and is omitted (it is assumed that transformation is the automatic process);as in reality ‘at design time’ transformations are not yet always automatic, we usethe term ‘mapping’. By merging, we mean a process in which source models arecombined together to produce the output model. Horizontal transformation (ormapping) defines transformations at the ‘same’ abstraction level (no matter highor low), while vertical transformation (or mapping) defines transformations atthe ‘different’ abstraction levels (usually adjacent from higher to lower in termsof forward engineering, but not in reverse engineering). Instantiation is a verticaltransformation process when a model instance is created from its meta-model.

8.3.2 Description of the Framework

The framework is represented using the Y-chart (see Fig. 8.1). The Y-chart [GK83]is a tripartite representation of a design process from different points of view. Here,we consider a problem domain, a solution domain and the result of design, thatis, executable system specification. Every branch has crossings which denote thespecific level of abstraction. Traversing across the branch means that the designerrefines or abstracts the design (vertical transformations), while moving to anotherbranch means that the designer changes the representation form of the design(horizontal transformation).

In Fig. 8.1, we outline the Y-chart in which the abstraction levels and a hierarchyof models for each domain are specified. Such a structure will serve as a tool topresent the mapping framework later. Schematically, the left branch of the structurerepresents the abstraction levels and models of the problem domain. The rightbranch represents the solution domain, the abstraction levels and models of thesolution domain. The vertical branch of the Y-chart represents the product (i.e. meta-specification or meta-program) to be created when the framework is implemented.At the highest level, there are meta-models for each (left and right) branch of thestructure. At the next (i.e. intermediate) level, there are model instances, and belowthem – elements of model instances. In the next section, we describe this abstractionand the model hierarchy in detail.

As we can see from Fig. 8.1, the design phase is extremely rich with models ofvarious kinds. The models differ in their abstraction level, that is, by the extent ofdetail in which the model is presented. A model is described at a high abstractionlevel if many unnecessary details are omitted in the description. As a result, it isvery concise, but not very accurate. It is convenient to express abstractions throughlevels. In our framework, we introduce three levels of abstraction: high, intermediateand low. Their meaning may be interpreted as follows: the high level is relevant


to meta-models that describe lower-level models; the intermediate level relates tothose models that might be used to transform (manually) the models into a low-level executable specification and the low-level abstractions describe the elementsof models, which allow implementation of the low-level executable specificationper se. Designing a meta-program means lowering the abstraction level through theuse of two kinds of processes: instantiation of (meta-) models and transformationsand merging of the instantiated model instances. Further, we describe the processesmore precisely.

A meta-designer manages that model transformation via the development pro-cess. Abstractly, the development of a software system is a process of mapping ofthe given problem domain onto the solution domain. In this context, by the problemdomain, we mean the abstractions that are used to express and represent the domain,that is, application tasks. We have already identified the relevance of the feature-based abstractions to specify the problem domain tasks in order to implementmeta-programs. Therefore, further, we use the FD notation for the description offeature-based abstractions. By the solution domain, we mean meta-programmingper se. As both domains are described at the high abstraction level by adequatemeta-models and models, we can speak about model mappings. To describe themapping, first, we need to specify abstractly both domains separately using high-level modelling abstractions as it is analysed below.

8.3.3 Meta-Model to Specify Problem Domain Abstractions

We express the problem domain abstractions through feature-based notation repre-sented using Feature Diagrams (FDs). Therefore, the task is to build a meta-modelfor the abstraction of FDs. In general, a meta-model is the description that specifiesall possible model representations of a given class. More shortly, a meta-model isabout other models of the same class. In the case of FDs, the task is to obtain the for-malism that describes all possible representations of FDs. The feature-based notionis described using the only two kinds of main abstractions (<feature>, <featurerelationships>) and a set of derivative abstractions. Derivative abstractions of themain two are <feature type>, <feature class>, <variation points>, <variants>,<relationships types>, etc. The meta-model (see Figs. 8.1 and 8.2) specifies theabstractions and enumerates the relationships among these abstractions. Followingthe object-based view of OMG to meta-modelling, we use two kinds of relationships(i.e. is-a and has-a) to represent our meta-model.

Therefore, the FD meta-model describes all types of abstraction as objects thatare represented with boxes and links among boxes as relationships either of typeis-a or has-a. Note that FD meta-models also have been defined by other authors,see [CHE05a, LC09, ML03, MPLC09].

One problem should be taken into account in the context of the FD meta-modeldevelopment: the open status of the abstraction per se. The FD notation is yetnot standardized, and the notation is still evolving (see [SHT06], for details). As


Root feature

Relationship (R)Feature Constraintshas-a has-a

Feature type Feature class

has-ahas-a

Relationship typeVariant -Variant

[1,*]is-a

[1,*]

Mandatory

Optional

Alternative Variant point Parent - child

[1,*]

has-a

has-a [1,*]

Solitary feature

[0,*]

Variant [1,*]is-a

has-a

[0,*]

Node is-a

Parent Child

is-a is-ahas-a

Leaf

is-a

is-a is-a is-a is-a is-a

has-a has-a

has-a has-a

has-a is-a

[1,*]

[1,*] [0,*]

[1,*]

[1,*]

Grouped feature

is-a

is-a

and-R

[1,*]

or-R

xor-R

is-a

is-a

is-a

has-a

REQUIRE XOR

is-a is-a

[1,1]

has-a

[1,1]

has-a [0,*]

Fig. 8.2 Meta-model of feature diagram to represent a domain

a result, various proposals and extensions have been proposed in recent years.Due to the open status of the notation, some inconsistence of the syntax hasalso been identified [HSTC07]. The meta-model, however, should be built on thebasis of the generally accepted notation. Furthermore, there are two visions toan FD: the notation is treated either as a tree (i.e. constraints among leaves (ifany) are considered separately from other relationships) or the notation is treatedas a directed graph if constraints are combined together with the parent-childrelationships. The presented meta-model (see Fig. 8.3) is based on the genericsemantics concept of FDs proposed in [HSTC07] and the tree-based view. Weconsider some extensions of the generic model further together with changes relatedto the meta-model.

The other important abstraction related to meta-modelling is the instantiation ofthe meta-models. In terms of OMG [OMG03], instantiation is the process of creatinglower-level models from the higher-level ones, that is, from the meta-models oreven from the meta-meta-models. Before instantiating, one needs to answer thefollowing question: is the created meta-model correct? To our knowledge, there areno formal methods to proving the correctness of such a kind of models; thus, werestrict ourselves only by formulating basic assumptions that give some confidenceof correctness.

The assumptions are as follows:

1. Analysis of meta-model entities and identification whether all entities have beenincluded in the meta-model


Homogeneous logic equation

Repesentation Functional aspects

Equation (FOL)

Others Function type

Left side

Variables

Input<VP1>

AND OR XOR NOTRight side

=

Output

Number IName OName

<VP2>

R1

1 2 … 16

[2..*]

x u y z

Legend:

Mandatory feature Obligatory featureOptional featureSolitary feature Grouped featuresVariant point VPVariant ViRelationship (variant-variant) RiConstraint Cj

Explanation:R1 - Relationship “variant-variant”:"AND” requires any <number> from the group Note 1. The only one relationship “variant-variant” is shownAn example: a derivative instance of equation is y = x1 AND x2 AND x3C1 - Constraint of type REQUIRE : “NOT” requires only 1 inputNote 2. Function type is the variant point<VP1> with 3 variants and Input number is the variant point <VP2>with 16 variants:one is asolitary feature variant, the rest are grouped

[1..*]

C1

Fig. 8.3 FD (in FOL) as a domain model instantiated from its meta-model

2. Checking of the relationships and identification of the following situations:

(a) Are there omitted relationships?(b) Is there no redundancy within relationships?(c) Is the given relationship of a correct type?

3. Checking of the correctness of relationship cardinalities4. Checking of the correctness of the constraints

8.3.4 Instances of FD Meta-Model

The model instantiation in the model-driven approach is a vertical process oflowering the abstraction level, when we start from the higher-level model and createits lower-level representation until the level suitable for implementation is reached.For example, the result of the instantiation of the problem domain meta-model inour context is the creation of a concrete FD for the given application. Therefore, toperform the instantiation, first, we need to introduce the problem (or application)domain. Two aspects are important to focus in that case.

If we assume that the problem domain is a priori known for both the analystand the meta-designer, the first aspect is the identification of the scope for thatdomain. More precisely, the identification of scope means dealing with two tasks:


(a) specifying the domain boundaries (i.e. what is within and what is outside of thedomain) and (b) specifying requirements, including requirements for change. Thesetasks are to be solved by the domain analyst, perhaps, with the possible partialinvolvement of the meta-designer. The result of the scope identification shouldbe expressed through features. As it is not an easy task, one can consider initiallythe ‘reduced scope’, that is, a sub-domain of the selected domain, and later extendthe domain model based on the evolving FD we propose in [DST08, SD09].

The second aspect is to draw an FD that conforms to its meta-model (Fig. 8.2).Checking correctness of the FD instantiation from its meta-model includes thefollowing: (a) checking whether or not the FD is depicted according to thepre-specified syntax (a full syntax of FDs as a graphical notation is given in[SHT06]) and (b) checking semantics of the FD, that is, validation of representingrequirements for change and constraints.

As requirements for change express domain variability and evolution, somedifficulties may arise when performing the checking procedure. As a result, a meta-designer needs to build and consider a few variants of FDs. These variants can betreated as an evolutionary model describing a family of instances of the relatedFDs. We illustrate the instantiation process and present an FD as an instantiatedmodel instance. Consider, for example, the entire domain of homogeneous logicequations (in terms of the prescribed requirements) for the efficient derivation (whenimplemented) of any instance of the equation. The domain is represented by itsmodel given as an FD in Fig. 8.3 (for details, read the explanation and legend withinFig. 8.3; FOL, feature-oriented language). It describes all properties depicted in themeta-model (see Fig. 8.2).

The instantiation process is the derivation of the FD instances from the FD meta-model. To facilitate implementation of the process, a domain analyser, first, shouldunderstand the domain under consideration well, and next, he/she needs to applywell-formed principles for representing the domain model, when it is derived fromits meta-model.

8.3.4.1 Meta-Model of Meta-Program

A meta-model of the solution domain (i.e. meta-programming) is indicated at thehighest level in the right branch of the Y-chart (see Fig. 8.1). Here, by the meta-model, we mean a description that specifies all theoretically possible variants ofmeta-programs, which are indicated by the meta-model. To specify the meta-model,we use the same notation (extended by the relationship <describes>), which wasused in Sect. 8.3.1. The specification of that meta-model contains two types ofentities, that is, <meta-interface model> and <meta-body model>, and entities thatare used to construct these two models (see Fig. 8.4).

For example, the <meta-interface model> is constructed of meta-parameters thatare described using meta-constructs derived from a meta-language. The <meta-body> is constructed of two parts: modification/change model and program in-stance model. The latter is derived from a domain language. The structure of the


Language

Algorithm

Meta data

Meta-language

Data

has-a

Domain algorithm

Domainlanguage

is-a

Meta-program meta-model

Meta-program model

Modification algorithm

has-a

has-a

Domain program

Set of Meta-parameters

is-a

is-a

is-aMeta-interface

model

is-a

is-a

has-a

has-a

has-a

has-a has-a [1,*]

[2,*]

[1,*]

Meta-body model

[1,*]

1

[1,1]

[1,*]

1

[1,*]

has-a

is-a

desc

ribes

Fig. 8.4 Specification of meta-program meta-model

meta-model should be interpreted as follows: All entities in the description (seeFig. 8.4) are abstractions of the solution domain, that is, meta-programming per se.By adding the word model to any entity, we intend to specify any entity of that kind,but not its concrete instance. For example, the modification/change model describesall possible changes within the meta-model. A set of domain languages means that aconcrete domain language is not specified at this level, yet. The same relates to meta-languages. We consider the instantiation of the meta-model in the next subsection.

8.3.4.2 Instance of the Meta-Program Meta-Model

The model instance is created through the instantiation process using the meta-model that is one level higher than the instance model itself. The instance ofthe meta-program meta-model is given in Fig. 8.5. This description differs fromthe previous one (see Fig. 8.4) in the following: (a) a concrete domain languageis derived from the set of domain languages that is described by the meta-model, (b) a concrete meta-language is derived from the set of meta-languages,(c) modification/change model is substituted by the concrete algorithm to implementchanges pre-specified by the given requirements and (d) program instance, meta-parameters and meta-interface are also concretized in the same way.

In order to create an instance of a modification algorithm, however, we need toknow requirements for change. Though the requirements are formulated by the useror/and domain analyst at the level that is higher than the meta-program model, wehave included requirements for change in the description of the model for clearness.

8.4 Interpretation of Transformations 137

Meta-program

Meta-interface Meta-body

Meta-parameter Instance of Modification(change) algorithm

Program instance

Instance ofmeta-language Meta-construct

Instance ofdomain language

has-a has-a

has-a has-a

has-a

has-a

has-ahas-a

1 1

[1,*]

has-a

Interface

Functionality

is-a

is-a

[1,*]

[1,*]

[1,*]

[1,*]

[1,*]

Requirements(for change)

Describes

has-a

[1,*]

Data

has-a

is-a [1,*]

[1,*]

Fig. 8.5 Instance of meta-program model derived from its meta-model

8.3.5 Elements of the Instance of Meta-Program Meta-Model

The elements of a meta-program are derived from the meta-program model throughthe instantiation process in the same way as the meta-program model is derivedfrom its meta-model. As we can see in Fig. 8.5, there are two basic elements:meta-interface and meta-body. For simplicity, we assume that a meta-programcontains only one meta-interface and meta-body. Each element has its internalstructure. When the structure is of interest in a predefined context, one can identifythe constituent parts of the element. For example, meta-interface contains a setof meta-parameters. Meta-body consists of a set of domain program instancesthat are represented using the domain language. A program instance has its owninterface and functionality. The program instance has specific locations specifiedwhere change can be applied. What level of granularity is to be achieved in theelements elicitation is the matter related to the transformation rules that shoulddescribe how input elements are transformed or merged into target elements.

8.4 Interpretation of Transformations

So far, we have considered transformations of the problem domain abstractions andsolution domain abstractions separately. Those transformations have been calledmodel instantiations. Model instantiation is a vertical transformation aiming to de-rive a lower-level model from its meta-model. Here, we describe all transformationsvery abstractly without details. Figure 8.6 outlines the view to all transformationsas they should be conceived using the framework.


FD MM

FD MM I

E FD MM I

MPG MM

MPG MM I

E MPG MM I

Vertical transformation

Encoded specification (meta-program)

Problem domainabstractions (feature-based)

Solution domainabstractions (meta-programming based)

Legend:

Vertical transformation

Horizontal transformations

Model merging

Abstract goal of transformation

Achievable goal of transformation

Concrete goal of transformation

Fig. 8.6 Abstract interpretation of transformations in meta-program development framework

At the beginning, the abstract goal for transformations at the highest level, thatis, at the meta-model level is specified. As the abstract goal is not achievable,one needs to make the lowering of abstraction level by one step (level) movingin the vertical direction in each branch of the Y-chart. The result of such a verticaltransformation is the creation of meta-model instances for both domains. Havingthe models instances, we can narrow the abstract goal transforming it into theachievable goal (in Fig. 8.6, it is denoted by the single line). Though the goal maybe achievable, the practical mechanism of its implementation is yet not devised.

Therefore, we need to make yet another step of horizontal transformation fortransforming models into constituent elements in each branch. Again, the achievablegoal is transformed through a vertical transformation into the concrete goal that canbe already implemented by transformation rules for each kind of model elements.Note that the definition of transformation rules is not the intention of the framework.

Though the proposed framework does not include the definition of detailedtransformation rules in order to produce the encoded specification (meta-program),for the sake of better understanding of the framework, we present a result of sucha transformation. The example (Fig. 8.7) outlines the implementation of the FDdepicted in Fig. 8.3, using Open PROMOL as a meta-language (see Chap. 6) andlogical equations in plain text as a domain language. Note that names of externalmeta-parameters are given in italic and Open PROMOL functions are given in bold(see Fig. 8.7).

8.5 Requirements for Tools to Support (Semi-) Automatic Development . . . 139

Fig. 8.7 Encoding of FD given in Fig. 8.3 using Open PROMOL (a); (b) one of derivativeinstances

8.5 Requirements for Tools to Support (Semi-) AutomaticDevelopment of Meta-Programs

In terms of the OMG approach, a transformation is the process that is performedautomatically by adequate tools. In general, however, this maturity level of designtechnologies is still not achieved, but we can assume that the creation of meta-programs automatically for some specific cases with some prescribed assumptionsmight be considered as a real scientific task already now. We analyse those cases andassumptions and formulate requirements for tools to support automation of meta-program development as follows:

1. Well-defined syntax and semantic of FDs2. Tools for automatic or semi-automatic drawing of FDs3. Automatic validation of correctness of feature models4. Automatic decomposition of a feature model into sub-models with respect to

prescribed requirements5. Well-defined formalism to specify requirements for change6. Well-defined transformation rules to support transformation of the feature model

specification into the meta-program specification7. Support for meta-language processors (depending on the application domains)8. Support for different domain language compilers, domain program analysers and

parsers (depending on the application domains)


8.6 Summary and Evaluation

We have proposed a general framework for the model-driven analysis of processesrelated with meta-program design. Abstractly, the meta-program design frameworkcan be represented as the Y-chart. Branches of the chart represent three importantitems: problem domain (left branch), solution domain (right branch) and theresult of their linking, that is, the developed meta-program (vertical branch). Wehave represented both domains at three abstraction levels: meta-model, modeland instance. By the problem domain, we mean abstractions used to representdomain models. By the solution domain, we mean meta-programming abstractions(languages and meta-models, models, etc.). We have selected the feature-basedabstraction (i.e. Feature Diagram) to specify and represent domain models becauseit allows expressing functional, structural and behavioural aspects in terms of featurevariability and commonality relationships explicitly and precisely; furthermore,those relationships are captured intuitively and simply.

The important aspect of the model-driven analysis of meta-programming, orhow meta-programs should be devised using a transformative approach, is thetraversing across the abstraction levels within the branches of the Y-chart. Thetraversing starts at the highest abstraction level in the right branch. The processis interpreted either as horizontal or vertical transformation. The intention of thehorizontal transformation is to achieve the abstract goal (i.e. to check a possibilityto combine domains) at the highest abstraction level. If, at this abstraction level,there is not enough information about the model elements to derive transformationrules to perform the horizontal transformation, a meta-designer needs to go througha series of vertical transformations to lower the abstraction level by introducingmore details within the model representations. Vertical transformation is the modelinstantiation process, when lower-level models or their elements are derived fromtheir meta-models. Vertical transformation in both the left and the right branch ofthe Y-chart is performed step by step that leads to lowering of the abstraction levelby one consecutive level.

At the lowest level, that is, at the model element representation level, we canalready formulate and precisely express transformation rules stating how to merge(i.e. to transform) model elements of the problem and solution domains. Though wehave not yet presented those rules explicitly (that will done later), the introducedframework gives a solid theoretical background to understand the meta-programdevelopment process for automation. We have also formulated requirements fortools to support the automation.

The introduced framework enables the following: (1) to understand the meta-program development process better using the model-driven approach and (2) toidentify some essential aspects of the model-driven transformations, such asreachability of goals within the horizontal transformation, or property to inducethe multiple representation forms of the feature diagram instance with the samesemantics for the same domain task. As a result, the framework creates precon-ditions to develop a transformation-based approach to construct meta-programssemi-automatically.

References 141

8.7 Exercise Questions

8.1. Explain what are model-driven analysis and model-driven engineering ingeneral. If you feel the lack of information presented in this chapter on thetopic, try to study original works.

8.2. Define the basic terms (meta-model, model, model instance, model transfor-mation model instantiation, vertical and horizontal transformation) and clarifytheir meaning in the context of model-driven view to meta-programming.

8.3. Explain the role of Y-chart in describing the framework to deal with model-driven approach to meta-programming. Is it possible to use Y-chart to otherdomains (e.g. to your application domains, where meta-programming isconsidered as a solution domain)?

8.4. Analyse a meta-model given in Fig. 8.2 and informally define all elements ofthat meta-model. Compare the meta-model with the one given in [JK07].

8.5. Explain how a model instance is derived from its meta-model.8.6. What is meta-model of a meta-program? Analyse the meta-model given in

Fig. 8.4 and give a rationale of its interpretation. Try to instantiate a meta-program model from its meta-model.

8.7. Draw an instance of a meta-program for your task of interest.8.8. Outline the procedure of abstract model transformations using the scheme

given in Fig. 8.6.

References

[Bat06] Batory D (2006) Multilevel models in model-driven engineering, product lines, andmetaprogramming. IBM Syst J 45(3):527–539

[BBC+01] Butler G, Batory DS, Czarnecki K, Eisenecker UW (2001) Generative techniquesfor product lines. In: Proceedings of the 23rd international conference on softwareengineering, ICSE 2001, 12–19 May 2001, Toronto, pp 760–761

[Bos00] Bosch J (2000) Design and Use of software architectures, adopting and evolving aproduct-line approach. Addison-Wesley, Reading

[CHE05a] Czarnecki K, Helsen S, Eisenecker U (2005) Staged configuration through special-ization and multi-level configuration of feature models. Softw Process Improv Pract10:143–169

[CHW98] Coplien J, Hoffman D, Weiss D (1998) Commonality and variability in softwareengineering. IEEE Softw 15:37–45

[DST08]ˇ Damasevicius R, Stuikys V, Toldinas E (2008) Domain ontology-based generativecomponent design using feature diagrams and meta-programming techniques. In:Proceedings of the 2nd European conference on software architecture (ECSA’08),September 29–October 1, Paphos, Cyprus. LNCS, vol 5292. Springer, Berlin,pp 338–341

[ECH+09] Ebraert P, Classen A, Heymans P (2009) Feature diagrams for change-orientedprogramming. In: D’Hondt T, Nakamura M, Reiff-Marganiec S (eds) Featureinteractions in software and communication systems X. Ios Press, Amsterdam,pp 107–122

[GGZ+06] Grunske L, Geiger L, Zundorf A, Van Eetvelde N, Van Gorp P, Varro D (2006) Usinggraph transformation for practical model-driven software engineering. In: Beydeda


S, Book M, Gruhn V (eds) Model-driven software development. Springer, Berlin,pp 91–118

[GK83] Gajski DD, Kuhn RH (1983) Guest Editor’s introduction: new VLSI tools. IEEEComput 16(12):11–14

[Hru98] Hruby P (1998) Mapping business processes to software design artifacts. In: De-meyer S, Bosch J (eds) Proceedings of the object-oriented technology, ECOOP’98workshop reader, Brussels, Belgium, 20–24 July 1998. LNCS, vol 1543. Springer,Berlin, pp 234–236

[HST+07] Heymans P, Schobbens P-Y, Trigaux J-C, Matulevicius R, Classen A, BontempsY (2007) Towards the comparative evaluation of feature diagram languages. In:Proceedings of the software and services variability management workshop –concepts, models and tools (SVM-WS 2007), Helsinki, April 2007, pp 1–16

[JK07] Janota M, Kiniry J (2007) Reasoning about feature models in higher-order logic. In:Proceedings of the 11th international conference on software product lines, SPLC2007, 10–14 September 2007, Kyoto, pp 13–22

[KWB03] Kleppe AG, Warmer J, Bast W (2003) MDA explained, the model-driven architec-ture: practice and promise. Addison-Wesley, Boston

[LC09] Laguna MA, Corral JM (2009) Feature diagrams and their transformations: anextensible meta-model. In: Proceedings of the 35th euromicro conference onsoftware engineering and advanced applications, SEAA 2009, Patras, Greece, 27–29August 2009, pp 97–104

[MCG06] Mens T, Czarnecki K, Van Gorp P (2006) A taxonomy of model transformations.Electron Notes Theor Comput Sci 152:125–142

[ML03] von der Massen T, Lichter H (2003) RequiLine: a requirements engineering tool forsoftware product lines. In: Proceedings of the software product-family engineering,PFE 2003, Siena, Italy. LNCS, vol 3014. Springer, Heidelberg, pp 168–180

[MPL+09] Morin B, Perrouin G, Lahire P, Barais O, Vanwormhoudt G, Jezequel J-M (2009)Weaving variability into domain metamodels. In: Schurr A, Selic B (eds) Proceed-ings of the 12th international conference on model driven engineering languages andsystems, MODELS 2009, Denver, CO, USA, 4–9 October 2009. LNCS, vol 5795.Springer, Berlin/Heidelberg, pp 690–705

[MV06] Mueller W, Vanderperren Y (2006) UML and model-driven development for SoCdesign.In: Proceedings of the 4th international conference on hardware/softwarecodesign and system synthesis (CODESCISSS’06), 22–25 October 2006

[OMG03] OMG (2003) MDA guide version 1.0.1, 2003. Version 1.0.1, OMG documentomg/03-06-01

[PKG+08] Perrouin G, Klein J, Guel N, Jezequel JM (2008) Reconciling automation andextensibility in product derivation. In: Proceedings of the 12th international softwareproduct line conference (SPLC 2008), Limerick, 2008, pp 339–348

[Sch06] Schmidt DC (2006) Model-driven engineering. IEEE Comput 39(2):25–31[SD09]ˇ Stuikys V, Damasevicius R (2009) Measuring complexity of domain models repre-

sented by feature diagrams. Inf Technol Control 38(3):179–187[SHT06] Schobbens P-Y, Heymans P, Trigaux J-Ch (2006) Feature diagrams: a survey

and a formal semantics. In: Proceedings of the 14th IEEE international require-ments engineering conference, 11–15 September 2006. IEEE CS Washington, DC,pp 136–145

[TBD07] Trujillo S, Batory DS, Dıaz O (2007) Feature-oriented model driven development:a case study for portlets. In: Proceedings of the 29th international conference onsoftware engineering (ICSE 2007), Minneapolis, 20–26 May 2007, pp 44–53

[WC09] Westfechtel B, Conradi R (2009) Multi-variant modeling concepts, issues and chal-lenges. In: European conference on model-driven architecture (ECMDA), Twente,24 June 2009, pp 57–67

[ZJ06] Ziadi T, Jezequel JM (2006) Product line engineering with the UML: derivingproducts. In: Software product lines. Springer, Berlin, pp 557–586

[advanced information and knowledge processing] meta-programming and model-driven meta-program...

Documents