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