Model-driven Architecture (MDA) is the OMG´s view of model-driven development (see clarifying concepts: MBE vs MDE vs MDD vs MDA). According to the OMG, “a complete MDA application consists of a definitive PIM (platform-independent model), plus one or more PSMs (platform-specific models) and complete implementations, one on each platform that the application developer decides to support”.
The idea is to start first with a model of the system-to-be free from technical details, i.e. completely focused on reprseenting the domain structure and behaviour (the PIM level model/s), which is then translated by means of executing a model transformation into a set of platform-specific models (the PSM level model/s) describing how the PIM model should be implemented in a particular technology (e.g. by means of a profile that annotates the PIM concepts with technical information).
Conceptually, two key benefits are: 1 – domain experts can focus on the PIMs while platform experts can focus on the PSMs (and transformations) and 2 – the PIM can be reused to implement the same system in different technologies. In practice, I still have to find a single company that adheres to this two-level modeling. Tools / companies I’ve been in touch with either stick to the PIM level (and use a model interpreter / code-generator able to fill all technical details using predefined generation strategies to execute the model) or to the PSM level (and then use a simpler “compiler” that translates that model into the final implementation code).
Not saying they don´t exist at all but in my experience it looks like companies don’t feel the investment of creating both types of models pay off. Maybe because with the advent of the web there are not so many different platforms anymore, maybe because tools are powerful enough to generate code for different target languages directly from the PIM, maybe because for very specific platform domains the PIM part is not so important (or rather small) and all the complexity lies on the PSM aspects so the benefit of creating the PIM is not worthwhile (e.g. for mobile app development, many companies have a separate development team per platform since it’s more productive to create each version from scratch due the importance, and variety, of the technical aspects of each platform).
Do you have the same experience? Any idea why? If you know examples of companies adhering to the two-level modeling architecture can you give some context on how they use them?
P.S. One scenario where this duality makes sense is in reverse engineering process (e.g. see MoDisco) where you first create a “low-level” model of the legacy code (to avoid any initial information loss) and then you process it to create higher-level views of the software (depending on your objectives).
FNR Pearl Chair. Head of the Software Engineering RDI Unit at LIST. Affiliate Professor at University of Luxembourg. More about me.
The first example of PIM and PSM that comes into my mind is the Eclipse EMF framework. In EMF, we define a metamodel in the ecore file (PIM) and refine it with the platform-specific details in the EMF Generator file (PSM). EMF can be used for different platform – Java, RAP, GWT and CDO. The platform-specific details are defined in the generator file.
Another example from the Eclipse Modeling Project is the Graphical Modeling Framework (GMF) which is used for generation of diagram editors. A GMF mapping model describes a shape (how an element should be presented in the diagram) and a tool (the way how the element can be created) for elements that meet certain conditions, usually by a metaclass. The mapping model is used to create GMF generator model which describes platform-specific details. GMF aims to target different platforms, such as GMF Runtime, Graphiti, RAP.
In both examples above they tools are already support and are implementing support for different target platforms. But in most of the case we don’t need several target platforms, one is sufficient, that’s why PIM and PSM got “glued” together implicitly or explicitly.
First of all, complete platform independence is usually not attained since the software industry hardly seems to do any proper domain modeling but tends to go directly for architecture and implementation. (Good counter examples include probably anything that comes out of MetaEdit+.) So, in practice, a lot of PIMs are actually just a slight abstraction/sanitization of the PSM – implicit or not. We should probably speak of a PiM instead of a PIM then 😉
Second of all, going from a PSM to code is usually not very difficult as the PSMM provides only a slight abstraction of the platform (=choice of technologies + chosen architecture + conventions). (The upshot here is the typical “fan-out”: persistence entity becomes a POJO/DTO, database table, DAO, UI component, CRUD service endpoint and Web page, etc..) On the other hand, going from a PIM directly to code tends to be quite a bit harder because of the impedance mismatch, especially for true Domain-Specific Models (DSMs).
The crux is: going from a PIM to a PSM will suffer from the same impedance mismatch so the actual value (in terms of sound engineering practices) of that extra step is doubtful or non-existent: essentially, it’s just an extra compilation step.
However, I often find a slight mixing of PIM and PSM in the form of a markings model useful: the PIM is augmented by or weaved with the markings PSM to provide the platform-specific information that the generation/interpretation phase needs. Usually, these are only relatively small details like table names etc. so this technique is useful to have a model that’s as platform-independent as possible while not burdening the whole process with a complete transformation to a PSM (which requires syncing up the PIMM and PSMM).
With Executable UML modeling, the cost of developing the transformation technology (model compilers) is usually higher than the cost of buying them off-the-shelf.
“buying them” – what’s them? The compilers, the models? Obviously, compilers are cheap (javac, gnuc) – it’s creating the input for them that’s expensive as _a lot of_ typing and monkeys are involved.
My understanding is that “them” refers to the model compilers, i.e. if you want to generate code for a platform X from you (domain) model is cheaper to buy the generator than to put your own time in creating it yourself
Jordi is correct. The Executable UML models are abstracted from specific implementation languages by (typically) using an action language (re. UML Action Semantics) for process modeling. The model compilers generate the PSMs as C, C++, Ada, Java, SystemC, etc. From everything I’ve read, building a model compiler is a non-trivial task.
I’ve used Executable UML with a model compiler, that generated ANSI C PSMs, on embedded systems to move my PIMs across different software architectures, but I’ve not had a need to buy another model compiler to generate in a different target language.
My experiences are entirely opposite, for a couple of reasons.
First of all, constructing model compilers is _not_ particularly difficult, with any mature M2T technology. I’ve taught people how to do it in a matter of hours: starting from a reference implementation of a small but relatively comprehensive example app which is also modeled as a PSM, it’s essentially a matter of recognizing the model elements in the code and replacing them by values coming from the model.
Secondly, the model compiler is intimately connected to the platform, including implementation architecture (which should capture non-functionals which seem to be ever-varying), code style and other conventions. This rarely is a match made in heaven, so usually either the compiler needs adjusting, the model is polluted to coax the compiler to produce the correct output, some manual code is plastered against the model compiler’s output (usually called Tibco ;)), or the output is altered (manually), or a combination of all these. (Too often this leads to the model being abandoned in favor of just continuing with a code base that was once generated for the most part.)
Thirdly, the actual value of the model-driven approach is not really in the model compiler but in the modeling language which allows one to capture the functional requirements in a comprehensive and formal, yet succinctly readable, verifiable and traceable manner. The fact that you can drive a model compiler with this is then “merely” a happy circumstance – which happens to save a lot of time and effort, even when one discounts the construction of the model compiler.
Lastly, Executable UML seems to me to be (an attempt at) a GPL based on a graphical notation, meaning that it is already quite close to the bare metal. (My hatred of UML is well-documented, so I’m pretty biased here.) This makes crafting a model compiler for it particularly easy, but actually modeling your application in it much more difficult – after all, there’s no such thing as a free lunch and the impedance mismatch between problem and solution spaces will continue to exist.
Executable UML is definitely not close to the bare metal, and it should be noted that Executable UML is not equal to UML! The move from Shlaer-Mellor notation to UML was a downgrade (IMO) driven by marketing concerns. Your definition of model compiler also seems to differ greatly from the Executable UML usage. Overloading terms is the hobgoblin of the software community. 🙂
Well, I’m the first to admit that I don’t know Executable UML well enough to have an informed opinion, but what I see in various sources is that the non-structural part of EUML mimics the usual programming language constructs very accurately, with a definite non-declarative taste. This is what I call “close to the bare metal” as the mapping from those constructs and concepts to imperative OO languages is then rather trivial – if tedious, for the sheer number of concepts. Also, I don’t use the term “model compiler” and it’s the first time I encountered it, so I inferred (maybe naively) that it’s equivalent to code generator. If not, then I still don’t understand what “them” refers to 😉
I tend to liken the model compiler concept to a 3GL compiler. The result is steerable through switches and not a direct one-to-one mapping. This is why Executable UML tools don’t support reverse engineering. Most of the code generators do a one-to-one mapping and use the target language for process modeling. Of course, the term “executable UML” was overloaded almost immediately.
Three use cases of a recent project come into my mind.
First, to keep the PSM for the database schema and enhance it with information about additional indexes just for performance reasons.
Second (more inportant than first one), keeping the same database PSM and compare it against the newer one while deducing “Alter Table” statements and further migration DML/DDL.
Third, translate the PIM into a PSM for the UI and let the product owner (there is not really specialist knowledge needed) add layout information for the widgets (very much like Java/Swing GridLayoutConstraint in an easy to edit syntax).
I always liked the MDA approach. But i never really understood where the CIM comes in. It is mentioned once or twice. Are you using it as well? What makes it different from the PIM? Is it just useful in the initial modeling or is it also useful for translation?
The concepts of PIM and PSM are abstract enough to cover any kind of transformation that starts from a more abstract form to a less abstract one (in general, one that is closer to the metal).
In that sense, if you have a PIM, you have a transformation, and you have a PSM. They don’t exist independently (well, unless you are running the model via model interpretation).
The implementation and the PSM can be the same thing. There is no requirement to support PSMs as an intermediate form (i.e. as a PIM for the next level of transformation). There is no incontestable benefit of having intermediate PSMs either. It may or may not be a good idea depending on the use cases one needs to support.
From the MDA Guide:
BTW, before I am accused of being pedantic, I do think the concept as a valuable contribution by MDA, and see value in thinking of PIMs and PSMs even if PSMs are not being used as an intermediate form (same for PIMs when no modeling tool is being used, i.e. source code is the PIM).
Is there a need for PIM/PSM?
Yes, if your transformation/generation scenario is fairly complex enough and your PIM-abstractions are independent enough. The reason to have a layered abstraction is quite the same why there is a separation of concerns in applications (layers, whatever): of course from the users point of view it is totally not neccesary to seperate UI/BL/DB/Services etc. – yet from the maintenance perspective it is.
I’m working on a long term product MDx scenario where many efforts have been collected over the years – completely unmaintainable if all this would be in one transformation step.
Why do others not use this?
To my experience, most MDx use cases are single application/single project where there are no (justifyable) resources available to make a super-fancy-maintainable MDx subproject.
Andreas, I agree with you but I do wonder how many companies face a complex enough scenario to justify the complexity of supporting several levels and your comment seems to confirm that this is rare
Yes, absolutely. Likewise as with n-Tiers, it makes no sense to develop a little universe in each application project. Such an architecture is only justified (resp. inevitable) in a product or ecosystem context, you shouldn’t (and cannot) do it alone. Yet from my point of view that undertaking is not an exotic luxury, but another dimension (!) of productivity. I know that such an ecosystem did not happen to come to existence yet, how hard we tried, but over the years I have developed a rather clear picture of how it may look like. Therefore, I wouldn’t say “MDA was a bad idea that failed”, but “MDA was too early for it’s time”, or maybe “MDA needs a corresponding biotope”. I do consider it a pity that during the agile hype peak R&D on MDx was so heavily neglected. At least, “architectural thinking” is on the topic list again, and IT demand is presently exploding. That might force us to rethink that “productivity issue”.
Actually, these are the abstraction layers we identified, and which are transformed into each other (while it’s also possible to augment the transformed layers with original artefacts on them):
1) DSM, domain specific model – content and metamodel domain specific
2) NM, neutral model – content in balance between domain descriptive and system-as-a-black-box descriptive, yet platform and architecture neutral; metamodel neutral
3) ASM, architecture specific mode – specific to a certain architectural type of system, say a n-tier-application, yet still platform neutral (language, UI etc.); metamodel neutral
4) Source Code – language specific, yet still partially neutral to specific environments (UI, i.e. HTML, Desktop, JS, etc.)
5) Runtime Process – architecture, language and environment specific