1 / 131

Software Engineering: Structured Analysis and Design

Software Engineering: Structured Analysis and Design. Soonglsil Univeristy Department of Industrial and Information Systems Engineering. What is Design ?. Design as activity The creative process of transforming a problem into a solution

ovidio
Download Presentation

Software Engineering: Structured Analysis and Design

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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. 설계 방법론 • 구조적 설계(structured design) • 시스템을 기능적 관점에서 다룸 • 하향적 세분화 • Yourdon/Coad • 객체지향 설계(object-oriented design) • 자료와 자료에 적용될 기능을 함께 추상화 • 객체: 자료+기능 • 시스템은 객체의 모임 • Yourdon, Sheller/Meller, Rumbaugh, Booch... • 자료구조 중심 설계 • 입출력자료의 구조 파악으로 소프트웨어 구조를 추출 • Jackson, Warnier-Orr 3

  4. 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“ • Need of criteria for evaluating a design • Need of principles and rules for creating good designs

  5. 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

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

  7. 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

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

  9. Multiple Architectural Design

  10. 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

  11. 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. ;-)

  12. 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

  13. 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

  14. 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

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

  16. 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

  17. 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

  18. 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

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

  20. 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

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

  22. 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

  23. 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

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

  25. 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

  26. Deep Structure Main A B C W X

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

  28. Centralized Structure Chart Centralized Process Module Centralized Input Module

  29. Centralized Structure Chart Centralized Output Module

  30. A Structure looks Moscow System

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

  32. 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.

  33. 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

  34. 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

  35. StepwiseAbstraction Abstract I Abstract III CAD system 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; . . . Abstract II CAD software tasks: user interaction task; 2-D drawing creation task; graphics display task; drawing file management task; end.

  36. 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.

  37. 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.

  38. 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 )

  39. 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; • } • 데이터 추상화도 제어 추상화 또는 과정 추상화와 같이 상세정보를 감추는 것이다

  40. 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.

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

  42. 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.

  43. 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); • }

  44. 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); • }

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

  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

More Related