USE CASE DIAGRAM It is one of the diagram in UML for modeling the dynamic aspects of the system. We can apply the UMl-use-case diagram to visualize the behavior of a system, subsystem or a class. In short we can define a use case diagram as, a diagram that shows a set of use cases and actors and their relationships. Developed and formalised by Ivar Jacobson in Objectory method and adopted by the UML. UML defines a use case as “a set of sequences of actions a system performs that yield an observable result of value to a particular actor”. Contents of the Use-case diagram: It commonly contains • use cases • actors • relationships Generalization Association Dependency Use-Cases: A use-case specifies the behavior of a system when the human interacts with the system. It captures the various functionalities of the system (what the system has to do) without specifying how that behavior is implemented. From this we can define the use-cases as follows Definition: A Use-Case is a definition of a set of sequence of actions, including variants that a system performs to yield a result to the actor. • A use-case describes a set of sequences of actions. Each sequence represents the intersection of the system with the things that exist outside the system. • A use case may have variants we can factor the common, reuseable behavior of a set of usecases by organizing them according to three kinds or relationships. • A Use-case carries some tangible amount of work which yields an observable result to the actors. • We can apply use-cases to the whole system, sub system and even for individual classes. Notation for Use-Case is an Ellipse. Issue Book
Validate User
USECASE
Return Book
Actors:
An actor represents a set of roles that users of use-case play when interacting with the system. Generally, an actor represents, o A role that a human play (Customer, Librarian) o A hardware component (Printer ,Scanner) o An another system (A billing system) o Any external system. An actor is represented as a stick figure. Notation for an Actor: (or)
<
>
Librarian
Librarian <>
< … Stereotype for an actor.
Flow of Events: Each use-case describes what a system (or) sub-system does but it does not specify how it does it. For better understanding of the system functionalities, (or) use-cases we have to describe the flow of events for each use-case. Flow of events are used to specify the behavior of the use-cases. This is the inside view of the system’s functionalities. Through this flow of events, we an define When the use-case starts and ends. When the use-case interacts with the system. What objects are exchanged. Basic flows and alternate flows of the behavior. Example: In the context of ATM systems we can describe the use-case “Validate User” with the following flow of events. Main Flow of Events: -
System prompts the customers for a PIN number. Customer enters a PIN Number. Customer commits the entry by pressing ENTER button. System checks the PIN number for validity. If it is valid, the system acknowledges the entry and thus ending the use-case.
Exceptional Flow of Events: Customer can cancel a transaction at any time by pressing CANCEL button. Customer may enter an invalid PIN number, which causes the use case to restart. Use-Cases and Scenarios: The only relationships that can be defined between actors is the Generalization relation. Symbol : Example : Employee
Manager
Worker
Generalization Relationship between Actors and Usecase: The actor is connected to a set of use-cases to show the interaction between them. The only relationship between an actor and the use-case is Association. Symbol :(
)
Example : Issue Book Librarian <>
Reserve Association book
Relationship between use-cases: We can organize the usecases by specifying the relationships among them. These relationships are specified in order to factor common behavior and also to factor variants. The common relationships among the use-cases are: Generalization Dependency
Include Extend Generalization: Generalization is a relationship in which a child usecase inherits he behavior and meaning of its parent use-case. The child may add to or override the behavior of its parents. Example
Check Password
Validate user
Generalization Retinal scan
Symbol: Generalization among usecase is rendered as a solid directed line with a large open arrowhead. Include Relationship: An include relationship between usecases means that the base use explicitly incorporates the behavior case of another usecase. The included usecase never stand alone. An include relationship is used to avoid describe some behavior in more than one usecase. The include relationship is rendered as a dependency relationship, stereotyped as <>. <> Notation: (-------------->) Example:
Student Member
Borrow Book
Reserve Book
<> Check for reservation <>
Extend Relationship: An extend relationship means that base usecase implicitly incorporates the behavior of another usecase.The base usecase may stand alone, but under certain conditions, its behavior may be extended by the behavior of another usecase. The base usecase may be extended only at certain points called Extension points. We can use the extend relationship to model the part of a usecase. The user may see to be optional, showing variation from the behavior. Notation: Graphically, extend relationship is rendered as a dependency, stereotyped as <>. <> (<----------------)
Borrow book Extn point: limit exceeds
Example:
<> Refuse book
Student Member
Reserve Book
Difference between <> and <>: 1 2 3
4
<> Base usecase explicitly incorporates behavior of another usecase. The usecase which is included can never stand alone. This is used when there is a need of reusing the same usecase by more than one usecase. Example.
<> Base usecase implicitly another usecase.
incorporates
It can stand alone. This is used when the usecases wants to show the exceptional (optional) behavior. Example.
Usecase diagram: UseCase diagram is used to model the static view of the system. We can apply use case diagram in 2 ways. 1. To model the context of a system: This is used to know which actors lies outside the system and interact with it. 2.
To Model the requirements of a system : Modeling the requirements of a systems involves specifying what the system should does from the users point of view.
Steps for drawing usecases: Identify the actors that surround the system. Organize the actors that are similar to one another using generalization relationship. Whenever necessary, provide a stereotype for each other. Identify the various use cases associated with each other. Draw a use case diagram, with all the actors and specify the communication path from each actor to the use-cases.
Example: Check for reservation
Borrow book Library member Issue books
Refuse book
Return books Librarian Reserve books
Staff Member
Student Member
Pay fine
Collect fine Tips For drawing a use-case diagram For
each
use-case
diagram,
give
a
name
that
communicates its purpose. Use clear Layouts. Organize the elements spatially Use notes and colors to draw attention to important features Do not show to many kinds of relationships. The purpose of the use-case diagram are • • • • •
It provides a way for domain experts to specify outside view and developers to construct the inside view. It helps the developers and the end-users to understand the system easily. Elaboration method of discovering user goals or system interactions. It is used in validation, ie to check whether all the requirements are gathered forms basis for test data generation (systems test). It helps to visualize and document the behavior of the system which is understandable by the end-user. Use-cases represent black box functionality of the system.
