11 Software Design CSCU 411 Software Engineering LEARNING

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 11. 24 • 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