Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] Detailed Design
This material was was not covered in lectures in 1997, and can be considered to be optional.
Detailed Design includes the selection of algorithms and data structures that will be used to implement modules (or services for classes) and data areas. It is, for the most part, beyond the scope of CPSC 333: Some of this has been covered already in CPSC 331, and more will be covered in senior courses, such as CPSC 413 and CPSC 461.
This page will mention two topics you should probably be aware of, but doesn't cover either in much detail. Recent editions of Pressman's Practitioner's Approach includes more details about each.
Stepwise Refinement is a top-down design strategy that was proposed by Niklaus Wirth in the following article.
N. Wirth
``Program Development by Stepwise Refinement''
Communications of the ACM 14 (1971), pp. 221-227
In principle, it could be used to develop an algorithm based on a set of requirements, by elaborating or refining the requirements, in order to gradually add details, until an algorithm emerged:
``In each step (of the refinement), one or several instructions of the given program are decomposed into more detailed instructions. This successive decomposition or refinement of specifications terminates when all instructions are expressed in terms of any underlying computer or programming language...
This kind of purely top-down strategy can be inadequate if the system to be defined is large or complex, since it isn't always clear how one can refine a large problem effectively; it may be more useful when the problem to be solved is simpler or smaller, so it may be useful when you're developing algorithms for individual modules or services.
Graphical notation for specifying procedural details does exist, and one example of this - flow charts - is still common. A decision table is another example of a graphical (or, tabular) representation of procedural detail.
These notations might, possibly, have the advantage that they force you to specify procedural information in a standardized way. However, pseudocode (or ``Structured English'') is generally easier to use, and can also be used in a uniform way. The advice given in this course is as follows: You should usually use pseudocode when you have the choice to.
Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] Detailed Design