Prepare Usecase Model

ASSIGNMENT NO. 2

AIM: With respect to your selected Problem Statement or given System / Project. Identify
Major Use Cases, Identify actors. Write Use Case specification for all major Use Cases. Draw
detail Use Case Diagram using UML2.0 notations.

OBJECTIVES:-

1. To develop Use Case Model.

2. To study how to analyzed requirements can be used for Use Case Model.

THEORY:

Use Case :

A use case is a description of a set of sequences of actions, including variants, that a system
performs to yield an observable result of value to an actor. Graphically, a use case is rendered as
an ellipse.

Names
Every use case must have a name that distinguishes it from other use cases. A name is a textual
string. That name alone is known as a simple name; a path name is the use case name prefixed
by the name of the package in which that use case lives. A use case is typically drawn showing
only its name, as in Figure.

Figure Simple and Path Names

Use Cases and Actors

An actor represents a coherent set of roles that users of use cases play when interacting with
these use cases. Typically, an actor represents a role that a human, a hardware device, or even
another system plays with a system. For example, if you work for a bank, you might be a
LoanOfficer. If you do your personal banking there, as well, you'll also play the role of
Customer. An instance of an actor, therefore, represents an individual interacting with the system
in a specific way. Although you'll use actors in your models, actors are not actually part of the
system. They live outside the system.

Computer Laboratory- VIII PCCOE-IT-A.Y.2019-20 Page 1

 Prepare Usecase Model

As Figure indicates, actors are rendered as stick figures. You can define general kinds of
actors (such as Customer) and specialize them (such as CommercialCustomer) using
generalization relationships.

You can use the UML's extensibility mechanisms to stereotype an actor in order to provide a
different icon that might offer a better visual cue for your purposes.

Actors may be connected to use cases only by association. An association between an actor and
a use case indicates that the actor and the use case communicate with one another, each one
possibly sending and receiving messages.

Use Cases and Flow of Events

A use case describes what a system (or a subsystem, class, or interface) does but it does not
specify how it does it. When you model, it's important that you keep clear the separation of
concerns between this outside and inside view.

You can specify the behavior of a use case by describing a flow of events in text clearly enough
for an outsider to understand it easily. When you write this flow of events, you should include
how and when the use case starts and ends, when the use case interacts with the actors and what
objects are exchanged, and the basic flow and alternative flows of the behavior.

For example, in the context of an ATM system, you might describe the use case ValidateUser
in the following way:
Main flow of events:
The use case starts when the system prompts the Customer for a PIN number.
The Customer can now enter a PIN number via the keypad.
The Customer commits the entry by pressing the Enter button.
The system then checks this PIN number to see if it is valid. If the PIN number is valid, the
system acknowledges the entry, thus ending the use case.
Exceptional flow of events:
The Customer can cancel a transaction at any time by pressing the Cancel button, thus restarting
the use case. No changes are made to the Customer's account.

Computer Laboratory- VIII PCCOE-IT-A.Y.2019-20 Page 2

 Prepare Usecase Model

Exceptional flow of events:

The Customer can clear a PIN number anytime before committing it and reenter a new PIN
number.
Exceptional flow of events:
If the Customer 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 Customer from interacting with
the ATM for 60 seconds.

You can specify a use case's flow of events in a number of ways, including informal structured
text (as in the example above), formal structured text (with pre- and postconditions), and
pseudocode.

Use Cases and Scenarios

Typically, you'll first describe the flow of events for a use case in text. As you refine your
understanding of your system's requirements, however, you'll want to also use interaction
diagrams to specify these flows graphically. Typically, you'll use one sequence diagram to
specify a use case's main flow, and variations of that diagram to specify a use case's exceptional
flows.
It is desirable to separate main versus alternative flows because a use case describes a set of
sequences, not just a single sequence, and it would be impossible to express all the details of an
interesting use case in just one sequence. For example, in a human resources system, you might
find the use case Hire employee. This general business function might have many possible
variations. You might hire a person from another company (the most common scenario); you
might transfer a person from one division to another (common in international companies); or
you might hire a foreign national (which involves its own special rules). Each of these variants
can be expressed in a different sequence.
This one use case (Hire employee) actually describes a set of sequences in which each sequence
in the set represents one possible flow through all these variations. Each sequence is called a
scenario. A scenario is a specific sequence of actions that illustrates behavior. Scenarios are to
use cases as instances are to classes, meaning that a scenario is basically one instance of a use
case.
There's an expansion factor from use cases to scenarios. A modestly complex system might have
a few dozen use cases that capture its behavior, and each use case might expand out to several
dozen scenarios. For each use case, you'll find primary scenarios (which define essential
sequences) and secondary scenarios (which define alternative sequences).

Use Cases and Collaborations

A use case captures the intended behavior of the system (or subsystem, class, or interface) you
are developing, without having to specify how that behavior is implemented. That's an important
separation because the analysis of a system (which specifies behavior) should, as much as
possible, not be influenced by implementation issues (which specify how that behavior is to be
carried out). Ultimately, however, you have to implement your use cases, and you do so by
creating a society of classes and other elements that work together to implement the behavior of

Computer Laboratory- VIII PCCOE-IT-A.Y.2019-20 Page 3

 Prepare Usecase Model

this use case. This society of elements, including both its static and dynamic structure, is
modeled in the UML as a collaboration.
As Figure shows, you can explicitly specify the realization of a use case by a collaboration.
Most of the time, though, a given use case is realized by exactly one collaboration, so you will
not need to model this relationship explicitly.
Figure Use Cases and Collaborations

Organizing Use Cases

Figure shows Generalization, Include, and Extend

Include
An include relationship between use cases means that the base use case explicitly incorporates
the behavior of another use case at a location specified in the base. The included use case never
stands alone, but is only instantiated as part of some larger base that includes it. You can think of
include as the base use case pulling behavior from the supplier use case.

Computer Laboratory- VIII PCCOE-IT-A.Y.2019-20 Page 4

 Prepare Usecase Model

Generalization:
Generalization among use cases is just like generalization among classes. Here it means that the
child use case inherits the behavior and meaning of the parent use case; the child may add to or
override the behavior of its parent; and the child may be substituted any place the parent appears.

Extend:
An extend relationship between use cases means that the base use case implicitly incorporates
the behavior of another use case at a location specified indirectly by the extending use case. The
base use case may stand alone, but under certain conditions, its behavior may be extended by
the behavior of another use case. This base use case may be extended only at certain points
called, not surprisingly, its extension points.

Common Modeling Techniques:

To model the context of a system,

 Identify the actors that surround the system by considering which groups require help
from the system to perform their tasks; which groups are needed to execute the system's
functions; which groups interact with external hardware or other software systems; and
which groups perform secondary functions for administration and maintenance.
 Organize actors that are similar to one another in a generalization/specialization
hierarchy.
 Where it aids understandability, provide a stereotype for each such actor.
 Populate a use case diagram with these actors and specify the paths of communication
from each actor to the system's use cases.

Figure Modeling the Context of a System

Computer Laboratory- VIII PCCOE-IT-A.Y.2019-20 Page 5

 Prepare Usecase Model

To model the requirements of a system,

identifying the actors that surround it.

provide.

variant
behavior into new use cases that extend more main line flows.

to attach some of these to the whole system

Figure Modeling the Requirements of a System

To model the behavior of an element,

 Identify the actors that interact with the element. Candidate actors include groups that
require certain behavior to perform their tasks or that are needed directly or indirectly to
perform the element's functions.
 Organize actors by identifying general and more specialized roles.
 For each actor, consider the primary ways in which that actor interacts with the element.
Consider also interactions that change the state of the element or its environment or that
involve a response to some event.
 Consider also the exceptional ways in which each actor interacts with the element.
 Organize these behaviors as use cases, applying include and extend relationships to factor
common behavior and distinguish exceptional behavior.

Computer Laboratory- VIII PCCOE-IT-A.Y.2019-20 Page 6

 Prepare Usecase Model

When you model use cases in the UML, every use case should represent some distinct and
identifiable behavior of the system or part of the system. A well-structured use case

 Names a single, identifiable, and reasonably atomic behavior of the system or part of the
system.
 Factors common behavior by pulling such behavior from other use cases that it includes.
 Factors variants by pushing such behavior into other use cases that extend it.
 Describes the flow of events clearly enough for an outsider to easily understand it.
 Is described by a minimal set of scenarios that specify the normal and variant semantics
of the use case.

When you draw a use case in the UML,

 Show only those use cases that are important to understand the behavior of the system or
the part of the system in its context.
 Show only those actors that relate to these use cases.

Use case Diagram Elements

Element Icon Description

Basic Section
Use Case The description of what a system does, not how the system does it. A Use
Case contains multiple scenarios, each of which describes a specific flow
of events through the Use Case. Scenarios in Use Cases must be
described clearly enough for outsiders to understand.
Package A grouping of model elements. Packages are used in Use Case, Class, and
Component diagrams. A Package can be nested within another Package,
and can contain both subordinate packages and ordinary model elements.
Packages can be subsystems of models. The entire system description can
be thought of as a single, high-level subsystem package containing all of
the system's modeling elements.
Actor A coherent set of roles that users of a system play when interacting with
the system's Use Cases.
Actors can be anything: human beings, devices, or other systems.
Actors can have attributes and operations, which do not appear on the
Actor element, but in the Documentation window.
A physical object can play several roles and thus can be modeled by
several Actors.
Include The dependency between Use Cases in which the source use case
explicitly incorporates the behavior of another Use Case at a specified
location.

Computer Laboratory- VIII PCCOE-IT-A.Y.2019-20 Page 7

 Prepare Usecase Model

Extend A dependency between Use Cases in which the Use Case extends the
behavior of the source.
Generalization Generalization is the taxonomic relationship between a more general
element and a more specific element that is fully consistent with the first
element and that adds additional information. This link is also known as a
specialization or inheritance link
Association The link that associates an Actor to a Use Case. This link shows
participation of an Actor in a Use Case and is the only relationship
between Actors and Use Cases.
Dependencies Section
Dependency The relationship between two elements whose definitions depend on one
another in such a way that changes to one can result in changes to the
other. For example, when one class mentions another as an operation
parameter, or as part of its data, the two classes exhibit dependency.
Realize A semantic relationship between classifiers. One classifier specifies a
contract that another classifier guarantees to carry out. These
relationships are used in two places: between interfaces and the classes
that realize them, and between use cases and the collaboration that realize
them.
Usage A dependency in which one element (the client) requires the presence of
another element (the supplier) for its correct functioning or
implementation.
Permission A dependency that signifies granting of access rights from the supplier
model element to a client model element, in which the client requires
access to some or all of the constituent elements of the supplier.
Abstraction A boundary relative to the perspective of the viewer. The essential
characteristics of an entity that distinguish it from all other kinds of
entities.
Comments Section
Comment A Notepad notation. Use Comments to record information for an element
or link in a diagram. This information is not included in generated code
but is for information only. Each Comment can contain unlimited text,
and can be numbered. You can also define a stereotype, and enter a noted
element.
Link The connection between the comment element and the associated
Comment element.

Computer Laboratory- VIII PCCOE-IT-A.Y.2019-20 Page 8

 Prepare Usecase Model

INPUT/OUTPUT:

INPUT: Problem Statement with SRS.

OUTPUT: Designed Use Case Model with specification of each specification.

CONCLUSION:

Thus we have studied how to develop Use Case Model and prepare specification of Use Case.

ORAL QUESTIONS:-

1. What is Mean by Use Case?

2. What are types of Use cases?
3. What is mean by Actor?
4. What is include?
5. What is extend ?
6. What is Use Case Realization?
7. What is Use Case generalization?
8. What are steps of identifying use cases and actors?

Computer Laboratory- VIII PCCOE-IT-A.Y.2019-20 Page 9