21/08/2015f21sf1 use case and activity diagrams1 software engineering foundations introduction to...
Post on 24-Dec-2015
220 Views
Preview:
TRANSCRIPT
19/04/23 F21SF1 Use case and Activity diagrams 1
Software Engineering Foundations
Introduction to UMLUse Cases
Activity Diagrams
Monica Farrow EM G30 email : M.Farrow@hw.ac.ukMaterial available on Vision
Dept ofComputerScience
19/04/23 F21SF1 Use case and Activity diagrams 2
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
19/04/23 F21SF1 Use case and Activity diagrams 3
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?
19/04/23 F21SF1 Use case and Activity diagrams 4
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
19/04/23 F21SF1 Use case and Activity diagrams 5
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
19/04/23 F21SF1 Use case and Activity diagrams 6
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
19/04/23 F21SF1 Use case and Activity diagrams 7
Use CasesHow people interact with the
system
19/04/23 F21SF1 Use case and Activity diagrams 8
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.
19/04/23 F21SF1 Use case and Activity diagrams 9
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
19/04/23 F21SF1 Use case and Activity diagrams 10
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
19/04/23 F21SF1 Use case and Activity diagrams 11
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
19/04/23 F21SF1 Use case and Activity diagrams 12
Use Case Diagram - notation
borrow bookborrower
ACTOR
USE CASE
SYSTEM BOUNDARY
LINK
19/04/23 F21SF1 Use case and Activity diagrams 13
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
19/04/23 F21SF1 Use case and Activity diagrams 14
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
19/04/23 F21SF1 Use case and Activity diagrams 15
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
19/04/23 F21SF1 Use case and Activity diagrams 16
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.
19/04/23 F21SF1 Use case and Activity diagrams 17
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
19/04/23 F21SF1 Use case and Activity diagrams 18
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>>
19/04/23 F21SF1 Use case and Activity diagrams 19
Use cases : extension
An extension is a significant exception to the normal case
Borrowing refused
borrow book
borrower<<extends>>
19/04/23 F21SF1 Use case and Activity diagrams 20
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.
19/04/23 F21SF1 Use case and Activity diagrams 22
19/04/23 F21SF1 Use case and Activity diagrams 23
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.
19/04/23 F21SF1 Use case and Activity diagrams 24
Activity Diagrams
19/04/23 F21SF1 Use case and Activity diagrams 25
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)
19/04/23 F21SF1 Use case and Activity diagrams 26
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
19/04/23 F21SF1 Use case and Activity diagrams 27
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]
19/04/23 F21SF1 Use case and Activity diagrams 28
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]
19/04/23 F21SF1 Use case and Activity diagrams 29
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
19/04/23 F21SF1 Use case and Activity diagrams 30
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.
19/04/23 F21SF1 Use case and Activity diagrams 31
Take-away meal diagram
19/04/23 F21SF1 Use case and Activity diagrams 32
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
19/04/23 F21SF1 Use case and Activity diagrams 33
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
19/04/23 F21SF1 Use case and Activity diagrams 34
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
19/04/23 F21SF1 Use case and Activity diagrams 35
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
19/04/23 F21SF1 Use case and Activity diagrams 36
19/04/23 F21SF1 Use case and Activity diagrams 37
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.
19/04/23 F21SF1 Use case and Activity diagrams 38
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
19/04/23 F21SF1 Use case and Activity diagrams 39
Swimlanes/ partitions example : library
Member Librarian
Find bookon shelf
Wait in queue
[borrowing]
[returning]
Process loan
Processreturn
[borrowing]
[returning]
19/04/23 F21SF1 Use case and Activity diagrams 40
Expanding one action : library
Process returnRecord return
Place book back on shelf
Place book In reserved pile
[reserved]
[not reserved]
19/04/23 F21SF1 Use case and Activity diagrams 41
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
19/04/23 F21SF1 Use case and Activity diagrams 42
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
19/04/23 F21SF1 Use case and Activity diagrams 43
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)
19/04/23 F21SF1 Use case and Activity diagrams 44
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
top related