Lesson 02:Use Case Diagrams

Eng Marwa Ali EissaSoftware Developer

Email:marwa84eissa@gmail.comYou can Also Find Me on Facebook

Outline

Justify the need for a Use Case diagram

Identify and describe the essential elements in a UML

Use Case diagram

Identifying the Actors in a System.

Identifying Use Cases in a System

Create a Use Case Diagram that shows the Use Cases in your system.

Recognize and document use case dependencies using UML notation for extends, includes, and generalization

Use Case Diagram

Built in early stages of development

 Purpose

Specify the context of a system

Capture the requirements of a system

Identify external and internal factors influencing the system

Validate a systems architecture

Drive implementation and generate test cases

Developed by analysts and domain experts

Use Case Diagram – Cont.

A Use Case diagram is one of the UML diagrams that uses the Use Case - Driven approach for modeling the dynamic aspects of systems

A Use Case Driven Approach to software development is an approach where the focus of the requirements of a system is meeting specific needs that Users of the System Under Development (SUD) have. This approach helps ensure that Customers get the software that they want.

What is a use case?

A case of a use of the system/product

Describes the system's actions from a the point of view of a user

The specification of actions, including variant sequences and error sequences that a system, subsystem, or class can perform by interacting with outside actors.

The specification of how a system interacts with external actors

Specifies one aspect of the behavior of a system, without specifying the structure of the system

Is oriented toward satisfying a user's goal

A complete set of use cases = system requirements

How do use case diagrams fit in?

Elements of Use Case Diagram

Actor Is a person , organization , or external system that plays a role in one or more interactions with the system

 Actors Usually represented with a stick figure

Actor triggers use case Actor has responsibility toward the system (inputs), and Actor have expectations from the system (outputs).

Use Cases Are the sequence of action that can be provided as a measurable value

to an Actor. These Use Cases are represented using ovals that are labeled with verbs that represent the system’s functions

Each Actor must be linked to a use case, while some use cases may not be linked to actors.

Elements of Use Case Diagram

Associations

Defines the relationship of an Actor with the Use Cases of the system ; Represented by a solid line.

System Boundary BoxIndicates the scope of the system functions with a rectangle drawn around the Use Cases. The Use Cases inside the rectangle represent the functionality that you intend to implement. Place Actors outside the System’s boundaries.

Use Case

Use Case

PackagesIs a mechanism that allows you to organize model elements such as Use Cases into groups.

Identifying the Actors in a System

Actors Software systems are built to be used by people or machines.

Any person or machine that interacts with the System Under Development is called an Actor. Actors are the users of a system. An Actor may have one or more roles when using or interacting with the system. In such cases, each role is considered to be a separate Actor.

An actor represents a role that a user can play, but NOT a specific user 

Types of Actors

Human Actors Are the people using the system who have a particular purpose or task to accomplish.

Machine Actors Are the machines that interact with the computer.

Primary Actors Primary actors are those who use the system’s main functions,

deriving benefits from it directly. Typically, the Primary Actor initiates functionality with a System.

Primary actors are completely outside the system and drive the system requirements Primary actors use the system to achieve an observable user goal

Types of Actors – cont.

Secondary Actors An Actor who is an incidental user of the system. Typically this

includes Actors who serve in maintenance roles. Secondary actors play a supporting role to facilitate the primary

actors to achieve their goals.

Secondary actors often appear to be more inside the system than outside Secondary actors are usually not derived directly from the statement of requirements. Hence, the designer can have more freedom in specifying

the roles of these actors Usually found on the right of the system (primary on the left)

Use Case Diagram :Actors

Actors are treated like classes and thus can be generalized

Finding Actors [1]

External objects that produce/consume data: Must serve as sources and destinations for data Must be external to the system

Finding Actors [2]

Ask the following questions: Who are the system’s primary users?

Who requires system support for daily tasks?

Who are the system’s secondary users?

What hardware does the system handle?

Which other (if any) systems interact with the system in question?

Do any entities interacting with the system perform multiple roles as actors?

Which other entities (human or otherwise) might have an interest in the system's output?

Identifying Use Cases in a System

Use Case:• A particular task that a system can do for Actors.

Task:• A function to be performed an objective. This is not an official

UML word. The official word is Use Case.

Step:• One of a series of actions that is a stage in a process.

Sub-Task:• A function that is to be performed as a sub-process of a

higher level task or another sub-task.

For example, when a user uses an ATM, the task might be withdrawingmoney from the account. On the other hand, inserting the ATM card into the ATM is not a task; it is a step or subtask along the way to accomplishing the task

Example Use Case Diagram : Example #1

Example Use Case Diagram : Example #2

Relationships in use-case diagrams

Association relationships Generalization relationships

One element (child) "is based on" another element (parent)

Include relationshipsOne use case (base) includes the functionality of another (inclusion case)Supports re-use of functionality

Extend relationshipsOne use case (extension) extends the behavior of another (base)

Generalization relationships

A use case generalization shows that one use case is simply a special kind of another.

In UML modeling, a generalization relationship is a relationship in which one model element (the child) is based on another model element (the parent). Generalization relationships are used in class, component, deployment, and use-case diagrams to indicate that the child receives all of the attributes, operations, and relationships that are defined in the parent.

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

Generalization relationships – Example #1

The following figure illustrates an e-commerce application for a Web site that sells a variety of merchandise. The application has an InventoryItem class that is a parent class (also called a superclass). This class contains the attributes, such as Price, and operations, such as setPrice, that all pieces of merchandise use.

After defining the parent class, a child class (also called a subclass) is created for each type of merchandise, such as books and DVDs. The book class uses the attributes and operations in the inventory class and then adds attributes such as author and operations such as setAuthor. A DVD class also uses the attributes and operations in the inventory class, but it adds attributes such as manufacturer and operations such as setManufacturer, which are different from those in the book class.

Generalization relationships – Example #2

Include relationships

In the process of developing a use case model, we may discover that some use cases share common behaviors.

There are also situations where some use cases are very similar but they have some additional behaviors.

For example, Withdraw Money and Deposit Money both require the user to log-on to an ATM system

Include relationships – cont.

Include relationships – cont.

Include relationships are used when two or more use cases share some common portion in a flow of events

This common portion is then grouped and extracted to form an inclusion use case for sharing among two or more use cases

Most use cases in the ATM system example, such as Withdraw Money, Deposit Money or Check Balance , share the inclusion use-case Login Account 

Include relationships – cont.

In UML modeling, an include relationship is a relationship in which one use case (the base use case) includes the functionality of another use case (the inclusion use case). The include relationship supports the reuse of functionality in a use-case model.

You can add include relationships to your model to show the following situations: The behavior of the inclusion use case is common to two or more use

cases. The result of the behavior that the inclusion use case specifies, not the

behavior itself, is important to the base use case.

a Use Case that is a subtask of another Use Case

a Use Case that uses the functionality of another Use

Case

Include relationships – Example #1

In an ATM, the process of Login can be thought of as a subtask of many different Use Cases. It can be used when a person Withdraws Money, Deposits Money or Checks Balance .You can draw this in a Use Case diagram.

Include relationships – Example #2

In an ATM, the process of printing a receipt can be thought of as a subtask of many different Use Cases. It can be used when a person withdraws money or when he deposits money. It could also be used when a bank customer wants to checks his balance. You can draw this in a Use Case diagram.

Include relationships – Example #3

 in a hotel reservation system, you might find that both the Cancel Reservation use case and the CheckIn Reservation use case need to perform the same steps to find a reservation.

Extend relationships

In UML modeling, you can use an extend relationship to specify that one use case (extension) extends the behavior of another use case (base). The Extending Use Case adds to the existing functionality and characteristics of the Base Use Case. This type of relationship reveals details about a system or application that are typically hidden in a use case.

The extend relationship specifies that the incorporation of the extension use case is dependent on what happens when the base use case executes. The extension use case owns the extend relationship. You can specify several extend relationships for a single base use case.

While the base use case is defined independently and is meaningful by itself, the extension use case is not meaningful on its own.

Extend relationships –cont. You can add extend relationships to a model to show the following situations:

A part of a use case that is optional system behavior A subflow is executed only under certain conditions A set of behavior segments that may be inserted in a base use case

The extension takes place at one or more extension points defined in the extended use case.

Extend relationship is shown as a dashed line with an open arrowhead directed from the extending use case to the extended (base) use case. The arrow is labeled with the keyword «extend».

Extend relationships – Example #1

Assume that a customer wants to withdraw money from an ATM. He can withdraw the money from his savings account, credit card account, or from another bank. Therefore, the task of withdrawing the money can be extended with the tasks of withdrawing money from the savings account, withdrawing money from the credit card account, andwithdrawing money from another bank.

Extension points

In UML models, an extension point identifies the point in the base use case where the behavior of an extension use case can be inserted. The extension point is specified for a base use case and is referenced by an extend relationship between the base use case and the extension use case.

A base use case can have several extension points. Each extension point has a unique name that identifies one or several locations in the behavior sequence of the base use case.

As the following figure illustrates, the name of the extension is listed in the Extension Points compartment of the use case.

Conditions in an Extend Use Case

To show how one Use Case extends another Use Case, extension points are added in the UML. In these extension points, the conditions from the UML can also be specified that shows the actual logic necessary for one Use Case to extend to another. They also show the exact extension point that is used between the two Use Cases. These conditions are specified as anote to the extend relationship

The extensions operate only under certain conditions

Extend relationships – Example #2

Registration use case is complete and meaningful on its own.It could be extended with optional Get Help On Registration use case.

Registration use case is conditionally extended by Get Help On Registrationuse case in extension point Registration Help.

Summary of Notations

Summary of Notations – Cont.

Use Case Relationships Compared

Generalization Extend Include

Base use case could be abstract use case(incomplete) or concrete (complete).

Base use case is complete (concrete) by itself, defined independently.

Base use case is incomplete (abstract use case).

Specialized use case is required, not optional, if base use case is abstract.

Extending use case is optional, supplementary.

Included use case required, not optional.

No explicit location to use specialization.

Has at least one explicit extension location.

No explicit inclusion location but is included at some location.

No explicit condition to use specialization.

Could have optional extension condition.

No explicit inclusion condition.

Case Study : Online Shopping Portal

Case Statement 

In this case, we will be designing a simple online shopping portal .The site will provide a soothing shopping experience for customers. The system will allow more than one categories and different brands under the segment. The case will trace the following sequence.

Scenario

A customer visits the online shopping portal. A customer may buy item or just visit the page and logout. The customer can select a segment, then a category, and brand to get the different products in the desired brand

Example #2 : Online Shopping Portal – cont.

The customer can select the product for purchasing. The process can be repeated for more items. Once the customer finishes selecting the product/s the cart can be viewed , If the customer wants to edit the final cart it can be done here.

For final payment the customer has to login the portal, if the customer is visiting for the 1st time he must register with the site, else the customer must use the login page to proceed

Final cart is submitted for payment and card details and address(where shipment has to be made) are be confirmed by the customer .Customer is confirmed with a shipment Id and delivery of goods within 15 days.