Use cases
● In a use case diagram, an "include" relationship is used to show that the behavior
of one use case (the "included" use case) is inserted into the behavior of another use
🎯
case (the "base" use case). This creates a dependency where the base use case
must execute the included use case to be complete.
Here's a breakdown of why the other options are incorrect:
● T o show that one use case is a subset of another use case: This is not the
precise definition. While the included functionality is part of the base use case, the
relationship's primary purpose is to show mandatory inclusion of common behavior,
not a subset relationship in a formal sense.
● To show that one use case is independent of another Usecase: This is the
opposite of an "include" relationship, which explicitly creates a strong dependency.
● To show that One use case is an alternative to another use case: This describes
an "extend" relationship, where one use case provides optional functionality that
can extend the behavior of another under specific conditions.
nalogy: Think of making a purchase online. The main use case is "Place Order." This use
A
case would include other essential steps like "Calculate Shipping" and "Process Payment."
You cannot place the order without performing these steps; therefore, "Place Order"
depends on them.
● OOSE, which stands for Object-Oriented Software Engineering, is a methodology
developed by Ivar Jacobson. A fundamental part of this methodology is the use of
use cases to capture system requirements.
In use case modeling, actors represent users or other systems that interact with the system
being designed. These actors are typically categorized into two types:
● P rimary Actors: These are the actors that initiate an interaction with the system to
🧑💻
achieve a specific goal. They are the main drivers of the use case. For example, a
Customer who places an order.
● Secondary Actors: These are actors that the system needs to interact with to
complete the use case, but they don't initiate the interaction themselves. They are
🤖
often supporting systems. For example, a Payment Gateway that the system
contacts to process a payment.
ince OOSE is the methodology where use case modeling was formalized, it inherently
S
includes the concepts of both primary and secondary actors.
● A use case describes an interaction between an actor (a user or another system)
and a system to achieve a specific, valuable goal. A well-formed use case should
provide an observable result of value to the actor.
Let's look at the options:
● U pload the reel into the camera: This is likely too low-level. It's a single step or task
within a larger goal, such as "Record a home movie." It doesn't represent the
complete goal of the user.
● Negotiate a supplier contract: This is a high-level business process, not a system
use case. It involves many activities, discussions, and decisions that happen outside
of a single software system.
● Handle returns: This is a perfect example of a valid use case. It describes a
complete service that a system offers. An actor (e.g., a Sales Clerk) initiates the
🛍️➡️🔄
process, interacts with the system, and achieves a clear, valuable result (the return is
processed, inventory is updated, and the customer is refunded).
● Move piece on the chess board: Similar to the first option, this is just one step in a
larger use case like "Play a game of chess." The ultimate goal for the actor isn't just
to move one piece but to complete the entire game.
use case diagram is a high-level, visual representation of a system's functionality from an
🧑💻
external perspective. Its main purpose is to show who can do what with the system.
It identifies the different types of users (called Actors) of a system.
📝
It lists the specific goals or tasks (called Use Cases) that each actor can achieve by
interacting with the system.
Think of it as a menu for a restaurant: it tells you what you can order (the use cases) but
doesn't explain how the chef prepares the food (the technical details).
The other options are incorrect for the following reasons:
To describe the data flow: While interactions imply data exchange, use case diagrams don't
detail the specific data. Other diagrams, like sequence diagrams, are used for that.
To describe the technical design/architecture: Use case diagrams are "black box" diagrams.
They focus on the system's external behavior (the "what"), not its internal structure, design,
or architecture (the "how").
● In a UML use case diagram, an actor is any external entity that interacts with the
system. The key is that the actor is outside the system being modeled. This external
entity is not limited to just human users.
An actor can be:
🧑💻
● A person: This is the most common type of actor. For example, a Customer placing
an order or an Administrator managing users.
● A system: Another computer system that interacts with the system you are
🖥️
designing. For example, a Payment Gateway that processes credit card transactions
or a remote server that provides data.
● A software: This is very similar to a system. It could be an external API or another
software component.
● A hardware device or sensor: For example, a sensor that triggers an alarm system.
⏰
● A timer or clock: An actor that initiates a scheduled event, like a "Nightly Batch
Job".
ince an actor can be a person, a system, or a piece of software, "All of the above" is the
S
correct option.
This option perfectly captures the essence of a use case. A use case is not just a function;
it's a complete story about how an external user (actor) interacts with the system to get
something meaningful done (achieve a specific goal).
or example, on an e-commerce website, a "Purchase Item" use case involves all the steps
F
a customer (the actor) takes—from finding the item to entering payment details—to
successfully buy the product (the goal).
Here’s why the other options are incorrect:
● A representation of the system itself: The entire diagram, specifically the
boundary box, represents the system, not a single use case.
● A specific function or process within the system: This is too limited. It misses the
crucial context of the external actor and the valuable goal they are trying to achieve.
● A specific piece of hardware that interacts with the system: This describes a
type of actor, not a use case.
In a UML use case diagram, the <<extend>> relationship is used to show optional
functionality. It means that an "extending" use case can optionally add behavior to a "base"
use case at a specific point.
A single base use case can have multiple, independent points of extension, and therefore,
multiple different use cases can extend it. Each <<extend>> relationship represents a
different optional path or feature.
Example:
Imagine a base use case called "Place Online Order." This core process can be optionally
extended by several other use cases:
"Add Gift Wrapping": A customer might choose this option before checkout.
"Apply Coupon Code": A customer might have a discount code to apply.
"Add Delivery Instructions": A customer might want to add a special note for the driver.
In this scenario, the single "Place Online Order" use case is extended by three different use
cases.
That statement is the definition of what a test case is. A test case is a specific set of actions
and expected outcomes designed to verify a particular feature or piece of functionality
within a software system.
For example, to test a "Login" feature, you would create several test cases:
● T est Case 1: Enter a valid username and password to verify a successful login.
● Test Case 2: Enter a valid username and an invalid password to verify that an error
message appears.
● Test Case 3: Leave the username field blank to verify it prompts the user for input.
Each test case is designed to check a very specific aspect of the system's functionality. ✅
The correct answer is Context diagram and Use case diagram.
Explanation
oth of these diagrams are used to provide a high-level, external view of a system. They
B
show the same fundamental kind of information by defining the system's scope and its
interactions with the outside world.
Here's a breakdown of their similarities:
● S ystem Boundary: Both diagrams clearly show what is considered part of the
system and what is external to it.
○ External Entities/Actors: Both identify the people, organizations, or other
systems that interact with the system. A Context Diagram calls them
"External Entities," while a Use Case Diagram calls them "Actors," but they
represent the same concept.
● High-Level View: Both are used early in a project to understand the system's overall
context and purpose without going into the internal details of how it works.
hile a Use Case diagram goes a step further to name the specific goals (use cases) of the
W
actors, its core purpose of defining the system's boundary and its interactors is
fundamentally the same as a Context Diagram.
A use case description, also known as a use case specification, is a detailed document that
provides the textual details for a single use case. It typically includes several standard
components to fully describe the interaction.
The options listed are all essential parts of a complete use case description:
Title: A clear, concise name that identifies the use case's goal (e.g., "Login to Account").
Actors: The list of users or external systems that participate in the use case.
Preconditions: The conditions that must be true or the state the system must be in before the
use case can begin (e.g., for "Withdraw Cash," a precondition is that the ATM must have
cash and be connected to the network).
Since all three are standard and necessary components, the correct answer is that all
options are right. Other common elements include postconditions, triggers, and the detailed
flow of events.
In the context of a use case diagram, multiplicity refers to the number of actors that can be
associated with a use case and vice versa. It defines the numerical relationship between
them.
All the options describe valid scenarios where multiplicity is applied:
● A use case with multiple actors: This is common. For example, a "Video
Conference" use case could involve multiple "Participant" actors. Multiplicity would
define how many participants can be in a single conference (e.g., 2..*).
● Multiple use cases with a single actor: This is also very common. A single
"Administrator" actor can perform multiple use cases like "Create User," "Delete
User," and "Generate Report."
● Multiple use cases with multiple actors: This describes the overall complexity of a
typical system, where various relationships exist between different actors and
different use cases.
ince multiplicity is the concept used to define the numerical constraints in all of these
S
scenarios, "All of the above" is the correct answer.
Multiplicity in a UML diagram specifies the number of instances of one element that can be
linked to an instance of another element. In a use case diagram, this is shown on the
association line that connects an actor to a use case.
It answers questions like:
● H ow many actors of this type can participate in one instance of this use case?
● How many times can a single actor perform this use case?
Example:
"Play Chess Game" use case must be associated with exactly 2 "Player" actors. That
A
number '2' is the multiplicity, and it is a property of the association between the actor and
the use case.
The other options are different types of relationships:
● Generalization: An "is-a" relationship (e.g., a "Manager" is an "Employee").
● Include/Extend: Relationships between two use cases, not between an actor and a
use case.
In the object-oriented approach, the process typically follows these major phases: Analysis,
Design, and Implementation. The question asks for the model that deals with the "nitty-gritty"
details and directly "leads to implementation" (coding).
● A nalysis: This phase is about understanding the problem and defining what the
system needs to do. The models created here are high-level and conceptual. Think
of this as the architect's initial sketch.
● Design: This phase takes the conceptual model from analysis and creates a
detailed, technical blueprint for the solution. It defines how the system will be built,
specifying the exact classes, their methods, data types, and how they will interact.
🛠️
This is the "nitty-gritty" step that developers use to write the code. Think of this as the
detailed construction blueprint.
● Deployment: This happens after the system is built (implemented). It's the process
of installing and running the software in its production environment.
herefore, the Design model is the detailed, nitty-gritty step that directly leads to
T
implementation.
