Software Design
Upcoming SlideShare
Loading in...5

Software Design






Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Microsoft PowerPoint

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.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment
  • © SE, Design, Hans van Vliet The resulting design description fakes the actual process followed.
  • © SE, Design, Hans van Vliet Mention another important article by David Parnas
  • © SE, Design, Hans van Vliet In the slides, we only discuss JSP. JSD is of historical interest, but little used now
  • © SE, Design, Hans van Vliet
  • © SE, Design, Hans van Vliet

Software Design Software Design Presentation Transcript

  • SOFTWARE DESIGN Present by : Bui, Ninh L.
  • OVERVIEW  Design principles  Design methods 2
  • DESIGN PRINCIPLES 3  Abstraction  Modularity, coupling and cohesion  Information hiding  Limit complexity  Hierarchical structure
  • ABSTRACTION  procedural abstraction: natural consequence of stepwise refinement: name of procedure denotes sequence of actions 4 abstraction subproblems time
  • ABSTRACTION  data abstraction: aimed at finding a hierarchy in the data 5 application-oriented data structures simpler data structuregeneral data structures
  • MODULARITY  structural criteria which tell us something about individual modules and their interconnections  cohesion and coupling  cohesion: the glue that keeps a module together  coupling: the strength of the connection between modules 6
  • TYPES OF COHESION 7  coincidental cohesion  logical cohesion  temporal cohesion  communicational cohesion  procedural cohesion  sequential cohesion  functional cohesion lowest and worst by far still not bad at all still not bad at all not bad at all still ok ok high and best
  • EXAMPLE FOR COHESION Staff Checkemail() Sendemail() Emailvalidate() Printletter() 8 Staff Salary Emailaddr Setsalary(newsalary) Getsalary() Setemailaddr(newemail) Getemailaddr() Example of Low Cohesion: Example of high Cohesion: Cohesion refers to what the class (or module) will do. Low cohesion would mean that the class does a great variety of actions and is not focused on what it should do. High cohesion would then mean that the class is focused on what it should be doing, i.e. only methods relating to the intention of the class.
  • TYPES OF COUPLING 9  Data coupling  Stamp coupling  Control coupling  External coupling  Common coupling  Content coupling loose and best still very good ok ok very bad tight and worst
  • INFORMATION HIDING 10  each module has a secret  design involves a series of decision: for each such decision, wonder who needs to know and who can be kept in the dark  information hiding is strongly related to  abstraction: if you hide something, the user may abstract from that fact  coupling: the secret decreases coupling between a module and its environment  cohesion: the secret is what binds the parts of the module together
  • COMPLEXITY  measure certain aspects of the software (lines of code, # of if-statements, depth of nesting, …)  use these numbers as a criterion to assess a design, or to guide the design  interpretation: higher value ⇒ higher complexity ⇒ more effort required (= worse design)  two kinds:  intra-modular: inside one module  inter-modular: between modules 11
  • OBJECT-ORIENTED METRICS 12  WMC: Weighted Methods per Class  DIT: Depth of Inheritance Tree  NOC: Number Of Children  CBO: Coupling Between Object Classes  RFC: Response For a Class  LCOM: Lack of Cohesion of a Method
  • DEPTH OF CLASS IN INHERITANCE TREE  DIT = distance of class to root of its inheritance tree  DIT is somewhat language-dependent  widely accepted heuristic: strive for a forest of classes, a collection of inheritance trees of medium height 13 Department StoreDepartments manager Employees display() credit() Clothing customer_gender size_range exchange() Appliances Category delivery() service() parts_ordering() DIT (Appliances) =2 DIT(StoreDepartments)=1 DIT(Department)=0
  • NUMBER OF CHILDREN 14  NOC: counts immediate descendants  higher values NOC are considered bad:  possibly improper abstraction of the parent class  also suggests that class is to be used in a variety of settings NOC(Division) = 1 NOC(StoreDepartments)= 2 NOC(Appliances)= 0 Division StoreDepartments manager Employees display() credit() Clothing customer_gender size_range exchange() Appliances Category delivery() service() parts_ordering()
  • OVERVIEW  Design principles  Design methods 15
  • DESIGN METHODS  Functional decomposition  Data Flow Design (SA/SD)  Design based on Data Structures (JSP)  Ojbject-Oriented method 16
  • SAMPLE OF DESIGN METHODS 17  Decision tables  E-R  Flowcharts  FSM  JSD  JSP  LCP  Meta IV  NoteCards  OBJ  OOD  PDL  Petri Nets  SA/SD  SA/WM  SADT  SSADM  Statecharts
  • FUNCTIONAL DECOMPOSITION 18 bottom-up top-down
  • FUNCTIONAL DECOMPOSITION (CNT’D)  Extremes: bottom-up and top-down  Not used as such; design is not purely rational:  clients do not know what they want  changes influence earlier decisions  people make errors  projects do not start from scratch  Rather, design has a yo-yo character  We can only fake a rational design process 19
  • DATA FLOW DESIGN  Yourdon and Constantine (early 70s)  nowadays version: two-step process:  Structured Analysis (SA), resulting in a logical design, drawn as a set of data flow diagrams  Structured Design (SD) transforming the logical design into a program structure drawn as a set of structure charts 20
  • ENTITIES IN A DATA FLOW DIAGRAM  external entities  processes  data flows  data stores 21
  • DESIGN BASED ON DATA STRUCTURES (JSP )  JSP = Jackson Structured Programming (for programming-in-the-small) 22
  • JSP  basic idea: good program reflects structure of its input and output  program can be derived almost mechanically from a description of the input and output  input and output are depicted in a structure diagram and/or in structured text/schematic logic (a kind of pseudocode)  three basic compound forms: sequence, iteration, and selection) 23
  • COMPOUND COMPONENTS IN JSP 24 A B C D sequence B A * iteration B C D A o o o selection
  • DIFFERENCE BETWEEN JSP AND OTHER METHODS  Functional decomposition, data flow design: Problem structure ⇒ functional structure ⇒ program structure  JSP: Problem structure ⇒ data structure ⇒ program structure 25
  • 26 OOAD METHODS  three major steps: 1 identify the objects 2 determine their attributes and services 3 determine the relationships between objects
  • 27 (PART OF) PROBLEM STATEMENT Design the software to support the operation of a public library. The system has a number of stations for customer transactions. These stations are operated by library employees. When a book is borrowed, the identification card of the client is read. Next, the station’s bar code reader reads the book’s code. When a book is returned, the identification card isnot needed and only the book’s code needs to be read.
  • 28 CANDIDATE OBJECTS  software  library  system  station  customer  transaction  book  library employee  identification card  client  bar code reader  book’s code
  • 29 RELATIONSHIPS  From the problem statement:  employee operates station  station has bar code reader  bar code reader reads book copy  bar code reader reads identification card  Tacit knowledge:  library owns computer  library owns stations  computer communicates with station  library employs employee  client is member of library  client has identification card
  • CAVEATS WHEN CHOOSING A PARTICULAR DESIGN METHOD  Familiarity with the problem domain  Designer’s experience  Available tools  Development philosophy 32
  • DESIGN PATTERN 33  Provides solution to a recurring problem  Balances set of opposing forces  Documents well-prove design experience  Abstraction above the level of a single component  Provides common vocabulary and understanding  Are a means of documentation  Supports construction of software with defined properties
  • EXAMPLE DESIGN PATTERN: PROXY  Context:  Client needs services from other component, direct access may not be the best approach  Problem:  We do not want hard-code access  Solution:  Communication via a representative, the Proxy 34
  • THANK YOU! 35