(Back to Use Cases)
A collection of techniques to represent various use case scenarios.
Don't see something you need? Please ask the course staff to add an example!
Representing Operational Choices
Operational choices present themselves in two basic forms:
Procedural:
This is the classic "if-else" or "switch" statement where different operations are conditionally selected. The different conditional clauses or cases can be represented as individual use cases.
A use case diagram can represent the conditional choice of invoked use cases with an "extends" arrow (open arrowhead with "<<extend>>" annotation). To "extend" a use case means that that the extended use case, the one with the conditional ("Main Op" below), will conditionally be extended by the operation of an extender use case, representing one of the if-else clauses or switch statement cases (the "Sub-Op" cases below).
Functional:
This would correspond more to a Strategy or Command Design Pattern where the invoker only perceives the operation as an abstraction and the particular concrete implementation of that abstraction in use at that moment has been selected elsewhere in the application. The cases of a Visitor and especially the Extended Visitor Design Pattern are also well represented in this manner.
Representing a Hierarchy of Personas
It is very common that the user personas interacting with a system have hierarchical relationships where the use cases available to one persona is a superset of the use cases available to another. For instance, an administrator can typically do anything a regular user can do plus the additional administrative tasks apropos to that role.
A use case diagram can represent this sort of relationship between its actors by using a "generalization" arrow (solid line with closed arrowhead). The semantics of this relationship is very much akin to the inheritance or implementation arrows used in UML class diagrams. Similarly, in a use case diagram, a generalization arrow point from the more specific entity to the more general entity. For instance, one can think of an administrator as being a subclass of a general user since it embodies everything a general user is plus additional capabilities. In terms of use cases, this means that all of the use cases available to a "super-actor" are available to the "sub-actor".
Representing Different States of an Actor
Since use case diagrams are not inheritantly able to express notions of time or conditions, it can be a challenge to represent the differing use cases that are available to an actor depending on what the actor has previously done. For instance, the use cases available to a non-logged in user are quite different than those available to a logged in user. Or if a user has chosen to enter "edit" mode, the available use cases change to those pertinent to editing rather than simply "viewing" the data.
For small diagrams, simply using labels to denote what use cases are available and/or in what order, depending on the actor's circumstance may be a viable option but this technique does not scale well to larger, more complex scenarios.
A more scalable technique is to view the actor as being in different "states" depending on what they've done or what has happened in the system. Each "state" of the actor can be modeled as a different actor, thus separating the diagram into smaller, more decoupled parts. It may be reasonable to even separate the different actors into completely separate diagrams to keep each individual diagram down to a reasonable complexity level.
The following example illustrates how the different use cases available to a non-logged in user are different from those available to a logged in user:
Note: While the network-crossing use case invocations show are all asynchronous invocations, this aspect is not technically germane to the illustration of using multiple actors to represent different states of the user. Internal use cases are only being shown to emphasize that the display of the logged-in user interface with which the Logged-in User is interacting is a result of a use case invoked by the Non-logged-in User.
Representing Multiple Operations: Using Different Use Cases vs. Single Use Case with Different Parameter Values
Expressing multiple operations as use cases, whether to an actor or internally, can be challenging and depends on how the invoker views the different operational options.
For example, consider an actor opting between multiple operations. The user interface (UI) can present those options as either separately invokable entities, e.g. buttons, or a a single invokable entity where an input parameter is selected, e.g. droplist+button:
- Different use cases: UI has separate buttons to invoke different operations.
- Each button invokes a different method.
- Single use case: UI has droplist with options for different operations and a single "Execute" button.
- The selected option is passed as a parameter to a single method.
The use case diagram for the above scenarios are different though related.
The issue is further complicated if the operations share common processing, which can be represented either hierarchically or compositionally. The common processing can be represented as an inherited component from an abstract "super-use case" or as a compositional component of each concrete use case. The former technique is useful when the common processing is definitively an invariant part of all the use cases involved while the latter is useful if the common processing is only used by some of the concrete use cases (adding an intermediate abstract use case that defines the use of the common processing is also an option here).
Different use cases presented to actor:
(Note: <<uses>> is synonymous with <<include>>.)
Single use case presented to actor:
(Note: <<uses>> is synonymous with <<include>>.)
Representing a Message-Passing Architecture
In a message-passing architecture, message objects are passed across network from one part of the system to another, e.g. frontend to/from backend. The message passing can be unidirectional or bidirectional, synchronous or asynchronous.
One of the major advantages of a message-passing architecture is that for any number of possible operations invoked across the network, there is only 1 use case (2 for bidirectional) crossing the network boundary. This makes the communications operations invariant with respect to changing data communications requirements because the message transportation is independent of the data carried by the message itself.
Top Priority Use Cases: Note that this means that the send/receive message and message parsing/processing use cases are extremely high development risks and the pathways that include these use cases are considered "critical pathways" whose development is of highest priority!
© 2024 by Stephen Wong