What is Use Case Modeling and its relationships?

The Use Case Model describes the proposed functionality of the new system. A Use Case represents a discrete unit of interaction between a user (human or machine) and the system. A Use Case is a single unit of meaningful work; for example, login to system, register with system and create order are all Use Cases. Each Use Case has a description which describes the functionality that will be built in the proposed system. A Use Case may 'include' another Use Case's functionality or 'extend' another Use Case with its own behavior. Use Cases are typically related to 'actors'. An Actor is a human or machine entity that interacts with the system to perform meaningful work.

Actors

An Actor is a user of the system. This includes both human users and other computer systems. An Actor uses a Use Case to perform some piece of work which is of value to the business. The set of Use Cases an actor has access to defines their overall role in the system and the scope of their actions.

The formal specification of a Use Case includes:

1. Requirements :

These are the formal functional requirements that a Use Case must provide to the end user. They correspond to the functional specifications found in structured methodologies. A requirement is a contract that the Use Case will perform some action or provide some value to the system.

2. Constraints :

These are the formal rules and limitations that a Use Case operates under, and includes pre- post, invariant conditions. A pre-condition specifies what must have already occurred or be in place before the Use Case may start. A Post-condition document what will be true once the Use Case is complete. An invariant specifies what will be true throughout the time the Use Case operates.

3. Scenarios :

Scenarios are formal descriptions of the flow of events that occurs during a Use Case instance. These are usually described in text and correspond to a textual representation of the Sequence Diagram.

USE CASE RELATIONSHIPS 

Use case relationships are divided into three types.

1. Include relationship

2. Extend relationship

3. Generalization

1. Include relationship :

It is common to have some practical behavior that is common across several use cases. It is simply to underline it or highlight it in some fashion.

Example:

Paying by credit: Include Handle Credit Payment

2. Extend relationship :

Extending the use case or adding new use case to the process, extending use case is triggered by some conditions called extension point.

3. Generalization relationship :

Complicated work and unproductive time is spending in this use case relationship. Use case experts are successfully doing use case work without this relationship. Includes and extends relationships between Use Cases One Use Case may include the functionality of another as part of its normal processing. Generally, it is assumed that the included Use Case will be called every time the basic path is run.

An example may be to list a set of customer orders to choose from before modifying a selected order, in this case the <list orders> Use Case may be included every time the <modify order> Use Case is run. A Use Case may be included by one or more Use Cases, so it helps to reduce duplication of functionality by factoring out common behavior into Use Cases that are re-used many times. One Use Case may extend the behavior of another - typically when exceptional circumstances are encountered.