New Thoughts On Not So Random Things…

17Jun/109

Trends in model driven development (cont’d)

After spending 2 days (one more to go) at Code Generation 2010 I feel it's time to add something to the trends I perceived earlier. I'll prepare a third installment on this based on the comments I received at the Model Driven Software Network later.

The first observation I had was concerning language workbenches becoming more and more of a buzz. During the Code Generation conference we actually started planning a Language Workbench Competition, which will likely be co-located with the conference next year. Based on input from Eelco Visser, Markus Völter, Jos Warmer, Pedro Molina, Karsten Thoms, Bernhard Merkle and others we are defining a case right now - to be resolved by different parties (suppliers as well as users of current workbenches). If workbenches weren't a buzz already it is now, with MetaEdit+, MPS, XText, Essential, CodeFluent, Concrete and others being presented and the workshop in the making.

Second, the integration between graphical and textual DSLs, and combination of different DSLs as part of one solution is also taking place. With MPS, integration between DSLs and programming language is available in a reasonably easy way as well now. Reasonably easy hear means that the tree based concept underlying MPS requires some 'getting-used-to'. It's too bad that the integraion of graphical and textual , as attempted in e.g. Papyrus was not presented at the conference this year. Next year will hopefully show more.

Then, I mentioned the 'multiple views on the same content', also known as projectional modeling or projectional editing. This seems to be mainly a case for the secretive folks at Intentional, but MPS is getting closer and closer to that. Also, at least one solution combining GMF and XText to show the same models exists (I'll provide a link later, if it's a public project). A nice new kid on the block here is Concrete, a web based solution developed at Lear Corporation.

Finally I listed the models@run-time concept seems to be something people are really enthousiastic about, although many haven't heard about it yet. Also, not many solutions are available. In a discussion with Johan den Haan and Steven Kelly, we concluded that in e.g. web or cloud based projects the technical limitations of that environment might get in the way, in relation to performance, usability as well as reliability.

On top of these trends that seem to be at least partially confirmed during the conference, I have to add the following:

First of all, there is still a large community that is not working on DSL based solutions, but has produced more and less successful solutions based on (executable) UML. Although DSL and DSM advocates may deny the feasibility of such solutions, the fact that some of them are succesful cannot be ignored.

Then, adoption of model driven approaches is still very much an issue. It seems to be something that depends on the market in which one is active how easy or difficult it is to get MDSD trials and project started. One discussino led to the conclusion that in markets where (software) engineers are working in closer cooperation with end users (e.g. in insurance and banking domains) the adoption of solutions based on domain modeling and domain specific languages is easier to achieve than in high tech environments, where developers tend to be more technology oriented and hardly ever meet with a customer or end user. This based on differences in aspects like developer focus, customer communication and organisational structures. Tomorrow's workshop discussion around Spring Roo may shed more light on this, if so I'll get back to it.

All in all, the presentations at CG2010 and the discussions I had during the breaks and in the evenings seem to confirm some of my observations, but also lead to new ones.

To be continued....

Comments (9) Trackbacks (1)
  1. Given the number of people using UML, at least SOME of them are going to be successful ;-) . Nobody would deny that there are some successful cases of significant code generation from models called UML – but in the cases I’ve seen, it wasn’t standard UML anymore. I’m sure you’ve all seen tools that are sold as “MDA” or “executable UML”, but actually existed before UML was created. Changing the symbols and calling it UML is an obvious and sensible marketing move for them.

    I think the Raytheon case is revealing: DSLs for variability layered on top of “executable UML”/”MDA” for the lower-level stuff. If I’ve understood right, the UML is used to create an in-house domain-specific framework, the DSLs generate code that uses it.

  2. Thanks for the report, really wish I could be there.

    we concluded that in e.g. web or cloud based projects the technical limitations of that environment might get in the way, in relation to performance, usability as well as reliability.

    Could you please clarify?

  3. Hello Rafael, sure I can try to clarify. If you want to do models@run-time in the way we discussed over here, at some point you have to make changes to models inside the system. In a web or cloud based application, that will likely come down to making these changes in a web browser. This has a negative impact on performance because things will be going back and forth between client and server), on usability because HTML and Javascript based user interfaces for this purpose in web browsers are complicated to make very user friendly, and on reliability once again because of the distributed nature of the systems: how to make this work flawlessly in a client-server/cloud environmnent where you cannot see what other users are doing while you change their underlying models.

  4. Thanks for clarifying, Angelo.

    Don’t the very same challenges exist for conventional (non-model-driven) applications running on the cloud?

    Also, running on the cloud doesn’t require developing on the cloud.

  5. Or maybe I am just misinterpreting what you mean by “models at runtime”. My understanding is that it basically means running straight from (executable) models, instead of transforming models into executable code and then running that code.

  6. That’s more or less it – models@run-time is about bringing the advantages of the models you have at development time into the run-time environment and use them to make changes without having to go through a new development cycle.

  7. I think your definition is more strict than mine – for me, having models at runtime does not imply those models are the artifacts modelers manipulate directly (that would be a possible scenario though). My definition includes also running models that are produced via some transformation.

    It seems your concern essentially applies to any interpreted languages. Most code driving web/cloud applications is in an interpreted languages such as Perl, PHP, Python and Ruby. It is something people haven been doing for ages, so I can’t seen what new challenges executable models would bring.

    Cheers.

  8. First of all, it’s not my definition – it’s one that’s been around for a few years. Second – as with programming and MDD, the difference in the level of abstraction. Check here for more info: http://www.comp.lancs.ac.uk/~bencomo/MRT10/, or check out the IEEE Computer issue of October 2009.

  9. For sure Model@Run-time needs a precise definition. However, there two thinking directions : one is, as Rafael point out, dynamic interpretation of model. The other one is using model to generate at run-time interpretable code. The first one, seems to lead to Yet Another Script Language or to another meta programming tool. Following that point of view, there is no new challenges in executable models!
    My opinion follow Angelo’s point of view which is to bring the advantages of models at development time into the run-time! Raising abstraction level is important when systems (web/cloud) have a high level of variability.
    It can potentially considerably reduce the software maintenance time and of course bring new challenges: reliability of the adaptation, usability of given user interfaces, etc. In other word how to monitor, control and envision consistent Model Driven Software Adaptations.


Leave a comment