1. 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.
Main
Get Validated Input
b,c,e.
Output
f,g,h
Schedule
b,c,e
Print
Timetable
Conflict
Explanation h g f

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
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 algorithm is 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. Software Engineering - Detailed Design
Algorithm Design Example -
Counting Different Words
Get Word List
Print the Count
Sort The List
Count the Number of Different Words
Input
Word
List:wl
Sorted
List
Count
The PDL description of this Data Flow Graph:

11. Software Engineering - Detailed Design
Algorithm Design Example -
Counting Different Words
Get Word List
Print the Count
Sort The List
Count the Number of Different Words
Input
Word
List:wl
Sorted
List
Count
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;
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 17

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

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

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

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

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 22

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
A module with its corresponding flow graph is shown below:
0 begin
1 i = 1
2 while (i £ n) do begin
3 j = 1;
4 while(j £ i) do 5 if A[j] < A[i] then
6 swap (A[j], A[i]);
7 end if
8 end while
end while
10 end
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
A module with its corresponding flow graph is shown below:
0 begin
1 i = 1
2 while (i £ n) do begin
3 j = 1;
4 while(j £ i) do 5 if A[j] < A[i] then
6 swap (A[j], A[i]);
7 end if
8 end while
end while
10 end
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