The document discusses key concepts in object-oriented analysis and design (OOAD). It describes how OOAD focuses on modeling a system using objects that encapsulate both data and behaviors. It defines objects and classes, and how classes act as templates for creating multiple object instances that share attributes and behaviors. The document also covers inheritance, polymorphism, encapsulation, aggregation, and other fundamental OO concepts.

1. Object Oriented Analysis &
1
Design (OOAD)

2. 2
OOAD
• It focuses on objects where system is broken
down in terms of the objects that exist within it.
• Functions (behaviour) and data (state) relating
to a single object are self-contained or
encapsulated in one place.

3. 3
Objects
• Object is an abstraction of something in a
problem domain, reflecting the capabilities
of the system to keep information about it,
interact with it, or both.
• Objects are entities in a software system
which represent instances of real-world and
system entities

4. 4
Objects
Object Identity Behaviors State
An employee “Mr. John” Join(),
Retire()
Joined,
Retired.
A book “Book with title
Object Oriented
Analysis Design”
AddExemplar, Rent,
available,
reserved
A sale “Sale no 0015,
15/12/98”
SendInvoiced(),
Cancel().
Invoiced,
cancelled.

5. 5
Object Class
• Class is a description of a set of objects that
share the same attributes, operations,
methods, relationship and semantics.
• Object classes are templates for objects.
They may be used to create objects.
• An object represents a particular instance of
a class.

6. 6
Term of objects
• Attribute: data items that define object.
• Operation: function in a class that combine
to form behavior of class.
• Methods: the actual implementation of
procedure (the body of code that is executed
in response to a request from other objects
in the system).

7. Employee object & class
7
Class Object
Employee
name: string
address: string
dateOfBirth: Date
employeeNo: integer
socialSecurityNo: string
department: Dept
manager: Employee
salary: integer
status: {current, left, retired}
taxCode: integer
. . .
join ()
leave ()
retire ()
changeDetails ()
Employee16
name: John
address: M Street No.23
dateOfBirth: 02/10/65
employeeNo: 324
socialecurityNo:E342545
department: Sale
manager: Employee1
salary: 2340
stauts:current
taxCode: 3432
….
Eployee16.join(02/05/1997)
Eployee16.retire(03/08/2005)
Eployee16.changeDetail(“X
Street No. 12”)

8. Encapsulation and Data Hiding
• Packaging related data and operations
together is called encapsulation.
• Data hiding: hides the internal data from
external by methods (interface).
8

9. public methods + printNumCustomer( ): void
9
Encapsulation
 private attributes and methods are encapsulated within the
class, they cannot be seen by clients of the class
 public methods define the interface that the class provides
to its clients
Customer
- numCustomers = 0
- MIN_BUDGET = 200
- name: String
- address: String
- budget: int
+ placeOrder( ): void
private attributes
Customer class

10. Object communication
• Objects communicate with each other by sending
messages
– a message is a method call from a message-sending
object to a message-receiving object
– a message consists of
• an object reference which indicates the message receiver
• a method name (corresponding to a method of the receiver),
and
• parameters (corresponding to the arguments of the calling
method)
– a message-receiving object is a server to a message-sending
object, and the message-sending object is a
10
client of the server

11. 11
Message Passing
name = “Alex”
address =
“1 Robinson Rd”
budget = 2000
placeOrder( ): void
name = “Lawrence”
employeeNo =15
commission = 200
takeOrder( ): int
message
takeOrder(“sofa”, name,
address, “120799”)
199
return value alex lawrence
message
lawrence.takeOrder(“sofa”, “1 Robinson Rd”, “120799”)
object reference method name parameters

12. SalesPerson
12
Message Passing
Customer
- numCustomers = 0
- MIN_BUDGET = 200
- name: String
- address: String
- budget: int
+ printNumCustomer( ): void
+ placeOrder( ): void
- MAX_ PRICE = 200
- name: String
- employeeNo: String
- commission: int
+ takeOrder( ): void
alex lawrence takeOrder
client server

13. 13
Inheritance
• Object classes may inherit attributes and
services from other object classes.
• Inheritance represents the generalization of
a class.

14. A generalisation hierarchy
14
Employee
Programmer
project
progLanguage
Manager
budgetsControlled
dateAppointed
Project
Manager
projects
Dept.
Manager
Strategic
Manager
dept responsibilities

15. Library class
hierarchy
Recorded item
Computer
program
15
Acquire ()
Catalogue ()
Dispose ()
Issue ()
Return ()
Book
Published item
Author
Edition
Publication date
ISBN
Magazine
Year
Issue
Film
Director
Date of release
Distrib
Version
Platform
Title
Publisher
Title
Medium
Library Item
Catalogue Number
Acquisition date
Cost
Type
Status
Number of copies

16. User class hierarchy
Student
16
Library user
Name
Address
Phone
Registration #
Register ()
De-r egister ()
Reader
Affiliation
Borrower
Items on loan
Max. loans
Staff
Department
Department phone
Major subject
Home address

17. Multiple inheritance
• Rather than inheriting the attributes and services
from a single parent class, a system which
supports multiple inheritance allows object classes
to inherit from several super-classes
• Can lead to semantic conflicts where
attributes/services with the same name in different
super-classes have different semantics
• Makes class hierarchy reorganisation more
complex
17

18. Multiple inheritance
Voice recording
18
Talking book
Author
Edition
Publication date
ISBN
# Tapes
Book
Speaker
Duration
Recording date

19. Advantages of inheritance
• It is an abstraction mechanism which may
be used to classify entities
• It is a reuse mechanism at both the design
and the programming level
• The inheritance graph is a source of
organisational knowledge about domains
and systems
19

20. Problems with inheritance
• Object classes are not self-contained. they cannot
be understood without reference to their super-classes
• Designers have a tendency to reuse the inheritance
graph created during analysis. Can lead to
significant inefficiency
• The inheritance graphs of analysis, design and
implementation have different functions and
should be separately maintained
20

21. Inheritance and OOD
• There are differing views as to whether
inheritance is fundamental to OOD.
– View 1. Identifying the inheritance hierarchy or
network is a fundamental part of object-oriented design.
Obviously this can only be implemented using an
OOPL.
– View 2. Inheritance is a useful implementation concept
which allows reuse of attribute and operation
definitions. Identifying an inheritance hierarchy at the
design stage places unnecessary restrictions on the
implementation
• Inheritance introduces complexity and this is
undesirable, especially in critical systems
21

22. Objects Association
• Modeling an association between two classes
means that there is some sort of relationship
between objects of each class that may be
connected.
Student 0..* Course 1..*
22
studies

23. Object aggregation
• Aggregation model shows how classes
which are collections are composed of other
classes
• Similar to the part-of relationship in
semantic data models
23

24. Object aggregation
Videotape
Tape ids.
24
Study pack
Lecture
notes
Text
OHP slides
Slides
Assignment
Credits
Solutions
Text
Diagrams
Exercises
#Problems
Description
Course title
Number
Year
Instructor
1 ..*
1 1 1 1
1 ..* 1 ..* 0 ..*
1 1
1 ..* 1 ..*

25. Object Cohesion & Coupling
• Cohesion of a component is a measure of how
well it fits together. Each operation provides
functionality which allows the attributes of the
object to be modified, inspected or used as a basis
for service provision.
• Coupling is an indication of the strength of
interconnections between program units. Highly
coupled systems have strong interconnections,
with program units dependent on each other
(shared variables, interchange control function).
Loosely coupled system which are independent .
25

26. name
getName( )
calculateArea( )
26
Polymorphism
• the ability of different objects to perform the
appropriate method in response to the same
message is known as polymorphism.
• the selection of the appropriate method depends
on the class used to create the object
Shape
Circle Square
side
calculateArea( )
radius
calculateArea( )

27. Example Polymorphism
27
class Shape {
private String name;
public Shape(String aName) { name=aName; }
public String getName( ) { return name; }
public float calculateArea( ) { return 0.0f; }
} // End Shape class a generic action
class Circle extends Shape {
private float radius;
public Circle(String aName) { super(aName); radius = 1.0f; }
public Circle(String aName, float radius) {
super(aName); this.radius = radius;
}
public float calculateArea() { return (float)3.14f*radius*radius; }
} // End Circle class
inheritance
overloading
overriding

28. 28
class Square extends Shape {
private float side;
public Square(String aName) { super(aName); side =
1.0f; }
public Square(String aName, float side) {
super(aName); this.side = side;
}
public float calculateArea() { return (float)
side*side; }
} // End Square class

29. Polymorphism Example
29
public class ShapeDemoClient {
public static void main(String argv[ ]) {
Shape c1 = new Circle("Circle C1");
Shape c2 = new Circle("Circle C2", 3.0f);
Shape s1 = new Square("Square S1");
Shape s2 = new Square("Square S2", 3.0f);
Shape shapeArray[ ] = {c1, s1, c2, s2};
for (int i = 0; i < shapeArray.length; i++) {
System.out.println("The area of " + shapeArray[i].getName( )
+ " is " + shapeArray[i].calculateArea( )
+ " sq. cm.");
}
} // End main
} // End ShapeDemoClient1 class
rule of subtype
dynamic binding

30. OO Analysis and Design
OO Analysis - examines requirements from the perspective
of the classes and objects found in the vocabulary of the
problem domain. In other words, the world (of the system)
is modelled in terms of objects and classes.
OO Design - OO decomposition and a notation for depicting
models of the system under development. Structures are
developed whereby sets of objects collaborate to provide
the behaviours that satisfy the requirements of the
problem.
30

31. Object Oriented Analysis
31
• Analyze the domain problem
• Describe the process systems
• Identify the objects
• Specify attributes
• Defining operations
• Inter-object Communication

32. 32
Identifying Object
• Objects can be:
– External Entity (e.g., other systems, devices, people)
that produce or consume information to be used by
system
– Things (e.g., reports, displays, letters, signals) that are
part of information domain for the problem
– Places (e.g., book’s room) that establish the context of
the problem and the overall function of the system.
– Organizational units (e.g., division, group, team,
department) that are relevant to an application,
– Transaction (e.g., loan, take course, buy, order).

33. Example of candidate objects
Just a Line management wishes to increase security, both in their building and on
site, without antagonizing their employees. They would also like to prevent
people who are not part of the company from using the Just a Line car park.
It has been decide to issue identity cards to all employees, which they are
expected to wear while on the Just a Line site. The cards records the name,
department and number of the member of staff, and permit access to the Just a
Line car park.
A barrier and a card reader are placed at the entrance to the car park. The driver of
an approaching car insert his or her numbered card in the card reader, which
then checks that the card number is known to the Just a Line system. If the
card is recognized, the reader sends a signal to raise the barrier and the car is
able to enter the car park.
At the exit, there is also a barrier, which is raised when a car wishes to leave the
33
car park.
When there are no spaces in the car park a sign at the entrance display “Full” and
is only switched off when a car leaves.
Special visitor’s cards, which record a number and the current date, also permit
access to the car park. Visitor’s cards may be sent out in advance, or collected
from reception. All visitor’s cards must be returned to reception when the
visitor leaves Just a Line.

34. 34
Candidate objects:
Just a Line management security building
site employee people company
car park card name department
number member of staff access barrier
card reader entrance driver car
system signal exit space
sign visitor reception

35. Candidate objects’ rejection
• duplicates: if two or more objects are simply different names for the
35
same thing.
• irrelevant: objects which exists in the problem domain, but which are
not intended.
• vague: when considering words carefully it sometimes becomes clear
that they do not have a price meaning and cannot be the basis of a
useful in the system.
• general: the meaning is too broad.
• attributes: as the attribute of objects.
• associations: actually represents the relationships between objects.
• roles: sometimes objects referred to by the role they play in a
particular part of the system.

36. Rejected Candidate objects
Candidate objects Rejection criteria
Just a Line, member of staff duplicates with company,
employee respectively
36
management,company,
building, site, visitor and
reception
irrelevant to the system
security, people vague
system too general
name, department, attribute
access association
driver role

37. 37
Rest Objects
Car park Staff Card Visitor’s card
Employee Entrance exit
card reader barrier Full sign
space sensor car

38. Define class attributes
38
Car Park
capacity
spaces
inc.spaces()
dec.spaces()
space left()
Full sign
on:boolean
switch on()
switch off()
Barrier
type:
up:boolean
raise()
lower()
Card Reader
valid card nos.
read card()
card OK()

39. 39
Data Dictionary
Barrier: type + up
type = [“Entrance”|”Exit”]
up = [“true”|”false”]
raise: if the barrier is not already raised, this operation takes as
argument an object of the barrier class and returns an object of the
same class, with the up attribute set to “true”. If the barrier is already
up, the operation returns the error message “barrier is already raised”
lower: if the barrier is not already lower, this operation takes as
argument an object of the barrier class and returns an object of the
same class, with the up attribute set to “false”. If the barrier is already
down, the operation returns the error message “barrier already
lowered”.

40. Objects Relationship
Car Park Car Park
40
Card Reader
2 ..* 2 ..*
Sensor
Barrier
1 ..*
1 .. *
1
Valid cards
Card
1 .. *
Visitor’s Card Staff Card

41. Object behaviour modelling
• A behavioural model shows the interactions
between objects to produce some particular
system behaviour that is specified as a use-case
• Sequence diagrams (or collaboration
diagrams) in the UML are used to model
interaction between objects
41

42. Sequence Diagram for Entrance
:User :CarPark :Sensor :CardReader :Valid card :Barrier :Full Sign
42
Card OK
Full Sign off
Car present
Check space left
Yes
Card number
Card number
Card returned
Raise
Car not present
lower
Decrement Space
Check space left
Yes

43. OO Analysis and Design
Object-Oriented (OO) development is very different
from structured development:
• Structured approach focuses on major functions
within a system and on the data used by the
functions.
• OO approach focuses on the objects in a system
and on the relationships between those objects.
43

44. · Unlike functional decomposition, OO views a
complex problem as a meaningful collection of
objects that collaborate to achieve some higher
level behaviour => closely mirrors how people
view complex problems => using OO should
make the job of developing large, complex
systems more manageable.
44

45. Object Oriented Model
45

46. 46
Structured Model

47. 47
Comparison
OO:
Systems decomposed into
collections of data objects;
function + data in one place =>
• System components more
independent => more resilient
to requirements and
maintenance changes.
• Inheritance and polymorphism
are possible => reuse,
extension, and tailoring of
software/designs is possible.
• Closely mirrors how humans
decompose and solve
complex.
Structured:
Systems decomposed into
functions; functions and data
modelled separately =>
• System components are more
dependent on each other =>
requirements and
maintenance changes more
difficult
• Inheritance and polymorphism
not possible => limited reuse
possible.
• System components do not
map closely to real-world
entities => difficult to manage
complexity.

48. 48
Comparison
OO:
Process allows for iterative and
incremental development =>
• Integration of programs is
series of incremental
prototypes.
• Users and developers get
important feedback
throughout development.
• Testing resources distributed
more evenly.
• If time is short, coding and
testing can begin before the
design is finished.
Structured:
Process less flexible and largely
linear =>
• Integration of programs is ‘big
bang’ effect.
• Users or developers provided
with little or no feedback; see
system only when it has been
completed.
• Testing resources are
concentrated in the
implementation stage only.
• Coding and testing cannot
begin until all previous stages
are complete.