Post on 21-Dec-2015
Requirements Analysis 4. 1 Use Case I - 2005b504.ppt
© Copyright De Montfort University 2000All Rights Reserved
INFO2005Requirements Analysis
Use-Cases I
Department of Information Systems
Requirements Analysis 4. 2 Use Case I - 2005b504.ppt
© Copyright De Montfort University 2000All Rights Reserved
Learning Objectives
Introduce the concept of use cases Examine various styles of specification
for use cases Use cases and RUP Consider the use of generalisation. Identify some of the problems with use
cases
Requirements Analysis 4. 3 Use Case I - 2005b504.ppt
© Copyright De Montfort University 2000All Rights Reserved
Use Cases
Developed at Ericsson by Ivar Jacobson to help build long-lived, flexible telecoms systems
Premise: “the most volatile part of a system is its users’ behaviour”
Conclusion: “Model systems from the point of view of its interactions with its users”
Use cases were part of the Objectory method (OOSE) , and now in UML
Requirements Analysis 4. 4 Use Case I - 2005b504.ppt
© Copyright De Montfort University 2000All Rights Reserved
Use Cases
A Use Case is a textual “description of a set of sequences or actions (that a system performs) that yields an observable result of value to a particular actor”– An Actor is a User in a role – Users need not be human, can be other
systems, devices, subsystems etc.
Requirements Analysis 4. 5 Use Case I - 2005b504.ppt
© Copyright De Montfort University 2000All Rights Reserved
Use Cases Use Cases may also be
represented diagrammatically. The use case specification need
not be purely textual but may include state charts, activity diagrams, collaboration diagrams and sequence diagrams.
Requirements Analysis 4. 6 Use Case I - 2005b504.ppt
© Copyright De Montfort University 2000All Rights Reserved
Use case diagram
The elements of a use case may surrounded by a rectangle that represents the containing systems or classifier
UpdateMedicalHistory
Doctor
PrintPrescription
Actor Use case
Requirements Analysis 4. 7 Use Case I - 2005b504.ppt
© Copyright De Montfort University 2000All Rights Reserved
Actors and Use Cases Actors
“They represent everything that needs to exchange information with the system. Since the actors represent what is outside the system, we do not describe them in detail.”
Use Cases“When a user uses the system, she or he will perform a behaviorally related sequence of transactions in a dialogue with the system. We call such a special sequence a use case.”
Jacobson, p.127.
Requirements Analysis 4. 8 Use Case I - 2005b504.ppt
© Copyright De Montfort University 2000All Rights Reserved
Use Cases & Instances Use cases may involve several processes,
but the users expect to be able to carry them all out together.
Use cases represent the general description of what happens when an actor performs a particular task with the system.
Each particular use of a use case is a use instance and each instance may take a different route through use case.
Requirements Analysis 4. 9 Use Case I - 2005b504.ppt
© Copyright De Montfort University 2000All Rights Reserved
Use Cases - applicability Use cases represent the functionality of
system or classifier such as subsystem or class.
A classifer is – A mechanism that describes
behavioral and structural features. Classifiers include interfaces classes, datatypes, and components.
RUP 2000
Requirements Analysis 4. 10 Use Case I - 2005b504.ppt
© Copyright De Montfort University 2000All Rights Reserved
Use Cases - applicability
This new definition (UML v1.3) of a Use Case gives it a wider role than its previous “system-level” definition
Use cases can also be used to describe “business processes”– As Jacobson suggests in The Object
Advantage?
Requirements Analysis 4. 11 Use Case I - 2005b504.ppt
© Copyright De Montfort University 2000All Rights Reserved
Use Case Descriptions
Each Use Case has additional details entered in the data dictionary which describe it.
This includes a text description and a list of the Actors who use it.
Requirements Analysis 4. 12 Use Case I - 2005b504.ppt
© Copyright De Montfort University 2000All Rights Reserved
Use Case Specification
Rational Rose 2000
Requirements Analysis 4. 13 Use Case I - 2005b504.ppt
© Copyright De Montfort University 2000All Rights Reserved
An Example Use Case Diagram
DepositMoney Withdraw
Money
Transfer BetweenAccounts
Bank Customer
An ATM application which offers three use cases is shown.The possible use of a use case by an Actor (Bank Customer in the example below) is shown by an association linking the actor and the use case.
Requirements Analysis 4. 14 Use Case I - 2005b504.ppt
© Copyright De Montfort University 2000All Rights Reserved
Example Use Case Specification for Withdraw Money
“The Bank Customer enters her card and is asked to enter her pin number. The ATM verifies her ID with the system.
If the ID is verified, the ATM asks the Bank Customer to select an option. If the withdraw option is selected the ATM asks the Customer to enter the amount to be withdrawn from Account. The ATM requests the withdrawal amount from the banking system. The system asks the Account to validate the request and, if possible, withdraws the amount.
The system then asks the Dispenser to dispense the appropriate amount.”
Requirements Analysis 4. 15 Use Case I - 2005b504.ppt
© Copyright De Montfort University 2000All Rights Reserved
Alternative Specification for Withdraw Money
The use case can also be shown as a step by step breakdown of action between the actor and the system (or classifier to be precise).
Bank Customer
1. The Bank Customerinserts her card
ATM
2. The ATM asks theCustomer to enter her pin
3. Customer enters pinnumber
4. Systems verifies her ID5. If the ID is verified, theATM asks the BankCustomer to select anoption.
Requirements Analysis 4. 16 Use Case I - 2005b504.ppt
© Copyright De Montfort University 2000All Rights Reserved
Use Case Formats
The format used for WithdrawMoney is described by Alaistair Cockburn as the ‘casual form’ in Writing Effective Use Cases.
He describes various formats - format used should reflect the needs of the project.
Requirements Analysis 4. 17 Use Case I - 2005b504.ppt
© Copyright De Montfort University 2000All Rights Reserved
Use Case Formats
Context of use Scope Level: Summary, User-goal,
Subfunction Primary Actors Stakeholders & Interests
Cockburn, Alistair, Writing Effective Use Cases
Requirements Analysis 4. 18 Use Case I - 2005b504.ppt
© Copyright De Montfort University 2000All Rights Reserved
Use Case Formats Precondition Minimal Guarantees Success Guarantees Trigger Main Success Scenario Extensions Technology and Data Variations List Related Information
Cockburn, Alistair, Writing Effective Use Cases
Requirements Analysis 4. 19 Use Case I - 2005b504.ppt
© Copyright De Montfort University 2000All Rights Reserved
Class Discussion: Use Cases
MakesSaleOf_StockItem
MakesSaleOf_StockItem
CheckOutOperator
CheckOutOperator
Customer
Which is right…
and why?
Requirements Analysis 4. 20 Use Case I - 2005b504.ppt
© Copyright De Montfort University 2000All Rights Reserved
Generalisation
‘A generalization from an actor A to an actor B indicates that an instance of A can communicate with the same kind of use case instances as an instance of B.’ - UML 1.3
For example, the Manager actor can communicate with the same use cases as the StaffMember actor
Requirements Analysis 4. 21 Use Case I - 2005b504.ppt
© Copyright De Montfort University 2000All Rights Reserved
Generalization - Actors
Actor B
Actor A
Generalization
Multiplicity RecordSick
Manager
*1
ClockOn
ClockOff
StaffMember
*
1
*
1
*
*
1
1 *
1
Requirements Analysis 4. 22 Use Case I - 2005b504.ppt
© Copyright De Montfort University 2000All Rights Reserved
Use Cases - Multiplicity
The multiplicity on the previous diagram shows the multiplicity between actor instances and use case instances. – Eg. A Manager instance may communicate
with zero or more instances of the RecordSick use case
– An instance of RecordSick may be communicated from only one Manager instance
Requirements Analysis 4. 23 Use Case I - 2005b504.ppt
© Copyright De Montfort University 2000All Rights Reserved
Use Case-driven Development Use cases drive the whole
development process in the RUP.– The result of the requirements workflow.
– The basis of decisions regarding architecture and component identification and design.
– Source for analysis and design use case realisations (i.e. the models involved).
– The basis of test scripts and test procedures.– The foundation of what is described in the user
manuals.
Requirements Analysis 4. 24 Use Case I - 2005b504.ppt
© Copyright De Montfort University 2000All Rights Reserved
Use Case-driven Development Using use cases involves
– Problem statement and/or domain information is mapped to Use Case specification and diagrams
– Candidate classes are extracted from Use Cases
– Collaboration diagram developed to show collaborations
– Class diagram(s) are built up.
Requirements Analysis 4. 25 Use Case I - 2005b504.ppt
© Copyright De Montfort University 2000All Rights Reserved
Problems with Use Cases
How broad is a Use Case? How deep is a Use Case? How many Use Cases should there be in
some typical system? Can be confused with DFDs Can lead to “main” sub-programs
through misinterpretation of “control” objects
Requirements Analysis 4. 26 Use Case I - 2005b504.ppt
© Copyright De Montfort University 2000All Rights Reserved
Summary
Introduce the concept of use cases Examine various styles of specification
for use cases Use cases and RUP Consider the use of generalisation. Identify some of the problems with use
cases
Requirements Analysis 4. 27 Use Case I - 2005b504.ppt
© Copyright De Montfort University 2000All Rights Reserved
References Cockburn, Alistair, Writing Effective Use Cases,
Addison-Wesley, 2000 Bennett, S., McRobb, S. & Farmer, R. Object-Oriented
Systems Analysis and Design using UML McGraw-Hill 1999, (Ch 5)
Jacobson, I., Booch, G. and Rumbaugh, J. (1999), The Unified Software Development Process, Addison-Wesley, Reading Mass. (Ch 7)
Jacobson I, Christerson M, Jonsson P and Overgaard G (1992), Object-Oriented Software Engineering: A Use Case Driven Approach. (Ch 6)
Rational Unified Process 2000