Software Engineering COMP 3400 - System Design

1. Main f,g,h b,c,e. f,g,h b,c,e Get Validated Input Output Schedule f g h Print Timetable Print Conflict Print Explanation Software Engineering COMP 3400 - System Design • The goal of the detailed design phase is to develop the internal logic of each of the modules identified during the system design phase. • The structured design methodology used during system design did not precisely specify the modules but rather described the modules in a natural language.

2. Software Engineering - Detailed Design Specifying Modules • Formal methods for module specification are intended to ensure that the specifications are precise and are not subject to interpretation by the coder. • Module specifications should be complete, unambiguous, implementation independent and easy to understand. • One technique used is to provide a very high level prototyping language for specifying and testing module specifications

3. Software Engineering - Detailed Design Specifying Functional Modules • A functional module can be described in terms of its input and output transform. SORT (L: list of integers) output: for all i, 1 ¦£ i < size(L’) L’[i] ¦£ L’[i+1] and L’ = permutation(L) ¦ input: non null L Sort a list L of integers in ascending order

4. Software Engineering - Detailed Design Specifying Data Abstractions • Another formal method for specifying modules is referred to as data abstraction. • This technique requires the use of a formal specification language, which is implementation independent but which shares many of the characteristics of a programming language. See figure 5.2 for specifying a queue. • Formal methods for module specifications are cumbersome, not very expressive, and are hard to write and understand.

5. Software Engineering - Detailed Design Process Design Language (PDL) • Process Design Language (PDL) is a practical way to precisely communicate the meaning of a system or module. • PDL can be thought of as a structured natural language, with some of the precision of a structured programming language and some of the ease of a natural language. • Some amount of automated processing can be done with the PDL design document.

6. Software Engineering - Detailed Design PDL Example minmax(infile) // Find the max and min of a string of numbers // ARRAY a DO UNTIL end of input READ an item into a ENDDO max, min := first item of a DO FOR each item in a IF max < item THEN set max to item IF min > item THEN set min to item ENDDO END

7. Software Engineering - Detailed Design Process Design Language (PDL) • Notice that in this example, we have the entire logic for the procedure without the implementation details of a particular imperative language. • To code this procedure the programmer needs to relate each of the statements into a construct in the implementation language. • There is little room for coding “creativity” • A series of PDL designs can be generated in a successive refinement approach.

8. Software Engineering - Detailed Design PDL Constructs • The constructs of PDL are similar to that of a structured imperative language like Pascal or C: IF condition THEN CASE OF transaction type CASE OF operator type DO iteration criteria statement list ENDDO

9. Software Engineering - Detailed Design Logic/Algorithm Design • An algorithmis a series of steps that need to be performed to to solve a given problem. • The design of a specific algorithm begins with a statement of the module problem from the System Design Specification. • The use of stepwise refinement techniques and PDL descriptions can be used to gradually convert the module description into a precisely defined algorithm. • PDL permits a series of refinements with varying degrees of precision not available in a specific programming language.

10. Count the Number of Different Words Get Word List Sort The List Print the Count Input Word List:wl Sorted Word List Word Count Software Engineering - Detailed Design Algorithm Design Example - Counting Different Words • The PDL description of this Data Flow Graph:

11. Count the Number of Different Words Get Word List Sort The List Print the Count Input Word List:wl Sorted Word List Word Count Software Engineering - Detailed Design Algorithm Design Example - Counting Different Words • 1st PDL refinement of this Data Flow Graph: count (in: file) returns integer var wl: word_list; begin sort (wl); count := different_words (wl); print (count); end;

12. Software Engineering - Detailed Design Algorithm Design Example - Counting Different Words • Three operations require refinement: • read file into word list (wl), • sort word list, • count different words in word list. • Select one of the three for further refinement. • Refine the reading operation:

13. Software Engineering - Detailed Design Algorithm Design Example - Counting Different Words • Three operations require refinement: • read file into word list (wl), • sort word list, • count different words in word list. • Select one of the three for further refinement. • Refine the reading operation: read_from_file (in: file, out: wl) begin initialize wl to empty; repeat get_a_word from file add word to wl until end_of_file end;

14. Software Engineering - Detailed Design Algorithm Design Example - Counting Different Words • Refine the counting operation:

15. Software Engineering - Detailed Design Algorithm Design Example - Counting Different Words • Refine the counting operation: different_words (in: wl) returns integer var last, cur: word; cnt: integer; begin last: = first word in wl; cnt : = 1; while not end of list cur : = next word from wl; if (cur ! = last) then begin cnt := cnt + 1; last := cur; end; end; return (cnt); end.

16. Software Engineering - Detailed Design Logic/Algorithm Design • For complex problems many successive refinements may be required. • Design for such problems can proceed depth first or breadth first: • depth first continues refinement of a single operation before other operations are refined, • breadth first refines all operations are refined in parallel. • The structure of PDL programs resulting from this technique are not the same as the structure resulting from the SDM (Structured Design Methodology): • in stepwise refinement sort is subordinate to the main module, in SDM it is subordinate to the input module.

17. Software Engineering - Detailed Design Verification • The goal of verification in the detailed design phase is to ensure that the detailed design is consistent with system design. • Three validation methods are: • design walkthroughs • critical design reviews • consistency checkers

18. Software Engineering - Detailed Design Design Walkthroughs • A meeting is held by the designer or design group leader or designated spokesperson. • The detailed design is described in step-by-step fashion. • The feedback is usually informal in nature. • The Design Review is more effective and more expensive.

19. Software Engineering - Detailed Design Critical Design Review • A review group, consisting of the detailed design author or team, the system design team, the programming team, the quality assurance organization and perhaps the client is convened. • The review is conducted in a manner similar to the requirements or system design review, i.e., each member is prepared and incented to review the detailed design beforehand and reveal detailed design errors. • The meeting is not intended to fix problems, but rather, to identify them. • A list of action items should be maintained for further reporting or a subsequent meetings.

20. Software Engineering - Detailed Design Critical Design Review Checklist • Does each of the modules in the system design appear in the detailed design? • Can the performance requirements be met? • Are the assumption explicit and acceptable? • Are all relevant aspects of system design in the detailed design? • Is the design structured and compatible with local practices? • Are the sizes of data structures explicit? • Is each statement codeable? • Will the loops terminate? • Is the module too complex? • Are the modules highly cohesive?

21. Software Engineering - Detailed Design Consistency Checkers • A consistency checker is a special purpose PDL compiler which, rather than producing executable target code, ensures that the modules invoked or used by a given module is consistent with the design • A consistency checker can ensure that any modules invoked or used by a given module actually exit in the design and that the caller interface is consistent with the interface definition of the called module. • Consistency checkers can generate complexity metrics. • The more formal the design language the better its checking and the closer it becomes to a formal programming language.

22. Software Engineering - Detailed Design Metrics • After the detailed design many important details are known about the software system. Only the implementation details associated with a programming language remain. • Hence, many system metrics can be formulated. • Detailed design metrics include: • Complexity metrics • Data bindings • Cohesion metrics

23. Software Engineering - Detailed Design Cyclomatic Complexity • Programs with with many conditional statements tent to be more complex than those with few conditional statements. • A simple measure of complexity is the number of constructs that represent program branches like if then else, while do, and repeat until. • A more refined measure of complexity is the cyclomatic complexity measure, which is based on a control flow graph of a programs logic. • A control flow graph is drawn by breaking a program into blocks delimited by control statements. • These blocks become graphical nodes with arcs connecting branchings between blocks. • The complexity can be calculated by counting the nodes, edges and connections in the control flow graph.

24. Software Engineering - Detailed Design Cyclomatic Complexity • A module with its corresponding flow graph is shown below:

25. Software Engineering - Detailed Design Cyclomatic Complexity 0 begin 1 i = 1 2 while (i £ n) do begin 3 j = 1; 4 while(j £ i) do5 if A[j] < A[i] then 6 swap (A[j], A[i]); 7 end if 8 end while 9 end while 10 end • A module with its corresponding flow graph is shown below: 0,1,2 3,4 5 • The cyclomatic number is the number of independent circuits in the chart 10 9 7,8 6

26. Software Engineering - Detailed Design Cyclomatic Complexity 0 begin 1 i = 1 2 while (i £ n) do begin 3 j = 1; 4 while(j £ i) do5 if A[j] < A[i] then 6 swap (A[j], A[i]); 7 end if 8 end while 9 end while 10 end • A module with its corresponding flow graph is shown below: 0,1,2 3,4 5 • The cyclomatic number is the number of independent circuits in the chart = 4 10 9 7,8 6

27. Software Engineering - Detailed Design Data Bindings • Data bindings attempt to measure the coupling and cohesion among modules. • A potential data binding counts the number of variables between two modules which are within the same scope. This metric represents the potential for coupling of variables by sharing between modules. • A used data binding is a potential data binding where two modules use the same variable. • An actual data binding occurs when a module assigns a value to a variable and another module uses that value. • All of these binding attempt to represent the strength of interconnections between particular modules.

28. Software Engineering - Detailed Design Module Complexity • After detailed design, the complexity of modules can be obtained. • If a module is very complex it will be difficult to understand, maintain and modify. • If a module is too complex it can be broken down into two or more less complex modules.

29. Software Engineering - Detailed Design Errors per Module • After a design walkthrough the number of errors per module can be determined. • Assuming a high quality review, a low number of errors implies that the module was well designed. • If the number of errors in module is high it may indicate that there will be problems during the coding phase and careful scrutiny may be required

30. Software Engineering - Detailed Design Summary • The goal of detailed design is to develop the internal logic of each of the modules identified during the system design. • Methods are available for specifying the logic of a module. • Formal methods exist for specifying modules. • One is the axiomatic specification technique, another is data abstraction.

31. Software Engineering - Detailed Design Summary • Unfortunately, the formal methods developed to date tend to be a pain and are rarely used in practice. • A more practical approach is to use a pseudo-language specifically designed for specifying modules during the detailed design phase of a project. • This pseudo-language should be practical enough to be usable yet precise enough to be convertible into code without requiring uncontrolled decisions on the part of the code writers.

32. Software Engineering - Detailed Design Summary • We discussed a language called Process Design Language which is used to describe the detailed design of systems and which is used in practice. • PDL can be used to express the detailed design of modules. • PDL has a formal outer syntax and a flexible inner syntax and vocabulary, giving it a balance between formalism and ease of expression.

33. Software Engineering - Detailed Design Summary • Several metrics were introduced to evaluate the effectiveness and output of this phase. • We have introduced metrics for evaluating the complexity of modules, the coupling among modules and the quality of modules. • We have discussed verification techniques such as our old friend the design review. • Several automated techniques exist which are based on PDL though the deign review is still the most used.

34. Software Engineering - Detailed Design Case Study • Design Decisions • PDL of main module procedure • Proc main() • PDL of input module procedures • Proc get_validated_input(file1,file2) • Proc validate_file(file1) • Proc validate_classrooms • Proc validate_dept_courses • Proc validate_lecture_times • Proc validate_file2

35. Software Engineering - Detailed Design Case Study • PDL of input module procedures • Proc get_ course_index(course_no, course_index) • Proc get_pref_valid(buffer, valid_pref_list) • Proc form_course_rec(course_index,enrol,valid_pref_list) • Proc separate_course