Table of Contents
We now have the problem we are trying to solve specified in the language of a putative solution. In the Design Phase, we construct all the details of that solution.
The blurred boundary between Analysis and Design is reflected in their use of many of the same UML tools. In this chapter we will mostly be reusing UML technology we have already met once. The big step is casting everything into concrete terms. We move from the abstract concepts of analysis to their concrete realization.
Once again the recursive, and iterative nature of our process means we will come back to the Design phase many times in the future.
The design process extends the modeling effort beyond the business concerns and into the solutions space. It is during this effort that you decide whether you are going to use Java, C++, J2EE, CORBA, SOAP, Dial up line, internet connection dedicated line, XML, etc. Many of these decisions will impact directly the PSM model, others may only be reflected in the documents produced.
...
Strength of CRC cards during Design
Spreading Objet-Oriented Design Expertise
Design Reviews
Framework for Implementation
Informal Notation
Choice of supporting software components
Performance Requirements
In this phase developers replace some of the domain experts in the group, but there should always be at least one domain expert in the group.
The focus of the group moves from what is to be done to how to do it. The classes from the solution domain are added to those defined in the analysis phase. Think about what classes are needed to make the system work. Do you need a List class to hold objects? Do you need classes to handle exceptions? Do you need wrapper classes for other subsystems? New classes that are looked for in this part, are classes that support the implementation of the system.
During the design phase the distinction between class and object becomes important. Think about the objects in your scenarios. Who creates the objects? What happens when it is created and destroyed? What is the lifetime of the object vs. the lifetime of the information held be the object?
Now is the time to look at what information the objects hold compared to what is requested from other classes or computed on the fly. Use the back of the card to record the attributes found for the classes. Break you responsibilities into subresponsibilities and list the subresponsibilities indented under the main responsibilities. Move the collaborators next to the subresponsibilities that use them.
After the Collaborator class on your card list the responsibility of the used class that is used in the collaboration. After the collaborating responsibilities on your cards, list the data passed back by the collaborating object in parenthesis.
Redo the scenarios you did in the analysis phase, but know take into consideration all of the design heuristics discussed. Make up your own scenarios and try them.