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?

Model Driven Engineering (MDE) overview

Figure 1 – Overview of Model Driven Engineering 

Meta level

The most important change in software development roles is the addition of a meta level. On this meta level we distinguish the following roles: domain expert, language engineer, transformation specialis, implementation / platform expert, and software factory architect.

Domain expert

Domain expertA 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.

Language engineer

The language engineer uses a meta language to specify the concrete syntax and abstract syntax of a DSL. For more information on metamodels see one of my previous article on defining DSLs with metamodels. Although DSL design can become quite complex, with appropriate tooling you don’t have to be an experienced language engineer to define a DSL. See for example openArchitectureWare and/or MetaEdit+.

Transformation specialist

Transformation specialistOnce 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.

Implementation / platform expert

While a transformation specialist knows how to use a transformation language and how to transform models into other model, an implementation (or platform) expert knows everything about executing / interpreting a model. A model is executed based on its semantics. While a model only contains the variable elements of an application (the business logic), a framework is needed for the static elements (the infrastructure). A platform expert defines and implements such a framework and ensures that it conforms to a given architecture.

Software factory architect

We’ve seen four roles involved with parts of the MDE process. I want to add one important role: the software factory architect. The situation shown in Figure 1 is a simplified version of an MDE process. In practice you’ll have a lot of models specified in different DSL, together leading to a working software application. A software factory architect defines what models are needed, how they relate, in what order they have to be produced, and how changes are propagated. In short: he defines the methodology, hence we can also call him a ‘method engineer’. A software factory architect also defines the architecture the resulting applications should conform to. See the place of architecture in Model Driven Engineering for more information.

Application Design

Besides the new meta level roles, the traditional roles in application development also change. Application design is still a challenging task. Complex real-world problems have to be expressed in a formal model. The good thing is that this model can be at a much higher level. You don’t have to be a programmer to read and write such a model. On the application level we can distinguish the following roles: business engineer, application / solution architect, test engineer.

Business engineer

Business engineer is a changed role in application development. The one translating a business problem into a formal application model. This role needs both an understanding of the problem domain and skills to express that understanding in a formal model. Because this model needs to be specified in a DSL a business engineer differs from a programmer.

Application / solution architect

Although an MDE software factory can guide business engineers a lot in how to specify an application model, they still have to decide on the application architecture. How to split functionality in components and services? That’s not a trivial task. See for example the architecture requirements for Service-Oriented Business Applications. I think the role of solution architect will stay important. However, note the difference with traditional software engineering: the technical architecture is defined on the meta level. The transformations guide how models are transformed to or interpreted by technology.

Test engineer

Test engineerThe 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).

Conclusion

We’ve seen the roles involved in model driven software development. Different roles doesn’t mean different people in every situation. One person can fulfill multiple roles. However, we see a substantial difference with the roles in ‘traditional’ software development. In practice this lead to changes in the roles people have in their job.
 
Do you recognize these roles? What are your experiences with people having to change to one of these roles?
 
 
————–
Figure 1 is created by me. Other pictures by (in order of appearance): HikingArtist.com, aikwhye, jasewiththeface.
 

2 Comments Added

Join Discussion
  1. Patrick Alff February 25, 2009 | Reply

    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…

  2. Johan den Haan February 25, 2009 | Reply

    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.

Leave a Reply