Question

What is a brief explanation of the system use case diagram? What is the purpose of the use case diagram, and why might a system analysts draw many different use case diagrams when reviewing the use cases with end-users?

Answer 1

A use case diagram captures the business processes carried out in the system. Normally, domain experts and business analysts should be involved in writing use cases. Use cases are created when the requirements of a system need to be captured. A use case diagram is quite simple in nature and depicts two types of elements: one representing the business roles and the other representing the business processes.

Active relationships are referred to as behavioral relationships and are used primarily in use case diagrams. There are four basic types of behavioral relationships: communicates, includes, extends, and generalizes.

COMMUNICATES. The behavioral relationship communicates is used to connect an actor to a use case. Remember that the task of the use case is to give some sort of result that is beneficial to the actor in the system.

NCLUDES. The includes relationship (also called uses relationship) describes the situation in which a use case contains behavior that is common to more than one use case.

EXTENDS. The extends relationship describes the situation in which one use case possesses the behavior that allows the new use case to handle a variation or exception from the basic use case.

GENERALIZES. The generalizes relationship implies that one thing is more typical than the other thing. This relationship may exist between two actors or two use cases.

In Visual Modeling we model according to some standard. Every shape or sign has a meaning.To draw relationship between Use cases we use to express the type of relationship by mentioning relationship type within . It’s a standard.

The scope of a system defines its boundaries, what is in scope—or inside the system—and what is out of scope. The project usually has a budget that helps to define scope, and a start and end time. Actors are always outside the scope of the system. The communicates lines that connect actors to the use cases are the boundaries, and define the scope. Since a use case diagram is created early in the systems life cycle, the budget, starting time, and ending time may change as the project progresses; as the analyst learns more about the system, the use case diagrams, use case, and scope may change.

When it comes to drawing use case diagrams one area many struggles with is showing various relationships in use case diagrams. In fact many tend to confuse <<extend>>, <<include>> and generalization. This article will look into various use case diagram relationships in detail and explain them using examples.

There can be 5 relationship types in a use case diagram.

• Association between actor and use case
• Generalization of an actor
• Extend between two use cases
• Include between two use cases
• Generalization of a use case

1. Association Between Actor and Use Case:

This one is straightforward and present in every use case diagram. Few things to note.

• An actor must be associated with at least one use case.
• An actor can be associated with multiple use cases.
• Multiple actors can be associated with a single use case.

2. Generalization of an Actor

Generalization of an actor means that one actor can inherit the role of the other actor. The descendant inherits all the use cases of the ancestor. The descendant has one or more use cases that are specific to that role. Let’s expand the previous use case diagram to show the generalization of an actor.

3. Extend Relationship Between Two Use Cases

Many people confuse the extend relationship in use cases. As the name implies it extends the base use case and adds more functionality to the system. Here are a few things to consider when using the <<extend>> relationship.

The extending use case is dependent on the extended (base) use case

The extending use case is usually optional and can be triggered conditionally

The extended (base) use case must be meaningful on its own

4. Include Relationship Between Two Use Cases

Include relationship show that the behavior of the included use case is part of the including (base) use case. The main reason for this is to reuse common actions across multiple use cases. In some situations, this is done to simplify complex behaviors. Few things to consider when using the <<include>> relationship.

• The base use case is incomplete without the included use case.
• The included use case is mandatory and not optional.

5. Generalization of a Use Case

This is similar to the generalization of an actor. The behavior of the ancestor is inherited by the descendant. This is used when there is common behavior between two use cases and also specialized behavior specific to each use case.