I read the MDA Guide v 1.0.1

Just reading the title of this post you know I’m kidding. This founding OMG’s MDA guide is unreadable by a human being ;D. However, even if skipping a lot of sections, it’s interesting enough to worth reading it as it proposes definitions for terms very much used in the MDE community: MDA, CIM, PIM, PSM, model transformation…(*)

When I discovered the MDA principles, seven years ago when entering in Sodifrance group, I tried to read this guide but gave up and prefered to ask my new colleagues to explain MDA as they were doing MDA every day. They did, and I soon produced my first MDA big picture, using OMG’s terms but in a way that reveals today not to be the canonical one:

MDA life-cycle

Wait. Just reading this picture again… Not so bad for a first try! Sorry it’s in French but here are English (hope so!) comments:

• The orange track to the left is the classic Specification>Conception>Coding track into which the corresponding MDA’s artifacts are CIM/PIM for specification, PIM/PSM for conception, and generated/hand-written code
• The blue track is the (often missing or disregarded) Architecture track: Applicative architecture + Infrastructure architecture + Programming rules. In this track there is only one MDA artifact: PDM (Platform Dependant Model). Clearly a mistake here as the applicative architecture should have been PIM/PSM instead of PDM.
• And the green track represents pure MDA tasks not covered by non-MDA teams: defining modeling rules to allow producing models productive for the transformation/generation steps, and writing code generators. Again, defining modeling rules should not have been put at PSM level but is rather clearly at PIM level (whatever we call PIM ;D)

I showed this picture to a lot of people, including customers and prospects. One of my MDA pitch’s key points was: as you can see part the perceived constraints (e.g. the need of a true architecture insight before writing generators) are just the fact that MDA guides you to do the job you ought to do if you want to write good applications at reasonable cost: writing formal specification, describing architecture and coding rules, and getting sure that both parts are full taken into account in the software life-cycle.

So, after some years of observing MDA practices in real life cases, what is my viewpoint on definition given in the MDA Guide?

• CIM: never used. The concept itself is highly questionable but it’s another subject…
• PIM: the MDA Guide places the PIM at a pure solution description level, thus opening a royal way to the brand new Executable UML. On the field, the PIM I know are a mix-up of problem analysis and solution description (as introduced here) and are clearly not executable nor intended to be
• PSM: never used. The terminal transformation, always called generation, is always a mix-up of templates (which may be seen as a kind of PSM) and programs containing implementation decision rules

So, all in one, a ~PIM and that’s all. And no model transformation as the only one we use is called generation.

A very intriguing point is that the MDA Guide doesn’t say a word on IS urbanization, nor on application architecture (ex: SOA). At this time, the MDA Guide doesn’t describe a realistic way to practice MDD… But it certainly is a rather good description of MDE practices principles used by an ADM(**) project! Why? Because in an ADM project we start from source code and try to get the same behavior in a target code which uses another implementation technology. As we just search a path from an implemented solution to another implemented solution, we stay in a “solution space” where meta-concepts, concepts and instantiations are almost in bijection. Taken it at model level doesn’t change the bijective property and then model transformations are easy to describe… At least if we stay at a principle level, however practice may be (and often is) much rude.

The funny end: the MDA Guide describes the MD but not the A. It’s a pity from an Enterprise viewpoint as the best value at IS level lies in the “A” part: describing IS organization in a way that enforces agility (and then optimize maintenance costs). This “A” came back in ADM but ADM also avoid the point as focusing on transformation tools.

Let’s go OMG: you can do better with that A!

(*) MDA: Model-Driven Architecture, CIM: Computation Independent Model, PIM: Platform Independent Model, PSM: Platform Specific Model
(**) ADM: Architecture Driven Modernization