the oo design process4.mht

VC书籍介绍C++的应用的TheOODesignProcess.zip 电子书好用的

        width=3D1></FONT></TD></TR>
        <TR>
          <TD><FONT face=3D=CB=CE=CC=E5 size=3D2>&nbsp;<A=20
            =
href=3D"http://www.cn.ibm.com/developerWorks/components/oo-design4/index_=
eng.shtml#1">Getting=20
            it right</A></FONT></TD></TR>
        <TR>
          <TD><FONT face=3D=CB=CE=CC=E5 size=3D2>&nbsp;<A=20
            =
href=3D"http://www.cn.ibm.com/developerWorks/components/oo-design4/index_=
eng.shtml#2">Mock=20
            up a solution</A></FONT></TD></TR>
        <TR>
          <TD><FONT face=3D=CB=CE=CC=E5 size=3D2>&nbsp;<A=20
            =
href=3D"http://www.cn.ibm.com/developerWorks/components/oo-design4/index_=
eng.shtml#3">Submit=20
            the mock-up </A></FONT></TD></TR>
        <TR>
          <TD><FONT face=3D=CB=CE=CC=E5 size=3D2>&nbsp;<A=20
            =
href=3D"http://www.cn.ibm.com/developerWorks/components/oo-design4/index_=
eng.shtml#4">Gold=20
            plating</A></FONT></TD></TR>
        <TR>
          <TD><FONT face=3D=CB=CE=CC=E5 size=3D2>&nbsp;<A=20
            =
href=3D"http://www.cn.ibm.com/developerWorks/components/oo-design4/index_=
eng.shtml#5">Users,=20
            marketing, and sales</A></FONT></TD></TR>
        <TR>
          <TD><FONT face=3D=CB=CE=CC=E5 size=3D2>&nbsp;<A=20
            =
href=3D"http://www.cn.ibm.com/developerWorks/components/oo-design4/index_=
eng.shtml#6">So=20
            that's it</A></FONT></TD></TR>
        <TR>
          <TD><FONT face=3D=CB=CE=CC=E5 size=3D2>&nbsp;<A=20
            =
href=3D"http://www.cn.ibm.com/developerWorks/components/oo-design4/index_=
eng.shtml#resources">Resources</A></FONT></TD></TR>
        <TR>
          <TD><FONT face=3D=CB=CE=CC=E5 size=3D2>&nbsp;<A=20
            =
href=3D"http://www.cn.ibm.com/developerWorks/components/oo-design4/index_=
eng.shtml#author">About=20
            the author</A></FONT></TD></TR>
        <TR>
          <TD bgColor=3D#000000><FONT face=3Dhelvetica,helv,arial =
size=3D-3><IMG=20
            height=3D3 =
src=3D"http://www.cn.ibm.com/developerWorks/i/c.gif"=20
            width=3D137></FONT></TD></TR></TBODY></TABLE></P><!-- End =
Table of Contents -->
      <P>
      <BLOCKQUOTE>Now that we have defined and refined the problem =
statement,=20
        it's time to move on to a mock-up of our educational=20
software.</BLOCKQUOTE>
      <P></P>
      <P>The article continues my series on the OO design process. The =
first=20
      three parts are:=20
      <UL>
        <LI><A=20
        =
href=3D"http://www.cn.ibm.com/developerWorks/components/oo-design1/index.=
shtml">Getting=20
        started</A>=20
        <LI><A=20
        =
href=3D"http://www.cn.ibm.com/developerWorks/components/oo-design2/index.=
shtml">Beginning=20
        to design software</A>=20
        <LI><A=20
        =
href=3D"http://www.cn.ibm.com/developerWorks/components/oo-design3/index.=
shtml">Refining=20
        the problem definition</A> </LI></UL>
      <P></P>
      <P>This month, I move the problem statement toward a solution by =
creating=20
      a mock-up that I deploy to my user community (my 7-year-old =
son).</P><A=20
      name=3D1>
      <P><STRONG class=3Dsubhead>Getting it right</STRONG> <BR>After =
capturing the=20
      problem definition on paper, the next step is to make sure that =
you've=20
      "got it right." There are several activities that you can use for =
this=20
      purpose (mock-ups, UI prototypes, and others), and I'll go through =
them=20
      this and next month. Bear in mind as you read these articles that =
it's the=20
      nature of a magazine article to be sequential, but in the real =
world many=20
      of these activities go on in parallel. For example, I'll be =
refining a=20
      mock-up as I create a UI; I'll be using information discovered by =
use-case=20
      analysis to improve the UI, and as I work on the UI, I'll identify =
flaws=20
      in my use-case analysis. By the same token, as I start working on =
my=20
      mock-up, I'll inevitably find flaws in my original problem =
statement and=20
      will have to go back and fix them. Design is not an orderly =
step-by-step=20
      process where you can neatly tie up all the loose ends of one =
activity=20
      before moving on to the next. Moreover, you're constantly =
revisiting work=20
      that you thought was finished, updating it with information you =
discover=20
      in the work you're doing right now.</P>
      <P>This constant revision is just part of the process, and it's =
essential=20
      that you do it. It's all too easy for a design document to become =
"stale"=20
      because it's not updated in this way. Your design documents will =
be=20
      essential documentation for a maintenance programmer who will see =
the code=20
      for the first time a year from now. Though I think that code can =
be=20
      self-documenting if written carefully -- with well chosen variable =
and=20
      method names, good structure, and so forth -- I disagree with Kent =
Beck=20
      and the "Extreme Programming" crowd when they claim that you =
shouldn't=20
      bother to try to keep design documents in sync with the actual =
code=20
      because busy programmers can never be bothered to do so.</P>
      <P>Since the design is so fluid, my preference is to keep as much =
of it as=20
      possible (literally) visible. Stravinsky, when he wrote the =
<I>Rite of=20
      Spring</I>, put the entire score up on the walls of his apartment =
so he=20
      could look at the piece as a whole. This is a good idea with =
software as=20
      well.</P>
      <P>For example, rather than using OO CASE tools, which hide the =
design=20
      documents inside the computer where you can't see them, I prefer =
to use=20
      vast quantities of white board, and leave as much as possible on =
the white=20
      board for as long as possible. 50-yard roles of white butcher =
paper are=20
      also a good medium for this purpose. Only when things get =
relatively=20
      stable will I consider moving the design into a CASE tool, and I =
won't use=20
      any CASE tool that won't let me easily print out the entire design =
so that=20
      I can tape it back up on the wall.</P><A name=3D2>
      <P><STRONG class=3Dsubhead>Mock up a solution</STRONG> <BR>One of =
the first=20
      steps in the direction of "getting it right" is to make sure that =
this=20
      problem is worth solving. I usually answer that question with a=20
      <I>mock-up</I>.</P>
      <P>There is an important difference between a "prototype" and a =
"mock-up."=20
      Using an aviation analogy, the "prototype" Boeing 777 was a=20
      fully-functional airplane. Other than the fact that it was pretty =
beat up=20
      by the time that the design process was over, it was exactly the =
airplane=20
      that Boeing shipped. A prototype is really a partially built =
program, not=20
      a throwaway. Like the 777, you use the prototype program as a test =
bed for=20
      design ideas. If the idea works, you keep it in the prototype. =
That is,=20
      the prototype is a partially built version of (usually, part of) =
the final=20
      program. Prototypes have to be carefully designed and constructed; =
this is=20
      the finished program you're working on. This sort of development =
-- the=20
      gradual refinement of a prototype until you arrive at a finished =
product=20
      -- is often called "incremental refinement."</P>
      <P>In the current situation, I didn't want a prototype, though. I =
wanted a=20
      mock-up. I wanted to see if the whole idea of a bank for kids made =
sense;=20
      I didn't want to build the thing. A mock-up, then, is something =
you pungle=20
      together out of duct tape, chewing gum, paper clips, cardboard, =
and paint=20
      just to test a concept that you don't necessarily want to =
implement.=20
      Boeing might have mocked up the 777 cockpit just to see if all the =

      switches could be reached from the pilot's seat. They could do =
that using=20
      plywood and a seat out of an existing airplane. The =
<I>prototype</I>=20
      cockpit, on the other hand, would be full size, completely wired, =
with=20
      real instruments, seats, and switches in it. It might be hooked up =
to a=20
      computer flight simulator rather than an airplane, but you could =
put it=20
      into an airplane if you wanted to.</P>
      <P>Another way that you can look at a prototype is that it =
provides the=20
      answers for important questions that come up at design time. For =
example,=20
      often, the only way to answer the question "do we have enough =
bandwidth to=20
      do X" is to prototype the part of the program that does "X" (or at =
least=20
      the network-related parts of the program). If you don't create the =
real=20
      code (that is, if you mock up the problem in an artificial way), =
you=20
      haven't actually answered the question. The real version might not =
behave=20
      like the mock-up.</P>
      <P>So, I implemented a mock-up for the Bank of Allen in Excel. In =
the=20
      mock-up, the bank was a simple spreadsheet, one row per day. You =
could=20
      make deposits by entering them in the correct cell of the =
spreadsheet, and=20
      see the current balance and accumulated interest in another cell. =
This=20
      would be a miserable UI for the real program, of course, but this =
is just=20
      a mock-up.</P><A name=3D3>
      <P><STRONG class=3Dsubhead>Submit the mock-up to a real =
user</STRONG> <BR>I=20
      then tried out the concept on my then-7-year-old son, Philip, =
using my=20
      mock-up. The results of the experiment were stunningly successful. =
First=20
      of all, Philip figured out the notion of compound interest on his =
own.</P>
      <P>
      <BLOCKQUOTE>I said: "So, at the end of the month, you get back =
your=20
        original dollar, plus another nickel that the bank pays you just =
to keep=20
        your money." <BR><BR>He said: "So the next month I get even more =
than a=20
        nickel because I now have more money in the bank?" </BLOCKQUOTE>
      <P></P>
      <P>He clearly liked the idea of making money without working for =
it. The=20
      proof of the concept was that during the months-long trial using =
the Excel=20
      mock-up, Philip didn't withdraw a penny. Cool.</P>
      <P>Two concrete improvements did emerge from the mock-up. It =
turned out=20
      that Philip was constantly asking how much money he had in his =
account.=20
      The one concrete effect of the mock-up process was to modify the =
Problem=20
      Statement as follows to reflect this new requirement:</P>
      <P>
      <BLOCKQUOTE>It's important that the kids see how interest =
accumulates on=20
        a daily basis; monthly interest postings are not adequate. =
Consequently,=20
        the bank compounds interest daily, and posts daily. The passbook =
shows=20
        this daily posting, even if there is no other activity on that =
day. This=20
        way the kid can see interest accumulating, even though no =
deposits have=20
        been made. The total interest earned over the life of the =
account is=20
        also prominently displayed in the passbook. </BLOCKQUOTE>
      <P></P>
      <P>The second issue didn't appear until the mock-up was in use for =
some=20
      time. Philip did eventually make a withdrawal to buy a Pokemon =
card that=20
      he had his eye on, but he was short a dollar or so. I offered to =
loan him=20