Top Banner
OO Design 1 Object Oriented Design
93
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: 7 ooad

OO Design 1

Object Oriented Design

Page 2: 7 ooad

OO Design 2

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

Page 3: 7 ooad

OO Design 3

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

Page 4: 7 ooad

OO Design 4

OOA and OOD…

Page 5: 7 ooad

OO Design 5

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

Page 6: 7 ooad

OO Design 6

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

Page 7: 7 ooad

OO Design 7

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

Page 8: 7 ooad

OO Design 8

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)

Page 9: 7 ooad

OO Design 9

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

Page 10: 7 ooad

OO Design 10

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

Page 11: 7 ooad

OO Design 11

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

Page 12: 7 ooad

OO Design 12

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

Page 13: 7 ooad

OO Design 13

Inheritance…

Page 14: 7 ooad

OO Design 14

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

Page 15: 7 ooad

OO Design 15

Hierarchy Class Example

Attributes Subclass has access to these

Operations Subclass has access to these

Page 16: 7 ooad

OO Design 16

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

Page 17: 7 ooad

OO Design 17

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

Page 18: 7 ooad

OO Design 18

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

Page 19: 7 ooad

OO Design 19

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

Page 20: 7 ooad

OO Design 20

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

Page 21: 7 ooad

OO Design 21

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

Page 22: 7 ooad

OO Design 22

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

Page 23: 7 ooad

OO Design 23

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

Page 24: 7 ooad

OO Design 24

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

Page 25: 7 ooad

OO Design 25

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

Page 26: 7 ooad

OO Design 26

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

Page 27: 7 ooad

OO Design 27

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

Page 28: 7 ooad

OO Design 28

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

Page 29: 7 ooad

OO Design 29

Friday

Page 30: 7 ooad

OO Design 30

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

Page 31: 7 ooad

OO Design 31

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

Page 32: 7 ooad

OO Design 32

Example

Page 33: 7 ooad

OO Design 33

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

Page 34: 7 ooad

OO Design 34

Example…

Page 35: 7 ooad

OO Design 35

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

Page 36: 7 ooad

OO Design 36

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

Page 37: 7 ooad

OO Design 37

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!

Page 38: 7 ooad

OO Design 38

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

Page 39: 7 ooad

OO Design 39

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

Page 40: 7 ooad

OO Design 40

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.

Page 41: 7 ooad

OO Design 41

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

Page 42: 7 ooad

OO Design 42

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 { }

Page 43: 7 ooad

OO Design 43

Class – example

Page 44: 7 ooad

OO Design 44

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

Page 45: 7 ooad

OO Design 45

Example – class hierarchy

Page 46: 7 ooad

OO Design 46

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

Page 47: 7 ooad

OO Design 47

Example – association/aggregation

Page 48: 7 ooad

OO Design 48

Interaction Diagrams Class diagrams represent static structure

of the system (classes and their relationships)

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

Page 49: 7 ooad

OO Design 49

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

Page 50: 7 ooad

OO Design 50

Example – sequence diagram

Tim

e

Objects participating in an interaction

Page 51: 7 ooad

OO Design 51

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

Page 52: 7 ooad

OO Design 52

Example – collaboration diag

Page 53: 7 ooad

OO Design 53

Other Diagrams

Class diagram and interaction diagrams most commonly used during design

There are other diagrams used to build different types of models

Page 54: 7 ooad

OO Design 54

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

Page 55: 7 ooad

OO Design 55

State diagram of a stack

push

pop

Page 56: 7 ooad

OO Design 56

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

Page 57: 7 ooad

OO Design 57

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

Page 58: 7 ooad

OO Design 58

Other symbols

Page 59: 7 ooad

OO Design 59

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

Page 60: 7 ooad

OO Design 60

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 definition gets refined as we proceed

Page 61: 7 ooad

OO Design 61

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

Page 62: 7 ooad

OO Design 62

Restaurant example: Initial classes

Page 63: 7 ooad

OO Design 63

Page 64: 7 ooad

OO Design 64

Restaurant example: a sequence diagram

Page 65: 7 ooad

OO Design 65

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

Page 66: 7 ooad

OO Design 66

Example: Word Count Problem…

History

addWord()

exists()

File

name

getword()isEof()

Word

string

setstring()getstring()

Counter

count

increment()display()

Page 67: 7 ooad

OO Design 67

Example: Word Count Problem…

ReadFile

Getwords

CheckFor

Uniqueness

Add to History

IncrementCount

Page 68: 7 ooad

OO Design 68

Monday

Object Oriented Design Covered concepts

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

Covered constraints Coupling Cohesion

Covered tools Class diagrams Sequence diagrams

Page 69: 7 ooad

OO Design 69

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

Page 70: 7 ooad

OO Design 70

Metrics…

The deeper a class is in a class hierarchy More methods to reuse – larger reuse

potential Increased coupling – harder to make change

Depth of Inheritance (DIT) Tree DIT of class C in an inheritance hierarchy

tree is depth from the root class Shortest path from root to node C

DIT is significant in predicting fault proneness

Page 71: 7 ooad

OO Design 71

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

Page 72: 7 ooad

OO Design 72

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 Can be determined from code

There are indirect forms of coupling that cannot be statically determined (e.g., pointers)

Can predict fault proneness of classes, particular user interface classes

Page 73: 7 ooad

OO Design 73

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

Page 74: 7 ooad

OO Design 74

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 non-cohesive minus the number of cohesive pairs

Not significant in predicting fault tolerance of a class

Page 75: 7 ooad

OO Design 75

Metrics Studies Show Weighted Methods per Class (WMC)

Classes tend to have only small number of methods Classes are simple and provide some specific abstraction and

operations Only few classes have many methods defined in them

Has a reasonable correlation with fault-proneness of a class Depth of Inheritance (DIT)

Classes tend to be close to the root Max DIT around 10 Most classes have DIT of 0 (they are the root)

Designers tend to keep the number of abstraction levels small, i.e., they give up reusability in favor of comprehensibility

Number of Children (NOC) Classes generally had a smaller NOC value with most

having 0 Inheritance was not used very heavily

Page 76: 7 ooad

OO Design 76

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

Response for a Class (RFC) Most classes tend to invoke a small number of

methods of other classes Classes for interface objects tend to have higher

RFC Lack of Cohesion in Methods (LCOM)

Not very good at predicting fault-proneness

Page 77: 7 ooad

OO Design 77

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

Page 78: 7 ooad

OO Design 78

Example OO Design – PIMSPersonal Investment System

Help investors keep track of their investments

Determine rate of return On individual investments On overall portfolio

Determine net worth of portfolios

Page 79: 7 ooad

OO Design 79

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

Dates and amounts are tracked by PIMS Get current value of each investment from Web site Invest in instruments with fixed interest rates

Alert to notify pending maturity dates Save information about the portfolio Edit entered data View any portfolio

Summary Detailed

Provide security Determine rate of return

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

Page 80: 7 ooad

OO Design 80

Example OO Design – PIMS…Basic Classes

Class Principle Responsibility

Investment Manages computations regarding total investment.

Portfolio Manages computations regarding a Portfolio.

Security Manages computations related to a security.

Transaction Manages computations and stores attributes related to a transaction.

GUI Manages the Graphical User Interface.

NetLoader Manages downloading current prices of shares from the Internet.

Current Value System

Manages current value of shares.

Alerts Manages alerts.

SecurityManager

Manages user validation.

DataRepository

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

Page 81: 7 ooad

OO Design 81

Example OO Design – PIMS…Inheritance Structure

Two kinds of securitiesBank: interest bearingShares: trading/dividends

Two kinds of transactionsbuy: exchange cash for securitysell: exchange security for cash

Page 82: 7 ooad

OO Design 82

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

Page 83: 7 ooad

OO Design 83

Example OO Design – PIMS…Class Diagram

Investment

Portfolio

Security

Bank Deposit Shares

Transaction

Debit Credit

1

m

1

m

1

m

Page 84: 7 ooad

OO Design 84

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

Page 85: 7 ooad

OO Design 85

Example OO Design – PIMS…Class diagram with all classes and associations

Page 86: 7 ooad

OO Design 86

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.

Page 87: 7 ooad

OO Design 87

Example OO Design – PIMS…Sequence diagram for principle action Create Portfolio

Page 88: 7 ooad

OO Design 88

Example OO Design – PIMS…Sequence diagram for principle action Delete Transaction

Page 89: 7 ooad

OO Design 89

Example OO Design – PIMS…Sequence diagram for action Compute Net Worth ofInvestment/Portfolio/Security

Page 90: 7 ooad

OO Design 90

Example OO Design – PIMS…Sequence diagram for action Compute ROI

Page 91: 7 ooad

OO Design 91

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

Page 92: 7 ooad

OO Design 92

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

Page 93: 7 ooad

OO Design 93

Example OO Design – PIMS…Sequence diagram for action Validate User