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?
Figure 1 – Overview of Model Driven Engineering
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.
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.
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.
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 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.
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).
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?