Lecture02
Upcoming SlideShare
Loading in...5
×
 

Lecture02

on

  • 1,291 views

Introduction to Software Design

Introduction to Software Design

Statistics

Views

Total Views
1,291
Views on SlideShare
1,286
Embed Views
5

Actions

Likes
0
Downloads
97
Comments
0

2 Embeds 5

http://hijjawitech.blogspot.com 4
http://www.slashdocs.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Lecture02 Lecture02 Presentation Transcript

  • Computer Engineering DepartmentObject Oriented Software Modeling and Design g CE 350 Abdel-Karim Al-Tamimi, Ph.D. altamimi@yu.edu.jo http://faculty.yu.edu.jo/altamimi Al-Tamimi 2011 © 1
  • Overview• Introduction to Software Design Al-Tamimi 2011 © 2
  • 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
  • Software Life CycleFeasibility Study Requirement Analysis q y Design Coding Testing Maintenance Al-Tamimi 2011 © 4
  • Relative Effort to Phases Al-Tamimi 2011 © 5
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • Dependency Inversion Principle Copy Copy VS. Reader WriterReadKeyboard WritePRinter × KeyboardReader PrinterWriter Al-Tamimi 2011 © 21
  • 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
  • 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