Model Driven Engineering

Model Driven Architecture

Broadly speaking, model driven engineering (MDE) can be defined as the symbolic processing of model contents, e.g by enrichment, extension, interpretation, translation, transformation, generation, etc.


From Nature to Artifact (Anne Desmet)

While the approach has a significant track record on proprietary platforms,  it has received a new impetus from the OMG’s Model Driven Architecture which is focused on modeling standards like UML and open-source platforms.

The MDA approach defines three model layers meant to be used as abutments:

  • Computation Independent Models (CIMs) describe business objects and activities independently of supporting systems.
  • Platform Independent Models (PIMs) describe how business processes are supported by systems seen as functional black boxes, i.e disregarding the constraints associated to candidate technologies.
  • Platform Specific Models (PSMs) describe system components as implemented by specific technologies.

A Straightforward Understanding of MDA

Those models are meant to support the design and development of software components along a sequence of normalized tasks:

  • Specifying a system independently of the platform that supports it.
  • Specifying platforms.
  • Choosing a particular platform for the system.
  • Transforming the system specification into one for a particular platform.

Material flows cannot be continuously governed by models

Model Driven Engineering and Development Flows

Even if terminologies may differ, there is some consensus about the main objective, namely let engineering be governed by models. And that seems a very encouraging perspective because, while the material flows of physical engineering put hard constraints upon the continuity of processes, that’s not the case for software engineering whose flows, being symbolic for most of the development process, can be directly fit into models.

Model layers and Development Flows

For that purpose it is necessary to characterize the contents of models depending on responsibilities and concerns, mainly set by stakeholders and users respectively, and to defined development flows accordingly. That is the aim of  architecture driven modelling, which combines MDA’s layers with a transverse section set along architectural tiers, with artifacts allocated depending upon persistency and coupling constraints.

MDA layers & Architectural Tiers

  • The persistency tier set units, actual or symbolic, whose identity and consistency must be maintained independently of business activities. Actual units are active and passive objects with communication channels. Symbolic units (CIMs) can be associated to actual units or stand for documental objects. Their features are described by attributes whose semantics are defined independently by functional domains. Functional units (PIMs) provide a consolidated description of persistency units, and design units describe their implementation.
  • The second tier deal with shared transient  units, actual or symbolic: their identity and consistency has only to be maintained within the context of business activities, possibly in collaboration. Actual units describe the execution states and transitions of business processes. Symbolic ones (CIMs) define the processing rules and can be associated to execution states or describe computations independently of their actual execution. Contrary to the persistency tier, the format and semantics of messages and operations are defined locally. Functional units (PIMs) provide a consolidated description of execution and control units, with messages and operations properly accounted for. Design units describe their implementation, including the resources and mechanisms supporting collaborations.
  • The third tier deal with transient units whose consistency can be checked locally and therefore has no impact on architectural constraints. That include external events (actual units) and roles played by active objects (symbolic units). It must be noted that external events may be associated to persistent (record) or transient (message) symbolic representations. Functional units (PIMs) provide a consolidated description of user interfaces, and design units describe their implementation.

Setting development flows along architectural tiers should provide a principled basis to model engineering.

Development Flows & Model Engineering

Setting the Paths

If development strategies are to be properly designed, assessed, and improved, they must be built on principled foundations, to begin with, a clear understanding of model contents and development flows.

  • CIM>PIM: On one hand, business requirements are meant to be modeled (as CIM artifacts) independently of their representation as system objects, persistent or transient. Yet, on the other hand, the rationale behind PIMs is to specify system functionalities independently of the technologies available for their implementation. Except for simple or standalone applications, there is no reason to think that the source models contain all the information required to transform them into the target ones. On the contrary, the point is to explicit non trivial decisions about architecture and design, possibly guided by representation patterns.
  • PIM>PSM: as a mirror of the previous leg (from specific requirements to functional architectures), the second leg is meant to bring symbolic descriptions to the ground, namely to design implementations targeting specific platforms. In that case platform specifications provide most of the needed information and translators can be used together with design patterns.
  • CIM>PSM: given a platform specific design (PIM>PSM), some local features of system components can be directly derived from CIM specifications, eg business rules.  User interfaces may offer the same opportunity yet for a different reason: system boundaries can sometimes be directly derived from business requirements and directly target specific platforms.
  • CIM>SOA: service oriented architectures are built from functional building blocs, each providing a set of business or support services. Since those services as defined on a contractual basis independently of the systems supporting them, they clearly belong to platform independent models.  Yet, as services, they mask the underlying architectures and can therefore be derived from business requirements irrespective of architecture and design decisions.

Setting the Paths for Model Engineering

From Model Driven Engineering to Engineered Models, and Back.

While the interpretations of CIMs and PIMs may be surprisingly diverse, there is a broad consensus about what platform  specific models are about, how to build them, and how to use them to implement system components.  Given the combined benefits of PSMs, design patterns and code generation, it may be tempting to generalize this approach by applying automated transformation to computation independent and platform independent models.

Unfortunately, what can be done from model to code is not necessarily possible between model layers:  as each layer embodies specific information, some derived, some decided, transformation policies will have to fence off what is added at each stage, together with its associated rationale. Otherwise, automated transformation may be conceivable when there is no added value between models; but in that case engineering processes are pointless.

MDE Profiles: (a) technical, (b) development, (c) enterprise.

Hence the need of an explicit definition of MDE footprint:

  • Technical MDE uses models to target different platforms (a).
  • Development MDE uses models to support the collaboration of different teams within the same business units (b).
  • Enterprise MDE uses models to support the consolidation of different business processes within the same functional architecture (c).

Further Reading

External Links

2 Responses to “Model Driven Engineering”

  1. nfigay Says:

    I do like the way MDE and modeling is presented all along this blog, in particular with introduction of CIM and knowledge representation.

    Some questions neverthelless. I would like to know why the Platform Model seems not to be considered? PM is one of the models considered in MDA – which can be very important when considering enterprise architecture – where continuous evolution (from AS IS to TO BE situations) is to be considered. It introduces a set of requirements/constraints which are to be considered.

  2. caminao Says:

    Platform Specific Models (PSMs) are considered but the Caminao framework has not much to add to the relatively mature solutions already implemented. Design Patterns in particular are seen as a blueprint of what should be achieved upstream for Platform Independent Models (PIMs).

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: