Software Design. Main Points. Programmer s Approach to Software

Transcription

1 Software Design Main Points Study desirable software design properties Understand the different notions of complexity Understand classical and object-oriented design methods Understand the use of design patterns Understand software design documentation 2 Programmer s Approach to Software Skip requirements engineering and design phases; Start writing code 3

2 Justification Design is a waste of time We need to show something to the customer real quick We are judged by the amount of code written per month We expect or know that the schedule is too tight But the sooner you start coding, the longer it will take 4 Comments on Design Design is a trial-and-error process There is an interaction between requirements engineering, architecture, and design 5 Software Design as a Wicked Problem There is no definite formulation There is no stopping rule Solutions are not simply true or false Every wicked problem is a symptom of another problem 6

3 Design Principles Abstraction Modularity, coupling and cohesion Information hiding Limit complexity Hierarchical structure 7 Abstraction procedural abstraction: natural consequence of stepwise refinement: name of procedure denotes sequence of actions abstraction subproblems time 8 Abstraction data abstraction: aimed at finding a hierarchy in the data application-oriented data structures general data structures simpler data structure 9

4 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 10 Types of Cohesion coincidental cohesion logical cohesion temporal cohesion procedural cohesion communicational cohesion sequential cohesion functional cohesion 11 Types of Coupling content coupling common coupling external coupling control coupling stamp coupling data coupling 12

5 Simple Interfaces Simple Interfaces result from strong cohesion and weak coupling Advantages: simpler communication simpler correctness proofs changes influence other modules less often reusability increases comprehensibility improves less error prone 13 Information Hiding each module has a secret design involves a series of decisions: 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 14 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 complexity measures may be: size based structure based 15

6 Counting Lines of Code How many lines of code is this? #include <stdio.h> #define NULL 0 main () { int i; for (i=0;i<10;i++) printf(%d,i); } 16 Sized-based Complexity Measures counting lines of code differences in verbosity differences between programming languages a:= b versus while p <> null do p:= p.next Halstead s software science, essentially counting operators and operands 17 Software Science Basic Entities n 1 : number of unique operators n 2 : number of unique operands N 1 : total number of operators N 2 : total number of operands 18

7 Software Science Formulas size of vocabulary: n = n 1 + n 2 program length: N = N 1 + N 2 volume: V = N log 2 n Program Level: L = V*/ V approximation: L = (2/n 1 )(n 2 /N 2 ) programming effort: E = V/L estimated programming time: T = E/18 estimate of length = n 1 log 2 n 2 + n 2 log 2 n 2 19 Structure-Based Measures based on control structures data structures or both example complexity measure based on data structures: average number of instructions between successive references to a variable 20 Difficulties with Complexity Measures complexity measures are not very context sensitive complexity measures take into account few aspects 21

8 height System Structure looks at the complexity of the dependencies between modules draw modules and their dependencies in a graph then the arrows connecting modules may denote several relations, such as: A contains B A precedes B A uses B 22 Measurements } size # nodes # edges width 23 Object-Oriented Metrics 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 methods of a class 24

9 Weighted Methods per Class measure for size of class WMC = c(i), i = 1,, n (number of methods) c(i) = complexity of method i mostly, c(i) = 1 25 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 26 Number Of Children 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 27

10 Coupling Between Object Classes two classes are coupled if a method of one class uses a method or state variable of another class CBO = count of all classes a given class is coupled with high values: something is wrong 28 Response For a Class RFC measures the immediate surroundings of a class RFC = size of the response set response set = {M} {Ri} R1 M1 M2 M3 29 Lack of Cohesion of a Method cohesion = glue that keeps the module (class) together if all methods use the same set of state variables: OK, & that is the glue if some methods use a subset of the state variables, and others use another subset, the class lacks cohesion LCOM = number of disjoint sets of methods in a class two methods in the same set share at least one state variable 30

11 Classical Design Methods Functional decomposition Data Flow Design Design based on Data Structures 31 Functional Decomposition bottom-up top-down 32 Functional Decomposition 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 33

12 acknowledgement Data Flow Design Yourdon and Constantine (early 70s) Modern 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 34 Data Flow Diagram Entities external entities processes data flows data stores 35 First-level Decomposition client request report management direction borrow request prelim. doc return request log data prelim. doc log data borrow title title title catalog adm. prelim. doc log file 36

13 Design Based on Data Structures JSP = Jackson Structured Programming (for programming-in-the-small) JSD = Jackson Structured Design (for programming-in-the-large) 37 JSP: Jackson Structured Programming 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) 38 Compound components in JSP sequence iteration selection A A A B C D B * B o C o D o 39

14 JSD: Jackson Structured Design Problem with JSP: how to obtain a mapping from the problem structure to the data structure? JSD tries to fill this gap JSD has three stages: modeling stage: description of real world problem in terms of entities and actions network stage: model system as a network of communicating processes implementation stage: transform network into a sequential design 40 Object Oriented Analysis and Design Methods Three step process: 1 identify the objects 2 determine their attributes and services 3 determine the relationships between objects 41 Identifying the Objects Generate a candidate list based on objects in the UoD Carefully consider candidate list: eliminate implementation constructs, such as software replace or eliminate vague terms: system computer equate synonymous terms: customer and client client 42

15 Identifying Relationships From the problem statement From tacit knowledge 43 Result: initial class diagram 44 Usage Scenario Sequence Diagram 45

16 OO Design Methods Booch: early, new and rich set of notations Fusion: more emphasis on process RUP: full life cycle model associated with UML 46 Booch method identify classes and objects identify semantics of classes and objects identify relationships between classes and objects identify interface and implementation of classes and objects 47 Fusion Analysis object model interface model Design object interaction graphs visibility graphs class descriptions inheritance graphs 48

17 RUP: Rational Unified Process Information represented as workflows Four phases: inception, elaboration, construction, transition 49 Classification of Design Methods Simple model with two dimensions: Orientation dimension: Problem-oriented: understand problem and its solution Product-oriented: correct transformation from specification to implementation Product/model dimension: Conceptual: descriptive models Formal: prescriptive models 50 Classification of design methods (cnt d) problem-oriented product-oriented conceptual I ER modeling Structured analysis II Structured design formal III JSD VDM IV Functional decomposition JSP 51

18 Criteria for Choosing a Design Method Familiarity with the problem domain Designer s experience Available tools Development philosophy 52 Object-orientation: Does it Work? do object-oriented methods adequately capture requirements engineering? do object-oriented methods adequately capture design? do object-oriented methods adequately bridge the gap between analysis and design? are object-oriented methods really an improvement? 53 Design Patterns Provide solution to a recurring problem Balance set of opposing forces Document well-proven design experience Abstraction above the level of a single component Provide common vocabulary and understanding Are a means of documentation Supports construction of software with defined properties 54

19 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 55 Antipatterns Patterns describe desirable behavior Antipatterns describe situations one had better avoid In agile approaches (XP), refactoring is applied whenever an antipattern has been introduced 56 Example Antipatterns God class: one class holds most responsibilities Lava flow: dead code Poltergeist: class with few responsibilities and a short life Golden Hammer: solution that does not fit the problem Stovepipe: different technologies used to solve similar problems making integration difficult Swiss Army Knife: class is too general and too reusable 57

20 Design Documentation Needs to accommodate different users: Project manager Configuration manager Designer Programmer Unit tester Integration tester Maintenance programmer 58 IEEE Standard 1016 Documentation Attributes Identification Type Purpose Function Subordinates Dependencies Interface Resources Processing Data 59 Summary Essence of the design process: decompose system into parts Desirable properties of a decomposition: coupling/cohesion, information hiding, (layers of) abstraction There have been many attempts to express these properties in numbers Design methods: functional decomposition, data flow design, data structure design, object-oriented design 60