Use Case Diagrams

Use case diagrams are one of the five behavioral diagrams for modeling the dynamic aspects of the system. A use case diagram specifies what the system does (behavior) for the actors. Use case diagram plays a key role in modeling the behavior of a system or subsystem or a class. Each use case diagram consists of a set of use cases, actors and their relationships.

Common Properties:

                Use case diagrams shares some common properties with the rest of the UML diagrams like a name which identifies a use case diagram and the graphical content which is a projection into a model.

Content:

Use case diagrams commonly contain:

• Use cases
• Actors
• Dependency, generalization and association relationships

Like all other diagrams, use case diagrams may contain notes and constraints. They may also contain packages or subsystems, which are used to group elements of your model into larger chunks.

Common Uses:

When we model the static use case view of a system, we apply use case diagrams in one of the two ways:

• To model the context of a system
• To model the requirements of a system

 

  

Common Modeling Techniques

Modeling the context of a system:

                All the things (actors) that live outside the system and interact with the system constitute the system’s context. This context defines the environment in which the system lives.

To model the context of a system:

1. Identify the actors that surround the system.
2. Organize actors that are similar to one another in a generalization-specialization hierarchy.
3. For better semantics, provide a stereotype for each actor.
4. Create a use case diagram with these actors and specify the paths of communication for each actor to the system’s uses cases using association relationships.

 

Modeling the requirements of a system:

                A system’s functional requirements can be expressed as use cases, and the UML’s use case diagrams are essential for managing these requirements.

To model the requirements of a system:

1. Establish the context of the system by identifying the actors that surround (use) the system.
2. For each actor, identify the behavior that the actor expects from the system or requires the system to provide.
3. Name these common behaviors as use cases.
4. Use include and extend relationships to factor common behavior and optional behavior.
5. Model these use cases, actors and their relationships in a use case diagram.
6. Use notes to provide details about the use cases and other non-functional requirements.

Forward and reverse engineering:

To forward engineer a use case diagram:

1. For each use case, identify the flow of events and its exceptional flow of events.
2. Generate a test script for each flow, using the flow’s preconditions as the test’s initial state and its post conditions as its success criteria.
3. As necessary, simulate test runs to represent each actor that interacts with the use case.
4.  Use tools to run these tests each time you release the element to which the use case diagram applies.

To reverse engineer a use case diagram:

1.  Identify each actor that interacts with the system.
2. For each actor, consider how the actor interacts with the system.
3. Trace the flow of events in the executable system relative to each actor.
4. Cluster (group) related flows by declaring a corresponding use case. Use include and extend relationships as necessary.
5. Model these actors and use cases in a use case diagram, and establish their relationships.

 

Use Casses

Introduction:

                Use case modeling describes what a system does or what is the functionality provided by the system to benefit the users. Use case modeling was created by Ivar Jacobson. More than any other diagrams in UML, use case diagrams allow us to quickly gather the requirements of the software system. The primary components of a use case model are use cases, actors or roles and the system being modeled also known as the subject.

The primary purpose of use cases are:

1. To describe the functional requirements of the system, resulting in an agreement between the stakeholders and the software developers who are developing the system.
2. To give a clear and consistent description of what the system should do.
3. To provide a basis for conducting system tests to verify whether the system works appropriately or not.
4. To provide the ability to transform functional requirements into classes and operations in the system.

Use Case:

                A use case represents the functionality provided by the system to the user. A use case is defined as “a set of actions performed by the system, which produces an observable result that is, typically, of some value to one or more actors or other stakeholders of the system”. The actions can include communicating with other actors or systems as well as performing calculations inside the system. The characteristics of a use case are:

1.       A use case is always initiated by an actor.

2.       A use case provides value to an actor.

3.       A use case is complete.

Use cases are connected to actors through associations, which are sometimes referred to as communication associations. Associations represent which actors the use case is communicating with. The association should always be binary, implying a dialog between the actor and system.

A use case is a classifier, not an instance. A use case represents the functionality as a whole with possible alternatives, errors and exceptions that can occur during the execution of the use case. An instance of the use case is known as a scenario, which represents a specific execution path through the system.

Example: Consider a online shopping system,

Use case: Purchase Product

Scenario: A user named surya purchases a product, gaming console by using debit card payment option.

           The graphical representation of a use case is a solid ellipse with the use case name specified inside the ellipse. A use case generally placed inside the system boundary and is always connected to an actor using an association relationship. The name of the use case is generally a phrase rather a one word label. The name can be a simple name or a path name as shown in the below example:

Actors:

                An actor is one which interacts or uses the system (subject). An actor sends or receives messages from the system. Actor can be either a person or another system (computer or application). An actor is a classifier, not an instance. An actor represents a role, not an individual user of the system. For example, in an online shopping system, if ramesh wants to purchase a product, his role will be buyer.

                An actor has a name, and the name should reflect the actor’s role. The name should not represent an instance of the actor or the functionality of an actor. A use case is always initiated by an actor that sends a message to it. This message is also known as stimulus. Actors may be of two types: active actors and passive actors. Active actors or those which initiates a use case and passive actors are those which participate in a use case but never initiate it.

               Actor can be represented with a class symbol stereotyped as <<actor>>. Actor has a standard stereotype icon known as the “stickman”. An actor can have both attributes and behavior.

Flow of Events:

                A use case describes what a system does but it does not specify how it does that. We can specify the behavior of a use case by describing the flow of events in text clearly enough for an outsider to understand it easily. When we write the flow of events, we must specify when the use case starts and ends, what objects are exchanged between the system and the actor, the basic/main flow and alternate flows of events. For example in an ATM system, we can describe the use case “Validate User” in the following way:

Main flow of events:

                The use case starts when the system prompts the customer for a PIN number. The customer can now enter a PIN number via the keypad. The customer commits the entry by pressing the Enter button. The system then checks this PIN number to see if its valid or not. If the PIN is valid, the system acknowledges the entry, thus ending the use case.

Exceptional flow of events:

                Customer can cancel the transaction at any point by pressing the Cancel button thereby restarting the use case. No changes are made to the customer’s state.

Exceptional flow of events:

                Customer can clear the PIN number anytime before confirming it and reenter a new PIN number again.

Exceptional flow of events:

                If the Customer enters an invalid PIN number, the use case restarts. If this happens, three times in a row, the system cancels the transaction, preventing the Customer from interacting with the ATM for 60 seconds.

Scenarios:

                A scenario is a specific sequence of actions that illustrates behavior. Scenario is an instance of an use case like objects are instances of classes. For example, in an online shopping system consider the use case “Purchase Product”. For this use case, a scenario can be: user Ramesh purchases a laptop. Another scenario can be user Mahesh purchases a washing machine etc..

Collaborations:

                A use case specifies what the system does but does not specify how it is implemented. A use case is implemented by creating a collection of classes and other elements that work together to achieve the behavior of the use case. This collection of elements, including both its static and dynamic structure, is modeled in UML as collaboration.

Organizing Use Cases:

                We can organize the use cases by grouping them in packages in the same manner in which we can organize classes. We can also organize use cases by specifying generalization, include and extend relationships. We apply these relationships in order to factor common behavior and in order to factor variants (alternatives).

                Generalization among use case represents that the child use case inherits the behavior from the parent use case. For example in an ATM system, the behavior of the use case “Validate User” is to check whether the user is a valid user or not. To implement this, system might ask for a PIN number or might ask for a retinal scan of the eye or may ask for finger scan. All these three, PIN validation, Retinal scan and Finger scan are specialized ways of checking the validity of a user and can be applied at any place where the “Validate User” use case appears.

                An include relationship between use cases means that the base use case explicitly incorporates the behavior of the included use case. Such relationship is represented as a dependency stereotyped with include. In an include relationship, the included use case cannot exist without the base use case. The include relationship is used to separate the common behavior.

                An extend relationship between use cases means that the base use case extends the behavior of the extending use case. Such relationship is graphically represented as dependency stereotyped with exclude. In a extend relationship, the base use case may exist on its own but at certain points its behavior may be extended by the behavior of another use case. The extend relationship is used to separate the optional behavior.

Common Modeling Techniques:

Modeling the behavior of an element:

To model the behavior of an element:

1.  Identify the actors that interact with the element.
2. Organize the actors by identifying the general and more specialized roles.
3. For each actor, consider the primary ways in which the actor interacts with the element.
4. Consider also the alternative ways in which the actor interacts with the element.
5. Organize these behaviors as use cases, applying include and extend relationships to factor common behavior and distinguish exceptional behavior.