Objective
Models are built on purpose, namely (1) define what a system is expected to do and (2) specify how it should be built.
Given that those aims belong to different realms, with different concerns, and using different languages, bringing models under a common roof calls for a shared perspective together with some anchors. Architecture deals with the perspectives while stereotyped artifacts are introduced to anchor models and support traceability.
- Models are set from different perspectives, each focusing on its own architecture: enterprise, functional, or technical. Building models along architectural constructs should provide continuity while focusing on concerns specific to perspectives.
- Stereotyped artifacts bring together the semantics of models providing for continuity and traceability between architectures.
Application vs System Modeling
From an architectural point of view, an application is a set of software components to be run within a single address space under a single clock; otherwise we speak of systems.
Applications can be designed and implemented along a staged routine as illustrated by the waterfall development process. Practically, it means that initial (requirements) models become useless once replaced by applications.
Such a fire-and-forget procedure is inadequate for systems because they must cohabit with contexts as described by initial models. As a consequence requirement models must be kept alive all along systems life-cycle.
The only way out of this conundrum is to distinguish between functional and technical architectures. Practically that would mean:
- Define stereotypes in order to describe within the same models actual (agents, devices,systems, passive) and symbolic (customary or representatives of actual ones) objects.
- Distinguish between symbolic objects whose identification is transient (during their processing) and those whose identification must be supported persistently (independently of their processing).
- Define coupling between actual and symbolic objects depending on coupling constraints: instant(synchronous) or delayed (asynchronous) mapping.
More formally it will be necessary to define architecture layers and modeling language constructs.
Architecture Layers
Architecture Driven System Modeling is based upon the three modeling layers defined by OMG’s Model Driven Architecture. The additional objective is to sieve business requirements (or CIMs) in order to fence off architectural archetypes upfront and to trace them across analysis and design, or PIMs and PSMs. That (small) set of archetypes are to be set in stone while the (large) remainder will be added piecemeal and at leisure all along the engineering cycle.
From Objects to Systems
Despite its clear merits the use of the OMG’s UML (Unified Modeling Language) remains limited, fragmented, and shallow. A large part of those problems may be due to its ill-defined scope (e.g requirements, analysis, and design), and concepts (e.g objects, aspects, and domains).
Those difficulties have clear consequences for MDA, whose implementations remain local, based on specific domains and languages. Hence the benefits to be expected from a comprehensive and consistent approach of object-oriented modeling based upon two classic distinctions:
- Business vs System: assuming that systems are designed to manage symbolic representations of business objects and processes, models should keep the distinction between business and system objects descriptions.
- Identity vs behavior: while business objects and their system counterpart must be identified uniformly, that’s not the case for aspects of symbolic representations which can be specified independently.
That two-pronged approach bridges the gap between analysis and design models, bringing about a unified perspective for concepts (objects and aspects) as well as scope (business objects and system counterparts).
Objects and Architectures
In order to get to the core of architectural archetypes requirements must be read through glasses colored with “architectural semantics”. First, it is necessary to identify anchor points between context and system; that will provide for a clear understanding of persistent and transient hooks holding the symbolic representations to their actual counterpart. That should be done by the first of model layers, which is meant to describe business objects and processes to be supported by systems independently of the technology used to implement their symbolic counterparts.
Yet, those anchors will impact differently on architectures depending on the associated constraints:
- Business objects, agents, events and processes identified independently of systems are to be set apart in order to guarantee the continuity of enterprise architecture.
- Aspects and activities identified through primary objects or processes are subject to change with organizational contingencies and business opportunities.
If different, and overlapping, business concerns are to live under the same roof, their symbolic representations will have to be consolidated, and that is to be achieved by the second layer, namely the platform independent (aka analysis) models. And if evolution is to be supported, a distinction must be maintained between anchoring units on one hand, and features and rules on the other hand. Changes to the former are likely to impact architectures, changes to the latter should not.
By setting apart model anchors it’s possible to map model layers to architectures: computation independent models with enterprise architecture, platform independent models with functional architecture, and platform specific models with technical architecture.
Abstraction layers are introduced to consolidate system symbolic representations and functionalities. For that purpose inheritance semantics are applied selectively to anchoring units and aspects, the former targeting identities, the latter limited to interfaces. It must be noted that the object-oriented constructs and semantics used with models are neutral and can be implemented by any programming language.
Finally, patterns are introduced to bridge the gap between abstract representations used in analysis models and design solutions. The objective of those representation patterns is to introduce some architecture rationale shared by functional and system architectures.
Kernel Modeling Language
Modeling languages come in two basic embodiment: specific or universal. As should be expected, there is as many specific languages as domains, and UML prevails among the small number of universal ones. Curiously, that leaves a blind spot for modeling pertaining to architecture concerns independently of their business counterparts. In fact, there has been some attempts to fill the gap using UML’s extension mechanisms, yet that usually adds to the current complexity of the language whereas what is required is a pared down language addressing the core issues shared by all and every system.
Along with architectural concerns, the objective of UML# is to describe systems independently of their implementation, and such a kernel language should support:
- Explicit distinction between actual and symbolic objects or activities.
- Unique and consistent formalism for the identification of persistency and execution units.
- Unique and consistent formalism for the connections between persistency and/or execution units.
- Unique and consistent formalism for the composition of persistency and execution units, as well as connections.
Engineering Processes
Engineering processes can be positioned along two axis:
- The democratic/bureaucratic axis measures the level of detail defining work units, illustrated by agile methods on one hand (freely defined work units), unified processes on the other hand (fully detailed work units).
- The cascade/iterative axis describe the sequencing of work units.
Despite the profusion of methodologies, “main street” or “boutique”, engineering processes usually keep along within a rigid dichotomy: either one-fits-all sequences of work units with adjustments here and there, or broadly defined organization of generic work units. As a consequence, design and assessment of engineering processes are either irrelevant (no much room for change) or problematic (work units are too vaguely defined).
Moreover, the lack of principled definitions for development flows means that their processing cannot be managed efficiently and, as a consequence there can be no significant alternative to cascade engineering.
Architecture Driven System Modeling aims to the best of each side: from procedural approaches it takes well-defined development artifacts and corresponding work units; in step with agile methods, it provides for lean and fit processes, pared down and finely tuned to the specificity of objectives and contexts. Set within the MDA framework, it’s possible to identify development patterns and design engineering processes accordingly.
Benefits are to be found in all aspects of the software engineering process: traceability, metrics, quality, reuse, and collaboration. As a result, architecture driven modeling processes should be easily mapped into the CMMI framework, with development patterns and strategies properly designed, assessed and improved.
Further Reading
- Architectures
- Thread: Model Based Systems Engineering
- Thread: Enterprise Architecture
- Models, Architectures, Perspectives (MAPs)
- Architecture Capabilities
- Abstractions & Emerging Architectures
- Enterprise Systems & the OS Kernel Paradigm
- Agile Architectures: Versatility meets Plasticity
- Service Oriented Architectures
- EA: Maps & Territories
- Relating to Functions
- Capabilities vs Processes
- From Processes to Services
- Alignment for Dummies
- Alignment: from Empathy to Abstraction