1.

1 Classes and Objects

• A problem can be divided into subjects.

• Subjects are used as logical divisions for development of
large systems
• Each subject is generally considered as a problem domain

Subjects eg. Airport Management System

Radar control Baggage Handling Passenger

Processing

9
1.1 Classes and Objects

• We understand the real world through ideas that are

organized into recognizable patterns and concepts.
• Concepts can be divided into following types :
Tangible - book
Roles - doctor
Relational - marriage
Intangible - time, quality
Judgmental - good pay
Event - Purchase, loan

10
 1.1 Classes and Objects
System concepts for object modeling

• In the real-world interaction of these concepts allow

complex operations to be performed.
Library System
Core Concepts - Borrowing, Returning of books, Book registration,
Member registration (Use Cases)
Concepts - Member, Copy, Book (Classes)

* He knows certain facts - eg. Name

address etc.
* Also perform certain activities
Instance of a
Member Concept

11
1.1 Classes and Objects

• Classes
• Represent the concepts that are to be modeled.
• Initial Step in OOA is the identification of Actors, Use
cases, classes (Problem Domain).
• Library System: identify Use Cases-Borrowing books,
returning of books , registration of Books in a library
system
• Classify type of expected users (Actors) of the system
( Librarian, Member etc.)
• Classes in a library system - Book, Copy,
Member etc. (problem Domain Classes)

12
1.1 Classes and Objects

• Objects (Instances of Classes)

• Something that is or is capable of being seen, touched,
or otherwise sensed and about which users store data
and associate behavior
• Types of objects
• Person: e.g. employee, customer, instructor, student
• Place: e.g. warehouse, building, room, office
• Thing: e.g. product, vehicle, computer, videotape
• Event: e.g. an order, payment, invoice, application
• Sensual: e.g. phone call, meeting

13
1.1 Classes and Objects

• Attributes and Services

by examining the descriptions/documents given by the
users, event type concepts (Scenarios) can be identified.
• Attributes: The data that represents characteristics of
interest about an object.
• Services: The set of things that an object can do and
that correspond to functions that act on the object’s
data or attributes.

14
1.1 Classes and Objects

• Attributes and Services

Borrowing of Books
eg. Library System
Main Actions Return of Books
Reservation of Books
Each Action Involves with Pool of Objects
(Instance of a Class)
Each Class offers
* Various Services
* Contains information reflected as Attributes

15
 1.1 Classes and Objects
Objects
eg.
- A Toshiba
Washing Machine
- A Panasonic
Washing Machine
e.g. Class WashingMachine
Attributes brandName
modelName
serialNumber
capacity
addClothes()
Services addDetergent()
removeClothes()
1.1 Classes and Objects

• A principle used to derive attributes and services

* What the specific concept knows?

- attributes
* What are the responsibilities of a class?
- services
Services operate when they are involved through message
connections.
Student knows how to draw a rectangle,
but he will not draw unless somebody ask
him to draw
Another example: TV and Remote

18
1.2 Methods and Messages

Message – Communication that occurs when one object

invokes another object’s method (behavior) to request
information or some action

19
1.2 Methods and Messages

• Message Passing
• In a system, objects work together.
• They do this by sending messages to one another.
• One object sends another a message to perform an operation.
• The receiving object performs that operation.
eg. A TV and a Remote
1.2 Methods and Messages

• Message Passing
• When you want to watch a different channel,
• You click the appropriate button on the remote,
• Remote object sends a different message change channel to the TV
object.
• The remote can also communicate with the TV via other messages
for changing the volume, muting the volume etc..
 1.2 Encapsulation and Information Hiding

• Data Abstraction
➢ A mechanism to reduce and filter out details so that one
can focus on a few concepts at a time. Focus on Essentials
➢ Filter out an object’s properties and operations until just
the ones you need are left.
➢ Ignore the irrelevant. Ignore the unimportant.
eg. Book – Bookshop you bought -Not important
• Abstraction, information hiding, and encapsulation are very
different, but highly-related, concepts.
• One could argue that abstraction is a technique that help us identify
which specific information should be visible, and which information
should be hidden.
• Encapsulation is then the technique for packaging the information
in such a way as to hide what should be hidden and make visible
what is intended to be visible.
1.3 Encapsulation and Information Hiding

• Encapsulation
• Packaging of several items together into one unit (both
attributes and behavior of the object), Also protects
the contents.
• The only way to access or change an object’s attribute
is through that object’s specific behavior.
• Objects encapsulates what they do.
• That is, they hide the inner workings of Eg. Class BankAcount
their operations {
• from the outside world Private: Balance
………
• and from other objects Withdraw(int)
Deposit(int)
}
27
1.3 Encapsulation and Information Hiding

When an object carries out its operations, those operations

are hidden.
E.g. When most people watch a television show,
- they usually don’t know or care about the complex
electronics that sit behind the TV screen
- or the operations that are happening.
The TV hides
its operations
from the
person
watching it.

28
1.3 Encapsulation and Information Hiding
• Information Hiding
• The principle of information hiding suggests that only
the information required to use a software module be
published to the user of the module.
• Typically, this implies that the information required to
be passed to the module and the information returned
from the module are published.
• It is not relevant to know exactly how the module
implements the required functionality
• We really do not care how the object performs its
functions, as long as the functions occur.
• In object-oriented systems, combining encapsulation
with the information-hiding principle supports treating
objects as black boxes.(a black box is a device or object
which can be viewed in terms of its inputs and outputs
without any knowledge of its internal workings.)
1.3 Encapsulation and Information Hiding

Why is this important?

• In the software world, encapsulation helps cut down on
the potential for bad things to happen.
• In a system that consists of objects, the object depends
on each other in various ways.
• If one of them happen to malfunction, software
engineers must change it in some way.
• Hiding its operations from other objects means it
probably won’t be necessary to change those other
objects.

31
1.3 Encapsulation and Information Hiding

• Turning from software to reality, you see the importance

of encapsulation.

eg. Your computer monitor, hides its operations from your

computers CPU.
When something goes wrong with your monitor, you
either fix or replace it.
You probably won’t have to fix or replace the CPU
along with it.

32
1.3 Encapsulation and Information Hiding

• An object hides what it does from other objects and

from outside world
• But an object does have to present a “face“ to the
outside world, so you can initiate those operations.
eg. A TV, has a set of buttons either on
the TV or on a remote.
The TV’s buttons are called interfaces.

33
1.3 Encapsulation and Information Hiding

Cannot access (private)

- Private : cannot access from outside objects

+ Public : can access from outside objects

34
1.3 Encapsulation and Information Hiding

• Encapsulation is done through the definition of region of

access.
• Region of access defines the accessibility of the services
or attributes in a class.
•In C++ (OO programming Language)
• 3 types of access regions: private, public, protected
•In Java
• Access modifiers: default, public, private, protected,
• Static modifier, final modifier, synchronized modifier, native
modifier

35
1.4 Inheritance

• The concept wherein methods and/or attributes defined in

a class can be inherited or reused by another class.
• The data modeling literature suggests using inheritance to
identify higher-level, or more general, classes of objects.
• Common sets of attributes and methods can be organized
into super-classes.
• Typically, classes are arranged in a hierarchy whereby the
super-classes, or general classes, are at the top and the
subclasses, or specific (specialized) classes, are at the
bottom.
e.g. some individuals in the room might be classified as STUDENTS
and TEACHERS. Thus, STUDENT and TEACHER classes are members of
the class PERSON

36
1.4 Inheritance

37
 1.4 Inheritance

• Generalization / Specialization
• A technique wherein the attributes and behaviors that
are common to several types of classes are grouped /
abstracted into their own class called a supertype.
• The attributes and methods of the supertype class are
then inherited by those classes (subtype)
• Sometimes abbreviated as gen/spec.
• Generalization is the term that we use to denote abstraction
of common properties into a base class. When we
implement Generalization in a programming language, it is
called Inheritance.

38
 1.4 Inheritance

Generalization
Specialization
Student
GPA firstName
Classification lastName
Person
birthdate
firstName enroll gender
lastName displayGPA walk
birthdate Inheritable
Attributes
+ jump
gender Teacher talk
And
walk sleep
behavior rank
jump
talk
sleep lecture

© e-Learning Centre, UCSC 39

1.4 Inheritance
An Example of UML (Unified Modeling Language) Representation of
Generalization /Specialization

Specialization
Generalization

© e-Learning Centre, UCSC 40

1.4 Inheritance

• Generalization / Specialization

Vehicle
Person

Bus Car Truck

Student Teacher

* Specialized classes inherit from the parent class

41
1.5 Polymorphism and Dynamic Binding

• Polymorphism is the concept that different objects can

respond to the same message in different ways.
• It allows different forms of the same service to be
defined.
• Sometimes an operation has the same name in different
classes.
eg. You can open a door, you can open a window, or
a bank account. In each case, you are performing
a different operation.

42
1.5 Polymorphism and Dynamic Binding
• We can simply send a message to an object, and that
object will be responsible for interpreting the message
appropriately.
• For example, if an artist sent the message ‘draw yourself’
to a square object, a circle object, and a triangle object,
the results would be very different, even though the
message is the same.
 1.5 Polymorphism and Dynamic Binding

In some programming languages,

function overloading or method
overloading is the ability to create
multiple functions of the same name
with different implementations.

5
 1.5 Polymorphism and Dynamic Binding

Polymorphism
Overriding – a e
techniquewhereby a
subclass (subtype) uses
an attribute or
behavior ofits own
instead of an attribute
or behavior inherited
from the class
(supertype).
 1.5 Polymorphism and Dynamic Binding
• Polymorphism is made possible through dynamic binding. Dynamic,
or late, binding is a technique that delays typing the object until run-
time. The specific method that is actually called is not chosen by the
object-oriented system until the system is running.
• This is in contrast to static binding. In a statically bound system, the
type of object is determined at compile-time. Therefore, the
developer has to choose which method should be called instead of
allowing the system to do it.
• This is why most traditional programming languages have
complicated decision logic based on the different types of objects in
a system.
• For example, in a traditional programming language, instead of
sending the message Draw yourself to the different types of
graphical objects we would have to write decision logic using a case
statement or a set of if statements to determine what kind of
graphical object we wanted to draw, and we would have to name
each draw function differently
(e.g., draw square, draw circle, or draw triangle). Th is obviously
makes the system much more complicated and difficult to
understand.
50
1.6 Introduction to Unified Modeling Language (UML)
• UML, A visual modeling language enables system
builders to create blueprints that capture their
visions in a standard, easy-to-understand way
• Provides a mechanism to effectively share and
communicate these visions with others (Technical
or Nontechnical)

52
1.6 Introduction to Unified Modeling Language
(UML)

• It most directly unifies the methods of

• Booch,
• Rumbaugh (OMT) and
• Jacobson
as well as the best ideas from several other methodologies.

53
1.6 Introduction to Unified Modeling Language
(UML)

UML Inputs

Booch Rumbaugh Jacobson

Mayer
Odell Pre and post
classification conditions
UML
Shlaer-Mellor Harel
Object life cycles State charts

Gamma et al Wirfs-Brook
Frameworks, Responsibilities
Embly
Patterns, Singleton Fusion
notes Operation descriptions
classes
Message numbering
54
1.6 Introduction to Unified Modeling Language
(UML)

• The UML does not prescribe a method

for developing systems—only a
notation that is now widely accepted as
a standard for object modeling.

55
1.6 Introduction to Unified Modeling Language (UML)

UML History
• The first public draft version – (version 0.8) – Oct 1995
• Feedback from public and Ivor Jacobson’s inputs included – (ver. 0.9 Jul 1996,
ver. 0.91 Oct 1996)
• Ver 1.0/1.1 was presented to OMG group for standardization in July/Sep 1997.
• Nov 1997 – UML adopted as the standard modelling language by OMG
• Ver 1.2 - June 1998
• Ver 1.3 – Dec 1998
• Ver 1.4 – 2000
• Ver 2.0 – 2003
• Ver 2.1 – 2007
• Ver 2.2 - 2009
• Ver 2.3 – 2010,
• Ver 2.4 –Jan 2011
• Ver 2.5 June 2015

56
UML Components and Capabilities

• The UML consists of several graphical elements that

combine to form diagrams.
• Because it is a language, the UML has rules for combining
these elements.
• Lets look at the diagrams before looking at the elements
and rules.
• The purpose of the diagrams is to present multiple views
(model) of a system.
• UML 2.5 include 14 different diagrams.

57
• UML diagrams are divided into two categories.
- Structure Diagrams:
Seven diagram types represent structural
information,
-Behavior Diagrams:
other seven represent general types of behavior.

58
UML Diagrams

59
 Context Models

• Context models are used to illustrate the operational

context of a system
• they show what lies outside the system boundaries.
• Use Case Diagram can be used to represent a Context model
for a system.
• There is no single diagram in UML that would map to the
definition

60
Context Models

61
• UML include many different diagrams.
Class Diagrams:
• Shows set of classes, interfaces, and collaborations and their
relationships.
• Most common diagram found in modelling object-oriented
system.
• Address the static view of a system.
class: a category or group of things that have the same attributes
and the same behaviors.

62
Class Diagram (UML 1.*)
e.g. School =Faculty

63
Object Diagrams :
• Models actual object instances with current attribute
values.
• Shows a set of objects and their relationships.
• Provides a snap shot of the system’s objects at one point
in time.

64
Object Diagram
e.g. Is being attacked by
thisWhiteQueen:Queen thisBlackKnight:Knight

Is strategically positioned against

thisWhitePawn:Pawn

65
Use Case Diagrams :
• Shows a set of use cases and actors and their
relationships.
• A tried-and-true technique for gathering
information.

• Graphically describes who will use the

system and in what ways the user expects to
interact with the system.

66
 Use Case Diagram
Order Processing

<<extend>>

<<Communicate>> Request Catalogue

Place Order
<<Include>>

Arrange Payment
Generalization Generalization
Order
Clerk
Arrange Credit
Pay Cash

67
State Diagrams :

• Shows a state machine consisting of states,

transitions, events and activities.
• Models how events can change the state of an
object over its lifetime,
• show both the various states of an object and
the transactions between those states.

68
State Diagrams
e.g. Course Registration

Add student[ count < 10] ]]

Add Student /
Initialization Set count =0 00
do: Initialize course Openn
entry: Register student
exit: Increment count

Cancel

Cancel [ count = 10] ]

Cancel

do: Notify registered students Closed

Cancel do: Finalize course

69
Sequence Diagrams:
• An Interaction diagram that emphasizes the time-
ordering of messages.
• Graphically depicts how objects interact with each other
via messages in the execution of a use case or operation.
• Illustrates how messages are sent and received between
objects and in what sequence.

70
Sequence Diagrams
e.g. Lending Books in a Library
a borrowing A borrower : A borrowed copy A copy : copy A book : book
: librarian form borrower : borrowedCopy
Enter Borrower IdcheckBorrowerExist( )

process
checkOverdue( ) getOverdueDetails( )

checkOverlimit( )

Enter copy id checkBorrowable( )

getBookDetails( )

confirm borrowing informBorrower( )

informBorrowedCopy( )

71
Activity Diagram :

• A diagram that shows the flow from activity to activity

within a system.
• Address the dynamic view of a system.

72
Activity Diagram

73
Communication Diagrams :
• An interaction diagram that emphasizes the structural
organization of the objects that send and receive
messages.
• Shows the interaction of objects via messages.
• Also known as collaboration diagram in UML 1.X.

74
Communication Diagrams : e.g. Lending of Books
1: Enter borrower id
2: checkBorrowerExist( )
3: process
4: checkOverdue( )
7: Enter copy id
6: checkOverlimit( )
11: confirm borrowing
borrowing 12: informBorrower( )
form

a borrower :
borrower

: l ibrarian
5: getOverdueDetails( )
13: informBorrowedCopy( )

8: checkCopyExist( )
10: checkBorrowable( )
a borrowed copy : a book :
borrowedCopy book

9: getBookDetai ls( )

a copy :
copy

75
Component Diagram :
• Shows the organizations and dependencies
among a set of components.

• Address the static implementation view of a

system.

76
Component Diagrams in UML 1.* and 2.*

77
Deployment Diagram
• Shows the configuration of run time processing nodes
and the components live on them.
• Shows the physical architecture of a computer-based
system.
• It can show computers, their connections with one
another, and show the software that sits on each
machine.

78
 Deployment Diagram

Registration Database
Server

LecturerOptions.exe

Main Library
Building

StudentOptions.exe StudentOptions.exe

79
Composite Structure Diagrams:
• Decomposes the internal structure of a class.
• New in UML 2.0.

• A diagram which shows something about the

class’s internal structure.
e.g.
PERSON

Mind Body

80
Interaction Overview Diagrams:
• New in UML 2.0.

• Replace some of the activities in the activity diagram

with sequence / communication diagrams (or a
combination of the two)

• Shows how objects interact within each activity of a use

case.

81
Interaction Overview Diagram
e.g.
:User :LibraryDatabase
find()

Find book goToLocation()

:User :Librarian
Borrow book processCheckOutRequest()
takeBook()

:User :Guard
Leave library
verifyCheckOut()

exitLibrary()

82
Timing Diagrams:

• New in UML 2.0.

• A diagram which shows how long an object is in a

particular state.

• Especially useful when designing

embeddedsoftware for devices.

83
 Timing Diagram : e.g.
:WashingMachine
Spinning

Rinsing

Washing

Soaking

0 5 10 15 20 25 30 35

84
Package Diagrams:

• A diagram which combines a number of classes or

components into a subsystem

85
Package Diagram e.g.

86
Package in a Package Diagram

87
Profile Diagram
Describes lightweight extension mechanism to the UML
Profiles allow adaptation of the UML meta-model for
different:
• platforms (such as J2EE or .NET), or
• domains (such as real-time or business process modeling).

88
Profile Diagram eg.

89