Use Case Diagram
Use Cases are described in UML through Use Case Diagrams, and a Use Case model can be divided into a large number of such diagrams. A Use Case diagram contains model elements that represent the system, actors, and use cases and show the relationships between the use cases.
Use Case content descriptions are usually provided in text form. In UML, that description is considered the “document” attribute of the Use Case. This description contains important information, defining requirements and specific functions. Instead of describing the use case in writing, you can also draw an activity diagram. However, it should be remembered that a use case needs to be described in a way that is easy to understand and communicate with the user, and complex structures such as an activity diagram can feel alien to the user. those who are not used to it.
Viewing: What is an agent?
Summary: A Use Case diagram shows:
– System
– Agent
– Use Cases.
Wallet; Use Case diagram example in UML:
A wallet; Use case diagram example in UML
In there :
– The system is represented by a rectangle with the system name above it
– The agent is represented by the sign; effigy
– Use Case is shown through an ellipse
System:
Because the system is part of the Use Case model, the boundaries of the system that we want to develop need to be clearly defined. Please remember that a system is not always a software system; it could be a machine, or a business. Defining the boundaries and responsibilities of the system is not always easy, because it is not always clear which tasks are most likely to be automated in this system and Which task is best done manually or left to other systems. Another aspect to watch out for is how big the system needs to be in its first version. Trying hard for the first version of the system is usually the way to go, but such outsized goals can cause the system to become too large and the time to deliver it too long. long. A better initiative would be to clarify the basic functions and focus on defining a clear, appropriate system architecture that has an open platform so that more functionality can be added. into this system in later versions.
It is important that you create a catalog of central concepts (entities) with appropriate terms and definitions during the early stages of the analysis. This is not yet an object-scoped model, but rather an attempt to describe in terms of the system or business that we need to model. The terms will then be used to describe the use case. The specific method of this catalog can vary widely; it can be a conceptual model showing simple relationships or just a text containing terms and brief descriptions of these terms in the real world.
Agent:
An actor is a person or thing that interacts with the system using the system. In the concept of “interacting with the system”, we mean that the actor will send a message to the system, either receive the message from the system, or change the information with the system. In short, the actor executes Use Cases. One more thing, an actor can be a person or it can also be another system (eg; a computer; another computer connected to our system or some kind of hardware device. some hardware that interacts with the system).
See also: What is Aggression – Meaning of the word : Aggressive
An actor is an entity type (a class), not an entity. The actor describes and represents a role, rather than an actual and specific user of the system. If a certain John wants to buy a policy from an insurance company, his role will be as policy buyer, and this is what we want to model, not John himself. In fact, a particular person can act as multiple actors in a system: a banker can also be a customer of the bank itself. On the other hand, the number of roles that a particular person is allowed to play in a system can also be limited, for example; For example, the same person is not allowed to create an invoice and approve it at the same time. An actor will have a name, and this name needs to reflect the role of the actor. That name must not reflect a distinct entity of an agent, nor should it reflect the function of that agent.
An agent communicates with the system by sending or receiving messages, like the concept we are familiar with in object-oriented programming. A Use Case is always activated by an agent sending a message to it. When a Use Case is executed, the Use Case can can send messages to one or more actors. These messages can also reach other actors, besides the agent itself that triggered and caused the Use Case.
Actors can also be classified. A primary actor is an actor that uses the basic functions of the system, that is, the main functions. Wallet; For example, in an insurance system, a base actor might be the agent that handles the enrollment and administration of insurance policies. A secondary actor is an actor that uses the secondary functions of the system, for example; such as system maintenance functions such as data bank administration, communication, back-up and other administrative tasks. A wallet; For example, a secondary actor can be an administrator or an employee who uses functions in the system to extract statistical information about the business. Both types of actors are modeled to ensure a complete description of the system’s functions, although it is the primary functions that are really in the customer’s primary interest.
See also: What is extremism – Meaning of the word Extreme
Actors can also be defined as either an active actor or a passive actor. An active actor is one that causes a use case, while a passive actor never causes a use case, but is only involved in one or more use cases.
