Use Case diagram

1
Object-Oriented Analysis and Design Inception
Requirements and Use Case Modeling
2
Use Case Model Use case model is a model that
describes a systems functional requirements in
terms of use cases. Use cases are a widely used
mechanism to discover and record requirements.
Use cases are primarily functional requirements
that indicate what the system will do. A use
case is a description of an interaction that
achieves a useful goal for an actor. It is a
collection of related success and failure
scenarios that describe actors using a system to
support a goal. Use cases defined for system
requirements are the foundation for all other
development activities, including design,
implementation, and testing.
3

• Several concepts are important
• The goal is the business value to the user of
  the system who usually initiates the interaction
  with the system.
• The system is the application with all its
  associated hardware that will be used by the
  user.
• An actor is the external entity that interacts
  with a system. It is something with behavior,
  such as a person, computer system, or
  organization.
• Scenario a scenario is a specific sequence of
  actions and interactions between actors and the
  system under discussion.

4
System Historically, systems have been
understood utilizing three basic models black
box, white box, and transparent box. Each
successive model provides increasing detail into
the internals and implementation of the
system. The black box model, shown as the solid
boundary, emphasizes the value the system
provides and where it fits into the rest of the
business computing environment. It presents the
system without concern about how it provides the
business value. Here the key concepts are the
users of the system (including other systems) and
the value the system provides to each user.
5
(No Transcript)
6
The white box model, shown as the oval, presents
the system in terms of what specific business
functions the system provides. This model
emphasizes how objects in the system map to
business processes. A white box model does not
concern itself with the hardware or software
architecture. The transparent box model, shown
as the very small circles, presents the internals
of the system and how they contribute to the
business functionality. Each circle represents an
internal element, whether it be source code or
device. In this model, technology entities
employed within the system are included as well
as details about how they work together to
provide the business functionality.
7
In the design of use cases, we should view the
system as a black box. Experience has shown us,
however, that it is sometimes necessary to take
at least a white box view to determine the
sequence of interaction between an actor and the
system. This helps us define the use case.
Furthermore, when we are doing low-level concrete
use cases, we probably have to take a transparent
view of the system.
8
Actors The use-case model divides the world into
two parts the system and the users (the external
entities that use it). Actors are a mechanism for
categorizing the users (usually a physical
entity) of the system who share a set of common
interactions to achieve a set of goals. An actor
can be a user, an external system, or a device.
An actor can make a service request of the
system, be requested to provide a service, and
interact with the system through a complex dialog
of service requests between the actor and the
system. An actor is a representation of any
entity that can initiate an action on the part of
the system or receive a request for an action
from the system. The complete set of
requests/responses for all actors establishes a
boundary on the domain of which the system can be
aware.
9
A number of actors may share common requests that
they all invoke on the system. Rather than
explicitly associate the same set of requests
with each actor, we can introduce a generalized
actor that encompasses those common requests. The
other actors are treated as specializations and
inherit the ability to perform those requests
from the generalization.
10
Use Cases A scenario is a little story that
outlines some expected sequence of request and
responses between a user and the system. It is
used to convey how a specific user employs the
system to achieve some useful goal. Writing a
scenario is a simple game of what happens
next. Most scenarios are simple there is only
one logical sequence of operations from the
initial state. Other scenarios are more
complicated, with multiple exception cases
(things going wrong) or different interaction
paths (options). A use case is closely related
to a scenario. The Figure in the next slide
illustrates a simple use case diagram for a
course registration system. A use case describes
a system in terms of sequences of interactions
between various actors and the system.
11
(No Transcript)
12
Use case is a formal way of describing all the
interactions between the actors and the system to
achieve the business goals of the system. The
actor that initiates the use case is called the
initiation actor. In most interactions, the
dialog may result in the interaction of the
system with other actors these actors are called
participating actors.
13

• The interaction assumes that the system is a
  "black box" and uses domain elements as actors
  that interact with the system in a
  request/response manner. A use case identifies
• the pre-conditions that must exist for it to be
  valid,
• the post-conditions that define the state of the
  system after the use case has concluded,
• detailed business that is performed,
• business exceptions that may arise,
• and business constraints that apply to the
  system in reacting to a specific actor request.

14

• In capturing the functional aspects of the
  system, one of the difficulties in generating a
  useful discussion of a system is keeping the
  description at a consistent level of abstraction.
  For use cases to be successfully developed, it is
  necessary to know the dimension of the functional
  description that one is attempting to capture.
  Then one can determine the level of detail in the
  information that should be captured.
• High-Level vs. Low-Level
• Primary vs. Secondary
• Essential vs. Concrete

15
High-Level vs. Low-Level In one dimension, we
can distinguish between high-level and low-level
functional descriptions of a system. A high-level
description provides general and brief
descriptions of the essence of the business
values provided. It is not concerned with how the
business values are achieved. A low-level
description provides business details showing the
exact order of activities, tasks, or
alternatives. For example, a high-level
description of Shakespeare's Romeo and Juliet is
that it is a love story. A low-level description
includes the kinds of details about the story as
presented in study guides. Neither level
description is actually the story.
16
For requirements analysis for a computer
application, focus on use cases at the level of
elementary business process (EBPs). EBP is a
term from the business process engineering field,
defined as A task performed by one person in one
place at one time, in response to a business
event, which adds measurable business value and
leaves the data in a consistent state.
17
Primary vs. Secondary In a second dimension, we
can distinguish between primary and secondary
functions of the system. Primary functions are
the essential business functionalities of the
system-the functions provided to users-and
constitute the reason for which the system
exists. The secondary processes deal with the
rare and exceptional cases. These are the
functions that are necessary to deliver a robust
system. Processes such as backing up data,
downloading needed data from other systems may
not be the primary reason for building the
system, but they are essential processes that are
almost always required. We consider those cases
to be primary cases.
18
Essential vs. Concrete Finally, in a third
dimension, we can distinguish between the
essential and the concrete functions of the
system. The essential use cases are business
solutions that are independent of implementation
(hardware and software), while the concrete use
cases are design-dependent. The distinction
between essential and concrete is the distinction
between black box and transparent box models.
19
Relations Among Use Cases IncludeA typical use
case outlines some sequence of interactions
between the initiator of a service request to the
system and the system. It often happens that some
sequences of interactions are common across
multiple use cases. In this situation, we can
extract these common sequences as a use case. We
then include the use case so formed within the
use cases from which they were extracted. When
this situation exists, we say that each of the
"multiple" use cases includes the common use case
(i.e., we can have an include relationship
between use cases). The includes relationship
allows us to localize in one use case a common
sequence of activities among several use cases.
This has the advantage that when changes occur in
this common sequence, then it only needs to be
changed in one place.
20
(No Transcript)
21
Extend In addition, we can have the situation
in which several use cases are identical with the
exception of one or two specific subsequences of
interactions. In this case, we can extract the
common core (base use case) and treat the use
cases that differ as extensions of this base use
case. Thus, an extend relationship exists between
an extension and the core. Generalization/Specia
lization Finally, in the development of a
high-level use case, it is often the case that it
can encompass several detailed and extended use
cases. The relationship that exists between the
high-level use case and the detailed and the
extended use case is a generalization/specializati
on relation.
22
(No Transcript)
23

• Use cases are written in different formats,
  depending on need,
• brief terse one-paragraph summary, usually of
  the main success scenario.
• casual informal paragraph format. Multiple
  paragraphs that cover various scenarios.
• fully dressed the most elaborate. All steps and
  variations are written in detail, and there are
  supporting sections, such as preconditions and
  success guarantees.

24

• Information Captured.
• One of the reasons for employing a use-case
  approach to bounding our system is the ease with
  which information can be identified. Use cases
  can capture the following set of information
• Actors A use case identifies all actors that
  participate in it.
• Relationships with other use cases
• A use-case description identifies the
  relationships (generalization/specialization,
  include, and extend relationships) that use cases
  have with each other.

25

• Pre-conditions
• A use case may require specific conditions to
  hold for it to be successfully invoked. All such
  conditions must be identified. In some cases,
  systems are intended to exhibit modality in
  behavior. That is, they are expected to operate
  in different modes and exhibit different
  behaviors for different modes. A pre-condition
  identifies the mode required and any other
  conditions that must hold for the use case to be
  valid. This includes information such as the
  action requested, confirmation of user identity,
  values that must hold, and any other factor that
  affects successful conclusion of the use case.

26

• Details
• A use case describes the details about how a
  system provides some service. The details of a
  use case identify the details of the sequences of
  interactions. The details are captured as
  step-by-step interactions among domain objects.
  Each step provides sufficient detail to identify
  which entities are involved, what each entity
  does, and the result of the step. This can be
  accomplished using text or sequence diagrams.

27

• Post-conditions
• The execution of a use case is intended to bring
  about some desired computation or state. The
  post-conditions identify exactly what results are
  expected from execution of the use case. This
  includes any side effects produced such as any
  objects created and all objects destroyed.

28

• Exceptions
• Every action performed in a use case is
  susceptible to error. Desired data may not be
  located, computations might be aborted, and
  connectivity lost. It is necessary to identify
  all possible errors that can occur in the use
  case. In addition, it is useful to identify what
  the specific actions should be taken to recover.
  Hence, for each exception we wish to know the
  circumstance in which it can occur and the action
  that should be taken.

29

• Constraints
• It is also necessary to identify all constraints
  that might apply to the use case. Such
  constraints can be on the values being
  manipulated, resources allocated to it, and
  resource allocations to various steps. There are
  usually the invariant conditions (i.e., the
  conditions that must always be true). The
  invariant conditions must hold at the beginning
  (pre-condition) of the service (operation) and at
  the end (post-condition) of the service
  (operation). Violation of these constraints can
  also give rise to errors and these errors should
  be identified as an exception.

30

• Variants/Alternatives
• It is also necessary to identify all variations
  that might apply to the use case. These are
  usually the variations that are not covered by
  independent use cases. Usually these variations
  are either easily handled or they are considered
  as part of another use case.
• Of course, the actual information that is
  captured in a specific use case varies according
  to several factors. In particular, it varies on
  whether it is (1) high level or low level and (2)
  essential or concrete.

31
DOCUMENTING USE CASES An important aspects of
use cases is documenting them in a fashion that
provides greater understanding of the domain.
Since a picture is worth a thousand words, a
highly useful and informative way to document use
cases is to use the UML notation. .
32
Use-Case Diagram A use-case diagram is a diagram
that shows the relationships among actors and use
cases within a system. Use-case diagrams describe
what a system does from the standpoint of an
external observer. The emphasis is on what a
system does rather than how. An example use-case
diagram is illustrated in Figure 6.3, page 90 of
the textbook. An actor is illustrated as a stick
figure person, even in situations in which it is
an external system. Individual use cases are
represented as ovals labeled with the name of the
use case. Lines connect actors with the use case
they initiate or connect the use cases with the
participating actors from which the system makes
requests. If the interaction is unidirectional,
the line is terminated by an arrow. The direction
of the arrow is from the requestor to the
provider of a service.
33
In some situations, the interaction is
bidirectional and the link is illustrated as a
double-headed arrow. In this case, the actor can
generate a request of the system or it can
request the actor to take some action. This might
be the case in which the manager wants to monitor
specific accounts for specific activities and the
system generates alerts requesting manager
attention when specific events occur. The system
may perform periodic queries against the account
database to identify when the event
occurs. Use-case and actor generalization/special
ization is illustrated with a triangle at the end
of a line. The lines originate at the
specializations and point with the triangle
towards the generalization. In the example, the
actor bank employee is a generalization of the
specialization actors bank teller and bank
manager. (in class exercise draw a use case
diagram)
34
System Sequence Diagram Documenting the
Details The details of a use case can be
documented utilizing sequence diagrams. A system
sequence diagram shows the order in which
messages are exchanged between the actor(s) and
the system. In a system sequence diagram, the
system is represented by rectangular boxes. From
that rectangular box, there is an extended
vertical dashed line. Message exchanges between
actors and the system are illustrated as directed
arrows and are labeled by the message being
communicated. The sequence of messages is read
from the top down thus, time elapses from top to
bottom. Also when the dashed line is replaced
with a rectangle, this means that the object is
active and using resources during that time
period.
35
An example of a system sequence diagram capturing
the open account use case is illustrated in the
next slide. This example shows how a bank manager
requests the system to create a new account. The
system asks for information about the customer,
which the bank manager provides. The system then
requests the bank manager to identify the type of
account, which the bank manager provides. The
system requests the initial balance information,
which the bank manager provides. Once all of the
information has been acquired, the system
requests the account database to create a new
account. The bank manager is then informed by the
system that an account has been successfully
created.
36
(No Transcript)
37
Textual Description In addition to graphic
representations of use cases, it is common
practice to use textual descriptions of
individual use cases. A textual description
contains the information identified in the
previous section. The key value of textual
descriptions is that more information is captured
than in graphical descriptions. As a result, most
practitioners use a combination of use-case
diagrams to provide an overview of the system,
sequence diagrams to capture the interactions,
and textual descriptions to capture the
pre-conditions, post-conditions, exceptions,
invariant conditions, and variations.
38
Template for Documenting Use Cases

Use-Case Name Description A one or two sentence
description of the use case. Actors Identifies
the actors participating in the use
case. Includes Identifies the use cases included
in it. Extends Identifies the use case that it
may extend. Pre-Conditions Identifies the
conditions that must be met to invoke this use
case. Details Identifies the details of the use
case. Post-Conditions Identifies the conditions
that are assured to hold at the conclusion of
the use case. Exceptions Identifies any
exceptions that might arise in execution of this
use case. Constraints Identifies any
constraints that might apply. Variants
Identifies any variations that might hold for the
use case. Comments Provides any additional
information that might be important in this use
case.