There are two users in the above diagram, each with separate goals. Add more ovals and connections as you discover new functionality the users want. Add stick figures to your diagram as you discover new types of users. Relationships added between actors and use cases Do that with a connecting line (called a relationship). Now you need to show which actors are interested in achieving which goal(s). Ok, you've got your use cases, but how are you going to connect them to your actors? With relationships, of course! Step 3: Add Relationships

You can see in the image above that use cases for librarians are on the right, and use cases for patrons are on the left. For example, you would write 'Check-in book' (that's what the librarian wants to do) rather than 'Update book status in the database record,' or 'Database book record updated.' (That's how the system will do it.) Right now, you aren't concerned with how this will get done, just that the user wants it to do. The goal is typically described as some result from the user's perspective, not the system's. Show a use case as an oval, with the goal written inside. You get them by reviewing the conversations you had with the librarians and patrons. Let’s give the users something to do: use cases. Ok, great! Now, on to defining the goals of the actors. Let's go back to the example of the library application and create the diagram by adding the actors you've discovered who will use the system. You’ve seen the first item that appears on the diagram in the introduction to this chapter: the actors! Actors are shown as stick figures, with a quick description of the type of user they are (their role) underneath. It's as easy as one, two, three! 😉 Step 1: Identify the Actors Let’s put one of those use case diagrams together. This is a diagram you generate early in the process and keep up to date as you learn more about what the user wants. It will represent the work you did earlier to capture system users and what they want the system to do. It's a way to capture what your system can do, in picture form, for various users. With the information you've gathered so far, you can construct one type of UML diagram: the use case diagram. In this course, we'll focus on just two that are the most commonly used. You won't usually use all of them to model your system. In its current standardized version, there are 13 different diagram types. That’s what the Unified part of Unified Modeling Language means.

Eventually, an agreement was reached on what images should be used for which modeling ideas (like the actor stick figure). It was tough to keep all these approaches straight. Some used circles, others rectangles, some dashed clouds. Years ago, there were many ideas on how to represent a system. It’s a standard notation that you can use to model, or visually represent software systems. UML stands for the Unified Modeling Language.

Create use case diagram