tij318.htm

这也是我们java老师给我们的thinking in java的一些资料

<p><a name="Index2082"></a>You might also decide at this phase that some additional process structure is necessary, but not the whole nine yards. Understandably, some programmers like to work in &#147;vacation mode,&#148; in which no structure is imposed on the process of developing their work; &#147;It will be done when it&#146;s done.&#148; This can be appealing for a while, but I&#146;ve found that having a few milestones along the way helps to focus and galvanize your efforts around those milestones instead of being stuck with the single goal of &#147;finish the project.&#148; In addition, it divides the project into more bite-sized pieces and makes it seem less threatening (plus the milestones offer more opportunities for celebration). <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap01_263" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p>When I began to study story structure (so that I will someday write a novel) I was initially resistant to the idea of structure, feeling that I wrote best when I simply let it flow onto the page. But I later realized that when I write about computers the structure is clear enough to me that I don&#146;t have to think about it very much. I still structure my work, albeit only semi-consciously in my head. Even if you think that your plan is to just start coding, you still somehow go through the subsequent phases while asking and answering certain questions. <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap01_264" title="Send BackTalk Comment">Feedback</a></font><br></p>
<h3>
<a name="_Toc408018411"></a><a name="_Toc24775972"></a><a name="Heading24362"></a>The
mission statement<br></h3>
<p><a name="Index2083"></a><a name="Index2084"></a>Any system you build, no matter how complicated, has a fundamental purpose&#151;the business that it&#146;s in, the basic need that it satisfies. If you can look past the user interface, the hardware- or system-specific details, the coding algorithms and the efficiency problems, you will eventually find the core of its being&#151;simple and straightforward. Like the so-called <a name="Index2085"></a><a name="Index2086"></a><i>high concept</i> from a Hollywood movie, you can describe it in one or two sentences. This pure description is the starting point. <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap01_265" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p>The high concept is quite important because it sets the tone for your project; it&#146;s a mission statement. You won&#146;t necessarily get it right the first time (you may be in a later phase of the project before it becomes completely clear), but keep trying until it feels right. For example, in an air-traffic control system you may start out with a high concept focused on the system that you&#146;re building: &#147;The tower program keeps track of the aircraft.&#148; But consider what happens when you shrink the system to a very small airfield; perhaps there&#146;s only a human controller, or none at all. A more useful model won&#146;t concern the solution you&#146;re creating as much as it describes the problem: &#147;Aircraft arrive, unload, service and reload, then depart.&#148; <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap01_266" title="Send BackTalk Comment">Feedback</a></font><br></p>
<h2>
<a name="_Toc472654693"></a><a name="_Toc24775973"></a><a name="Heading24365"></a>Phase
1: What are we making?</h2>
<p>In the previous generation of program design (called <i>procedural design</i>), this is called &#147;creating the <a name="Index2087"></a><a name="Index2088"></a><i>requirements analysis</i> and <a name="Index2089"></a><a name="Index2090"></a><i>system specification</i>.&#148; These, of course, were places to get lost; documents with intimidating names that could become big projects in their own right. Their intention was good, however. The requirements analysis says &#147;Make a list of the guidelines we will use to know when the job is done and the customer is satisfied.&#148;<sup><a name="fnB104" href="#fn104">[104]</a></sup> The system specification says &#147;Here&#146;s a description of <i>what</i> the program will do (not <i>how</i>) to satisfy the requirements.&#148; The requirements analysis is really a contract between you and the customer (even if the customer works within your company, or is some other object or system). The system specification is a top-level exploration into the problem and in some sense a discovery of whether it can be done and how long it will take. Since both of these will require consensus among people (and because they will usually change over time), I think it&#146;s best to keep them as bare as possible&#151;ideally, to lists and basic diagrams&#151;to save time (this is in line with Extreme Programming, which advocates very minimal documentation, albeit for small- to medium-sized projects). You might have other constraints that require you to expand them into bigger documents, but by keeping the initial document small and concise, it can be created in a few sessions of group brainstorming with a leader who dynamically creates the description. This not only solicits input from everyone, it also fosters initial buy-in and agreement by everyone on the team. Perhaps most importantly, it can kick off a project with a lot of enthusiasm. <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap01_267" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p>It&#146;s necessary to stay focused on the heart of what you&#146;re trying to accomplish in this phase: Determine what the system is supposed to do. The most valuable tool for this is a collection of what are called &#147;use cases,&#148; or in Extreme Programming, &#147;user stories.&#148; Use cases identify key features in the system that will reveal some of the fundamental classes you&#146;ll be using. These are essentially descriptive answers to questions like:<a name="Index2091"></a><sup><a name="fnB105" href="#fn105">[105]</a></sup> <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap01_268" title="Send BackTalk Comment">Feedback</a></font><br></p>
<ul>
<li>&#147;Who will use this system?&#148; </li>
<li>&#147;What can those actors do with the system?&#148; </li>
<li>&#147;How does <i>this</i> actor do <i>that</i> with this
system?&#148;</li>
<li>&#147;How else might this work if someone else were doing this, or if the
same actor had a different objective?&#148; (to reveal variations)</li>
<li>&#147;What problems might happen while doing this with the system?&#148;
(to reveal
exceptions)</li></ul><p>If you are designing a bank auto-teller, for example, the use case for a particular aspect of the functionality of the system is able to describe what the auto-teller does in every possible situation. Each of these &#147;situations&#148; is referred to as a <a name="Index2092"></a><i>scenario</i>, and a use case can be considered a collection of scenarios. You can think of a scenario as a question that starts with: &#147;What does the system do if...?&#148; For example, &#147;What does the auto-teller do if a customer has just deposited a check within the last 24 hours, and there&#146;s not enough in the account without the check having cleared to provide a desired withdrawal?&#148; <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap01_269" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p><a name="Index2093"></a>Use case diagrams are intentionally simple to prevent you from getting bogged down in system implementation details prematurely:<br></p>
<p align="center"><img src="TIJ337.png" 	alt="TIJ337.png" border="0" ><br></p>
<p>Each stick person represents an &#147;actor,&#148; which is typically a human or some other kind of free agent. (These can even be other computer systems, as is the case with &#147;ATM.&#148;) The box represents the boundary of your system. The ellipses represent the use cases, which are descriptions of valuable work that can be performed with the system. The lines between the actors and the use cases represent the interactions. <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap01_270" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p><a name="Index2094"></a>It doesn&#146;t matter how the system is actually implemented, as long as it looks like this to the user. <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap01_271" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p>A use case does not need to be terribly complex, even if the underlying system is complex. It is only intended to show the system as it appears to the user. For example: <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap01_272" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p align="center"><img src="TIJ338.png" 	alt="TIJ338.png" border="0" ><br></p>
<p>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 system, and once you&#146;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&#146;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 on to the next phase. You probably won&#146;t get it all figured out perfectly on the first try, but that&#146;s OK. Everything will reveal itself in time, and if you demand a perfect system specification at this point you&#146;ll get stuck. <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap01_273" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p>If you do get stuck, you can kick-start this phase by using a rough approximation tool: Describe the system in a few paragraphs and then look for nouns and verbs. The nouns can suggest actors, context of the use case (e.g., &#147;lobby&#148;), or artifacts manipulated in the use case. Verbs can suggest interactions between actors and use cases, and specify steps within the use case. You&#146;ll also discover that nouns and verbs produce objects and messages during the design phase (and note that use cases describe interactions between subsystems, so the &#147;noun and verb&#148; technique can be used only as a brainstorming tool because it does not generate use cases).<sup><a name="fnB106" href="#fn106">[106]</a></sup> <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap01_274" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p>The boundary between a use case and an actor can point out the existence of a user interface, but it does not define such a user interface. For a process of defining and creating user interfaces, see <a name="Index2095"></a><a name="Index2096"></a><i>Software for Use</i> by Larry Constantine and Lucy Lockwood, (Addison-Wesley Longman, 1999) or go to <i>www.ForUse.com</i>. <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap01_275" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p>Although it&#146;s a black art, at this point some kind of basic scheduling is important. You now have an overview of what you&#146;re building, so you&#146;ll probably be able to get some idea of how long it will take. A lot of factors come into play here. If you estimate a long schedule then the company might decide not to build it (and thus use their resources on something more reasonable&#151;that&#146;s a <a name="Index2097"></a><i>good</i> thing). Or a manager might have already decided how long the project should take and will try to influence your estimate. But it&#146;s best to have an honest schedule from the beginning and deal with the tough decisions early. There have been a lot of attempts to come up with accurate scheduling techniques (much like techniques to predict the stock market), but probably the best approach is to rely on your experience and intuition. Get a gut feeling for how long it will really take, then double that and add 10 percent. Your gut feeling is probably correct; you <i>can</i> get something working in that time. The &#147;doubling&#148; will turn that into something decent, and the 10 percent will deal with the final polishing and details.<sup><a name="fnB107" href="#fn107">[107]</a></sup> However you want to explain it, and regardless of the moans and manipulations that happen when you reveal such a schedule, it just seems to work out that way.<sup><a name="fnB108" href="#fn108">[108]</a></sup> <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap01_276" title="Send BackTalk Comment">Feedback</a></font><br></p>
<h2>
<a name="_Toc408018412"></a><a name="_Toc472654694"></a><a name="_Toc24775974"></a><a name="Heading24389"></a>Phase
2: How will we build it?</h2>
<p>In this phase you must come 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 <a name="Index2098"></a><a name="Index2099"></a><i>Class-Responsibility-Collaboration</i> (CRC) card. Part of the value of this tool is that it&#146;s so low-tech: You start out with a set of blank 3 x 5 cards, and you write on them. Each card represents a single class, and on the card you write: <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap01_277" title="Send BackTalk Comment">Feedback</a></font><br></p>
<ol>
<li>The name of the class. It&#146;s important that this name capture the
essence of what the class does, so that it makes sense at a glance. <font
size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap01_278"
title="Send BackTalk Comment">Feedback</a></font></li>
<li>The &#147;responsibilities&#148; of the class: what it should do. This can
typically be summarized by just stating the names of the methods (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&#146;s standpoint: What objects would you like to magically appear
to solve your problem? <font size="-2"><a