4.10 Summary . . . 124
�.� ����������
The development of methods for model-driven software engi- neering uses meta-models to describe the structure of artefacts on which they work on. The according terms known from the
Need for a
meta-model algebra literature are method engineering [Bri96] and meta-modelling
as for example the OMG Software & Systems Process Engineer- ing Meta-Model (SPEM) [Obj08b]. Another example is the Meta- Object Facility (MOF) [Obj06a], which can be used to define lan- guages. In all mentioned domains the meta-modelling of struc- tural aspects (for example definition of meta-models according to the MOF-based languages) rather then behavioural (for ex- ample transformations of meta-models) aspects are focused. Ad- ditional techniques as constraints modelling (for example OCL [Obj06b]) or declarative model transformations (for example QVT [Obj08a]) could be used to specify the behaviour, but they miss the specification of the required meta-model properties as travers- ability or structural mapping.
The general idea of the meta-model algebra is to support the specification of the behaviour of operations on meta-models and the required properties of meta-models within method engineer- ing. In Figure 29, we depicted the idea by using views on the
General idea
structure, behaviour and roles in method engineering. The main artefacts are meta-models, which describe the structure of the data the method operates on. First, the behaviour of the method is described by the algebra operations (which represent the sig- nature of a method). Second, algorithms (which represent the se- mantic of a method) refine the algebra operation. Both artefacts are created by a method engineer and are based on meta-models. Finally, the algorithms are implemented into tools and executed by software engineers in a project on meta-model instances. In the case of this thesis, we use method engineering to develop a holistic model-based testing approach, which consists of several
Thesis context
meta-model operations. Each operation is based on the analysis and / or test meta-model (see Chapter2). The method engineer from Figure 29 is the thesis’ author. The implementation of al- gorithms is part of the prototype used in the evaluation chapter. The execution of our approach can be done by software engi- neers in model-driven development projects.
�.� ���������� 107 Method Engineer Model Tool Software Engineer Algebra Operation (Signature) Algorithm (Semantic) exec Meta-Model instance_of implements refines based_on
Structure Behaviour Role
1
2
3
Properties
Figure 29: General idea of the meta-modelling with the meta-model
algebra
To motivate the usage of algebras for meta-models, we provide an exemplary definition of an algebra A:
A= (M, (4.1)
select: M! M, (4.2)
transform: M! M, (4.3)
cover: M, M ! M) (4.4)
Exemplary terms specified with algebra A:
select(m) (4.5)
transform(select(m)) (4.6)
In the example provided above, we define an algebra A. This algebra is defined over the universe of all meta-models M. The algebra consists of two unary operators select (selection of test cases), transform (model transformation). This way, the signature of meta-model operators is specified (see step 1 in Figure 29). Since the mentioned operations cannot work on any type of meta-model (for example to select test cases the traversability
of meta-models is needed), the meta-models M have to fulfill certain properties. Then, terms like 4.5 (selection of logical test cases based on the analysis meta-model structure) or 4.6 (trans- formation of the test selection results) with the variable m 2 M can be constructed. But, to develop a holistic method in this the- sis, also the semantic of the operations has to be defined. This is done by defining algorithms. The specification of algebra oper- ations with meta-model properties together with algorithms is the goal of the meta-model algebra.
Since the definition of an complete algebra, which includes all possible operations on meta-models would require a separate phd thesis, we concentrate on a set of operations relevant for the
Customization
holistic model-based testing. We apply the set of operations to concrete meta-models (see analysis and test meta-models from Chapter2) in the next chapter. In the context of model-driven de- velopment, further possible operations could be identified. Since the meta-model algebra is not the main part of this thesis, we will give an outlook of possible extensions as future work.
�.� �����������
We provide the following definitions for the purpose of this the- sis:
����-����� ������� consists of one or more operations and their related properties, which are performed on single or multiple meta-models.
������� ��������� specifies an operation, which is performed on elements of one or several meta-models. Each operation has a signature, which consists of an input and an output set of meta-model elements. Both sets can consist of ele- ments of the same or different meta-models. The concrete specification of an algebra operation is done by a method engineer within an algorithm. We assume that algorithms are implemented in a tool and executed automatically. ����-����� �������� defines an abstract property, which is
fulfilled between elements of single or multiple meta-mo- dels. Properties are defined over an abstract and not con- crete meta-model (for example analysis or test meta-model).
�.� ������� ����-����� 109 An algebra operation is always based on one or several meta-model properties and can be only applied on meta- models for which the property holds.
����-����� ������� ������������� takes place together with the instantiation of the meta-models used in the meta-model algebra operations. The operations are refined as concrete algorithms and implemented (instantiated) for automated execution.
�.� ������� ����-�����
In Figure 30, the meta-model of the algebra is shown. The alge- bra consists of several operations which can be performed on meta-models. The algebra operations and the properties are the main concepts of the meta-model algebra. Each operation has one property on which it is based on. Further, each operation uses one or several meta-models to define the input and output sets. A property is described over an abstract meta-model (high- lighted in Figure30), since it defines an abstract property which can hold on any concrete meta-model.
Each algebra operation is refined by one or more algorithms. Let us consider the distinction between algebra operations and algorithms in the meta-model from Figure 30. The algebra op-
Algebra operation
vs. algorithm erations represent the high-level view (what / signature), while
the algorithms represent the concretization of each algebra oper- ation (how / semantic). We have chosen this distinction because of the fact that there can be several concrete algorithms, which can be mapped to one algebra operation. Each algorithm can use a different technique (for example sequential, parallel or recur- sive algorithms) to produce the output set based on the input set of meta-model elements. This distinction can be also compared to programming languages: the algebra operations are the signa- tures and algorithms the body of methods.
Together with the instantiation of the meta-models, the imple- mentation of the algorithms into source code takes place. The implemented code is executed on models, which are based on meta-models used as the input and output set of algebra opera- tions. More detailed description of the instantiation is provided in Section4.8.
We have chosen this meta-model structure because of the sim- plicity and usability of the algebra for the method engineer. Be- sides the operation and property elements, further ones formal- izing the semantics by detailed constraints of each operation or property would be possible. For the purpose of this thesis a lan- guage, which supports the specification of the syntax and rigour semantics of operations is relevant. The specification of more pre- cise formal semantics of operations (for example with algebraic specification [EM90]) is not part of this thesis.
�.� ������� ����
In the literature the topic of algebra is known from the math- ematics. Algebra is the branch of mathematics concerning the study of the rules of operations and relations, and the construc- tions and concepts arising from them, including terms, polyno- mials, equations and algebraic structures [BS81]. There are differ- ent types of algebras. For the purpose of this thesis, the so called elementary algebra, which consists of variables, operations and equations is relevant. In its simplest meaning in mathematics
�.� ������� ���� 111 and logic, an operation is an action or procedure, which pro- duces a new value from one or more input values. There are two common types of operations: unary and binary. The meta- model algebra operations used in this thesis are both unary (sin- gle meta-model operations) and binary (multiple meta-model operations).
In the field of computer science the domain of algebraic speci- fication is a formal process of refining specifications to system- atically develop more efficient programs. Ehrig and Mahr intro- duced in [EM90] the concept of signature algebras, which are defined over a set of sorts (data structure) and operations. Se- mantics in this context is defined by equations over the men- tioned sorts by using operations. This fundamental concept is applied within the meta-model algebra by replacing sorts with meta-model definitions and operations with algebra operations. In the context of method engineering the general concept of specifying methods for software engineering was shown by En- gels and Sauer in [ES10]. The authors provide a good overview to method engineering, meta-modelling and language engineer- ing. The goal of the approach presented in [ES10] is to provide a meta-method for systematically developing methods for soft- ware engineering. To support the method engineer the authors introduce a fundamental process of the meta-method, which con- sists of six steps. The result of this process is a software engi- neering method. The meta-method integrates the structural (for example the meta-model structure) and behavioural (for exam- ple transformations on the meta-model) meta-modelling aspects. The behavioural aspects of meta-modelling presented in [ES10] influenced the definition of the algebra operations.
Good examples of meta-modelling approaches for models of software development methods are SPEM [Obj08b] and the ISO/ IEC 24744 Software Engineering - Metamodel for Development Methodologies [ISO07]. Both examples introduce the structural aspects of meta-modelling in form of meta-models. Unfortunately, none of them supports the behavioural aspects which are rele- vant in this thesis.
�.� ����-����� ����������
Before we introduce the concept of algebra operations, we need to introduce the meta-model properties, since each algebra op- eration is based on one property. Properties of meta-models are constraints, which have to be fulfilled for one or several meta- models. For example the existence of model relations between meta-model elements is a property. Meta-models without the possibility to model relations can not be used to define algebra operations based on the mentioned property. We define the fol- lowing meta-model properties for the purpose of this thesis:
• traceability
• modelling viewpoints • model relation
• structural mapping • traversability
We have chosen the five meta-model properties because of their relevance for the development of a holistic model-based testing approach. The modelling viewpoints and model relation property
Identification of
properties is the essential property needed to use a holistic view on all
three viewpoints of the analysis model (see Chapter 1). To use analysis models for test purposes (see Section1.1), the structural mapping property is needed. The traceability property is needed to measure the holistic model coverage (see Section1.1). Finally, the traversability property is needed to perform the test selection, which is essential in model-based testing (see Subsection2.2.4). Besides the mentioned properties, further ones can be defined and used within the meta-model algebra.
In the following we briefly describe each meta-model property. �.�.� Traceability
Traceability was already defined in Subsection2.5.3as the ability to trace the connection between the artefacts of the testing life cy- cle or software life cycle [UL07]. In the context of model-driven development we redefine it as the ability to trace the connection between elements of models based on their meta-model struc- ture. For example: a test case (element of the test meta-model) is
�.� ����-����� ���������� 113 traceable to a use case (element of the analysis meta-model). The identification of the trace between the mentioned meta-model el- ements can be done at the model instance level by executing algorithms (refinements of algebra operations).
Figure 31: Meta-model property traceability
In Figure 31 we have depicted the traceability property on the meta-model level. The element MME2 (part of the meta-model M2) is traceable to the element MME1 (part of the meta-model M1). The traceability property is bidirectional, since MME2 can be traced back to MME1 and MME1 can be traced forward to MME2. The bidirectional traceability can be used in model-driven development for impact analysis and especially in model-based software testing for model coverage measurement.
�.�.� Modelling viewpoints
The essential contribution of this phd thesis is the usage of differ- ent modelling viewpoints for model-based system testing. Based on an exemplary analysis modelling approach from Salger et al. [SSE09], we identified viewpoints as structure, behaviour and interaction. This viewpoints are defined by the modelling ap- proach itself and supported by the chosen modelling language (here UML).
To define operations on meta-models, which use the holistic view the property of existing modelling viewpoints has to be ful- filled. It means that the modelling approach and the modelling language used to create the meta-model have to support the con- cept of viewpoints.
�.�.� Model relation
The relations between elements of the analysis model has a di- rect impact on the quality of the holistic model-based testing approach (see Section 1.1). Model relations are syntactical as- sociations between elements of a meta-model. For example the Association concept of the UML meta-model [Obj09, p.39] fulfills this meta-model property. The relations are defined for single elements of the meta-model, which can be part of different mod- elling viewpoints. This kind of model relations enables the usage of the holistic view in our approach.
The topic of the semantic of model relations has been covered by Jan Hausmann in [Hau05]. Within algebra operations, we con- centrate on the syntax and not semantic of model relations.
Figure 32: Meta-model property model relation
In Figure 32 the model relation relation property is visible be- tween MME1 and MME2, which both are parts of the meta- model M1. Similar to the traceability property, also model rela- tions are bidirectional.
�.�.� Structural mapping
The intended use of analysis models for test purposes is based on the idea of a structural mapping between the analysis and test model (see Section1.1). The meta-model property structural mapping is defined as the structural mapping between elements of two or more meta-models. The mapping takes place when an algorithm (refinement of an algebra operation) is executed. This
�.� ����-����� ���������� 115 property is visualized in Figure33. Information contained in the element MME1 is mapped to the element MME2. This property is not bidirectional, since we assume that MME2 was created by using the information of MME1 and not otherwise.
Figure 33: Meta-model property structural mapping
�.�.� Traversability
The last meta-model property is the traversability of behavioural parts of a meta-model. The topic of graph traversation for test selection was introduced in Subsection 2.2.4. Based on this in- troduction, we define traversability as the property of traversing meta-model elements by using its transition system. For exam- ple traversing meta-models defined in a graph-like structure (for example sequences of actions within use case scenarios from the analysis meta-model in Subsection 2.4.11) to select traces (also called paths) with sophisticated algorithms. In this case the tran- sition system allows to navigate tokens from the initial to the final action of the use case scenario. To allow only valid transi- tions the operational semantics of the transition system has to be defined.
The problem of infinite loops in such a transition system is han- dled within the algorithms as the refinement of algebra oper- ations, which are based on the traversability property. To exe- cute operations based on this property the assumption of meta- models, which can be traversed from the initial to the final node has to be fulfilled.
�.� ������� ����������
The purpose of the algebra operations is to specify operations performed on meta-models. The algebra operations specify the purpose and data structure needed to operate (signature), but not the concrete steps (semantics) for its execution. The con- cretization of an algebra operation is an algorithm specified by a method engineer. Let us consider the visualization from Fig- ure34. In a model-driven development process two meta-models MM1 and MM2 are used to support activities like business analy- sis, design, code generation, testing, etc. Both meta-models con- sist of several meta-model elements. An operation can be per-
Different operation
types formed on a single meta-model (see OP1 in Figure34) or several
meta-models (see OP2 in Figure 34). The specification of an op- eration uses meta-model elements as input and output sets. The input set for OP1 and OP2 are the elements of MM1. In the case of OP2 the elements of MM2 are the output set. The output set of operation OP1 consists of elements of MM1.
Figure 34: Meta-model algebra operation
Based on the description provided above, we define the follow- ing types of algebra operations:
������ ����-����� ��������� is an operation which input and output sets are based on the same meta-model.
�������� ����-����� ��������� is an operation which in- put and output sets are based on different meta-models. The distinction between single and multiple model operation types was chosen because of the operations identified in the
�.� ������� ���������� 117 literature. Good examples of single meta-model operations are test selection algorithms (an overview was introduced in Sub- section2.2.4), which are based on meta-models used to describe the systems behaviour. A widely known example for multiple meta-model operations are M2M transformations (an overview was introduced in Section2.5).
For the purpose of this thesis, we concentrate on single and mul- tiple meta-model operations, which use a maximum of two dif- ferent meta-models for the specification of input and/or output sets. This restriction was chosen because none of the operations defined in the model-based testing approach from Chapter 5 uses more than two different meta-models. The specification of algebra operations based on more than two meta-models is pos- sible and can be evaluated in the future work.
To define an operation of the meta-model algebra the following requirements have to be fulfilled:
REQ1 The structure of each meta-model has to be defined
REQ2 The input and output element sets based on their meta- models have to be defined for each operation
REQ3 Each operation has to be based on a meta-model property (see Section4.5)
REQ4 Meta-models used in the operation have to fulfill the meta- model property
Based on the introduction provided so far, we define the follow- ing attributes of an algebra operation:
• Name (one word name of the algebra operation)
• Goal (short description of the operations purpose)
• Type (type of the algebra operation) • Input meta-model
• Input set (list of meta-model elements based on one or sev-
eral meta-models serving as the input of the operation)