|
|
Critical design review (CDR) involves trying to ensure that the "how" of detailed design, as shown on sequence diagrams and associated class diagrams, matches up well with the "what" that the use cases specify, and that the detailed design is of sufficient depth to facilitate a relatively small and seamless leap into code. CDR also involves reviewing the quality of your design from a number of perspectives. These might include modularity, cohesiveness of your classes, coupling between objects, and a number of other metrics that we can lump together and call "OO goodness."
At this time, you might also be making sure that your design meets a set of internal design standards for your organization. Sometimes these standards might make use of design patterns. For example, there may be a project-wide decision to use factories to create instances of our objects. Or there might be standard access mechanisms for interfacing to an underlying relational database. The sequence diagrams, and the detailed class diagrams that go with them, should reflect the real software design, as the senior designers intend for it to be coded. We've made our best attempt to stabilize and validate our requirements and our technical architecture before we got here. CDR is the last stop before code, so at this point we're looking to nail down all of our remaining design issues. Figure 8-1 shows where we are.
|
|