MDE - Model Driven Engineering - reference guide(转 The Enterprise Architect)
MDE - Model Driven Engineering - reference guide
While I'm getting a lot of questions about MDE, MDA, MDD, DSL, metamodels, etc. I thought it would be a good time to give a short overview of Model-Driven Engineering and its related concepts. I've managed to do it in about 350 words. However, if you have no experience with model driven software development it can be a bit dense. That's why I have added a glossary below, explaining every used term in more detail (that took another 2000 words... ;) ).
When trying to explain so many concepts you definitely are going to make errors. So, please report them in the comments. I'm of course also happy to receive questions!
MDE explained
Model Driven Engineering, MDE for short, aims to raise the level of abstraction in program specification and increase automation in program development. The idea promoted by MDE is to use models at different levels of abstraction for developing systems, thereby raising the level of abstraction in program specification. An increase of automation in program development is reached by using executable model transformations. Higher-level models are transformed into lower level models until the model can be made executable using either code generation or model interpretation.
A model is specified in some model notation or model language. Since model languages are mostly tailored to a certain domain, such a language is often called a Domain-Specific Language (DSL). A DSL can be visual or textual. A sound language description contains an abstract syntax, one or more concrete syntax descriptions, mappings between abstract and concrete syntax, and a description of the semantics. The abstract syntax of a language is often defined using a metamodel. The semantics can also be defined using a metamodel, but in most cases in practice the semantics aren't explicitly defined, they have to be derived from the runtime behavior.
A model specified using a DSL is called a Domain-Specific Model (DSM). A complex system is usually described using multiple DSMs specified in different DSLs. These models refer to each other and have to be combined when executing them. Because complex systems ask for a lot of DSMs to model them, it is important to structure the modeling space.
As in each software engineering approach quality is an important aspect of MDE. Quality in MDE can be checked, or ensured, with three different techniques: model validation, model checking, and model-based testing.
MDE is often confused with Model Driven Architecture (MDA). MDA can be seen as OMG's (Object Management Group) vision on MDE. The MDA focuses on the technical variability in software, i.e. how to specify software in a platform independent way. The OMG holds a trademark on MDA. I've explained the basic concepts of MDA in a previous post. Another term in this field trademarked by the OMG is Model Driven Development (MDD).
Glossary
Model
Model transformation
QVT - Query/View/Transformation
Code generation
Model interpretation
Model language
DSL - Domain-Specific Language
Domain-Specific Visual Language
Abstract syntax
Concrete syntax
Semantics
Metamodel
MOF - Meta Object Facility
DSM - Domain-Specific Model
Multi-modeling
Modeling space
Model validation
Model checking
MBT - Model-based Testing
Model
The term "model" is derived from the Latin word modulus, which means measure, rule, pattern, example to be followed. A formal definition of model can be: Any subject using a system A that is neither directly nor indirectly interacting with a system B, to obtain information about the system B, is using A as a model for B.
This definition is fairly generic, we can describe the concept model more precise by presenting three criteria for a model. Stachowiak describes that a model needs to meet three criteria otherwise it is not a model:
- Mapping: a model is based on an original. The original (system) might be something yet to be build or it may remain completely imaginary.
- Reduction: not all the properties of the subject are mapped onto the model, but the model is somehow reduced. However, a model must mirror at least some properties of the subject.
- Pragmatic: a model needs to be usable in place of an subject with respect to some purpose.
More on different model roles and usage...
Model transformation
Transforming a model into another model means that a source model is transformed into a target model based on some transformation rules. Different methods can be used for defining the transformation rules. In 2007 the OMG released QVT, a model transformation language specification.
We can make a distinction between transformations (or refinements) adding computational information and transformations adding technology (or platform) information. The first case needs human intervention, the latter can be done automatically if we feed the transformation with the information of the platform.
If we, for example, want to transform a business process model into an lower level format, we have to add all kind of information: rules, data, presentation, etc. If we want to transform a data model into Java code (which can be considered as another model) we can define an automatic transformation based on the information of the platform we have (Java).
Although both examples are transformations between abstraction layers, they differ in executability. That's why we have to distinguish between automatic and manual transformations.
Another transformation type I want to highlight is a change propagating transformation. Change propagating transformations support the non-destructive propagation of changes from the source model to the already existing target model. So, instead of rerunning the full transformation, only the changes are propagated to the target model. Using a change propagating transformation enables the replacement of a component at runtime or with preservation of runtime data. An example of such a transformation is updating the structure of a database (the target model) based on an object model (the source model) without losing data. This, of course, isn't possible for every change.
More on different model transformation approaches...
QVT - Query/View/Transformation
As model transformation is a critical component in the MDA the OMG has been working on a model transformation standard for a while. In 2007 the final specification of the Meta Object Facility (MOF) 2.0 Query/View/Transformation Specification has been released. This specification, better known as QVT, defines metamodels for defining model transformation languages. The resulting languages can transform source models into target models where the source and target models may conform to an arbitrary MOF metamodel. The transformation language itself is also a model and conforms also to a MOF metamodel.
Code generation
Code generation is the act of generating source code (in a programming language like Java or C#) from a model. This can be done in various way, for example by using templates and rewrite rules or by constructing a metamodel of a programming language and defining formal transformations from the metamodel of the model to the metamodel of the programming language.
Model interpretation
Model interpretation or model execution means that we directly execute a model on an engine (or virtual machine). So, we don't generate code or define transformations, we just put the model in a runtime environment and it executes as defined by the semantics of the model.
Model language
A model is specified in some modeling notation. Such a modeling notation is mostly referred to as a modeling language, thereby combining MDE with language theory. Since model languages are mostly tailored to a certain domain, such a language is often called a Domain-Specific Language (DSL).
DSL - Domain-Specific Language
A DSL can be defined as a programming language or executable specification language that offers, through appropriate notations and abstractions, expressive power focused on, and usually restricted to, a particular problem domain.
The domain specificity of a language is a matter of degree. Any language has a certain scope of applicability, but some of them are more focused than others. Languages can be compared using levels based on the number of code statements needed for implementing a function point. This results in a table ranging from low level languages like natural language, machine language and assembly to high level languages which are targeted at a very specific domain (see the SPR programming languages table). Although the difference between a GPL (General Purpose Language) and a DSL is a matter of degree, we mostly consider only the more focused languages as a DSL, such as BNF, HTML or SQL.
More on Domain-Specific Languages...
More on the difference between UML and DSL...
Domain-Specific Visual Language
A DSL with a graphical concrete syntax.
More on the structure of Domain-Specific Languages...
Abstract syntax
The abstract syntax defines the concepts of a language and their relationships.
Concrete syntax
The concrete syntax defines the physical appearance of language. For a textual languages this means that it defines how to form sentences. For a graphical language this means that it defines the graphical appearance of the language concepts and how they may be combined into a model.
Semantics
The semantics describe the meaning of a sentence or model specified in some language. In the context of MDE this means that the semantics of a model describe what the effect is of executing that model.
Metamodel
A metamodel is often defined as a model of a model. The concept of metamodeling is used as a means of language definition. Atkinson and Kühne call this linguistic metamodeling. But according to Atkinson and Kühne this "traditional" point of view on metamodeling covers only one of the two important dimensions. Besides linguistic instantiation, like student is an instance of entity, an ontological instantiation relation exists defining that student is also an instance of person. In linguistic metamodeling student and person are on the same layer, whereas from an ontological point of view person would be on a meta layer. Atkinson and Kühne call this ontological metamodeling.
So, a linguistic metamodel defines the abstract syntax of a language, while an ontological metamodel defines the semantics of a language. As said before, the semantics are almost never formally defined in current practice. They are implicitly defined by the runtime behavior of the languages.
A metamodel itself also needs to be expressed in some language. A possible language with this purpose is MOF.
More on metamodels, different types of metamodels, and metamodel hierarchies...
MOF - Meta Object Facility
MOF is a standard hosted by the OMG. MOF can be seen as a DSL for defining metamodels. In other words: a standard for writing metamodels. While MOF itself is also expressed as a model, it is often called a meta-metamodel.
DSM - Domain-Specific Model
I mostly use DSM to refer to a Domain-Specific Model, i.e. a model specified using a DSL. However, the most common use of DSM is to refer to Domain-Specific Modeling. According to the DSM Forum DSM is defined as:
Domain-Specific Modeling raises the level of abstraction beyond programming by specifying the solution directly using domain concepts. The final products are generated from these high-level specifications. This automation is possible because both the language and generators need fit the requirements of only one company and domain. Your expert defines them, your developers use them.
Multi-modeling
In literature multi-modeling is defined as the act of combining diverse models, which can be done in two ways:
- Hierarchical multi-modeling: hierarchical compositions of distinct modeling styles are combined to take advantage of the unique capabilities and expressiveness of the distinct modeling styles.
- Multi-view modeling: distinct and separate models of the same system are constructed to model different aspects of the system.
When I refer to multi-modeling I mean multi-view modeling as defined above. While in multi-modeling a complete system is described using multiple interdependent DSMs, the integration of these DSMs is needed to synthesize the described system.
Modeling space
A complex system is described with a lot of models, modeling different parts of the system. We call all these models together the modeling space. It is important to structure the modeling space, which can be done by categorizing the model perspectives. We can, for example, categorize the models on
- the system aspect they describe (e.g., data, presentation, security, business rules, workflows),
- the subject area they describe (e.g., order entry, customer portal, back-end administration),
- the abstraction level they are defined in (e.g., CIM, PIM, PSM),
- etc.
If we see these categorizations as dimensions of the modeling space, we can combine them, thereby creating a structured way to deal with a lot of models. Example models in such a structured space are: a platform independent data model of a customer portal, a computation independent workflow model of an order entry component, etc. As you can see models are defined on the intersections of the chosen dimensions.
Model validation
Model validation, or consistency checking, is used for evaluating models with respect to the semantic and syntactic quality criteria. Consistency checking evaluates a model against its metamodels. In addition to metamodels constraints can be used (mostly defined in the metamodel) for validating a model.
The most used constraint language is the Object Constraint Language (OCL), a formal language used to describe expressions on UML models. Hence, you can only use them if you use UML as language for defining your models. That might not always be the best choice...
Model checking
Model checking is a formal verification technique based on state exploration. Given a state transition system and a property, model checking algorithms exhaustively explore the state space to determine whether the system satisfies the property.
For example: the autonomous services of a service-oriented solution are communicating using messages. Each message receipt can trigger a state transition (in state full services) and/or results in a new message. If most of the services are implemented using a process definition the whole system can be modeled in a formal way using processes and interactions. A model checker uses this definition as input along with some correctness claims to check the correctness of a system.
MBT - Model-Based Testing
Besides testing, validating and checking models, we also want to test the resulting software artifact. Testing the behavior of the runtime system with use of test cases automatically generated from models is called Model-Based Testing (MBT).
