UML# Manifesto

Objective

Taking a cue from Ivar Jacobson (“The road ahead for UML“), some modularity should be introduced in order to facilitate the use of UML in different contexts, organizational, methodological, or operational. Three main overlapping objectives should be taken into consideration:

• Complexity levels: the language features should be regrouped into clearly defined subsets corresponding to levels of description. That would open the way to leaner and fitter models.
• Model layers: the language constructs should be re-organized along MDA layers if models are to map stakeholder concerns regarding business requirements, system functionalities, and system design.
• Specificity: principled guidelines are needed for stereotypes and profiles in order to keep the distinction between specific contents and “unified” ones, the former set with limited scope and visibility, the latter meant to be used across model layers and/or organizational units.

As it happens, a subset of constructs centered on functional architecture may well meet those three objectives as  it will separate supporting structures (“charpentes” in french) from features whose specifications have no consequences on system architectures.

State of The Art

Information technologies progress crab-like, the hardware leg striding forward with Moore Law, and the software leg crawling on practices, with rare real leaps like relational (more than 30 years ago) and object (10 years later) technologies. The adoption of UML as a modeling standard at the end of the last century could have spurred a new start of innovation for software engineering; instead, its protracted diffusion and shallow or biased usage suggest a latent factor behind the limping progresses of software technologies. The absence of clear advances for the last 20 years, despite the undisputed soundness and cogency of available concepts and tools, may hint at some basic focusing error regarding what is to be considered.

Whereas object oriented approaches to software analysis and design are now broadly accepted, there is no consensus regarding the nature of targeted objects; more precisely, there is no explicit distinction between symbolic objects and processes on one hand, and their operational counterparts on the other hand. Such a confusion can be observed at different levels:

• Requirements: the perspective is limited to a dual distinction between problem (what) and solution (how) spaces. That approach is much too simplistic as it overlooks the functional dimension, namely how a software solution (nothing more than a piece of code) is to be used within operational systems (a distributed set of agents, devices, and symbolic machines).
• Time-scales: when models are used (that’s not always the case), operational contexts (business objects and processes) are captured at inception time and their description frozen as snapshots until further notice. This lack of synchronized context and system models rules out any explicit management of systems life-cycles and transformation.
• Model contents: the aim of model driven (or based) approaches is to define development flows in terms of models and organize engineering processes accordingly. But that may not be possible if the semantics of model contents are not properly differentiated between modeling stages, the consequence being a lack of principled support for model transformation. That point is best illustrated by the perplexing debate about executable models and models as code.
• Architectures: blurred focus on systems and contexts necessarily entails a confusion between enterprise, functional, and technical architectures. That confusion is proving to be critical when service oriented architectures (SOA) are considered.
• Processes: the aim of development processes is to manage concerns set by different stakeholders, based upon different rationales, and subject to changes along different time-frames. If those concerns cannot be specified independently, the design and assessment of engineering processes will lack a sound basis.

Yet, since all those problems stem from the same blurred focus, they may also be deal with a shift in modeling paradigm. Moreover, that shift could be especially productive given the availability of the conceptual constructs associated with object-oriented approaches and UML. For that purpose it is necessary to clarify model purposes and customize the language accordingly.

Two Legs and a Bridge

From a general perspective, and beyond lexical controversies, models and architectures should be defined along two parallel scales:

• Architectures: enterprise (concepts), systems (functionalities), and platforms (technologies).
• Models: conceptual (business context and organization), analysis (symbolic representations), design (physical implementation).

Caminao puts the focus on models as bridges between business goals and system implementation. While simple or standalone applications may often be developed without mediation, that’s not the case for shared applications deployed across distributed system with independent life-cycles.

• Enterprise architecture: business requirements are not necessarily expressed with modelling languages.
• Functional architecture: functional (aka system) requirements should be expressed with modelling languages.
• Technical architecture: non functional requirements are not expressed with modelling languages.

Grammars and Semantics

Whatever the editor, graphical or otherwise, models are built from expressions according to grammatical rules. Some rules are meaningless as they only define what is possible, i.e how to form correct expressions; others are mixed as the associated constructs may also convey some meaning.

In any case, those rules have to deal with three types of considerations: lexical, syntactic, and semantics.

1. Legitimate items, words or symbols, are defined by the lexical layer.
2. The way lexical items can be used to build well-formed expressions is defined by syntactic rules.
3. Finally, language semantics define the relationships between expressions and targeted contexts.

The Unified Modeling Language (UML) is the outcome of the collaboration between James Rumbaugh with his Object-modelling technique (OMT), Grady Booch, with his eponymous method, and Ivar Jacobson, creator of the object-oriented software engineering (OOSE) method. Whereas the Three Amigos did a pretty good job in consolidating the best of different approaches, UML 1.x was not built from scratch along the ideal template: instead of drawing clear lines between lexical, syntactic, and semantics layers, constructs were first established along semantic perspectives, namely static (aka structural) and dynamic (aka behavioral) views. Formal syntactic definitions of qualifiers and expressions came almost as an afterthought.

As is often the case when ambitious objectives set by visionaries are taken over by committees, things certainly didn’t improve with UML 2.x. Having to face a growing complexity without a solid grammatical ground, the OMG turned simultaneously to abstraction and specificity: on one hand Meta-Object Facility (MOF) is meant to bypass classical grammars descriptions by bringing every modeling language under a single meta-language roof; on the other hand stereotypes and profiles provide a very practical way to tailor UML to specific domains and organizations.

But those options have driven UML into opposing directions: on one hand meta-models do nothing to improve UML capabilities and usability as their aim is mainly to enable some interoperability between tools providers; on the other hand stereotypes and profiles push UML users into specific corners, which is not what a “unified” modelling language is supposed to do. As a consequence, more than 15 years since it became a standard, UML is still not widely accepted as such; and when it is used, it is all too often on a very limited scope, or for very specific purpose, or without much of methodology.

Lean, fit, and Sharp, as in “Charpente”

The proposed approach takes advantage of UML stereotyping mechanism to reorganize the semantics around a kernel of simple syntactic constructs dealing with:

• Nodes, for artifacts with standalone semantics and use.
• Containers, for nodes that may be used as address spaces for other nodes
• Power-types, for nodes describing partitioning of other nodes.
• Functional connectors, for links between nodes identified independently.
• Structural connectors, for links between nodes identified as a whole (aka composites).
• Derived types, for views on nodes.
• Attributes and operations, for features to be associated to nodes, i,e without semantics of their own.

All structures (nodes, connectors and features) are to be described uniformly with a single set of standard operators.

The semantics layer is to use a finite set of stereotypes to characterize:

• Artifacts life-cycle, transient or persistent.
• Artifacts nature, actual or symbolic.
• Identification mechanisms: standalone, dependent, joint, continuous.

Traceability with “Charpentes”

Finally, semantics are needed to support built-in traceability of dependencies across models or along development cycles.

Those dependencies must be managed depending on their scope and nature.

Regarding scope, one must distinguish between dependencies involving operational contexts and those limited to symbolic artifacts.

Modeling dependencies stem from requirements and refer to both operational contexts and their symbolic representations:

• Representation dependencies between business objects or behaviors and their symbolic counterparts.
• Structural dependencies between roots and members.
• Functional dependencies between connected nodes.

Development dependencies arise from modeling decisions and refer solely to symbolic artifacts:

• Ownership dependencies between address spaces and artifacts.
• Usage dependencies through reused features, either shared or inherited.
• Abstraction dependencies

Regarding the nature of dependencies, a clear-cut distinction must be maintained between those rooted to decisions and those born from necessity.

By-products

Taking inspiration from the Capability Maturity Model Integration (CMMI), the benefits of UML# and, more broadly, from architecture driven modelling can be identified for product, project, and process areas:

• Traceability is obviously a starting point as it is a prerequisite for streamlined engineering (product), portfolio and risk management (project), and application life-cycle management (process).
• Measurement comes close, with built-in unbiased estimators, project workloads, and process assessment.
• Quality management would clearly benefits from layered traceability and objective measurements, with built-in controls, non-regressive testing, and model-based validation.
• Reuse provides another path to quality, with patterns (product), profiles (project) and development strategies (processes).
• Finally, collaboration is to be facilitated between engineering processes targeting heterogeneous platforms, using different methodologies, across independent organizations.

That should open new perspectives to projects productivity and effectiveness.

Implementation

A shallow implementation will simply add  UML# stereotypes to core UML diagrams.

Depending on tools it may be possible (e.g with No magic) to customize diagrams or even define new ones.

A deep implementation will entail the development of a two-level interpreter, one for UML# syntax, the other for the semantics.