Model-Driven Development (MDD) [MCF03, Sel03], also called Model-Driven Software Engineering (MDSE), refers to a software development process which focuses on building models of software systems before actually implementing them. This principle is well-known in traditional engineering principles; in fact, in many cases the construction of complex structures such as buildings or bridges is not feasible without a model. MDD attempts to transfer the advantages of modelling to software engineering, in which case the benefits from a process based on models promise to be every greater: Through automation, models can be used for more than just communication purposes; in fact, they can be used to drive the system implementation or even replace the need to implement a system by hand.
The concept of model-driven development is independent of any concrete technology. Several frameworks for MDD have been proposed, the most promi- nent of which is the Model-Driven Architecture (MDA) by the OMG [Ric00]. MDA is closely related to other OMG standards such as the UML and MOF introduced in previous sections.
This thesis takes a wider approach to MDD without committing to any particular OMG or other standard.
The following subsections describe the idea of models in software develop- ment, the added benefits of being able to analyse models before implementing a software system, and finally the automatic generation of software artefacts and, in the end, executable code.
2.4. MODEL-DRIVEN DEVELOPMENT 37
2.4.1
Models
It is difficult to arrive at a global, agreed-upon definition of amodel, as models differ between application areas, abstraction level, and purpose. For example, one might consider code written in Java or C# to be a model of a software sys- tem, since it abstracts from the concrete machine instructions, instead allowing developers to think and write code in terms of classes, objects, and (virtual) method invocations. Another view might consider code written in such a lan- guage to be too concrete, and consider a graphical representation of a system, for example drawn using UML constructs, as a model later to be implemented in Java or another language.
In general, the definition of a model tends to concentrate as much on what is modelled as on what is not, i.e. theimplementation which is abstracted away. Each of the two examples provided above is based on this view: The respective models are more general than their counterpart implementations, and thus fur- ther removed from any concrete implementation technique and more focused on abstract concepts. The term ofplatform independence is often associated with models, which reflects the attempt to model software independent of any one realisation option. An example of the inverse relationship of abstraction and platform dependence is shown in figure 2.11.
Abstraction Machine Code Byte Code Java Code Activity Use Case Platform Dependence
Figure 2.11: Model-Driven Development
Independent of the concrete model abstraction level, a model should be easy to specify, understand, and maintain, which means that the modelling technique must be tailored to the concrete problems at hand. This has given rise to the concept of domain-specific modelling languages (DSMLs). It is also important to note that using MDD is by no means a single-step approach: Models can be refined in a step-wise fashion, thus introducing many intermediate representations of the system with varying levels of details.
and thus allowing too much freedom in implementation — and too specific, negating the benefits of using a model in the first place. The level of detail required depends on the target use of the model. For maximum usability, a model should at least be amenable to analysis, if not for code generation. These two ideas are discussed in the following.
2.4.2
Analysis on Models
Using models as an abstract representation of a computer system has the benefit of being more amenable to (formal) analysis, as fewer details need to be taken care of and the essence of the software behaviour can be extracted in an easier fashion. As models are available in an earlier phase of a software development process than the actual implementation, there is a higher chance of still being able to correct a system design if problems are found.
Analysis of software models has the aim of testing, or verifying, that certain properties hold in the modelled software. Such analysis can take the form of executing (parts of) a model to evaluate its runtime properties; another form is using rigorous mathematical techniques for verifying the qualitative or quantita- tive aspects of the system, i.e. aspects such as deadlock freeness or performance analysis and prediction in different usage scenarios.
In chapter 1, the Sensoria project has already been mentioned. Many results of this project lie in the area of model-driven verification by using formal methods; also, several of the tools developed inSensoriaaddress this area and have been integrated into the common tooling platform introduced in chapter 8.
2.4.3
Model Transformations and Code Generation
Model-driven development and its promise of automated development is closely linked to the domain ofmodel transformation, which is in fact regarded as one of the core technologies for the realisation of model-driven development.
As noted above, model-driven development is not a single-step approach from a model to executable source code. Rather, multiple steps are possible where both the source and the target artefacts can be regarded as models of the software system. Thus, model transformation may refer to any translation from a source software artefact to a target artefact; the latter might even be a model of machine code.
Model transformations are defined in terms of domainmeta-models instead of models. As shown in figure 2.12, a model transformation relates two meta- models to one another; execution of the transformation then results — depend- ing on the direction — of a transformation of a concrete model compliant to one of the meta-models to a concrete model compliant to the other meta-model.
Model transformations, in general, are not concerned with generating code, but stay on the level of model instances. Thus, two additional steps are required on a technical level to acquire the source model from its native representation, and to emit the target model in the same way. These are referred to as deseri- alisation and serialisation, and are shown at the bottom of the figure.
2.4. MODEL-DRIVEN DEVELOPMENT 39 Input Meta- Model Input Model
Transformation
Specification
Transformation
Execution
Output Meta- Model Output Modelinstance of execution of instance of
source
reads
target
writes
deserialise serialise
Figure 2.12: Model Transformations
It is important to note that MDD in itself does not define which models are considered read-only, and which are to be edited further. In figure 2.11, for example, a concrete development process might allow editing of all artefacts, or only of the artefacts higher than or on the same level as UML or Java. There are two fundamental views of MDD which affect this decision.
The first view is that of MDD as a compilation step. In this view, a certain model is selected as the definitive implementation of the system. All other models on the way to machine code are generated and not to be read by humans. In this view, MDD is a natural extension, or new layer, on top of existing compilers.
The second view is that of MDD as a helping hand in programming: Models do not contain the complete specification of a system, but are rather seen as a first step to generate code which is later extended in a lower-level programming language.
Note that in the first view, all information about the system resides in the model, as all changes are done in the model, and the code is re-generated after each change. In the second view, changes to the initially generated code lead to inconsistencies between the model and the implementation. Possible remedies include discarding the model once it has served its purpose, or attempting to keep both artefacts in sync. The latter, however, is a complicated topic and a research area of its own.