Preamble
UML (Unified Modeling Language) and MDA (Model Driven Architecture) epitomize the lack of focus and consistency of the OMG’s strategy. As it’s safe to assume that there can be no architectures without models, MDA and UML arguably bring sensible (if not perfect) schemes without significant competition.
Unfortunately, not much has been made to play on their obvious complementarity and to exploit their synergies.
MDA & the Nature of Models
Model driven architecture (MDA) can be seen as the main (only ?) documented example of model based systems engineering. Its taxonomy organizes models within three layers:
- Computation independent models (CIMs) describe organization and business processes independently of the role played by supporting systems.
- Platform independent models (PIMs) describe the functionalities supported by systems independently of their implementation.
- Platform specific models (PSMs) describe systems components depending on implementation platforms.
Engineering can then be managed along architecture layers (a), or carried out as a whole for each application (b).
It’s important to note that the MDA framework is completely neutral with regard to methods: engineering processes can be organized as phased activities (procedural), iterations (agile), or artifacts transformation (declarative).
Logic & The Matter of Models
Whatever the idiosyncrasies and fuzziness of business concerns and contexts, at the end of the day requirements will have to be coerced into the strict logic of computer systems. That may be a challenging task to be carried out directly, but less so if upheld by models.
As it happens, a fact all too often ignored, models come with sound logical foundations that can be used to formalize the mapping of requirements into specifications; schematically, models are to be set in two formal categories:
- Descriptive (aka extensional) ones try to classify actual objects, events, and processes into categories.
- Prescriptive (aka intensional) ones specify what is expected of systems components and how to develop them.
Interestingly, that distinction provides a formal justification to the one between analysis and design models, the former for the consolidation of requirements across business domains and enterprise organization, the latter for systems and software designs. Such logical foundations could help to manage the mapping of business processes and systems architectures.
UML & the Anatomy of Models
Except scientific computation, there is no reason to assume a-priori congruence between the description of business objects and processes and the specification of the software components. As a corollary, their respective structures and features are better to be dealt with separately.
But that’s not the case at architecture level, where domains and identities have to be managed continuously and consistency on the two sides of the business/system divide. At this level (aka enterprise architecture), responsibilities and identification and communication mechanisms must be defined uniformly.
Compared to MDA set at architecture level, UML describes the corresponding artifacts for business, systems, and platform layers. Regardless of the confusing terminology (layers or levels), that puts MDA and UML along orthogonal dimensions: the former (layers) deals with the nature of contents, the latter (levels) with their structures and features.
Using the same unified modeling language across business, systems, and platform layers is to clearly and directly enhance transparency and traceability; but the full extent of MDA/UML cross-benefits is to appear when models logic is taken into account.
Models & Systems Evolution
As illustrated by the increasing number of systemic crashes, systems obsolescence is no longer a matter of long-term planning but of operational continuity: change has become the rule and as far as complex and perennial systems are concerned, architectures are to evolve while supporting their functional duties seamlessly. If that is to be achieved, modularity and a degree of consistency are necessary between the nature of changes and their engineering. That’s where MDA is to help.
As pointed to above, modularity is best achieved with regard to level (architecture, element) and models contents (business, systems, platforms).
At architecture level, changes in domains, identification, and categories must be aligned between descriptive (enterprise) and prescriptive (systems) models. That will be best achieved with UML models across all MDA layers.
The constraints of continuity and consistency can be somewhat eased at element level: if descriptive (business) and prescriptive (systems) models of structures and features are to be consistent, they are not necessarily congruent. On component (prescriptive/design) side, UML and object-oriented design (OOD) are to keep them encapsulated. As for the business (descriptive/analysis) side, since structures and features can be modeled separately (and OOD not necessarily the best option), any language (UML, BPMN, DSL,etc.) can be used. In between, the structure (aka signature) of messages passed at architecture level is to be specified depending on communication framework.
Considering the new challenges brought about by the comprehensive interoperability of heterogeneous systems, the OMG should reassess the full range of latent possibilities to be found in its engineering portfolio.
Further Reading
- EA: Maps & Territories
- Caminao & UML
- UML’s Semantic Master Key, Lost & Found
- UML and Users’ Concerns
- UML# Manifesto
- UML#: Core Artifacts
- Focus: UML Reenacted
- Model Based Systems Engineering
- Model Driven Engineering
- Architecture Driven System Modeling
- Models as Parachutes
- EA & MDA
- Models Transformation
- Knowledge Based Model Transformation
- Models Transformation & Agile Development
- Legacy Refactoring
- Modernization & The Archaeology of Software