If you look at the diagram, you see that there is some connection between "Pay late book fine" and "Collect patron fines." It's too early to know how those two use cases will interact with one another, but you can indicate that they will: Completed use case diagramįinally, you will end up with a diagram showing actors, use cases, and the relationships between all of them. UML has other diagrams to capture those ideas (activity, communication).Įarlier, it appeared as though there were two subdomains (librarian and patron), but that doesn't mean they don't interact. There might be data exchanged (there probably is), but that is not the intention of this diagram. It just means "Fine accounts for lateness" depends on "Send email" to do some of the work. Since it's an arrow, it's easy to misinterpret it as some sort of data or execution flow. The arrow on the diagrams indicates a dependency. And there would be more dashed arrows pointing to "Send email" coming from other use cases. In this case, "Fine accounts for lateness" depends on "Send email" doing some of the work. It can be handy to see this shared activity visually. For example, there may be several use cases that have "then send an email to someone" as part of their execution. Sometimes, when you dig deeper into the actual implementation of use cases, you notice that there are duplicate steps among the various cases. This is an early indicator that you probably have two domains or at least two subdomains in our system. 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.
Domain driven design diagram how to#
Years ago, there were many ideas on how to represent a system.
Domain driven design diagram software#
It’s a standard notation that you can use to model, or visually represent software systems. UML stands for the Unified Modeling Language.