Use Case Diagram The purpose is to communicate the system’s functionality and behaviour to the customer or end user. Mainly used for capturing user requirements Work like a contract between end user and software developers

What it Does? Models the system’s intended functions (use cases) and its surroundings (actors). Defines the outside (actors) and inside (use case) of the system’s behaviour. The same use case diagram is used in requirement analysis, design, implementation and testing.

Elements Actor Represents anything that interacts with the system Use case A sequence of actions a system performs that yields an observable result of value to a particular actor

Use Case Diagram (core components) Actors: A role that a user plays with respect to the system,including human users and other systems. e.g.,inanimate physical objects (e.g. robot); an external system that needs some information from the current system. Use case: A set of scenarios that describing an interaction between a user and a system, including alternatives. System boundary: rectangle diagram representing the boundary between the actors and the system.

Actor Actors are not part of the system. The represent roles a user or the system can play. An actor may actively interchange information with the system. An actor may be a passive recipient of information. An actor can represent a human, a machine or another system. An actor represents a category or a type of a user rather than a physical user.

Finding Actors Who is interested in certain requirement? Where in the organisation is the system used? Who will supply the system with this information, use this information, remove this information? Who will use this function? Who will support and maintain the system? Does the system use an external resource? What actors do the use case need? Does one actor play several different roles? Do several actors play the same role?

Use Case A use case models a dialogue between actors and the system. A use case is initiated by an actor to invoke a certain functionality in the system. A use case is a complete and meaningful flow of events. Taken together, all use cases constitute all possible ways of using the system.

Finding Use Cases What are the tasks of this actor? Will the actor create, store, change, remove or read information in the system? What use case will create, store, change, remove or read this information? Will the actor need to inform the system about sudden, external changes? Does the actor need to be informed about certain occurrences in the system? Does the system supply the business with the correct behaviour? What use cases will support and maintain the system? Can all functional requirements be performed by the use cases?

Sources of Informationfor Use Cases System specification/problem statement Domain relevant literature Interviews with domain expert Personal knowledge of the domain Legacy systems

Use Case Diagram

Use Case Relationship Association: communication between an actor and a use case; Represented by a solid line. Generalization: relationship between one general use case and a special use case (used for defining special alternatives); Represented by a line with a triangular arrow head toward the parent use case.

Use Case Relationship … Include: a dotted line labeled > beginning at base use case and ending with an arrows pointing to the include use case. The include relationship occurs when a chunk of behavior is similar across more than one use case. Use “include” in stead of copying the description of that behavior Extend: a dotted line labeled > with an arrow toward the base case. The extending use case may add behavior to the base use case. The base class declares “extension points”.

Use Case Diagram

Diagram Explanation Pay Bill is a parent use case and Bill Insurance is the child use case (generalization). Both Make Appointment and Request Medication include Check Patient Record as a subtask (include). The extension point is written inside the base case Pay bill; the extending class Defer payment adds the behavior of this extension point (extend).

Use Case Documentation Use cases are documented in A brief description The purpose of the use case in a few lines Detailed flow of events Description of the primary and alternate flow of events that occur when the use case is initiated Both documents are written using the terms that the customer understands.

Flow of Events Each use case Has one normal, basic sequence of transactions. May have several alternative sequences of transactions. Usually has several exceptional sequences of transactions handling erroneous situations. May also have well defined pre- and post-conditions.

Flow of Events … Describe only the events that belong to the use case. Avoid vague terminologies. Should describe How and when the use case starts and ends When the use case interacts with the actors What information is exchanged between an actor and the use case Do not describe the details of the user interface The basic flow of events Any alternate flow of events

Use Case Documentation is for … Customers – approve what the system should do. Users – gain system understanding. System developers – document system behaviour. Reviewers – examine the flow of events. System analysts – provide the basis for analysis and design System tester – used as a base for test cases. Project leader – provide input to project planning. Technical writer – basis for writing the user manual.

Course Registration Example

Scenarios A scenario is an instance of a use case It is one flow through a use case Each use case will have a web of scenarios Primary scenarios (happy day scenarios) Secondary scenarios (rainy day scenarios)

Register for Courses Use Case Scenario John enters the student ID number and the system validates the number. The system asks which semester. John indicates the current semester and chooses to create a new schedule. From a list of available courses, John selects the primary courses English 101, Geology 110, World History 200 and College Algebra 110. He then selects the alternate courses Music Theory 110 and Introduction to Java Programming 180.

Register for Courses Use Case Scenario … The system determines that John has all the necessary prerequisites and adds him to the course rosters. The system indicates that the activity is complete. The system prints the student schedule and sends billing information for four courses to the billing system for processing.

Secondary Scenario Some possible secondary scenarios are: Student does not select 4 primary courses Primary course is not available Primary and secondary courses are not available Cannot add student to the course roster Cannot create the student schedule

How many scenarios? As many as needed to understand the system. Rule of thumb: 80% of the primary scenarios Few of the interesting and high risk secondary scenarios