Lecture 02 - Use Case Diagrams PDF

Preview

Summary

17 qp 12...

Description

Requirements Diagrams: Traditional and OO Models

1

2

USE CASE DIAGRAMS Lecture 02

Use Case Diagram 3

Using Use Case Diagrams 4







Graphical models that summarize information about actors and use cases Use case analysis used to identify and define all business processes that system must support System Analyst/Developer 

Looks at system as whole



Identifies major uses from event table



Identifies functions to be supported by new system



Organizes use cases

Use case diagrams are used to visualize, specify, construct, and document the (intended) behavior of the system, during requirements capture and analysis.  Provide a way for developers, domain experts and end-users to Communicate.  Serve as basis for testing.  Use case diagrams contain use cases, actors, and their relationships. 

Use Cases

Actors 6

5

 

Use cases specify desired behavior. A use case is a description of a set of sequences of actions, including variants, a system performs to yield an observable result of value to an actor.



 



Four Types of Actors

An actor represents a set of roles that users of use case play when interacting with these use cases. Actors can be human or automated systems. Actors are entities which require help from the system to perform their task or are needed to execute the system’s functions. Actors are not part of the system.

Use Cases and Actors 8

7



Primary business actor  





The stakeholder that directly interfaces with the system to initiate or trigger the business or system event. e.g. the bank teller entering deposit information

External server actor  





Primary system actor 



The stakeholder that primarily benefits from the execution of the use case. e.g. the employee receiving the paycheck

The stakeholder that responds to a request from the use case. e.g. the credit bureau authorizing a credit card charge

External receiver actor  

The stakeholder that is not the primary actor but receives something of value from the use case. e.g. the warehouse receiving a packing slip



From the perspective of a given actor, a use case does something that is of value to the actor, such as calculate a result or change the state of an object. Use-Cases is a powerful tool to understand  Who

your users are (including interacting systems) functions the system shall provide  How these functions work at a high level  What

Relationships between Use Cases and Actors

Use Case Diagram 9

10



Use Case Diagram with System Boundary 11

Actors may be connected to use cases by associations, indicating that the actor and the use case communicate with one another using messages.

Use Case of Customer Support System 12

All Use Cases Including Customer 13

Checkpoint 1 - HACS 14







Use Case Diagram - Relationships 15

Homework assignment and collection are an integral part of any educational system. Today, this task is performed manually. What we want the homework assignment distribution and collection system (HACS for short) to do is to automate this process. HACS will be used by the instructor to distribute the homework assignments, review the students’ solutions, distribute suggested solution, and distribute student grades on each assignment. HACS shall also help the students by automatically distributing the assignments to the students, provide a facility where the students can submit their solutions, remind the students when an assignment is almost due, remind the students when an assignment is overdue.

Relationships between Use Cases 16

1.

2.

3.

Generalization - use cases that are specialized versions of other use cases. Include - use cases that are included as parts of other use cases. Enable to factor common behavior. Extend - use cases that extend the behavior of other core use cases. Enable to factor variants.

1. Generalization Relationship

1. Generalization Relationship

17

18





The child use case inherits the behavior and meaning of the parent use case. The child may add to or override the behavior of its parent.

parent

registration

child non-graduate registration

1. Generalization Relationship 19

graduate registration

2. Relationship 20





The actor Order Registry Clerk can instantiate the general use case Place Order. Place Order can also be specialized by the use cases Phone Order or Internet Order.







 

The base use case explicitly incorporates the behavior of another use case at a location specified in the base. The included use case, as far as possible, does not stand alone. It occurs as a part of some larger base that includes it. Documents situation where one use case requires the services of a common subroutine Another use case is developed for this common subroutine A common use case can be reused by multiple use cases base

included

2. Relationship 21

2. Relationship 22



Enables to avoid describing the same flow of events several times by putting the common behavior in a use case of its own.

updating grades

verifying student id

output generating

3. Relationship 23

3. Relationship 24







The base use case implicitly incorporates the behavior of another use case at certain points called extension points. The base use case may stand alone, but under certain conditions its behavior may be extended by the behavior of another use case. Extension use case – a use case consisting of steps extracted from a more complex use case in order to simplify the original case and thus extend its functionality.

base

extending



Enables to model optional behavior or branching under conditions.

Exam copy request

Exam-grade appeal

Include vs. Extend

Include vs. Extend

25

26



Include



You have a piece of behavior that is similar across many use cases  Break this out as a separate use-case and let the other ones “include” it  Examples include 

 

Validation Search

Extend



A use-case is similar to another one but does a little bit more  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-cases25

Checkpoint 2 – Hospital Admissions System

Relationships between Actors 27

Do not try to identify «include» and «extend» relationships in your first cut model. Use «include» to abstract sequences of steps out of the base Use Cases that are useful to the analyst to avoid repetitious descriptions. Use «extend», sparingly, to overlay additional functionality on top of a well-formed Use Case to divide up the complexity of a large and complex Use Case.

28



Generalization.

student

graduate student

non-graduate student

This system serves six types of users: patients, admissions receptionists, floor nurses, medical technologists, physicians, and release receptionists. When a patient comes to the hospital, the patient and admissions receptionist use the system to perform a check-in procedure. Check-in procedures all involve the same steps, such as getting patient information, insurance information, etc. Some check-ins are for inpatients; for these there are additional check-in steps for assigning the patient to a room and bed. The floor nurse uses the system to perform two tasks. First is the task of obtaining a list of all patients on the floor. Second is a task of entering patient notes. The medical technologist also performs two tasks on the system. One is to retrieve the patient record, and the second is to enter lab service notes. The physician performs two tasks as well, one of which is to obtain her rounds schedule and the other is to enter patient notes (which is the same system process used by the floor nurse). Finally, the patient and release receptionist go through the check-out procedure. The system performs a number of queries and updates on a patient’s record.

References 29



Systems Analysis & Design in a Changing World, 6th ed.,  By

John W. Satzinger, Robert B. Jackson and Stephen D. Burd...