【正文】 eventually find the core of its being, simple and straightforward. Like the socalled high concept from a Hollywood movie, you can describe it in one ore two sentences. This pure description is the starting point.The high concept is quite important because it sets the tone for your project。 it’s a mission statement. You won’t necessarily get it right the first time (you may be in a later phase of the project before it bees pletely clear), but keep trying until it feels right. For example, in an airtraffic control system to a very small airfield。 perhaps there’s only a human controller or none at all. A more useful model won’t concern the solution you’re creating as much as it describes the problem: “Aircraft arrive, unload, service and reload, and depart.”Phase 1: What are we making?It’s necessary to stay focused on the heart of what you’re trying to acplish in this phase: determine what the system is supposed to do. The most valuable tool for this is a collection of what are called “use cases.” Use cases identify key features in the system that will reveal some of the fundamental classes you’ll be using. These are essentially descriptive answers to questions like:“Who will use this system?”“What can those actors do with the system?”“How does this actor do that with this system?”“How else might this work if someone else were doing this, or if the same actor had a different objective?”(to reveal variations)“What problems might happen while doing this with the system?”(to reveal exceptions)If you are designing an autoteller, for example, the use case for a particular aspect of the functionality of the system is able to describe what the autoteller does in every possible situation. Each of these “situations” is referred to as a scenario, and a use case can be considered a collection of scenarios. You can think of a scenario as a question that starts with: “What does the system do if…?” For example, “What does the autoteller do if a customer has just deposited a check within 24 hours and there’s not enough in the account without the check to provide the desired withdrawal?”Use case diagrams are intentionally simple to prevent you from getting bogged down in system implementation details prematurely:The use cases produce the requirements specifications by determining all the interactions that the user may have with the system. You try to discover a full set of use cases for your systems, and once you’ve done that you have the core of what the system is supposed to do. The nice thing about focusing on use cases is that they always bring you back to the essentials and keep you from drifting off into issues that aren’t critical for getting the job done. That is, if you have a full set of use cases you can describe your system and move onto the next phase. You probably won’t get it all figured out perfectly on the first try, but that’s OK. Everything will reveal itself in time, and if you demand a perfect system specification at this point you’ll get stuck.Phase 2: How will we build it?In this phase you must e up with a design that describes what the classes look like and how they will interact. An excellent technique in determining classes and interactions is the ClassResponsibilityCollaboration (CRC) card. Part of the value of this tool is that it’s so lowtech: you start out with a set of blank 3” by 5” cards, and you write on them. Each card represents a single class, and on the card you write:The name of the class. It’s important that this name capture the essence of what the class does, so that it makes sense at a glance.The “responsibilities” of the class: what it should do. This can typically be summarized by just stating the names of the member functions (since those names should be descriptive in a good design), but it does not preclude other notes. If you need to seed the process, look at the problem from a lazy programmer’s standpoint: What objects would you like to magically appear to solve your problem?The “collaborations” of the class: what other classes does it interact with? “Interact” is an intentionally broad term。 it could mean aggregation or simply that some other object exists that will perform services for an object of the class. Collaborations should also consider the audience for this class. For example, if you create a class Firecracker, who is going to observe it, a Chemist or a Spectator? The former will want to know what chemicals go into the construction, and the latter will respond to the colors and shapes released when it explodes.You may feel like the cards should be bigger because of all the information you’d like to get on them, but they are intentionally small, not only to keep your classes small but also to keep you from getting into too much detail too early. If you can’t fit all you need to know about a class on a small card, the class is too plex (either you’re getting too detailed, or you should create more than one class). The ideal class should be understood at a glance. The idea of CRC cards is to assist you in ing up with a first cut of the design so that you can get the big picture and then refine your design.One of the great benefits of CRC cards is in munication. It’s best done realtime, in a group, without puters. Each person takes responsibility for several classes (which at first have no names or other information). You run a live simulation by solving one scenario at a time, deciding which messages are sent to the various objects to satisfy each scenario. As you go through this process, you discover the classes that you need along with their responsibilities and collaborations, and you fill out the cards as you do this. When you’ve moved through all the use cases, you should have a fairly plete first cut of your design.Before I began using CRC cards, the most successful consulting experiences I had when ing up with an initial design involved standing in front of a team, who hadn’t built an OOP project