After a promising inception twenty years ago by the OMG (Object Management Group), UML (Unified Modeling Language) seems to have lost part of its steam and fallen short of initial expectations.
On a general perspective that may be due to the primacy given to the agendas of tools providers, at the expense of users concerns. More specifically, UML practices have been hamstrung by two opposed misconceptions: on one side UML has been associated to OO methods and as a result demoted by non-devotees; on the other side it has been taken as a substitute for programming languages, and so confined to class diagrams and code generation. Hopefully, two major advances in methods and development frameworks, respectively agile and MBSE, could correct those biases and renew UML appeal.
UML Core Artifacts
UML diagrams target five primary artifacts:
- Use cases, events, and actors describe what happens between systems and active agents in their environments.
- Activities describe what systems are supposed to do when use cases are triggered.
- Classes describe systems components.
- Sequences describe how systems components collaborate to perform activities.
- States and transitions describe the behaviors and synchronization of systems components.
While those diagrams cover the whole of enterprise systems, UML is all too often limited to the description of software components.
UML and Enterprise Systems
As noted above, the lack of clear users guidelines can be seen as a main cause of UML piecemeal and biased adoption. That can be illustrated by the use of activity and class diagrams:
- Whereas activity and state diagrams could have been tailored to fully and consistently describe business processes, an alternative notation (BPMN) with arguable benefits is often preferred by business analysts.
- Whereas UML is meant to deal with the whole of systems, successful implementations like domain specific languages (DSL) focus on class diagrams and code generation.
But both negative trends could be reversed if changes in methodological or technical environments could put UML users on sounder grounds and give them clearer guidelines.
Methods: Use Cases & Agile
As it happened, use cases have been the main UML innovation, other artifacts having been already introduced by modeling languages. And more to the point, they were meant to be the cornerstone of the “unified” construction, a modeling bridge between business processes and supporting systems. That clearly didn’t happen with traditional (and failed) methods like waterfall, but agile could be more welcoming.
Agile principles put the focus on collaboration and iterative code development, with only sparse mentions of models or processes. But as requirements don’t always come as clear-cut short stories told by well identified business units, use cases may help agile teams to deal with organizational or architectural dependencies:
- Open minded and Versatile: use cases are not limited to users because actors (aka roles) are meant to hide the actual agents involved: people, devices, or other systems. As a consequence, the scope of UCs is not limited to dialog with users but may also includes batch (as one-step interactions) and real-time transactions.
- Modular and inter-operable: given their simplicity and clarity of purpose, use cases can be easily processed by a wide array of modeling tools on both sides of the business/engineering divide, e.g BPM and UML.
- Iterative: given their modularity, use cases can be easily tailored to the iterative paradigm. Once a context is set by business process or user’s story, development iterations can be defined with regard to invariants (use case), iterations (extension points and scenarii), backlog units (activities), and exit condition.
- Scalable: use cases provide a sound and pragmatic transition between domain specific stories and architectural features.
That could be the basis of an open relationship between agile development models and UML.
Frameworks: Classes & MBSE
Beyond the various labels (based/driven, system/software, development/engineering), all model based approaches to systems engineering and software development try to replace procedural approaches by declarative ones, and to redefine processes in terms of artifacts transformation.
The benefits of that approach have already been demonstrated at design level through the use of domain specific languages (DSLs). Since effective DSLs usually rely on class diagrams, UML could be used to leverage their success beyond code generation and across the whole of the engineering process.
With artifacts seamlessly and consistently defined and managed within a single engineering framework, procedural schemes could be replaced by declarative ones reusing, editing, or transforming artifacts depending on constraints.
- UML and Users’ Concerns
- Agile & Models
- Phased Yet Lean Processes
- Caminao & UML
- Modeling Paradigm
- UML# Manifesto
- UML’s Semantic Master Key, Lost & Found
- Business Processes & Use Cases
- Use Cases are Agile Tools
6 thoughts on “Focus: UML Reenacted”
I will not argue about what the three amigos had in mind, but the fact is that Use Cases were the main innovation of UML, the rest was a consolidation of existing OO methods.
Well Use Cases were actually part of Jacobson OO-methodolgy, known as Objectory, some years before the panel event at OOPSLA 92 where Rumbaugh asked the gurus in the panel to join instead of continuing the OO war. So from my perspective Use Cases not an invention of UML.
And I completely agree with UML has its roots in software.
Not quite right. UML started out as the software design language taking parts from previous work by Grady Booch, Ivar Jacobson and James Rumbaugh. UML has been applied to other domains, but its primary purpose is software design. SySML is a UML variant for systems engineering.
The appellation “DSL” is often used to refer to a paradigm specific language rather than to designate a domain specific language.
Musical notation (solfège) is a DSL (you can express only music).
HTML is not a DSL but a PSL (you can express whatever you want).
Agreed (that’s the spirit of the sculpture above).