Metamodels
In our approach, we used metamodels to formalize the artifacts of MBT. This approach has some advantages: First, we can leverage on object-oriented extension mechanisms like inheritanceto refine the MBT metamodel for a specific target system. This will allows us,
3.6. Discussion 49
1 // this procedure performs service−based mapping of abstract tasks
2 // if no service instance can be found, it falls back to the default MWE behavior
3 serviceBasedTaskMapping(type∈<Class, Interface>,
4 cardinality∈ΘService-Cardinality, filter∈ΘOSGi-Filter) : Object {
5
6 // try to find a service instance for the type
7 if(type == Interface) {
8 service = findService(type, cardinality, filter)
9 if(service != null) {
10 returnservice
11 }
12 }
13
14 // fall back to the default MWE behavior (creates instance of the type)
15 returntype.newInstance()
16 }
17
18 findService(type Interface, cardinality∈ΘService-Cardinality, filter∈ΘOSGi-Filter) : Object {
19 //search all registered services instances of the given type, filtered by the given osgi filter
20 List services = osgiServiceRegistry.getAllServices(type, filter)
21
22 if(cardinality.isMandatory && services.size == 0) {
23 throw Exception(”Mandatory task mapping failed”)
24 }
25
26 if(services.size > 1 && cardinality.isUnary) {
27 // choose an arbritary item of the list
28 returnservices.any()
29 } else {
30 returnservices
31 }
32
33 // MWE cannot handle Java Interfaces itself, so we have to instantiate a NULL−Object
34 returncreateNullObjectFor(type)
35 }
Listing 3.1:Pseudo code for the service-based task mapping extension of MWE.
1 <workflow>
2 <!−−the abstract Task ”Model Reading” modeled as the Java Interface ”IModelReading”−−>
3 <component class=”examples.IModelReading”cardinality=”1..1”>
4 <uri value=”model.mbt”/>
5 <modelSlot value=”MBTModel”/>
6 </component>
7
8 <!−−
9 This abstract task is marked as optional (using the cardinality attribute).
10 The workflow execution continues if the abstract task cannot be mapped.
11 The ”filter” attribute filters potential concrete tasks.
12 −−>
13 <component class=”examples.ITestCaseSpecificationOrdering”
14 cardinality=”0..1”filter=”(strategy=random)”>
15 <modelSlot value=”MBTModel”/>
16 </component>
17
18 <!−−
19 This is a concrete task, where no mapping is needed.
20 −−>
21 <component class=”examples.TestGenerationWithModelCheckerImpl”>
22 <modelSlot value=”MBTModel”/>
23 </component>
24
25 <component class=”examples.IModelWriting”cardinality=”1..1”>
26 <uri value=”model.mbt”/>
27 <modelSlot value=”MBTModel”/>
28 </component>
29 </workflow>
Listing 3.2:Workflow description of the example in Fig. 3.2, expressed in MWE with service-based extensions.
3.6. Discussion 51
for example, to refine the MBT metamodel for UML Statecharts as the modeling notation for test models, and define several test selection criteria for that notation (Chap. 4). Sec-ond, metamodels are independent of programming languages or execution environments, in which metamodel instances are created and manipulated. This makes our approach ap-plicable in other environments than supported by our prototype. Finally, the creation of a common metamodel helps in communicating, comparing, and judging an MBT approach (realized as a refinement of the metamodel).
However, our approach also leaves open issues. For example, we made a couple of de-sign decisions while creating the MBT metamodel. This decisions are arguable and might have resulted in a metamodel which fits for our purposes only. One of these decisions was to avoid including any modeling notation specific test selection criterion in the MBT metamodel. However, some criteria likeAll-StatesorAll-Transitionsare often mentioned for different modeling notations (Utting and Legeard, 2006), so the decision to include some of them in the MBT metamodel would be sensible. Another design decision was that we did not include workflow related concepts in the MBT metamodel. For example, we could add elements likeTask,Resource,Dependency, and further concepts from the workflow com-munity (Hollingsworth et al., 1994). We decided that these concepts should be added by a refinement of the MBT metamodel. In summary, it is fair to say that the metamodel can only be seen as a proposal to the MBT community and might undergo changes in future.
Workflows
In our approach, we usedabstract workflowsto model the test generation workflow of MBT.
The abstract tasks within this abstract workflow are mapped (using a mapping strategy) to concrete tasks. We made the assumption that somefamily of MBT approachescan be iden-tified, and that an abstract workflow can be used to model the workflows of this family.
Within a family, there might be different approaches for each task, and task mapping was our approach to cope with this problem. Our approach has several advantages: First, it makes the single steps necessary to generate or execute test cases transparent by explicitly model these steps as tasks. The resulting workflow can help in communicating, comparing, and judging an MBT approach. Second, abstract workflows allow to design workflows at a level of abstraction above that of the target execution environment. This approach makes the workflow extensible by definition. We think that this approach can lead to a set of com-mon workflows for different families of MBT approaches. Finally, our approach allows to
treat the issue of test generation as a series of model transformations. We achieved this by using models (based on our MBT metamodel) as data in the workflow. The tasks can then implement their functionality by transforming this models.
Our approach has also some implications we like to discuss: First, similar to the issues with the MBT metamodel, we made design decisions which might lead to a approach fitting our purposes only. Second, it might turn out that our assumption about the existence of family of MBT approachesdoes not hold in practice. In such a case, it is questionable if an abstract workflow should be used in favor of simply using a concrete workflow. We tried to cope with this problem by supporting a mixture of abstract and concrete tasks, so that work-flows containing only concrete tasks are also supported. Second, the usage of our approach might lead to a unpredictable test generation and execution. This will be an issue in cases where an automatic task mapping strategy, i.e. service-based task mapping, is used and the mapping to concrete tasks may change in every execution of the workflow³. While this can be seen as a benefit, because we can introduce new test algorithms easily, it may be an issue when strong reproducibility is required. We think that our approach is still applicable in such cases by using either a manual task mapping, or when using our prototypical imple-mentation, use OSGi filters which match to one and only one service instance. Another way to ensure reproducibility is to applydata provenance(Deelman et al., 2009) by recording the (complete) history of the creation of data object (in our case elements in the MBT model) to be able to reproduce the results of the workflow execution. Another approach would be to go into the details of formalizing the execution semantics of the concrete tasks. In our formalization we avoided this step, because we think that no formal language for describing the execution semantics of tasks has become widely adopted. In order to keep our approach as general as possible, we only formalize the artifacts of MBT in a metamodel and let the concrete tasks operate on an instance of this metamodel. This way, the concrete tasks can be implemented in any formal or general purpose programming language.
Additionally to the above issues, the question about the costs to create and maintain the refinement of the MBT metamodel and the abstract workflows may arise. Within this dissertation, we did not asses this issue with empirical studies, but left it for future work as the next logical step after this dissertation.
³this is analog to a polymorphic dispatch in object-oriented systems, where the object determines the behavior of a method call