Use Case Diagrams

Karoly Nyisztor • Professional Software Architect
A free video tutorial from Karoly Nyisztor • Professional Software Architect
Senior Software Engineer, Author, Inventor
4.4 instructor rating • 4 courses • 17,676 students

Lecture description

The use case diagram visualizes the functional requirements of the system. Although it's simple, it's quite powerful. Let's see how it works.

Learn more from the full course

UML and Object-Oriented Design Foundations

Get started with Object-Oriented Design and the Unified Modeling Language (UML). Use UML for effective communication!

01:41:08 of on-demand video • Updated February 2021

  • Learn UML from a leading expert
  • Think as professional software designers
  • Gain a working knowledge of Object-Oriented Design and UML 2.0
  • Communicate more clearly and eliminate misunderstandings
  • Get the companion eBook for FREE! (sells for $28.80 on Amazon)
  • Get ready for technical job interviews
  • Increase your software development productivity
  • Create professional UML diagrams
English Let's start with the use case diagram. It's one of the simplest UML diagrams. Its purpose is to visualize the functional requirements of the system. Use case diagrams show groups of related use cases. Sometimes, they may include all of the use cases. The result is an overview of the system that may include several written use cases. You will rarely create use case diagrams for a single use case description. To represent the use case we draw an oval in the middle of the screen and put the title of the use case in it. "Create a trip entry," "Add trip," "Export app database." These are examples of use cases from our Travel Expense app mentioned earlier. We use stick figures to represent the actors. As you may recall, actors are human beings or other systems that may interact with our system. We draw the stick person to the left or the right of the diagram. The actor's name goes below the stick figure. We usually draw the primary actors on the left side and the secondary ones on the right side of the use case diagram. Next, we draw lines to represent the interaction between an actor and the use case. A mobile user can create or edit a trip entry, but he cannot export the app's database. The power user can perform all these actions, so I draw the lines accordingly. We need to visualize our system's boundaries if it interacts with other systems. For that, we draw a frame around all use cases and actors that belong to a given system. Let's say that we're relying on an external cloud-based storage. I'm going to represent this external system as a separate actor on the right side. I even change this visual representation to show that it's not a human actor. Most tools allow you to do that. The "Create trip entry" and the "Edit trip" use cases would rely on the cloud to back up their data. Thus, I connect these use cases with the external system. The frame makes it obvious where are app's boundaries end. Use case diagrams provide a clear way to communicate the high-level features and the scope of our system. You can quickly tell what our system does just by looking at this use case diagram. The system lets users create new trips and edit existing ones. Power users can even export the database. The app relies on an external cloud system to store its data. Such a simple diagram makes it clear what the system does and what it doesn't do. A customer or a user can easily see if needed features are missing. The absence of use cases shows what the system doesn't do. Now, the UML use case diagram includes other artifacts and relationships between use cases. We're going to ignore them as they tend to overcomplicate our design and the benefits are questionable. You can't go wrong if you focus on the actors, the use cases, and their interactions. You will be able to easily create your own use case diagrams and communicate your ideas in a clear and concise way. Use case diagrams provide an easy to understand overview of the features of our system. They are not a replacement for written use case descriptions, though. Use case descriptions include more information to ensure that we don't miss any of the important details or requirements.