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
Free preview
Create a free account to keep watching
It takes a minute and costs nothing. Your free account unlocks all of Chapter 1 and 3 more lessons of Software Engineering.
Lesson complete
Earn the 3 college credits for Software Engineering
Enrolling adds a quiz after each lesson, the graded work and the official transcript. Recommended for credit by NCCRS.
Next lesson: Mapping Data and Control Flow: DFDs and Control Flow Diagrams Compared and Applied →← Organizing Data with Class-Based ModelingNext lesson: Mapping Data and Control Flow: DFDs and Control Flow Diagrams Compared and Applied →
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.
Enroll now → Course details Download the syllabus All Computer Science courses Every course with PRO →
Why take it here
Why students take Software Engineering with UPI Study
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.
Thomas Edison State UniversitySigned partner
University of the PeopleSigned partner
Charter Oak State CollegeSigned partner
Strayer UniversitySigned partner
Columbia Southern UniversitySigned partner
Indiana TechSigned partner
Penn StateWorks with NCCRS
Southern New Hampshire UniversityWorks with NCCRS
SUNYWorks with NCCRS
+many more cooperating universitiesFind my college →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?
What are the main elements of a use case diagram?
What is the difference between include and extend in a use case diagram?
Can one use case involve more than one actor?
About the Software Engineering course
How many college credits is Software Engineering?
How much does Software Engineering cost and what is included?
Which universities accept UPI Study credits?
How long does Software Engineering take?
How are the exams done?
How do my credits reach my college?
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.
3 credits · NCCRSEnroll →