Use Case Diagram Symbols and Rules

Tom and Angela Hathaway
A free video tutorial from Tom and Angela Hathaway
BA-EXPERTS: Business Analysis for Anyone Wearing the BA Hat
4.3 instructor rating • 12 courses • 51,040 students

Lecture description

The Use Case Diagram speaks volumes and your job is to ensure that it is drawn in accordance with standards to ensure that others understand what it says.

Learn more from the full course

Lean / Agile Business Analysis: Writing BUSINESS Use Cases

Enabling Stakeholders to Capture, Organize, and Communicate Functional Business Requirements for a Digital Solution

03:22:34 of on-demand video • Updated January 2020

  • Document user interaction in Lean Use Cases descriptions and diagrams
  • Define and defend the need for Lean Use Cases
  • Describe the major components of a Lean Use Case
  • Determine how to handle alternate and exception situations
  • Extract Use Cases from a Vision Statement
  • Apply Business Event Analysis to discover Lean Use Cases based on business activities
  • Analyze business scenarios to discover Lean Use Cases
English [Auto] Next I'd like to talk a little bit about the symbols that you should use on a You Use Case Diagram. Following the rules of the unified modeling language well actually whatever rules you follow when you are drawing diagrams such as the Use Case Diagram you should always use the correct symbols because this is a tool of communication. And as I've mentioned before communication is a two way street. It only works if both parties the person receiving and the person sending are using common terminology in the world of diagrams. That means that every symbol Hastert has conveys a specific meaning. And if you use the correct symbols you are conveying the correct thing to the recipient or to the person looking at the diagram. So any Use Case Diagram the first symbol you're going to see logically enough is a thing called a use case. You're an example of three different use cases one use case for Browse Web site a use case for place order and a use case for check order status. If all three of these use cases if this is the way we're representing use case by convention we're using an oval. Very important to use an oval because circle in the world of the UML has a very different meaning. The Oval is indicates that this is a use case and the name of the use case is written inside the Oval. By convention by the way that dotted line as it says is also convention and that is merely to say that this comment is related to this object. So since the dotted line connects the text with that object our eyebrows Web site is saying that this is what this comment is related to. Now if all three of these use cases are part of a common application or a single application you might put them together in what the UML calls it package. Now symbol for a package is this things that looks a bit like a folder with a tab on top that basically just says these three things are part of this package and they are going to be defined they are going to be within the scope of this package they are going to be clearly delineated and defined Nixon what we see is the actor and the actor in this case for example is a shopper interacts with and the Browse Web site. So there is a connecting line between the actor and shopper and the use case browse Web site also see that the shopper can place an order that is one of the features or one of the things that they can use these. This use case to do that they could interact with the use case place order the credit card processor if you're paying with a credit card typically is going to be an external entity or an extra internal API that place order is going to go to to get your credit card processed since you can have multiple different types of credit cards. American Express MasterCard etc. It's going to go to whatever credit card processor is appropriate that really says that this actor credit card processor can have a few different conventions they can actually be a fairly complex thing in and of themselves. That complexity is hidden in the use case diagram we're consciously try to keep this as simple as possible because it's a tool of communication between the business community and the I.T. world. Now with a check order status use case down here and fundamentally that's a little different than the others because this is something that you can't do as a shopper. You have to have placed an order meaning you have to have become a customer in order to use the check order status. So we've changed an actor name we have an actor called a customer. Now this is really interesting because it also shows that on a use case diagram the customer could be a shopper in the future until that customer has logged in. And we know that they are a known customer. They are going to be going under the generic shopper actor if they're already logged in. We know they're a customer. There may be other use cases that they could access in their role as customer. But in this particular example the only one we're interested in showing is the check order status check order status involves a shipping clerk who's going to give the customer information about where the when the package was shipped or when it's expected to be shipped. What the status of that order is finally the lines that you see connecting the actors with the use case in both sides. You'll see that they are a straight line. There's no arrow on them now. People by habit if you will can put an arrow on there because the initial interaction is going to come from Lubitsch the actors on the left which we call here primary actors. They are the only ones that can initiate one of these use cases they can trigger it whereas the secondary actors which by convention are on the right side of the diagram are the enter our actors that are going to be interacting with the use case in order to achieve the desired business goal namely getting the order shipped to the customer getting their money the connecting lines have no arrows for the very simple reason they indicate interaction. If you put an arrow head on him it looks like it's unit directional meaning it's only going from the actor to the use case or in the case of secondary actors perhaps from the use case to the secondary actor. You could put arrowheads on both ends which would then add something to the diagram that is not necessarily revealing because the lines by convention a solid line is interaction between two entities. In this case actors and use cases. So that's the connecting line. Very important that it's a solid line. It's not a dotted line the dotted line indicates this is a comment connected to some object on the diagram whereas the solid line indicates a connection between two different objects on the diagram.