The Model Driven Software Network

Raise your level of abstraction

It seems to me that the Agile MDD terminology is well accepted by practitioners.

My today's question: How to make MDD more agile ?

Reply to This

Replies to This Discussion

How about getting the message across that you shouldn't spend ages perfecting a DSL before releasing it to users, instead you should build it incrementally and refine it in the light of feedback, trying to deliver value along the way?

Reply to This

This is related to one of the concerns I raised in my latest post in my blog: If a language is incrementally built, can we be productive using it if it is changing all the time? I guess not, because rapid change is what would happen with internal DSLs. Unless, of course, if the language's release cycle is very long.

Reply to This

In our experience the DSL (or MetaModel) must be able to change over time. The evolution of the software products built on the DSL require you to change it. Its how you deal with the incremental additions, the process you put around managing the changes. So I would add to Mark's point making sure your processes make it easy to change rather than hard.

You will also find that sometimes the iterations with the DSL are short and quick, with fairly minor evolution, other times the cycle may be very long depending on the extent of the change and whats required to stablise it.

Reply to This

I don't recommend to change the UML metamodel because we have spent years and years to make it stable, powerful and still compatible with the latest OMG specifications. The same UML model (e.g. EclipseUML2) is used by many tools (e.g. Rational, Borland, EclipseUML2, Topcased, Papyrus, ObjectEering, Omondo etc....) and compatibility is now a reality.
We have also experienced a very difficult upgrade from UML 1.5 to UML 2. Many users still don't understand UML2 and prefer to model with UML 1.x. If there is another upgrade I am afraid it could be the end of UML !!
I think that agile should not be applied at this infrastructure UML model layers. We need to build advanced features on the top of standardized language and not to change the standard.

Concerning DSL and other MDD uses I don't really know what is the best approach because I don't use them.

Reply to This

I fully agree with Michael on the metamodel evolution: it is just a fact of life. Once the language is used we normally need to tackle the evolution of models too. In the worst case (and tool) the models made with the older version don’t open anymore and in the best case (and tool) the models update and always work with the newer language version too.

We have experiences on both sides since in the first versions of MetaEdit (back in early 90’s and not a tool called MetaEdit+) you could change the metamodel but the older models would not always work. To support agility, although that term was not used then, we implemented a totally new tool (MetaEdit+), which guarantees that models made with the older language version will always open and work if the metamodel changes. This was simply a necessity for industrial use since companies don’t want to start creating DSL if they are unsure what happens to models made in the longer run. The model/metamodel update policies are included in the tool and thus do not require extra effort to use from language developers (metamodelers). If someone want to try this type of agility there is an evaluation version available at http://www.metacase.com/download

Reply to This

RSS

Badge

Loading…

© 2010   Created by Mark Dalgarno on Ning.   Create a Ning Network!

Badges  |  Report an Issue  |  Privacy  |  Terms of Service