use case modeling cen 5016: software engineering © dr. david a. workman school of ee and computer...
TRANSCRIPT
![Page 1: Use Case Modeling CEN 5016: Software Engineering © Dr. David A. Workman School of EE and Computer Science University of Central Florida February 1, 2005](https://reader035.vdocuments.site/reader035/viewer/2022062719/56649ec65503460f94bd23d7/html5/thumbnails/1.jpg)
Use Case Modeling
CEN 5016: Software Engineering© Dr. David A. Workman
School of EE and Computer ScienceUniversity of Central Florida
February 1, 2005(Revised February 14, 2006)
![Page 2: Use Case Modeling CEN 5016: Software Engineering © Dr. David A. Workman School of EE and Computer Science University of Central Florida February 1, 2005](https://reader035.vdocuments.site/reader035/viewer/2022062719/56649ec65503460f94bd23d7/html5/thumbnails/2.jpg)
September 28, 2005 (c) Dr. David A. Workman 2
Requirements Capture• Input
Client approaches Developer with a problem and or product concept. This may be expressed verbally or in the form of a document (Statement of Work (SOW)) (Request for Proposal (RFP))
• ActivitiesDeveloper interacts with Client and Users to elicit product requirements. This
involves face-to-face meetings and possibly the exchange of technical documents. The Developer must determine as completely and precisely as possible the following information:
– cost and time constraints – target system platform and operational environment– user groups– functional capabilities– non-functional constraints: quality and performance– Client and User's needs (as opposed to "wants")
• OutputsA complete understanding of the problem the Client and Users need to have solved.Client should be in agreement with the Developer’s assessment of the problem. This
shared view of the system is captured in the form of a UML Use Case Model.
![Page 3: Use Case Modeling CEN 5016: Software Engineering © Dr. David A. Workman School of EE and Computer Science University of Central Florida February 1, 2005](https://reader035.vdocuments.site/reader035/viewer/2022062719/56649ec65503460f94bd23d7/html5/thumbnails/3.jpg)
September 28, 2005 (c) Dr. David A. Workman 3
Use Case Model• Definitions1
A Use Case is a sequence of actions that the system performs to offer some results of value to a User.
– Use cases drive the whole development process. “They offer a systematic and intuitive means of capturing functional requirements from the user’s perspective.”
– A system has many types of users. Each type of user is define by an actor. Actors may be people or external systems. Actors interact with the product via one or more Use Cases. An actor role is defined by a particular set of use cases performed by that actor to accomplish a particular goal or objective.
– “All actors and uses cases make up a Use Case Model.”
– A good collection of use cases is central to understanding what your users want. Use Cases also present a good vehicle for project planning, because they control iterative development, … it gives regular feedback to users about where the software is going.
– Use cases provide the basis of communication between the client and the developers in planning the project.
1The Unified Software Development Process, by Rumbaugh, Jacobson, and Booch, Addison-Wesley, 1999, 0-201-57169-2.
![Page 4: Use Case Modeling CEN 5016: Software Engineering © Dr. David A. Workman School of EE and Computer Science University of Central Florida February 1, 2005](https://reader035.vdocuments.site/reader035/viewer/2022062719/56649ec65503460f94bd23d7/html5/thumbnails/4.jpg)
September 28, 2005 (c) Dr. David A. Workman 4
Use Case Model
• Definition2 (Fowler)A Use Case captures a typical interaction between a user and a computer system.
– A use case captures some user-visible function.
– A use case may be small or large.
– A use case achieves a discrete objective for the user.
In its simplest usage, you capture a use case by talking to typical users and discussing the various things they might want to do with the system. Take each discrete task or action they want to do, give it a name, and write up a short description.
During the Elaboration phase, this is all you need to do to get started.
2UML Distilled, by Scott & Fowler
![Page 5: Use Case Modeling CEN 5016: Software Engineering © Dr. David A. Workman School of EE and Computer Science University of Central Florida February 1, 2005](https://reader035.vdocuments.site/reader035/viewer/2022062719/56649ec65503460f94bd23d7/html5/thumbnails/5.jpg)
September 28, 2005 (c) Dr. David A. Workman 5
Use Case Modeling Process
ProduceUse Case Model
1.0
Classify Data asInputs/Outputs
1.2
Analyze RQ ForNoun phrases
1.1
Analyze RQ ForUse Cases & Actors
1.3 Allocate Inputs/Outputs/Actors
to Use Cases1.4List of
Noun Phrases
List ofInput Data
List ofOutput Data
List ofUse Cases
List ofActors
Actor/Use CaseRelationships
DetermineRelations Among
Use Cases1.5
Use CaseRelationships
Review WithCustomer/Users
1.6
ReviseWork Products
1.7
Next
Inputs:Problem Statement (SOW)Requirements DocumentInitial Customer/User Mtngs
![Page 6: Use Case Modeling CEN 5016: Software Engineering © Dr. David A. Workman School of EE and Computer Science University of Central Florida February 1, 2005](https://reader035.vdocuments.site/reader035/viewer/2022062719/56649ec65503460f94bd23d7/html5/thumbnails/6.jpg)
September 28, 2005 (c) Dr. David A. Workman 6
Use Case Modeling Process
ProduceUse Case Model
1.0
Allocate Use Case Inputs/Outputs
To Actors1.9
Produce SystemUse Case Diagram
1.8
Revise Use CaseInputs/Outputs
1.10
Determine DataRelationships
1.11Use CaseDiagram
List of ActorInputs to Use Case
List of Use CaseOutputs to Actor
List of ClassesObjects and
Data members
ProduceClass/Object Diagram
1.12
ClassDiagram
Review WithCustomer/Users
1.13
ReviseWork Products
1.14
Next
![Page 7: Use Case Modeling CEN 5016: Software Engineering © Dr. David A. Workman School of EE and Computer Science University of Central Florida February 1, 2005](https://reader035.vdocuments.site/reader035/viewer/2022062719/56649ec65503460f94bd23d7/html5/thumbnails/7.jpg)
September 28, 2005 (c) Dr. David A. Workman 7
Use Case Modeling Process
ProduceUse Case Model
1.0
Define SystemBoundary Objects
For Use Case1.16
Model Use CaseInterface
1.15Define Use Case
Interaction Scenario1.17
Use CaseInterface
ModelUse Case
InteractionFlows
Produce Use Case Communication
Diagram1.18
Use CaseCommunication
Diagram
Review WithCustomer/Users
1.20
ReviseUse Case
1.21
Next
List ofUse Case
InteractionObjects
Produce Use Case Spec
1.19
Use CaseSpec
![Page 8: Use Case Modeling CEN 5016: Software Engineering © Dr. David A. Workman School of EE and Computer Science University of Central Florida February 1, 2005](https://reader035.vdocuments.site/reader035/viewer/2022062719/56649ec65503460f94bd23d7/html5/thumbnails/8.jpg)
September 28, 2005 (c) Dr. David A. Workman 8
Use Case Modeling Process
ProduceUse Case Model
1.0
Review WithCustomer/Users
1.21
ReviseUse Case Model
1.22
CompleteUse Case Model
1.20
Use CaseModel
Review bySQA1.23
Use CaseModel
FinalRevision of
UCM1.24
Place UnderConfig. Mgmt.
1.25
Use CaseModel
ReleaseUCM1.26
Use CaseModel
![Page 9: Use Case Modeling CEN 5016: Software Engineering © Dr. David A. Workman School of EE and Computer Science University of Central Florida February 1, 2005](https://reader035.vdocuments.site/reader035/viewer/2022062719/56649ec65503460f94bd23d7/html5/thumbnails/9.jpg)
September 28, 2005 (c) Dr. David A. Workman 9
Use Case Model OutlineTitle (System Name, Author Name, Assignment, Course, Pub. Date)
– TOC– List of Figures (optional for small documents)
1. System Summary– Overview of System Purpose and Context– Business Case ( business need and how this system will address this need )– System Operation
• Use Case Diagram• Supporting Narrative (explains diagram: operational flow, actor roles )
– System Interfaces ( External Interfaces with Actors )
2. Use Case Specifications1. Purpose ( function from user’s perspective )
• Collaboration diagram (flow of interactions between actors and interface objects )• Narrative summary of use case purpose or function
2. Precondition (system states & triggering events )3. Flow of Events (nominal flow of interaction events between actor and interface objects)4. Alternative Paths (error processing flows; special case flows )5. Post Condition (system states & completion events )6. Special Requirements (non-functional : performance and quality )
3. Requirements Traceability4. Glossary
![Page 10: Use Case Modeling CEN 5016: Software Engineering © Dr. David A. Workman School of EE and Computer Science University of Central Florida February 1, 2005](https://reader035.vdocuments.site/reader035/viewer/2022062719/56649ec65503460f94bd23d7/html5/thumbnails/10.jpg)
September 28, 2005 (c) Dr. David A. Workman 10
Use Case Model: Detail
Title Page and FormatDocument type, System Title, Author, Publication Date, Course, Assignment
Table of Contents (TOC)
Table of Figures (optional)
1. System Summary1. Scope and purpose of document ( Document content, Intended audience )
2. Business case: motivation for building the system; how it meets needs of users and organization
3. Concept of Operation• Use Case Diagram
• Narrative explaining flow of use cases and their relationships. Identifies all actors (and perhaps key internal agents) and introduces their roles with respect to the use case(s) they engage in. Should also identify all major problem data elements consumed, manipulated, or produced by the system.
4. System Interfaces (See Next Slide)• For each interface: identify the actors and use cases that exercise that interface, the
problem data content, flow direction, medium and/or mechanism.
• For each interface: supporting diagrams illustrating actor interface (optional)
![Page 11: Use Case Modeling CEN 5016: Software Engineering © Dr. David A. Workman School of EE and Computer Science University of Central Florida February 1, 2005](https://reader035.vdocuments.site/reader035/viewer/2022062719/56649ec65503460f94bd23d7/html5/thumbnails/11.jpg)
September 28, 2005 (c) Dr. David A. Workman 11
Use Case Model: System Interfaces
Actor UseCase Actor Inputs
System Outputs SystemInterface
MechanismVehicle at
Toll Booth
Pay Toll with Cash
Money (Coins | Bills)
Transaction Receipt
& Access Arm Raised
[& Change]
Interacts withToll Clerk and
Lane AccessArm
On-Line
Transaction
System
Pay Toll with Cash
TransactionAccepted
Cash Transaction
(Amount Paid, Change, Date)
TCP/IP
… … … …
![Page 12: Use Case Modeling CEN 5016: Software Engineering © Dr. David A. Workman School of EE and Computer Science University of Central Florida February 1, 2005](https://reader035.vdocuments.site/reader035/viewer/2022062719/56649ec65503460f94bd23d7/html5/thumbnails/12.jpg)
September 28, 2005 (c) Dr. David A. Workman 12
Use Case Model: Detail
2. Use Case SpecificationsThis section should include a subsection (2.xx) for each use case identified in section 1.3. Each
use case should have the following format and organization. An introductory section should be included giving a diagram and narrative describing system states and their transitions.
1. Purpose: Specify the purpose of the use case – what it accomplishes from the view of the actors involved and the service the system provides these actors. Support with a collaboration diagram .
2. Preconditions: Specify the system states that must hold before the use case is defined or can begin, AND the triggering event(s) that mark the beginning of the use case.
3. Interaction Scenario: In conjunction with collaboration and state diagrams , present the primary or normal flow of interaction events that accomplish the purpose of the use case. The collaboration diagram identifies the analysis classes involved in the scenario.
4. Alternative Scenarios: In conjunction with collaboration and state diagrams , present possible alternative flows of interaction events. This subsection can be used to describe error handling scenarios and/or alternative sub-use cases.
5. Post conditions: Specify the system states that result after the use case has completed, AND the event(s) that mark the end of the use case.
6. Other Requirements: resource constraints, other qualify factors (e.g. reliability).
![Page 13: Use Case Modeling CEN 5016: Software Engineering © Dr. David A. Workman School of EE and Computer Science University of Central Florida February 1, 2005](https://reader035.vdocuments.site/reader035/viewer/2022062719/56649ec65503460f94bd23d7/html5/thumbnails/13.jpg)
September 28, 2005 (c) Dr. David A. Workman 13
Use Case Modeling: Activity Diagram
AcceptPaymentOf NextMotorist
ProduceReceipt
ReleaseVehicle
ReturnChange
Initial??
[over payment]
[exact Amt]
![Page 14: Use Case Modeling CEN 5016: Software Engineering © Dr. David A. Workman School of EE and Computer Science University of Central Florida February 1, 2005](https://reader035.vdocuments.site/reader035/viewer/2022062719/56649ec65503460f94bd23d7/html5/thumbnails/14.jpg)
September 28, 2005 (c) Dr. David A. Workman 14
Use Case Modeling: Communication Diagram
Toll Clerk
Toll Arm
1: Pay Cash
2a: Return Change2b: Return Receipt 3: Raise Access Arm
4: Leave Gate
NOTE: Communication Diagram is UML 2.0 terminology.In earlier versions of UML, these were called Collaboration Diagrams.
![Page 15: Use Case Modeling CEN 5016: Software Engineering © Dr. David A. Workman School of EE and Computer Science University of Central Florida February 1, 2005](https://reader035.vdocuments.site/reader035/viewer/2022062719/56649ec65503460f94bd23d7/html5/thumbnails/15.jpg)
September 28, 2005 (c) Dr. David A. Workman 15
Use Case Model: Detail3. Requirements Traceability
In this section you identify the sources of requirements and enumerate allrequirements statements. A source must be associated with each requirement. This is best presented in the form of a table.
1. List all sources of requirements statements. A source can be a document, an interview with some individual (customer or user or expert), or a web site, etc. Each source should be uniquely identified (by number or acronym ).Ref[1] Customer Requirements for Jiffy Stop Simulation SystemRef[2] Personal interview with Dr. David Workman, CEO of CEN 5016..
2. A Table should be constructed, such as the one shown below, where a statementof the requirement is given (“shall” statement) and a reference to thesource containing or implying the requirement statement.
Requirements Statments Requirements
Source
“The system shall simulate a convenience store customer engaged in the activity of purchasing gasoline from the time the customer leaves the automobile to the time the customer returns to the automobile upon completing the scenario.”
Ref[1] pp12, line 4.
“The pay-by-credit scenario shall support credit cards only – no debit cards.” Ref[2].
![Page 16: Use Case Modeling CEN 5016: Software Engineering © Dr. David A. Workman School of EE and Computer Science University of Central Florida February 1, 2005](https://reader035.vdocuments.site/reader035/viewer/2022062719/56649ec65503460f94bd23d7/html5/thumbnails/16.jpg)
September 28, 2005 (c) Dr. David A. Workman 16
Use Case Model: Detail4. Glossary
The Glossary presents an organized list of problem space terms and their definitions as elicited from the client and system users. This provides the common vocabulary by which all system stake holders communicate. All common synonyms should be included, but the most common synonym should be used consistently through the rest of the document. For example, “clerk” is the most preferred term for the person that processes purchases and interacts with the customer to collect payment for gasoline purchased – this term should be used in the body of the document. However, one should list acceptable synonyms in a format as shown below.
Clerk: the convenience store agent (store employee) who processes each cash transaction for gasoline; configures the gas pump to dispense the appropriate fuel amount, and to produce a sales receipt of the transaction. Synonyms: cashier.
The Glossary should capture all terms that denote problem objects and system operations or use cases. It should capture all actors that externally interact with the system and the terms that pertain to actor interfaces. The Glossary should be used as a central repository of all information that is known about a particular term.
![Page 17: Use Case Modeling CEN 5016: Software Engineering © Dr. David A. Workman School of EE and Computer Science University of Central Florida February 1, 2005](https://reader035.vdocuments.site/reader035/viewer/2022062719/56649ec65503460f94bd23d7/html5/thumbnails/17.jpg)
September 28, 2005 (c) Dr. David A. Workman 17
Use Case Diagram
• Actors: perform user roles • Actions: identify use cases• Connectors: identify actors
that participate in an action.
Actor3
Actor4
SelectCatalog Pay by
Credit Card
Place Order
ArrangePayment
The system to be developed.
association
extends
includes
specialization/ generalization
<extends>
<include>
Seenotes
OrderProduct
<include>
* *
* *
* * * *
Actor1
Actor2
<specializes>
![Page 18: Use Case Modeling CEN 5016: Software Engineering © Dr. David A. Workman School of EE and Computer Science University of Central Florida February 1, 2005](https://reader035.vdocuments.site/reader035/viewer/2022062719/56649ec65503460f94bd23d7/html5/thumbnails/18.jpg)
September 28, 2005 (c) Dr. David A. Workman 18
Use Case ModelActors
An actor is a role that a user plays with respect to the system. An actor is a role that requires the system to perform some function or task on its behalf, and not the converse.
Since a user may play more than one role at different times, it is important to focus on roles, rather than users (job titles ).
Actors carry out Use Cases; conversley, a Use Case may have several actors performing it.
– For large systems, it is easier to identify the actors first and then define the Use Cases each actor would perform.
– Actors do not have to be human, they could be external systems that must interface with the system in question.
– User groups can be characterized or profiled in terms of the actor roles they play.
– Different actors may share some set of Use Cases. This may suggest a need for assigning priorities to actors and/or defining some type of security mechanism to resolve access conflicts; the system may therefore need a mechanism for identifying a particular actor with which it is interacting.
– Actors generally receive value from a Use Case.
![Page 19: Use Case Modeling CEN 5016: Software Engineering © Dr. David A. Workman School of EE and Computer Science University of Central Florida February 1, 2005](https://reader035.vdocuments.site/reader035/viewer/2022062719/56649ec65503460f94bd23d7/html5/thumbnails/19.jpg)
September 28, 2005 (c) Dr. David A. Workman 19
Use Case DiagramsConnector: Association
Bank
Manager
Pay byCredit Card
OrderProduct
* *
* * * *
Customer
Association defines a communication link between actors and the use cases they participate in, or between two or more use cases that have to interact (or share data) to accomplish their task. Associations are not directional, suggesting that interactions are generally bi-directional. However, UML does permit an “initiates” annotation to identify the actor or use case that initiates the interaction. Association is the default relationship when others do not apply.
« initiates »
« initiates »
![Page 20: Use Case Modeling CEN 5016: Software Engineering © Dr. David A. Workman School of EE and Computer Science University of Central Florida February 1, 2005](https://reader035.vdocuments.site/reader035/viewer/2022062719/56649ec65503460f94bd23d7/html5/thumbnails/20.jpg)
September 28, 2005 (c) Dr. David A. Workman 20
Use Case DiagramsConnector: Includes
Bank
Manager
ArrangePayment
BrowseCatalog
* *
* *
* *
Customer
Includes is analogous to “whole-part” relationship between objects. One use case (the “whole”) may require several subordinate processing actions or steps (the “parts”).The subordinate actions are generally use cases themselves, but need not be. The Includesrelation should always be used if the subordinate action defines a necessary step to ensure success of the superior use case, or if the superior use case has sole responsibility for ensuring that the subordinate action is performed.
« initiates » BuyProduct
OrderProduct
« includes »
« includes »
« includes »
![Page 21: Use Case Modeling CEN 5016: Software Engineering © Dr. David A. Workman School of EE and Computer Science University of Central Florida February 1, 2005](https://reader035.vdocuments.site/reader035/viewer/2022062719/56649ec65503460f94bd23d7/html5/thumbnails/21.jpg)
September 28, 2005 (c) Dr. David A. Workman 21
Use Case DiagramsConnector: Extends
FinancialInstitutions
* *
* *
In-houseDealer
Extends implies that one use case is a functional extension of the capabilities of another use case. If A extends B, then A does everything B does and more. Extension usually suggests extending either the potential user base, or extending the functional capability to an existing client base – offering more services – or both.
« initiates »
ExchangeMoney
Play CardGames
Electronically
PlayBlack Jack
« extends »
In-houseGamblers
* *
« initiates »
Casino System
* *
RemoteGamblers
See Notes
![Page 22: Use Case Modeling CEN 5016: Software Engineering © Dr. David A. Workman School of EE and Computer Science University of Central Florida February 1, 2005](https://reader035.vdocuments.site/reader035/viewer/2022062719/56649ec65503460f94bd23d7/html5/thumbnails/22.jpg)
September 28, 2005 (c) Dr. David A. Workman 22
Use Case DiagramsConnector: Generalizes/Specializes
Customer
Generalization is analogous to the superclass – subclass relationship amongobject classes. A generalizes B if B is a special case of A. Specialization is the converse of generalizes, B specializes A.NOTE: the arrow dictates how the relation should be read.
« initiates »Ship
Package
Ship byUPS
Ship byUS Mail
US MailSystem
« specializes »
« generalizes »
Mail Boxes, Etc.
UnitedParcel Service
See Notes
* *
* *
* *
![Page 23: Use Case Modeling CEN 5016: Software Engineering © Dr. David A. Workman School of EE and Computer Science University of Central Florida February 1, 2005](https://reader035.vdocuments.site/reader035/viewer/2022062719/56649ec65503460f94bd23d7/html5/thumbnails/23.jpg)
September 28, 2005 (c) Dr. David A. Workman 23
Use Case DiagramsConnector: Uses
Bank
* *
* *
Customer
Uses defines a relationship where two or more use cases (or actions) share a common function or action. Shared actions need not be use cases per se, but denote significant system-level operations that can be factored to improve system performance. Also,uses should be used to relate a major use case and an optional minor system action orsub- use case.
« initiates »
NYSE
* *
« uses »
e-PayBills
BuyStock
EstablishTelecomm
Link
« uses »