Use Case Modeling COP 4331 and EEL 4884

Use Case Modeling COP 4331 and EEL 4884 OO Processes for Software Development © Dr. David A. Workman School of Computer Science University of Central Florida February 1, 2005 February 18, 2010 (c) Dr. David A. Workman

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)) • Activities Developer 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") • Outputs A 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. February 18, 2010 (c) Dr. David A. Workman 2

Use Case Model • Definitions 1 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. 1 The Unified Software Development Process, by Rumbaugh, Jacobson, and Booch, Addison-Wesley, 1999, 0 -201 -57169 -2. February 18, 2010 (c) Dr. David A. Workman 3

Use Case Model • Definition 2 (Fowler) A Use Case captures a typical interaction between a user and a computer system. – A use 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. 2 UML Distilled, by Scott & Fowler February 18, 2010 (c) Dr. David A. Workman 4

Use Case Modeling Process Inputs: Problem Statement (SOW) Requirements Document Initial Customer/User Interviews 1. 1 Analyze RQ for Noun Phrases 1. 0 Start Use Case Modeling List of Noun Phrases List of Use Cases List of Actors 1. 3 Analyze RQ for Use Cases (Verb Phrases) & Actors 1. 4 Allocate Inputs/ Outputs/Actors to Use cases 1. 10 Decide on Boundary Objects for each Input & Output Use Case Spec Next slide List of Use Case Outputs to Actor/Use Case Relationships Use Case Interaction Scenario 1. 5 Determine relationships among Use cases Activity Diagram Of Dynamic Use Case Flows February 18, 2010 1. 11 Develop Interaction Scenarios for this Use Case List of Actor Inputs to Use Case 1. 2 Classify Nouns as Inputs/Outputs and Actors List of Input Data List of Output Data Use Case Communication Diagram 1. 12 Write Use Case Specification 1. 9 For this use case determine Inputs/Outputs for each Actor [ more use cases need modeling ] 1. 8 Select a Use Case 1. 6 Review with customer/users [need changes] 1. 7 Revise Work Products Use Case Diagram (c) Dr. David A. Workman 5

Use Case Modeling Process 1. 13 Construct Requirements Mapping Table For Functional And Non-Functional Requirements 1. 14 Write Glossary 1. 17 Revise Work Products [need changes] 1. 15 Produce Use Case Model 1. 16 Review with customer/users Start Analysis Modeling Use Case Model February 18, 2010 (c) Dr. David A. Workman 6

Use Case Analysis: Concordance Generator Phrase from Problem Statement Classification Develop a software system (Concordance Generator) Name of System Reads an ASCII (input) File Use Case: read input file (Actor => File System) Use Case: read input file name (Actor => User) Constructs a concordance of unique words Use Case: Construct Concordance Use Case: Find unique words Output Concordance to ASCII file Use Case: create output file (Actor => File System) Use Case: read output file name (Actor => User) The output shall contain a unique word followed by a list of all references to its use in the input file. Use Case: collect word references Order output alphabetically by word. Use Case: sort words A word shall consist of …. Specification (definition) of a word object Specification (definition) of word delimiters characters A reference to a word shall … Specification (definition) of a word reference in terms of line and column. Other details of the output format are implied by example. (See below) Non-functional formatting requirements. Reference count output for each word. Use Case: report number of references to each word in addition to listing them Count and report total number of words Use Case: Count and report total number of lines Use Case: February 18, 2010 (c) Dr. David A. Workman 7

Use Case Modeling: Concordance Generator Use Case Inputs Outputs Actors Name Input File name Prompt and error messages User Name Output File name Prompt and error messages User Read (parse) input file lines Words and their references File System Construct concordance Words and references Unordered concordance NA Sort concordance Unordered concordance Ordered concordance NA Count lines Line tally File System Count words Word tally NA Output Concordance, Line and Word tallies Ordered concordance Formatted concordance on output file File System February 18, 2010 (c) Dr. David A. Workman 8

Use Case Model Outline Title (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 (static view of system, use cases, and actors) Activity Diagram showing flow of use cases at the system level. Supporting narrative (explains diagrams: operational flow, actor roles ) System Interfaces ( External Interfaces with Actors ) 2. Use Case Specifications (one subsection for each use case) 1. Purpose ( function from user’s perspective ) • • 2. 3. 4. 5. 6. Communication diagram (flow of interactions between actors and system boundary objects ) Narrative summary of use case purpose or function Precondition (system states (data available) & triggering events ) Flow of Events (nominal flow of interaction events between actor and interface objects) Alternative Paths (error processing flows; special case flows ) Post Condition (system states (data produced) & completion events ) Special Requirements (non-functional : performance and quality ) 3. Requirements Traceability 4. Glossary February 18, 2010 (c) Dr. David A. Workman 9

Use Case Model: Detail Title Page and Format Document type, System Title, Author, Publication Date, Course, Assignment Table of Contents (TOC) Table of Figures (optional) 1. System Summary 1. 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) February 18, 2010 (c) Dr. David A. Workman 10

Use Case Model: Detail 2. Use Case Specifications This 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). February 18, 2010 (c) Dr. David A. Workman 11

Use Case Modeling: Toll Gate Diagram Toll Gate System ** Pay Toll by Epass Motorist <specializes> Pay Toll ** Generate Toll Transaction Make Change <extends> ** Cash Motorist <uses> <specializes> Pay Toll by Cash Toll Transaction Processing System <uses> Pick Up Cash Receipts ** Courier Service Use Case Diagram of Use Case Flow February 18, 2010 (c) Dr. David A. Workman 12

Use Case Modeling: Toll Gate Generate Epass Transaction Accept Epass Payment of Next Motorist Initial Courier Picks Up Daily Cash Receipts Accept Cash Payment of Next Motorist Release Epass Vehicle Activity Diagram of Use Case Flow Generate Currier Transaction ? ? [exact Amt] [over payment] Produce Receipt Generate Cash Transaction Release Cash Vehicle Return Change February 18, 2010 (c) Dr. David A. Workman 13

Use Case Modeling: Toll Gate Communication Diagram of Use Case: Pay Toll by Cash (see Notes) Toll Clerk 1: Pay Cash 2 a: Return Change 2 b: Return Receipt Cash Motorist 3: Raise Access Arm 4: L eav e Ga te 3: Lower Access Arm Exit Access Arm February 18, 2010 Gate Exit Sensor Purpose: To process motorists who pay tolls with cash. Preconditions: Motorist next to be served in Cash lane arrives at Toll Clerk booth. Exit access arm is in the down position. Nominal Scenario: (1) Motorist hands Toll Clerk an amount of cash. (2 a) If cash exceeds toll, Toll Clerk returns the difference in change; (2 b) The Toll Clerk hands motorist a receipt for the cash transaction. (3) The Toll Clerk raises access arm to exit lane. (4) Motorist leaves gate via exit lane. (5) Gate sensor lowers arm to exit lane. Alternate Scenario 1: (1) If motorist has insufficient cash for toll, then (2) Toll Clerk asks motorist for Credit Card. (3) Motorist hands Toll Clerk a Credit Card. (4) Toll Clerk returns a credit transaction receipt. (5)-(7) Same as (3)-(5) of Nominal scenario Alternate Scenario 2: (1) If motorist has no valid means of payment, (2) Toll Clerk asks motorist for drivers license. (3) Motorist hands Toll Clerk a drivers license. (4) Toll Clerk asks motorist to fill in an IOU voucher. (5) Motorist hands Toll Clerk a completed IOU voucher. (6)-(8) Same as (3)-(5) of Nominal scenario. Postcondition: Next motorist has egressed the gate via exit lane. The Exit Access Arm is in the down position. (c) Dr. David A. Workman 14

Use Case Model: Detail 3. Requirements Traceability In this section you identify the sources of requirements and enumerate all requirements 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 System Ref[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 statement of the requirement is given (“shall” statement) and a reference to the source 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] pp 12, line 4. “The pay-by-credit scenario shall support credit cards only – no debit cards. ” February 18, 2010 (c) Dr. David A. Workman Ref[2]. 15

Use Case Model: Detail 4. 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. February 18, 2010 (c) Dr. David A. Workman 16

Use Case Diagram The system to be developed. ** Select Catalog Actor 1 <extends> ** Pay by Credit Card <specializes> Actor 3 Place Order ** <include> Arrange Payment ** Order Product Actor 2 Actor 4 See notes • • • Actors: perform user roles Actions: identify use cases Connectors: identify actors that participate in an action. February 18, 2010 (c) Dr. David A. Workman association extends includes specialization/ generalization 17

Use Case Model Actors 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; conversely, 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. February 18, 2010 (c) Dr. David A. Workman 18

Use Case Diagrams Connector: Association ** Pay by Credit Card Bank Customer « initiates » ** ** Order Product Manager « initiates » 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. February 18, 2010 (c) Dr. David A. Workman 19

Use Case Diagrams Connector: Includes Arrange Payment ** « includes » ** « initiates » Buy Product « includes » Order Product Customer Bank Browse Catalog ** Manager 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 Includes relation 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. February 18, 2010 (c) Dr. David A. Workman 20

Use Case Diagrams Connector: Extends War Game Training System ** Simulate Battle Commander « extends » Inspect Triage Facility Extends implies that one use case is an optional functional extension to another use case. If A extends B, then A is an optional (and unnecessary) use case that performs some additional service not normally included in B. February 18, 2010 (c) Dr. David A. Workman 21

Use Case Diagrams Connector: Generalizes/Specializes See Notes Mail Boxes, Etc. ** Ship by US Mail System ** « generalizes » « initiates » Customer Ship Package « specializes » Ship by UPS ** United Parcel Service Generalization is analogous to the superclass – subclass relationship among object 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. February 18, 2010 (c) Dr. David A. Workman 22

Use Case Diagrams Connector: Uses ** Buy Stock ** NYSE « uses » « initiates » Customer Establish Telecomm Link « uses » e-Pay Bills ** Bank 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. February 18, 2010 (c) Dr. David A. Workman 23