Whereas UML stands for “unified” modeling language, its versatility is usually ignored and models semantics are set by default to software components. Moreover, since being a Jack of all trades often means a master to none, the use of UML may also be frustrated by its versatility; that translates either into shallow usage of ambiguous semantics, tunnel vision targeting specific domains or technologies.
That is doubly unfortunate as enterprise architecture and model based system engineering offer new perspectives providing UML can be used to build an architecture framework for the shared modeling of contexts, systems and software.
Hence the benefits to be reaped by revisiting UML purposes and targets in terms of:
- Enterprise architecture and business objectives.
- Business processes and system functionalities.
- Software design and platform technologies.
As it happens, and not by chance, those targets are congruent with enterprise, functional, and technical architectures.
The Unified Modelling Language introduced by the Object Management Group is a de facto standard for system modelling. It’s not a method but a comprehensive toolbox whose extension mechanisms can be used to support a wide range of methods. UML diagrams covers the different aspects of system modelling:
- Object diagrams describe physical objects (active or passive), and locations, with proper stereotypes of instance and package.
- Deployment diagrams are a subset of object diagrams targeting active physical objects, devices or systems.
- Class diagrams describe symbolic objects and containers at architecture level on one hand, at features level on the other hand.
- Use case diagrams describe roles (aka actors) and symbolic behaviors of active objects (agents).
- Activity diagrams describe the processing of symbolic objects, including data and control flows.
- Interaction diagrams describe symbolic behaviors of symbolic objects, including roles.
- State diagrams describe concrete behaviors of actual objects.
- Composite diagrams describe the structure and collaboration of system objects.
- Component diagrams describe system objects.
From Diagrams to Tasks
Diagrams can be seen as views on a continuum of development workflows. From that perspective they can be used as sequencing tools and associated with tasks, for instance UML diagrams may be mapped to Caminao’s workshops and work units.
On step further, diagrams may be customized to directly support Caminao stereotypes.
UML with Caminao Stereotypes
Besides a core of existing stereotypes with unambiguous semantics, new ones are introduced in order to crisscross the modeling layers:
- Physical objects, depending on their activity and communication interface: device, system, human agent, passive object.
- Symbolic objects, depending on their counterpart: representation of physical object, documental object, history record, role, message.
- Roles, depending on communication channels.
- Events: change, time, signal, request, message.
- Activities, depending on binding constraints: CRUD, I/O (symbolic, analog, coded), computation, control.
- States, depending on support: activity, symbolic object, physical object, agent.
Detailed but partial mappings can be defined with specific UML profiles. For instance, SysML define blocks as active physical objects possibly mixing software and hardware, but has no explicit stereotype for humans as physical objects (see under agent), not to be confused with their roles as described by the UML’s “actor”.
Requirements with Caminao stereotypes (Using No Magic‘s Magic Draw)
Using UML tools like No Magic’s Magic Draw it’s possible to iteratively collect requirements rooted in structure and functional units characterized by unambiguous stereotypes.
A domain driven perspective will look at persistency units, ie symbolic representations that must be recorded independently across activities, be it for actual or symbolic objects, or the recording of events and process states.
A use case perspective will focus on activities and associated transient representations: functional or execution units, agents, roles, and events.
UML for “charpentes”: Leaner & Sharper (UML#)
UML is a Jack of all trades and as such may introduce complexity where clarity should be the order of the day. As noted by Ivar Jacobson (“The road ahead for UML“), some kind of hierarchy would help to adapt UML to its different uses. As for Caminao the objective is to circumscribe a kernel whose purpose would be to identify supporting structures (“charpentes” in french) within models.
The proposed solution is to set apart a syntactic subset and use stereotypes to express the semantics of artifacts. The basic grammar will deal with:
- Anchors are artifacts describing instances that can be identified independently.
- Containers are anchors that may be used as address spaces for other anchors
- Power-types are anchors describing subsets of other anchors.
- Functional connectors describe links between anchors
- Structural connectors describe links within anchors
- Derived types describe views on anchors
- Attributes and operations describe features, i.e
Caminao stereotypes can then be added to specify the semantics of artifacts.
- UML’s Semantic Master Key, Lost & Found
- UML and Users’ Concerns
- UML# Manifesto
- UML#: Core Artifacts
- Focus: UML Reenacted
- Focus: UML & MDA
- Thread: Use cases
- Use Cases shouldn’t know about classes
- Use Cases & Action Semantics
- Business Processes & Use Cases
- Use Cases are Agile Tools
- Focus: Business Processes & Abstraction
- Focus: Business Cases for Use Cases