In the previous section, we describe the artifacts and components (i.e., modeling
2.20
languages and model editor; code generators) which are used inside a model-driven development infrastructure during the model-driven development of a software system. However, in order to introduce a model-driven development approach to a new domain, a corresponding model-driven development infrastructure must be first created by infrastructure developers. Although there is no comprehensive state- of-the-art process or automation for the systematic development of domain-specific model-driven development infrastructures, best practices have been proposed by several authors (e.g., by Kelly and Tolvanen [KT08, Pt. IV], Völter et al. [Völ+13, Pt. II], Völter [Völ09]). We want to clarify that these best practices do not describe
2.2. Design of Model-Driven Development Infrastructures 27 a general software development process on how model-driven development in- frastructures could be created, but rather provide guidance on how individual components should be designed. Therefore, we contribute our agile bottom-up de- velopment process for domain-specific model-driven IDEs. Based on the following building blocks this process will be described in the next chapter.
2.2.1
Design of Modeling Languages and Model Editors
The hardest part during the development of a domain-specific model-driven devel- 2.21
opment infrastructure may possibly be the identification of concepts, i.e., domain- specific language elements. Various authors, such as Deursen et al. [VD+00], Hudak
[Hud96], Spinellis [Spi01], and Luoma et al. [TK05] carried out research pertaining
to the domain-specific modeling language construction. They propose different methods for concept identification in new domains.
Mernik et al. [Mer+05] describe a detailed approach to construct a domain-specific 2.22
modeling language. This approach consists of the steps decision, analysis, design, and implementation. The decision motivates the development of the new domain-specific modeling language. The main reasons to develop a domain-specific modeling language are notational improvement, task automation, and description of product lines. Within the analysis step, the problem domain is identified and domain knowledge is gathered. Sources of knowledge are the technical documents, knowledge provided by domain experts (interviews), customer surveys and existing implementations, i.e., native program code in general-purpose languages (GPL). Mernik et al. point to two variation points within the design step. First, the designed domain-specific modeling language can exploit other modeling or programming languages. In this case, the domain-specific modeling language is embedded (piggyback) in an- other language. Otherwise, the domain-specific modeling language is developed and used in an isolated fashion (language invention). Second, the degree of for- malism denotes whether the domain-specific language is described informally or with formal methods (e.g., grammars). Finally, the implementation steps describe how a domain-specific language can be implemented. Based on the assumption that models of a domain-specific modeling language are executable, Mernik et al. propose several implementation patterns for such languages. Three important implementation patterns are the interpreter, compiler, and hybrid approach, which are discussed in the next section in more detail.
A domain-specific modeling language which is developed with the techniques 2.23
mentioned before is not ready for use. The domain-specific modeling language needs a least one concrete syntax. Although the design of a textual or graphical concrete syntax is also a very creative part which affects the usability and acceptance of a modeling language in many respects, this task is supported well by tools. Many state-of-the-art frameworks support the semi-automated generation of textual and visual model editors.
2.2.2
Design of Model Compilers
Technically, a code generator realizes a model-to-code (M2C) transformation. Since 2.24
the input and output follow a well-defined language, the term model compiler is also often used in literature. Two alternative approaches are proposed in literature to create model compilers:
2.2.2.1 Visitor-Based Approach
A visitor-based approach processes every model element and generates a stream of 2.25
Architecture) [Boo03] [41] follows this approach. It provides the creation of meta- modeling elements and corresponding Java classes and an application program- ming interface (API) for modifying these models. A visitor mechanism traverses the model and invokes code synthesis (CodeWriters) for the considered model element. The Jamda framework manipulates metamodel elements as long as possible by using cumulative transformations. A disadvantage of this framework is its focus on a top-down model compiler development. Having, as in our case, reference applications, it seems not feasible to decompose them into single transformation steps. Nevertheless, this approach will be applied partially to expand and deco- rate the input model with additional model elements (cf. Section7.3.2) during a preprocessing step.
2.2.2.2 Template-Based Approach
Most model compiler frameworks (e.g., JET [67], FUUT-je, Codagen Architect,
2.26
AndroMDA [24], ArcStyler, MetaEdit+ [TR03], and OptimalJ [Lon03]) follow a template-based approach. A template represents a unit of static code with meta- code gaps. These meta-code gaps are filled during the model compilation, using information from the app model as an instance of the domain-specific modeling language. Hence, template extraction is aimed at identifying which parts of a program are static, which parts are schematically recurring (e.g., declaration of attributes and corresponding getters and setters), and which parts depend on the modeled information. In contrast to the visitor-based approach, the template-based approach fits well to the bottom-up creation of a code generator.
Since the model-driven development infrastructure should generate runnable mo-
2.27
bile applications, all related resources, i.e., layouts, mobile application project properties, and icons, must be generated as well, since the mentioned artifacts can also generated by a template-based approach. Hence, we deal not only with model-to-code transformation but also with a more general model-to-text (M2T) transformation. Actually, this would not affect the template-based approach. Both code generators to be developed are written in Xtend [Bet13] using the template- based approach.
Example(Native Program Code Template). Listing2.1shows a native program
2.28
code template for the generation of POJOs (Plain Old Java Object). The main template function (lines 1-8) gets the modeling element class and generates the native program code of this class comprising the local field declarations and the accessor methods (getter and setter).
LISTING2.1: Template for POJO generation
1 <<DEFINE Root FOR Class >> 2 public c l a s s <<name>> { 3 <<FOREACH a t t r s AS a>>
4 p r i v a t e <<a . type . name>> : <<a . name> >; 5 <<ENDFOREACH>>
6 <<EXPAND AccessorMethods FOREACH a t t r i b u t e >> 7 }
8 <<ENDDEFINE>> 9
10 <<DEFINE AccessorMethods FOR A t t r i b u t e >>
11 public <<type . name>> get <<name . t o F i r s t U p p e r > >() { 12 r e t u r n t h i s. < <name> >;
13 }
14 public void s e t <<name . t o F i r s t U p p e r >>(<< type . name>> <<name> >)
{
15 t h i s. < <name>> = <<name> >; 16 }
2.2. Design of Model-Driven Development Infrastructures 29 The first static code occurs in line 2 outside the meta-code tags («...»). This code will be generated without modification. The static code in line 4 may occur several times because it is part of the for-each-iteration. As seen in line 6, other template functions can be called again in order to generate native program code. This native program code appears at the location of template method invocation.
Using the class Address (cf. Figure2.3) as input, the generated code is shown in 2.29
Listing2.2. From a developer’s perspective, it is often not possible to distinguish between generated and manually written program code. We follow this attitude when generating human-readable code. Although models are the primary artifacts within the model-driven development approach, it is advisable to keep generated artifacts human-readable regarding labels and structure.
Address
City:String ZIP:String Street:String Number:Integer
FIGURE2.3: The class Address
LISTING2.2: The compiled object Address (of type class)
1 public c l a s s Address 2 p r i v a t e S t r i n g : C i t y ; 3 . . . 4 p r i v a t e I n t e g e r : Number ; 5 6 public S t r i n g g e t C i t y ( ) { 7 r e t u r n t h i s. C i t y ; 8 } 9 public S t r i n g s e t C i t y ( S t r i n g C i t y ) { 10 t h i s. C i t y = C i t y ; 11 } 12 . . . . 13 }
This encourages the manual extension of generated software prototypes (as required by our agile bottom-up development approach) as well as the maintainability of
the code templates.
A very common practice is the creation of code templates (cf. Listing2.1) from 2.30
existing code samples (cf. Listing2.2) gained by reference applications. We will also follow this common practice of model compiler construction, but it should also be clarified how this approach is affected by model interpreter requirements.
2.2.3
Model Compiler vs. Model Interpreter
As shown by the preceding example, the model compiler replaces the meta-code 2.31
statements by the corresponding static information (e.g., class name, type names). The following two examples show the difference of a model compiling approach from a model interpreter approach:
Example(Model compiler). Given the GUI model in Figure2.4, the Page Process- 2.32
esOverview (ProcessSelectorPage) and its style settings can be translated into the native program code shown in Listing2.3.
FIGURE2.4: Excerpt of a GUI model (showing a ProcessSelectorPage and StyleSettings)
LISTING2.3: The compiled object ProcessesOverview (excerpt)
1 . . . 2 public c l a s s M a i n P r o c e s s e s A c t i v i t y extends A c t i v i t y { 3 . . . 4 p r i v a t e void c r e a t e P r o c e s s L i s t ( ) { 5 . . . 6 m a i n _ l i s t . s e t F o n t C o l o r ( . . . ( 2 5 5 , 2 5 5 , 2 5 5 ) ) ; 7 . . . 8 } 9 }
The corresponding code template evaluates the meta-code statement «styleSet-