General Course Flow Recommendations

I recommend that we teach A&D as presented in the book, that is, according to the principles of an iterative development lifecycle. Touch on all the topics in Cycle 1, delve more deeply into each in Cycle 2, and so on (as opposed to exhaustively covering each topic in a "waterfall" approach). For example, in the first 6-week period, go through all the topics (use cases, conceptual modeling, etc.) and have the students develop a project. Then revisit all the topics at greater depth in the second 6-week period, with an associated second iteration of the same student project. Please note that the book follows the above pattern, the major sections being (in order):

1. Analyze Phase (Cycle 1)
2. Design Phase (Cycle 1)
3. Analyze Phase (Cycle 2)
4. Design Phase (Cycle 2)

Not surprisingly, I recommend teaching in a pattern that follows typical software construction activities described in the book: requirements, use cases, conceptual modeling, and so on. The book organization mirrors how I structure the course syllabus.

Miscellaneous Recommendations

Not all activities and models are equally important; not all "sections" of an artifact are equally important. Certainly, responsibility assignment is more important that state modeling. Throughout the course I suggest exploring questions such as: Why bother doing this? What problems or questions does this model address? Is it worth the ROI, or is it just a mechanical make-work exercise with no value later in the development cycle? The student should complete the course knowing that they don't have to do all activities, and they should know what the costs and benefits are. They should learn to avoid doing something if it is not a meaningful input to something else, and conversely, to inquire why some artifact was not used later on. There is no value in making "pretty" paper diagrams that don't actually and practically drive towards better software.

Above all else, the student should understand that the most important concept they can learn in object-oriented analysis and design is skillful responsibility assignment. This is the real-life make-or-break skill. They should learn that the GRASP patterns are a tool to help them learn and apply basic responsibility assignment principles.

Due to space constraints, the book emphasizes responsibility assignment only in the context of doing interaction diagrams. However, this does not imply it is the only way. I consider it equally valid to stare at an evolving class diagram and add responsibility comments to individual classes (probably via a UML dog-eared text constraint note or in a separate "box" within the class rectangle) or to use something like CRC cards and role playing. The important thing is skillful responsibility assignment, not the notational vehicle. One advantage of considering responsibilities in the context of interaction diagrams is that the full picture of collaborations is considered at the same time.