The Model Driven Software Network

Raise your level of abstraction

Steven Kelly interview for MDSN - recording online in Vimeo

I have just published the recording of this monday's MDSN interview with Steven Kelly on Vimeo. At the time of writing, it is still converting, but if that goes well, it will be available for viewing tonight.


I talked with Steven Kelly for a little over an hour, about his background in model driven software development, his views on arguments
against model driven development and the benefits of using it. We also
discussed the importance of learning from the past, and whether or not Martin Fowler is right in saying that the productivity benefits of model driven development have not yet ....

Views: 70

Reply to This

Replies to This Discussion

Thanks to Steven, Angelo and all involved. Great questions, great answers, high quality interview all around.
Excellent interview with a lot of success stories for MDD. Congratulations Steven and Angelo. About the M2M transformations, I do believe they are quite important: wp.me/p1auAH-81
I think so, too, and I'd like to explain why.

In the 90'ies, the community headed to solve a challenging goal: creating whole (mostly enterprise) applications based on models - that failed fantastically! To be fair, we should take into account that applications were much simpler in those days, remember, Windows 3.x was released then for the first time.

Why did it fail? Steven argues that languages and solutions did not fit customers needs, and that is quite true. So one approach (DSM) is to build languages that do fit - individually, per customer. Does it solve the general problem? No - and it is not even aimed at doing so. As far as that, there's still agreement on the reason: the general problem is _very_ complex. But is it _too_ complex? Is it hubristic? BDUF?

To describe the scenery, I like a metaphor of a bridge: "The bridge of abstraction leading over the river of complexity". There are of course differently wide rivers, depending, some contain little islands. A river has to sides: left, there's the customer with his individual requirements, right, there are specific software solutions.

Around 2000, MDA suggested to build a bridge pier in the midths of the river, to make the bridge more stable. That alone didn't really help, and it introduced another complication into the projects: build a model, build a M2M-, and build a M2T-transformation. It seems, next to noone really did this within his project, and the few who did failed again. So very soon, all projects I could gain insight at, even if they claimed to to MDA and were using MDA tools, in fact just and only did plain old M2T.

Is DSM (building short bridges, not spanning broad rivers) better than MDA? In a sense, yes, since it delivers productivity gains, while MDA (alone - piers for still crashing bridges) does rarely. But in another sense, both are not conmpeting, but mutually complementing approaches, ingredients of a larger MDSD framework.

The bridge can be divided into abstraction levels: starting from the technical side, there are technically specific details. Going to the midths of the bridge, it's getting more and more abstract, in a technical sense. Ideally, in the midths, there's a completely neutral model, with respect to technical details and with respect to business details. Continuing to the customer, it's getting specific again, but now in a business sense: that's where DSLs come into play.

In this picture, both approaches have their place. Does such a neutral model exist? Is it manageable? What is the benefit of these intermediate layers (they have costs, too)?

First: it is quite clear that a neutral model is economically extremely benefical: it simply enables not to build each bridge starting from scratch, but to use prebuilt bridgeparts. Very attractive, I'd say.

Second, I don't see any acceptable reason against a universal modelling language _except_ it's provenly too complex, which noone has shown so far.

Does that suffice: DSM + MDA? To my experience: no. As described in detail in the post http://www.modeldrivensoftware.net/forum/topics/introducing-emos we discovered a substantial amount of more problems and had to find solutions for them.

To close the circle of this post, one technology we apply are Object Construction Plans (xocp.org, open source) to describe our transformations. With this approach, we can dynamically build "Object Views", i.e. models that provide a "view" to an underlying model, thereby representing a transformation. These stacked views are not bound to a predefined scheme of Model A, Model B, Model C but can be applied partially, in small pieces and repeatedly on top of each other. Thereby we're open to introduce new "intermediate" models or get "rid of them", as much we like.

We often asked ourselves, reflecting on architecture, whether the intermediate parts are necessary at all. In fact, in the beginning, we had not planned a certain architecture, but it evolved from our code itself (ok, with some educated guesses), in a reiterated sequence of refactorings of our templates with the goal of eliminating redundancy, organising information better and making it more maintainable. We observed repeatedly a strong tendency of the system for emergence of as well "the neutral model" as "domain specific models". Last not least, the result of this process looks aesthetically satisfying. These observations give us confidence that the whole approach is a "Good Thing".

To compare it with traditional software development: yes, it is true that for the customer the only thing that counts is the working application. Still noone would doubt today that e.g. a three tier architecture is helpful for all the "ilities". Same with MDSD: what counts is only the running application in the end, but talking about the whole bridge, architectural advances are inevitable.

Andreas
I listened to the whole interview. Very good. Keep'em coming!...

But Angelo still needs experience as a podcaster. Well, one more reason to continue!
Thanks. Never did a podcast before, so you got a point there.

RSS

Badge

Loading…

© 2019   Created by Mark Dalgarno.   Powered by

Badges  |  Report an Issue  |  Terms of Service