Relationships in Use Case Diagrams

Use Case Model Use case diagram Part 2

Use Case Diagram Other Types of Relationships for Use Cases Generalization Include Extend

Components of Use Case Diagram Generalization Relationship Represented by a line and a hollow arrow From child to parent Child use case Parent use case

Example of Relationships

Relationships between Use Cases 1. Include - use cases that are included as parts of other use cases. Enable to factor common behavior. 2. Extend - use cases that extend the behavior of other core use cases. Enable to factor variants.

Includes and Extends Includes Extends You have a piece of behavior that is similar across many use cases A use-case is similar to another one but does a little bit more Break this out as a separate use- case and let the other ones include it Put the normal behavior in one use- case and the exceptional behavior somewhere else Capture the normal behavior Try to figure out what can go wrong in each step Capture the exceptional cases in separate use-cases Examples include Valuation Validate user interaction Sanity check on sensor inputs Check for proper authorization Makes it a lot easier to understand <<include>> <<extend>> base included base extending 05-Use-Cases 6

Use Case Diagram Include Relationship Represents the inclusion of the functionality of one use case within another Arrow is drawn from the base use case to the used use case Write << include >> above arrowhead line

Use Case Diagram Extend relationship Represents the extension of the use case to include optional functionality Arrow is drawn from the extension use case to the base use case Write << extend >> above arrowhead line

Example of Relationships

Examples Include Extend Purchase Item <<include>> Verify Credit card

Benefits of Use Cases Use cases are the primary vehicle for system requirements. Use cases are described using the language of the customer (language of the domain which is defined in the glossary) Use cases provide an easily-understood communication mechanism When requirements are traced, they make it difficult for requirements to fall through the cracks Use cases provide a concise summary of what the system should do at an abstract (low modification cost) level.

Difficulties with Use Cases As functional decompositions, it is often difficult to make the transition from functional description to object description to class design. Since UCs do not talk about classes, developers often wind up in a vacuum during object analysis, and can often wind up doing things their own way, making reuse difficult Use Cases make stating non-functional requirements difficult (where do you say that X must execute at Y/sec?)

Use Case Description Complements Use Case Diagram A breakdown of a single use case (e.g., sequence of steps included in the function Look up item availability ); process logic included In contrast to Use Case Diagram, Use Case Description captures variations of a Use Case Example: Create new order can be done via phone+clerk and via Internet ordering 2 scenarios 13

Level of Use Case Description Three levels of details: UC* Brief description Summary of what system does in response to actor s actions UC Intermediate description Shows steps in use case, if-then UC Full description Includes Brief description, expands intermediate description, shows scenarios * UC=Use Case 14

Brief Description of Use Case Same description that is usually captured in initial Use Case Diagrams 6

Intermediate Use Case Description Telephone Order Scenario for Create New Order Use Case 7

Full Use Case Description Shows steps ( Flow of Events ) broken down to the actor and the system side useful! 8

Use Cases Basics A use case has four mandatory elements: 1.Name: Each use case has a unique name describing what is achieved by the interaction with the actor. EX: "Turn Light On/Off" and "Print Document" are good examples. 2.Brief description: The purpose of the use case should be described in one or two sentences. EX: "This use case controls the selected light bank when instructed by the actor Homeowner. 3.Actor(s) List each actor that participates in the use case. 4.Flow of events: The heart of the use case is the event flow, usually a textual description of the interactions between the actor and the system. The main (basic) flow of events The alternate flows of events 18

Use Cases Basics Optional elements in a Use case: Pre-conditions: Must be present in order for a use case to start. Represent some system state that must be present before the use case can be used. EX: A pre-condition of the "Print Author's Manuscript Draft" use case is that a document must be open. Post-conditions: Describe the state of the system after a use case has run. Represent persistent data that is saved by the system as a result of executing the use case. EX: Post-condition of Register" use case is that the new data is added in the profile of the student. 19

Use Cases Basics Other stakeholders: Other key stakeholders who may be affected by the use case. EX: A manager may use a report built by the system, and may not personally interact with the appear as an actor on the system. yet the manager system in any way and therefore would not 20

A Recommended Template: Use Case Description System: Use Case name: Primary actor: Other actors: Stakeholders: Description: Relationships Includes: Extends: Input: Pre-conditions: Steps: Actor System 1. Actor does. 3. 4. Alternative and exceptional flows: 4.1 . Post-conditions: 2. System does. 21