Drawing Interactions: UML Use Case Diagrams in Action

UPI Study › Courses › Software Engineering › Free lessons › Lesson 6.8 Free with a free account

Drawing Interactions: UML Use Case Diagrams in Action

Software Engineering · Chapter 6: Requirements Engineering and PrototypingSection 6.8 · lesson 45 of 1036 min · free with a free account

← Organizing Data with Class-Based ModelingNext lesson: Mapping Data and Control Flow: DFDs and Control Flow Diagrams Compared and Applied →

Earn 3 college credits for Software EngineeringRecommended for credit by NCCRS · Computer Science 301 · self-paced · one payment, lifetime access

In this lesson

Who uses a system, and what they can do with it - at a glance.

  • Explain what a use case diagram shows, and leaves out
  • Identify actors, use cases, the system boundary, and associations
  • Read and draw include and extend relationships
  • Interpret a complete use case diagram

Transcript

Everything said in the video, section by section (857 words). Read along, or search it.

Requirements Engineering and Prototyping

Drawing Interactions: UML Use Case Diagrams

Before writing a single requirement in words, is there a way to sketch, at a glance, who uses a system and what they can do with it? That is what a U M L use case diagram is for. This section covers its four building blocks, the include and extend relationships, and how to read a complete diagram.

The Question

Who Can Do What Here?

A use case diagram is a visual summary of who interacts with a system, and what they can accomplish through it. It answers one question at a glance. Who can do what here? It does not describe how any of it happens, step by step. That is worth holding onto. A use case diagram is deliberately shallow. No screens, no data, no timing, and no order of steps. It only shows which outside roles connect to which goals, and how a few of those goals relate. The detailed behavior is written up separately.

Table 1

The 4 Building Blocks

Every basic use case diagram is built from four elements. An actor is drawn as a stick figure. It is a role outside the system, either a person or another system, that interacts with it. A use case is drawn as an oval, containing a short verb phrase. It is a discrete goal the system helps an actor accomplish. The system boundary is a labeled rectangle around the use cases. It separates what the system does from the actors outside it. And an association is a plain line from an actor to a use case, showing that the actor takes part in it.

Use Cases Relate Too

Include and Extend

Use cases can also relate to each other, not just to actors. Two relationships cover most of what shows up in practice, include and extend. And they are easy to confuse. Both are drawn as a dashed arrow between two ovals. The difference is which way the arrow points, and what that means. An include arrow runs from the base use case to the included one. The included use case happens every time. An extend arrow runs from the extending use case to the base one. It happens only sometimes, under a specific condition.

Figures 1 and 2

An Online Library System

Here is a complete diagram for an online library system. Two actors stand outside the system boundary, a member and a librarian. Inside the boundary are the use cases. Search catalog, borrow book, return book, and manage catalog. Borrow book has a dashed include arrow, pointing to verify membership. And apply late fee has a dashed extend arrow, pointing back to return book.

Reading the Diagram

Actors and Associations

Reading the actors first. The member is associated with three use cases. Search catalog, borrow book, and return book. The librarian is associated with manage catalog, and return book. Notice that an actor can be associated with more than one use case. And a use case can involve more than one actor, exactly as return book does here.

Reading the Diagram

Always vs. Sometimes

Now the relationships between use cases. The include arrow points away from borrow book, toward verify membership. That is because verifying membership is mandatory, every single time a member borrows a book. The extend arrow points away from apply late fee, toward return book. Applying a late fee is not part of every return. It only happens under a specific condition, when the book is overdue.

Think About It

Why Opposite Directions?

Here is a question to think about. Why do the two arrows point in opposite directions, relative to the main use case? Because each arrow points toward the use case being depended on. Borrow book depends on verify membership always happening, so the include arrow points there. Return book does not depend on apply late fee at all. But apply late fee depends on return book, as the point where it might get inserted. So its arrow points back to return book.

Apply It

A Checkout Use Case

Let's apply that. A checkout use case always calculates the shipping cost, but only sometimes applies a discount code, if the customer enters one. Calculating shipping cost always happens, so it is an include. The arrow points from checkout to calculate shipping cost. Applying a discount code only happens under a condition, so it is an extend. The arrow points from apply discount code, back to checkout.

Key Terms

The Vocabulary of This Section

Let's lock in the key terms. An actor is a role outside the system, drawn as a stick figure. It can be a person, or another system. A use case is a discrete goal the system helps an actor accomplish, drawn as an oval. The system boundary is the labeled rectangle around the use cases. An include relationship is a dashed arrow from a base use case to an included one, which always occurs. And an extend relationship is a dashed arrow from an extending use case to a base one, occurring only under a specific condition.

Key Takeaways

What to Carry Forward

To pull this together. A use case diagram shows who can do what with a system, without describing how. Actors, use cases, the system boundary, and associations are the four building blocks. An include relationship always happens, and its arrow points to the included use case. An extend relationship happens only under a condition, and its arrow points to the base use case. And either way, the arrow points toward the use case being depended on.

About Software Engineering at UPI Study

Software Engineering (Computer Science 301) is a self-paced online course of 103 video lessons in 15 chapters, from process models and agile to requirements, design, user interfaces, reliability, security and project management. It carries a NCCRS credit recommendation for 3 semester credits.

Every lesson transcript is free on pages like this one, and the videos are free with a free UPI Study account. Enrolling adds a practice quiz after each lesson, the graded work and final exam that earn the credit, lifetime access, and an official transcript on completion. UPI Study has helped over 130,000 students with college credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Compare: Software Engineering vs Systems Analysis

Why take it here

Why students take Software Engineering with UPI Study

How professional software gets builtSoftware Engineering covers how teams turn requirements into working, maintainable software: process models, agile, requirements, design, testing, reliability and project management. It is a core course in computer science and software degrees.
Credit at a fraction of the priceThe same 3 credits can cost $750 or more at a US college. Here it is one payment, self-paced, with lifetime access.
Finish your degree soonerTransfer credits reduce the courses you still owe, so you can graduate earlier or lighten a heavy semester.
Strengthen an applicationA completed college-level course on an official transcript shows admissions and scholarship committees you can do the work.
Study on your own scheduleNo start dates, no deadlines. Watch the lessons, practice, and take the final when you are ready.
130,000+students helped with college creditsACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Where the credit goes

Universities that work with NCCRS

Software Engineering carries a NCCRS credit recommendation. These universities work with NCCRS; some are UPI Study's signed partners. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Find my college → Not listed? Ask Athena in the corner of this page, or book a 15-minute call.

FAQ

Questions students ask us

About Drawing Interactions: UML Use Case Diagrams in Action

What is a UML use case diagram?
A UML use case diagram is a visual summary of who interacts with a system and what they can accomplish through it. It answers the question of who can do what at a glance. It is deliberately shallow, showing no screens, data, timing, or order of steps, and the detailed behavior of each use case is written up separately.
What are the main elements of a use case diagram?
A basic use case diagram has four elements. An actor, drawn as a stick figure, is a role outside the system, either a person or another system. A use case, drawn as an oval with a short verb phrase, is a goal the system helps an actor achieve. A labeled rectangle marks the system boundary, and plain lines show associations between actors and use cases.
What is the difference between include and extend in a use case diagram?
Both are dashed arrows between use cases, but include means the included behavior happens every time, while extend means it happens only under a specific condition. An include arrow points from the base use case to the included one. An extend arrow points from the extending use case back to the base. In both, the arrow points toward the use case being depended on.
Can one use case involve more than one actor?
Yes, a use case can be associated with several actors, and one actor can be associated with several use cases. In an online library system, a member is linked to search catalog, borrow book, and return book, while a librarian is linked to manage catalog and return book. Return book therefore involves both actors, each connected to it by its own association line.

About the Software Engineering course

How many college credits is Software Engineering?
Software Engineering (Computer Science 301) carries a NCCRS credit recommendation for 3 semester credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
How much does Software Engineering cost and what is included?
$250, paid once, with lifetime access: all 103 video lessons, a practice quiz after each, the graded work and final exam, and an official transcript when you finish. Students who want several courses choose UPI Study PRO instead.
Which universities accept UPI Study credits?
UPI Study has signed partner agreements with universities such as Thomas Edison State University, University of the People and Charter Oak State College, and works with universities such as Penn State, SNHU and SUNY. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities. Use "Find my college" on this page to check yours.
How long does Software Engineering take?
It is self-paced with no deadlines. The 103 lessons total about 11 hours of video; most students add reading and practice time and finish in a few weeks to a few months, on their own schedule.
How are the exams done?
Quizzes and assignments are online in the course. The final exam is taken online with proctoring; a person on the UPI Study team checks assignments, usually within two days.
How do my credits reach my college?
When the course shows 100% complete, request the official transcript from your dashboard. It is sent to the college you name, and you can send it to more than one. Check your college first with "Find my college" on this page, or ask Athena.

Ready for the full course? Earn 3 credits in Software Engineering.

103 video lessons, a quiz after each one, and the graded work that earns the credit. Recommended for credit by NCCRS.

Software Engineering
3 credits · NCCRS
Enroll →