5 types of Model Driven Software Development

Model Driven Software Development is getting momentum. Is Model-Driven the future of software development? Or is it the same old wine in a new bottle? I’m not going to answer this question right now. I’ll first show you the different types of model driven software development using a simple metaphor: farming.

Programming – the manual work

FarmerDoing all the farming by hand, it’s a craft, an art. You love it, or you don’t. Everything will become as you want it to be, on your time.

In software development programming can be seen as manually creating a low level model of an application. That low level model (implementation model) is compiled to an executable or interpreted on a virtual machine.

As with tools for farming you have tools and frameworks making the job easier, but it stays handiwork. I won’t define programming as model driven software development. I just mention it to sketch the starting point.

Code generation – automation

AutomationNowadays lots of work on a farm can be automated. You have to learn how to use the machines doing the work for you, but once you have, all manual task are ‘generated’ automatically.

In software development the manual work can also be automated. Instead of writing code you can create models. These models are transformed into source code. You, of course, have to learn how to model, but once you have, all the manual work of writing code is automated. This means a whole shift in application development roles.

An early, well-known example of code generation is the generation of corresponding source code for graphical user interfaces in Integrated Development Environments. Nowadays a lot of tools exist, generating full applications based on templates.

MDA – abstraction

In the previous approach we needed a specialized machine for each task. That involves a lot of learning about how to configure and operate those machines. In case of milking we have to attach the machine to each cow by hand. Can’t this be automated by stepping one abstraction level higher? We just model how to attach the machine and the next part of our job is automated!

In a very basic way that’s what Model Driven Architecture (MDA) is for software development. Instead of just generating code from a model, you can construct platform independent and platform dependent models. The platform independent model is transformed into a platform dependent model using model transformations. From the platform dependent model the source code is generated.

If you specify the needed functionality in a platform independent model, you can transform this functionality into models for different platforms. So, the MDA is mainly aimed at technical variability.

DSL – specializing

Farms have changed a lot over time. Started as a means for farmers to grow their own food, the focus has now changed to financial gain. That, in combination with, among others, the industrialization and growing complexity of a farm led to more specialized farms. This means that consumer products are mostly composed of materials from different farms. Examples of specialized farms are dairy farms, orchards, vineyards, stud farms, plantations, poultry farms, etc.

In software development a same movement can be seen. A lot of people argue that the UML, the language used to define the models in the MDA, is too complex. Instead of using UML the use of Domain-Specific Languages (DSLs) is promoted for model driven software development. DSLs are small languages tailored to a specific domain (a system aspect or a certain problem domain). An application isn’t modeled with a single, monolithic model specified in one language, but with multiple small models specified with different DSLs. DSLs can vary in structure, variability, and notation. Most DSL approaches contain a direct translation between DSLs and their execution by using code generation or the direct interpretation of the DSLs.

MDE – from problem to solution

We can talk a lot about farming and how to automate and specialize it more, however, the real leap in productivity is in alignment. The production of raw materials need to be aligned with consumer needs. We see this happen with big companies targeting consumer needs (or manipulating them 😉 ) with advertising campaigns. All production is aligned to deliver consumer products composed of multiple materials maybe coming from different farms. The focus is not on the farm and how to improve it, the focus has become consumer-centric.

In model driven software development the same can be done. In the approaches mentioned before the target was to model the application at a higher abstraction level than a programming language. We can, however, go one step further. We can also create models of the using system, i.e. creating models of the organization which is going to use the software. Once we have modeled the so-called problem domain, we can make translations to a model of the solution domain. These translations or transformations don’t necessarily have to be automated, in some cases that’s not even possible. However, they need to be supported by appropriate tools and methodologies.

This Model-Driven Engineering approach differs from other approaches because we can distinct between horizontal and vertical transformations. Horizontal transformations from problem to solution domain, and vertical transformations from solution domain models to executable models. We’ve seen in previous articles on Model-Driven SOA that such approaches are possible. However, the challenges of MDE are in appropriate tooling, methodologies, patterns, templates, reference architectures, and industry standards.

In short: MDE focuses on the problem domain, it is (or should be) business-centric.


A lot more can be said about the different approaches and how they compare to each other (and yes, I think I’ll do that in the future), but for now you have a quick overview of these 5 approaches. What are your experiences with these approaches? What approach do you prefer and why?


Photos by cresk, Airborne Guy, Flint-Hill, DocBuddie, Farl.

9 Comments Added

Join Discussion
  1. Gert van Duinen April 1, 2009 | Reply

    Oi,
    This permalink has been added to the description of my photograph (see url). Thanks for featuring it.
    Mvg,
    Gert van Duinen
    cresk design
    http://www.cresk.nl

  2. Patrick April 2, 2009 | Reply

    Hi Johan, In my experience the boundaries aren’t that obvious. My goal is to no do the manual coding anymore, so that option is out. As for the other options, I am on a journey from DSL/DSM to MDE via MDA. We have done abstraction, an OO constraint and an OO implementation model and made it executable. Not really rocket science at this stage. But ultimately what matters to me is to be able to define a model that captures requirements from different disciplines shares and combines requirements plus knowledge in a model that is implementable and executable. It gets complicated when you try to find a “common” model between users of different disciplines, who need to collaborate to build something… Try to share a common model, notation, or ontology between a process designer, a network engineer and a systems architect. Even more tricky if you get into versioning and interfaces, which are quite foreign concepts to non software engineers.
    This collaboration aspect is not trivial, but this is where one of the biggest potentials of modelling lies imho. If we can effectively bridge this gap between domain experts we will drastically reduce the cost and speed of many design activities. I am still figuring out how to make this work and any suggestions will be very welcome.

  3. An MDA tool is a tool used to develop, interpret, compare, align, measure, verify, transform, etc. models or metamodels. Some MDA tools are as follows:
    * Creation Tool: A tool used to elicit initial models and/or edit derived models.
    * Analysis Tool: A tool used to check models for completeness, inconsistencies, or error and warning conditions. Also used to calculate metrics for the model.
    * Transformation Tool: A tool used to transform models into other models or into code and documentation.
    * Composition Tool: A tool used to compose (i.e. to merge according to a given composition semantics) several source models, preferably conforming to the same metamodel.
    * Test Tool: A tool used to “test” models as described in Model-based testing.
    * Simulation Tool: A tool used to simulate the execution of a system represented by a given model. This is related to the subject of model execution.
    * Metadata Management Tool: A tool intended to handle the general relations between different models, including the metadata on each model (e.g. author, date of creation or modification, method of creation (which tool? which transformation? etc.)) and the mutual relations between these models (i.e. one metamodel is a version of another one, one model has been derived from another one by a transformation, etc.)
    * Reverse Engineering Tool: A tool intended to transform particular legacy or information artifact portfolios into full-fledged models.

  4. Johan den Haan April 2, 2009 | Reply

    Hi Patrick,
    > But ultimately what matters to me is to be able to define a model that captures requirements from different disciplines shares and combines requirements plus knowledge in a model that is implementable and executable. It gets complicated when you try to find a “common” model between users of different disciplines, who need to collaborate to build something… Try to share a common model, notation, or ontology between a process designer, a network engineer and a systems architect.
    That’s why we need small tailored languages (DSLs) targeted at specific domains or system aspects. They key challenge is to synthesize multiple models specified in different DSLs.
    If the gap between the different ‘modelers’ is to big you can consider using multiple views on the same model, i.e. a different concrete syntax for different roles.
    In my experience it is possible to define multiple models with different DSLs covering the full spectrum from the using system (the organization) to the ICT system. However, it is very difficult to define what roles should define what models. So, tools need to be flexible on this point (with different views, etc.).
    > … Even more tricky if you get into versioning and interfaces, which are quite foreign concepts to non software engineers
    Yup, that’s quite formal. I think the role of a system architect won’t disappear soon… 😉

  5. Patrick April 2, 2009 | Reply

    In deed multiple views / DSLs is the technique that comes to mind, and which we tried. Yet remains to be worked out how very different conceptualizations in each discipline can feed into a single core model. It looks like lots of fun ahead of us.

  6. James Taylor April 9, 2009 | Reply

    I think that too many MDx approaches neglect the need to move to a declarative approach. As long as code is getting written I think we remain limited to the past. We must be able to specify the behavior the business wants and needs not program it. This means using BPM tools to declare our workflow, BRM tools to declare our business logic or rules, BI tools to declare reporting etc. DSLs are good, as long as they are declarative, and models are good, as long as they stay declarative (http://jtonedm.com/tag/declarative/).

  7. Haitham El-Ghareeb April 20, 2009 | Reply

    Many Thanks to this amazing post. I have been attempting for a while now to learn about MDA, and I have hesitated a lot till I found this blog. I started with this entry, and waiting for more posts. Again, Thank You

  8. ogbise, wodidei May 21, 2010 | Reply

    i will be please be a updated everytime

  9. Testking 640-816 August 5, 2011 | Reply

    This is great. We will show this to the class. Good job.

Leave a Reply