2009 copyright Leslie Munday University
Use Case Modeling With Activity And Use Case
Diagrams
An Environment DisciplineApril 11, 2023
Leslie Munday 2008
Precursor
In order to understand the material in this course, you should have equivalent knowledge of the following: An Introduction To Business Use Cases. Working with AUC documents.
04/11/23 2
Leslie Munday 2008
Use Case And Activity Diagrams In this presentation we will learn:
what are the components of a use case diagram. how the use case diagram components are
related. what is the difference between an application use
case diagram and a business use case diagram. what are the different components of an activity
diagram. what are the relationships between the different
components. how to represent a business use case with an
activity diagram. how to represent an application use case with an
activity diagram.
04/11/23 3
Leslie Munday 2008
Activity - The specification of an executable statement that includes 1 or more actions and may result in a change in the state of the system.
Application – the software part of the system under discussion. Artifact – Any complete piece of a model. Business Actor – Someone who gets benefit from the business use case. Component – Anything that can be placed on a diagram. Diagram – A graphical depiction of all or part of a model. Model – A complete description of a system from a particular perspective. Object - An entity with a well-defined boundary and identity that
encapsulates state and behavior. Postcondition – the state of the system after a use case has executed. Precondition – the state of the system prior to a use case executing. Relationship – shows communication between an actor and a use case. State - A condition or situation during the life of an object during which it
satisfies some condition, performs some activity, or waits for some event. Package – A container for grouping artifacts. System – the item under discussion, it may comprise hardware, software or
both. System Actor - Someone or something, outside the system that interacts
with the system. Use Case – A set of actions a that yields an observable result of value to a
particular actor.
Terms Used In This Presentation
04/11/23 4
Leslie Munday 2008
Diagram History The use case was invented by Ivar Jacobson and
adopted by Rational. The activity diagram is a derivation of the state
transition diagram. (State transition diagrams, (STD) as their name suggests contain states connected by transitions.)
A transition is triggered by an event. A state is the result of the execution of an event. With the emergence of use cases a diagram was
required that also shows events and actions. Actions were added to the STD to create the
activity diagram. Think of it as a hybrid of a state transition diagram
and a flowchart. Both diagrams are part of the Unified Modeling
Language (UML), which is now owned by the Object Management Group (OMG).
04/11/23 5
Leslie Munday 2008
Overview The notation used in this presentation is
based upon that specified in the UML 1.x specifications, not UML 2.x.
The notation is specific to modeling use cases. Where the definition of a component is not relevant to this goal, I either ignore it or redefine it appropriately.
The objective is to define a notation that is consistent, easy to use and does not allow ambiguous modeling rules (one way and one way only to represent a concept) yet will not restrain you from expressing everything that is required in your use case model.
04/11/23 6
Leslie Munday 2008
Why Do We Need Notation? Don’t the UML specifications specify how to draw these
diagrams? No, they define the semantics of the symbols used in the diagrams, but do not commit to a consist use on diagrams.
UML tries to be all things to all people. It is impossible to use in consistent and unambiguous manner unless guidelines are built around the semantics in order to constrain their rules.
For example, Rational recommends that the primary actor in a use case is identified with a directed association. UML contains no such rules or guidelines.
I was taught that when two threads are created, from a fork, (which run concurrently) that neither thread could continue (return to the main path) until both threads reached a join.
According to the UML specifications, concerning forks and joins, either can be used without the other. In my understanding this does not make sense because the threads will never complete, hence the use case will never end.
04/11/23 7
Leslie Munday 2008
The Use Case Diagram There are two types of use case diagram:
business use case (BUC) diagram. application use case (AUC) diagram.
The business use case diagram describes the activities performed by any number of business workers (people) in order to achieve a business goal (whether they are manual or automated is not specified in the BUC).
The application use case describes the activities performed by the software in order to achieve a system goal.
04/11/23 8
Leslie Munday 2008
Use Case Diagram Overview A use case diagram
contains actors, use cases and relationships between them.
If a use case diagram becomes difficult to read on a single page, then break it into 2 diagrams.
I recommend, especially for systems with a large number of use cases, showing actors connecting to a single use case, by duplicating the actor. In this manner restructuring the use case diagram is much simpler.
04/11/23 9
Leslie Munday 2008
Common To Use Case Diagrams Indicate the primary actor
using an arrowhead on the relationship entering the use case.
Indicate secondary actors by using no arrowheads on the relationship line.
Included use cases have an arrowhead entering the use case and the relationship contains the stereotype <<include>>.
Extending use cases have an arrowhead entering the use case being extended and the relationship contains the stereotype <<extend>>.
04/11/23 10
Leslie Munday 2008
Business Use Case Diagrams The primary actor is the stakeholder that is getting benefit from the
BUC. The secondary actors are people outside the business, that interact
with the activity of the BUC. Some modeling tools will distinguish a BUC from an AUC by placing a
line through the use case shape; alternatively give the BUC a stereotype named ‘Business’.
Some guidelines distinguish between business actors and system actors; rarely do I find this necessary. (If a role of the same name appears in both organizations; business and system, but they perform different roles, then distinguishing between business and system actors may be necessary.)
04/11/23 11
Leslie Munday 2008
Application Use Case Diagrams The primary actor is the role that initiates the
execution of the AUC. The secondary actors are applications or people
outside of the AUC that interact with the use case.
04/11/23 12
Leslie Munday 2008
Using Inheritance In Use Cases When two or more roles are
the primary actor of a use case, create a common role and use the ‘generalization’ relationship to inherit that role’s capabilities.
The systems and business process analysts both inherit everything the analyst role does.
I have rarely found a need to use the ‘generalization’ relationship between use cases. If anything I have found that it adds ambiguity to the use cases.
04/11/23 13
Leslie Munday 2008
The Activity Diagram Components
Initial Node Control Flow Action or Activity Object Flow Branch
Merge
Fork Join
Final Node
04/11/23 14
Leslie Munday 2008
Initial Node This represents the
start of the flow of an activity diagram.
An activity diagram contains a single start node.
The name of the initial node is entered on the node. It takes the form of an adjective.
04/11/23 15
Leslie Munday 2008
Control Flow A control flow connects any combination of:
activities branches merges forks joins
A control flow has direction, which is indicated by the arrow head – you may only traverse the control flow in the direction of the arrow.
A control flow may not enter an initial state. A control flow may not exit a final node. A control flow is the representation of an occurrence
of an event. The name of the event is entered on the control
flow. It takes the form of something has been done, noun-verb(past-tense)
04/11/23 16
Leslie Munday 2008
Activity And Action The activity represents
the actions that occur as a result of an incoming event from a control flow.
The name of the activity is entered on the activity and takes the form of something being done, present tense verb-noun
04/11/23 17
Leslie Munday 2008
Branch The branch is used to show alternative paths in
the activity diagram. Label the decision node with a question(?). Do not label the merge, (unless you have a good
reason to). One control flow enters the decision node and
two or more alternative control flows exit the decision node.
Only one of the paths may be transitioned as the result of an event occurring.
Each exiting control flow contains the condition under which it is taken (called a guard), dependent upon the answer to the question. These guards must be mutually exclusive.
The guards on exiting control flows must cover all possible outcomes of the question being asked by the branch.
The simplest way to ensure all possible outcomes are covered is to phrase the branch question such that the only possible answers are ‘Yes’ or ‘No’. Note, this can add extra branches to the diagram.
Two or more control flows enter the merge node and one control flow exits.
04/11/23 18
Leslie Munday 2008
Fork The fork may be represented by vertical
or horizontal bars. The fork represents that the flow through
the diagram has split into 2 paths that are running in parallel (multitasking).
The fork has a single control flow on entry and several control flows exiting.
Use a fork when there is no requirement on the order of activities in a flow.
For example, the Dematerializer receives an event that the door is shut. It now suspends the cargo and creates a vacuum, but these actions may be performed in parallel, so we model them with a fork.
04/11/23 19
Leslie Munday 2008
Join For every fork there should be a join (if not
your activity diagram is broken). The join may be represented by vertical or
horizontal bars. A join simply shows that when the parallel
activities have finished that they then come back to join a single flow again.
The join has several control flows entering and a single control flow on exit.
The exiting control flow cannot be executed until every incoming control flow has completed.
There is no need to label the fork or join.
04/11/23 20
Leslie Munday 2008
Final Node The final node represents the
termination of the activity diagram. There may be several termination
states in a single diagram. Label the final node with an adjective.
04/11/23 21
Leslie Munday 2008
The Use Case Details How does the activity diagram relate to the
use case template? Each component of the activity diagram
represents a detail in the use case, as follows: Precondition – Initial state. User step – Event. System action – Activity. Alternate flow – Decision. Alternate flow returning to the basic flow – Merge. System activities running in parallel – Fork. Parallel activities joining the basic flow – Join. Postcondition – Final node.
04/11/23 22
Leslie Munday 2008
Mapping To The Use Case? Precondition Actor input System Step Alternative or
extension flow Basic Flow Returning alternate
flow Parallel activities Postcondition
04/11/23 23
Leslie Munday 2008
Dematerialize Cargo Example 1 Precondition
The system is ready to transport cargo.
Basic Flow1. The system receives a
command to open the door to the Dematerializer.
2. The system opens the door to the Dematerializer.
3. The system receives a command to transport the cargo.
4. The Transmitter is ready to transmit and the system closes the door to the Dematerializer.
Alternate Flow1. At step 4, the Transmitter is
not ready to transmit, and the system waits for the transmitter to be ready to transmit.
2. The Transmitter is ready to transmit and the use case continues from step 4.
04/11/23 24
Leslie Munday 2008
Dematerialize Cargo Example 2 Basic Flow (continued)
6. The system sends the deconstructed cargo to the Transmitter and sends the cargo blueprint to the Blueprint Manager.
7. The system removes the vacuum from the Dematerializer.
8. The vacuum is removed and the use case ends.
Postcondition The system is ready to
transmit cargo. Extension Flow
1. At step 8, the system is set to shutdown when the cargo is transmitted, and the systems performs a shutdown.
2. The system shutsdown and the use case ends.
Postcondition The system is shutdown
04/11/23 25
Leslie Munday 2008
Advanced Notation
In addition to the basic activity diagram components there are: Objects and object flows. Swimlanes.
Objects are used to identify potential analysis classes.
Swimlanes can be used on BUC activity diagrams to group activities or indicate roles that perform an activity.
04/11/23 26
Leslie Munday 2008
Swimlanes Consider the following activity diagram which
describes the ‘Exploring Automation Requirements’ workflow from the business modeling discipline.
‘Set And Adjust Goals’ activity is performed by the business process analyst.
‘Define Automation Requirements’ activity is performed by the business designer.
The activities performed by the same role (or department) are positioned such that they all fall into the same vertical column.
Beware: swimlanes can become very expensive to maintain, you might want to consider using stereotypes to identify the role.
04/11/23 27
Leslie Munday 2008
Swimlane Example Diagram
04/11/23 28
Leslie Munday 2008
Another Swimlane Example
This example demonstrates how swimlanes can be used to define the steps of a business use case that are to be automated.
04/11/23 29
Leslie Munday 2008
Object Objects represent external
information that is being manipulated by the use case.
Every use case activity should be reading from or writing to at least one object, (otherwise how can you test that the activity executed).
Any data manipulated by an activity, should be shown as being input from an object.
The results are output to an object.
The object takes the name of an instance of its class.
04/11/23 30
Leslie Munday 2008
AUC With Objects The ‘Opening
Door’ activity sends an ‘open’ command to the ‘door’ object.
The ‘Waiting For Transmitter’ activity reads the status of the ‘transmitter’ object.
The objects are instances of the ‘Door’ and ‘Transmitter’ classes.
04/11/23 31
Leslie Munday 2008
Why Model Use Cases? Gives an overview of your use case steps without
having to read the details. Performing a simulated execution, aids identifying
missing or misplaced steps in the use case. Shows the alternative paths through the use case
with the basic flow. Allows for a consistent and unambiguous method
for specifying the steps in the use case. It’s a faster way to get the basic flow from the
stakeholders (they will thank you in the long term).
04/11/23 32
Leslie Munday 2008
Naming Conventions Name events in the past tense with text that describes what happened in
order to trigger the event. Text of the form of ‘Verb Noun’ is appropriate, (or ‘Noun Verb’ if preferred, but be consistent).
Activities should be named in the present tense with text that describes what is currently happening. Text of the form ‘Doing Something With Noun’ is appropriate.
The control flows exiting a fork synchronization bar are effectively the same as the control flow entering the fork and do not need to be named.
The control flow exiting a join synchronization bar is effectively a combination of all entering control flows. It is not necessary to label the exiting control flow.
Use ‘Capitalized Words’ for names of activities, events and guards. The start state should be labeled such that it describes a precondition of the
activity diagram (i.e. the state of the system or business prior to the occurrence of the event that control flows out of this state).
Label the end state with text that describes the postcondition of the system/business when the end state is reached.
Label a decision with text representing the question being asked, followed by a ‘?’.
It is not necessary to label a merge, fork or join.
04/11/23 33
Leslie Munday 2008
Activity Diagram Semantics Every activity diagram should have exactly one start state. Every activity diagram should contain one or more end states. Every activity should have at least one entering control flow and one exiting
control flow. (An activity with no entering control flow will never be executed. An activity with no exiting control flow will never terminate.)
Ensure that the labels on the control flows exiting a decision cover every possible outcome to the question being asked by the decision node.
Ensure that no two exiting control flows from a decision can take the same answer to the question.
Use the [guard] field to label the outgoing control flows from a decision; because the text does not represent an event, it represents a guard on the incoming event.
Avoid placing activities (or any other activity diagram component) within activities. If you feel the need to break your activity into smaller sub-activities (the general semantic meaning of placing activities within activities) it suggests that the activities are too complex and their scope should be re-visited.
For every fork synchronization bar there should be a corresponding join synchronization bar. The join synchronization bar allows every activity on a parallel path in the fork, to complete. The omission of a join synchronization bar indicates that the activity diagram can end with an activity not completed.
04/11/23 34
Leslie Munday 2008
Exercise
Create a use case diagram that shows a customer making a withdrawal and a deposit with an ATM.
Model The ATM example use case With An Activity Diagram.
There are no ‘right’ answers. There is no industry standard for
modeling use cases.
04/11/23 35