When its first version was published twenty years ago the prognosis for OMG’s UML (Unified Modeling Language) was of rapid and wide expansion. It didn’t happen, and notwithstanding a noteworthy usage, UML has not become “the” unified modeling language. Beyond the diverse agendas of methods and tools providers, this falling short may have something to do with a lack of robust semantics, as illustrated by UML 2.5’s halfhearted attempt to define individuals.
UML 2.5 Aborted Attempt with Individual
UML 2.5 has often been presented as an attempt to redress the wayward and increasingly convoluted paths taken by the previous versions. Yet, beside some useful (and long needed) clarifications and adjustments, its governing group failed to agree on some compact and unambiguous semantics and had to content itself with perfunctory guidelines introduced as an afterthought.
As a matter of fact the OMG committee may have tried to get its semantics in order, as suggested by the chapter “On semantics” making the point right away with a distinction between the things to be described and the categories to be applied:
“A UML model consists of three major categories of model elements [classifiers, events, and behaviors], each of which may be used to make statements about different kinds of individual things within the system being modeled (termed simply “individuals”in the following)”.
That straightforward understanding (UML is meant to describe individual objects, events, or behaviors) could have provided the semantic cornerstone of a sound approach. Surprisingly, and for obscure reasons, it is soon smudged by syntactical overlapping and semantic ambiguity, the term “individual” being used indifferently as adjective and noun, and then appears to be restricted to classifiers only. That leaves UML with a dearth of clear semantics regarding its scope.
Individual as a Semantic Master Key
The early dismiss of individual as a constitutive concept is unfortunate because, taking a leaf from Archimedes, it could have been the fulcrum on which to place the UML lever.
To begin with, no modeling language, especially one supposed to be unified, can do without some convincing semantics about what it is supposed to describe. Furthermore, such a requirement is of primary importance for UML whose scope straddles the divide between business and systems realms, and must therefore rigorously define what they share and how they differ.
And that could have been neatly achieved with a comprehensive and unified interpretation of individuals, combined with a clear taxonomy of the aspects to be modeled:
- Individuals are whatever occurrences (in business or systems contexts) with identities of their own.
- These individuals (objects, events, or behaviors) can be specified with regard to their structure and relationships.
The logical primacy of this approach is reinforced by its immediate, practical, and conclusive benefits for business processes modeling on one side, model based engineering processes on the other side.
A Key to Business Processes Modeling
As far as business processes are concerned, modeling the part played by supporting systems turns around few critical issues, and these issues can be dealt more clearly and consistently when set in reference to individuals taxonomy (objects, behaviors, events) e.g:
- Functional or non functional requirements ? The former can be associated with individuals, the latter cannot.
- Architecture or application ? The former affect the specification of interactions between individuals, the latter affect only their local features.
- Synchronous or asynchronous ? Specifications can only be made with regard to life-cycles and time-frames: system (objects), process (behaviors), or instant (event).
- Structures or Relationships ? The former are bound to individuals’ identity, the latter are used between different individuals.
- Inheritance or Delegation ? The former is used for the specification of structural or functional features, the latter for individuals’ behaviors.
More generally that understanding of individuals should greatly enhance the alignment of systems functional architectures with business processes.
A Key to Model Based Systems Engineering
As should be expected from a lack of semantic foundations, one of the main characteristics of the UML community is its fragmented practices, regrouped around diagrams (e.g Use case or Class) or task (e.g requirements analysis or code generation).
The challenge can be directly observed for model based system engineering and software development: with the exception of Statecharts for RT modeling, Class diagrams are the only ones used all along engineering processes; the others, when used, are reduced to documentation purposes. That bottleneck in development flows can be seen as the direct consequence of UML restricted semantics: since behaviors are not identified as individuals in their own right, their description cannot be directly translated into software artifacts, but have to be understood as part of active objects descriptions before being translated into class diagrams. Hence the apparent redundancy of corresponding diagrams.
As a corollary, reinstating a unified semantics of individual for both classifiers and behaviors could be the key to a seamless integration of the main UML diagrams. Most important, that would bear out the cross benefits of combining UML and MBSE.
- A Conceptual Thesaurus Overview
- UML and Users’ Concerns
- Thread: Model Based Systems Engineering
- Objects with attitudes
- Caminao & UML
- UML# Manifesto
- Use Cases shouldn’t know about classes
- Business Processes & Use Cases
- Use Cases are Agile Tools