Usecase diagram

Use case diagram describes the functional purpose of the system or, in other words, what the system will do in the process of its functioning. The use case diagram is the initial conceptual representation or conceptual model of the system in the process of its design and development. 

The essence of this diagram is as follows: the system being designed is represented as a set of entities or actors interacting with the system using the so-called use cases. 

The diagram is being developed for: 

• Definition of common boundaries and context of a simulated domain at the initial stages of system design. 
• Creation of general requirements for the functional behavior of the designed system. 
• Development of the initial conceptual model of the system for its subsequent refinement in the form of logical and physical models. 
• Preparation of source documentation for the interaction of system developers with its customers and users. 

1. Basic elements

Use case

Shows the general features of the behavior of a system or any other entity without considering the internal structure of this entity.

Each use case determines the sequence of actions performed by the system when it interacts with the corresponding actor.

The use case can describe any action, for example, the interaction between the user and the entity, the reaction of the entity to the message, the description of the features of the implementation methods, etc.

Visually it is represented as an ellipse with text inside, which is called a script or note.

Actor

Any entity (role) external to the system. The actor interacts with the system and achieves the goal with its help.

This can be a person, a technical device, a program, or any other system that can serve as a source of influence on the simulated system as defined by the developer.

Visually it is a human pictogram with a name under it.

Relationships

Various relationships may exist between the components of the use case diagram, which describe the interaction of instances of some actors and use cases with instances of other actors and use cases. One actor can interact with several use cases. In this case, this actor refers to several services of this system. In its turn, one use case can interact with several actors, providing its service for all of them.

There are several standard types of relationships between actors and use cases: 

• Association relationship. The interaction of the actor and the use case. It is indicated by a solid line.
• Extend the relationship. Indicate that the properties of one instance of a use case can be extended due to the properties of another use case. It is indicated by an arrow with an unfilled triangle at the end or an arrow labeled “extend”.
• Generalization relationship. Some use case (or actor) A can be generalized to use case (or actor) B. Thus, option A is a special case of option B. B is the parent, A is the child. A has all the properties of B.
• Include relationship. Shows that one use case includes another use case. Indicated by an arrow labeled “include”.

Interfaces

Model parameters visible from the outside without specifying their internal structure. Visually, this is a circle labeled with a name, connected by a straight line to the use case that supports this interface.

Notes

Notes are intended for inclusion in the model of arbitrary textual information that is directly related to the context of the project being developed.

2. Syntax

Use case, or precedent, or usecase

Use cases are enclosed in two brackets (because the two brackets look like an oval).
You can use usecase to set a use case (precedent). You can create an alias using the AS keyword.
This alias will be used later when defining relationships.

If the use case description needs to be broken down into several lines, quotation marks can be used.

In addition, the following delimiters can be used: - .. == __. To insert a title inside the delimiters, you just need to write it inside the notation, for example .. Title ..

Actors

The name of the Actor is in two colons :Actor:

You can use the actor keyword to define an actor. You can create an alias using the as keyword. This alias will be used later when defining relationships.

Relations

To connect actors and precedents, use the arrow ->.
The more dashes in the arrow, the longer it is.
You can add a label to the arrow by adding colons symbol : when defining the arrow (for example, to determine the multiplicity of an association, or to define different relationships, for example, extend or include).

In this example, you can see that User is not defined earlier and is used as an actor

• Dotted arrow …>
• Triangle arrow --- |>
• Change arrow direction <-

If you use two dashes or two dots, then the default arrow is vertical. To draw a horizontal arrow, you can use one dash or one dot. 

It is possible to change the direction of the arrow by adding the keywords left, right, up or down inside the arrow:

The default behavior is to build diagrams from top to bottom:

You can change the direction from left to right using the left to right direction command. Often the result with this direction looks better. 

When defining actors and use cases, you can add patterns using << and >>:

Notes

To add notes to the diagram, you can use the keywords note left of, note right of, note top of, note bottom of to create a note related to a single object. A note can also be created using the note keyword, and then attached to another object using the symbol ..

Use cases can be grouped in a rectangular field, to do it you can use the rectangle keyword {}
The group can be called, the name is written immediately after the rectangle:

Styles

You can use the skinparam command to change the fonts and colors of the diagram.

You can use this command: 

• In a diagram definition, like any other command, 
• In the attached file, 
• In the configuration file specified on the command line in the ANT job. 

You can set the color or font for actors or use cases with patterns.