This article offers a minimal theoretical approach to Model Driven Design through Model Driven Architecture. It describes what a Conceptual Model is and how it is linked with the Domain Model/Problem Model. Afterwards, it offers a simple example of how a Model is created and manipulated in Model-driven Software Development.
First order of business: What is a Model? Presently, there is still a large debate on what a "model" is and how it is linked with a solution. There are several descriptions for models and several types of models (conceptual model, domain model, business model, etc.). In this sense, we should clarify some aspects regarding the terminology surrounding the concept of "Model".
Any software solves a customer problem. This problem can be divided into several areas of concerns. Based on these areas, we extract topics (themes) that are relevant for the software.
A Domain is an area of concern from the problem. If the area of concern is a business, this would be a Business Domain. The term Problem Domain is a more general term and reflects one or all possible area of concerns.
In computer science, Domain Models consist of representations of all the topics related to a specific problem/area of concern. To put it simply, the Domain Model describes the problem by splitting it into sub-problems, depending on the concerns. This is done by extracting all the key concepts of the sub problems and linking them together. At the end of this process, we see a more comprehensive view of the Problem and its possible solution.
Based on this Domain Model, we design a Conceptual Model (henceforth called simply "model") which proposes a possible solution to the Problem. This is an abstraction based on concepts and relationships from the Domain Model.
The Model becomes an abstraction to a physical system, in which the developer describes various entities, their attributes, relationships and constraints. This also creates a structural view of the Solution, but the focus is on what is important rather than on detail.
There are many views on what Model Driven Design (henceforth MDD) is and what a Model Driven Architecture (henceforth MDA) should look like. However, the leading opinion comes from the Object Management Group (OMG) - a consortium of software organizations that develops and supports specifications to improve the practice of enterprise software development and deployment.
This group has created the conceptual framework, called "Model Driven Architecture" that separates the business decisions (what the application does) from the software oriented decisions (how does it do it), by using "an approach to system specification and interoperability based on the use of formal models".[1]
Basically, MDA uses models to describe the business (functionality) of the solution, independent of any system constraints (software oriented decisions).
In MDA, "platform-independent models are initially expressed in a platform-independent modeling language". In short, the model is described according to specification, independent from the programming language in which it will be transformed. The result source code will be described at the time with the model or after the model is finished, but the model will always have priority.
The solution proposed in this article is influenced by the Object Management Group's vision about MDA, so, each model proposal will be based on this Architecture.
Thomas Stahl describes Model-driven software development (MDSD) as: "an alternative to round-trip engineering. Round-trip engineering is the concept of being able to make any kind of change to a model as well as to the code generated from that model. The changes always propagate bidirectional and both artifacts are always consistent. The transition from code to model (the reverse engineering) is especially interesting in this context. Model Driven Engineering provides the tools used for domain specific constraints and performs model checking."[2]
To put it simply, Model-driven Software Development is the means used to develop applications described by a Model Driven Architecture. Model-driven Software Development is made of:
Domain-specific modeling language (DSML) - models and meta models- in which the relationship among concepts in a domain, constraints and semantics are defined (here we describe the models)
The end product will be platform specific code that will reflect the described model. This assures not only conceptual consistency, but also helps the functional development of the application. "The ability to synthesize artifacts from models helps ensure the consistency between application implementations and analysis information associated with functional and QoS requirements captured by models."[3]
There are also other advantages of using this type of software development.
An example consists of reuse of earlier efforts. The Conceptual model may be Domain specific, but the present solution may be inspired from other projects, or can be used, as a reference for future projects. That results in a reuse of platform dependent solutions, by transforming the model into another Domain specific conceptual model. This approach is supported by the OMG, as it reflects one of the four principles of MDA [1]
These are the building blocks for a Model Driven Application. Now it's time to see it in action. To do this, we must describe a Problem and its potential Modelling Solution.
We assume the following scenario of a Technical Domain: Our client uses as a Graphical User Interface a custom version of the Eclipse Rich Client Platform (Eclipse RCP). In this custom version, called 'myRCP', he intends to use a variety of applications, with different scopes.
Our new application will run in this custom version of RCP as a new perspective.
Business transactions will be handled by an Application server.
To provide a common framework between these applications, the myRCP Client has defined a data structure that should complement any possible needs. This data structure extends EObject from Eclipse RCP. Eg. - all objects extent MyRCPObject.
Domain Model: The application will run in proprietary software. This software contains its own set of contracts (interfaces) for the Objects, and its own custom framework for displaying the visual elements. This software is under continuous change, and our Application must change with it.
We separate the business concern (object handling and business functions) from the display concern (page display). By this, we create two separate components: the RCP component and the business Component. The RCP component handles all the topics regarding the page display, action management and any other user interaction, while the Business Component will handle the business Object management and business functions.
These two components will communicate through their common contract - the MyRCPObject.
Conceptual Model: Each of the two components will receive their own Conceptual Model. This Model will handle all the possible topics regarding the Technical Domain and, in the same time, the Business Domain of the application. This way, our model can offer a technical view and a functional view of the application.
The RCP component is developed within a custom proprietary framework - myRCP. This framework defines how the graphical elements will be displayed and the actions within the Client container.
This raises a concern regarding the implementation cycle. Every developer must learn this proprietary framework and (possibly) the RCP framework. We circumvent this, by modeling the GUI elements.
The Conceptual Model will be described using a Domain-Specific Modeling Language (DSML) in which the developer will describe the visual components and the expected behavior. The visual elements will be linked with Business Objects and the behaviors will be linked with Business Services. This DSML will be called "GuiDSML".
The data exchange between the application server and RCP is done by Data Transfer Objects (DTO). These DTOs will comply with the MyRCPObject contract (as requested by the myRCP framework) and will represent Business Objects.
To reduce the development workload, we generate all DTOs, Business Services Interfaces, Business Objects and the Relationships between them by using a Domain-Specific Modeling Language (DSML) - "BusinessDSML".
The Business Services Interfaces (used by RCP and the Application Server) will be generated, but the business functionality will hand written.
The two Domain-Specific Modeling Languages - GuiDSML and BusinessDSML will be used to describe all the models of the applications. These Models will provide an accurate overview of all the application.
"Xtext is a framework for development of programming languages and domain specific languages. It covers all aspects of a complete language infrastructure, from parsers, over linker, compiler or interpreter to fully-blown top-notch Eclipse IDE integration. It comes with great defaults for all these aspects which at the same time can be easily tailored to your individual needs."[4]
Xtext provides a simple way to design any domain-specific language. After the architect describes the grammar used by the domain specific language, xtext will generate a working parser and linker. This parser will be used in the development of the Conceptual model description. The developer will simply describe the conceptual model in the DSML using the generated xtext parser, focusing only on what is essential to the business aspect of the solution, and not the implementation.
Xtext also offers Eclipse support and many other tools used in the grammar development and in the model development like: content assist, validation and quick fixes, advanced Java integration, Integration with other eclipse tools, etc.
By defining the model with the parser, we assure the compliance with the four principles of MDA, example from [1]:
The model is in a well-defined notation
The system is organized around a set of models that support transformations
The meta-model component consists of the xtext grammar
In this Conceptual Model, the developer will describe an abstract depiction of the visual components and the expected behavior. This is done by fragmenting the perspective into editors and views. These Editors will contain sub-editors and/or graphical control elements.
Let's take the following example from LDAP Studio (c):
https://directory.apache.org/studio/users-guide/ldap_browser/tools_ldap_perspective.html
The main area of the application will be the perspective itself - 1. Every perspective contains one or more editors and/or one more views. Every editor contains paragraphs and/or graphical control elements. Every paragraph contains different graphical control elements.
The model should be able to describe all these elements and their interaction. With Xtext we will describe the components and the Business Objects they work with.
To do this, we take the following GuiDSML example - Entry editor - 2:
{"Description for possible transformation."}
editor EntryEditor opensIn MainEditor {
title Titles.EntryEditor
behavior EntryEditorBehaviours
businessObject EntryDTO
paragraphs{
submenu DN …
table EntryDescriptionTable
}
}
{"Description for possible transformation."}
Table EntryDescriptionTable {
Title Titles.EntryDescriptionTable
businessObject EntryDTO.descriptionDTO
columns {
column AttributeDescription {
value descriptionDTO.attributeDescription
}
column Value {
value descriptionDTO.value
}
}
}This is a description of the graphical control elements and their Business Object values. The interaction between components is described in a behavior element, where, the functionality/business is developed.
Behavior EntryEditorBehaviours {
businessObject EntryDTO
Load
Save
customAction changeColorField
customServerAction EntryService.deleteField(descriptionDTO.attributeDescription)
}The Conceptual model describes a behavior, but lets the implementation details to the generated code. The Load and Save actions are default behaviors, and their target code will contain a default implementation. This is done using generics that receive a certain DTO type.
The customAction describes a custom RCP action. Here the Conceptual Model presents the behavior, but lets a part of the implementation details to the developer. The final source code will be generated partially and the developer will receive a method definition, where he must implement the action particularities.
Practically, the model offers some common behaviors, and if these are not enough, it gives the developer the option to describe its own custom actions.
The deleteField is a server call to a specific server functionality. To use this functionality, the developer will bind the action to a specific button. The call will be made, and the answer will be displayed in a specific area.
{"Description for possible transformation."}
Table EntryDescriptionTable {
. . .
columns {
. . .
}
button buttonName action EntryService.
deleteField(descriptionDTO.attribute)
}This Conceptual model should describe all the Business Objects (such as Entry and Description) and the Business Services such as deleteField(descriptionsDTO. attributeDescription).
{"Description for possible transformation."}
entity Entry {
description : listof DescriptionEntity;
}
{"Description for possible transformation."}
entity DescriptionEntity {
attributeDescription : String;
value : String;
}
{"Description for possible transformation."}
dto EntryDTO link Entry {
link descriptionDTO : listof DescriptionDTO;
}service EntryService {
{"Description for possible transformation."}
operation deleteField (
{"Information anout inout."}attributeDescription: String) : void;
}Now that we have our Domain-Specific Modeling Language, the next step is defining the meta-model and the code generation framework.
Underlying these model representations (DSML) is a set of meta-models. "The ability to analyze, automate, and transform models requires a clear, unambiguous way to describe the semantics of the models. Hence, the models intrinsic to a modeling approach must themselves be described in a model, which we call a meta-model."[1]
Our meta-models (one for GUI and one for Business) will describe the grammar (semantics) used for constructing the models. So, every time a developer describes a business object, or a service, or any element specific to the Domain-Specific Modeling Language, the model is analyzed and compiled for possible problems.
An example of an editor in GuiDSML:
Editor EntryEditor opensIn MainEditor {
Title Titles.EntryEditor
Behavior EntryEditorBehaviours
businessObject EntryDTO
paragraphs{
submenu DN …
table EntryDescriptionTable
}
}The Editor in the meta-model (grammar):
Editor :
'editor'name=GUI_ID'opensIn'EditorComponent=EDITOR_ID'{'
'title' title=[Titles::TitleElement]
('behavior'service=[dm::BusinessService])?
('readOnly'service=[dm::ReadOnly])?
'businessObject 'object=[dm::BusinessObject]
'paragraphs''{' (paragraph+=Paragraph)+ '}'
'}';In Xtext we describe the grammar specific to all Domain Model concerns, implicitly Conceptual Model concerns. In the previous example, we can see that an 'editor' element must have a name and a EditorComponent. After the bracket opens it expects a 'title'. The behavior and readOnly tags are optional.
Using the resulting grammar, Xtext generates its parser. This parser verifies that the GuiDSML model is correctly constructed, by comparing it with the input grammar.
One meta-model will be used for all the Client models, and one meta-model will be used for all the Server Models.
This plugin will provide all the necessary tools for describing the model in GuiDSML and BusinessDSML. After the developer finishes the description of the Conceptual model (GuiDSML and BusinessDSML ) a code generator tool will create the final source code.
Up to this point, everything is software platform independent. Here is where the modeling ends and the code results.
In this example we use one of the code generator tools provided by Eclipse Modeling Framework - Xpand. This statically-typed template language generates result code from predefined templates. We use this code generating tool as it specializes on EMF Models (RCP Objects).
Example for an editor:
«DEFINE editorTemplate FOR Editor-»
«EXPAND DefaultEditor(editorTemplate.name)-»
«EXPAND editorTemplate_Vars(editorTemplate.name)-»
«EXPAND editorTemplate_Components_BusinessObject(editorTemplate.businessObject)-»
«EXPAND editorTemplate_Components_Behaviour(editorTemplate)-»
«ENDDEFINE»
«DEFINE editorTemplate_Vars(String name) FOR editorTemplate -»
«IF 'readOnly' == true-»
private booleanreadOnly = true;
«ENDIF-»
private String editorName = « name »;
«ENDDEFINE»
«DEFINE DefaultEditor(String name)-»
Import staticorg.junit.Assert.*;
Import java.io.IOException;
Import java.util.HashMap;
Import java.util.Map;
Import java.util.Set;
…
public static class « name » {
…
«ENDDEFINE»The editor is defined in the order specified by the DEFINE/ EXPAND tags. In the previous example, the class definition is generated.
Import staticorg.junit.Assert.*;
Import java.io.IOException;
Import java.util.HashMap;
Import java.util.Map;
Import java.util.Set;
…
public static class EntryEditor {
private String editorName = EntryEditor;
// template components
}After the generation process is finished, the generated classes are packed into jars and sent from the model to the projects that use these jars. The classes that are partially generated are generated only once - a new generation process will not overwrite the old implementation. As these classes are partially hand written, the source generation process should not override any existing changes.
Xpand is a good solution for generating EMF objects, but for a more general approach, and a better overall solution, I would recommend using Xtend. It is more flexible and easier to read/use.
In practice, every element of the Conceptual Model is analyzed at great detail. After a close and thorough study of the Domain Model, the conceptual model is described (at an abstract level), and, afterwards the meta-modeling creation begins. After the meta-model is finished, it will be passed to the developers for usage. From this point onward, the meta-model will suffer changes if necessary and according to the change in the Problem Domain.
This is only an overview of how an Application, designed using Model-driven Software Development, would look like. Every Domain Problem is different, so every Conceptual Model will be different. For further information, I recommend reading the articles from the reference area, and try some of the tools used in MDD [8].
References
[1] An introduction to Model-Driven Architecture (MDA) - Alan W. Brown, Jim Conallen
[2] Model-Driven Software Development, (Technology, Engineering, Management) Thomas Stahl, Markus Volter
[3] Towards the Automatic derivation of Malaca Agents using MDE - Inmaculada Ayala, Nercedes Amor and Lidia Fuentes - E.T.S.I. Informatica, Universidad de Malaga
[4] Xtext website - http://www.eclipse.org/Xtext/
[5] http://www.omg.org/mda/mda_files/Model-Driven_Architecture.pdf
[6] http://ftp.icm.edu.pl/packages/ace/ACE/PDF/GEI.pdf
[7] https://eclipse.org/community/images/apacheldap.png
[8] http://mdwhatever.free.fr/index.php/2010/06/model-driven-tools-the-big-list/
by Ovidiu Deac
by Radu Butnaru
