Object-Oriented System Analysis And

Design
Chapter II- Modeling using
UML
Understanding modeling tools
in system/software
development

Chapter Objective
To

be familiar with UML diagrams

To appreciate different aspects
modeling process in system
development

12/06/15

Chapter II- Topics

Overview-

The UML
Functional Model
Use Case Diagram (essential and system)
Structural

Model

Class/object, Component and

Deployment Diagram
Behavioral

Models

Activity, State chart, sequence

/collaboration
3

Overview- The UML

12/06/15

OO METHODOLOGIES
During the early 90s, there were around 50 O-O
methodologies among them:

Rumbaughs Object Modeling Technique (OMT):

Class and Associations

Shlaer-Mellor
(OOA/D),

Booch Method : Categories and Subsystems

Wirfs-Brock
(Responsibility-Driven
Design/Class/Responsibility/Collaboration)
RDD/CRC,

Coad/Yourdon Methodology : Class, Object, Class-&-

(Object-Oriented

Analysis/Design

Object

Jacobson Object-Oriented
(OOSE) Use case driven

Software

Engineering

PROBLEMS
The existence of different OO
methodologies resulted in the
following problems:
Resulted in multitude
interpretation of same concepts
Encouraged confusion
Limited the progress of methods
Methods influenced one another

THE NEED FOR STANDARDIZATION

There

are many methods and notations

competing with each other that users are
distracted by the decisions they need to make.

Existing

methods are already converging since

these methods pick up ideas from other
sources.

single, common language is desirable

because it can be used for all development
methods, used throughout the project lifecycle,
and used for different application technologies.

THE UNIFICATION
Based

on the fact that differences between

the various methods were becoming
smaller.
The method wars did not move OOT any
longer.
Jim Rumbaugh and Grady Booch decided at
the end of 1994 to unify their work within a
single method: the Unified Method.
Definition of a universal language for O-O
modeling
Unified Method 0.8 Oct. 1995

THE UNIFICATION
A year later they were joined by
Ivar Jacobson

Objective: Standardization of the

o-o development process
The
Unified
Method
was
transformed
into
UMLthe
Unified Modeling Language
6/96 UML 0.9
9/96 UML 0.91
A consortium of partners created

THE UNIFIED MODELLING LANGUAGE

(UML)

A language whose vocabulary

and
rules
focus
on
the
conceptual
and
physical
representation of a system.
UML defines structural and
behavioral
things
and
diagrams.
UML
is
the
language
of
blueprints for software.

UML
It

is a graphical language for

Visualizing
Specifying building models that are
precise, unambiguous, and complete
Constructing possible to map from
a model in the UML to a
programming language
Documenting
Intended

systems

for software-intensive

WHAT UML IS NOT

UML

is
not
a
method
or
methodology (Method = Notation
(e.g.,UML) + Process)
UML does not dictate a particular
process
UML can be used to record the
resulting
domain
and
design
models, independent of the process
Choose an appropriate process for a
particular project, independent of
the modeling language

WHY USE UML

Standardized

notation without sacrificing

specialized model data
Common language that can be used from
product conception to delivery, from
system to detailed design levels
Reduced learning curve across projects
Increased domain and design model
reuse
Increased
customer
involvement
/understanding of problem translation to
product solution

UML STRUCTURE
UML

Common
mechanisms

Building
blocks
Building

blocks

things
relationships
Diagrams

Common

mechanisms

specifications
Adornments/ dicoration
common divisions
extensibility mechanisms

Architecture

Architecture

usecaseview
logicalview
processview
implementationview
deploymentview

The Unified Modeling

Language (UML)

UML has three building blocks:

Things, the objects.

Relationships, the glue that holds
things together.
Diagrams, categorized as either
structure or behavioral.

UNDERSTANDING UML

BUILDING BLOCKS OF UML

1. Things the abstractions

1.

Structural things nouns, static, represent

conceptual or physical elements: Class, interface,
collaboration, use case, active class, component, and a
node

2.

Behavioural things verbs, dynamic, represent

behaviour over time and space: Interaction and state
machine

3.

Grouping things organizational parts of UML:

Packages

4.

Annotational things explanatory parts of UML:

Note

BUILDING BLOCKS OF
UML

2. Relationships tie things together

A.

Dependency (uses) a semantic

relationship between two things in which
a change to one thing (the independent
thing) may affect the semantics of the
other thing (the dependent thing)
A car uses a fuel

B. Association a structural relationship that

association
describes a set of
links, a link being a
connection among
objects.
0..1
*
employe
r
role

employee

name

BUILDING BLOCKS OF UML

C.
Generalization
(is
a)

a
specialization/generalization relationship in
which objects of the specialized element
(the child) are substitutable for objects of
the generalized element (the parent)

BUILDING BLOCKS OF
UML
3. Diagram

The graphical representation of a set

of elements
Help to visualize a system from
different perspectives
May contain any combination of
things and relationships.

UML DIAGRAMS
Diagrams used to describe structure

Class diagram
Object diagram
Component diagram
Deployment diagram

Diagrams used to describe behavior and

Function

Use Case diagram (functional)

Sequence diagram
Activity diagram
Collaboration diagrams
Statechart diagram

Commonly Used UML

Diagrams

The most commonly used UML

diagrams are:
Use case diagram, describing how
the system is used.
The starting point for UML modeling.

Activity diagram.
Each use case may create one activity
diagram.

Commonly Used UML

Diagrams

Sequence diagram, showing the

sequence of activities and class
relationships.
Each use case may create one or
more sequence diagrams.
A collaboration diagram is an
alternative to a sequence diagram.

Commonly Used UML

Diagrams

Class diagram, showing classes

and relationships.
Sequence diagrams and CRC cards
are used to determine classes.

Statechart diagram.
Each class may create a statechart
diagram, useful for determining
class methods.

Overview of UML
Diagrams

RULES OF UML
UMLs

building blocks should be put together to

develop a well-formed model.
A model that is semantically self-consistent and in
harmony with all its related models.
The UML has semantic rules for
Names: What you can call things, relationships, and diagrams
Scope: The context that gives specific meaning to a name.
Visibility: How those names can be seen and used by others
Integrity: How things properly and consistently relate to one
another.
Execution: What it means to run or simulate a dynamic model.

COMMON MECHANISMS IN
UML
Systems development using UML can be made simpler
by the presence of common mechanisms:
1.

Specifications Behind every part of UMLs graphical

notation there is a specification that provides a textual
statement of the syntax and semantics of that building
block.

2.

Specification are used to state the systems details.

Provides a semantic backplane that contain all the parts of
all the models of the system.
Example a class diagram

Adornments Most elements in the UML have a unique and

direct
graphical
notation
that
provides
a
visual
representation of the most important aspects of the element.

Every element in the UMLs notation starts with a basic

symbol, to which can be added a variety of adornments to
that symbol.

COMMON MECHANISMS IN UML

3. Common divisions
Class and Object

4. Extensibility mechanisms
UML can be extended using the following mechanisms

Stereotypes: Extends the vocabulary of UML, allowing you

to create new kinds of building blocks that are derived from
existing ones but that are specific to your problem.

Constraints: Extends the semantics of a UML building block,

allowing you to add new rules or modify existing ones.

ARCHITECTURE
Architecture is the set of significant decisions
about
The organization of a software system
The selection of the structural elements and their
interfaces by which the system is composed
Their behavior, as specified in the collaborations
among those elements
The composition of these structural and behavioral
elements into progressively larger subsystems
The architectural style that guide this organization:
the static and dynamic elements and their
interfaces,
their
collaborations,
and
their
composition.

ARCHITECTURE
Software

architecture is not only concerned with

architecture and behavior, but also with usage,
functionality, performance, resilience`(elasticity),
reuse,
comprehensibility,
economic
and
technology constraints and trade-offs, and
aesthetic concerns.
Architecture of a system can be described by a
view.
A view is simply a subset of UML modeling
constructs that represent one aspect of the
system
Each of the views involve structural and
behavioural models

Views of a system
Systems

can be viewed from a number of

perspectives
different stakeholders: system owners, end
users, analyst, developers, project managers
etc
Each looks at the system in different angle at
different times over the projects life span
System architecture can be used to manage
these different viewpoints, therefore
controlling the development of a system
throughout its life cycle

 UML

captures these different angles/viewpoints as a

set of five interlocking views: -

system assembly
configuration mangmt

vocabulary
functionality

Designview

Use case view

behavior

Processview
performance
scalability
throughput

Implementationview

Deploymentview
system topology
distribution
delivery
installation

Eachviewfocusedonaparticularaspectofthesystem,arestand
aloneandinteractwitheachother

Use

case view

Focuses on scenarios executed

by human users and external
systems
Expresses what the new system
will do without specifying how it
will do it
End-product: use case diagrams

Design

views

Supports the functional requirements of the

system
Focuses on the things (classes, interfaces and
collaborations) that form the vocabulary of the
problem that the system is trying to solve and
the elements of the solution to that problem.
The view encompasses the static and dynamic
aspects of the system
End-product: class and object diagram (static),
sequence/collaboration, activity and statechart
diagram (dynamic)

Process

view

Focuses on the aspects of the

system that involves timing and
the flow of control.
Addresses the performance,
scalability and throughput of the
system
End product: activity diagrams

Implementation

view

Encompasses the components and files that are

used to assemble and release the physical
system
End-product: component diagrams
Deployment

view

Focuses on the geographic distribution of the

various software elements on hardware and other
physical elements that constitute a system
Encompasses the nodes that form the systems
hardware topology on which the system executes
End-product: deployment diagram

Functional Model
Use Case Diagram
Essential
System

12/06/15

37

USE CASE MODEL

Use

Case analysis is one of the first and

primary means of gathering requirements
in the behavioral methodology.
Use cases are a standard technique for
gathering requirements in many modern
software development methodologies.
Used to capture the intended behaviour
of the system under development
(requirements of a system)
The Use case diagram is used to identify
the primary elements and processes that
form the system.
38

Cont
Represents

the
functional
requirements of a system under
development
Captures the business processes
carried out in the system
A use case model may consists of
Single use case diagram
Further (nested) packages of use case
diagrams

The

supreme package of the nested

packages is the use case model

Cont..
Use

case Modeling could be

Essential
Used at requirement elicitation stage
Technology free
Just to understand what users need to
see on the system from functions point of
view

System
Is a continuation of essential use case
Adding implementation related details
12/06/15

40

System Use case Modeling

The

system use case talks more about more or

less same concept like the essential use case with
some details of the implementation.
The modeling will be influenced by the technology
to be used for the systems development.
System use case model is composed of the
system use case diagram and its corresponding
documentation.
The use case diagram and the documentation will
have same components as the essential use case
model with little technology influence.

Components
Diagram

with the following

components
Actors
Use cases
Boundary
Relationship (Associations, include or
use, Extend)

Documentation

For each use case using the standard

template

USE CASE DIAGRAM

Shows

the relationship between

actors and use cases in a system
A use case diagram for a system
consists of :

The system boundary

Actors
Use cases
Relationships (among use cases,
among actors, and between actors
and use cases)
43

On-line Bookstore
System

Register

Custome
r

Order
books

Sell used
books

Use Case
Functional
Requirements
Diagram

Review
books
44

What is the difference with the previous

use case?
Sell Item

Reorder
Sales Clerk

<
<

In
cl
u

de
s>

>

<<Includes>>

Login
Add to Stock

<<Includes>>

<<Includes>>

Generate
Report

Manager

Cont
The

Use Case documentation needs

information like:
List of Actors
List of Business Rules (BR)
List of User Interfaces (UI)

The

template will be the same as the

essential use case documentation except that
the Include and Extend part will be
exercised (included) at this level.
The following example describes one of the
use cases documentation from the previous use
case diagram.

Use case documentation

Name
Identifier
Description
Actor
PreCondition
PostCondition

SellItem
UC008
Sellavailableitemsinastoretoacustomer
SalesClerk
none
Thesalesclerkwillselltheitemifavailableinstore

none
Extends
UC001
Includes
BasicCourseofAction
1.TheSalesClerkwanttosellanitem
2.TheSalesClerklogsintothesystemusingUC001:Login
3.ThesystemdisplaysthemainWindowUI002:MainMenu
4.TheSalesClerkselectsSellfromtheMainMenu
5.ThesystemdisplaystheSellinterfaceUI006:SellItem
6.TheSalesClerkselectstheitemsandquantityhewanttosell
7.ThesystemchecktheavailabilityoftheitemsaccordingtothebusinessruleBR012:checkavailabilityofitem
8.ThesystemdisplaysthetotalamountofmoneytobepaidwiththeitemlistviaUI013:PaymentVoucher
9.TheSalesClerkindicateshewanttoprintthepaymentvoucher.
10.Thesystemprintsthepaymentvoucher
11.TheusecaseendswhentheSalesclerkreceivethemoneyandgivethepaymentvouchertocustomer.
AlternativeCourseofActionA:Theitemisnotavailableinstore
8.Thesystemdeterminesthattheitemisnotavailable.
9.ThesysteminformstheSalesClerkthatthetransactioncannotbecompletedviaUI014:ItemQuantitynotAvailable
10.Theusecasesresumesatstep6ofthebasiccourseofaction

Cont
Note

Association between Actors and Use

cases dictate the need for Interfaces
(screen or Report)
Use case description does not
include unexpected interruption of
the action either by the actor or by
system failure
The flow of events should be in
action-response style.

General steps in Use case

Modeling
Identify

actors from the SRS or

problem definition
Identify use cases
Identify relationships
Use symbols for representing use
cases and actors with in a
boundary
Define use case description
12/06/15

49

Actor
An

actor define roles that users can

play.
Actors model anything that needs to
exchange information with the system
The
different
roles
the
actor
represents are the actual business
roles of users in a given system.
An actor in a use case diagram
interacts with a use case.
50

Actor
Actors

are external to the system. Actors

interact with the system.
Actor classes have actors instances or objects
that represent specific actors.
An actor is shown as a stick figure in a use
case diagram depicted "outside" the system
boundary.
To identify an actor, search in the problem
statement for business terms that portray
roles in the system.

51

USE CASES
A

use case is a specific way of using the

system by performing some part of the
functionality.
A visual representation of a distinct
business functionality in a system.
The business process is discrete in nature.
A use case describes what a system
does; not how.
List the discrete business functions in
your problem statement - potential use
case.
Remember that identifying use cases is a
discovery rather than a creation.
52

USE CASES
Ausecaseisshownasanellipseinausecasediagram

Use cases have the following characteristics:

Use case are interactions or dialogs between a system and actors,
including the messages exchanged and the actions performed by
the system. Use cases may include variants of these sequences,
including alternative and exception sequences.
Use cases may be initiated by actors and may involve the
participation of numerous other actors.
Use cases may have extension points that define specific points
within an interaction at which other use cases may be inserted
Use cases classes have use case instances or objects called
scenarios that represent specific interactions.
53

Use-Cases: describing how

the user will use the system
A

use case is a typical sequence

of actions that a user performs in
order to complete a given task

The objective of use case analysis is

to model the system from the point
of view of
how users interact with this system
when trying to achieve their objectives.
It is one of the key activities in
requirements elicitation and analysis
54

Use cases
A

use case should

Cover the full sequence of steps from

the beginning of a task until the end.
Describe the users interaction with
the system ...
Not the computations the system performs.

Be written so as to be as independent
as possible from any particular user
interface design.
Only include actions in which the actor
interacts with the computer.
12/06/15

55

Scenarios
A

scenario is an instance of a use

case
A specific occurrence of the use case
a specific actor ...
at a specific time ...
with specific data.

12/06/15

56

RELATIONSHIPS
Relationships

between actors and

use cases
are represented by directional or
nondirectional edges
May be annotated by stereotypes

May relate two use cases

May relate two actors, or
May relate a use case and an
actor
57

RELATIONSHIPS
Association

denoted as solid lines or paths.

Arrowheads may be used to indicate who
initiates communication in the interaction.
Includes
Indicates that the base use case will contain
the inclusion use case.
A base use case defines the location at which
the inclusion use case is included.
Denoted as dashed lines with an open arrowhead pointing at the inclusion use case and
are labelled with the <<include>> keyword
(stereotype).
58

RELATIONSHIPS

Extends

Indicates that the base use case may be

augmented by the extension use case; i.e., the
inclusion use case will augment the base use
case if an extension condition is satisfied.
A base use case defines the extension point.
Denoted
as dashed lines or paths with an open arrow-head
pointing an extension use case
labelled with the extension condition in square
brackets,
the <<extend>> keyword (stereotype), and
the extension point name in parentheses.
59

RELATIONSHIPS
Generalization
From specialization to generalized use case

Indicate the specialization use cases are consistent with

the generalized use case and may add additional
information.
A specialized use case may be used in place of a
generalized use case and may use any portions of the
interaction of the generalized use case.
Denoted as solid lines or paths with a hollow arrow-head
pointing at the generalized use case.

From specialization to generalized Actor

The specialized actor are consistent with the generalized

actor and may add additional information.
A specialized actor may be used in place of a generalized
actor and receives the characteristics of the generalized
actor.
Denoted as solid lines or paths with a hollow arrow-head
pointing at the generalized actor.
60

RELATIONSHIPS

<<includes>
>
<<includes>
>

61

System Boundary
The

use case describes the functionality of a

system from an outside point of view from
the users point of view.
Only the interaction between actors and
system are shown, what happens inside the
system is hidden.
This boundary is clarified by the system
boundary
Defines the scope of what a system will be.
A system boundary of a use case diagram
defines the limits of the system.
The system boundary is shown as a rectangle
spanning all the use cases in the system
62

SYSTEM BOUNDARY
A use case diagram depicting the system
boundary of a clinic application

63

RELATIONSHIPS

64

Good Practice
Develop

a use case diagram at

different levels wherever
appropriate.
Minimizes complexity

System level
Module level
Class
Interface
etc

65

FLOW OF EVENTS
Specify

the behavior of a use case by

describing the flow of events in text clearly
enough for an outsider to understand it
easily.
Include

How and when the use case starts and ends

When the use case interacts with the actors
What objects are exchanged
The basic flow and alternative flows of the
behavior

66

FLOW OF EVENTS(major
elements)

Introduction: Describe a quick background of the use

case.
Actors: List the actors that interact and participate in
this use case.
Actor Description/Definition: Define/Describe each
actor.
Pre-conditions: Pre-conditions that need to be satisfied
for the use case to perform.
Post-conditions: Define the different states in which
you expect the system to be in, after the use case
executes.
Basic Flow: List the primary events that will occur when
this use case is executed.
Alternative flows: Any subsidiary events that can
occur in the use case should be separately listed. List
each such event as an alternative flow. A use case can
have as many alternative flows as required.
67

COMMON MODELING TECHNIQUE

The most common thing for which you will

apply use case is to model the Functional
behavior of an element ; A system as a whole,
a subsystem, or a class
Focus on what that element does, not how it does

Reasons for applying use cases to elements

1. By modeling the behavior of an element with
use cases, you provide a way for domain
experts to specify its outside view to a
degree sufficient for developers to construct
its inside view.
2. Use cases provide a way for developers to
approach an element and understand it.
3. Use cases serve as the basis for testing each
element as it evolves during development.

68

HINTS AND TIPS: For developing use cases

The

goal is to develop a well-structured use

case that:
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.
69

HINTS AND TIPS

A

well-structured use case diagram

Is focused on communicating one aspect

of a systems static use case view.
Contains only those use cases that are
essential to understanding that aspect.
Provides detail content with its level of
abstraction.
Is not so minimalist as to misinform the
reader about semantics that are
important.
70

Example:
On-line Bookstore is a web application that can be

accessed by the stores registered customer,

whereby each customer can order books, review
one or more books sold in the book store, and sell
used books to other customers. Before performing
any one of these transactions, the customer must
first log-in into the system using their user id and
password kept in their account. The customer can
also take a book he/she ordered.
Problems:
Develop a use case model(system use case)-Provide your

reason to pick one as a component of your model

Document one of the use cases you have identified sell
used book

On-line Bookstore System

Register

<<extend>>
(CustID)

Customer

Check out

Order books
<<include>>

<<include>>

Log-in

Sell used
books
<<include>>

Review books
72

Use

case: Sell used books

Main flow of events: -

1. The CUSTOMER clicks the Sell Used Books button on the Home
Page.
2. The system displays the sell used books web page.
3. The CUSTOMER enters the required information on the used
books
that he/she wants to sell.
4. The CUSTOMER clicks the SEND button on the webpage.
5. The system displays a confirmation page listing the
information that
the CUSTOMER has entered.
6. The CUSTOMER checks that the information displayed are
accurate.
If yes, the CUSTOMER clicks the OK button on the web page.
7. The system updates the USED BOOKS table in the database.

73

The benefits of basing

software development on
They can
use cases

Help to define the scope of the system

Be used to plan the development
process
Be used to both develop and validate
the requirements
Form the basis for the definition of test
cases
Be used to structure user manuals
12/06/15

74

Use cases must not be seen

as a solution
The use cases themselves must be
validated
Using the requirements validation
methods.

Some aspects of software are not

covered by use case analysis.
Innovative solutions may not be
considered.

12/06/15

75

TO BE CONTINUED

12/06/15

76

Exercise-one

The clock shows the time of day. Using buttons,

the user can set the hours and minutes fields
individually, and choose between 12 and 24hour display. It is possible to set one or two
alarms. When an alarm fires, it will sound some
noise. The user can turn it off, or choose to
snooze. If the user does not respond at all, the
alarm will turn off itself after 2 minutes.
Snoozing means to turn off the sound, but the
alarm will fire again after some minutes of
delay. This snoozing time is pre-adjustable.
Q: Identify the top-level functional requirement for the
clock, and model it with a use case diagram.
12/06/15

77

Exercise-two

Open Road Insurance (ORI) is an independent agency that

receives policy contracts from various insurance companies.
The purpose of the ORI system is to provide automotive
insurance to car owners. Initially, a customer applies for
coverage via an application. The agency requests a drivers
record report from the local police department. The agency also
requests vehicle registration confirmation from the Department
of Motor Vehicles. An agent determines the best policy for the
type and level of coverage desired and sends the customer a
copy of the insurance policy along with an insurance coverage
card. The customer information is stored. Periodically, the
system generates a fee statement, which along with
addendums to the policy is sent to the customer, who responds
by sending in a payment with the fee stub.
12/06/15

78

Guide Lines

Ask who, what, and where about the tasks and

their inputs and outputs:
What are the major tasks performed?
What triggers this task? What tells you to perform
this task?
What information/forms/reports do you need to
perform this task?
Who gives you these information/forms/reports?
What information/forms/reports does this produce
and where do they go?
12/06/15

79