Object Oriented Design

OO Design 1
Object Orientation
 Traditional procedural systems separate
data and procedures, and model these
separately
 Object orientation –views data and fns
together; data abstraction is the basis
 The purpose of OO design is to define
the classes in the system to be built and
their relationships

OO Design 2
OOA and OOD
 OO techniques can be used in analysis (req)
as well as design
 The methods and notations are similar
 In OOA we model the problem, while in OOD
we model the solution
 Often OOA structures are subsumed in the
solution domain structures
 The line between OOA and OOD is not fixed

OO Design 3
OOA and OOD…

OO Design 4
OO Concepts
 Encapsulation – grouping of related
ideas into one unit which we can refer
to by a single name
 Eg. procedures, funs, packages
 In OO, object is the unit; encapsulates
state and provides interface to access
and modify

OO Design 5
OO Concepts..
 Information hiding – use encapsulation
to restrict external visibility
 OO encapsulates the data, provides
limited access, visibility
 Info hiding can be provided without OO
– is an old concept

OO Design 6
OO Concepts…
 State retention – fns, procedures do not
retain state; an object is aware of its
past and maintains state
 Identity – each object can be identified
and treated as a distinct entity
 Behavior – state and services together
define the behavior of an object, or how
an object responds

OO Design 7
OO Concepts..
 Messages – through which a sender obj
conveys to a target obj a request
 For requesting O1 must have – a handle
for O2, name of the op, info on ops that
O2 requires
 General format O2.method(args)

OO Design 8
OO Concepts..
 Classes – a class is a stencil from which
objects are created; defines the structure and
services. A class has
 An interface which defines which parts of an
object can be accessed from outside
 Body that implements the operations
 Instance variables to hold object state
 Objects and classes are different; class is a
type, object is an instance
 State and identity is of objects
OO Design 9
OO Concepts – access
 Operations in a class can be
 Public: accessible from outside
 Private: accessible only from within the
class
 Protected: accessible from within the class
and from within subclasses
 There are some constructor and
destructor operations
OO Design 10
Inheritance
 Inheritance is unique to OO and not there in
function-oriented languages/models
 Inheritance by class B from class A is the
facility by which B implicitly gets the
attributes and ops of A as part of itself
 Attributes and methods of A are reused by B
 When B inherits from A, B is the subclass or
derived class and A is the base class or
superclass

OO Design 11
Inheritance..
 A subclass B generally has a derived
part (inherited from A) and an
incremental part (is new)
 Hence, B needs to define only the
incremental part
 Creates an “is-a” relationship – objects
of type B are also objects of type A

OO Design 12
Inheritance…

OO Design 13
Inheritance…
 The inheritance relationship between classes
forms a class hierarchy
 In models, hierarchy should represent the
natural relationships present in the problem
domain
 In a hierarchy, all the common features can
be accumulated in a superclass
 An existing class can be a specialization of an
existing general class – is also called
generalization-specialization relationships

OO Design 14
OO Design 15
Inheritance…
 Strict inheritance – a subclass takes all
features of parent class
 Only adds features to specialize it
 Non-strict: when some of the features
have been redefined
 Strict inheritance supports “is-a” cleanly
and has fewer side effects

OO Design 16
Inheritance…
 Single inheritance – a subclass inherits
from only one superclass
 Class hierarchy is a tree
 Multiple inheritance – a class inherits
from more than one class
 Can cause runtime conflicts
 Repeated inheritance - a class inherits from
a class but from two separate paths
OO Design 17
Inheritance and Polymorphism
 Inheritance brings polymorphism, i.e. an
object can be of different types
 An object of type B is also an object of type A
 Hence an object has a static type and a
dynamic type
 Implications on type checking
 Also brings dynamic binding of operations which
allows writing of general code where operations
do different things depending on the type

OO Design 18
Module Level Concepts
 Basic modules are classes
 During design key activity is to specify
the classes in the system being built
 Correctness of design is fundamental
 But design should also be “good” –
efficient, modifiable, stable, …
 Can evaluate a design using coupling,
cohesion, and open-closed principle
OO Design 19
Coupling
 Coupling is an inter-module concept, captures
the strength of interconnection between
modules
 More tightly coupled the modules, the more
they depend on each other, more difficult to
modify one
 Low coupling is desirable for making systems
understandable and modifiable
 In OO, three types of coupling exists –
interaction, component, and inheritance

OO Design 20
Coupling…
 Interaction coupling occurs due to
methods of a class invoking methods of
other classes
 Like calling of functions
 Worst form if methods directly access
internal parts of other methods
 Still bad if methods directly manipulate
variables of other classes
 Passing info through tmp vars is also bad
OO Design 21
Coupling…
 Least interaction coupling if methods
communicate directly with parameters
 With least number of parameters
 With least amount of info being passed
 With only data being passed
 I.e. methods should pass the least
amount of data, with least no of parms

OO Design 22
Coupling…
 Component coupling – when a class A has
variables of another class C
 A has instance vars of C
 A has some parms of type C
 A has a method with a local var of type C
 When A is coupled with C, it is coupled with
all subclasses of C as well
 Component coupling will generally imply the
presence of interaction coupling also

OO Design 23
Coupling…
 Inheritance coupling – two classes are
coupled if one is a subclass of other
 Worst form – when subclass modifies a
signature of a method or deletes a method
 Coupling is bad even when same signature
but a changed implementation
 Least, when subclass only adds instance vars
and methods but does not modify any

OO Design 24
Cohesion
 Cohesion is an intra-module concept
 Focuses on why elements are together
 Only elts tightly related should exist together in a
module
 This gives a module clear abstraction and makes it
easier to understand
 Higher cohesion leads to lower coupling –
many interacting elements are in the module
 Goal is to have higher cohesion in modules
 Three types of cohesion in OO – method,
class, and inheritance
OO Design 25
Cohesion…
 Method cohesion – why diff code elts
are together in a method (like cohesion
in functional modules)
 Highest form is if each method implements
a clearly defined function with all elts
contributing to implementing this function
 Should be able to state what the module
does by a simple statement

OO Design 26
Cohesion…
 Class cohesion – why diff attributes and
methods are together in a class
 A class should represent a single concept
with all elts contributing towards it
 Whenever multiple concepts encapsulated,
cohesion is not as high
 A symptom of multiple concepts – diff gps
of methods accessing diff subsets of
attributes

OO Design 27
Cohesion…
 Inheritance cohesion – focuses on why
classes are together in a hierarchy
 Two reasons for subclassing –
generalization-specialization and reuse
 Cohesion is higher if the hierarchy is for
providing generalization-specialization

OO Design 28
Open-closed Principle
 Principle: Classes should be open for
extension but closed for modification
 Behavior can be extended to accommodate new
requirements, but existing code is not modified
 I.e. allows addition of code, but not modification
of existing code
 Minimizes risk of having existing functionality stop
working due to changes – a very important
consideration while changing code
 Good for programmers as they like writing new
code
OO Design 29
Open-closed Principle…
 In OO this principle is satisfied by using
inheritance and polymorphism
 Inheritance allows creating a new class to
extend behavior without changing the original
class
 This can be used to support the open-closed
principle
 Consider example of a client object which
interacts with a printer object for printing

OO Design 30
Example

OO Design 31
Example..
 Client directly calls methods on Printer1
 If another printer is to be allowed
 A new class Printer2 will be created
 But the client will have to be changed if it wants
to use Printer 2
 Alternative approach
 Have Printer1 a subclass of a general Printer
 For modification, add another subclass Printer 2
 Client does not need to be changed
OO Design 32
Example…

OO Design 33
Liskov’s Substitution Principle
 Principle: Program using object o1 of
base class C should remain unchanged
if o1 is replaced by an object of a
subclass of C
 If hierarchies follow this principle, the
open-closed principle gets supported

OO Design 34
Unified Modeling Language
(UML) and Modeling
 UML is a graphical notation useful for
OO analysis and design
 Allows representing various aspects of
the system
 Various notations are used to build
different models for the system
 OOAD methodologies use UML to
represent the models they create

OO Design 35
Modeling
 Modeling is used in many disciplines –
architecture, aircraft building, …
 A model is a simplification of reality
 “All models are wrong, some are useful”
 A good model includes those elts that
have broad effect and omits minor elts
 A model of a system is not the system!

OO Design 36
Why build models?
 Models help us visualize a system
 Help specify the system structure
 Gives us a template that can guide the
construction
 Document the decisions taken and their
rationale

OO Design 37
Modeling
 Every complex system requires multiple
models, representing diff aspects
 These models are related but can be
studied in isolation
 Eg. Arch view, electrical view, plumbing
view of a building
 Model can be structural, or behavioral

OO Design 38
Views in an UML
 A use case view
 A design view
 A process view
 Implementation view
 Deployment view

 We will focus primarily on models for design –

OO Design 40
Class Diagram…
 Class itself represented as a box with
name, attributes, and methods
 There are conventions for naming
 If a class is an interface, this can be
specified by <<interface>> stereotype
 Properties of attr/methods can be
specified by tags between { }

OO Design 41
Class – example

OO Design 42
Generalization-Specialization
 This relationship leads to class hierarchy
 Can be captured in a class diagram
 Arrows coming from the subclass to the
superclass with head touching super
 Allows multiple subclasses
 If specialization is done on the basis of
some discriminator, arrow can be labeled

OO Design 43
Example – class hierarchy

OO Design 44
Association/aggregation
 Classes have other relationships
 Association: when objects of a class need
services from other objects
 Shown by a line joining classes
 Multiplicity can be represented
 Aggregation: when an object is composed of
other objects
 Captures part-whole relationship
 Shown with a diamond connecting classes

OO Design 45
Example – association/aggregation

OO Design 46
Interaction Diagrams
 Class diagram represent static structure of
the system (classes and their rel)
 Do not model the behavior of system
 Behavioral view – shows how objects interact
for performing actions (typically a use case)
 Interaction is between objects, not classes
 Interaction diagram in two styles
 Collaboration diagram
 Sequence diagram
 Two are equivalent in power

OO Design 47
Sequence Diagram
 Objects participating in an interaction are
shown at the top
 For each object a vertical bar represents its
lifeline
 Message from an object to another,
represented as a labeled arrow
 If message sent under some condition, it can
be specified in bracket
 Time increases downwards, ordering of
events is captured

OO Design 48
Example – sequence diag.

OO Design 49
Collaboration diagram
 Also shows how objects interact
 Instead of timeline, this diagram looks
more like a state diagram
 Ordering of messages captured by
numbering them
 Is equivalent to sequence diagram in
modeling power

OO Design 50
Example – collaboration diag

OO Design 51
Other Diagrams
 Class diagram and interaction diagrams
most commonly used during design
 There are other diagrams used to build
different types of models

OO Design 52
State Diagrams
 Dynamic model to represent behavior of
an individual object or a system
 Shows the states of an object and
transitions between them
 Helps understand the object – focus
only on the important logical states
 State diagrams can be very useful for
automated and systematic testing

OO Design 53
State diagram of a stack

OO Design 54
Activity Diagrams
 Another method for modeling the
dynamic behavior
 Describes the sequence of activities,
and parallel behavior in a system
 Activity represented by ovals, dependence
shown by inputs/outputs
 Variant of a state diagram – captures
the state of the system and transitions

OO Design 55
Other Diagrams
 Instead of objects/classes, can represent
components, packages, subsystems
 These are useful for developing architecture
structures
 UML is extensible – can model a new but
similar concept by using stereotypes (by
adding <<name>>)
 Tagged values can be used to specify
additional properties, e.g. private, readonly..
 Notes can be added

OO Design 56
Other symbols

OO Design 57
Design using UML
 Many OOAD methodologies have been
proposed
 They provide some guidelines on the steps to
be performed
 Basic goal is to identify classes, understand
their behavior, and relationships
 Different UML models are used for this
 Often UML is used, methodologies are not
followed strictly

OO Design 58
Design using UML
 Basic steps
 Identify classes, attributes, and operations from
use cases
 Define relationships between classes
 Make dynamic models for key use cases and use
them to refine class diagrams
 Make a functional model and use it to refine the
classes
 Optimize and package
 Class diagrams play the central role; class
defn gets refined as we proceed

OO Design 59
Restaurant example: Initial classes

OO Design 60
OO Design 61
Restaurant example: a seq diag

OO Design 62
Metrics
 Weighted methods per class
 Complexity of a class depends on no of
classes and their complexity
 Suppose complexity of methods is c1, c2..;
by some functional complexity metric

WMC = Σ ci
 Large WMC might mean that the class is
more fault-prone

OO Design 63
Metrics…
 Depth of Inheritance Tree
 DIT of C is depth from the root class
 Length of the path from root to C
 DIT is significant in predicting fault
proneness
 Number of Children
 Immediate no of subclasses of C
 Gives a sense of reuse

OO Design 64
Metrics…
 Coupling between classes
 No of classes to which this class is coupled
 Two classes are coupled if methods of one
use methods or attr of other
 Can be determined from code
 (There are indirect forms of coupling that
cannot be statically determined)

OO Design 65
Metrics…
 Response for a class
 The total no of methods that can be invoked from
this class
 Captures the strength of connections
 Lack of cohesion in methods
 Two methods form a cohesive pair if they access
some common vars (form a non-cohesive pair if
no common var)
 LCOM is the number of method pairs that are non-
cohesive – the no of cohesive pairs

OO Design 66
Summary
 OO is a newer paradigm, slowly replacing the
functional approach
 OO models both data and functions
 UML is a notation that is used often to model
systems in an OO manner
 UML provides various diagrams for modeling
the structure, dynamic behavior, etc.
 Through UML modeling, design for the
system can be developed

OO Design 67