Explain Association in Use Case Diagram

So far you have learned about Use Cases and Actors. Actors are the external entities who executes the Use Cases. So Actors and Use Cases are related to each other. In the next video, you will learn how to depict this relationship using association.

In the previous video, you learnt that association connects an actor to the use case that he will execute. Association is represented as a solid line between the actor and the use case.

Video Transcript

Now we can see how each of these actors are related to each of these use cases. For example, in our inventory management system, admin as an actor could do login, logout, manage inventory manager and additionally pay supplier as you can see with the arrows. Similarly an inventory man ager in addition to doing login and logout, he could place order a supplier. Apart from login and logout, he could raise an invoice. Finally, a notification service is not a human, so he need not do a login and log out. Instead just send a notification.

Video Recap

• Use case diagram is discussed for an inventory management system

• Three actors are mentioned: Admin, Inventory Manager, and Notification Service

• Admin actor can perform login, logout, manage inventory, and pay supplier

• Inventory Manager actor can perform login, logout, place orders, and raise invoices

• Notification Service is a non-human actor that can only send notifications

• No mention of use case diagrams for warehouse management system, hospital management system, or stock management system

In the next video, you will see how to draw an association between an actor and the use case in draw.io.

In the previous video, you saw how to draw association between an actor and a use case. In the next video, you will see how we club different use cases into a single use case.

In the previous video, you learnt that while drawing use cases, you don’t make separate use cases for each and every functionality that the system can perform, but a use case must represent a specific way of using the system.

This also does not mean that you club all the use cases that an actor can perform into one use case; however, you only club relevant use cases. For example, in the Inventory Management System, the Admin will add, update or remove Inventory Managers; so, these three functionalities can be clubbed into one use case: Manage Inventory Managers. The Admin will also pay a supplier for supplying the order; so, there should be a use case: Pay Supplier. Here, you don't club them into one use case as Manage Inventory Managers and Pay Supplier because these two use cases are not relevant to each other.

In this segment, you learnt about the association in terms of UML. Associations are connections between the actor and the use cases that the actor executes. You also learnt how it is not necessary to have use-cases for every functionality of the system.