Question

The Use Case Diagram in UML

Answer 1

Use Case Diagram - One of the many diagrams in UML
Use case diagram in practice
Elements and structure of the use case diagram
Example use case diagram

---

The Use Case Diagram in UML

The use case diagram is a form of behavior diagram in Unified Modeling Language (UML ), which represents business processes as well as object-oriented programming systems and processes. Therefore, the UML is not a programming language, but a modeling language, that is, a standardized method for representing existing or planned systems. In this diagram, all the objects involved are structured and related to each other..

Index

1. Use Case Diagram - One of the many diagrams in UML
2. Use case diagram in practice
3. Elements and structure of the use case diagram
4. Example use case diagram

Use Case Diagram - One of the many diagrams in UML

Representing all kinds of objects, relationships and processes using a single diagram would be too complex and confusing. For this reason, 14 different types of diagrams are used in the UML, which can be divided into structure diagrams, behavior diagrams, and interaction diagrams . Interaction diagrams, in turn, are a subcategory of behavior diagrams.

The structure diagrams focus on representing all system elements and their relationships with each other. A typical example is the class diagram, with which elements can be grouped and displayed in hierarchies. The behavior diagrams , however, do not represent static structures, but show the flow of the planned or actual process that should take place in the run the program or software. In this type of diagram, the dynamics take center stage..

The use case diagram also belongs to the latter group, but it is a particular model , because it shows the expected behavior of a system or software in a specific use case . Compared to other behavior diagrams in the UML, the use case diagram is fairly static, as it can only be used to describe actions and objectives, but not the exact sequence of processes and actions. For the latter, other types of diagrams are used in UML, such as activity diagrams, which represent the processes chronologically; or the sequence diagrams, which show the exchange of messages between the different elements that make up a system.

Use case diagram in practice

In the use case diagram, the functions of the system in question are represented from the user's point of view (called an "actor" in UML). This actor does not necessarily have to be a human user, but the role can also be attributed to an external system accessing another system. In this way, the use case diagram shows the relationship between an actor and its requirements or expectations of the system , without representing the actions that take place or putting them in a logical order..

In practice, this structure is adequate to clearly represent the most important functions and / or objectives of a system. For this reason, when developing software or planning new business processes , creating a use case diagram is often one of the first steps, as it allows you to clearly and easily visualize which use cases should be considered during development. so that the actors (and, in a broader sense, also the operators or customers) achieve their objective, in principle regardless of technical feasibility.

Elements and structure of the use case diagram

To ensure that the use case diagram is understandable to everyone at a glance, standardized elements are used to build it. First of all, there are three main elements:

• Actor: whether it is a person or a system, it is represented with the drawing of a schematic human figure.
• System: The system to which the use case refers is shaped like a rectangle.
• Use case: shown as an ellipse that usually includes a text briefly describing the process.

Symbols to represent the actor, the system and the use case

The relationship between these elements is represented by connecting lines called associations. A straight line between the actor and the use case shows that the actor and the use case described in the ellipse are related. A dashed line establishes a relationship between different use cases . As there are two different types of association between use cases, a keyword is added to the lines, called? Stereotype? in UML, it is put between two pairs of angle brackets. The dependency relationship between the use cases is represented by the head of an arrow. A distinction is made between these two stereotypes:

• Association <> : The use case in which the dashed line begins relates to a second use case indicated by the arrowhead.
• Association <> : the use case in which the dashed line begins can be extended to the use case indicated by the arrowhead under certain conditions, which do not necessarily have to be fulfilled in all cases.

The lines connecting the use cases include an arrowhead and a stereotype that indicate the relationship between those elements

While the << include >> association requires both use cases to be realized, in the case of the <<extend>> association this depends on certain conditions that are represented as the so-called extension point in the use case diagram in UML. In the schematic, the extension point is represented by two elements:

• Mention in the use case ellipse - The possible extension point is mentioned and briefly described under the use case title.
• Note: starting from the <> stereotype , a dashed line is drawn ending on the graph of a note (represented as a rectangle with a bent corner). This note includes the titles of? Condition? and? Extension point ?. Behind the first, the condition that must be met for the second use case to be executed is in square brackets. Behind? Extension point ?, the name that appears in the corresponding use case ellipse is indicated, to make it clear what the extension refers to.

If the conditions defined in the extension point are met, use case B will occur and the process for use case A will change

So far all the basic components you need to create your own use case diagram.

Example use case diagram

So far we have only talked about theory. To give you a better idea of ​​the diagram of use cases in real life, we will show you how to make one using the example of a bank customer who wants to withdraw money from an ATM.

Note

In practice, you should always make sure that the use case diagram is not too confusing, which is often the case when representing several cases on the same diagram related to each other by the <<include>> and <<extend>> associations . When in doubt, create a separate use case diagram for each of them.

In our example, the ATM is the system; the bank's customer, the actor who is going to use it, and the use case, "get money." The latter is related to two other use cases through inclusion associations, namely? Authentication? and? PIN and account control ?. If the authentication is invalid, the client's request will not be served. To prevent customer attempts from being repeated indefinitely, the cashier must retain the card when the PIN is entered incorrectly three times. Therefore, for the "authentication" use case, an extension point is defined with the condition "wrong PIN three times". If this condition is met, the use case of? Hold card ?, related to the use case of? Authentication? Is executed. through an association of type extend . With all these elements, our use case diagram would look like this:

In this diagram for the use case? Get money ?, you can see how the different use cases are related to each other

---