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.
Harmonizing UseCases, Dialogs or Conversations, Process Maps, UseCase Diagrams, Sequence Class Diagrams and Sequence Diagrams
I agree with Remy and Branclay Brown and wish to present my PPTs and PDFs on the subject.
AA: The Exact Nature of UseCase is a DILOG but NOT a PROCESS
This is not recognized and clarified in UML giving raise to avoidable controversies and arguments raging for nearly two decades. Please see https://www.slideshare.net/putchavn/usecase-case-is-a-dialog-not-a-process
BB: Specification of “Dialog or Conversation”
Till 2011, there was no standard definition or representation of Dialog or Conversation. In 2011 BPMN has defined “conversation” and given graphic symbols for it but the UML specification does not acknowledge and use them though they are apt and effective.
CC: Hierarchy of Process Map, Class Diagram, UseCase Diagram and UseCase
UseCase is a part of process with the distinction that it is a “Dialog” between any two Performing Entities. Specifically, UseCase is a “Dialog” between the System to be Developed, STBD or System under Consideration SuC and a selected Actor.
The relevant diagrams are Context Diagram in SSAD and UseCase Diagram in OOAD. They are directly and unsystematically created but they are parts of higher level Process Maps (Activity Diagram or BPMN Diagram) or Class Diagram in which multiple entities appear. It is possible to systematically arrive at Context / UseCase Diagram. Please see https://www.slideshare.net/putchavn/proper-context-of-the-system-to-be-developed
CC: Presenting UseCase
The nature of UseCase being a Dialog, there only two entities involved. Craig Larman used System Sequence Diagram in which the System, as a whole (black-box), exchanges messages (has dialog) with a single associated Actor. Effectively a two column table of text serves the same purpose without any diagram. See: https://www.slideshare.net/putchavn/combined-use-case-description-mock-up-screens-and-system-sequence-diagram.
DD It is possible to harmonize concepts and standards of UML and BPMN
Acceptance and use of the above definitions and relations would resolve raging controversies and arguments on the subject.
CHEERS
putchavn@yahoo.com
20DEC17
Thank you for some other fantastic post. The place else could anybody get that type of info in such a perfect manner of writing? I have a presentation next week, and I’m at the search for such information.|
About “gateway” , point taken. Thanks.
The insight that may shed light on the difficulties expressed in this article is that virtually all business processes already involve the use of systems, and cannot occur without them. In the early days of business process modeling it may have been true that systems were not involved in the businesses processes (or at least were not essential) and that the purpose of the business process model was to determine how to automate the process. Today, few if any business processes occur without the use of systems. So modeling even the “as-is” business process must include the use of systems as an integral part.
So a use case is not a “gateway” but simply a part of the business process. But as the article above points out, the current semantics do not allow for the expression of use cases as part of business processes.
Coincidentally this topic has been my major research interest for some time. The latest work proposes a concept called a “usage process” which is simply a use case (by the classic definition) but which is inserted in a process flow among other normal processes. While seemingly mixing apples and oranges, this seems to work out well and allows the easy combination of manual actions by anyone (regular processes) with specific system usages by system actors and even the involvement of multiple systems, in a single, familiar process flow. Swimlanes in the process flow represent people or organizations responsible for actions. Usage Processes are placed in the swminlane of the actor who initiates the use case (or they can be placed in a swimlane for the system, but this has disadvantages). This scheme can be represented in UML, SysML or BPMN.
If someone has a project on which this might be useful, I would like to discuss as I’m seeking case studies for future publication.