Model-Driven Engineering (MDE) in a nutshell

Models have been an integral part of software engineering and have always been used to support different stages of the software development lifecycle of a product. Model-driven engineering (MDE) is a modern approach to software engineering, which obeys the core principle that “Everything is a model” and focuses on the creation, manipulation and management of conceptual models of software systems. Models provide an abstract representation of the system and above all, allow for managing complexity by describing application-specific solutions using high-level graphical modelling, rather than a programming language. Thus, abstraction from the implementation details allows for an evaluation of the target system properties very early in the design, as it is less expensive to modify or refine models of the system at a high-level prior to development, than after it has been fully built.

In recent times, pieces of software have become more and more complex and their evolution will surely be increasing in the future, which requires that they are looked at different levels of abstraction. One way in which this can be accomplished is through the use of models, which are abstract representations of a system. Models have always been used in software engineering to support various stages of the development lifecycle, however they were not traditionally seen as end-products. That is why MDE is a growing software engineering paradigm which treats models as primary artifacts, as opposed to other traditional paradigms which consider source code as their primary artifact. Models capturing various information allow for representing different views of the system and focusing on certain aspects of it. Having different views of the system captured in models can be useful for concentrating on a particular concern of the system where irrelevant information is filtered out. Therefore, models provide a powerful way to manage complexity by allowing developers to separate concerns and describe complex systems from a very abstract point of view.

Models could be represented either graphically or textually, but in both cases they must be expressed in a well-defined and unambiguous notation. That is why, models are normally expressed in a general purpose modelling language which is characterised by three main components:

  • Abstract syntax which specifies the structure of the language and the way its primitives can be combined.
  • Concrete syntax which describes the actual representations of the language elements in terms of visual appearance.
  • Semantics which specify the meaning of the language elements.

The abstract syntax of a modelling language is often represented with a metamodel, which defines the structure that the model must conform to in order to be valid. Furthermore, metamodels are subject to modification and extension of the language definition and can be used to check whether models are valid instances of the language. Having precisely defined metamodels is the basis for applying operations on models such as querying the content of models, checking their well-formedness, or as we shall see later on – performing model transformations. All models must be
built in compliance with a set of metamodels thus facilitating meaningful integration and transformation among models and automation through tools. Although the standard metamodeling language defined by the Object Management Group (OMG) is the Meta Object Facility (MOF), several other tools for metamodeling exist, the most widespread of which is the Eclipse Modeling Framework (EMF) which uses the metamodeling language Ecore.
Another initiative by the OMG is the Model Driven Architecture (MDA) which is an approach to software development relying on automated mapping of models to implementations. MDA typically distinguishes between three modelling levels in a software system:

  • Computation Independent Model (CIM) which outlines the requirements of the system and the business context, but does not consider any structural or processing characteristics.
  • Platform Independent Model (PIM) which describes the system, its information and algorithms, independently from the platform or the technology that is adopted to realise it.
  • Platform Specific Model (PSM) which provides detailed specification of the system including technology and platform-specific characteristics.

A set of mappings between those modelling levels can be defined through model transformations. The basic MDA pattern involves a single PIM that can then be transformed into one or more PSMs. Such transformations need to provide the additional information required in order to produce the PSM from the PIM. Ultimately, this is one of the main objectives of the model-driven approach – transforming the higher-level models to PSMs via code generation techniques. Transformations performed by code generators that convert abstract models into platform specific code are indeed essential to MDE, because they provide increased productivity in development by leaving most of the less challenging and mundane aspects of the programming to the code generator. Other major goals of MDA apart from increased automation include improved portability, interoperability and reusability which are accomplished through abstraction and architectural separation of concerns. It is also key to emphasise that models are structured and live entities that are amenable to automated processing and by manipulating models, repetitive tasks can be automated, resulting in increased productivity.

As already mentioned, in order to achieve the transition from a model to some other useful artefact, model transformations are used. Model transformations provide a chain that allows for automatically implementing a system in successive steps from the various models present, each of which can subsequently produce a more and more refined version of the software. Transformations may also be used for various other purposes in MDE including modifying, creating and merging models which all rely on the reuse of information captured in models to do so.
Model transformations normally have one or more source models as inputs and one or more outputs which depending on the type of transformation can either be another set of models or text. Consequently, we can identify two types of model transformations according to the type of target. Model-to-model transformations (M2M) generate elements of the target model by mapping source model elements to elements in the target model (e.g. transforming a UML class diagram into an Entity Relationship Diagram). Transformation is performed between a source and a target model both of which have to conform to a metamodel, following a set of transformation rules that are defined in a transformation language. On the other hand, model-to-text (M2T) transformations map source models to a set of files. Quite often, the text produced by the transformation is source code, in which case the transformation can also be referred to as model-to-code transformation (e.g. generating Java classes with appropriate attributes, getters and setters based on information in the class model). M2T approaches, however, can be useful not only for achieving the transition from the model level to code level, but also for generating non-code artifacts such as documents, for example. Within the M2T category, a common approach in which transformations are performed is the template-based approach, which separates the static and dynamic parts of the code. A template defines the static text elements shared by all artifacts, while dynamic parts are marked with meta-markers and contain code that accesses the information stored in the source model. Those dynamic parts are then filled in with relevant information specific to each particular case. Templates help explicitly defining the structure of the output which leads to generating more readable and understandable code. Also, being able to reuse a personalised and manually developed presentation template in an automatically generated application, can win the acceptance of users, reluctant to use MDE.

Unfortunately, MDE does not come without disadvantages. First, there is a general barrier of mistrust in the software engineering community concerning the quality of the automatically generated code, which is perceived by many as less performing than the highly optimised code developers can write manually. Moreover, powerful tools are required to support the automation of model transformations if the MDE vision is to become widely spread in the software development community. These tools should not only allow users to execute predefined transformations on demand, but also to fine-tune and define their own transformations using an advanced transformation language. Furthermore, it must be noted that using MDE to support the software development across all layers of an application (e.g. business logic, data, user interface) is still regarded a difficult task. Generating a fully functional application code across all tiers is complex because of the complexity in creating models that are detailed enough to be usable in practice for generating an application end-to-end. Although successfully generating code from models is possible, it is better suited to the cases where the model is very close to the implementation or where the semantics of the transformation is well understood (e.g. transforming a UML class diagram into class skeletons). That is why this project concentrates on generating code for only one tier of the application (e.g. user interface) for the purposes of early prototyping, where the internal quality of the end solution is not of prime importance.

6 Responses to Model-Driven Engineering (MDE) in a nutshell

Leave a Reply

Your email address will not be published. Please enter your name, email and a comment.