Lecture02

Computer Engineering Department

Object Oriented Software Modeling and Design g

CE 350Abdel-Karim Al-Tamimi, Ph.D.

[email protected]@yu.edu.jo

http://faculty.yu.edu.jo/altamimi

Al-Tamimi 2011 © 1

OverviewOverview

• Introduction to Software Design Introduction to Software Design

Al-Tamimi 2011 © 2

Software DesignSoftware Design

• Design phase is one of the most important Design phase is one of the most important phases in the product development process (A K A software life cycle) process (A.K.A. software life cycle)

• After gathering the required information about the project you are usually required about the project, you are usually required to design the product (software) taking into consideration its requirements and to into consideration its requirements and to minimize the need to redo the work if changes needed to be made in the futurechanges needed to be made in the future

Al-Tamimi 2011 © 3

Software Life CycleSoftware Life Cycle

Feasibility Study

Requirement Analysisq y

Design

Coding

Testing

Maintenance

Al-Tamimi 2011 © 4

Relative Effort to PhasesRelative Effort to Phases

Al-Tamimi 2011 © 5

Design PhaseDesign Phase

• Transform requirements in the SRS document Transform requirements in the SRS document into a possible implementation

• Using either Traditional or Object oriented g bjapproaches

• Object-oriented approach:j pp– System objects are first identified

– The relationship between these objects are then d f d d d didentified and documented

– Less development time and efforts

Better maintainability of the product– Better maintainability of the product

Al-Tamimi 2011 © 6

Why We Need A Good Design?Why We Need A Good Design?

• If we do not follow a proper design scheme, our If we do not follow a proper design scheme, our product may :

• Become rigidg– Rigidity is the inability to be changed

• Become fragileg– Software changes seem to exhibit non-local effects

• Become non-reusable

• Have high viscosity (glueyness) – Viscosity is resistance to fluid motion

Al-Tamimi 2011 © 7

Rigid DesignRigid Design

• The impact of a change cannot be The impact of a change cannot be predicted

• If not predicted it cannot be estimated• If not predicted, it cannot be estimated

• Time and cost cannot be quantified

• Managers become reluctant to authorize change

Al-Tamimi 2011 © 8

Fragile DesignFragile Design

• A single change requires a cascade of A single change requires a cascade of subsequent changes

• New errors appear in areas that seem • New errors appear in areas that seem unconnected to the changed areas

Q li i di bl• Quality is unpredictable.

• The development team loses credibility

Al-Tamimi 2011 © 9

Non-Reusable DesignNon Reusable Design

• Desirable parts of the Desirable parts of the design are dependent upon undesirable parts

• The work and risk of extracting the desirable part may exceed the cost of exceed the cost of redeveloping from scratchscratch

10Al-Tamimi 2011 ©

High Viscous DesignHigh Viscous Design

• When the “right changes” are much more When the right changes are much more difficult than hacking, the viscosity of the system is highsystem is high

• Over time, it will become increasingly difficult to continue developing the difficult to continue developing the product

Al-Tamimi 2011 © 11

Design PrinciplesDesign Principles

• SOLID:SOLID:

• SRP: The Single Responsibility Principle

OCP Th O /Cl d P i i l• OCP: The Open/Closed Principle

• LSP: The Liskov Substitution Principle

• ISP: The Interface Segregation Principle

• DIP: The Dependency Inversion PrincipleDIP: The Dependency Inversion Principle


SRP Principle : Single ibiliResponsibility

• A class should have one, and only one, reason to A class should have one, and only one, reason to change

• If a class assumes more than one responsibility, then there will be more than one reason for it to change

• If a class has more then one responsibility, then the ibiliti b l dresponsibilities become coupled

• Changes to one responsibility may impair or inhibit the class’ ability to meet the othersthe class ability to meet the others

• This kind of coupling leads to fragile designs that break in unexpected ways when changedp y g


Open/Closed PrincipleOpen/Closed Principle

• A principle which states that we should A principle which states that we should add new functionality by adding new code, not by editing old codenot by editing old code

• Defines a lot of the value of OO programmingprogramming– “all member variables should be private”

“ l b l i bl h ld b id d”– or “global variables should be avoided”

• Abstraction is the key


AbstractionAbstraction

• Abstraction is the most important word in OOD

• Client/Server l ti hi “ ”

Client Server

relationships are “open”

• Changes to servers cause changes to clients

Client AbstractServerc a ges to c e ts

• Abstract servers “close” clients to changes in i l t ti C timplementation Concrete

Server

15Al-Tamimi 2011 ©

Liskov Substitution PrincipleLiskov Substitution Principle

• LSP: Derived classes must be usable through the LSP: Derived classes must be usable through the base class interface, without the need for the user to know the difference

• All derived classes must be substitutable for their base classes

• This principle guides us in the creation of abstractions

• Question: Can we consider a square class a substitute of a rectangle class ?


Interface Segregation PrincipleInterface Segregation Principle

• Sometimes class methods have various Sometimes class methods have various groupings

• These classes are used for different • These classes are used for different purposes

N ll l ll h d• Not all users rely upon all methods

• This lack of cohesion can cause serious dependency problems

• These problems can be refactored awayp y


ATM User Interface (UI) lExample

TransferDepositWithdraw

«interface»ATM UI

+ GetWithdrawAmountAndAccount()+ GetDepositAmountAndAccount()+ GetTransferAmountAndAccounts()

French ATM UI English ATM UI



A Segregated ATM UI lExample

TransferWithdrawDepositp

ATM Transfer UIATM Deposit UI«interface» «interface»«interface»

ATM Transfer UIATM Withdraw UIATM Deposit UI

+ GetDepositAmountAndAccount() + GetWithdrawAmountAndAccount + GetTransferAmountAndAccounts()

«interface»ATM UI

+ GetWithdrawAmountAndAccount()+ GetWithdrawAmountAndAccount()+ GetDepositAmountAndAccount()+ GetTransferAmountAndAccounts()



Dependency Inversion PrincipleDependency Inversion Principle

• Details should depend on abstractionsDetails should depend on abstractions

• Abstractions should not depend on details

A id d i i f l• Avoid deriving from concrete classes

• Avoid associating to concrete classes

• Avoid aggregating concrete classes

• Avoid dependencies on concrete Avoid dependencies on concrete components

• There are some reasons to violate this • There are some reasons to violate this principle Al-Tamimi 2011 © 20

Dependency Inversion PrincipleDependency Inversion Principle

Copy

Copy

VS.

ReadKeyboard WritePRinter

Reader Writer

KeyboardReader PrinterWriter

21Al-Tamimi 2011 ©

×

ResourcesResources

• Matt Weisfeld The Object Oriented Matt Weisfeld, The Object Oriented Thought Process, Sams Publishing, ISBN:0-672-32611-6 ISBN:0 672 32611 6

• M. Jesse, “UML 2.0 for dummies”, ISBN:0764526146ISBN:0764526146

• P. Kimmel, “UML Demystified”, McGraw Hill ISBN 86Hill, ISBN: 0-07-148671-2

• Advanced Principles Of Class Design, http://www.objectmentor.com

22Al-Tamimi 2011 ©

ResourcesResources

• http://www.objectmentor.com/resources/articlehttp://www.objectmentor.com/resources/articles/ocp.pdf

• http://www.objectmentor.com/resources/articlep // bj / /s/srp.pdf

• http://www.objectmentor.com/resources/articlep // j / /s/lsp.pdf

• http://www.objectmentor.com/resources/articles/isp.pdf

• http://www.objectmentor.com/resources/articles/dip.pdf


Lecture02

Education

product altamimi

joaltamimi altamimi

future altamimi

software designaltamimi

abdelkarim altamimi

changedp yg altamimi

d changes

d principle lsp