the oo design process4.mht

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

      the money "just like a bank." That is, I would charge him twice as =
much=20
      interest as he made by saving. This extra loss was enough to =
discourage=20
      him from making the withdrawal (so my primary goal of teaching him =
how to=20
      save was indeed working), but I did think that the ability to make =
a loan=20
      at some point in the future would be handy. Consequently, a second =

      addition to the problem statement is in order:</P>
      <P>
      <BLOCKQUOTE>Kids should be able to borrow money from the bank, but =
this=20
        process should, again, mimic a real bank. The interest rate on =
loans=20
        must be high enough to make the point that borrowing is =
expensive (say,=20
        twice the savings rate), and the bank should impose a =
requirement for a=20
        regular payment over a fixed, relatively short, payback period =
(a few=20
        months at the outside). The kid can pay back the loan using =
automatic,=20
        periodic, deductions from savings. Again, as the point of the =
exercise=20
        is to teach money management, the bank must be able to show the =
kid a=20
        loan statement that makes it abundantly clear how much the loan =
costs.=20
        Moreover, the passbook should highlight the automatic =
deductions, show=20
        both the principal reduction and interest paid. The bank charges =
a=20
        penalty, set by the parent, for late payments.</BLOCKQUOTE>
      <P></P>
      <P>
      <BLOCKQUOTE>The bank caclulates loan interest as "simple" interest =
--=20
        for every payment period, multiply the current outstanding =
principal by=20
        the current interest rate to determine the interest payment. Any =

        remaining money from the payment is used to reduce principal. =
Kids=20
        should be able to reduce the principal amount at any time by =
making an=20
        extra payment (or a larger-than-usual payment) into the loan=20
      account.</BLOCKQUOTE>
      <P></P>
      <P>
      <BLOCKQUOTE>The standard formula for computing the payment amount =
is:=20
        <TABLE border=3D0 cellPadding=3D0 class=3Dcode-sample =
width=3D"100%">
          <TBODY>
          <TR>
            <TD><PRE>rate /=3D 1200;  // Adjust rate to per-month
tmp =3D pow( 1.0 + rate, (double) number_of_periods );
return( (tmp * present_value * rate) / (tmp - 1.0) =
);</PRE></TD></TR></TBODY></TABLE></BLOCKQUOTE>
      <P></P>
      <P>
      <BLOCKQUOTE>where <I>rate</I> is the annual interest rate (that =
is, 11.5=20
        for 11.5%).</BLOCKQUOTE>
      <P></P><A name=3D4>
      <P><STRONG class=3Dsubhead>Gold plating</STRONG> <BR>My main =
reservation=20
      with this last addition is that Philip did not actually make a =
loan, so=20
      I'm not sure I really need to implement loans. There's no point in =

      implementing features that won't be used. In fact, that's a big =
problem=20
      with many existing programs: they're chock full of features that=20
      <I>might</I> need to be there, but which aren't actually used by =
anyone.=20
      This sort of "gold plating" does nothing but make the program more =

      expensive by virtually every measure: it costs more to build, it =
takes=20
      more time to build, and it costs more to the user because the =
company has=20
      to recoup the construction costs.</P>
      <P>The golden rule is:</P>
      <P>
      <BLOCKQUOTE>A program should implement exactly those capabilities =
that=20
        are actually used by the end user, no more, no less. =
</BLOCKQUOTE>
      <P></P>
      <P>The overall design, however, should be sufficiently flexible =
that new=20
      features can be added easily at some later date.</P>
      <P>With respect to the current problem, I decide to leave out =
loans for=20
      the time being in order to get the program to market faster. I'll =
try to=20
      come up with a design that will easily let me add them in at a =
later date,=20
      however.</P><A name=3D5>
      <P><STRONG class=3Dsubhead>Users, marketing, and sales</STRONG> =
<BR>One=20
      final point to bring up with respect to the mock-up: Jacob Nielsen =
once=20
      wrote (unfortunately, I can't remember exactly where) that showing =
your=20
      prototype to two users is twice as useful as showing it to one, =
but=20
      showing it to three users is only about 2.5 times as useful as =
showing it=20
      to one. Running it past more than three users is a waste of =
time.</P>
      <P>Having a real end user actually be a part of the design team is =

      essential, not just to help in the product definition, but to =
provide=20
      constant feedback throughout the design and implementation =
process. Having=20
      two users is even better, but the second one can be on call for =
doing=20
      things like checking out live prototypes and mock-ups. In fact, =
it's=20
      probably better if the second user isn't intimately familiar with =
the=20
      entire design process so that his or her input will be as fresh =
and=20
      unbiased as possible.</P>
      <P>If a real end user isn't available, someone from your =
<I>marketing</I>=20
      (not your sales) department -- a user surrogate, if you will -- =
can be=20
      used. This distinction between marketing and sales is important. =
The main=20
      purpose of a good marketing department is research. Marketing is =
the=20
      process of trying to figure out what program will be truly useful =
to real=20
      people in the real world who are doing real work. They accomplish =
this=20
      work with surveys, one-to-one conversations, and so forth. The =
notions of=20
      "business development" and marketing go hand in hand. In a very =
real=20
      sense, the formal problem statement is a marketing document, but =
it must=20
      be a collaborative effort between the marketing and technical =
teams to=20
      ensure that the program can actually be built in a timely fashion. =
The=20
      classic trade-off between features and time-to-market is a =
marketing=20
      decision.</P>
      <P>The job of the sales department, on the other hand is to sell =
an=20
      existing product. The sales department has absolutely no business=20
      specifying features, and should <I>never</I> be permitted to =
communicate=20
      directly with the technical side. Sales should suggest a new =
feature to=20
      marketing, which would then verify that the feature is actually =
valuable=20
      to the user community. If the feature was indeed valuable, the =
marketing=20
      side would then collaborate with the technical side to add the =
feature to=20
      the design, and eventually to the program. Programmers, by the =
way,=20
      <I>must</I> add features that are specified by marketing, no =
matter how=20
      hard it is to add the feature. It's marketing's job to come up =
with the=20
      minimum feature set required for the product to be dominant in the =
market.=20
      If you don't have those features, the product won't be successful. =
A=20
      programmer cannot be permitted to sabotage the success of the =
company=20
      simply because adding a feature is inconvenient.</P>
      <P>Things go horribly wrong -- and many of us have experienced =
this=20
      process -- when the design is driven by sales rather than =
marketing. One=20
      customer calls in with a request, which is turned by the sales =
person into=20
      an OH-MY-GAWD-WE-HAVE-TO-HAVE-THIS-YESTERDAY requirement. Some =
hapless=20
      programmer is then pulled off useful work and forced to work on =
this new=20
      feature. Three days later, the same thing happens again, and the =
push to=20
      add the first feature is abandoned and replaced by some new=20
      GOT-TO-HAVE-IT-NOW feature. The end result is that nothing ever =
gets=20
      finished. If by some miracle a functioning program is produced, =
the=20
      program probably won't do anything useful. It's just plain wrong =
to add a=20
      feature or modify a design solely because one customer has asked =
for it;=20
      when you do taht, you run the risk of turning your software =
company into a=20
      custom-software house with one customer. The real question is: Is =
this=20
      feature useful to the broader user community? And that's a =
marketing=20
      question.</P><A name=3D6>
      <P><STRONG class=3Dsubhead>So that's it for mock-ups</STRONG> =
<BR>So much=20
      for the mock-up. Next month we'll start with use-case analysis and =
UI=20
      design.</P><A name=3Dresources>
      <P><STRONG class=3Dsubhead>Resources</STRONG>=20
      <UL>
        <LI>Kent Beck's Extreme Programming is described in <A=20
        =
href=3D"http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=3D0201=
616416&amp;from=3DNCN454"=20
        target=3D_blank><I>Extreme Programming Explained: Embrace =
Change</I></A>=20
        (Reading: Addison Wesley, 2000; ISBN 0-201-61641-6).=20
        <LI>To see the real difference between a mock-up and a =
prototype, check=20
        out PBS's documentary on the building of the Boeing 777: <A=20
        =
href=3D"http://www.amazon.com/exec/obidos/ASIN/B00004C8SC/qid=3D974054497=
/sr=3D2-1/103-1113157-1338245">21st=20
        Century Jet: The Building of the 777</A>.=20
        <LI>Jacob Nielsen's thoughts on prototyping in the context of =
usability=20
        are described in <A=20
        =
href=3D"http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=3D0125=
184069&amp;from=3DNCN454"=20
        target=3D_blank><I>Usability Engineering</I></A> (San Francisco: =
Morgan=20
        Kaufmann Publishers, 1993; ISBN 0-12-518406-9). </LI></UL><A =
name=3Dauthor>
      <P><STRONG class=3Dsubhead>About the author</STRONG> <BR><!-- <img =
SRC=3D"http://www.ibm.com/developer/i/p-author.jpg" BORDER=3D0 =
width=3D64 height=3D71 align=3DLEFT> -->Allen=20
      Holub is the Chief Technical Officer at <A=20
      href=3D"http://www.net-reliance.com/">NetReliance</A>, a =
San-Francisco-based=20
      company that's building a secure global infrastructure for =
conducting=20
      trusted business transactions over the net.=20
      <P>He has worked in the computer industry since 1979, and is =
widely=20
      published in magazines (<EM>Dr. Dobb's Journal</EM>, =
<EM>Programmers=20
      Journal</EM>, <EM>Byte</EM>, <EM>MSJ</EM>, among others). He =
writes the=20
      "Java Toolbox" column for the online magazine <A=20
      href=3D"http://www.javaworld.com/">JavaWorld</A>, and also writes =
the "OO=20
      Design Process" column for the <A=20
      href=3D"http://www.ibm.com/developer/components">IBM =
developerWorks=20
      Components zone</A>. He also moderates the <A=20
      =
href=3D"http://forums.itworld.com/webx?[e-mail]^0@.ee6b806">IT=
world=20
      Programming Theory &amp; Practice</A> discussion group.=20
      <P>Allen has <A =
href=3D"http://www.holub.com/allenholub.html#books">eight=20
      books</A> to his credit, the latest of which covers the traps and =
pitfalls=20
      of Java threading (<A=20
      =
href=3D"http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=3D1893=
115100&amp;from=3DNCN454"=20
      target=3D_blank><I>Taming Java Threads</I></A> ). He's been =
designing and=20
      building object-oriented software for longer than he cares to =
remember (in=20
      C++ and Java). He teaches OO design and Java for the University of =

      California, Berkeley, Extension (since 1982). Contact Allen via =
his Web=20
      site <A href=3D"http://www.holub.com/">http://www.holub.com/</A>. =
<!-- End paper --><BR></P></TD>
    <TD vAlign=3Dtop width=3D8><!-- gutter--><IMG height=3D1=20
      src=3D"http://www.cn.ibm.com/developerWorks/i/c.gif" =
width=3D8>&nbsp;</TD><!-- Formatter, when paper is in folder, change =
above to=20