Mais conteúdo relacionado
Semelhante a Lecture02 (20)
Lecture02
- 3. Software Design
• Design phase is one of the most important
phases in the product development
process (A.K.A. software life cycle)
(A K A
• After gathering the required information
about the project, you are usually required
project
to design the product (software) taking
into consideration its requirements and to
minimize the need to redo the work if
changes needed to be made in the future
Al-Tamimi 2011 © 3
- 6. Design Phase
• Transform requirements in the SRS document
into a possible implementation
• Using either Traditional or Object oriented
g bj
approaches
• Object-oriented approach:
j pp
– System objects are first identified
– The relationship between these objects are then
identified and d
d f d d documented d
– Less development time and efforts
– Better maintainability of the product
Al-Tamimi 2011 © 6
- 7. Why We Need A Good Design?
• If we do not follow a proper design scheme, our
product may :
g
• Become rigid
– Rigidity is the inability to be changed
• Become fragile
g
– 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
- 8. Rigid Design
• The impact of a change cannot be
predicted
• If not predicted, it cannot be estimated
predicted
• Time and cost cannot be quantified
• Managers become reluctant to authorize
change
Al-Tamimi 2011 © 8
- 9. Fragile Design
• A single change requires a cascade of
subsequent changes
• New errors appear in areas that seem
unconnected to the changed areas
• Q li i unpredictable.
Quality is di bl
• The development team loses credibility
Al-Tamimi 2011 © 9
- 10. Non-Reusable Design
Non Reusable
• Desirable parts of the
design are dependent
upon undesirable
parts
• The work and risk of
extracting the
desirable part may
exceed the cost of
redeveloping from
scratch
Al-Tamimi 2011 © 10
- 11. High Viscous Design
• When the “right changes are much more
right changes”
difficult than hacking, the viscosity of the
system is high
• Over time, it will become increasingly
difficult to continue developing the
product
Al-Tamimi 2011 © 11
- 12. Design Principles
• SOLID:
• SRP: The Single Responsibility Principle
• OCP: The Open/Closed P i i l
OCP Th O /Cl d Principle
• LSP: The Liskov Substitution Principle
• ISP: The Interface Segregation Principle
• DIP: The Dependency Inversion Principle
Al-Tamimi 2011 © 12
- 13. SRP Principle : Single
ibili
Responsibility
• 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
responsibilities b
ibiliti become coupled l d
• Changes to one responsibility may impair or inhibit
the class’ ability to meet the others
class
• This kind of coupling leads to fragile designs that
break in unexpected ways when changed
p y g
Al-Tamimi 2011 © 13
- 14. Open/Closed Principle
• A principle which states that we should
add new functionality by adding new code,
not by editing old code
• Defines a lot of the value of OO
programming
– “all member variables should be private”
– or “ l b l variables should be avoided”
“global i bl h ld b id d”
• Abstraction is the key
Al-Tamimi 2011 © 14
- 15. Abstraction
• Abstraction is the most
important word in OOD Client Server
• Client/Server
relationships are “
l ti hi “open””
• Changes to servers cause Abstract
Client
c a ges clients
changes to c e ts Server
• Abstract servers “close”
clients to changes in
implementation
i l t ti Concrete
C t
Server
Al-Tamimi 2011 © 15
- 16. Liskov Substitution Principle
• 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 ?
Al-Tamimi 2011 © 16
- 17. Interface Segregation Principle
• Sometimes class methods have various
groupings
• These classes are used for different
purposes
• N all users rely upon all methods
Not ll l ll h d
• This lack of cohesion can cause serious
dependency problems
• These problems can be refactored away
p y
Al-Tamimi 2011 © 17
- 18. ATM User Interface (UI)
Example l
Withdraw Deposit Transfer
«interface»
ATM UI
+ GetWithdrawAmountAndAccount()
+ GetDepositAmountAndAccount()
+ GetTransferAmountAndAccounts()
French ATM UI English ATM UI
Al-Tamimi 2011 © 18
- 19. A Segregated ATM UI
Examplel
Deposit
p Withdraw Transfer
«interface» «interface» «interface»
ATM Deposit UI ATM Withdraw UI ATM Transfer UI
+ GetDepositAmountAndAccount() + GetWithdrawAmountAndAccount + GetTransferAmountAndAccounts()
«interface»
ATM UI
+ GetWithdrawAmountAndAccount()
+ GetDepositAmountAndAccount()
+ GetTransferAmountAndAccounts()
French ATM UI English ATM UI
Al-Tamimi 2011 © 19
- 20. Dependency Inversion Principle
• Details should depend on abstractions
• Abstractions should not depend on details
• Avoid d i i from concrete classes
A id deriving f l
• Avoid associating to concrete classes
• Avoid aggregating concrete classes
• Avoid dependencies on concrete
components
• There are some reasons to violate this
principle Al-Tamimi 2011 © 20
- 22. Resources
• Matt Weisfeld, The Object Oriented
Weisfeld
Thought Process, Sams Publishing,
ISBN:0 672 32611 6
ISBN:0-672-32611-6
• M. Jesse, “UML 2.0 for dummies”,
ISBN:0764526146
• P. Kimmel, “UML Demystified”, McGraw
Hill, ISBN:
Hill ISBN 0-07-148671-2
86
• Advanced Principles Of Class Design,
http://www.objectmentor.com
Al-Tamimi 2011 © 22
- 23. Resources
• http://www.objectmentor.com/resources/article
s/ocp.pdf
• http://www.objectmentor.com/resources/article
p // bj / /
s/srp.pdf
• http://www.objectmentor.com/resources/article
p // j / /
s/lsp.pdf
• http://www.objectmentor.com/resources/article
s/isp.pdf
• http://www.objectmentor.com/resources/article
s/dip.pdf
Al-Tamimi 2011 © 23
