A use case diagram is used for communicating very complex ideas in a fairly basic way. To start out with, a use case diagram is comprised of three parts. A system or an application, who interacts with the system, and then a basic flow of what the system or application does.
The system or application could be a few tables/relations that work together. An example of this would be the winners table we have created along with an education table and possibly one other table about the turning award winners.
Then you have the system administrators (for my example it will be my group that’s designing our turning award winners database). Then the users that want to learn about the database. Also another system/database could interact with this one.
Next we have the design, it gives a brief outline of what is going on with the databases and how to find information about them easily. This would be running querries to get specific results you might be interested in or need to know for decision making.
Breaking down a use case system into four components: systems, actors, use cases and relationships. A system could be a website, business process, application, etc. An actor would be the admin of the database (my group), another person curious about the information in the database, an organization, another system, or an external device. There are primary and secondary actors. A primary actor is who is using the system for their benefit. A secondary actor only helps the primary actor to benefit. Use cases represent an action that accomplishes a task within the system. There are many use cases in each system. Use cases should be in a logical order. We then show what actors have relationships with the use cases. An actor must have at least one relationship with a use case. There are different types of relationships, one is an include relationship and the other is an extend relationship. An include relationship happens every time, and an extend relationship only happens when certain criteria are met. An example of an include relationship would be trying to change something in our database, it will always ask us to login to make sure we have those privileges to change the database. An example of an extended relationship would be if we entered a wrong username/password. A message would only then show up if we don’t have those privileges.
The video that really helped me understand this concept comes from YouTube and the link will be provided below:
Here is a practical diagram for college students:
