Scribd
Upload
20 views4 pages

Use Case Diagrams

The document provides a comprehensive overview of use-case and ER diagrams, highlighting their definitions, purposes, and key differences. It details important terminologies related to use-case diagrams, such as actors, use-cases, and relationships, while also offering guidance on creating these diagrams effectively. Additionally, it outlines common mistakes to avoid and best practices to follow when designing use-case diagrams.

Uploaded by

huzaifaltaf605
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
20 views4 pages

Use Case Diagrams

The document provides a comprehensive overview of use-case and ER diagrams, highlighting their definitions, purposes, and key differences. It details important terminologies related to use-case diagrams, such as actors, use-cases, and relationships, while also offering guidance on creating these diagrams effectively. Additionally, it outlines common mistakes to avoid and best practices to follow when designing use-case diagrams.

Uploaded by

huzaifaltaf605
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 4

Part 1: Clearing Up Your Understanding

1. Use-Case Diagram Basics

• What It Is: A graphical representation that shows the interaction between actors (users or systems) and use-
cases (functions or tasks) in a system.
• Purpose: It helps understand what the system should do from an end-user's perspective.

2. ER Diagram Basics

• What It Is: A graphical representation of entities (like tables in a database) and their relationships.
• Purpose: It focuses more on the data structure — how different data elements are connected, usually in database
design.

Part 2: Key Differences Between Use-Case and ER Diagrams


Feature Use-Case Diagram ER Diagram
Focus System functions and user interactions Data entities and their relationships
Components Actors, use-cases, relationships Entities, attributes, relationships
Usage System requirements and behavior Database design and structure
Connections Include, Extend relationships One-to-one, one-to-many, many-to-many

Part 3: Important Terminologies for Use-Case Diagrams


1. Actor

• Who It Is: A person, system, or external entity that interacts with the system.
• Example: In an online shopping system, a customer or payment system is an actor.

2. Use-Case

• What It Is: A specific function or task the system performs.


• Example: Placing an order or making a payment.

3. System Boundary

• What It Is: The box that defines the scope of the system being designed. All use-cases are inside it.
• Purpose: Shows what is part of the system and what is not.

4. Relationships in Use-Case Diagrams

a. Include

• When Used: When a use-case always needs another use-case to work.


• Example: Processing payment includes validating payment details.
b. Extend

• When Used: When a use-case sometimes needs another use-case based on certain conditions.
• Example: Logging in can extend to password recovery if the user forgets their password.

Correcting Misconceptions
1. Explicit and Implicit Relationships: These terms are not used in use-case diagrams. Instead, we use include
and extend.
2. Include vs. Extend:
o Include: Necessary actions; always happen.
o Extend: Optional actions; happen under specific conditions.
3. Focus of Use-Case vs. ER Diagrams:
o Use-Case = User interactions and system functions.
o ER Diagram = Database structure and data relationships.

Part 4: How to Create a Use-Case Diagram


Step 1: Read the Case Study Carefully

• Identify Actors: Look for users, external systems, or other stakeholders that interact with the system.
• Identify Use-Cases: Highlight all the functions or tasks the system should perform.

Step 2: Categorize Use-Cases

• Core Use-Cases: Main tasks that the system must perform.


• Supporting Use-Cases: Tasks that assist core use-cases.

Step 3: Identify Relationships

• Include: If a use-case cannot function without another use-case.


• Extend: If a use-case may optionally use another use-case.

Step 4: Draw the Diagram

1. Draw a box for the system boundary.


2. Place actors outside the boundary and use-cases inside.
3. Use arrows to show interactions.
o Label with <> or <> where necessary.

Example for Better Understanding


Scenario: Online Shopping System

• Actors: Customer, Admin, Payment System


• Use-Cases: Search Product, Place Order, Process Payment, Manage Inventory
• Include Example: Place Order includes Process Payment.
• Extend Example: Place Order extends to Apply Discount (if there’s a promo code).

Arrows and Lines in Use-Case Diagrams

1. Basic Association Line:


o What It Looks Like: A solid line connecting an actor to a use-case.
o Arrow Direction: Usually, the arrowhead points toward the use-case to show the direction of interaction.
However, some people skip the arrowhead and just use a solid line.
o Purpose: Shows basic interaction — who uses the system and what they do.
2. Include and Extend Relationships:
o What They Look Like: Dotted lines with an arrowhead pointing toward the use-case being included or
extended.
o Label: We explicitly label them as <> or <> to clarify the relationship.
o Purpose:
▪ Include: A use-case always needs another use-case.
▪ Extend: A use-case optionally extends another based on a condition.

Clearing Up Your Understanding

• The basic solid line with a simple arrow is not double-headed. It's a basic connection showing interaction.
• The dotted line with a single arrowhead is for include or extend relationships. These lines are always labeled
with <> or <>.

Example in Simple Words:

• Customer — solid line → Place Order (basic interaction)


• Place Order — dotted line labeled <> → Process Payment (must happen)
• Place Order — dotted line labeled <> → Apply Discount (optional)

I'm glad to hear you're feeling confident about use-case diagrams! Since you want to be thorough, let me quickly go over
any last details, common mistakes, and tips to make sure nothing is missed.

Final Checklist and Warnings for Use-Case Diagrams

A. Common Mistakes to Avoid:

1. Forgetting Labels:
Always label include (<<include>>) and extend (<<extend>>) relationships properly. Without the labels, the
meaning can get confusing.
2. Incorrect Arrow Direction:
The arrowhead should always point toward the use-case that is being included or extended. Double-check the
direction!
3. Mixing Up Actors and Use-Cases:
o Actors are always outside the system boundary.
o Use-cases are inside the boundary.
o Don't treat actors as use-cases or vice versa.
4. Overcomplicating the Diagram:
o Only include relevant actors and use-cases — keep it simple and focused.
o Don't try to show every single detail of the system; use-case diagrams are meant to give an overview, not
intricate details.
5. Using Arrows for Basic Association Lines:
For simple actor-to-use-case associations, a solid line without arrows is often fine. No need to overthink it!

B. Best Practices:

1. Keep Actor Names Simple:


Use descriptive yet simple names like Customer, Admin, User, etc. Avoid technical jargon.
2. Clear System Boundary:
Clearly draw the system boundary box and keep all use-cases inside it. Actors should be outside.
3. Logical Grouping:
If there are multiple actors interacting with similar use-cases, consider grouping them logically to avoid a
cluttered look.
4. Review Your Use-Cases:
Ensure each use-case represents an observable function of the system from the user's perspective — no internal
technical processes.

C. Quick Warning:

• Overusing Extend and Include:


Use <> when a use-case must happen (necessary function).
Use <> when it’s optional (conditional function).
Avoid these relationships if a simple basic interaction can explain it. Overuse makes the diagram hard to understand.

D. Last Tip:

• Read the Scenario Carefully: When working with case studies to create use-case diagrams, underline or highlight phrases
like "must happen," "optional," "only if," "necessary," etc. These often indicate potential include or extend relationships.

That wraps it up! If you feel confident now or need any last clarifications, just let me know. You're all set to make some
solid use-case diagrams!

You might also like