Software Design

878
-1

Published on

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
878
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
43
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • © 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

    1. 1. SOFTWARE DESIGN Present by : Bui, Ninh L.
    2. 2. OVERVIEW  Design principles  Design methods 2
    3. 3. DESIGN PRINCIPLES 3  Abstraction  Modularity, coupling and cohesion  Information hiding  Limit complexity  Hierarchical structure
    4. 4. ABSTRACTION  procedural abstraction: natural consequence of stepwise refinement: name of procedure denotes sequence of actions 4 abstraction subproblems time
    5. 5. ABSTRACTION  data abstraction: aimed at finding a hierarchy in the data 5 application-oriented data structures simpler data structuregeneral data structures
    6. 6. 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
    7. 7. 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
    8. 8. 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.
    9. 9. 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
    10. 10. 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
    11. 11. 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
    12. 12. 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
    13. 13. 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
    14. 14. 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()
    15. 15. OVERVIEW  Design principles  Design methods 15
    16. 16. DESIGN METHODS  Functional decomposition  Data Flow Design (SA/SD)  Design based on Data Structures (JSP)  Ojbject-Oriented method 16
    17. 17. 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
    18. 18. FUNCTIONAL DECOMPOSITION 18 bottom-up top-down
    19. 19. 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
    20. 20. 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
    21. 21. ENTITIES IN A DATA FLOW DIAGRAM  external entities  processes  data flows  data stores 21
    22. 22. DESIGN BASED ON DATA STRUCTURES (JSP )  JSP = Jackson Structured Programming (for programming-in-the-small) 22
    23. 23. 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
    24. 24. COMPOUND COMPONENTS IN JSP 24 A B C D sequence B A * iteration B C D A o o o selection
    25. 25. 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. 26. 26 OOAD METHODS  three major steps: 1 identify the objects 2 determine their attributes and services 3 determine the relationships between objects
    27. 27. 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. 28. 28 CANDIDATE OBJECTS  software  library  system  station  customer  transaction  book  library employee  identification card  client  bar code reader  book’s code
    29. 29. 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
    30. 30. RESULT: INITIAL CLASS DIAGRAM 30
    31. 31. USAGE SCENARIO ⇒ SEQUENCE DIAGRAM 31
    32. 32. CAVEATS WHEN CHOOSING A PARTICULAR DESIGN METHOD  Familiarity with the problem domain  Designer’s experience  Available tools  Development philosophy 32
    33. 33. 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
    34. 34. 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
    35. 35. THANK YOU! 35

    ×