Environment generation

The DSL editor generation (label 7 in Figure 3.17), is provided in this framework as an

extensible feature. We use as a basis the graphical environment generator proposed in [39], a work that proposes a neutral, platform-independent model for the generation of visual

name : EString extension : EString Layer name : EString DefaultLayer AdditionalLayer DiagramElement Node isAbstract : EBoolean = false EdgeClass EdgeStyle style : EString width : EInt NodeElement LabelAttribute PaletteDescription icon_filepath : EString name : EString Shape Ellipse width : EInt height : EInt Diamond size : EInt Rectangle width : EInt height : EInt Figure filepath : EString SpatialRelation Overlapping Containment Adjacency EReference EClass EAttribute EdgeReference [0..*] layers [0..*] diagramElements _{[0..1] paletteDescription} [0..1] nodeElement [0..1] shape [0..*] parents [0..1] edgeStyle [0..*] labelAttributes [0..*] spatialRelations [0..1] source [0..1] eAttribute [0..1] eClass [0..1] target [0..*] edgeReferences [0..1] edgeStyle [0..1] eReference self.layers->one(a|a.oclIsKindOf(DefaultLayer))

Figure 3.26: Excerpt of theGraphicRepresentation meta-model.

editors.

Figure 3.26 shows an excerpt of the neutral meta-model proposed in [39] to represent graphical concrete syntaxes, which is called GraphicRepresentation. The concrete syntax information induced from fragments is converted into this intermediate meta-model to be independent from the target technology, but also, to be able to refine this information, e.g., by specifying palette information, organize elements in layers, or select labels for nodes.

A graphical representation in theGraphicRepresentation meta-model is organized into layers (abstract class Layer). There is one DefaultLayer where all diagram elements belong by default

(as shown by the OCL invariant attached to class GraphicRepresentation), and zero or more AdditionalLayers.

DiagramElements define the graphical representation of the objects of a certain meta-model EClass, and can be visualized either as nodes (class Node) or edges (class EdgeClass). In both

cases, they may hold a PaletteDescription with information on how the element is to be shown

in the editor palette. Nodes may be represented as geometrical shapes (Ellipse,Rectangle, etc.)

or as image figures (class Figure). They can display a label either inside or outside the node,

being possible to configure its font style (classLabelAttribute). Moreover, some nodes may need

Chapter 3. Example-driven Meta-model Development

adjacent to (class Adjacency) or being contained in (class Containment) other nodes. On the

other hand, as abovementioned, classes can also be visualized as edges using class EdgeClass.

In such a case, it is possible to configure their style (class EdgeStyle) and the references of

the class acting as source and target of the edge. Regarding the representation of EReferences,

they can be visualized as links by means of the class EdgeReference, and can define a style and

decorators (omitted in the figure).

The GraphicRepresentation meta-model also enables the reuse of graphical property defi-

nitions by means of relation parents in class Node, so that graphical properties defined for a

node are inherited by its children nodes. If a node is only being used as a placeholder for reusable properties but not for drawing, then it should be marked as abstract.

The generation of the modelling environment requires establishing a correspondence be- tween the abstract syntax meta-model of the DSL and the concrete syntax meta-model in Figure 3.26. Classes in the domain meta-model can be represented either as nodes (classNode)

or as edges (class EdgeClass), and are referred to through the reference DiagramElement.eClass.

References in the domain meta-model are mapped into EdgeReferences, and their concrete

syntax annotations are mapped into an EdgeStyle. In addition, if a reference is annotated

with @containment, @adjacency or @overlapping, then it gets assigned a Containment, Adjacency or Overlappingobject, respectively. All created graphical elements are included in theDefaultLayer

and receive a PaletteDescription.

The quality of the resulting editor is subject to the accuracy of the fragments and examples provided by the DE, to the skills of the ME, and finally to the power of the generator that is employed for building the environment. The validation of the deliverable tool is expected to be carried out by the DE, who shall inspect the produced software in order to assess its validity, and report deficiencies to be corrected. We distinguish three scenarios for failure, each one of them solved in a different way:

• The editor is incomplete. If there are node types or relationships missing in the DSL edi-

tor, most probably that means more fragments are needed for completing the abstract syntax. In this case, it is suggested that new fragments are provided, aiming to cover the missing features the DE has signaled.

• The concrete syntax does not match the aesthetics of the sketches. When some node or

connector does not have the same look than those employed in the original drawings, it should be checked whether the target platform actually supports the graphical features

Figure 3.27: Resulting DSVL editor from the running example.

covered by our framework. If it does, then the parameters of annotations @style and

the legend folder should be checked and repeat the generation process.

• The editor is semantically incorrect. Errors in the abstract syntax might cause the unex-

pected functioning of the editor, e.g., objects that can be placed or connected to some other objects that they should not or unexpected attributes. This case demands the ME to examine the meta-model to assess changes to be applied on the meta-model.

Figure 3.27 shows the resulting editor to our running example, obtained from exporting the abstract syntax from Figure 3.22 together with the graphic properties derived from examples. It can be noticed that the concrete syntax of the editor includes the same elements added in the fragments with the exact same graphic representation of nodes and spatial relationships amongst them. Notice, for instance, that theHomecontains a series ofElectronicDevices, or that

Chapter 3. Example-driven Meta-model Development

including all the object types and available connections between them, also preserving the edge style utilized in the fragments, and finally, induced attributes can be added to objects in the properties view.

In conclusion, in this chapter we have presented a process for developing DSML visual editors by example, in which a Domain Expert provides sketches of the desired models, and these are transformed into processable fragments which automatically build a meta-model. A Modelling Expert is in charge of ensuring that the abstract syntax is being built correctly, and is enabled to perform modifications over it. This iterative process results in a visual DSML editor mimicing the graphical properties used by the Domain Expert for the sketches.

4

Meta-Model Validation and Verification of

DSMLs

This chapter presents a framework for meta-model testing which complements the proposed

bottom-up process introduced in Chapter 3. The aim is to have means to Validate and

Verificate (V&V) the quality and adequacy to the domain of a DSML under construction. This is accomplished with three different languages: one for unit-testing (Section 4.2), one for specification-based testing (Section 4.3) and one for reverse testing (4.4).

There are scarce tools and methods supporting DSML Validation and Verification (V&V) [19], which are essential activities for the proper engineering of meta-models. More specif- ically in our framework, there is an actual need for establishing well-defined means for the Domain Expert to ascertain the fidelity of the language under development to the original requirements, as well as ways for the Modelling Expert to formulate assertions to evaluate the quality and precision of the current abstract syntax.

In order to fill this gap, three complementary features to the system, in the form of V&V languages are proposed in this chapter:

• The first one, namedmmUnit, has similar philosophy to thexUnit [15] framework, as it

enables the definition of meta-model unit test suites comprising model fragments and assertions on their (in-)correctness.

• The second one (mmSpec) is directed to express and verify expected properties of a

meta-model, including domain and design properties, quality criteria and platform- specific requirements.

• The third one (mmXtens) aims for the automatic generation of example models that

take into account both the abstract and concrete syntax of a DSL. The idea is producing example instantiations of the meta-model being developed, which both domain experts and engineers can inspect more easily to detect possible flaws in the meta-model and reason on the properties that instances should have.

This chapter is partially based on [71, 72, 73, 74], although certain details have been extended or modified for reflecting later additions and improvements performed over the originally published work.

4.1 Overview

Figure 4.1 outlines the proposed approach to V&V. It comprises our three complementary approaches and languages for meta-model V&V:mmUnit, for unit testing;mmSpec, for meta- model property specifications; and mmXtens, for the generation of example models.

The first approach, realized in the mmUnit language, allows performing unit testing on meta-models with respect to valid and invalid test models, likely provided by the Domain Expert in the form of graphical sketches (label 1 in Figure 4.1) in the exact same way it is

explained in Chapter 3, relying on the core system features for their transformation into text fragments (label 2).

mmUnit incorporates an assertion language for describing expected errors in test models

and make explicit why a certain test model is incorrect. It is the Modelling Expert in this case the one in charge of formulating those assertions based on the fragments provided by the Domain Expert (label 3) and his own knowledge on the abstract syntax. In the end,

the fragment and the attached assertions are evaluated to check the fragment conformance with respect to the meta-model under test (label4), producing the system the pertinent test

results.

Note that in EMF, meta-models can be tested using the generic JUnit framework for unit Java code. However, unit testing of incorrect models is problematic because EMF models need to conform to their meta-models, and hence cannot include erroneous features. Moreover, JUnit assertions are suitable for Java code (e.g., to assess whether the result of an operation is null), while for meta-model testing, specific assertions to indicate expected

Chapter 4. Meta-Model Validation and Verification of DSMLs

Validation & Verification

mmUnit mmSpec mmXtens Sketch test Meta-model construction requirements quality criteria platform-specific rules Formulate meta-model properties test report model example(s)

Domain Expert Modelling Expert Automatic activity

1 _Parse sketch 2 _Add assertions 3 _Test meta-model 4 6 _Test meta-model 7

sketch fragment fragment

Verbalize domain requirements 5 properties Draw seed fragment 8 _Parse sketch 9 Add extension rules Generate example model(s)

sketch fragment fragment

0 1 11 Evaluate test report 2 1 Evaluate example model(s) 3 1

Figure 4.1: Overview of the framework for meta-model V&V.

conformities/disconformities might be appropriate. Section 4.2 will present all details of this language, whereas Section 6.2.1 features an evaluation with respect to using EMF for unit testing.

Secondly, the V&V of meta-model properties is approached. These properties can emerge from domain requirements elicited by domain experts, quality criteria adapted from object- oriented metrics [13], conceptual schema quality rules [3], naming style conventions [5], and platform-specific rules [95]. While properties can come either from the Domain (label 5) or

the Modelling Expert (input of the activity labelled 6), they will necessarily be encoded by

the latter (main activity in label 6), and run over the meta-model under development (label 7).

Thus, a DSL, named mmSpec, has been developed to describe meta-model properties in a compact and meaningful way. For this purpose, it includes high-level primitives for recurrent meta-model checks, like the existence of a navigation path between two given classes. The features of this language will be explained in Section 4.3. Although we could employ OCL to specify meta-model properties, it was appreciated in the realization of this work that the resulting expressions may get cumbersome, for which a DSL able to express these common properties was created. A comparison between mmSpec and OCL is given in Section 6.2.2.

Finally, the goal of the third example-based validation approach, called mmXtens and presented in Section 4.4, is to automatically produce interesting example models that can be easily inspected (even by non-meta-modelling experts) to validate the correctness of a meta-model, or counterexamples signalling meta-model flaws.

The system is able to produce the output example models either in text format, or, more interestingly, in their visual syntax, if previously specified. The arrangement of the different graphical elements in the produced visualization preserves the one in the seed model (if it was provided), and moreover, it may take into account domain-specific layout rules regarding adjacency, containment and (non-)overlapping of graphical elements.

Occasionally, the mmXtens solver might be unable to produce valid examples. In that event, the Modelling Expert would be committed to exploratorily find out whether this happens due to inconsistencies in the abstract syntax, or due to the use of a search space too narrow. In that event, the user can parametrize the number of objects and relationships that an output model is expected to include.

Normally, at the finalization of any of these three approaches, the delivered output shall be reviewed either by the Modelling Expert (mmUnit andmmSpec) or by the Domain Expert

(mmXtens), although deciding whether or not these results motivate a change in the abstract

syntax before starting the next iteration of the meta-model construction cycle, relies chiefly on the former. These final activities are referred to in labels12 and 13, respectively.