Software Engineering: Structured Analysis and Design

1. Software Engineering: StructuredAnalysis and Design Soonglsil Univeristy Department of Industrial and Information Systems Engineering

2. What is Design ? • Design as activity • The creative process of transforming a problem into a solution • In our case, transforming a requirement specification into a detailed description of the software • Design as documentation • The description of the solution • We can get documentation as output of design activity

3. What is Good Design? • A good design is one that balances trade-offs to minimize the total cost of the system over its entire lifetime • […] • a matter of avoiding those characteristics that lead to bad consequences. • Coad & Jourdon • “Correct design" • An insurance against "design catastrophes“. • Proper design methods guarantee the "correct design" There is no correct design! You must decide! • Need of criteria for evaluating a design • Need of principles and rules for creating good designs

4. Stages of Design • Problem understanding • Look at the problem from different angles to discover the design requirements • Identify one or more solutions • Evaluate possible solutions and choose the most appropriate depending on the designer's experience and available resources • Describe solution abstractions • Use graphical, formal or other descriptive notations to describe the components of the design • Repeat process for each identified abstractionuntil the design is expressed in primitive terms

5. Phases in the Design Process RequirementsSpecification Design Activities ArchitecturalDesign AbstractSpecification InterfaceDesign ComponentDesign DataDesign AlgorithmDesign SystemArchitecture SoftwareSpecification InterfaceSpecification ComponentSpecification DataSpecification AlgorithmSpecification Design Products

6. Design Phases • Architectural design • Identify sub-systems • Abstract specification • Specify sub-systems • Interface design • Describe sub-system interfaces • Component design • Decompose sub-systems into components • Data structure design • Design data structures to hold problem data • Algorithm design • Design algorithms for problem functions

7. Phases in the Design Process RequirementsSpecification Design Activities ArchitecturalDesign AbstractSpecification InterfaceDesign ComponentDesign DataDesign AlgorithmDesign SystemArchitecture SoftwareSpecification InterfaceSpecification ComponentSpecification DataSpecification AlgorithmSpecification Design Products

8. Multiple Architectural Design

9. Key Design Issues • Main purpose - Manage software system complexity by ... • ... improving software quality factors • ... facilitate systematic reuse 1. Decomposition/Composition • Why and How ? • What is a component? • Principles 2. Modularity • Definition. Benefits • Criteria • Principles

10. Decomposition WHY ? Handle complexity by splitting large problems into smaller problems, i.e. "divide and conquer" methodology 1. Select a piece of the problem • initially, the whole problem 2. Determine the components in this piece using a design paradigm • e.g. functional, structured, object-oriented, generic, etc. 3. Describe the components interactions 4. Repeat steps 1 through 3 until some termination criteria is met • e.g., customer is satisfied, run out of money, etc. ;-)

11. DecompositionBased on Data Flow Analysis • Decompose the product into three modules • Repeat stepwise until each module has high cohesion • Minor modifications may be needed to lower the coupling

12. Operation-Oriented Design • Data flow analysis • Use it with most specification methods (Structured Systems Analysis here) • Key point: We have detailed action information from the DFD Output Input h g a b c f d e

13. Data Flow Analysis • Every product transforms input into output • Determine • “Point of highest abstraction of input” • “Point of highest abstract of output” Output Input h g a b c f d e Input Modules Output Modules Transform Modules Point of highest abstraction of input Point of highest abstraction of output

14. Mini Case Study: Word Counting (contd) • First refinement - Perform word count Word count Data Control Validated filename Status flag Word count Validated filename Format and display word count Read and validate filename Count number of words

15. Mini Case Study: Word Counting (contd) • Now refine the two modules of communicational cohesion • Second refinement- All eight modules now have functional cohesion Perform word count Word count Data Control Validated filename Status flag Word count Validated filename Count number of words Produce output get_input filename formatted word count formatted word count Status flag filename filename display word count validate filename Read filename Format word count

16. The Structure Chart - 1 • Principal tool of Structured Design • Based on dividing a system into modulesforStructured Programming and then mapping the connections between the modules • Structured Design is only concerned with the outside view of the module

17. The Structure Chart - 2 • A module is defined as a collection of program statementswith four attributes: • input and output - what the module gets from its invoker and what the invoker receives from the module • function - what it does to its input to produce its output • mechanics - the code or logic by which it carries out its function • internal data - its own private workspace, data to which it alone refers

18. The Structure Chart • Notation • One module calls another module • Data Flow (Variable or Data structure) • Control Flow (flag) • Module comment Repetition Selection comment Module

19. Iteration and Decision on a Structure Chart Symbol for showing decisions Symbol for showing iteration Issue pay cheques for all employees Calculate Pay for Casual Worker Calculate Pay for Salaried Worker Get Employee Pay Record Print Pay Cheque

20. Connections between modules • A connection indicates that one module calls another module A Get Customer Details Calling Module B Find Customer Name Called Module

21. Difference between Data and Flags • Data is processed, flags are not • A flag is typically set and tested • Data relates to the problem • Flags communicate information about the data

22. Showing Data and Information • Need to show the movement of data and the movement of information about data (flags) Get Customer Details Flag going from caller to called Data going from caller to called Customer Name Customer Account Number Flag going from called to caller Account Number is OK Data going from called to caller Find Customer Name

23. Structure Chart • Example Main c a b B C A a f f f X W Y Z • Other Notation Pre defined Module in Library Input or Output Module

24. PRINT READ Example Structure Chart SUMMARIZE PAYMENTS FOR ALL CUSTOMERS Total for One Customer Total for All Customers Total for One Customer EOTP GET TOTAL PAYMENT FOR ONE CUSTOMER PUT CUSTOMER TOTAL PUT FINAL TOTAL Valid Customer Record EOVCR Final Total Line Customer Total Line GET VALID CUSTOMER RECORD Field Valid Customer Record Field EDIT FIELD

25. Deep Structure Main A B C W X

26. Wide Structure Main A B C Fan out Fan in

27. Centralized Structure Chart Centralized Process Module Centralized Input Module

28. Centralized Structure Chart Centralized Output Module

29. A Structure looks Moscow System

30. Phases in the Design Process RequirementsSpecification Design Activities ArchitecturalDesign AbstractSpecification InterfaceDesign ComponentDesign DataDesign AlgorithmDesign SystemArchitecture SoftwareSpecification InterfaceSpecification ComponentSpecification DataSpecification AlgorithmSpecification Design Products

31. Abstraction Abstraction is an important problem-solving technique, especially in software design. Abstraction is suppressing or ignoring some properties of objects, events, or situations in favor of others.

32. Importance of Abstraction • Problem simplification • Abstracting allows us to focus on the most important aspects of a problem in (partially) solving it. • Structuring problem solving • Top-down strategy: Solve an abstract version of the problem, then add details (refinement) • Bottom-up strategy: Solve parts of a problem and connect them for a complete solution

33. Abstraction in Top-Down Design Figure An example of top-down design • This process continues for as many levels as it takes to expand every task to the smallest details • A step that needs to be expanded is an abstract step

34. StepwiseAbstraction Abstract I Abstract III procedure: 2-D drawing creation; repeat util <drawing creation task terminates> do while <digitizer interaction occurs> digitizer interface task; determine drawing request; line: line drawing task; curcle: cricle drawing task; . . . CAD system Abstract II CAD software tasks: user interaction task; 2-D drawing creation task; graphics display task; drawing file management task; end.

35. Information Hiding/Abstraction • Information Hiding and Abstraction are two sides of the same coin. • Information Hiding The practice of hiding the details of a module with the goal of controlling access to the details of the module. • Abstraction A model of a complex system that includes only the details essential to the viewer.

36. Information Hiding/Abstraction • Abstraction is the result with the details hidden • Data abstraction Separation of the logical view of data from their implementation. • Procedural abstraction Separation of the logical view of actions from their implementation. • Control abstraction Separation of the logical view of a control structure from its implementation.

37. Procedural abstraction • Procedural abstraction is to abstract a procedure of a function or a role. • Examle) Equation  ax + by = c  a’x+b’y = c’  solve_equation ( equationType equ )

38. Data abstraction • Stack using Data Abstraction const int MAXSIZE = 100; class stack{ private: char stack_value[MAXSIZE]; int top; public: stack(){top = 0;}; void push(char); char pop(); }; void stack::push(char x){ if (top+1 == MAXSIZE) error("stack is full"); else stack_value[++top] = x; } char stack::pop(){ if (top == 0){ error("stack is empty"); return NULL; } else return stack_value[top--]; } void main(){ stack st1; char x, y; st1.push('a'); st1.push('b'); x = st1.pop(); y = st1.pop(); cout << x << y << endl; } • 데이터 추상화도 제어 추상화 또는 과정 추상화와 같이 상세정보를 감추는 것이다

39. Control abstraction • Swapping of two variables temp := value1; value1 := value2; value2 := temp; • We can represent as a form of control abstraction as next; value1 value2; • Even though the abstraction mechanism doesn’t show up the details, it is enough to program it at coding stage.

40. Control abstraction • 다음으로 설계 단계에서 어떤 회사의 모든 사업부에 대해 필요한 처리를 하는 순환 제어 구조를 다음과 같이 추상화할 수 있다. for (회사의 모든 사업부) do ... end for • We don’t need to mention the way to access to every business department in a compay.

41. Information Hiding/Abstraction • Information Hiding and Abstraction are two sides of the same coin. • Information HidingThe practice of hiding the details of a module with the goal of controlling access to the details of the module. • Abstraction A model of a complex system that includes only the details essential to the viewer.

42. Stack using Information Hiding #define MAXSIZE 100; struct STACK{ char stack_value[MAXSIZE]; int top; }; typedef struct STACK stack; void create_stack(stack aStack){ aStack = new STACK; aStack->top = 0; } void push(stack aStack, char x){ if (aStack->top+1 == MAXSIZE) error("stack is full"); else aStack->stack_value[++aStack->top] = x; } char pop(stack aStack){ if (aStack->top == 0){ error("stack is empty"); return NULL; } else return aStack->stack_value[aStack->top--]; } char top_element(stack aStack){ if (aStack->top == 0){ error("stack is empty"); return NULL; } else return aStack->stack_value[aStack->top - 1]; } void destroy_stack(stack aStack){ delete aStack; } void main(){ stack st1; char x, y; create_stack(st1); push(st1, 'a'); push(st1, 'b'); x = pop(st1); y = top_element(st1); destroy_stack(st1); printf("%c , %c", x, y); }

43. Stack not using Information Hiding #define MAXSIZE 100; typedef struct { char stack_value[MAXSIZE]; int top; } stack; void push(stack* aStack, char x){ if (aStack->top+1 == MAXSIZE) error("stack is full"); else aStack->stack_value[++aStack->top] = x; } char pop(stack* aStack){ if (aStack->top == 0){ error("stack is empty"); return NULL; } else return aStack->stack_value[aStack->top--]; } void main() { stack* st1; char x, y; st1 = new stack; st1->top = 0; push(st1, 'a'); push(st1, 'b'); x = pop(st1); y = st1->stack_value[st1->top - 1]; delete st1; printf("%c , %c", x, y); }

44. Phases in the Design Process RequirementsSpecification Design Activities ArchitecturalDesign AbstractSpecification InterfaceDesign ComponentDesign DataDesign AlgorithmDesign SystemArchitecture SoftwareSpecification InterfaceSpecification ComponentSpecification DataSpecification AlgorithmSpecification Design Products

45. Interface design • Screen design • For text-based screens, can use design forms • Format: 25 rows x 80 characters • For GUI, can use ‘Print Screen’ • Report design • For text-based reports, e.g. dot-matrix printers, use design forms (80 or 132 columns) • For graphical reports, use ‘Print Screen’

46. A Component (Module ) is ... • ... a SW entity encapsulating the representation of an abstraction • ... a vehicle for hiding at least one design decision • ... a "work" assignment • for a programmer or group of programmers • ... a unit of code that • has one (or more) name(s) • has identifiable boundaries • can be (re-)used by other components • encapsulates data • hides unnecessary details • can be separately compiled

47. Component Interface A component interface consists of several sections: • Exports • services provided to other components • Imports • services required from other components • Access Control • e.g. protected/private/public

48. Iteration and Decision on a Structure Chart Symbol for showing decisions Symbol for showing iteration Issue pay cheques for all employees Calculate Pay for Casual Worker Calculate Pay for Salaried Worker Get Employee Pay Record Print Pay Cheque

49. PRINT READ Example Structure Chart SUMMARIZE PAYMENTS FOR ALL CUSTOMERS Total for One Customer Total for All Customers Total for One Customer EOTP GET TOTAL PAYMENT FOR ONE CUSTOMER PUT CUSTOMER TOTAL PUT FINAL TOTAL Valid Customer Record EOVCR Final Total Line Customer Total Line GET VALID CUSTOMER RECORD Field Valid Customer Record Field EDIT FIELD

50. Meyer's Five Rules of Modularity • Direct Mapping • consistent relation between problem model and solution structure • Few Interfaces • Every component should communicate with as few others as possible • Small Interfaces • If any two components communicate at all, they should exchange as little information as possible • Explicit Interfaces • Whenever two components A and B communicate, this must be obviousfrom the text of A or B or both • Information Hiding