currently I'm researching the "Model Driven" approaches to software development. Yesterday I discovered some groups on xing discussing model driven architecture and model driven design. After browsing through some of the entries I discovered that the common understanding of model driven approaches seams to be "generate code from some diagram" or "introduce a new domain programming language". In my eyes this boils down to using a new programming language. And yes, I consider diagrams that generate code as yet another programming language.
I usually don't rely on forum discussions as primary source of information, so I wanted to find out more. If you do a google search on "model driven" you get the wikipedia page on model driven architecture and the usual suspects: information from companies that want to sell you their brand new model driven tools. As MDA seems to be a major topic on OO conferences you'll probably agree with me that this may be mostly due to some big bucks behind the movement.
But the concepts behind MDA are not really new. The wiki-page sums up the central statement of the model driven approach as:
One of the main aims of the MDA is to separate design from architecture and realization technologies (...)
This is old stuff. And I don't yet see how using UML models as programming language will solve any issues. The domain language approach is interesting, though. But let me explain my view on this whole architecture thing...
Separating the design from architecture and realization technologies is one of the main concerns of good software design for some time now. Eric Evans for example proposes the "Domain Driven Design" concept, which basically means to take the programming language of your choice (state of the art: object oriented) and create a set of objects with which you can build up a domain language that still follows the implementation rules of the underlying language.
The bad thing is that even on the domain level you are still dependent on the underlying language. But I know from experience that you can even code 95% of your C++ project in a technology agnostic way. This is the real challenge of software architecture: build or buy a technology layer that hides your underlying hardware architecture away and create an easy to access domain layer that nonetheless captures your domain logic.
The good thing about not introducing a new language, be it an UML model or a new domain language, is that, well, you don't need a new language... The key question is: why is UML or a new domain language better suited to the task of describing a domain logic than <pick your favorite OO language>?
Let's consider the options: What about using UML as a programming language? One of the first comments in the xing forum about MDA I found was about "hey, our programmers don't like the clumsy way to express all the complex logic in a UML diagram - can I create one by using a textual description? this would especially make diffing much easier...". This says a lot.
When I wanted to learn UML, I asked my colleges if anybody knew a good introduction into the topic. Andreas than got me some UML reference and handbooks. 1500 pages explaining how to use UML. But that wasn't what I was looking for. I was looking for an explanation of how to use UML in a way that it's actually generating business value. I didn't read those manuals but found "Domain Driven Design" by Eric Evans. Now this is technically not really about UML, but it introduces some very interesting practices regarding it's use.
Eric Evans states that a diagram should be used to communicate a concept. He argues that trying to stuff all the information into a diagram tends to render them useless. This exactly matches my experience. And this is why I don't think UML diagrams (or any graphical representation, for that matter) is a good choice as a programming language.
Now for the domain language. A domain language is a new programming language that enables you to write domain logic in a way that matches the way rules are usually expressed in the problem domain. In my opinion this is often a very good idea. It is used widely since a long time now (perl and the posix shell language started as domain languages) and there are myriads of calculator sized scripting interpreters used in commercial applications. You can probably think of some more...
But there is also some choice with regards to general purpose languages. When implementing a domain language (like php, which was originally developed to be used for dynamic web services) often the feature requests make the language a general purpose language over time (perl, php, bash, just to name a few). At that moment you have a new general purpose language on the market and have to ask yourself if it wouldn't have been easier to use an already stable language in the first place.
At the time of this writing, there are many general purpose languages that target different domain audiences. There are the functional programming languages that express mathematical concepts (while high performance maths is still done in fortran), the logic programming languages that target, well, logics and a bunch of object oriented languages that target web server development, web client scripting, web browser extensibility or just try to provide fine building blocks for object oriented domain frameworks and domain design (like java and C#).
So what should you do if you are an architect. My advice is to look for a nice general purpose language first. If your choice is one of those diagram compilers, than fine. Just make sure programming in this language fits your needs. If you find a framework for your chosen language that makes developing the domain logic easier, use it. Mind that I don't argue against using UML diagram compilers or frameworks or your own little language that you always wanted to implement. But I don't believe UML diagram compilers really enhance your productivity in all but a small limited set of applications. The same goes for elaborate frameworks or the use of awkward domain language wannabes like Gupta.
Most of your domain language needs can be met by today's general purpose languages.
The art is to use the language concepts to implicitly express your domain language. This can be done with every general purpose programming language I know (even with perl - which was built as domain language for string manipulation and "grew" into a full-fledged swiss army knife object oriented programming language and - in my opinion - often into a maintenance nightmare).
So what remains of the "model driven" hype? If you take away the fuss about expensive programming tools you get what Eric Evans calls "Domain Driven Design": Use diagrams that really enhance understanding. Use diagrams only to show few concepts at a time. Use your design skills to make your general purpose programming language feel like a domain language. And finally introduce a new domain language where it really makes sense. Most of all, come down from your ivory tower and get your hands dirty on the project.
... "He argues that trying to stuff all the information into a diagram tends to render them useless..."
ReplyDeleteWhy? If you look at a graphical representation of the mandlebrot set, you aren't really looking at the entire set. There is the issue of resolution. I say your language needs to embed as much information as possible then your viewer/editor needs to be able to select what resolution you wish to view the information.
Of course most of these can be implemented using O-O. However, O-O itself doesn't necessarily provide reflection and introspection. Every application has a similar pattern, database column mapping, data validation, posting rules. Sometimes, these rules leak from the db abstraction layer into the gui layer.
ReplyDeleteThis is why having a separate language can be so attractive.
Of course, data dictionaries have been around for a long time, and serve this purpose in many production applications.
MDA is nothing but new name for a very old idea.