Introduction to UML & Object Oriented Analysis

INTERNAL
January 21, 2009

Course Objectives - OOM

To understand the concepts of object oriented

analysis and design
To be able to analyze and design a case study of
moderate complexity using the object oriented
approach

-2-

Object Oriented Modelling

INTERNAL

Introduction
Owning an hammer doesnt make one an architect
Knowing a OO language like Java is a necessary but insufficient first step to create object systems!

Knowing How to Think in Objects is critical

We will try to cover many possible activities, artifacts, principles and guidelines which help
us to effectively think in objects
In all these activities a critical ability in OO Development is to skillfully assign
responsibilities to software objects.
In this first part we cover OO Analysis Its an investigation of the domain objects (doing the
right thing)
In the next part we cover OO Design where we focus on a conceptual solution that fulfills
the requirements .Its about doing the thing right

-3-

Object Oriented Modelling

INTERNAL

Overview OOMI Orientation Session 1

Introduction
Introduction to UML
Evolution of UML
Model Views and UML Diagrams
OO Requirement Analysis
Analysis Approach
Use Case Model
Domain Model

-4-

Object Oriented Modelling

INTERNAL

What is UML?
The Unified Modeling Language (UML) is a family of
graphical notations, that help in visualizing, specifying,
constructing and documenting software systems.
It can be used with all processes, throughout the software
development life cycle, and across different implementation
technologies

-5-

Object Oriented Modelling

INTERNAL

Evolution of UML
Rumbaugh - Analysis oriented (OMT*)
Booch - Design and Construction oriented
Jacobson - Use case oriented (OOSE **)
Unification:
The independent methods were evolving towards
one another.
Jim Rumbaugh, Grady Booch and Ivar Jacobson
joined Rational Software Corporation to unify their
methods.

* Object Modeling Technique

**Object Oriented Software Engineering

UML 2.0 notations will be used for Object Oriented Modeling during
ILP.

-6-

Object Oriented Modelling

INTERNAL

Model Views and UML Diagrams

Structural ViewImplementation View

Component

Class

User
User
View
view
Behavioral View

Use
Use case
Case

Sequence

Environment View
Deployment

-7-

Object Oriented Modelling

INTERNAL

Model Views
User View: Illustrates how the end user views the system
Structural View: Illustrates the static feature of a model that includes
classes, attributes, behaviours and relationship between the classes.
Behavioral View: Illustrates the interactions between the objects and how
the group of objects collaborate in some behaviour
Component View: illustrate the organizations and dependencies
among software components, including source code components, run time
components, or an executable component.
Deployment View: This view shows a systems physical layer, revealing
which piece of software run on what pieces of hardware.

-8-

Object Oriented Modelling

INTERNAL

Object Oriented Analysis

In object oriented approach, in the Analysis phase the emphasis is on
discovering and describing objects in the problem domain.
In OO Analysis, focus is on doing the right thing.
OO Analysis includes
1. Use Case Model:
Use Cases : Stories or scenarios of how people use the system
Use Case Diagram : Gives a high level view of how different users
interacts with the system (through use cases)

2. Domain Model:
A description of the domain from the perspective of objects. In this model we
identify the concepts, attributes and associations

-9-

Object Oriented Modelling

INTERNAL

Requirements Analysis
1. Identify the users and their goals

2.Develop Use Cases Model

(Use Cases & Use Case Diagram)

3. Develop Domain Model

(Conceptual Class Diagram)

- 10
-

Object Oriented Modelling

INTERNAL

Use Case Model : User View

Use Case Model : Use Cases + Use Case Diagram
It captures the functionality the system should provide from the users perspective
They do not specify how the system actually implements the system.
in essence it helps to systematically identify systems responsibilities in the user
requirements perspective

- 11
-

Object Oriented Modelling

INTERNAL

Case Study

get
your
hands
dirty
- 12
-

Object Oriented Modelling

INTERNAL

Reference Case Study - Requirement

ABC Bank Automation System
Problem Statement:
ABC bank plans to automate its current account related activities. A customer can open
a current account. There are two types of current accounts:-Cash Credit account and
Regular Current account. Cash credit account holders can avail overdraft facility. They can
withdraw 10% of their balance amount as overdraft. They cannot withdraw or avail an
overdraft if existing overdraft is not paid back. Only privileged customers can open a Cash
Credit account. For every 100 transactions made on a regular current account a fee of
Rs.100/- is deducted from the account balance. A customer should first provide his details to
register in the bank before opening an account. If required he can update his details later.
Clerk can view details of registered customers. The customer may have one or more
accounts in the bank. He can deposit or withdraw money from his account. He can also
close his account. The clerk generates a statement of the transactions performed on an
account to verify the account transactions.
Assumption : Customer interacts with the system through the clerk

- 13
-

Object Oriented Modelling

INTERNAL

Reference Case Study Identify Actors and their goals

Customer

1.Stake Holders ?

Bank

2.Actors ?
An Actor is a role that a user plays when invoking a
use case.
A single user can represent multiple actors
Actors need not be always human, they can
represent even external systems.

3.Goals of each actor ?

- 14
-

ABC

Clerk

Bank
Customer

ABC

Clerk

Goals of Clerk
Adding a new customer
Updating existing customer details
Viewing existing customer details
Opening a current account
Handling transactions such as
withdraw, deposit and overdraft for
a current account
Closing a current account
Generate Transaction
statement
Object
Oriented Modelling
INTERNAL

Use Cases

Define one use case for each user goal

Use case express a goal that system must achieve and/or that it must
produce

Use case is a textual description which formally specifies several

scenarios.

A Scenario is a sequence of steps describing an interaction between a

user and a system

A Use Case is a set of scenarios tied together by a common user goal

Use case has main success scenario and alternate scenarios (extensions)
/failure scenarios.

- 15
-

Object Oriented Modelling

INTERNAL

Writing Use Cases for each actor goal

Use Case UC1: Add Customer
Level: User goal
Scope: ABC Bank Automation System
Primary Actor: Clerk
Stakeholders and interests:
Customer: Wants to register with ABC bank, for availing various current account related activities provided by the bank.
Clerk: Wants the system to accurately record the details provided by the customer to register with the bank.
ABC Bank: Wants to make customer registration process fast and reliable,
Preconditions: none
Success Guarantee: Customer details given by the customer is recorded. Customer Id is generated.
Main Success Scenario:
1.
Customer arrives at ABC bank and provides details for registration.
2.
Clerk enters the details into the system
<number> <name>
3.
System validates the customer details.
4.
System Prompts for confirmation of registration.
Name should be the goal as a short active verb phrase>
5.
Clerk Confirms registration.

System generates a customer Id for the customer

<one of: User Goal, Sub function

The customer details are saved in the system

<what system is being considered black-box under design>

Clerk provides the customer Id to the customer.

Extensions:
3a. Invalid Customer Details
<a role name for the primary actor, or description>
System displays an error message.
System displays menu.
<what we expect is already the state of the world>
5a. Customer requests to stop registration.
Clerk cancels registration process.
<the state of the world upon successful
System displays menu
completion>
7a. System fails to save the customer details provided.
System displays an error message.
System displays menu.

Use Case Template

Title

Level
>
Scope
Stakeholders & their interests
Primary Actor
Preconditions:
Success Guarantee::

Main Success Scenario

Extension (s)

- 16
-

Object Oriented Modelling

INTERNAL

Use Case Diagram

UML Use case diagram shows the relationships among actors and use cases within a system.
A use case is represented as a ellipse
Use Cases and actors are connected using associations
Goals of Clerk

Adding a new customer

Updating existing customer details
Viewing existing customer details
Opening a current account
Handling transactions such as
withdraw, deposit and overdraft for
a current account
Closing a current account
Generate Transaction statement

Within the same system, use cases relate to each other using generalization, extension or inclusion,
Use Case Relations should be sparingly used.
Instead concentrate on the textual description of use case; that's where the real value of the technique lies.

- 17
-

Object Oriented Modelling

INTERNAL

Domain Model Based on User View

Domain Model
Scope,
goals,acto
rs,
features

Suggests
domain
concepts

Vision

Use Case Model

Explanation of
terms attributes

- 18
-

Glossary
Account:
Customer: ...

Object Oriented Modelling

INTERNAL

Domain Model

A domain model is a visual representation of conceptual classes in

a domain
Its a conceptual model & Its not a software model.

- 19
-

Object Oriented Modelling

INTERNAL

Discovering Objects for Domain model

Object Oriented methodology favors many different approaches.
Some of the methods are listed below:

List the basic responsibilities that the objects should share.

Assign responsibilities to the appropriate objects. Focus on
collaborations and responsibilities in the system.

Create a category list and identify objects in the domain, falling

under each category.

Single out nouns and verbs from the user view/problem

statement, and create corresponding classes and operations.

- 20
-

Object Oriented Modelling

INTERNAL

User View suggests domain concepts

Use Case UC1: Add Customer
Level: User goal
Scope: ABC Bank Automation System
Primary Actor: Clerk
Stakeholders and interests:
Customer: Wants to register with ABC bank, for availing various current account related activities provided by the bank.
Clerk: Wants the system to accurately record the details provided by the customer to register with the bank.
ABC Bank: Wants to make customer registration process fast and reliable.
Preconditions: none
Success Guarantee: Customer details given by the customer is recorded. Customer Id is generated.
Main Success Scenario:
1.
Customer arrives at the bank and provides details for registration.
Nouns and Noun Phrases Identified
2.
Clerk enters the details into the system
from UC1: Add Customer
3.
System validates the customer details.
4.
System Prompts for confirmation of registration.
Customer Details
5.
Clerk Confirms registration.
Customer

System generates a customer Id for the customer

Customer Id

Bank
The customer details are saved in the system
Clerk **

Clerk provides the customer Id to the customer.

System ***
Extensions:
Error Message
3a. Invalid Customer Details
System displays an error message.
ClassCandidates
Attribute Candidates
System displays menu.
5a. Customer requests to stop registration.
1. Customer Details
1.Customer
Clerk cancels registration process.
System displays menu
2.Bank
2. Customer Id
7a. System fails to save the customer details provided.
System displays an error message.
System displays menu.

*Note: Details of clerk is not required in this scenario, so clerk is not considered as a
class.
**Note: System represents the whole system, its not a candidate for a class.

- 21
-

Object Oriented Modelling

INTERNAL

Domain model - Evolves

Possible Multiplicity Values

Notation

Meaning

0..1

Zero or one

One only

0..*

Zero or more

Zero or more

1..*

One or more

Six only

0..4

Zero to Four

5..15

Five to Fifteen

Domain Level Class Diagram based on analysis of UC1 (Reference Case Study)

- 22
-

Object Oriented Modelling

INTERNAL

Domain model - Evolves

Domain Level Class Diagram based on analysis of UC1 & UC4 (Reference Case Study)

- 23
-

Object Oriented Modelling

INTERNAL

Analysis Patterns

overDraftLimit is an attribute independent of the

CashCreditAccount instance

You may have to know the overdraft Limit for cash credit
accounts even when no cash credit account exist.

Over draft limit is unnecessarily repeated for all the

instances of cash credit account.

Solution- Move the overDraftLimit to another class and associate it with CashCreditAccount
Move the overdraftLimit which describes any cashCredit account to a
class called cashCreditAccountDescription.
Now you can get over draft limit of any cash credit a/c even when
no cash credit a/c is opened in the system.
The redundancy of this data is avoided
This pattern is named as Item-Descriptor Pattern.

- 24
-

Object Oriented Modelling

INTERNAL

Domain Model Evolves

1
0*

holds

holds

0*

Domain Level Class Diagram based on analysis of UC1 & UC4 (Reference Case Study)

- 25
-

Object Oriented Modelling

INTERNAL

References

Larman Craig, Applying UML and Patterns Third Edition, Pearson Education
Fowler Martin, UML Distilled Third Edition, Addison-Wesley

- 26
-

Object Oriented Modelling

INTERNAL