Use Case

A use case is a methodology used in system analysis to identify, clarify, and organize system requirements. The use case is made up of a set of possible sequences of interactions between systems and users in a particular environment and related to a particular goal. It consists of a group of elements (for example, classes and interfaces) that can be used together in a way that will have an effect larger than the sum of the separate elements combined. The use case should contain all system activities that have significance to the users. A use case can be thought of as a collection of possible scenarios related to a particular goal, indeed, the use case and goal are sometimes considered to be synonymous.

A use case (or set of use cases) has these characteristics:

• Organizes functional requirements

• Models the goals of system/actor (user) interactions

• Records paths (called scenarios) from trigger events to goals

• Describes one main flow of events (also called a basic course of action), and possibly other ones, called exceptional flows of events (also called alternate courses of action)

• Is multi-level, so that one use case can use the functionality of another one.

• Use cases can be employed during several stages of software development, such as planning system requirements, validating design, testing software, and creating an outline for online help and user manuals.

What makes up a UML use case diagram?

• Actors: An actor represents a role external to a system that uses or is used by a system. Actors can be shown as boxes marked with an «actor» stereotype or a stick figure. From a stylistic point of view, stick figures are best reserved for human roles. (In spite of technological advances and Hollywood, it looks a little strange to see devices or software systems presented in human form. As an aside, the term actor is somewhat misleading, as we normally think of an actor as someone who plays a role, not as the role itself. To sidestep such confusion an increasing number of practitioners favor the term user role.

An actor represents a role of a user that interacts with the system that you are modeling. The user can be a human user, an organization, a machine, or another external system.

You can represent multiple users with a single actor and a single user can have the role of multiple actors. Actors are external to the system. They can initiate the behavior described in the use case or be acted upon by the use case. Actors can also exchange data with the system.

In models that depict businesses, actors represent the types of individuals and machines that interact with a business. In models that depict software applications, actors represent the types of individuals, external systems, or machines that interact with the system.

You would typically use actors in use-case diagrams, but you can also use them in class and sequence diagrams.

As the following figure illustrates, an actor is displayed as a line drawing of a person.

Each actor has a unique name that describes the role of the user who interacts with the system.

You can add documentation that defines what the actor does and how the actor interacts with the system.

• System boundary: A boundary that separates actors -- which are external to the software system -- from use cases -- which represent goals fulfilled by the system -- makes clear the separation between the software system of interest and the world around the system. It also acts as a reminder that the behavior of the use cases in question is system behavior and not the broader and sometimes less-deterministic and less-biddable behavior of the world around the system that might lead to or be inspired by the use cases. The system box is sometimes treated as an optional presentation feature. Omission makes sense if use cases are used to model a business rather than a software system, but otherwise absence does not make the chart grow sounder.

• Use case

A use case describes a function that a system performs to achieve the user’s goal. A use case must yield an observable result that is of value to the user of the system.

Use cases contain detailed information about the system, the system’s users, relationships between the system and the users, and the required behavior of the system. Use cases do not describe the details of how the system is implemented.

Each use case describes a particular goal for the user and how the user interacts with the system to achieve that goal. The use case describes all possible ways that the system can achieve, or fail to achieve, the goal of the user.

You can use use cases for the following purposes:

• Determine the requirements of the system
• Describe what the system should do
• Provide a basis for testing to ensure that the system works as intended

In models that depict businesses, use cases represent the processes and activities of the business. In models that depict software systems, use cases represent the capabilities of the software.

Each use case must have a unique name that describes the action that the system performs. Use case names are often short phrases that start with a verb, such as Place Order Online.

As the following figure illustrates, a use case is displayed as an oval that contains the name of the use case.

You can add the following features to use cases:

• Attributes that identify the properties of the objects in a use case
• Operations that describe the behavior of objects in a use case and how they affect the system
• Documentation that details the purpose and flow of events in a use case

• Associations between use cases and actors:Actors do not simply sit around resting, and a system's use cases are not orphaned islands of functionality. Associations connect primary actors with the use cases that represent the goals they can have against a system, and they connect secondary actors with the use cases that use them to fulfill goals.

• Relationships between use cases: It is possible for use cases to include, extend or generalize other use cases. In theory the idea that use cases can interrelate, much as classes on a class diagram do, makes sense. The problem is that in practice this aspect of use case diagrams is not only less than useful, it is typically harmful.

Association relationships

In UML models, an association is a relationship between two classifiers, such as classes or use cases, that describes the reasons for the relationship and the rules that govern the relationship.

Generalization relationships

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.

Include relationships

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.

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). This type of relationship reveals details about a system or application that are typically hidden in a use case.

Not only do use case relationships obscure a diagram, disenfranchising all but the UML geeks, but they tend to distract practitioners from the objective of identifying and understanding the system's behavior. Use case diagrams that make use of such relationships often end up degenerating into an ineffective top–down programming model of the system. They are rarely backed up by clear use case descriptions.

There are a couple of other elements that sometimes find their way onto use case diagrams, such as packages, but the ones just listed are the core ingredients that, depending on use, can clarify or obscure the message of a diagram.

The notion that a diagram has a message is perhaps the question we should be asking. Having answered what a use case diagram can show from a technical point of view, we really need to ask what we want or need it to show from an intentional point of view. Unless we have a clear purpose for a diagram, the diagram is likely to end up a confused and aimless exhibition of notation.

What use case diagrams do not show

Use case diagrams do not present architectural models, user-interface models or workflow models. However, this does not appear to stop them from being press-ganged into these roles. It is common to find use case diagrams with extra ad hoc ornamentation. Although well meant, such extras are invariably confusing rather than helpful.

There are better approaches suited to each of these tasks. For architectural models, there are many ways to present and describe architecture, and many viewpoints from which to do so. For user-interface models, UI design is a discipline and activity that is not well addressed by UML, and even less so by use case diagrams. For workflow models, activity diagrams offer a clearer way of organizing flow by considering use cases as activities.

What a use case diagram is good at showing is the system context and a summary of the functional goals fulfilled by the system. In other words, use case diagrams offer a rich "table of contents" but are not themselves the content. They do not illustrate the structure of the software or its required behavior, which is why they are an iconic rather than a schematic concept.

By contrast, a class diagram can illustrate a system's information model or some aspect of design, a textual use case description describes a slice of system behavior, and a state-machine diagram can illustrate an object's lifecycle. All of those are schematic in the sense that something can be built from them and they offer concrete and testable assertions about a system, either from an external or an internal point of view.

The notion that a use case diagram acts like a table of contents, a summary, is one that suggests that use case diagrams are not the only way to present an overview of actors and their goals. A tabular presentation can be just as effective, with actors in one column and their corresponding goals (i.e. use cases) in an adjacent column. Use case diagrams offer a more visual presentation for sketching on whiteboards, but sometimes a tabular presentation is easier to both read and write in word-processed documents and on Wiki pages.