Object Oriented Design

OO Design

Object Orientation

Traditional procedural systems separate data and procedures, and model these separately Object orientation views data and functions 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 (requirements) as well as design The methods and notations are similar In Object Oriented Analysis (OOA) we model the problem, while in Object Oriented Deisgn (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

OO Concepts

Encapsulation grouping of related ideas into one unit which we can refer to by a single name

Eg. procedures, functions, packages

In OO, object is the unit; encapsulates state and provides interface to access and modify

OO Design

OO Concepts..

Information hiding use encapsulation to restrict external visibility OO encapsulates the data, provides limited access, visibility Information hiding can be provided without OO is an old concept

OO Design

OO Concepts

State retention functions, 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

OO Concepts..

Messages through which a sender object conveys to a target object a request For requesting O1

must have a handle for O2 name of the operation information on operations that O2 requires

General format O2.method(args)

OO Design

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

A class defines the attributes and operations 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

Used to modify attributes

OO Design 10

Inheritance

Inheritance is unique to OO

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 operations 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

Hierarchy Class Example

Attributes Subclass has access to these Operations Subclass has access to these

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 information through temporary variables 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 information being passed With only data being passed

I.e. methods should pass the least amount of data, with least number of parameters

OO Design

22

Coupling

Component coupling when a class A has variables of another class C

A has instance variables of C A has some parameters of type C A has a method with a local variable 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 variables and methods but does not modify any
OO Design 24

Cohesion

Cohesion is an intra-module concept Focuses on why elements are together

Only elements 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 different code elements are together in a method (like cohesion in functional modules)

Highest form is if each method implements a clearly defined function with all elements 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 different attributes and methods are together in a class

A class should represent a single concept with all elements contributing towards it Whenever multiple concepts encapsulated, cohesion is not as high A symptom of multiple concepts different groups of methods accessing different subsets of attributes

OO Design

27

Cohesion

Inheritance cohesion focuses on why classes are together in a hierarchy

Two reasons for subclassing

generalization-specialization reuse

Cohesion is higher if the hierarchy is for providing generalization-specialization

OO Design

28

Friday

OO Design

29

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 30

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 openclosed principle Consider example of a client object which interacts with a printer object for printing
OO Design 31

Example

OO Design

32

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 Have Printer1 a subclass of a general Printer For modification, add another subclass Printer 2 Client does not need to be changed
OO Design 33

Alternative approach

Example

OO Design

34

Liskovs 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

35

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

36

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 elements that have broad effect and omits minor elements A model of a system is not the system!
OO Design 37

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

38

Modeling

Every complex system requires multiple models, representing different aspects These models are related but can be studied in isolation Eg. Architecture view, electrical view, plumbing view of a building Model can be structural, or behavioral

OO Design

39

Views in an UML

Different views

A use case view A design view A process view Implementation view Deployment view

We will focus primarily on models for design

class diagram, interaction diagram, etc.

OO Design 40

Class Diagrams

Classes are the basic building blocks of an OO system as classes are the implementation units also Class diagram is the central piece in an OO design. It specifies

Classes in the system Association between classes Subtype, supertype relationship

OO Design

41

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 attributes/methods can be specified by tags between { }

OO Design

42

Class example

OO Design

43

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

44

Example class hierarchy

OO Design

45

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 46

Example association/aggregation

OO Design

47

Interaction Diagrams

Class diagrams represent static structure of the system (classes and their relationships) Do not model the behavior of system Behavioral view

Interaction is between objects, not classes Interaction diagram in two styles

shows how objects interact for performing actions (typically a use case)

Two are equivalent in power

OO Design 48

Collaboration diagram Sequence diagram

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 49

Example sequence diagram

Objects participating in an interaction

Time

OO Design

50

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

51

Example collaboration diag

OO Design

52

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

53

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

54

State diagram of a stack

push

pop

OO Design

55

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

56

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 57

Other symbols

OO Design

58

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 59

Design using UML

Basic steps

Class diagrams play the central role; class definition gets refined as we proceed
OO Design 60

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

Success Scenario

Customer read the menu Customer places the order Order is sent to the kitchen for preparation Ordered items are served Customer requests for a bill for the order Bill is prepared for this order Customer is given the bill Customer pays the bill
OO Design 61

Restaurant example: Initial classes

OO Design

62

OO Design

63

Restaurant example: a sequence diagram

OO Design

64

Example: Word Count Problem

System prompts for the file name; user enters the file name System checks for existence of file System reads the words from the file Systems prints the count

OO Design

65

Example: Word Count Problem

File

name
History addWord() exists() getword() isEof()

Counter count increment() display()

Word string setstring() getstring()

OO Design

66

Example: Word Count Problem

Read File

Get words

Check For Uniqueness

Increment Count

Add to History

OO Design

67

Monday

Object Oriented Design Covered concepts

Covered constraints

Classes and objects Encapsulation State, behavior, identity Relationships among objects Inheritance and polymorphism Coupling Cohesion

Covered tools

Class diagrams Sequence diagrams

OO Design

68

Metrics

Weighted Methods per Class (WMC)

Complexity of a class depends on number of classes and their complexity

Suppose class C has methods M1, M2, , Mn Suppose complexity of methods is c1, c2 determined by some functional complexity metric WMC = ci If the complexity of each method is considered 1, WMC gives the total number of methods in the class

Large WMC might mean that the class is more fault-prone

OO Design 69

Metrics

The deeper a class is in a class hierarchy

More methods to reuse larger reuse potential Increased coupling harder to make change
DIT of class C in an inheritance hierarchy tree is depth from the root class

Depth of Inheritance (DIT) Tree

Shortest path from root to node C

DIT is significant in predicting fault proneness

OO Design 70

Metrics

Number of Children (NOC)

Number of immediate subclasses of C Evaluates the degree of reuse Higher NOC indicates reuse of definitions in superclass by a larger number of subclasses Indicates influence of a class on other elements

Larger influence, more important to get design correct

Higher NOC classes are less defect-prone

NOC is only measuring structure, not inheritance
OO Design 71

Metrics

Coupling Between Classes (CBC)

Reduces modularity and makes module modification harder CBC = Number of classes to which this class is coupled

Two classes are coupled if methods of one use methods or instance variables of other There are indirect forms of coupling that cannot be statically determined (e.g., pointers)

Can be determined from code

Can predict fault proneness of classes, particular user interface classes

OO Design 72

Metrics

Response for a Class (RFC)

The total number of methods that can be invoked from an object of this class RFC of C is cardinality of the response set for a class

Set of all methods that can be invoked if a message is sent to an object of this class

All methods of C as well as other classes the methods of C send messages

Even if CBC of a class is 1, RBC may be high

Captures the strength of connections Harder to test classes with high RFC
OO Design 73

Metrics

Lack of Cohesion in Methods (LCOM)

Cohesion captures how close are different methods of a class bound

Two methods form a cohesive pair if they access some common variables Form a non-cohesive pair if no common variables High cohesion is highly desirable

LCOM is the number of method pairs that are noncohesive minus the number of cohesive pairs Not significant in predicting fault tolerance of a class

OO Design

74

Metrics Studies Show

Weighted Methods per Class (WMC)

Classes tend to have only small number of methods

Depth of Inheritance (DIT)

Has a reasonable correlation with fault-proneness of a class Classes tend to be close to the root

Classes are simple and provide some specific abstraction and operations Only few classes have many methods defined in them

Number of Children (NOC)

Designers tend to keep the number of abstraction levels small, i.e., they give up reusability in favor of comprehensibility Classes generally had a smaller NOC value with most having 0 Inheritance was not used very heavily
OO Design 75

Max DIT around 10 Most classes have DIT of 0 (they are the root)

Metrics Studies Show

Coupling Between Classes (CBC)

Most classes are self contained with CBC = 0

Not coupled with any other class

Interface objects tend to have higher CBC Most classes tend to invoke a small number of methods of other classes Classes for interface objects tend to have higher RFC Not very good at predicting fault-proneness
OO Design 76

Response for a Class (RFC)

Lack of Cohesion in Methods (LCOM)

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 Metrics can help predict fault proneness of design
OO Design 77

Example OO Design PIMS Personal Investment System

Help investors keep track of their investments Determine rate of return

On individual investments On overall portfolio

Determine net worth of portfolios

OO Design

78

Example OO Design PIMS

Investor can have many portfolios Portfolio can have many investments Investor can invest and withdraw any amount of money at any time

Get current value of each investment from Web site Invest in instruments with fixed interest rates

Dates and amounts are tracked by PIMS

Save information about the portfolio Edit entered data View any portfolio

Alert to notify pending maturity dates

Provide security Determine rate of return

Summary Detailed

For each investment Overall for each portfolio Total investments Compute on monthly basis
OO Design 79

Example OO Design PIMS Basic Classes

Class Investment Portfolio Security Transaction GUI Principle Responsibility Manages computations regarding total investment. Manages computations regarding a Portfolio. Manages computations related to a security. Manages computations and stores attributes related to a transaction. Manages the Graphical User Interface.

NetLoader
Current Value System

Manages downloading current prices of shares from the Internet.

Manages current value of shares.

Alerts
SecurityManager DataRepository

Manages alerts.
Manages user validation. Manages all file operations. It is an interface between the main modules and the database (which in our case is done using file system.)
OO Design 80

Example OO Design PIMS Inheritance Structure

Two kinds of securities Bank: interest bearing Shares: trading/dividends

Two kinds of transactions buy: exchange cash for security sell: exchange security for cash
OO Design 81

Example OO Design PIMS Aggregation Structure

An investment consists of many portfolios

A portfolio can consist of many different securities

Many transactions can act on a single security

OO Design

82

Example OO Design PIMS Class Diagram

Investment

1 m

Transaction
m

Portfolio

1 m

Security
1

Debit

Credit

Bank Deposit

Shares

OO Design

83

Example OO Design PIMS associations for action Create/Delete/Edit Transaction

OO Design

84

Example OO Design PIMS Class diagram with all classes and associations

OO Design

85

Example OO Design PIMS Basic Actions

Actions Create/Delete/Rename Portfolio/Security. Create/Delete/Edit Transactions. Calculate Net Worth of Investment/Portfolio/ Security.

Calculate Rate of Investment of a security.

Load Current Prices from the Internet. Check/Set/Delete Alerts. Validate User.
OO Design 86

Example OO Design PIMS Sequence diagram for principle action Create Portfolio

OO Design

87

Example OO Design PIMS Sequence diagram for principle action Delete Transaction

OO Design

88

Example OO Design PIMS Sequence diagram for action Compute Net Worth of Investment/Portfolio/Security

OO Design

89

Example OO Design PIMS Sequence diagram for action Compute ROI

OO Design

90

Example OO Design PIMS Sequence diagram for action Load current prices from the Internet

OO Design

91

Example OO Design PIMS Sequence diagram for action Set/Check/Delete Alerts

OO Design

92

Example OO Design PIMS Sequence diagram for action Validate User

OO Design

93