Use case diagrams in Software Engineering - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the sentence to define a use case diagram.

Software Engineering

A use case diagram shows [1] and their interactions with the system.

Drag options to blanks, or click blank then click option'

Aactors

Bclasses

Cvariables

Dfunctions

Attempts:

3 left

💡 Hint

Common Mistakes

Confusing actors with classes or functions.

Thinking use case diagrams show code details.

A use case diagram visually represents actors (users or other systems) and how they interact with the system.

2fill in blank

medium

Complete the sentence to describe the purpose of use case diagrams.

Software Engineering

Use case diagrams help to [1] the system's functional requirements.

Drag options to blanks, or click blank then click option'

Aignore

Bdelete

Cvisualize

Dcompile

Attempts:

3 left

💡 Hint

Common Mistakes

Choosing words related to coding instead of visualization.

Misunderstanding the diagram's role in requirements.

Use case diagrams visualize how users interact with the system to fulfill requirements.

3fill in blank

hard

Fix the error in the sentence about use case diagrams.

Software Engineering

Use case diagrams show [1] and their methods.

Drag options to blanks, or click blank then click option'

Avariables

Bclasses

Cobjects

Dactors

Attempts:

3 left

💡 Hint

Common Mistakes

Confusing use case diagrams with class diagrams.

Thinking use case diagrams show code structure.

Use case diagrams show actors and their interactions, not methods which belong to classes.

4fill in blank

hard

Fill both blanks to complete the description of use case diagram elements.

Software Engineering

In a use case diagram, [1] represent users or external systems, and [2] represent the actions they perform.

Drag options to blanks, or click blank then click option'

Aactors

Bclasses

Cuse cases

Dvariables

Attempts:

3 left

💡 Hint

Common Mistakes

Mixing up actors with use cases.

Thinking classes or variables are part of use case diagrams.

Actors are users or external systems interacting with the system, and use cases are the actions or services they perform.

5fill in blank

hard

Fill all three blanks to complete the sentence about use case diagram relationships.

Software Engineering

The [1] relationship shows that one use case is a specialized version of another, the [2] relationship shows required behavior, and the [3] relationship connects actors to use cases.

Drag options to blanks, or click blank then click option'

Ageneralization

Bassociation

Cinclude

Dinheritance

Attempts:

3 left

💡 Hint

Common Mistakes

Confusing inheritance with generalization in use cases.

Mixing up include and association relationships.

Generalization means one use case is a specialized form of another. Include shows required behavior included in a use case. Association connects actors to use cases.

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