Model Driven Engineering

Preamble

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

As every artifact, models can be defined by nature and function. With regard to nature, models are symbolic representations, descriptive (categories of actual instances) or prescriptive (blueprints of artifacts). With regard to function, models can be likened to currency, as they serve as means of exchange, instruments of measure, or repository. Along that understanding, models can be neatly characterized by their intent:

1. No use of models, direct exchange (barter) can be achieved between business analysts and software engineers.
2. Models are needed as medium supporting exchange between organizational units with different business or technical concerns.
3. Models are used to assess contents with regard to size, complexity, quality, …
4. Models are kept and maintained for subsequent use or reuse.

Depending on organizations, providers and customers could then be identified, as well as modeling languages.

Past & present

Despite their impressive track record proprietary solutions like Information Engineering Facility (IEF) or PacBase have lost most of their traction due to their overheads and lack of interoperability. The paradigm is now coming back either through pragmatic schemes using domain specific languages, or as open frameworks. The OMG’s Model Driven Architecture (MDA) epitomized the latter as its ambition is to leverage 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.

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.

Sadly, MDA promises have been frustrated by OMG’s preferences for meta-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.

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.

• The persistency tier deals with identified business entities, 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 documentary 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 to be shared between contexts and systems, and design units describe their implementation within systems.
• 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. Compared to the persistency tier set at enterprise level, the format and semantics of messages and operations are defined at process level. 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 at user or interface level, 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.

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.

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.

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).

Trying to cross these different footprints brings what could be the corner-stone of MDE benefits, namely its ability to support a declarative approach to engineering.

A matter of Granularity

As phased development processes are gradually conceding ground to model based or agile ones, confusion arises with regard to engineering artifacts: code (agile), diagrams (UML), models (MDE), or views (e.g P.Kruchten’s “4+1”). With MDA those issues can be clarified by formulating them in terms of granularity.

Perhaps confusingly, model based engineering doesn’t deal with models but with artifacts, built with diagrams, organized into models, and presented as views. With artifacts’ granularity soundly defined (e.g along CIMs, PIMs, and PSMs guidelines), engineering processes can be adjusted to engineering problems:

• Iterative if shared ownership and continuous delivery can be achieved.
• Phased if organizational dependencies are to be taken into account.
• Declarative when architectural dependencies are to be taken into account.

That could arguably bring some ecumenical perspective across system engineering creeds, and extend MDE paradigm beyond DSLs silos and code generation.

Engineering & Architectures

OMG’s strayings neatly summarize the MDE alternative between architectures (MDA) and abstractions (UAFP).

Compared to the latter’s outcome of endless, circular, or overlapping definitions, the former paves the way to a comprehensive, principled, and transparent integration of engineering and architectures capabilities, as illustrated by the Caminao framing of Zachman’s principles:

• Conceptual models, targeting enterprises organization and business independently of supporting systems.
• Logical models, targeting the symbolic objects managed by supporting systems as surrogates of business objects and activities.
• Physical models, targeting the actual implementation of symbolic surrogates as binary objects.

• 

Relevance and benefits of model based approaches appear all the more clearly with the digital transformation:

• Data level, for digital environment, operations, and platforms; described by physical and analytical models.
• Information level, for systems and engineering, described by logical and functional models.
• Knowledge level, for business objectives and organization; described by conceptual and process models.

Using models to weave systems and knowledge architectures is to critically enhance enterprises capacity to assess changes and opportunities and so adjust processes and architectures.

Further Reading

• Thread: Model Based Systems Engineering
• Architectures
• EA: Maps & Territories
• Models, Architectures, Perspectives (MAPs)
• About the ‘S’ in MBSE
• The Pagoda Blueprint
• EA & MDA
• How to Pick Development Models
• Phased Yet Lean Processes
• Conceptual Models & Abstraction Scales
• Models & Meta-models
• Knowledge-based Models Transformation
• Focus: Data vs Information
• Redeeming Conceptual Debts
• Agile Architectures: Versatility meets Plasticity
• Projects Have to Liaise

External Links

• Arcadia
• OMG’s Model Driven Architecture