The use case diagrams describe the relationships and dependencies between the use case groups and the actors involved in the process.

It is important to understand that use-case diagrams are not intended to display a project and cannot describe the internal structure of the system. Use-case diagrams are intended to simplify interaction with future users of the system, with customers, and are particularly useful for determining the necessary system characteristics. In other words, use-case diagrams indicate what the system should do without specifying the methods used.

Use case (use case)

The use case describes, from the point of view of the actor, a group of actions in the system that lead to a specific result.
Use cases are descriptions of typical interactions between users of the system and the system itself. They display the external interface of the system and indicate the form of what the system should do (which is what, not how).
When working with use cases, it is important to remember a few simple rules:

• each use case refers to at least one actor
• each use case has an initiator,
• each use case leads to a corresponding result (a result with a “business value”).

Use cases can also interact with other use cases. The three most common types of interaction between use cases are listed below.

• Inclusion indicates that the use case is embedded in another use case.
  
  
  In this example, the use case for Part is included in the use case for Base.
  ')
  
• Adding indicates that in certain situations or at some point (called an extension point) the use case will be expanded to another.
  
  
  In this example, the Base use case is extended by the Another use case.
  
  
• A generalization indicates that the use case inherits the characteristics of the “parent” use case and may override some of them or add new ones, like inheritance in classes.
  
  
  In this example, the Child use case summarizes the Base use case.
  
  

Actor

The actor is an external source (not an element of the system) that interacts with the system through a use case. Actors can be both real people (for example, users of the system), and other computer systems or external events.

Actors do not represent physical people or systems, but their roles. This means that when a person interacts with the system in various ways (assuming different roles), it is displayed by several actors. For example, a person working in a support service and accepting orders from clients will be displayed in the system as a “member of the support department” and “a member of the sales department”.

Actors can have two types of links with use cases:

• A simple association is reflected by the line between the actor and the use case (without an arrow). Reflects the relationship of the actor and use case.
  
  
• A directional association is the same as a simple association, but it shows that the use case is initialized by the actor. It is indicated by an arrow.
  
  

Description of the use case

Use case descriptions are text based explanations. They usually take the form of a note or document that is somehow attached to a use case and describes a process or activity.

Notes

In my opinion, designing a new component should be carried out in the following sequence: use case diagram (use case diagram) => sequence diagram of actions (sequence diagram) => class diagram (class diagram). Accordingly, when creating documentation for existing code, the sequence of actions will be reversed. Here we talked about the class diagram, therefore, for the completeness of the review, there is still not enough sequence diagram.