Use case diagrams in Software Engineering - Step-by-Step Execution

Concept Flow - Use case diagrams

Identify Actors

↓

Identify Use Cases

↓

Draw Actors and Use Cases

↓

Connect Actors to Use Cases

↓

Add Relationships (include, extend)

↓

Review Diagram for Completeness

The flow shows how to create a use case diagram step-by-step from identifying actors to reviewing the final diagram.

Execution Sample

Software Engineering

Actors: Customer, Admin
Use Cases: Login, Purchase, Manage Inventory
Connections: Customer->Login, Customer->Purchase, Admin->Manage Inventory

This example lists actors and use cases, then shows how actors connect to use cases in a use case diagram.

Analysis Table

Step	Action	Details	Result
1	Identify Actors	Customer, Admin	Actors listed
2	Identify Use Cases	Login, Purchase, Manage Inventory	Use cases listed
3	Draw Actors and Use Cases	Actors as stick figures, Use cases as ovals	Basic diagram shapes created
4	Connect Actors to Use Cases	Customer->Login, Customer->Purchase, Admin->Manage Inventory	Relationships drawn
5	Add Relationships	Include 'Login' in 'Purchase'	Diagram shows include relationship
6	Review Diagram	Check all actors and use cases connected	Diagram complete and clear
7	End	All steps done	Use case diagram ready

💡 All actors and use cases identified and connected, diagram reviewed and finalized

State Tracker

Element	Start	After Step 1	After Step 2	After Step 4	After Step 5	Final
Actors	None	Customer, Admin	Customer, Admin	Customer, Admin	Customer, Admin	Customer, Admin
Use Cases	None	None	Login, Purchase, Manage Inventory	Login, Purchase, Manage Inventory	Login, Purchase, Manage Inventory	Login, Purchase, Manage Inventory
Connections	None	None	None	Customer->Login, Customer->Purchase, Admin->Manage Inventory	Include: Login in Purchase	All connections drawn

Key Insights - 3 Insights

Why do we identify actors before use cases?

Actors represent who interacts with the system, so knowing them first helps define what actions (use cases) they perform, as shown in execution_table step 1 and 2.

What does the 'include' relationship mean in a use case diagram?

It means one use case always uses another as part of its process, like 'Purchase' includes 'Login' in step 5 of the execution_table.

Can an actor connect to multiple use cases?

Yes, actors can interact with many use cases, for example, 'Customer' connects to both 'Login' and 'Purchase' in step 4.

Visual Quiz - 3 Questions

Look at the execution_table at step 4, which actor connects to 'Manage Inventory'?

A Admin

B Both Customer and Admin

C Customer

D No actor connects

💡 Hint

Check the 'Connections' column at step 4 in the execution_table

At which step does the diagram show the 'include' relationship?

A Step 3

B Step 4

C Step 5

D Step 6

💡 Hint

Look for 'Add Relationships' action in the execution_table

If we add a new actor 'Guest' who only logs in, which step would change?

A Step 1 only

B Steps 1 and 4

C Step 5 only

D No steps change

💡 Hint

Adding an actor affects actor list and connections, see variable_tracker and execution_table steps 1 and 4

Concept Snapshot

Use case diagrams show system users (actors) and their actions (use cases).
Actors are drawn as stick figures; use cases as ovals.
Connect actors to use cases with lines.
Use 'include' to show one use case uses another.
Helps understand system requirements visually.

Full Transcript

Use case diagrams visually represent how users interact with a system. The process starts by identifying actors, who are the users or external systems. Next, identify use cases, which are the actions or services the system provides. Then, draw actors as stick figures and use cases as ovals. Connect actors to the use cases they interact with using lines. Add relationships like 'include' to show when one use case is part of another. Finally, review the diagram to ensure it clearly shows all interactions. This step-by-step approach helps create clear and useful diagrams for understanding system behavior.

Practice

1. What is the main purpose of a use case diagram in software engineering?

easy

A. To test the software performance

B. To design the database schema

C. To write the program code

D. To show users and their interactions with system functions

Solution

1. Step 1: Understand the role of use case diagrams

   Use case diagrams visually represent how users (actors) interact with the system's functions (use cases).

2. Step 2: Compare with other software tasks

   Designing databases, coding, and testing are different activities not shown by use case diagrams.

3. Final Answer:

   To show users and their interactions with system functions -> Option D

4. Quick Check:

   Use case diagrams = show actors and interactions [OK]

Hint: Use case diagrams focus on users and their actions [OK]

Common Mistakes:

• Confusing use case diagrams with database design
• Thinking use case diagrams show code details
• Assuming use case diagrams test software

2. Which of the following is the correct symbol for an actor in a use case diagram?

easy

A. A stick figure

B. A rectangle

C. An oval

D. A diamond

Solution

1. Step 1: Identify actor symbol in use case diagrams

   Actors are represented by stick figures to symbolize users or external systems.

2. Step 2: Recognize other symbols

   Ovals represent use cases, rectangles and diamonds are not used for actors.

3. Final Answer:

   A stick figure -> Option A

4. Quick Check:

   Actor symbol = stick figure [OK]

Hint: Actors are stick figures in use case diagrams [OK]

Common Mistakes:

• Confusing actors with use cases (ovals)
• Choosing rectangles or diamonds for actors
• Not recognizing standard UML symbols

3. Consider a use case diagram with an actor "Customer" connected to two use cases: "Place Order" and "Track Order". What does this connection represent?

medium

A. Customer is a system component

B. Customer can perform both placing and tracking orders

C. Use cases depend on each other

D. Customer is a database entity

Solution

1. Step 1: Understand actor-use case connections

   Lines between an actor and use cases show the actor can perform those actions.

2. Step 2: Interpret the given connections

   Customer connected to "Place Order" and "Track Order" means the customer can do both activities.

3. Final Answer:

   Customer can perform both placing and tracking orders -> Option B

4. Quick Check:

   Actor connected to use cases = actor performs those actions [OK]

Hint: Lines show actor's possible actions [OK]

Common Mistakes:

• Thinking actors are system parts
• Assuming use cases depend on each other
• Confusing actors with database entities

4. A use case diagram shows an actor connected to a use case with a dashed arrow labeled "<<include>>". What is the likely issue if the arrow is drawn as a solid line instead?

medium

A. The diagram incorrectly shows a direct association instead of an include relationship

B. The actor symbol is wrong

C. The use case should be a rectangle

D. The diagram is missing actors

Solution

1. Step 1: Understand <<include>> notation

   The <<include>> relationship is shown with a dashed arrow from one use case to another, not from actor to use case.

2. Step 2: Identify the error in arrow style

   A solid line from actor to use case shows direct association, not an include relationship, so the diagram is incorrect.

3. Final Answer:

   The diagram incorrectly shows a direct association instead of an include relationship -> Option A

4. Quick Check:

   Include = dashed arrow between use cases, not solid actor line [OK]

Hint: <<include>> uses dashed arrows between use cases only [OK]

Common Mistakes:

• Drawing solid lines for <<include>>
• Confusing actor symbols with use case symbols
• Misplacing <<include>> arrows from actors

5. You want to model a system where a "User" can either "Login" or "Register" before accessing "Dashboard". Which use case diagram structure correctly shows that "Dashboard" use case requires either "Login" or "Register" first?

hard

A. "Login" and "Register" use cases extend "Dashboard" use case

B. "Dashboard" use case extends "Login" and "Register" use cases

C. "Dashboard" use case includes both "Login" and "Register" use cases

D. Login" and "Register" use cases are actors

Solution

1. Step 1: Understand include vs extend relationships

   Include means mandatory sub-function; extend means optional or conditional addition.

2. Step 2: Model login/register before dashboard

   Since "Dashboard" requires either "Login" or "Register" first, "Dashboard" use case includes both "Login" and "Register" use cases to show mandatory preconditions.

3. Final Answer:

   "Dashboard" use case includes both "Login" and "Register" use cases -> Option C

4. Quick Check:

   Include = mandatory use case inclusion [OK]

Hint: Use include for mandatory preconditions before main use case [OK]

Common Mistakes:

• Using extend instead of include for mandatory steps
• Confusing actors with use cases
• Reversing direction of include/extend arrows