« SOA is dead; long liv… | Home | Model Driven Engineer… »

Roles in Model Driven Engineering

Model-Driven Engineering, or Model-Driven Development if you like, asks for other roles than we are used to in traditional software development. I think the most important change is the addition of a meta level. Instead of translating business wishes into source code, a software engineer has to define the Domain-Specific Language (DSL) and how to transform a Domain-Specific Model (DSM) specified in that DSL into working software.

Figure 1 exhibits an overview of the artifacts involved in Model Driven Engineering (MDE). A functional specification is translated into application code by a generator. This application code uses a (domain) framework to execute. Both the application code and the framework conform to some architecture, for example a Service-Oriented Architecture (SOA). The models of the functional specification are specified in a DSL, which in its turn is specified in some meta language. The generator is configured with transformation rules, specified in a transformation language.

The question for this article is: what roles do we distinguish in MDE and how are they different from traditional software development?

A domain expert is involved in defining a DSL. The goal of a DSL is to be domain-specific, so it should capture domain knowledge. If multiple different DSLs are used for modeling an application multiple domain experts are involved in the DSL design process. Although a domain expert is necessary for constructing a usable DSL, we need another role to specify the DSL in a formal meta language: the language engineer.

Once the DSLs are defined, we need to define how models defined in these DSLs are executed or transformed into an executable model (called ‘application code' in Figure 1). This can be done with so-called model transformation. A model transformation is configured using transformation rules, which are specified in a model transformation language (like QVT defined by the OMG). We call the role defining these transformation rules a transformation specialist.

The testing role will change a bit. Technical testing is performed at the meta level. So, test engineers can focus on functional testing. Perhaps part of this work can also be transferred to the meta level with use of model-based testing, but I think it is not possible to fully automate all the testing (automation itself is also error-prone and adds complexity).

2 comments:

Hi Johan, your analysis is in deed very interesting. I have been leading a project for model driven ICT service design and we have identified that it was not trivial to to map out the new engineering process. In particular there are huge knowledge gaps between the domain experts and the language engineers. We managed to bridge that gap to define the meta language and implement its transformation. However when it comes to using the the DSL to actually design and implement ICT services it is almost impossible to find service designers who do understand your DSL. In practice in the telco world the service design has been segmented into big monolithic service models, information models, service platforms and support platforms. When a service designer sees the object oriented modeling language, he or she has a hard time understanding the concept. Part of the issue is that apart from the software engineering most other disciplines have no understanding of object orientation, and hence object models don’t talk to them. If you look at disciplines, like network engineering, the engineers do partial abstractions. We call that M 0.5, as they are mixing instances and classes. When they represent an abstracted network, they draw a cloud with 2, or several boxes connected to it. They don’t fully use the M1 representation, which would be one cloud connected to one box with a 2..*/1 multiplicity. So it became obvious to us that there needed to be a “Service Modeler”, who could capture the requirements of the Domain Experts and describe them in our DSML. We still have a lot of work to do to find a representation that the different domain experts can understand. I think there is going to be a role similar to the software analyst gathering requirements with traditional software engineering in MDE...

Patrick Alff (URL) - 25 02 09 - 01:37

Hi Patrick,

Thanks for sharing your experiences. I often see the same thing happen. I think the minimal requirement for a DSL should be that it is business readable. If every DSL complies to that requirement someone without a programming background can at least read and understand all models.

However, it is possible to create DSLs in which non-programmers can express a model, or at least can define the rough outline of a model. After that someone with a more technical background can finish the details of the model.

So, in principle the role ‘business engineer’ sometimes need to be fulfilled by multiple, different people.

Johan den Haan () (URL) - 25 02 09 - 20:55