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