Synopsis
Use cases are meant to describe dialogues between users and systems, yet they usually don’t stand in isolation. On one hand they stem from business processes, on the other hand they must be realized by system functionalities, some already supported, others to be newly developed. As bringing the three facets within a shared modeling paradigm may seem a long shot, some practical options may be at hand.
To begin with, a typical option would be to use the OMG’s Meta-Object Facility (MOF) to translate the relevant subset of BPM models into UML ones. But then if, as previously suggested, use cases can be matched with such a subset, a more limited and pragmatic approach would be to introduce some modeling primitives targeting UML artifacts.
For that purpose it will be necessary to clarify the action semantics associated with the communication between processes and systems.
Meta-models drawbacks
Contrary to models, which deal with instances of business objects and activities, meta-models are supposedly blind to business contents as they are meant to describe modeling artifacts independently of what they stand for in business contexts. To take an example, Customer is a modeling type, UML Actor is a meta-modeling one.
To stress the point, meta-languages have nothing to say about the semantics of targeted domains: they only know the language constructs used to describe domains contents and the mapping rules between those constructs.
As a consequence, whereas meta-languages are at their best when applied to clear and compact modeling languages, they scale poorly because of the exponential complexity of rules and the need to deal with all and every language idiosyncrasies. Moreover, performances degrade critically with ambiguities because even limited semantics uncertainties often pollute the meaning of trustworthy neighbors generating cascades of doubtful translations (see Knowledge-based model transformation).
Yet, scalability and ambiguity problems can be overcame by applying a core of unambiguous modeling constructs to a specific subset, and that can be achieved with use cases.
Use Cases & UML diagrams
As it happened, the Use Case can be seen as the native UML construct, the original backbone around which preexisting modeling artifacts have been consolidated, becoming a central and versatile hub of UML-based development processes:
- Sequence diagrams describe collaborations between system components but can also describe interactions between actors and systems (i.e use cases).
- Activity diagrams describe the business logic to be applied by use cases.
- Class diagrams can be used for the design of software components but also for the analysis of business objects referenced by use cases.
- State diagrams can be used for the behavior of software components but also for the states of business objects or processes along execution paths of use cases.
Apart of being a cornerstone of UML modeling, use cases are also its doorway as they can be represented by a simple sequence diagram describing interactions between users and systems, i.e between business processes and applications. So the next step should be to boil down the semantics of those interactions.
Use Cases & Action Semantics
When use cases are understood as gateways between business users and supporting systems, it should be possible to characterize the basic action semantics of messages in terms of expectations with regard to changes and activity:
- Change: what process expects from system with regard to the representation of business context.
- Activity: what process expects from system with regard to its supporting role.
Crossing the two criteria gives four basic situations for users-to-system action semantics:
- Reading: no relevant change in the environment has to be registered, and no activity has to be supported.
- Monitoring: no relevant change in the environment has to be registered, but the system is supposed to keep track on some activity.
- Achievement: the system is supposed to keep track on some specific change in the environment without carrying out any specific activity.
- Accomplishment: the system is supposed to keep track on some specific change in the environment and support associated activity.
These action primitives have to be wrapped into interaction ones relating to changing expectations of users and systems.
State machine can fully support action semantics
When use cases are positioned at the center of UML diagrams, those situations can be neatly modeled with state machines for actors’ expectations, business objects, and execution.
Use Cases & Modeling Patterns
If use cases describe what business processes expect from supporting systems, they can be used to map action semantics to UML diagrams:
- Reading: class diagrams with relevant queries.
- Monitoring: activity diagrams with reference to class diagrams.
- Achievement: class diagrams with associated state diagrams.
- Accomplishment: activity diagrams with associated state diagrams and reference to class diagrams.
While that catalog cannot pretend to fully support requirements, the part it does support comes with two critical benefits:
- It fully and consistently describes the interactions at architecture level.
- It can be unambiguously translated from BPM to UML.
On that basis, use cases provide a compact and unambiguous kernel of modeling constructs bridging the gap between BPM and UML.
