Under construction!  Will be developed throughout the Fall.

    This ...

COMMENTS:

1. D&L are inconsistent in their use of terms to describe the outlines of problem solving, algorithm development, and object-oriented development strategies, i.e. they use "phases", "stages", "steps", etc.  I use only "phases" to ensure you know exactly when I am talking about development strategies.
2. D&L use two text based representations for software development, pseudocode for algorithms and CRC cards for object-oriented development.  I prefer two schematic representations, flowcharts for algorithms and UML class diagrams for object oriented development.  My reasons are:
1. Visual schematic representations are more efficient, i.e. they can be presented and modified much more quickly than text based representations.
2. Visual representations are language independent.
3. Especially the UML, but also flowcharts are standardized; in fact, the UML is the ONLY international standard for representing object technology.  (I do have a nonstandard version of flowcharts that I call "Structured Algorithm Charts" (SACs) that is the most powerful algorithm analysis and devlopment tool that I know of, but, because it is nonstandard, I hesitate to spend time covering it.)
   
3. Up to now, no one uses CRC cards in our curriculum and I have not seen it used in any CS 1 or CS 2 texts in either C++ or Java.  Since they can be useful in the OO analysis of software development projects as well as in the design phase, they may be used in COSC 240 and 241, although CRC card techniques can only take a subordinate role to the international standard Unified Modelling Language (UML). 
   
1. Note that although collaborators on a CRC card can specify the "nearest neighbor" classes of a software architecture, CRC cards have no format to display the complete architecture, like the UML does, i.e. there is no mechanism for showing all the relationships in the software.
4. It is important to realize that the terms "top-down design" and "module" apply to both algorithm development (structured programming) and OOSD.  There is nothing wrong with using "top-down design" and "module" to describe algorithm development or structured programming, as D&L does, but it is a mistake to think that these terms ONLY apply to these forms of software development.  Both top-down design  and module apply, perhaps more exactly, to the inheritance hierarcy view of software architectures (top-down design) using classes (modules).