While having a great number of followers, model-driven software development (MDSD) never became the mainstream development technique that graphical and CASE tool vendors at some point had hoped. While domain-specific languages are receiving a fair amount of attention, model-driven development has been relegated to somewhat of a niche, projects such as the Eclipse Modeling Project, notwithstanding.
In a recent blog post,
ModelDrivenSoftwareDevelopment, Martin Fowler describes the relationship between DSLs and model-driven development, characterizing MDSD as:
A style of software development that considers itself as an alternative to the traditional style of programming. The approach centers itself on building models of a software system. These models are typically made manifest through diagrammatic design notations - the UML is one option. The idea is that you use these diagrams, to specify your system to a modeling tool and then you generate code in a conventional programming language...
Most fans of MDSD base their enthusiasm on the basis that models are ipso facto a higher level abstraction than programming languages. I don't agree with that argument - sometimes graphical notations can be a better abstraction, but not always - it depends on the specific cases...
Instead of an abstract model, domain-specific languages, or code written in such languages, are often used for a similar purpose, as quasi software models:
Since MDSD hasn't caught on that much... you also see a different approach where modeling DSLs are used in the context of a traditional language environment. Here you might use several modeling DSLs that generate Java code to be combined in a Java project. In this case there's no general purpose MDSD model around - you use MDSD for each DSL relatively independently... DSLs exist in both the textual language and MDSD worlds and play pretty much the same role for both.
There is much that model-oriented DSLs share with textual DSLs. I put a lot of emphasis with textual DSLs in basing work around a Semantic Model. MDSD, as its name indicates, is very much about driving a system from that kind of a model. A difference is that most MDSD people assume that you'll want to generate code from that model rather than executing the model directly.
Artima spoke at last year's JavaOne conference with Daniel Brookshier, chief architect of NoMagic, a company selling tools for model-driven projects. In the interview, Brookshier shed some light on why model-driven development, including model-driven architecture, is not all that different from other forms of code generation techniques, including those that use a DSL as a source of code generation:
I think the key thing about MDA, Model Driven Architecture, is the model represents the code, and the code is produced. It's generated. So I model all of my entities. I say what's going to be the business objects in my system, and the model is annotated, and then code is produced from that model. I don't really have a disconnect between the code and model, because the model always generates the code.
In the case of things like Spring and Hibernate, I can go from a model to Spring and Hibernate and out to the web tier with Struts, and I've done all that with just model. There's maybe a few places where I put in a little bit of code, but it's minor. It's glue code. Very little has to be done in that teir. Most of the code is in the model. Press a button, produce it every time. So I'm only editing the model. I don't edit code.
In his blog post, however, Fowler points out that using a non-textual model, unlike code written in a DSL, requires significant tools support, such as repositories:
In order to use model-oriented DSLs you need a different, RepositoryBasedCode, approach to tooling. This introduces quite a few pragmatic issues as the general support environment for such tools is less established. In order to define your own DSLs you need more specialized tooling - something I call a Language Workbench.
And in reply to Fowler's post, Sven Efftinge noted that code generation is not the only way to benefit from model-driven development: instead of generating code, a model can be directly executed:
Basically, MDSD is about:
Defining domain-specific abstraction (no matter how) and
make them executable (no matter how).
MDSD is only about using DSLs, interpreters and code generators and integrate them in your project. To be a good software developer you need to have much more than this in your mental tool box...
Also have met people (mostly with a CASE or MDA background) who haven't yet understood that models are just information like code is information and DSLs are just about specifying information in an abstract, concise, intentional and non-redundant manner. Models are code!
What do you think about model-driven development? What role, if any, do you think it should play in a software project?
Well, a model is an abstraction of something that leaves out details in order to make it easier to manipulate and perform "what if?" experiments. Code must necessarily include everything required to implement a system.
The fact that MDA tries to equate the two is the fundamental flaw. A DSL, on the other hand, tries to be a higher-level language in order to produce results more efficiently. It solves the problem differently.
Over time, I've seen numerous approaches to "making pictures into code," all with the same fatal misconception: that pictures are always a better way to express things than code. This usually shows up when you need to represent a loop or some other such basic but necessary mechanism.
Does this mean it's impossible to create a picture-based programming system? Not at all. But such a system will need to be designed by someone -- a computer scientist, probably -- who understands language creation, not by the opportunists that we've seen so far (hey, everyone likes UML! Let's hack it into a programming language!). And it will almost certainly need to be a hybrid of text and pictures, to take advantage of what each does best.
I believe there have been papers on program creation with graphical languages; the fact that, after all this time, we haven't seen anything particularly usable suggests to me that the problem is a lot harder than the sales types would like it to be.
Better abstractions in programming will continue to appear; they are fundamental to our progress and increasing productivity. We may even find a use for pictures in our programming, but I doubt it will be the quick and dirty approaches that we've seen so far. My best experience in language productivity has been some of the more recent features in Python, such as list comprehensions and other changes that can seem small, but greatly improve the results as you learn to use them.
I think that picture support needs to be something that first appears as a small, helpful tool that adds to your text-based programming experience, not this "drop all that text-based stuff and come over to this world we've created where everything is pictures" approach. Maybe someone can take a language and add one small feature where pictures are very useful (you could argue that GUI designers are one such example, but there's no abstraction there) and once we become convinced, add more such features.
In the meantime I remain unconvinced that I want to throw everything away and jump into a nothing-but-pictures way of programming. Certainly not something based on UML, which just wasn't designed for it.
Well, I think it would be more accurate to say that platform independent models can be translated automatically into a platform specific model. A platform specific model is code, while a platform specific model is traditionally what we think of as a model.
> Well, a model is an abstraction of something that leaves > out details in order to make it easier to manipulate and > perform "what if?" experiments.
Sounds good. Kind of like a prototype, or code written using a DSL or dynamic language. Sometimes good enough to be released, but usually not production strength.
> Code must necessarily > include everything required to implement a system.
Well leaving out details and leaving out neccessary parts are two different things. Many scripting languages leave out useful things like types, but these are not required to implement a system.
The missing parts can always be modeled independently and merged using AOP (or some other metaprogramming technique).
> The fact that MDA tries to equate the two is the > fundamental flaw.
If done in a simplistic code equals model manner, I agree.
I think the secret to successful MDA is to keep an abstract and incomplete model of the high-level functioning of the system, along with more detailed implementation level models and transformation rules (again more models), to create full systems.
> Over time, I've seen numerous approaches to "making > pictures into code,"
Models are not neccessarily pictures. This is the traditional approach to modeling, but some people (myself) working on alternatives (see http://www.heron-language.com). Pictures are just a popular representation of models, but they aren't the only one. Human Usable Textual Notation (HUTN), Xml Model Interchange Format (XMI), and Heron are all textual representations of models.
> I think that picture support needs to be something that > first appears as a small, helpful tool that adds to your > text-based programming experience, not this "drop all that > text-based stuff and come over to this world we've created > where everything is pictures" approach.
I agree. With Heron I am trying to mix the two approaches.
> Maybe someone can > take a language and add one small feature where pictures > are very useful (you could argue that GUI designers are > one such example, but there's no abstraction there) and > once we become convinced, add more such features.
Agree, I am also striving to do that with Heron.
> In the meantime I remain unconvinced that I want to throw > everything away and jump into a nothing-but-pictures way > of programming.
Completely agree.
> Certainly not something based on UML, > which just wasn't designed for it.
Well I believe there is still hope for UML, or at least a constrained subset of it.
Yep. Last Tuesday I built a toy Python interpreter to trace stack operations for debugging bytecode hacks in generator_tools. This model is realistic in one single aspect and abstracts from all others. That the original interpreter is written in C doesn't matter. It could also be a toy interpreter that simulates an aspect of PyPy for better understanding.
This describes roughly the essence of models: you want to isolate a single property of a complex system or a small group of interrelated properties that shall be studied in high accuracy and neglect the rest. It's both abstraction and precision that matters.
MDA is about something entirely different. It stems from the desire to close the cartoon/code mismatch. While everyone agrees that there are some interesting mismatches in programming e.g. objects/relations, some are much less relevant like the one between cartoons and code and MDA aims to close it.
It think there are several reasons why graphical programming hasn't made it in is unlikely to make it in the future:
1. The wankel engine effect: Despite its benefits, the wankel engine never made it to wide adoption. The most important reason for that is that there was so much research done in traditional engine design, the new design simply couldn't catch up with that. Graphical languages suffer from the same problem. There are so many tools and technologies around textual languages (configuration management, refactoring tools, static analyzers to name just a few) that it's close to impossible for a different approach to catch up.
2. The level of complexity in nowadays software. Nobody wants to mess around with some square kilometers of UML or what ever diagrams.
Compare that to integrated circuit design: It's easy read and understand the diagram of an Intel 4004 with around 2300 transistors for an electrical engineer. Things are different with a Pentium 4 with more than 42 million transistors.
That said, I think that UML diagrams are extremely useful as kind of meta-language for communication among programmers. That is the way they are successfully used now and probably will be in the future.
> If you drop picture-based models and ignore tooling for a > moment, what difference, if any is there between MDA and > traditional OOD?
Model-driven architecture is equivalent to Object-Oriented Analysis.
A lot of the best ideas for the future of software engineering have roots in model-driven architecture. For instance, Real-time Object-Oriented Modeling (ROOM) was far ahead of its time. Unfortunately, it was proprietary and required training to use.
Don't listen to Bruce's flame that picture-based programming systems were created by the "opportunists that we've seen so far (hey, everyone likes UML! Let's hack it into a programming language!)" ROOM came even before UML. Before ROOM, the first picture-based programming systems were the earliest prototypes for CASE tools, and they were written in AutoCAD and AutoLisp.
Previous Topic
