Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
An overview of the Use Case Model, a key component of software development. The Use Case Model illustrates the system's intended functions, its surroundings, and relationships between use cases and actors. It includes constructs like actors, use cases, use case relationships, and use case diagrams. Actors represent anyone interacting with the system, while use cases represent the functionality provided. Use case relationships, such as association, uses, extends, and inheritance, define the interactions between actors and use cases.
Typology: Slides
1 / 11
This page cannot be seen from the preview
Don't miss anything!
Logical View
Process View
ViewImplementation
Process,Threads
Source, binary, executable componentscollaborationsClasses, interfaces,
Deployment View
Nodes
Use Case View
Use cases
Captures system functionality as seen by users
Built in early stages of development
Developed by
(^) analysts and domain experts
System behavior
, that is what functionality it must provide, is
documented
(^) in a use case model.
illustrates the system’s
(^) intended functions
(^) (use cases), its
surroundings
(^) (actors), and
(^) relationships
(^) between the use cases
developers to^ • provides a vehicle used by the customers or end users and theand actors (use case diagrams).
(^) discuss the system’s functionality and behavior
.
(^) identification of actors
(^) and
principal use cases
(^) for the system, and is then matured in the
elaboration phase, by adding more details and additional use cases.
measurable result of values for a particular actor.sequence of transactions performed by a system that yields a
Place Order
inside:In the UML, a use case is represented by an oval with a name
Association
Two types of relationships that may exist between use cases:
(^) uses
and
extends
(^) relationship is used to show:
-Different flows which may be run based on actor selectionas triggering an alarm-Behavior that is only run under certain conditions, such-Optional behavior
is related to these uses cases by a^ • A functionality shared by multiple use cases can be placed in a separate use case which
(^) uses
(^) relationship.
Inheritance:
description of the events needed to accomplish the required behavior.Each use case is documented with a flow of events, which is a
describe what the system should do and not how the system does it.The flow of events is written in the language of the domain and
The flow of events should include: -The description of any alternate or exceptional flows-The normal sequence of events for the use case-What data is needed by the use case-What interaction the use case has with the actors-When and how the use case starts and ends
Template:
X Flow of Events for the <
name
> Use Case
X.4 Alternative FlowsX.3 Subflows (if applicable)X.2 Main FlowX.1 Preconditions
Where X is a number from 1 to the number of use cases
use case model contains all the use cases).Contains only architecturally significant use cases (whereas the final
(^) logical view
(^) is derived using the use cases identified in the
architectural view of the use case model.
Architecturally significant use cases
as performance, responses times etc.-use cases that have the most important nonfunctional requirements, such-critical use cases, those that are most important to the users of the system
Secondary and optional use cases are not key to the architecture.
Customer
Query
Withdrawal Transfer Deposit
Validation
<
Customer Foreign
Bank Customer
Maintain
OfficerBank
ATM System
Handle Exception
<
Check PIN
Collect statistics
<
Advertise
Example: Textual Description for Check PIN Use Case
X Flow of Events for the <
name
> Use Case
X.4 Alternative FlowsX.3 Subflows (if applicable)X.2 Main FlowX.1 Preconditions
Where X is a number from 1 to the number of use cases
Flow of Events for
(^) Check PIN
(^) Use Case
Main flow of events
: The use case starts when the system prompts the
(^) User
(^) for a PIN
number. The
(^) User
(^) can now enter a PIN number via the keypad
(^) (E1)
. The
(^) User
(^) commits
the entry by pressing the Enter button
(^) (E2)
. The system then checks this PIN number to see
if it is valid
(^) (S1, E3)
. If the PIN number is valid, the system acknowledges the entry, thus
S1: Subflows: ending the use case. (^) The system invokes
(^) Validate
(^) use case.
E1: Alternative flow of events: (^) The (^) User
(^) can clear a PIN number any time before committing it and reenter a new PIN
E2: number. (^) The (^) User
(^) can cancel a transaction at any time by pressing the Cancel button, thus
restarting the use case. No changes are made to the
(^) User’s
(^) account.
E3: (^) If the
(^) User
(^) enters an invalid PIN number, the use case restarts. If this happens three
times in a row, the system cancels the entire transaction, preventing the
(^) User
(^) from
interacting with the ATM for 30 minutes.
