Chapter 6 – OO Design with UML

Object-orientedconcepts
Unified Modelling Language (UML)
Structure View
Behavioural View
User’s view
Implementation View
Environmental View
OOAD Overview
 Object-Oriented Concepts
Object-oriented(OO) design techniques are
extremely popular:

◦ Inception in early 1980’s and nearing maturity.

◦ Widespread acceptance in industry and
academics.
◦ Unified Modelling Language (UML) already
an ISO standard.
 Objects
 A system is designed as a set of interacting objects:
 Often, real-world entities:
Examples: an employee, a book etc.
 Can be conceptual objects also:
Controller, manager, etc.
 Consists of data (attributes) and functions (metho
that operate on data.
 Hides organization of internal information (Data

abstraction).
 Model of an Object
m8 m7
mi are methods
of the object

m1 m6
Data
m2 m5

Object

m3 m4
 Class
 Instances are objects
 Template for object creation
 Considered as abstract data type (ADT)
 Examples: Employees, Books, etc.
 Sometimes not intended to produce instances:
 Abstract classes
 Methods and Messages
 Operations supported by an object:
 Means for manipulating the data of other
objects.
 Invoked by sending a message (method
call).
 Examples:
calculate_salary, issue-book,
member_details, etc.
 Encapsulation
• Objects communicate with outside world
through messages:
― Data of objects encapsulated within its methods.
― Data accessible only through methods.
Encapsulation

m4

m3
m5

m2 Data
m6

m1

Methods

Concept of encapsulation
 Polymorphism

 Denotes poly (many) morphism (forms).

 Under different situations:
 Same message to the same object can
result in different actions:
Static binding
Dynamic binding
 Dynamic Binding
A method call to an object of an class
◦ Would result in the invocation of the method of an appropriate
object of the derived class.

Following principles are involved:

◦ Inheritance hierarchy
◦ Method overriding

Exact method to be bound on a method call:

◦ Not possible to determine at compile time.
◦ Dynamically decided at runtime.
 Dynamic Binding
Cont …

 Exact method to be bound on a method

call:
 Not possible to determine at compile time.
 Dynamically decided at runtime.
 Advantages of OO Development
 Code and design reuse
 Increased productivity
 Ease of testing (?) and maintenance
 Better understand ability
 Elegant design:
 Loosely coupled, highly cohesive objects:
 Essential for solving large problems.
 Initially incurs higher costs
 After completion of some projects reduction in cost become
possible
 Using well-established OO methodology and environment:
 Projects can be managed with 20% to 50% of traditional cost of
development.
Object Modelling Using UML

 UML is a modelling language

 Nota system design or development
methodology
 Usedto document object-oriented
analysis and design results.
 Independent
of any specific design
methodology.
 UML Origin
 OOD in late 1980s and early 1990s:
 Different software development houses were
using different notations.
 Methodologies were tied to notations.

 UML developed in early 1990s to:

 Standardize the large number of object-
oriented modelling notations
 UML Lineology

 Based Principally on:

 OMT [Rumbaugh 1991]
 Booch’s methodology[Booch 1991]
 OOSE [Jacobson 1992]
 Odell’s methodology[Odell 1992]
 Shlaer and Mellor [Shlaer 1992]
Different Object Modelling
Techniques in UML

OMT

UML
Booch’s
OOSE Methodology
 UML as A Standard
 Adopted by Object Management Group (OMG
in 1997
 OMG is an association of industries
 Promotes consensus notations and techniques
 Used outside software development
 Example car manufacturing
 Why are UML Models Required?

 A model is an abstraction mechanism:

 Capture only important aspects and ignores the rest.
 Different models result when different aspects are
ignored.
 An effective mechanism to handle complexity.
 UML is a graphical modelling tool
 Easy to understand and construct
Modeling a House
 UML Diagrams
 Nine diagrams are used to capture
different views of a system.
 Views:
 Providedifferent perspectives of a
software system.
 Diagrams
can be refined to get the actual
implementation of a system.
 UML Model Views
 Views of a system:
 User’s view
 Structural view
 Behavioral view
 Implementation view
 Environmental view
 UML Diagrams

Structural View Behavioural View

- Class Diagram - Sequence Diagram
- Object Diagram - Collaboration Diagram
- State-chart Diagram
User’s View - Activity Diagram
- Use Case
Diagram

Implementation View Environmental View

- Component Diagram - Deployment Diagram

Diagrams and views in UML

 Are All Views Required for Developing
A Typical System?

 No
 Use case diagram, class diagram and one of the
interaction diagram for a simple system
 State chart diagram required to be developed when a
class state changes
 Deployment diagram in case of large number of
hardware components used to develop the system
Object responsibility
Objects have three responsibilities

What they know about themselves

◦ Attributes

What they do
◦ Operations / Functions

What they know about other objects

◦ Relationships
Defining Class
A CLASS is a template (specification, blueprint)
for a collection of objects that share a common
set of attributes and operations.

HealthClubMember
Class attributes
operations

Objects
 • Relationships
A RELATIONSHIP is what a class or an object knows
about another class or object.

 Generalization (Class-to-Class) (Superclass/Subclass)

• Inheritance
• Ex: Person - FacultyPerson, StudentPerson, Staff...

 [Object] Associations
• FacultyInformation - CourseInformation
• StudentInformation – CourseInformation

 [Object] Aggregations & Composition (Whole-Part)

• Assembly - Parts
• Group - Members
• Container - Contents
 • Relationships
Exist to:
1) show relationships 2) enforce integrity 3) help produce results

In this example:
• Removal of a University
Course should also remove
UniversityCourse Students that are in the
Course but not Student
Information.

StudentInformation • Removal of a Student

should also remove the
Courses that the Student is
in but not the University
Course.
StudentInCourse
• Removal of a Student in a
Course should not affect
either University Course or
Student Information.
UML Class Diagram Notations
Class

{
Member
memberNumber
firstName Expanded view of a
lastName
Class into its three
attributes telephone
address sections:
city
etc... Top: Class Name

{
checkOutVideo Middle: attributes
operations checkInVideo Bottom: operations
buyItem
etc...
Class Diagram Relationship
Class
◦ Generalization

Object
◦ Association
◦ Aggregation
◦ Composition
 UML Class Diagram notation
Class
Generalization
Relationship

Object Object
Aggregation Composition
Object Association Association Association

n n 1..* 1

0..* 0..*

Will always be “1”

Generalization (super class - subclass)
A Generalization follows a “is a” or “is a kind of” relationship from a
specialization class to the generalization class.

Common attributes, operations and relationships are located in the

generalization class and are inherited by the specialization classes

Unique attributes, operations and relationships are located in the

specialization classes.

Inherited attributes and operations may be overridden or enhanced in the

specialization class depending on programming language support.

Multiple inheritance is allowed in the UML but can complicate the class
model’s understanding and implementation (e.g., C++ supports but Java
and Smalltalk do not).
Generalization Example
<<abstract>>
Role
attributes
operations

Faculty Student Staff

attributes attributes attributes

operations operations operations

Note: <<abstract>> = no objects

Poor Generalization Example

Person
attributes
operations

Arm Leg Head

attributes attributes attributes

operations operations operations

UML Generalization Notation

Supertype

discriminator

Subtype 1 Subtype 2
Generalization – Multiple Classification

Discriminator
Doctor

role
<<abstract>>
Nurse
Person

patient
Lab Attend

Patient
#2
#1
 Associations
 A semantic relationship between two or more classes
that specifies connections among their instances.
 A structural relationship, specifying that objects of one
class are connected to objects of a second class.
 An association between two classes indicates that
objects at one end of an association “recognize”
objects at the other end and may send messages to
them.

Example: “An Employee works for a Company”

Employee Department Company

 Contd..
Role
name
Association
name
instructor
Staff Member Student
1..* instructs *
Navigable
Multiplicity (uni-directional)
association *
Courses

Association Name Multiplicity Role Name

Contd..
Association name
◦ The name is represented as a label placed midway
along the association line

Multiplicity
◦ The number of instances of the class, next to which
the multiplicity expression appears, that are
referenced by a single instance of the class that is at
the other end of the association path.
◦ Indicates whether or not an association is mandatory.
◦ Provides a lower and upper bound on the number of
instances.
Multiplicity Indicator

Exactly one 1

Zero or more 0..*

One or more 1..*

Zero or one (optional association) 0..1

Specified range 2..4

Aggregation
A special form of association that models
a whole-part relationship between an
aggregate (the whole) and its parts.
◦ Models a “has - a” relationship.

2..* Door
1..*
Car House

Whole Part
Test for Aggregation
◦ Is the phrase “has - a” fit in the relationship
 A car “has a “ door.

◦ Is the phrase “part of” used to describe the

relationship?
 A door is “part of” a car

◦ Are some operations on the whole automatically

applied to its parts?
 Move the car, move the door.

◦ Are some attribute values propagated from the whole

to all or some of its parts?
 The car is blue, therefore the door is blue.
Composition
A strong form of aggregation
◦ The whole is the sole owner of its part.
◦ The life time of the part is dependent upon
the whole.
◦ The composite must manage the creation
and destruction of its parts.

1 *
Order Item
Aggregation vs. Composition
 Composition:
◦ Composite and components have the same
life.
Aggregation:
◦ Lifelines are different.
Consider an order object:
◦ Aggregation: If order items can be changed
or deleted after placing the order.
◦ Composition: Otherwise.
Case Study - Asignment
The police department has many people working under
various wings. A traffic police is also an employee of the
police department. A system needs to be developed for
recording the details of the violations. If a traffic police
catches an offender he has to file a report with the date of
occurrence of violation.

The system analyst has identified the following classes –

police, traffic police, traffic report, offender and violation
details.
Help him to draw the class diagram for the above.
Please denote the multiplicity between the association too.
Assignment - Solution

TrafficReport Offender
TrafficPoliceman 1 issues * id : long 1..* 1 name : String
description : String id : long
occuredAt : Date

reports of
1..*
Policeman
id : long Violation
name : String id : long
rank : int description : String
<<abstract>>
Use Case Diagram
User’s view of the system

Use case diagrams are used to visualize,

specify, construct, and document the
(intended) behavior of the system, during
requirements capture and analysis.

Use case diagrams contain use cases,

actors, and their relationships.
Use Cases
Different ways in which a system can be
used by the users
Corresponds to the high-level requirements
Represents transaction between the user and
the system
Defines external behaviour without
revealing internal structure of system
Set of related scenarios tied together by a
common goal.
Representation of Use Case
◦ Represented by use case diagram
◦ A use case is represented by an ellipse
◦ System boundary is represented by a rectangle
◦ Users are represented by stick person icons
(actor)
◦ Communication relationship between actor
and use case by a line
◦ External system by a stereotype i.e
<< >>
Example

Play Move

Player

Use case model

Use Case - Factoring
Two main reasons for factoring:
◦ Complex use cases need to be factored into
simpler use cases
◦ To represent common behaviour across
different use cases

Three ways of factoring:

◦ Generalization
◦ Includes
◦ Extends
Generalization
 Use cases that are specialized versions of other use
cases
 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.

Generalization - Example
 registration

 BCA  MCA
 registration  registration
Includes
 Use cases that are included as parts of other use
cases. Enable to factor common behavior.
 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. It only
occurs as a part of some larger base that includes it.
 Enables to avoid describing the same flow of events
several times by putting the common behavior in a
use case of its own
Includes - Example

Issue Hall
Ticket <<include>>
verifying
student id

View SE <<include>>
Marks
Extends
Use cases that extend the behavior of other
core use cases.

The base use case implicitly incorporates the

behavior of another use case at certain points
called extension points.

The base use case may stand alone, but under

certain conditions its behavior may be
extended by the behavior of another use case.
Extends - Example

Process <<extend>> New

Order customer
check
Use Case Packaging

Accounts

Print
Query balance
Balance sheet

Receive Make
grant payments
Example – Use Case

place
place <<extend>> conference
phone call
call
cellular
network receive
phone call

user
Interaction Diagram

 Models how groups of objects collaborate to

realize some behaviour
 Typically each interaction diagram realizes
behaviour of a single use case
Sequence diagram is an example of
interaction diagram
Sequence Diagram
Shows interaction among objects as a two-
dimensional chart

Objects are shown as boxes at top

Ifobject created during execution then shown at

appropriate place

Objects existence are shown as dashed lines

(lifeline)

Objects activeness, shown as a rectangle on

lifeline
Contd..
Messages are shown as arrows
Each message labelled with corresponding
message name
Each message can be labelled with some
control information
Two types of control information
◦ condition ([])
◦ iteration (*)
 Elements of a Sequence Diagram

: Customer : Order : Payment : Product : Supplier

object place an order

process

lifetime
Object validate

activeness if ( payment ok )
if ( not in stock )
deliver
back order

get address

mail to address

message
 Example - Sequence Diagram
:Library
:Library
:Library Book :Library
Book :Book
Boundary Renewal Member
Register
Controller

renewBook find MemberBorrowing

displayBorrowing
selectBooks bookSelected
* find
[reserved]
[reserved] apology
update
apology

confirm

confirm
updateMemberBorrowing

Sequence Diagram for the renew book use case

Case Study - XYZ Bazaar
For the XYZ Bazaar application, design
the use case diagram and the various
sequence diagram
XYZ –Bazaar Use Case

register
Customer customer

register
sales

Sales Clerk
select
winners

Supermarket
Prize scheme
Manager
XYZ Bazaar – Sequence Diagram
Step 1 – Identify the various sequences from
the user case diagram

Step 2 – Identify the main classes

Step 3 – Identify the boundary and controller

classes

Step 4 – Draw the sequence diagram for all

Contd..
The various sequence diagram that can be
drawn:

◦ Registration of customer
◦ Registration of sales
◦ Selection of Prize winners
Contd..
Customer Record
Registration of customer
Customer Info
Sales Record
Sales Info Registration of sales

Sales Info Customer Info

1 1

* *
Sales Records Customer Record
Contd..
Boundary and Controller Classes

◦ RegisterCustomerBoundary
◦ RegisterCustomerController
◦ RegisterSalesBoundary
◦ RegisterSalesController
◦ SelectWinnerBoundary
◦ SelectWinnerController
 Sequence Diagram – Register Customer

:RegisterCustomer :RegisterCustomer :Customer :Customer

Boundary Controller Info Record

register
register
checkDuplicate
*match

[duplicate]

showError
generateCIN

create
register :Customer
Record
displayCIN
 Sequence diagram – Register Sales

:Register :Register
:Sales
Sales Sales
Info
Boundary Controller

RegisterSales registerSales
registerSales

create :Sales
Record

confirm
confirm
 Sequence diagram – Select Winner

:SelectWinner :SelectWinner :Sales :Sales :Customer :Customer

Boundary Controller Info Record Info Record

SelectWinners
SelectWinners
*computeSales

*browse

[for each winner]

find WinnerDetails [for each winner]
announces
*browse