Software Engineering Software Engineering COMP 3400 - System COMP 3400 - System Design 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 f,g,h Print Timetable Print Conflict Print Explanation h g f
Transcript
Software Engineering Software Engineering COMP 3400 - System COMP 3400 - System
DesignDesign
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.
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.
Specifying Data AbstractionsSpecifying Data Abstractions
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.
Process Design Language (PDL)Process Design Language (PDL)
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.
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.
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.
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?
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.
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
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.
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.
