UNIT - III

OBJECT ORIENTED SOFTWARE DESIGN

D.Sudhagar/Associate Professor
 UNIT - III OBJECT ORIENTED SOFTWARE DESIGN
Object Oriented Design – Interaction Diagrams – Sequence Diagram –
Collaboration Diagrams – Refinement of Use Case Description –
Refinement of Classes and Relationships – Construction of Detailed Class
Diagram – Development of Detailed Design & Creation of Software Design
Document - Object Oriented Methods : Object Oriented Analysis (OOA /
Coad-Yourdon), Object Oriented Design (OOD/Booch) , Hierarchical Object
Oriented Design (HOOD), Object Modeling Technique (OMT), Responsibility
– Driven Design Case Studies : Warehouse Management System, Telecom.

Reference:
1. Yogesh Singh, Ruchika Malhotra, “Object – Oriented Software
Engineering”, PHI Learning Private Limited ,First edition, 2012
Object Oriented Software Life Cycle
 Object Oriented Design(OOD)
• 2 stages
1. Conceptual design
2. Detailed design

Conceptual design
• Recognize all the classes required to build the system
• Responsibilities are allocated to each class
• In high level design,
• Class diagram – analyse the relationship between classes
• Interaction diagram – shows the flow of the events.
Detailed design
• Attributes and operations are allocated to each class based on their interaction
diagram.
• The state machine diagram is developed to explain the next details of the design is
called as low-level design.
Interaction Diagrams
 Interaction Diagrams

• Interaction diagrams describe how groups of

objects collaborate to get the job done.
• Interaction diagrams capture the behavior of a
single use case, showing the pattern of interaction
among objects.
 Interaction Diagrams
An interaction diagram depicts the messages between
objects or classes in a program. It shows collaborations
between objects.

The UML includes two types of interaction diagrams

• Collaboration diagrams
• Sequence diagrams.
 Collaboration Diagrams
A collaboration diagram is a network model of
messages between interacting objects or classes.
Its components are:
• Objects or classes – shown as labeled rectangles
• Links (instances of associations) – shown as lines
• Messages – shown next to the links
Arrows show the direction of messages.
 Collaboration Diagrams
The links are message paths.

The sequence of messages is shown by a hierarchical

numbering convention.

The standard UML syntax for a message is:

messageName (in parameter : parameterType, out
parameter : parameterType)
 Collaboration Diagrams
• A collaboration diagram represents a set of objects
related in a particular context, and the exchange of
their messages to achieve a desired outcome.
Telephone Call
Object Caller Message

1: OffHooke
2: DialTone 3: Dial Number

Exchange

4: RingTone

Receiver

5: OffHook

6: OnHook
Talk
Collaboration Diagrams

Telephone Call
Object Caller Message

1.1: OffHooke 2.1: DialTone 1.2: Dial Number

Exchange

2.2: RingTone

Receiver

3.1: OffHook

4.1: OnHook
Talk
Collaboration Diagrams (continued)

.
 Sequence Diagrams
• Sequence diagrams are an easy and intuitive way
of describing the behavior of a system.
• A sequence diagram shows an interaction
arranged in a time sequence.
Telephone Call
Caller Exchange Receiver Talk

OffHook

DialTone

Dial Number

RingTone

OffHooke

OnHook
 Sequence Diagrams
System sequence diagrams show only messages
between the system and actors.

Design sequence diagrams show all the messages

between objects inside the system.
 Sequence Diagrams
Automated tools convert collaboration diagrams to
sequence diagrams and vice versa.

Manual conversion involves using the sequence

numbers in the collaboration diagrams to place
t h e m e s s a g e s i n
the sequence diagram in order from top to bottom.
Creating Sequence Diagrams (continued)

.
Creating Sequence Diagrams (continued)

.
Sequence Diagrams (continued)

.
 Design Class Diagrams
A design class diagram follows the same conventions as a domain
model.
However, it also shows the operations of the classes.
Design Class Diagrams (continued)

.
Procedure for Object-Oriented Design

Step 1. Produce an interaction diagram for each system operation

identified during analysis.
Step 2. Produce a design class diagram showing the operations from
the interaction diagrams.
Step 3. Specify the signature and the algorithm for each operation.
Step 4. Design the graphical user interface.
Step 5. Define the interface to the presentation layer.
Step 6. Define the interface to the storage layer.
Step 7. Place the classes in packages.
Refinement of Use Case Description
Construction of Detailed Class Diagram

36
How do we design classes?
• class identification from project spec / requirements
• nouns are potential classes, objects, fields
• verbs are potential methods or responsibilities of a class

• CRC card exercises

• write down classes' names on index cards
• next to each class, list the following:
• responsibilities: problems to be solved; short verb phrases
• collaborators: other classes that are sent messages by this class (asymmetric)

• UML diagrams
• class diagrams (today)
• sequence diagrams
• ...

37
Introduction to UML
• UML: pictures of an OO system
• programming languages are not abstract enough for OO design
• UML is an open standard; lots of companies use it

• What is legal UML?

• a descriptive language: rigid formal syntax (like programming)
• a prescriptive language: shaped by usage and convention
• it's okay to omit things from UML diagrams if they aren't needed by
team/supervisor/instructor

38
Uses for UML
• as a sketch: to communicate aspects of system
• forward design: doing UML before coding
• backward design: doing UML after coding as documentation
• often done on whiteboard or paper
• used to get rough selective ideas

• as a blueprint: a complete design to be implemented

• sometimes done with CASE (Computer-Aided Software Engineering) tools

• as a programming language: with the right tools, code can be auto-

generated and executed from UML
• only good if this is faster than coding in a "real" language

39
UML class diagrams
• What is a UML class diagram?
n UML class diagram: a picture of the classes in an
OO system, their fields and methods, and
connections between the classes that interact or
inherit from each other
n details of how the classes interact with each other

n algorithmic details; how a particular behavior is

implemented
• What are some things that are not represented in a UML class
diagram?

40
Diagram of one class
• class name in top of box
• write <<interface>> on top of interfaces' names
• use italics for an abstract class name

• attributes (optional)
• should include all fields of the object

• operations / methods (optional)

• may omit trivial (get/set) methods
• but don't omit any methods from an interface!
• should not include inherited methods

41
Class attributes
• attributes (fields, instance variables)
• visibility name : type [count] = default_value

• visibility: + public
# protected
- private
~ package (default)
/ derived
• underline static attributes

• derived attribute: not stored, but can

be computed from other attribute values

• attribute example:
- balance : double = 0.00

42
Class operations / methods
• operations / methods
• visibility name (parameters) : return_type

• visibility: + public
# protected
- private
~ package (default)
• underline static methods
• parameter types listed as (name: type)
• omit return_type on constructors and
when return type is void

• method example:
+ distance(p1: Point, p2: Point): double

43
Comments
• represented as a folded note, attached to the appropriate
class/method/etc by a dashed line

44
Relationships btwn. classes
• generalization: an inheritance relationship
• inheritance between classes
• interface implementation

• association: a usage relationship

• dependency
• aggregation
• composition

45
Generalization relationships
• generalization (inheritance) relationships
• hierarchies drawn top-down with arrows pointing
upward to parent
• line/arrow styles differ, based on whether parent is
a(n):
• class:
solid line, black arrow
• abstract class:
solid line, white arrow
• interface:
dashed line, white arrow

• we often don't draw trivial / obvious generalization

relationships, such as drawing the Object class as a
parent

46
Associational relationships
• associational (usage) relationships
1. multiplicity (how many are used)
• *  0, 1, or more
• 1  1 exactly
• 2..4  between 2 and 4, inclusive
• 3..*  3 or more
2. name (what relationship the objects have)
3. navigability (direction)

47
Multiplicity of associations
n one-to-one
n each student must carry exactly one ID card

n one-to-many
n one rectangle list can contain many rectangles

48
 Car

Association types 1
aggregation
1
• aggregation: "is part of"
Engine
• symbolized by a clear white diamond

Book
• composition: "is entirely made of" composition
• stronger version of aggregation 1
• the parts live and die with the whole *
• symbolized by a black diamond Page

• dependency: "uses temporarily"

dependency
• symbolized by dotted line
• often is an implementation Lottery Random
detail, not an intrinsic part of Ticket
that object's state 49
Class diagram example 1

50
Class diagram example 2
Multiplicity

Customer
1 Simple
Class Aggregation

Abstract Rental Invoice

Class

Rental Item 1..*

1 0..1

Composition Simple
Generalization
Association

Checkout Screen
DVD Movie VHS Movie Video Game

51
Class diagram example 3

StudentBody Student
1 100
- firstName : String
+ main (args : String[]) - lastName : String
- homeAddress : Address
- schoolAddress : Address

+ toString() : String
Address
- streetAddress : String
- city : String
- state : String
- zipCode : long

+ toString() : String

52
Tools for creating UML diags.
• Violet (free)
• http://horstmann.com/violet/

• Rational Rose
• http://www.rational.com/

• Visual Paradigm UML Suite (trial)

• http://www.visual-paradigm.com/
• (nearly) direct download link:
http://www.visual-paradigm.com/vp/download.jsp?product=vpuml&edition=ce

(there are many others, but most are commercial)

53
 Development of Detailed Design &
Creation of Software Design Document