11 Software Design CSCU 411 Software Engineering

LEARNING OBJECTIVES To be able to discern desirable properties of a software design To Understand different notions of complexity, at both the module and system level To be aware of some widely-known design Methods To be aware of a global classification scheme for design methods To be aware of guidelines for the design documentation

The ‘Programmer's Approach' No Design Phase the 'programmer's approach' to software development. Far too much software is still being developed without a clear design phase. The real The reasons for this 'code first, design later' attitude are many: –We do not want to, or are not allowed to, 'waste our time' on design activities. –We have to, or want to, quickly show something to our customer. –We are judged by the amount of code written per man-month. –We are, or expect to be, pressed for time.

Wicked Problem Software design is a 'wicked problem'. The term originated in research into the nature of design in social planning problems –There is no definite formulation of a wicked problem. –Wicked problems have no stopping rule. –Solutions to wicked problems are not true or false. –Every wicked problem is a symptom of another problem.

DESIGN CONSIDERATIONS abstraction, modularity, Information hiding, complexity, and system structure

Abstraction Procedural Abstraction Data Abstraction OOP Languages (C++, JAVA, ADA Modula-2) –Package –Structure –Module –Class

Modularity (cohesion) Coincidental cohesion Logical cohesion Temporal cohesion Procedural cohesion Communicational cohesion Sequential cohesion Functional cohesion

Modularity (coupling) Content coupling Common coupling External coupling Control coupling Stamp coupling Data coupling

Information Hiding Data Hiding Function Hiding Other –Debug –Logging –Advance Options

Complexity How Complex? Size Module attributes Structure Interface Pointers Recursion Dynamic allocation WOW factor

System Structure module A contains module B module A follows module B module A delivers data to module B module A uses module B Note Call Graphs

System Structure Local and Global Data Flow A local flow from module A to module B exists if : –A invokes B and passes it a parameter, or – B invokes A and A returns a value. A global flow from module A to module B exists if A updates some global data structure and B retrieves from that structure

System Structure Complexity M is Modules in a program Complexity (M) = (Fan-In (M) X Fan-Out (M)) 2 Fun(int a) same as Fun(struct *b)

DESIGN METHODS Functional Decomposition Data Flow Design (SA/SD) Data Structure Look at Table 11.3

Functional Decomposition Top-down design Bottom-up design Both not ideal in real world More often try and refine Layered system

Data Flow Design (SA/SD) Data Flow Diagrams (DFD) Structure Charts Structured Analysis Structured Design Using: –External Entities –Processes –Data Flows –Data Stores

External Entities Processes Data Flows Data Stores

Design Based on Data Structures Structure Diagrams or Jackson Diagrams –Structured text or Structure Diagrams –Schematic Logic (11.13 to 11.23)

Selecting a Design Method How to Select a Design Method Problem solving is based on experience –Cost –Maintaining software –Flexibility –It is The prescriptiveness of the design methods differs considerably.

Classification of Design Techniques See fig The four Quadrants –I Understand the problem –II Transform to implementation –III Represent properties –IV Create implementation units

Environmental Factors Familiarity with the problem domain. Designer's experience. Available tools. Overall development philosophy.

NOTATIONS THAT SUPPORT THE DESIGN PROCESS Software is far more subject to change. One of the major issues in software design is the hierarchical decomposition of the system. The outcome of the design is the major source of information for the programmer

DESIGN DOCUMENTATION People responsible for Creating and using documentation –The project manager –The configuration manager –The designer –The programmer –The unit tester –The integration tester –The maintenance programmer

IEEE Standard 1016 Recommended Practice for Software Design Descriptions. (Distinguishes ten attributes) –Identification –Type –Purpose –Function –Subordinates –Dependencies –Interface –Sources –Resources –Processing –Data

VERIFICATION AND VALIDATION Same as before