From http://www.omg.org/mda/faq_mda.htm “UML is the key enabling technology for the Model Driven Architecture: Every application using the MDA is based on a normative, platform-independent UML model. By leveraging OMG's universally accepted modeling standard, the MDA allows creation of applications that are portable across, and interoperate naturally across, a broad spectrum of systems from embedded, to desktop, to server, to mainframe, and across the Internet.”

Introduction

The MDA® (Model Driven Architecture) is an initiative proposed by the OMG (Object Management Group), aimed to solve integration and portability problems between platforms.

Jon Siegel from OMG has summarized in a few words what MDA is, or better said, what it does: “The MDA unites OMG's well-established modeling standards with every middleware technology - past, present, and future - to integrate what you've built, with what you're building, with what you're going to build.”

Key Concepts

Turning these words into practical advantages for software development, we are dealing with three key concepts:
  • possibility of reuse;
  • portability; and, consequently;
  • higher productivity

How does MDA fulfil this promise?

MDA consider the existence of two models:

  • a PIM (Platform Independent Model), which is an abstract, high level model that specifies the application to be built (=what we want to do).
  • a PSM (Platform Specific Model), which is a concrete model that contains elements tied to a specific platform (=how we will do it).

The MDA core is based on OMG technologies (MOF, UML, CWM). These technologies can be used to describe PIMs. A PIM can be refined n-times until the desired system description level is obtained. Then, when it is necessary to take into account the infrastructure, the PIM will be transformed into a PSM. Then, again, PSMs are refined as many times as needed.

Summarizing, a complete MDA application consists of a definitive PIM, plus one or more PSMs and complete implementations, one on each platform that the application developer decides to support.

Model and UML roles in MDA

“In the MDA, models are first-class artifacts, integrated into the development process through the chain of transformations from PIM through PSM to coded application. To enable this, the MDA requires models to be expressed in a MOF-based language” (e.g. UML).

(...)

“Each MDA-based specification has, as its normative base, two levels of models: a Platform-Independent Model (PIM), and one or more Platform-Specific Models (PSM). For many specifications, these will be defined in UML, making OMG's standard modeling language a foundation of the MDA.”

MDA website, MDA Specifications section

As we can see, Model and UML are key concepts for the MDA approach. That is normal: MDA implies that software development is driven by models, and UML has become the de facto standard for systems and software modeling.

Development driven by models. Why? Why modeling has become more and more usual in development environments? Because the model:

  • is easier to understand and to manipulate than code
  • represents better than code the real object we want to build
  • helps to manage the complexity of the software development
  • enables to see several things at the same time
  • provides a graphical interface
  • shows the significant elements of the system. Code is too full of things
  • allows to document the project
  • allows to do an impact analysis
  • allows to build automation facilities for producing the implementation portion
  • represents requirements
  • enables reuse
  • allows communication before taking risks of the construction
  • facilitates certain kind of changes that would be error-prone and tedious to make at a code level
  • simple mechanisms offered by the model (drag and drop, etc) provide an “automatic” way for adjusting code changes
  • enables abstraction and helps to manage the increased complexity of software
  • makes easier to introduce changes
Changes are easier to implement at model level rather than at code level.

A good model helps to generate good code.

Support claimed by Tool vendors

The support to MDA has become an important feature that every UML tool vendor claims to offer. But the fact is that the MDA concept, which is language-, vendor- and middleware- neutral, let tool vendors free to implement it in different ways.

Here are some of the examples about how UML tool vendors claim their support to MDA:

  • PIM to PSM transformation engine
  • Template-based techniques
  • Use of UML profiles and extensions
  • Action languages
  • Kit of features contained into an MDA package
  • Executable UML (X-UML)
  • Implementation of the Design Pattern concept
  • etc.

ARTiSAN MDA approach

ACS-SHADOW/ACS-TDK: A new way of working with model & code

Shadow is a real-time synchronizer that keeps an ARTiSAN Studio model and its generated code continuously synchronized. Whatever modifications are introduced into the model or at function body level, Shadow immediately intercepts them, and updates their counterpart. That is, whenever something is changed inside the model, the code is generated from it; on the other hand, when you modify a source code file manually, Shadow parses it and roundtrips your modifications inside the model.

In this way, we have the “best of both worlds” solution. Using Shadow you can make structural changes to your design in ARTiSAN Studio and make use of a coding IDE to edit source code bodies at the same time.

ARTiSAN MDA approach using Shadow and TDK is based on the following concepts:

Model and code are just two views of the same thing.
This does not mean that UML and code are the same thing. UML is a visual notation, whilst code is a “non-visual” set of instructions. But there are mapping rules between UML and programming languages like C, C++, Java, etc., and this is the reason why UML tool vendors provide automatic code generation from models. Nevertheless, these automatic engines don’t guarantee that model and code will remain the same thing along the project. Many times, the first code generation will be just the starting point for software engineers to go ahead with their job, and the model will be taken apart forever... In other (optimistic) cases, at the end of the project and for documentation purposes, the model will be modified manually in order to reflect the final code, eventually by using additional features such as synchronization facilities, etc. But, as you can imagine, this practice is very time-consuming and error-prone.

What ARTiSAN offers is an approach that assures that:

  1. model and code will remain perfectly aligned all along the project
  2. the model will be the container of the entire project (including code)

The UML tool, which enables us to edit models, and the IDE environment, which enables us to edit code, are open all the time, simultaneously.
Shadow will take control of the permanent synchronization between these two worlds. The possibility of visualizing model and code simultaneously allow users to verify within a few seconds how modeling choices are translated into code. Changes at model or code level will be immediately reflected in the counterpart. From the beginning, it will be possible for the user to build a better model in order to generate a better code.
On the other hand, some actions are much more appropriate to be done at model level (e.g. adding an attribute or an operation to a class), whilst the IDE environment is much more likely for executing another kind of things (e.g. edit function bodies).

The ARTiSAN code generator is a UML model.
The TDK (Template Development Kit) allows users to create code generators from a UML model. These code generators will be used by Shadow for keeping in synch the UML model of the application and the related code according to the generation algorithms defined by the user.

In this way, the MDA Platform Specific Model, the one that contains implementation details, is with ARTiSAN a real model, visible and maintainable at model level. Being a true model, you can fully understand it, easily modify it and reuse it across different applications.

TDK is definitely the ARTiSAN implementation of MDA. True MDA. TDK allows people to define specific implementations (platform dependent) in some classes that can be shared across models, and automatically apply those implementations to other classes (platform independent) just when the code generation takes place. With TDK, both the platform dependent and independent layers are fully accessible by the users.

Users must rule MDA approach

Both PIM and PSM are models, and both models are supposed to be provided by the *users*, not tool vendors.

Vendors that actually deliver the code-equivalent (not model) of PSM exist. However, this approach is just wrong in MDA context, since MDA explicitly requires that PSM is a *model*, not something hard-coded inside a tool executable as many vendors offer. Vendors providing PSM as code or hard-coded inside the code generator fail one of the main benefits of MDA, i.e. the ability to let the *user* specify the platform details (via a model).

On the other side, ARTiSAN provided in the past some examples of real MDA approach, like the real-time OS integrations actuated by mean of models and patterns. We know that technically this was a limited approach, nevertheless it is really model based for both PIM *and PSM*.

TDK is the ideal tool for implementing real MDA. In facts, it allows to define PIM and PSM separately and *BIND* them together during the code generation phase. The ability of TDK in MDA is not limited in literally reproducing the contents of PIM and PSM, hoping that they merge together respecting target language syntax and semantics constraints (very unlikely, and definitely the big black hole of MDA).

TDK can generate bind code on purpose that exactly matches those constraints; being this ability confined inside the code generator (so completely independent on the project PIM and PSM models), this ability can be *RE-USED* immediately to *other* projects. This includes completely different projects (i.e. with different PIMs and PSMs), different projects with the same platform (so different PIMs but same PSM), different platform for the same project (different PSMs and same PIM).