software model driven approaches
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:
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:
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?
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