
The general guidelines for use cases are: If actors in your system need to interact with each other, you might consider a separate use case diagram to depict this interaction.Ī use case represents an action, and thus the names should begin with a verb. It is important to note that actors don’t interact with other actors. To enable quick highlighting of the critical roles in the system, you must place the primary actors on the left side of the diagram.Įxternal systems are also actors in your use case diagram. Also, use generalized names to make the modification and presentation simpler. Give meaningful and relevant names to the actors. The general guidelines for identifying the actors are: An actor is a person, an organization, or an external system that interacts with the application being analyzed. In the analysis phase, these diagrams provide an outside view of a system by identifying the system's external and internal factors.Īctors are the external users that interact with a system. Use cases are also convenient in requirement gathering and documentation. Use case diagrams to represent the basic flow of events through use cases.

Use case diagrams are used to define and organize functional requirements in a system along with specifying the context.

They show how a user will trigger a response from the system and what is the expected response. They represent the end-user interaction goals and methods. UML use case diagrams are used for many purposes, for example: Thus, they provide a high-level analysis of the design from the outside without worrying about the functionality details. These requirements are later translated into design choices and development priorities.Īpart from the interaction model, use case diagrams also help to identify internal or external factors that can influence the workflow of the system. Use case diagrams to help to visualize the functional requirements of a system. In this case, the "Update Delivery Address" use case extends the "Place Order" use case, but can also be used independently by the customer actor.In UML, the purpose of a use case diagram is to demonstrate the different interaction methods for the end-user.

#Extend in use case diagrams update
However, "Update Delivery Address" can also be used directly by the customer actor, as they may need to update their delivery address at any time before or after placing an order. This use case can be extended by the "Place Order" use case, as the customer may want to update their delivery address while placing a new order. We have also a use case called "Update Delivery Address" which represents the process of updating the delivery address for an existing order. In this case, the "Apply Discount" use case would extend the "Place Order" use case. This use case might be extended by the use case "Apply Discount," which represents the process of applying a discount to the order. However, the extended use case is not required for the main use case to be complete.įor example, let's say we have a use case called "Place Order" which represents the process of placing an order on an online store. This means that the main use case can be enhanced by adding the functionality of the other use case.

The extend relationship is used to show that a use case can be extended by another use case.
