Date post: | 14-Apr-2015 |
Category: |
Documents |
Upload: | carrie-morales |
View: | 22 times |
Download: | 0 times |
© 2010 Bennett, McRobb and Farmer 1
Use Case DiagramsUse Case Diagrams
Based on Chapter 6: Section 6.6-6.8Bennett, McRobb and Farmer
Object Oriented Systems Analysis and Design Using UML
4th Edition, McGraw Hill, 2010
2
Last Lecture• What is a model?
– A simplified representation that helps us understand something more complicated, e.g., a tube map
• Different types of models used to provide different views of same system, e.g., a person is modelled by a photo, an x-ray, a model of preferences
• Models range in level of detail: As IS development proceeds, models become more detailed
• Diagrams are standardized visual representations used to communicate models.
• Many diagrams can serve to convey a single model, e.g. a model of a solar system may be conveyed with many diagrams.
3
Size of Real IT Systems
Why model Information Systems?
• Student programs typically less than 500 lines (first year)
• up to 5000 lines of Java in following years.
• Commercial systems may be written by large teams of programmers and may contain 100,000- millions, of lines of code.
4
Many types of models in UML• Activity diagrams• Use Case Diagrams• Class Diagrams• Collaboration Diagrams• …There are ~14 types of diagrams in UML
All types of diagrams vary in detail as project processes, e.g., Use Case Diagram ranges from simple to more complex.
UML is for Object-oriented systems development (vs. structured systems approach)
5
Two general types of UML diagramsDiagrams that support :
• Structural (static) view: represent things that must be present in the system, e.g., static structure such as objects, attributes, operations and relationships.
• Behavioural (dynamic) view: represents dynamic behaviour of the system, e.g., showing collaborations among objects and changes to the internal states of objects.
6
The different types of UML diagrams
7
In this module we will cover:
8
In this module we will cover:
A model usually consists of many diagrams of different types
9
A model consists of many diagrams of different types
Analysis Model
Use CasesInterface
Prototypes
RequirementsList
Class diagram (initial draft)
Glossary
Use Case Model
Assign staff to work on
a campaign
Campaign Manager
Add a new advert to
a campaign
Check campaign budget
Find campaign
Accountant
summary Print campaign
invoice
«include»
«extend» «extend»
Print campaign
«include»
«include»
Campaign Management
Use Case DiagramsOne View of the Use Case Model
Assign staff to work on
a campaign
Campaign Manager
Add a new advert to
a campaign
Check campaign budget
Find campaign
Accountant
summary Print campaign
invoice
«include»
«extend» «extend»
Print campaign
«include»
«include»
Campaign Management
10
11
In this lecture you will learn
• Using scenarios to capture functional requirements
• Use case diagram• The notation of use case diagrams• How to draw use case diagrams• How to write use case descriptions
• Requirements lists• How prototyping can be used with use case
modelling
12
Drawing Use Case Diagrams
• Purpose– document the functionality of the system from
the users’ perspective– document the scope of the system– document the interaction between the users
and the system using supporting use case descriptions (behaviour specifications)
13
Notation of Use Case Diagrams
Staff Contact
Change a client
contact
System or subsystem boundary(Subject)
Actor
Use case Communication association
© 2010 Bennett, McRobb and Farmer 14
Requirements as Scenarios
15
What is a Scenario?• Possible interaction between a system and
its users• Specific scenario
– specific data values at each step in the interaction
– test case
• Generalised scenario– cover many specific scenarios
• Word ‘scenario’ most often means specific scenario
16
Specific Scenario• Mrs H wants to register a new student for
Computer Science• Mrs H enters the student details
– A. Patel lives at 29 Devon Lane, Surbiton
• Mrs H enters the registration details– home student, G500, first year, – adviser Prof Robinson
• The system – allocates A. Patel student id 123456789– records A. Patel’s registration details– prints A. Patel’s course registration form, with the
first year G500 recommended programme
17
Generalised Scenario• Administrator wants to enter a student
registration• Administrator enters the student details
– name, address
• Administrator enters the course details– fees level, UCAS code, year of study, adviser
• The system – generates a student id number– records details of the student– prints the course registration form, with the
recommended programme, if any
18
Essential v. Real ScenariosUse cases range in level of detail specified, can
range from ‘essential’ to ‘real’
• Essential scenario (minimal detail) – abstract, ignore user interface, ignores precise
number of steps, free of technology and design assumptions and user interface details
– Only contains essential information
• Real scenario (maximum detail).– how is the interaction achieved?– details of the user interface– specifies concrete steps that assume technology
and design commitments
19
Essential v. Real Scenarios
• Administrator enters the course details– UCAS code
• Administrator chooses the UCAS course code form a drop-down box, with an ‘others’ option which allows the course code and the description
Real
Essential
20
Use Cases• Generalised and essential scenarios
• Number of use cases– up to 80 for complex systems– 20 to 50 for most systems
• Diagram– very simple and abstract– standardised in UML
• Description– ‘structured text’, not standardised
21
Use Case Diagram
CampaignManager
Accountant
Assign staff contact
Add new staffmember
actor
communicationassociation
use case
22
Notation of Use Case Diagrams
• An actor is– user of the system– initiates the interaction– Drawn with a stick figure
• Not all actors are people– can be a connected system
(e.g. Facebook)
Campaign Manager
Invoicing system
© 2010 Bennett, McRobb and Farmer 23
Case Study: Agate
(from Object-Oriented Systems Analysis and
Design; Bennett, McRobb and Farmer)
24
Agate Organisation
A d m in is tration
C redit Co n tro ller
A ccou nts Cle rks
P u rch as in g Ass istant
A cco u ntant
A ccou n ts
G raph ics D es ign ers
C o py W rite rs
E d ito rs
P h otog rap hers
R eso u rce L ib rar ian
A ccou n t M anag ers x 4
C reative C o m p uting
B o ard of D irecto rs
A g ate L td
25
Existing and Proposed Systems
• Existing system:– client management
• record names• assign client contact• campaign
– staff management• names, grades, bonuses
• Redevelop existing system in Java, more functions
26
Organisation’s roles may inform choice of actors
A d m in is tration
C redit Co n tro ller
A ccou nts Cle rks
P u rch as in g Ass istant
A cco u ntant
A ccou n ts
G raph ics D es ign ers
C o py W rite rs
E d ito rs
P h otog rap hers
R eso u rce L ib rar ian
A ccou n t M anag ers x 4
C reative C o m p uting
B o ard of D irecto rs
A g ate L td
The roles in organization give you an idea for possible actors in your use case scenario. Whom you choose to be an actor may be a specific job title, ‘Accountant’, or can be general ‘Creative staff’.
27
Notation of Use Case Diagrams• Use cases
– drawn as ellipses with a name in or below each ellipse
– describe a sequence of actions that the system performs to achieve an observable result of value to an actor
– the name is usually an active verb and a noun phrase
Add a new client
Assign staff to work on campaign
Add a new campaign
28
Notation of Use Case Diagrams
• Communication associations
– line drawn between an actor and a use case– represent communication link between an instance of
the use case and an instance of the actor
Campaign Manager
Add a new client
Assign staff to work on campaign
Add a new campaign
29
Notation of Use Case Diagrams• Subsystems (also called subjects)
– drawn as a rectangle around a group of use cases that belong to the same subject
– in a CASE tool, use cases for different subjects are usually placed in separate use case diagrams
Campaign Manager
Add a new client
Assign staff to work on campaign
Add a new campaign
© 2010 Bennett, McRobb and Farmer 30
Examples
31
Campaign Manager
Add a new client
Assign staff to work on campaign
Record completion of a campaign
Change a client contact
Record completion of an advert
Assign a staff contact
Add a new advert to a campaign
Add a new campaign
Staff Contact
Use case diagrams for Agate
32
Additional descriptions/notations
• Each use case (ellipse) and actor (stick figure) is usually accompanied by a textual actor and use case description. This can be brief description, or can be a step-by-step breakdown of the interaction between the actor and system
• These descriptions are added using the program you are using to draw UML diagrams
33
Campaign Manager
Detailed description…………………
Use Case Diagrams will often be accompanied by more detailed descriptions of actor and use case
CampaignManager
Add new advert to campaign
Add new advert to campaign
Detailed description…………………
So for above Use Case, additional screens in CASE tool will show the following descriptions:
34
Campaign Manager
A Campaign manager is either a Director or an Account Manager. They are responsible for estimating the campaign cost and agreeing it with the client. They are responsible for assigning staff to the team and supervising their work, managing the progress of the campaign, conducting any further budget negotiations, and authorizing the final invoice.
Actor DescriptionCampaignManager
Add new advert to campaign
35
Add a new advert to a campaign
A campaign can consist of many adverts. Details of each advert are entered into the system, including advert cost
Record completion of a campaign
When a campaign is completed, the actual completion date and cost are entered. A record of completion form is printed out for the Accountant as the basis for invoicing the client
Clients have a member of staff assigned to them as their particular contact person.
Assign a staff contact
Change a client contact
Records when the client’ s contact person with Agate is changed.
Agate Use Cases and Descriptions
36
When Agate gets the business for a new campaign, details of the campaign are entered, including the intended finish date and the estimated cost. The manager for that campaign is the person who enters it.
When a new campaign starts, members of staff are assigned to work on it.
Add a new campaign
Assign staff to work on a campaign
When Agate obtains a new client, the full details of the client are entered. Typically this will be because of a new campaign, and therefore the new campaign will be added straight away.
Add a new client
When an advert is completed, the actual date is entered.
Record completion of an advert
Agate Use Cases
37
Accountant
Record client payment
Change the rate for a staff grade
Add a new member of staff
Add a new staff grade
Change the grade for a member of staff
38
Add a new member of staffWhen a new member of staff joins Agate, his or her details are recorded. He or she is assigned a staff number, and the start date is entered. Start date defaults to today’ s date. The starting grade is entered.
Accountant Use Case descriptions
39
Add a new staff grade
Change the rate for a staff grade
Change the grade for member of staff
Record client payment
Accountant Use Case descriptions
40
Add a new staff gradeOccasionally a new grade for a member of staff must be added. The name of the grade is entered. At the same time, the rate for that grade and the rate start date are entered; the date defaults to today’ s date.
Change the rate for a staff gradeAnnually the rates for grades are changed. The new rate for each grade is entered, and the rate start date set (no default). The old grade is retrieved and the rate finish date for that grade rate set to the day before the start of the new rate.
Accountant Use Case descriptions
41
Record client payment. When a client pays for a campaign, the payment amount is checked against the actual cost and the date paid is entered.
Change the grade for a member of staff When a member of staff is promoted, the new grade and the date on which they start on that grade are entered. The old staff grade is retrieved and the finish date set to the day before the start of the new one.
Accountant Use Cases
42
Good Use Cases• Identifying use cases
– do not distinguish too many, especially at first
• Title– verb and noun combination
• Language– ‘user’ language, not computer-speak
– avoid ‘click’, ‘input’, ‘menu box’
© 2010 Bennett, McRobb and Farmer 43
Detailed Description of a Use Case
• add more detail• … structured description• … following a template
44
Normal Flow• Normal flow (or path)
– steps of the interaction
– distinguish between the user’s request and the system’s response
actor system
request
response
45
Use case description: Add a New Advert to a Campaign
System Response
2. Displays campaign budget, total cost of adverts paid for and total estimated cost of adverts not paid for.
4. Creates new advert and adds to list of adverts for that campaign.
Actor Action
1. Campaign manager checks campaign budget.
3. Campaign manager enters details of advert including estimated cost.
Alternative Courses
Step 4. The advert will exceed the budget and a budget extension request is generated.
Another version of Use Case description
CampaignManager
Add new advert to campaign
46
Use case description: Add a New Advert to a Campaign
In comparison: A more general Use Case description. Use cases get more detailed as analysis progresses
CampaignManager
Add new advert to campaign
A campaign can consist of many adverts. Details of each advert are entered into the system, including advert cost
47
Additional descriptions for use cases: Alternative Flow
• Variation to some steps of the normal flow
• Alternative flow allows several related scenarios to be combined
• Admin. enters the student details
• Admin updates the student details
Single use case: admin enters/updates student details
48
Additional descriptions for use cases: Exceptions
• Errors, and what happens when they occurs
• Exceptions v. Alternatives– exception is abnormal – alternative is just different to the normal interaction– an alternative path could be a separate Use Case
• Caution– some versions of Use Cases don’t have
exceptions– don’t have too many exceptions
49
Additional descriptions for use cases: Pre- and Postconditions
• Precondition– must be true, – … otherwise the interaction is not possible
• Postcondition– how the system is changed by the
interaction– applies to all alternatives– e.g. ‘customer order is recorded’
50
Suggested Detailed Use Case Description Template
• Use case name• Description• Precondition: required starting state of system
(optional)• Normal flow of events (actions and system
responses)• Alternative flows (optional)• Postcondition: ending state of system (optional)• Exceptions (optional)
51
Suggested Detailed Use Case Description Template
• Use case name• Description• Precondition: required starting state of system
(optional)• Normal flow of events (actions and system
responses)• Alternative flows (optional)• Postcondition: ending state of system (optional)• Exceptions (optional)
Difference between exceptions and alternative flows is subtle, you will not be required to distinguish these in exams
53
Good Use Cases• Distinguish
– user actions– system response
• Use user language– avoid ‘click’, ‘input’, ‘menu box’, ‘database’
For analysis:– abstract as possible– avoid user interface details
© 2010 Bennett, McRobb and Farmer 54
Additional Use Case notations:
include and extend
55
Notation of Use Case Diagrams
• Dependencies– Extend and Include relationships between use
cases– shown as stereotyped dependencies– stereotypes are written as text strings in
guillemets: «extend» and «include»
56
«include»
• Common steps can be included in other use cases
• Common steps documented as a normal use case
• Referenced by name in ‘using’ use case
A
Common Sequence
«include»
«include»
B
57
CampaignManager
Assign staff to Work on a Campaign
Add a New Advertto a Campaign
Find Campaign
«includes»
«includes»
«include»
58
Detailing «include»
• Possible template for included use case
Use case: Update widget details
Description: Update the details about the widgetNormal flow: 1. Widget details are displayed with ‘Find Widget Details’ 2. User enters new widget price 3. …..
Use case: Find Widget Details
Description: Display the basic details about the widgetNormal flow: 1. User requests list of widgets 2. System displays the available widgets 3. User chooses the widget identifier 4. System displays widget details
• Informal approach – not too much ‘apparatus’
59
«extend»
• One use can extend the functionality of another
• Extension may be available to another actor
Basic Use Case
Extension BExtension A
Extension Point
«extend» «extend»
60
Detailing «extend»
• Possible template for extended use case
Use case: Display details
Description: Display the basic details
Normal flow: 1. User enters widget name 2. System displays the details
Extension points: When the system displays details (step 2): Print details Confidential display
Use case: Confidential display
Description: Display the basic details
Normal flow: Extends ‘Display details’ 1. User enters authorisation code 2. System displays confidential data
• Informal approach – not too much ‘apparatus’
61
«extends»
CampaignManager
Accountant
Check Campaign Budget
Print CampaignInvoice
Print CampaignSummary
System Displays Balance
«extends» «extends»
62
Actor Generalisation• Some actors
represent roles which generalise another role
• Use cases available to the ‘Staff Member’ are also available to the ‘Campaign Manager’
Staff Member
Staff ContactCampaign Manager
© 2010 Bennett, McRobb and Farmer 63
Developing Use Cases
64
Use Case Iterations• Use cases can be developed in stages• Step 1: Scope
– identify actors and use cases, short descriptions – objective is to scope system
• Step 2: Details– detailed descriptions– break out some detailed use cases
• Step 3: Structure– structure use cases using ‘extend’ and ‘include’– select the use cases that are to be implemented,
discard non-essential functionality
65
Other Uses of Scenarios• Scenario as a test case
– test cases derived from use cases
• Development increments– implement, test & deliver sets of use cases
• Scenarios can be used to analyse other models– we will see the how scenarios analyse an
object model, using sequence diagrams
66
Use Case Descriptions
• Many projects use templates– name of use case– pre-conditions– post-conditions– purpose– description– alternative courses– errors
67
Drawing Use Case Diagrams
• Identify the actors and the use cases• Prioritize the use cases• Develop each use case, starting with the
priority ones, writing a description for each• Add structure to the use case model:
generalization, include and extend relationships and subsystems
68
Prototyping
• Use case modelling can be supported with prototyping
• Prototypes can be used to help elicit requirements
• Prototypes can be used to test out system architectures based on the use cases in order to meet the non-functional requirements
69
Prototyping
• For user interface prototypes, storyboarding can be used with hand-drawn designs
70
Prototyping
• User interface prototypes can be implemented using languages other than the one that the system will be developed in
OKOK QuitQuit
Campaign:
Campaign Selection
Holborn MotorsLynch PropertiesYellow Partridge Zeta Systems
Client:
Spring Jewellery Campaign 2003Spring Jewellery Campaign 2004Spring Jewellery Campaign 2005Summer Collection 2004
Campaign:
Campaign Selection
Holborn MotorsLynch PropertiesYellow Partridge Zeta Systems
Client:
Yellow Partridge
Spring Jewellery Campaign 2003Spring Jewellery Campaign 2004Spring Jewellery Campaign 2005Summer Collection 2004
Campaign:
Campaign Selection
Holborn MotorsLynch PropertiesYellow Partridge Zeta Systems
Client:
Yellow Partridge
Spring Jewellery Campaign 2002
Dialogue initialized. User selects Client. Campaigns listed.
User selects Campaign.
OKOK QuitQuit OKOK QuitQuit
71
Summary
In this lecture you have learned about:
• The purpose of use case diagrams
• The notation of use case diagrams
• How to draw use case diagrams
• How to write use case descriptions
• How prototyping can be used with use case modelling