21/08/2015F21SF1 Use case and Activity diagrams1 Software Engineering Foundations Introduction to...

19/04/23 F21SF1 Use case and Activity diagrams 1

Software Engineering Foundations

Introduction to UMLUse Cases

Activity Diagrams

Monica Farrow EM G30 email : [email protected] available on Vision

Dept ofComputerScience


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


Object-oriented Design questions

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?


Where did UML come from ?

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


How it can be used

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


Topics covered in this module

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


Use CasesHow people interact with the

system


Use Case

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.


Use Case Diagram for Library

add stock

remove stock

join

borrow book

return book

borrower

reserve book

librarian

Here’s an example of a diagram showing all the use cases for a library


The textual description for the ‘Borrow’ use case

USE CASE: BorrowGOAL: To borrow a library bookACTORS: Borrower, System

Main success scenario1. Provide card with membership bar code2. Provide book with bar code3. System checks membership 4. System records loan to borrower for 3 weeks 5. Borrower leaves with the book

Alternatives3a Borrower already has borrowed maximum number of books1. The loan cannot happen3b Borrower has outstanding fines to pay1. Borrower may pay fines, in which case system updated to

show this.2. Continue from 4


Use Case

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


Use Case Diagram - notation

borrow bookborrower

ACTOR

USE CASE

SYSTEM BOUNDARY

LINK


Actors

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


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


Scenarios

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


Scenarios

‘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.


Notes On The Description

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


Use Cases : include (used to be ‘uses’)

Some use cases may share one or more common steps

Reserve book

Borrow book

borrower

<<includes>>

Check membership

<<includes>>


Use cases : extension

An extension is a significant exception to the normal case

Borrowing refused

borrow book

borrower<<extends>>


Use Cases: generalisation

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 CD

borrow book

borrower

Borrower : books and CDs

Borrower : books only

Simplifying Complex Use Cases Break large/complex use cases down into smaller and

more manageable use cases – is this a good diagram?

Is the previous diagram OK?

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.



Finally

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.


Activity Diagrams


Activity Diagrams overview

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)


The basic notation

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

Process loan


Decision Points and Guards

Decision point : diamond Single entry transition line Multiple exit transition lines

each with Guard (condition) Exit lines must cover all

eventualities

There could be a problem with the decisions in this diagram. What do you think it is?

socks sandals

shoes

[rainy]

[sunny]


Merge Points

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.

sandals

[sunny]

go out

go out UML1

shoes sandals

socks

shoes

[rainy]


result = 1counter = 1

result = counter * resultcounter += 1

[n>1]

[n== 0, n== 1]

[counter <=n]

print ( result ,n )

[counter > n]

In the format

n! = result

Notes

A mathematical formula, showing process flow

n! = n * (n-1) * (n-2) * … * 1


Take-away meal

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.


Take-away meal diagram


Synchronisation

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


Fork and Join

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


Shopping in Argos (assuming all items in stock)

• 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

Fill in form

Items entered into computer

processpayment

Items picked

Sent for collection

Collect items


Synchronization and decisions

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

Another example



Eating dinner

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.


Swimlanes / partitions

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


Swimlanes/ partitions example : library

Member Librarian

Find bookon shelf

Wait in queue

[borrowing]

[returning]

Process loan

Processreturn

[borrowing]

[returning]


Expanding one action : library

Process returnRecord return

Place book back on shelf

Place book In reserved pile

[reserved]

[not reserved]


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

The activity diagram's purpose


The activity diagram's focus

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


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)


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

21/08/2015F21SF1 Use case and Activity diagrams1 Software Engineering Foundations Introduction to...

Documents

Transcript of 21/08/2015F21SF1 Use case and Activity diagrams1 Software Engineering Foundations Introduction to...