MDA, Model Driven Architecture, basic concepts

Nowadays creating enterprise software comes with a lot of compatibility issues. Existing application landscapes within enterprises consist of a lot of different applications, application servers, middleware solutions, operating systems, programming languages, etc. In an ideal situation new software build in such a context is compatible with all existing and future systems. Users of enterprise software shouldn’t have to deal with compatibility issues. According to the Object Management Group (OMG) this isn’t possible: "Given the continued, and growing, diversity of systems, this will never be achieved by forcing all software development to be based on a single operating system, programming language, instruction set architecture, application server framework or any other choice. There are simply too many platforms in existence, and too many conflicting implementation requirements, to ever agree on a single choice in any of these fields." (OMG, 2003). The solution of the OMG is Model-Driven Architecture (MDA). The state: "We have to agree to coexist by translation, by agreeing on models and how to translate between them" (OMG, 2003).


MDA, Model-Driven Architecture was first mentioned in 2000 in an OMG whitepaper (Soley, 2000). Based on this whitepaper OMG members decided to form an architecture team to produce a more formal statement of MDA. This formal but still incomplete definition of the MDA was presented in 2001 in the document "Model Driven Architecture – A Technical Perspective" (ORMSC, 2001). OMG members voted to establish the MDA as the base architecture for their organization’s standards in late 2001. In 2003 a more detailed definition of MDA, presented in the document "MDA Guide Version 1.0.1" (OMG, 2003), was adopted by the members of OMG.

MDA is an approach to using models in software development. The Model-Driven Architecture prescribes certain kinds of models to be used, how those models may be prepared and the relationships of the different kinds of models. According to OMG, MDA is another small step on the long road to turning the craft of building software into an engineering discipline.

Basic Concepts

Before MDA and related concepts can be explained and analyzed a couple of basic concepts have to be defined.

System notions
Two different system notions exist: the teleological and the ontological system notion (Dietz & Hoogervorst, 2007). The teleological system notion is about the function and the (external) behavior of a system. This notion can be visualized with a black-box model. The teleological system notion is adequate for the purpose of using or controlling a system. The ontological system notion, on the other side, can be used for building or changing a system. It is about the construction and operation of a system and can be modeled with a white-box model.

Both the teleological and the ontological system notion are relevant for designing a system (Dietz & Hoogervorst, 2007). In other words: both the functional and the constructional perspective of a system are relevant. In software, the terms functional design and technical design are often used to refer to these perspectives .

Model
A model of a system is a description or specification of that system and its environment for some certain purpose. A model is often presented as a combination of drawings and text. The text may be in a modeling language or in a natural language (OMG, 2003).

Viewpoint
A viewpoint on a system is a technique for abstraction using a selected set of architectural concepts and structuring rules, in order to focus on particular concerns within that system. Here ‘abstraction’ is used to mean the process of suppressing selected detail to establish a simplified model (OMG, 2003).

Platform
A platform is a set of subsystems and technologies that provide a coherent set of functionality through interfaces and specified usage patterns, which any application supported by that platform can use without concern for the details of how the functionality provided by the platform is implemented (OMG, 2003). In principle a platform is a place to launch software on. Examples of platforms are operation systems, the Java Virtual Machine, runtime libraries of programming languages, etc.

Platform Independence
Platform independence is a quality, which a model may exhibit. This is the quality that the model is independent of the features of a platform of any particular type. Like most qualities, platform independence is a matter of degree. So, one model might only assume availability of features of a very general type of platform, such as remote invocation, while another model might assume the availability a particular set of tools for the CORBA platform. Likewise, one model might assume the availability of one feature of a particular type of platform, while another model might be fully committed to that type of platform (OMG, 2003).

Pervasive Services
Pervasive services are services available in a wide range of platforms (OMG, 2003). In the MDA pervasive services are modeled as platform independent. Examples are Directory services, Event handling, Persistence, Transactions, and Security (Soley, 2000).

Application
The term application is used to refer to computer software delivering certain functionality.

Implementation
An implementation is a specification, which provides all the information needed to construct a system and to put it into operation (OMG, 2003).

Model Transformation
Model transformation is the process of converting one model to another model of the same system (OMG, 2003).

Overview

MDA is an approach to using models in software development. The Model-Driven Architecture prescribes certain kinds of models to be used, how those models may be prepared and the relationships of the different kinds of models. The basic concept of the Model-Driven Architecture is the separation of the operation of a system from the details of the way that system uses the capabilities of its platform.

The MDA provides an approach in which systems are specified independently of the platform that supports it. It also provides an approach for specifying platforms, for choosing a particular platform for the system and for transforming the system specification into one for a particular platform.

The three primary goals of MDA are portability, interoperability and reusability through architectural separation of concerns (OMG, 2003).

MDA Viewpoints
The Model-Driven Architecture specifies three viewpoints on a system, a computation independent viewpoint, a platform independent viewpoint and a platform specific viewpoint.

Computation Independent Viewpoint
The computation independent viewpoint focuses on the on the environment of the system, and the requirements for the system. The details of the structure and processing of the system are hidden or as yet undetermined (OMG, 2003). The Computation Independent Viewpoint can be compared to the teleological system notion (see 2.1).

Platform Independent Viewpoint
The platform independent viewpoint focuses on the operation of a system while hiding the details necessary for a particular platform. A platform independent view shows that part of the complete specification that does not change from one platform to another. A platform independent view may use a general purpose modeling language, or a language specific to the area in which the system will be used (OMG, 2003). The Platform Independent Viewpoint can be compared to the ontological system notion (see 2.1). An ontology is implementation independent by definition.

Platform Specific Viewpoint
The platform specific viewpoint combines the platform independent viewpoint with an additional focus on the detail of the use of a specific platform by a system (OMG, 2003).

MDA Models
MDA specifies three default models of a system corresponding to the three MDA viewpoints defined in 3.1. Besides these models MDA also specifies a Platform Model. 

The Computation Independent Model (CIM)
A computation independent model is a view of a system from the computation independent viewpoint. A CIM does not show details of the structure of systems. A CIM is sometimes called a domain model and a vocabulary that is familiar to the practitioners of the domain in question is used in its specification (OMG, 2003).

It is assumed that the primary user of the CIM is the domain practitioner or business consultant. The user of a CIM doesn’t have to have knowledge about the models or artifacts used to realize the construction of the application complying to the requirements defined in the CIM.

The CIM specifies the function (or external behavior) of a system without showing constructional details. The CIM plays an important role in bridging the gap between domain experts (or business experts) and experts of the design and construction of the system (or IT experts).

Platform Independent Model (PIM)
A platform independent model is a view of a system from the platform independent viewpoint. A PIM exhibits a specified degree of platform independence so as to be suitable for use with a number of different platforms of similar type (OMG, 2003).

A PIM describes the construction of a system on an ontological level, meaning that the construction of the system is specified without implementation details. The ontological model of a system is defined as:
Something is a system if and only if it has the next properties (Dietz & Hoogervorst, 2007):

  • Composition: a set of elements of some category (physical, biological, social, chemical etc.).
  • Environment: a set of elements of the same category. The composition and the environment are disjoint.
  • Production: the elements in the composition produce things (products or services) that are delivered to the elements in the environment.
  • Structure: a set of interaction bonds among the elements in the composition and between these and the elements in the environment.

An important characteristic is the category to which the elements of a system belong (physical, biological, social, chemical etc.). In the case of MDA we start with a model of an enterprise. By model translation it is tried to convert this model into a model of a software system.

Platform Specific Model (PSM)
A platform specific model is a view of a system from the platform specific viewpoint. A PSM combines the specifications in the PIM with the details that specify how that system uses a particular type of platform (OMG, 2003). In other words: the PSM is a more detailed version of a PIM. Platform specific elements are added. When defining a PSM a target Platform Model has to be available.

Platform Model
A platform model provides a set of technical concepts, representing the different kinds of parts that make up a platform and the services provided by that platform. It also provides, for use in a platform specific model, concepts representing the different kinds of elements to be used in specifying the use of the platform by an application (OMG, 2003).

Usage

Now the basic concepts are clear, the question is how MDA can be used to build a software system.

MDA basic process
In principle the building process starts with defining the Computation Independent Model or domain model. This CIM will be defined by a business analyst in cooperation with the business user. The CIM will be transformed into a Platform Independent Model by an Enterprise Architect. He adds his architectural knowledge to the CIM without showing the details of the used platform. The resulting PIM has to be targeted to a platform to complete the build process. Therefore a detailed model of the platform is needed. The transformation of a PIM to a PSM will be done by a platform specialist. The resulting PSM can be an implementation if it provides all the information needed to construct a system and to put it into operation. The described process is visualized in Figure 4 1.

MDA basic process

Figure 4 1 MDA basic process

In this process, in principle knowledge is added at each step by different professionals. The main challenge is the transformation between the different models. In traditional approaches these transformation are mostly very inefficient because no formal models are used. Without formal models it isn’t possible to define a formal transformation which can be (partly) automated.

MDA process for complex systems
In practice the process from CIM to PSM might be a lot more complex. Between the models gaps can exist not small enough to perform a direct transformation. In that case many interrelated models may consist on different layers of abstraction. Within this global set of models horizontal transformations may occur within a single layer of abstraction. By example, a PIM is transformed in a more detailed PIM several times. These horizontal transformations are an addition to the vertical transformation of models across the layers.

MDA process for a complex system

Figure 4 2 MDA process for a complex system

In Figure 4 2 such a complex process is shown. There isn’t a strict separation between the different layers anymore. A PIM, for example, is step by step enriched with platform specific information, at last resulting in a PSM. The PSM itself can be translated into more detailed PSM until the implementation level have been reached.

Conclusion

The basic concepts of Model Driven Architecture are explained in this article. However, even more question can come up while reading these concepts.

  • How exactly are models transformed into other models?
  • What different target platforms can be used (source code, virtual machines, etc.) and how?
  • What standards can or have to be used?
  • What are the business benefits of MDA?

In future posts I hope to address some of these topics!

New post: MDA and Model Transformation 

New post: Although the MDA acknowledge things like a richer modelling space than just the dichotomy between PIM and PSM and the automation of transformations between models, they stay far from defining a real engineering approach. Model-Driven Engineering is an enhancement in this direction.


————————————
Dietz, J. L., & Hoogervorst, J. A. (2007). Enterprise Ontology and Enterprise Architecture – how to let them evolve into effective complementary notions. GEAO Journal of Enterprise Architecture , Vol. 2 (Nr. 1).

OMG. (2003, 06 12). MDA Guide Version 1.0.1. Retrieved from Object Management Group: http://www.omg.org/mda

ORMSC, A. B. (2001, 07 09). Model Driven Architecture – A Technical Perspective. Retrieved from Object Management Group: http://www.omg.org/mda

Soley, R. (2000, 11 27). Model Driven Architecture. Retrieved from Object Management Group: http://www.omg.org/mda

8 Comments Added

Join Discussion
  1. Ajay S Solanki January 31, 2008 | Reply

    A very interesting read. I really like to understand the fact from fiction here. My knowledge on this area is limited. But I yet have to come to point to accept building reusable domain models. And more importantly these models are ready to use by the domain guys. A small change in the model will build the code on the fly and cut across all the areas of architectural and physical deployment issues.
    Im quite sure some educated decision would have to be made upto what extent can we look at automation of this entire thing.
    A couple of decades we did see the Application Generator which did create some raves at start but floped miserably.
    Im currently closing looking Microsoft’s offering in this space they call it DSL Tools have used it does a bit of automation but there;s a long voyage to be covered before we find that silver bullet to solve all problems.

  2. Johan den Haan February 4, 2008 | Reply

    >A very interesting read. I really like to understand the fact from fiction here.
    Thanks! In principle the description in this article just presents the MDA idea. Of course the key advantage is the automation of the model transformation. A lot of approaches can be chosen doing this. I’ll elaborate a bit more on that in my next post. But, please, don’t hesitate to share your practial experiences with this subject!
    > … does a bit of automation but there’s a long voyage to be covered before we find that silver bullet to solve all problems.
    Yes, the silver bullet we’re all dreaming about 😉 At Mendix I’m very busy with this subject. We’re far on our voyage, compared to others really far I think, but still a 10 percent of a standard business application has to be programmed by hand. However, the other 90 percent can be directly modeled and executed. See http://www.theenterprisearchitect.eu/archive/2007/09/01/from_software_engineering_to_b

  3. Michel Weststrate February 19, 2008 | Reply

    Hi,
    currently the Computer Science at Tu Delft is doing a lot of research in this area. Take a look at http://www.webdsl.org/webdslorg/home to see Domain Specific Languages at work. This application converts an easy to read text base model into a rich web application, just by parsing and rewriting the model. Without programming anything (although sometimes this is a disadvantage). But the general idea is there, and it is not just for webapplications applicable, but for any domain specific model.

  4. fasika biresaw October 17, 2010 | Reply

    im a student in ethiopia(addis abeba university) and i was looking for advises from you as i’m fresh man. please contact me

  5. Johan den Haan October 18, 2010 | Reply

    Hi Fasika,
    Have a look at this reference guide for more details and links: http://www.theenterprisearchitect.eu/archive/2009/01/15/mde—model-driven-engineering—-reference-guide
    Please let met know if you have any specific questions!

  6. rcd March 28, 2013 | Reply

    Tool that you use to apply the concepts of MDA?

  7. Pingback:

    […] MDA, basic concepts […]

  8. Raz March 26, 2014 | Reply

    Thank you, this post hits the spot when it comes to basic understanding of the model driven architecture.

Leave a Reply