I am starting now a series of posts on the Model Driven Software Development (MDSD) approach. The reason is that I strongly believe it is a very powerful approach and I will invest time and efforts in 2009 in this direction. There are already tools that are following this approach and probably one of the most compelling success stories is the ORM tools. There are also things going on in the industry and for instance Microsoft is planning to follow the model driven path with its OSLO platform and the M language, so I will also be talking about this.
The first post of the series is a quick overview of the MDSD approach. The objective here is not to do a full presentation of this software development paradigm but introduce the subject, key terms and overall principles. I will in further posts analyze and foresee what benefits could bring MDSD to the software industry and what place this might have in the future.
Part 1: Toward generative programming? The case for Model Driven Software Development: A quick overview of the MDSD approach
Part 2: The case for Model Driven Software Development - Developing high quality, well designed software applications is hard and expensive – MDSD can help!
MDA versus MDSD
In order to briefly explain what the model driven approach is, it is interesting to start explaining what the Model Driven Architecture (MDA) approach is and how it differs with a more permissive and flexible MDSD (Model Driven Software Development) approach.
The MDA approach is an initiative of the Object Management Group (OMG), and is a natural evolution after the introduction of the UML language and its relatively wide adoption on the market. The MDA approach aims at providing a generic, model oriented, tools friendly language that could be used to automate the generation of software applications through the creation of platform independent models and diagrams. This generative implementation is supposed to be done through MDA tools, able to parse the platform independent MDA model and generate code and artifacts for the targeted platform.
One primary objective of the MDA approach is the platform independence and a universal generic language to describe systems, the same way UML was designed to be generic enough to be usable to describe the different architectural views of a software system, and even potentially apply beyond software systems.
While this generic MDA approach has the definite benefit of the universality of a language that anyone, and any tool could understand and exploit, it also has its drawbacks. The main drawback being that a too generic and universal language can be too much abstracted from the real system and its specificities. Extensions of the UML language such as stereotypes were invented to solve this problem but make the whole exercise of precisely diagramming a system very difficult to achieve. And the precision and level of details required for a generative approach is of crucial importance, much more than for creating diagrams for the sole purpose of communication and documentation.
I personally am a big believer of more pragmatic approaches that aim at giving a clearer, less abstracted vision, but closer to the reality of the system. After all, the primary objective is to build systems that work and is not to have a generic description of systems for just the sake of purity. This is for me the reason why the MDA approach was not as successful and broadly used as expected and the driving force why a more permissive and flexible MDSD approach has a much better chance to succeed and convince the community and the market.
From now on, we will talk about the Model Driven Software Development (MDSD) approach as a generic term that applies to any solution, tools or processes that follow the model driven concept of modeling an application for the purpose of automating its implementation. The MDA approach in this perspective is a MDSD approach that has the specificity of being tightly coupled to, and constrained by the UML language.
So the generic MDSD approach we describe here differs from the MDA approach in that there is not such a thing as a ready to use, generic MDSD approach and associated languages that you can use out of the box on your projects. The MDSD approach is more of a concept, a guidance and new way/philosophy to see software development. So where there is only one MDA standardized set of languages, there are not only one but as many different MDSD tools and processes as vendors or individuals will invest on creating.
Domain Specific Languages (DSL) and MDSD
Let's now have a word on the Domain Specific Language (DSL) terminology. The DSL acronym is often misleadingly used for describing a full model driven approach. However a domain specific language is not really a model driven approach on its own but only a part of a full MDSD approach. The MDSD approach is more than just languages, it is a full set of languages (and more specifically DSLs), tools, runtime frameworks, code generators and/or language interpreters (more on compiled versus interpreted DSL later), on potentially more.
Therefore DSLs are a major part of (and only a part of) the model driven approach. A DSL is an abstracted language that aims at describing a system or part of a system that we want to model in the most convenient and natural way for the targeted domain. A DSL can take any form as best suited for the targeted domain, can be textual, graphical or both or even take another exotic form.
A DSL can be architecture oriented of functional oriented. An architecture oriented DSL aims at describing technical layers or architecture centric components and services of your application. A very common example of an architecture oriented DSL are the Object Relational Mapping tools (see the description of Llblgen for an example of such a tool). An architecture oriented DSL can be used horizontally across different functional domains. A functional DSL is a DSL that is explicitly dedicated for a given functional domain and an example can be FpML, used to model financial instruments. Functional DSLs provide business analysts with a proper abstraction level to describe their very specific domain that can then translate to code (the dream of having analysts or business specialists designing applications with no more need for developers...), or more realistically functional DSLs provide developers with a language that can help then translate functional models to applications and code.
And finally DSLs can be interpreted or compiled. A model written in an interpreted DSL is used "as is" in the real production application, hosted by a runtime (interpreter) able to understand the model and execute operations. In my very basic understanding the M Language (Microsoft OSLO) can partly be used as such an interpreted DSL (more on OSLO on a later post). On the other hand, for compiled DSL, a model has to go through a compilation phase for transformation of the model to a lower level language, such as C# for the Microsoft platform. An example of such a compiled DSL again is the Llblgen ORM tool. It is pretty clear that compiled and interpreted DSL are very different in nature and imply very different constraints.
In the model driven approach, the DSL or set of DSLs is the way to describe the model of the application you are aiming at implementing. Defining the model of your application is the first step in the model driven approach, followed by the generation activity, or interpretation of the model (more later on compiled versus interpreted DSLs).
Generators and Interpreters
The second brick of the model driven approach is the generator(s) and/or interpreter(s). The generators responsibility is to generate from the model anything you need for your specific domain. Artifacts that are useful to be generated range from code to configuration files though user manual, or anything you might dream of automating. Generation can be based on text templates that are useful to customize or extend the content of the generation. On the other hand, interpreters don't generate anything but rather interpret at runtime the models to deliver the required application functionality. A model driven approach can make use of a runtime framework. The final application will then use at runtime the support libraries that make up the framework. This is especially true and mandatory for the interpreted approach but also true for the generative approach. It indeed often proves useful to generate code and classes that are depending and built on top of a well designed and fully featured framework rather than generate the full application code base. This runtime support framework is the third brick of the MDSD approach.
The fourth brick on a full MDSD approach would be the SDK that allows users of the DSL and generators/interpreters to extend or automate the DSL and generators/interpreters, from instantiation of a model to generation of the application, through integration with other DSLs. I will in a later post talk about DSLs composition and DSL integration with other approaches and tools, to bring the model driven approach even further.
That's enough for this quick introduction. Hope it was clear enough, and I will enter in more details in further posts. I will talk more in next posts on the motivations behind the model driven approach and why MDSD is good for you!
And here are a few links to resources related to the model driven approach:
MDA web site: http://www.omg.org/mda/
Microsoft OSLO web site: http://www.microsoft.com/soa/products/oslo.aspx
Podcasts related to the model driven approach:
Software Engineering radio shows on MDSD
Software Engineering radio shows on DSLs
Recent Comments