3.2.1 Overview
Once we have explained the benefits that a bottom-up strategy can bring to a meta-model development process, we present our own solution for it, a novel way to define meta-models and modelling environments. It is particularly important mentioning that this framework was designed with the observance of the following requirements:
• Bottom-up. Whereas meta-modelling requires abstraction capabilities, the design of
DSMLs demands, in addition, expert knowledge about the domain in two dimensions: horizontal and vertical [11]. The former refers to technical knowledge applicable to a range of applications (e.g., the domain of Android mobile development) and experts are developers proficient in specific implementation technologies. The vertical dimension corresponds to a particular application domain or industry (e.g., insurances) where experts are usually non-technical people. Our proposal is to let these two kinds of experts build the meta-models of DSMLs incrementally and automatically starting from example models.
Using example models is appropriate in this context, as these two kinds of users may not be meta-modelling experts. Example models document requirements of the DSML to be built, provide concrete evidence on the specific use of the primitives to be sup- ported by the DSML, and can be used for the automated derivation of its meta-model.
Chapter 3. Example-driven Meta-model Development
Afterwards, the induced meta-model can be reviewed by a meta-modelling expert who can refactor some parts if needed.
Finally, DEs also play a crucial role in meta-model validation. Thus, we encourage their collaboration in this task by proposing an example-based validation process where end-users can feed the system with concrete examples models, and the system reports whether they are correct according to the current version of the meta-model, and the reason why they are not. Moreover, we also enable the automatic generation of example models fulfilling certain criteria, which can be populated either from a seed model fragment or from scratch. In this way, DEs can easily perform validation by just inspecting the generated models.
• Interactive. A meta-model can become large, and it may address different separate
concerns. In practice, its construction is an iterative process in which an initial meta- model is created, then it is tested by trying to instantiate it to create some models of interest, and whenever this is not possible, the meta-model is changed to accommodate these models [57]. The performed changes may require the detection of broken models and their manual update.
Our proposal aims at supporting this interactive meta-model construction process. Hence, we do not advocate building a complete meta-model in one step, but the meta- model is “grown” (using the terminology of Test-Driven Development [34]) as new fragments gathering more requirements are inserted. If a new version of the meta- model breaks the conformance with existing models, the problem is reported together with possible fixes.
• Exploratory. The design of a meta-model is refined during its construction, and several
choices are typically available for each refinement. To support the exploration of design options, we should let the developer annotate the example models with hints about the intention of the different model elements, which are then translated into some meta-model structural design decision or into additional integrity constraints.
• Guided by best-practices. Since the users of this approach may not be meta-modelling
experts, we provide a virtual assistant which suggests the application of meta-modelling design guidelines, best practices and refactorings that help to improve the quality of the current version of the meta-model.
• Implementation-agnostic. The platform used to implement a meta-model may enforce
inclusion of a root node). This knowledge is sometimes not even available to meta- modelling experts, but only to experts of the particular platform. For this reason, we postpone any decision about the target platform to a last stage. The meta-models built interactively are neutral or implementation-agnostic, and only when the meta-model design is complete, it is compiled for a specific platform.
In this context, this work aims giving support to four main functionalities in the meta- model development process:
1. Provide a way for DEs to be able to sketch their own model fragments in a free, visual format. This platform needs to be extensible, that is, permitting new formats to be easily added, as this will make the meta-modelling tool independent from a specific drawing tool.
2. Automate a process in which input fragments are used to grow a meta-model which can also be changed by the ME.
3. Facilitate validation and verification activities over the fragments and the meta-model under development, including an automatic instance generation facility.
4. Enable a range of generators that provide the abstract syntax meta-model with a concrete syntax as similar as possible in its format to the input fragments provided by the DE.
The ultimate goal of this work is to facilitate the creation of DSMLs by DEs without proficiency in meta-modelling and MDE platforms and technologies, and to aid the ME in the process. For that, the bottom-up process shown in Figure 3.2 has been designed. This chapter tackles the core part of that process, gray-shaded in the Figure. If we take a look at it, we can see that it sketches an iterative cycle, started by the DE providing input examples in the form of drawings, that is, portraying how models should look like (label 1). Then, the examples are automatically parsed into models, more amenable to manipulation (label 2). The parsed models are represented textually, making explicit the existing objects, attributes and relations in the examples. The ME can edit this textual representation (label 3) to set more appropriate names to the derived relations, or to trigger refactorings in the meta-model induction process which takes place next (label 4). Thus, an iteration step finishes when the meta-model under construction is evolved to accept the revised fragment.
Chapter 3. Example-driven Meta-model Development Draw sketch Parse fragment Revise and annotate fragment Meta-model generation DSL editor generation Editor validation Update meta- model according to revised fragment Domain Expert Modelling Expert Automatic activity 1 2 3 4 6 7 Perform Validation & Verification 5 8
Figure 3.2: Scheme of the overall process.
Furthermore, our framework enables test case definition and property check over the ever growing meta-model (label 5), as well as the automatic generation of examples for their validation. This task, explained in detail in Chapter 4, normally demands the collaboration of both modelling and DEs, and, as it encompasses a broad variety of tools and languages, it is presented as an independent test framework itself.
After processing all provided examples, the ME can export the induced meta-model to a suitable format (label 6), and invoke our DSL editor generator to obtain a fully operating editor mimicking the concrete syntax of the examples (label 7). The DE can validate the editor (label 8), and if necessary, he can refine the DSL by providing further examples and re-generating the editor. We fully detail the DSL editor generation process in Chapter 3.5.
3.2.2 Running example
As a running example, we will develop a DSL in the home networking domain. The DSL is inspired by one of the case studies in the Sirius gallery1. In this DSL, we would like to
represent the ocustomer data held by internet service providers (ISPs), the possible con-
figurations of home networks, and their connection with the ISP infrastructure. Customer homes are connected via cable modems to the ISP network. Typically, each home has a (normally WiFi-enabled) router to which the landline phone is connected, and with a num- ber of Ethernet cable ports. WiFi networks are password protected and work in a frequency
Figure 3.3: Fragment showing a connection between customer homes and an ISP.
range. Moreover, each home may have both cabled devices (e.g., PCs, printers or laptops) and wireless devices (e.g., smartphones, tablets or laptops).
Using the presented approach, DEs provide example fragments that illustrate interesting network configurations and depict the desired graphical representation for them. As an example, Figure 3.3 shows an example of a fragment representing the connection between some customer homes and the ISP through cable modems. The elements in the drawing define some properties, like the ipBase of cable modems, thename of the home owner, the tier
and location of the ISP network, and the name of the ISP. The legend to the right assigns a
name to every picture used in the drawing.
Figure 3.4 shows a real snapshot of the process, in which a sketch has been drawn by a DE, and automatically turned into a text fragment from which a meta-model has been induced. The meta-model is then converted into a visual DSML editor.