The document provides an overview of Object-Oriented Analysis and Design (OOAD) concepts, including definitions of objects and classes, inheritance, and polymorphism. It describes the process of identifying classes, designing interfaces, and establishing object relationships through various UML diagrams. The document emphasizes the iterative nature of object identification and the importance of encapsulating behaviors and attributes in classes for effective system design.

1. Object Oriented Analysis & Design
Presentation By
Ganapathi M

2. • An instance of a CLASS
• Contains meaningful data
• Concepts that occupy memory space at
runtime are, according to the definition,
objects
– If not, they are CLASSES
– For example: data type vs. double
2
What is an OBJECT

3. A little Quiz…
• #1 Class or Object?
3
DogDog
Scooby-DooScooby-Doo
Dog is a generalization of Scooby-Doo

4. A little Quiz (cont’d)…
• #2 Class or Object?
4
DogDog
Scooby-DooScooby-Doo
AnimalAnimal
The concept of subclass!
Dog is a subclass of the Animal class
Animal is a generalization of Dog

5. A little Quiz (cont’d)…
• #3 Class or Object?
5
AnimalAnimal
DogDogBirdBird
The concept of polymorphism!

6. Characteristics of OOD
• Objects are abstractions of real-world or system
entities and manage themselves
• Objects are independent and encapsulate state and
representation information.
• System functionality is expressed in terms of object
services
• Shared data areas are eliminated
– Objects communicate by message passing
• Objects may be distributed
• Objects may execute sequentially or in parallel6

7. Advantages of OOD
• Easier maintenance. Objects may be
understood as stand-alone entities
• Objects are appropriate reusable components
• For some systems, there may be an obvious
mapping from real world entities to system
objects
7

8. Object-oriented development
• Object-oriented analysis, design and programming
are related but distinct
• OOA is concerned with developing an object model
of the application domain
• OOD is concerned with developing an object-
oriented system model to implement requirements
• OOP is concerned with realising an OOD using an
OO programming language
8

9. Objects and object classes
• Objects are entities in a
software system which
represent instances of real-
world and system entities
• Object classes are templates
for objects
– Classes may be used to create
objects
• Object classes may inherit
attributes and services from
other object classes
Em p loyee
nam e: string
addres s: s tring
dateO fBirth: Date
em ployeeN o: integer
s ocialSec urity No: s tring
department: Dept
ma nager: Employ ee
s alary : integer
s tatus: {current, left, retired}
taxC ode: integer
. . .
join ()
leav e ()
retire ()
c hangeDetails ()
9

10. Object communication
• Conceptually, objects communicate by message
passing
• Messages
– The name of the service requested by the calling object.
– Copies of the information required to execute the
service
and the name of a holder for the result of the service.
• In practice, messages are often implemented
by procedure (a.k.a. method) calls
– Name = method name
– Information = parameter list
– Result holder = method return value
10

11. Message examples
// Call a method associated with a buffer
// object that returns the next value
// in the buffer
v = circularBuffer.Get() ;
// Call the method associated with a
// thermostat object that sets the
// temperature to be maintained
thermostat.setTemp(20) ;
11

12. Generalisation and inheritance
• Objects are members of classes which define
attribute types and operations
• Classes may be arranged in a class hierarchy where
one class (a super-class) is a generalisation of one or
more other classes (sub-classes)
• A sub-class inherits the attributes and operations
from its super class and may add new methods or
attributes of its own
• It is a reuse mechanism at both the design and the
programming level
• Inheritance introduces complexity and this is
undesirable, especially in critical systems 12

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

14. Object Relationships
• Objects and object classes participate in
relationships with other objects and object
classes
– In UML, such a relationship is indicated by an
association
• Associations may be annotated with
information that describes the association
Employee
Department
Manager
is-member-of
is-managed-by
manages
14

15. Object identification
• Identifying objects (or object classes) is the
most difficult part of object oriented design
• There is no “magic formula” for object
identification
– It relies on the skill, experience
and domain knowledge of system designers
• Object identification is an iterative process
– You are unlikely to get it right first time
15

16. Approaches to identification
• Use a grammatical approach based on a
natural language description of the system
(used in HOOD method)
• Base the identification on tangible things in
the application domain
• Use a behavioural approach and identify
objects based on what participates in what
behaviour
• Use a scenario-based analysis – the objects,
attributes and methods in each scenario are
identified 16

17. Object interface specification
• Object interfaces have to be specified so
that the objects and other components
can be designed in parallel
• Designers should avoid designing the
interface representation but should hide
this in the object itself
• Objects may have several interfaces
which are viewpoints on the methods
provided
17

18. Examples of design models
• Sub-system models that show logical groupings of
objects into coherent subsystems
– UML package diagrams
• Sequence models that show the sequence of
object interactions
– UML sequence diagrams
• State machine models that show how individual
objects change their state in response to events
– UML statechart diagrams
• Other models include use-case models,
aggregation models, generalisation models,etc.
18

19. Weather station subsystems
19
«subsystem»
Interface
CommsController
WeatherStation
«subsystem»
Data collection
«subsystem»
Instruments
Air
thermometer
WeatherData
Ground
thermometer
Anemometer
WindVane
RainGauge
Instrument
Status
Barometer

20. Weather station - data
collection sequence
20
:CommsController
request (report)
acknowledge ()
report ()
summarise ()
reply (report)
acknowledge ()
send (report)
:WeatherStation :WeatherData

21. State charts
• Object states
• State transitions triggered by
requests to objects
21

22. OOD Process – Access Layer
• Create Mirror classes: For every business class
identified and created, create one access class.
• Simplify classes and their relationships – to
eliminate redundant classes and structures
• Redundant classes: Do not keep 2 classes that
perform similar request and results translation
activities. Select one and eliminate the other.
• Methods: Revisit the classes that consist of only
one or two methods to see if they can be
eliminated or combined with existing classes.22

23. Object Oriented Design Process
• Design the view layer classes
– Design the macro & micro level user interface,
identifying view layer objects
– Test usability and user satisfaction
• From the UML class diagram, begin to extrapolate
the classes to build and classes to reuse.
• Also think about the inheritance structure.
• If we have several classes that seem related but
have specific differences, probably it means an
inheritance structure.
• All designed components must trace back to the
user requirements.
23

24. Example: Invoice
24

25. Example: Invoice
• Classes that come to mind: Invoice,
LineItem, and Customer
• Good idea to keep a list of candidate classes
• Brainstorm, simply put all ideas for classes
onto the list
• You can cross not useful ones later
25

26. Finding Classes
• Keep the following points in mind:
– Class represents set of objects with the same behavior
• Entities with multiple occurrences in problem
description are good candidates for objects
• Find out what they have in common
• Design classes to capture commonalities
– Represent some entities as objects, others as primitive
types
• Should we make a class Address or use a String?
– Not all classes can be discovered in analysis phase
– Some classes may already exist 26

27. CRC Card
• CRC Card
• Describes a class, its responsibilities, and its
collaborators
• Use an index card for each class
• Pick the class that should be responsible for each
method (verb)
• Write the responsibility onto the class card
• Indicate what other classes are needed to fulfill
responsibility (collaborators)
27

28. CRC Card
28

29. Self Check
1. Suppose the invoice is to be saved to a file.
Name a likely collaborator.
2. Looking at the invoice, what is a likely
responsibility of the Customer class?
3. What do you do if a CRC card has ten
responsibilities?
29

30. Answers
1. FileWriter
2. To produce the shipping address of the
customer.
3. Reword the responsibilities so that they are
at a higher level, or come up with more
classes to handle the responsibilities.
30

31. Relationships Between Classes
• Inheritance
• Aggregation
• Dependency
31

32. Inheritance
• Is-a relationship
• Relationship between a more general
class (superclass) and
a more specialized class (subclass)
• Every savings account is a bank
account
32
Continued…

33. Inheritance
• Every circle is an ellipse (with equal
width and height)
• It is sometimes abused
–Should the class Tire be a subclass of
a class Circle?
–The has-a relationship would be more
appropriate
33

34. Aggregation
• Has-a relationship
• Objects of one class contain references to objects of
another class
• Use an instance variable
– A tire has a circle as its boundary:
• Every car has a tire (in fact, it has four)
34
class Tire
{
. . .
private String rating;
private Circle boundary;
}

35. Example
35
class Car extends Vehicle
{
. . .
private Tire[] tires;
}

36. Example
36
UML Notation for Inheritance and Aggregation

37. Dependency
• Uses relationship
• Example: many of our applications
depend on the Scanner class to read
input
• Aggregation is a stronger form of
dependency
• Use aggregation to remember another
object between method calls 37

38. UML Relationship Symbols
Relationship Symbol Line Style Arrow Tip
Inheritance Solid Triangle
Interface
Implementation
Dotted Triangle
Aggregation Solid Diamond
Dependency Dotted Open
38

39. Self Check
4. Consider the Bank and BankAccount
classes. How are they related?
5. Consider the BankAccount and
SavingsAccount objects. How are they
related?
6. Consider the BankAccountTester class.
Which classes does it depend on?
39

40. Answers
4. Through aggregation. The bank manages
bank account objects.
5. Through inheritance.
6. The BankAccount, System, and
PrintStream classes.
40

41. Attributes and Methods in UML
41
Attributes and Methods in a Class Diagram

42. Multiplicities
• any number (zero or more): *
• one or more: 1..*
• zero or one: 0..1
• exactly one: 1
42
An Aggregation Relationship with Multiplicities

43. Aggregation and Association
• Association: more general relationship
between classes
• Use early in the design phase
• A class is associated with another if you
can navigate from objects of one class to
objects of the other
• Given a Bank object, you can navigate to
Customer objects 43 Continued…

44. Aggregation and Association
44
An Association Relationship

45. Five-Part Development Process
• Understand requirements
• Use CRC cards to find classes, responsibilities,
and collaborators
• Use UML diagrams to record class
relationships
• Document method behavior
• Implement your program
45

46. Printing an Invoice – Reqs
• Task: print out an invoice
• Invoice: describes the charges for a set of products in certain
quantities
• Omit complexities
– Dates, taxes, and invoice and customer numbers
• Print invoice
– Billing address, all line items, amount due
• Line item
– Description, unit price, quantity ordered, total price
• For simplicity, do not provide a user interface
• Test program: adds line items to the invoice and then prints it
46
Continued…

47. Sample Invoice
47

48. CRC Cards
• Discover classes
• Nouns are possible classes
48
Invoice
Address
LineItem
Product
Description
Price
Quantity
Total
Amount Due

49. CRC Cards
• Analyze classes
49
Invoice
Address
LineItem // Records the product and the quantity
Product
Description // Field of the Product class
Price // Field of the Product class
Quantity // Not an attribute of a Product
Total // Computed–not stored anywhere
Amount Due // Computed–not stored anywhere
Continued…

50. CRC Cards
• Classes after a process of elimination
50
Invoice
Address
LineItem
Product

51. CRC Cards for Printing Invoice
• Invoice and Address must be able to
format themselves:
51

52. CRC Cards for Printing Invoice
• Add collaborators to invoice card:
52

53. CRC Cards for Printing Invoice
• Product and LineItem CRC cards:
53

54. CRC Cards for Printing Invoice
• Invoice must be populated with products
and quantities:
54

55. Printing an Invoice – UML Diag
55
The Relationships Between the Invoice Classes

56. Implementation
• Invoice aggregates Address and
LineItem
• Every invoice has one billing address
• An invoice can have many line items:
56
public class Invoice
{
. . .
private Address billingAddress;
private ArrayList<LineItem> items;
}

57. Implementation
• A line item needs to store a Product object
and quantity:
57
public class LineItem
{
. . .
private int quantity;
private Product theProduct;
}

58. Implementation
• The methods themselves are now very easy
• Example:
– getTotalPrice of LineItem gets the unit price of
the product and multiplies it with the quantity
58
/**
Computes the total cost of this line item.
@return the total price
*/
public double getTotalPrice()
{
return theProduct.getPrice() * quantity;
}

59. Self Check
7. Which class is responsible for computing the
amount due? What are its collaborators for
this task?
8. Why do the format methods return
String objects instead of directly printing
to System.out?
59

60. Answers
7. The Invoice class is responsible for
computing the amount due. It collaborates
with the LineItem class.
8. This design decision reduces coupling. It
enables us to reuse the classes when we
want to show the invoice in a dialog box or
on a web page.
60