Dept of
Computer
Science
11/04/2020
Monica Farrow EM G30 email : M.Farrow@hw.ac.uk
Material available on Vision
F21SF1 Use case and Activity diagrams 1

Topics



Introduction to UML
Use Cases
Activity Diagrams

Class diagrams and Sequence diagrams were introduced in previous lectures and summarised in
ClassSeqDiags.doc.

Also read Case Study on Noughts and Crosses

A different sort of problem, but still using UML
11/04/2020 F21SF1 Use case and Activity diagrams 2


We’re aiming for a well-designed, robust and maintainable object-oriented system which meets the users’ requirements

What does the user require?



Which classes should there be?
What responsibilities should each class have?
How should objects interact?
11/04/2020 F21SF1 Use case and Activity diagrams 3


Unified Modeling Language


From the late 1980’s to the early 1990s, many languages were developed for modelling object-oriented design graphically
In 1997 Booch, Rumbaugh,Jacobson (called ‘3 Amigos’) combined the best ideas into UML

Now UML is an open standard controlled by the Object
Management Group, a consortium of companies
 www.omg.org

UML2 is the later version, so you may see small differences in older books or websites
11/04/2020 F21SF1 Use case and Activity diagrams 4


Sketch - recommended

Informal

Selective – ONLY use it if the problem is complex and therefore the diagram helps

Blueprint

Complete

Usually too time-consuming, especially if design changes

Programming language


Diagrams transformed to executable code
Not widespread
11/04/2020 F21SF1 Use case and Activity diagrams 5





Use cases

How people interact with the system
Activity diagrams

Shows workflow, how software and human activities interact
Class diagrams

Used both from the conceptual and the software perspective (i.e. design and documentation)
Sequence and communication diagrams

Interaction between the classes for common scenarios

State machine diagrams(mentioned, covered in Advanced
Software Engineering)

Shows changes in the state of an object
11/04/2020 F21SF1 Use case and Activity diagrams 6

11/04/2020 F21SF1 Use case and Activity diagrams 7


Use Cases describe the main processes in the system, from the users’ perspective.

Look at the next 2 slides to get an idea of what a use case diagram and textual description look like, then read the following slides to find out more details.
11/04/2020 F21SF1 Use case and Activity diagrams 8

join reserve book borrower borrow book return book
Here’s an example of a diagram showing all the use cases for a library librarian
11/04/2020 add stock remove stock
F21SF1 Use case and Activity diagrams 9

The textual description for the ‘Borrow’ use case
USE CASE: Borrow
GOAL: To borrow a library book
ACTORS: Borrower, System


Main success scenario
1.
2.
3.
4.
5.
Provide card with membership bar code
Provide book with bar code
System checks membership
System records loan to borrower for 3 weeks
Borrower leaves with the book
Alternatives
3a Borrower already has borrowed maximum number of books
1.
The loan cannot happen
3b Borrower has outstanding fines to pay
1.
Borrower may pay fines, in which case system updated to show this.
2.
Continue from 4
11/04/2020 F21SF1 Use case and Activity diagrams 10




A Use Case is a textual description of the processes in the system, from the users’ perspective.
They describe the interaction between a user and the high level functions within the system.
A user can be a person, another information system, or a hardware device : anything that triggers or is involved in the system

E.g.



Library Use Case: Borrow book
VCR Use Case: Set Timer
IT Help Desk Use Case: Log issue
11/04/2020 F21SF1 Use case and Activity diagrams 11

ACTOR
SYSTEM
BOUNDARY
LINK borrower borrow book
USE CASE
11/04/2020 F21SF1 Use case and Activity diagrams 12





An actor indicates a role played by an external person or system which is involved in a use case
The same person or system may play the role of more than one actor, depending on the context

E.g. maybe a librarian is also a borrower
An actor may be involved in more than one use case
Actors initiate and/or respond to use cases e.g.

Sales rep logs call



Driver starts car
Alarm system alerts duty officer
Timer triggers email
11/04/2020 F21SF1 Use case and Activity diagrams 13

Diagrams and textual description

You should always make a list of use cases and for each one, write a textual description. An example is given a few slides back. Look back at the example while you read the next few slides.


There’s not a lot of point drawing a use case diagram with 1 actor and 2 or 3 use cases – a simple list of the use cases would do
Use the diagram whenever the situation is more complex
11/04/2020 F21SF1 Use case and Activity diagrams 14



A Scenario is a sequence of steps describing an interaction between a user and a system.
Each use case is likely to have several scenarios

The ideal or ‘happy’ scenario is when the process works as normal. This is the primary business flow : it does not cater for any errors in the system or any user entry errors.

 money is withdrawn from ATM book is borrowed from library
11/04/2020 F21SF1 Use case and Activity diagrams 15


‘Unhappy’ scenarios, or ‘extensions’ are when things don’t go so well

 wrong pin number entered member has maximum number of books out already


Numbering of extensions – e.g. 3a means that the extension relates to step 3, and the ‘a’ identifies it as the first thing that might go wrong. Other problems for this step would be numbered b,c etc
After identifying the extension, list the steps that must be taken. This should clearly show whether the process stops or resumes at another step.
11/04/2020 F21SF1 Use case and Activity diagrams 16





The borrower is the actor that initiates the loan
The inputs to the use case are identified

The book code, the membership code
The outcomes are identified

The borrower leaves with the book, the loan is recorded in the system
The exceptions are identified and the alternative outcomes are given.

The borrower already has 6 books out : loan refused


This use case is adequate for the users to agree that it is accurate, without becoming a design.
The cheapest place to sort out errors in the requirements is at this stage
11/04/2020 F21SF1 Use case and Activity diagrams 17


Some use cases may share one or more common steps borrower
11/04/2020
Reserve book
<<includes>>
Check membership
<<includes>>
Borrow book
F21SF1 Use case and Activity diagrams 18


An extension is a significant exception to the normal case borrower
Borrowing refused
<<extends>> borrow book
11/04/2020 F21SF1 Use case and Activity diagrams 19


Actors and use cases can be generalised, showing that one is simply a special case of the other


This is like inheritance in object-oriented design
Suppose that to borrow a CD, users must have additional registration and pay per CD.
borrow book
Borrower : books only borrower borrow CD
11/04/2020 F21SF1 Use case and Activity diagrams
Borrower : books and CDs
20

Break large/complex use cases down into smaller and more manageable use cases – is this a good diagram?



It is often necessary to break up a complex use case into components before a suitable Use Case description can be written.

Do create sub-use-cases and write the description

Sub-use-cases in a diagram are particularly useful if they each involve different actors.
BUT, the diagram on the previous slide doesn’t show anything that couldn’t be shown with

A simple list, if no conditions


An activity diagram (next topic) if conditions exist
Current thinking is that the previous slide is not a good use of a diagram.
11/04/2020 F21SF1 Use case and Activity diagrams 22


Don’t get too involved with the diagrams.
Remember that the textual description is more important.

You will see slight variations in the use of use cases, due to different use and versions of UML

There is no one right answer to any question associated with design.
11/04/2020 F21SF1 Use case and Activity diagrams 23

11/04/2020 F21SF1 Use case and Activity diagrams 24




Activity diagrams model flow of control in a system
States have transitions to other states
States may be either

 action states: atomic action activity states: actions that can be broken down


They may have decisions, explained by conditions, and merges
They may have forks and joins for modelling simultaneous activities (not covered here)
11/04/2020 F21SF1 Use case and Activity diagrams 25

Process loan
Action / Activity

Long rounded rectangle
Start / Initial State
 unique with only one transition line
End State
 not necessarily unique
Transition


Lines indicate sequential flow of actions. Must be labelled after a decision.
Arrows indicate direction of next action
Activity is shown in more detail in another diagram
11/04/2020 F21SF1 Use case and Activity diagrams 26


Decision point : diamond


Single entry transition line
Multiple exit transition lines

 each with Guard (condition)
Exit lines must cover all eventualities
[rainy] socks
[sunny] sandals

There could be a problem with the decisions in this diagram. What do you think it is?
shoes
11/04/2020 F21SF1 Use case and Activity diagrams 27


Merge : diamond




Are used to indicate a merge after a decision
Multiple entry, single exit
In UML1, more than one transition line can enter an activity.
In UML2 (and in this module!), use merge diamonds.
[rainy] socks shoes
[sunny] sandals shoes sandals
11/04/2020 go out UML1
F21SF1 Use case and Activity diagrams go out
28

A mathematical formula, showing process flow n! = n * (n-1) * (n-2) * … * 1
Notes result = 1 counter = 1
[n== 0, n== 1]
[n>1]
In the format n! = result print ( result ,n ) result = counter * result counter += 1
[counter > n]
[counter <=n]
11/04/2020 F21SF1 Use case and Activity diagrams 29


Draw an activity diagram for this situation:
When I order a take-away meal, I phone the
Chinese restaurant, give him my phone number, and his computer will automatically display my address if I’ve ordered before. But if I’m a new customer calling for the first time, he must get my address before he takes my order.
11/04/2020 F21SF1 Use case and Activity diagrams 30

11/04/2020 F21SF1 Use case and Activity diagrams 31


When modelling activities, you sometimes need to show that certain action sequences can be done in parallel
(synchronously, concurrently, simultaneously).

You are buying some items from a shop like Argos.

First you fill in a form showing which items you want to buy.



Then you take it to a desk where a member of staff enters the items into a computer.
If all of these items are in stock, you pay for them, and AT THE
SAME TIME, staff in the warehouse are picking the items off the shelves for you.
You collect the items, but ONLY WHEN you have finished paying
AND when the items have been picked out and sent to the collection desk
11/04/2020 F21SF1 Use case and Activity diagrams 32


Fork



Shows start of concurrent actions
The thread within each exit can be executed at the same time as the other thread
Single entry, multiple exits

Join


Shows end of concurrent actions
The exit cannot occur until all entry threads have been completed

Multiple entry, single exit
11/04/2020 F21SF1 Use case and Activity diagrams 33

Shopping in Argos (assuming all items in stock)
Fill in form
Items entered into computer process payment
Items picked
Sent for collection
Collect items
• The fork shows that the payment can be processed at the same time as the items are being picked out and sent for collection.
• The join shows that you can’t collect them until the payment has been processed and also the items have been picked out and sent for collection
11/04/2020 F21SF1 Use case and Activity diagrams 34




•

Beginners often get confused here.
Use a fork/join if the actions can be done

 at the same time if the order does not matter but both must be done before continuing
In the Argos example, if the warehouse is busy, the items may not be picked until after the payment is processed. The fork shows that these actions CAN be done at the same time – but they don’t have to be. The join shows that they must both be done before continuing.
Do NOT use a join after a decision – use a merge.

We can’t model forks and joins in the java applications this course
11/04/2020 F21SF1 Use case and Activity diagrams 35

11/04/2020 F21SF1 Use case and Activity diagrams 36


Draw an activity diagram to model eating dinner, including a fork and a join
You have to decide whether to eat at home or in a restaurant. If you eat in a restaurant, you go there, order your meal, and eat it. If you stay at home, you have to find a recipe, find the ingredients, and cook it. You need to lay the table. Finally you eat your dinner.
In this scenario, assume that nothing goes wrong – all ingredients are in the house, there is a table in the restaurant etc etc.
11/04/2020 F21SF1 Use case and Activity diagrams 37


Useful to model activity's procedural flow of control between objects

Use vertical columns

Assign column object’s name
 placed at the top of the column

Place each action associated with an object in that object's swimlane
11/04/2020 F21SF1 Use case and Activity diagrams 38

Librarian
[borrowing]
Member
Find book on shelf
[returning]
Wait in queue
[borrowing]
Process loan
[returning]
Process return
11/04/2020 F21SF1 Use case and Activity diagrams 39

Process return
Record return
[reserved]
[not reserved]
Place book back on shelf
Place book
In reserved pile
11/04/2020 F21SF1 Use case and Activity diagrams 40


Activity diagrams are used to



Communicate effectively

Clarity and simplicity
Model the procedural flow of actions that are part of a larger activity
Model a specific use case at a more detailed level

Model business-level function or flow of program code
11/04/2020 F21SF1 Use case and Activity diagrams 41


Focuses on the action sequence of execution and the conditions that trigger or guard those actions.

Focused on the activity's internal actions and not on external actions

Activity diagrams show all potential sequence flows in an activity, whereas a sequence diagram ( covered in a later lecture) typically shows only one flow of an activity
11/04/2020 F21SF1 Use case and Activity diagrams 42

Activity diagrams, statechart diagrams & UML2

In UML1 they were considered to be a special case of statechart diagrams (covered later in the course)

Not really appropriate

UML2


Not a special case of statechart diagrams
Always use merge or join explicitly

Further features

They can be used to show more details such as timing and parameters (not covered in this module)
11/04/2020 F21SF1 Use case and Activity diagrams 43

Try it yourself

Draw a high-level use case diagram for the use of an ATM machine. Write a textual description for the main scenario of the use case to withdraw money, with alternatives

Then draw the corresponding activity diagram for the withdraw money use case

Answer available on website
11/04/2020 F21SF1 Use case and Activity diagrams 44