OBJECT-ORIENTED PROGRAM DESIGN AND

ANALYSIS

Unified Modeling Language (UML) (Use Case Diagrams)

UML
• Unified Modeling Language(UML) is a general purpose
modeling language that is intended to provide a standard
way to visualize the design.
• Unified Modeling Language(UML) was released around
1997 by the Object Management Group (OMG).
• One of the purposes of UML was to provide the
development community with a stable and common
design language that could be used to develop and build
computer applications.
Definition
● Quite simply, the UML is a visual language for
modeling and communicating about systems through
the use of diagrams and supporting text.
● UML resulted from the merging of three very popular
Object Oriented Design methods by Grady Booch,
James Rumbaugh, and Ivar Jacobson.
● The three worked in separate organizations through
the 1980s and early 1990s, each devising his own
methodology for object-oriented analysis and design.
● UML is now under the control of the Object
Management Group (OMG) Check for updates at the
OMG Web site, http://www.omg.org
UML uses ...
UML different views ...
Definition ...
● UML consists of a number of graphical elements that
combine to form diagrams
● The diagrams is to present multiple views of a system;
this set of multiple views is called a model.
● In our discussion, a model is a set of UML diagrams
that we can examine, assess, and modify in order to
understand and develop a system.
● A UML model describes what a system is supposed to
do. It doesn't tell how to implement the system.
● UML has a number of diagrams, each providing a
certain view of your system. But we will concentrate
with common ones (with **) (refer next slide)
UML
• Use Case Diagram
• Context Diagram
• Class Diagram
• Sequence Diagram
• Collaboration Diagram
• State Diagram
• Activity Diagram
• Component diagram
• Deployment diagram
UML ...
Use Case Diagrams
● UML model used to graphically show the use cases
and their relationship to actors

● Automation Boundary is the boundary between

computerized portion of an application and the users
who operate the application
Use case
● Use case is an activity that the system performs, usually in
response to a request by a user. Use case define functional
requirements.
● The use case is a construct that helps analysts work with
users to determine system usage. A collection of use cases
depicts a system in terms of what users intend to do with it.
● Think of a use case as a collection of scenarios (related
sequence of steps) about system use. These scenarios would
emerge through conversations with users.
● Each scenario describes a sequence of events. Each sequence
is initiated by a person, another system or a piece of
hardware.
● Entities that initiate sequences are called actors. The result of
the sequence has to be something of use either to the actor
who initiated it or to another actor.
Actors
● Identifying actors help determine use cases in the
requirement Analysis phase of the Software
Development Process.
● Actor icon (Stick figure). Actor name (label for the
icon). One way to think of actors is to consider the
roles the actors play. In the real world, people (and
systems) may serve in many different roles; for
example, a person can be a salesperson, a manager, a
father, an artist, and so forth.
Techniques for identifying use cases
● User goal technique
● Used for small and simple systems
● Event decomposition technique
● Used for larger and complicated systems
User goal technique
● Step 1: identify all possible users for the new system(people and other
external systems).
● Step 2: classify all users into their functional roles(e.g. shipping,
marketing, sales etc).
● Step 3: classify users into their organizational level(e.g operations,
executives, professional etc)
● Step 4: Interview to find a specific goals(what they do).
● Start with current goal, then imagine new functionality that will add value.
● Use verb-noun phrasing (doing something)
● Add customer
● Update order
● Produce report
● Step 5: Create use case list organized by user type
● Step 6: Look for duplicates and resolve inconsistencies
● Step 7: Identify where different types of users need the same use cases
● Step 8: Review all the use cases with each type of user and the
stakeholders
Event decomposition technique
● More comprehensive and complete technique
● Event - something that occurs at a specific time and

place, can be described, and should be remembered

by the system. Eg adding a new account, deposite
money etc
● Identify the events that occur to which the system

must respond
● For each event, name a use case (verb-noun) that

describes what the system does when the event

occurs.
Type of events
● External events: An events that occurs, usually
initiated by external agent or actor. e.g customer pay
their bills
● Temporal events: An event that occurs as a result of

reaching a point in time. Set after some time. e.g

produce report automatically after some set time
● State events: An event that occurs when something

happen inside the system that triggers some process.

e.g Exceptions
Steps of events decomposition technique
● Step 1: consider external events in the system environments that
require a response from the system
● Step 2: for each external event, identify and name the use case
● Step 3: consider temporal events that require a response from the
system.
● Step 4: for each temporal event, identify and name the use case
that the system require and then establish the point of time that
will trigger the use case.
● Step 5: Consider the state events that the system might respond to
after internal state change
● Step 6: for each state event, identify and name the use case that the
system require and then define the state change.
● Step 7: When events and use case are defined, check to see if they
are required by using perfect technology assumption. Do not
include events that involve such system controls as login, logout,
change password, and backup or restore the database, as these are
put in later.
Representing a Use Case Model
● An actor initiates a use case, and an actor (possibly
the initiator, but not necessarily) receives something
of value from the use case.
● Graphic representation: An ellipse represents a use
case, and a stick figure represents an actor. The
initiating actor is on the left of the use case, (and the
receiving actor is on the right).
Representing a Use Case Model
● Many modelers omit the receiving actor, and the UML 2.0
specification doesn’t mention it. So actors can also appear on the
right hand side.
● The actor’s name appears just below the actor. The name of the use
case appears either inside the ellipse or just below it.
Representing a Use Case Model
● An association line connects an actor to the use case,
and represents communication between the actor
and the use case. The association line is solid.
● A rectangle is used (with the name of the system
somewhere inside) to represent the system boundary.
● The rectangle encloses the system’s use cases.
● The actors, use cases, and interconnecting lines make
up a use case model as shown in figure below.
Representing a Use Case Model
Representing a Use Case Model
Representing a Use Case Model
Example: A book Store system
Example Soda Machine System
Use Case Relationships
• There can be 5 relationship types in a use case diagram.
• Association between actor and use case
• Generalization of an actor
• Extend between two use cases
• Include between two use cases
• Generalization of a use case
Association between actor and use case
• An actor must be associated with at least one use case.
• An actor can be associated with multiple use cases.
• Multiple actors can be associated with a single use case.
Association between actor and use case
Uses or Include
• Include relationship show that the behavior of the included use case is
part of the including (base) use case.
• The main reason for this is to reuse the common actions across multiple
use cases.
• In some situations this is done to simplify complex behaviors.
• Few things to consider when using the <<include>> relationship.
• The base use case is incomplete without the included use case.
• The included use case is mandatory and not optional.
• To represent inclusion, you use a dashed line connecting the classes
with an arrowhead pointing toward common use case. Near the line,
you add the keyword include.
Uses or Include
Extends Relationship
• Many people confuse the extend relationship in use cases. As the name
implies it extends the base use case and adds more functionality to the
system. Here are few things to consider when using the <<extend>>
relationship.
 The extending use case is dependent on the extended (base) use
case. In the below diagram the “Calculate Bonus” use case doesn’t
make much sense without the “Deposit Funds” use case.
 The extending use case is usually triggered conditionally. In the
diagram you can see that the extending use case is triggered only for
deposits over 10,000 or when the age is over 55.
 The extended (base) use case must be meaningful on its own. This
means it should be independent and must not rely on the behavior of the
extending use case.
Extends Relationship
● The extends association is used when you have one use
case that is similar to another use case but does a bit
more. i.e. One Use case is extended to another use case
so that the latter has the behavior of the former in
addition to its own.
● In essence, it is like a subclass (do you remember
subclasses from inheritance?)
● Like inclusion, you visualize extension with a dashed line
and arrowhead along with a keyword “extend”
● For example in an accounting system one use case might
be “Add Account Ledger Entry”. This might have extending
use cases “Add Tax Ledger Entry” and “Add Payment
Ledger Entry”. These are not optional but depend on the
account ledger entry. Also they have their own specific
behavior to be modeled as a separate use case.
Extends Relationship
Extends Relationship
Generalization of actors
● Classes can inherit from one another, and so can
actors. In actors inheritance, the child actor inherits
the roles and meaning from the parent and adds its
own roles and meaning.
● You model generalization of actors the same way you
model generalization of classes with a solid line that
has an open triangle pointing at the parent.
Generalization of actors
Generalization of use cases
● Classes can inherit from one another, and so can use
cases. In use cases inheritance, the child use case
inherits the roles and meaning from the parent and
adds its own roles and meaning.
● You model generalization of use cases the same way
you model generalization of classes with a solid line
that has an open triangle pointing at the parent.
● Eg pay bill….pay bill by credit card….pay bill by m-pesa
Generalization of use cases
● Purchase Ticket contains the basic steps necessary for
purchasing any tickets, while the child use cases
specialize Purchase Ticket for the specific kinds of
tickets being purchased.
Use cases and actors in the generalization
relationship
The Use-Case Diagram for Appointment System
Use-Case Diagram with Specialized Actor
Use-Case Diagram with Specialized Actor
Use Case Description
● Use case name
● The actor who initiates the use case
● Description
● Assumptions for the use case
● Preconditions for the use case (what must be true
prior to executing the use case)
● Postconditions (what will be true after executing the
use case)
● Limitations.
Use Case Description
Use Case Description
Use Case Description-Example
Use Case Description
Use case Description
• Once you have your use cases, provide a brief description, describing
the basic steps taken by actor to complete the use case and other
related issues.
• Example
• Create customer account
• User enter new customer account data, the system and the system assigns account
number, creates a customer record and creates account record.
• Look up customer
• User enters customer account number, the system retrieves and displays customer and
account data.
Example: Withdraw money use-case description

● Use case name: Withdraw money

● Actors: AccountHolder (initiates), Bank system
● Description: AccountHolder selects an account, and amount, then
receives cash.
● Assumptions: User withdraws from one account, only. No daily limit
on withdrawal can withdraw entire balance. Transaction with Bank
system is successful.
Example: Withdraw money use-case description

● Preconditions: AccountHolder identity information is available.

● Post-conditions: If selected account has sufficient balance, cash is
dispensed and bank account is adjusted, accordingly. If selected
account has insufficient balance, no cash is dispensed.
● Transaction information is available to system (such as, for login).
Example: Deposit money use-case description
● Use case name: Deposit money.
● Actors: AccountHolder (initiator) and Bank system.
● Description: AccountHolder selects an account to deposit
to and inserts an envelope that (presumably) contains
the cash or a bank draft.
● Assumptions: User deposits to one account, only
Transaction with Bank system is successful.
● Preconditions: AccountHolder identity information is
available.
● Post-conditions:Bank account is adjusted, accordingly.
● Transaction information is available to system (such as,
for logging and receipt printing).
Documentation Property of a Use Case
• Note:
● Overall, a use case specification should not be very long

it should be only a few pages. If your specifications are

very long, you should reconsider whether your use case
is doing too much. It may be that it is actually more
than one use case.
● Also, for practical reasons, you cannot include all

possible things that could trigger an alternate flow.

Include the most important or critical alternates. Do
not include every possible error condition, such as
when the operator enters data in the wrong format (let
the user interface handle that type of exception).
Use case Description
Use case Description
Steps for Creating a Use Case Model
• The steps required to create a use case model are:
1.Review the business specifications and identify the
actors within the problem domain.
2.Identify the high-level events and develop the
primary use cases that describe the events and how
actors initiate them.
3.Review each primary use case to determine possible
variations of flow through the use case.
4.Develop the use case documents for all primary use
cases and all important use case scenarios.
Conclusion
● Better to create fewer use cases.
● 20 use cases for a large system.
● 50 use cases would be the maximum for a large system.
● Can nest use cases, if needed.
END