the oo design process3.mht

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

called=20
              the Bank of Allen.</BLOCKQUOTE>
            <P></P>
            <P>The next step that I usually take when starting a problem =

            definition is to create a glossary. In general, terms that =
are=20
            immediately recognizable by someone familiar with the domain =
don't=20
            need to be defined, but often a term has an ambiguous =
meaning or is=20
            used in a limited way in the current problem, so it will =
have to be=20
            explicitly defined.</P>
            <P>One <I>gotcha</I> in a problem statement is =
inconsistency. It's=20
            essential that one word is not used to mean two different =
things,=20
            and that two different words are never used to mean the same =
thing.=20
            Your first line of defense is a glossary. Typically, you =
would not=20
            define problem-domain terms here. For example, you wouldn't =
define=20
            <I>credit</I> or <I>interest</I> if the problem domain was=20
            accounting. The current problem domain is parenting, =
however, so=20
            terms like <I>credit</I> need to be defined precisely.</P>
            <P>The glossary is also helpful in our main goal, which is =
to=20
            identify the key problem-level abstractions. Often essential =
words=20
            and concepts that appear in the glossary don't appear in the =
main=20
            body of the problem statement. For example, the definition =
of=20
            <I>passbook</I> introduces the term <I>transaction</I>. (The =
notion=20
            of a transaction turned out to be significant, although I =
didn't=20
            come to this realization immediately.)</P>
            <P>It's also helpful to add an Implementation Details =
section in the=20
            glossary to provide a place to record these details, even =
though=20
            they're not actually part of the problem statement per se. =
The sorts=20
            of things that normally would go in a Functional =
Requirements=20
            Specification often go into the Implementation Details.</P>
            <P>Here's my first-pass glossary and implementation =
details.</P><!-- Sidebar -->
            <TABLE align=3Dcenter border=3D1 cellPadding=3D3 =
class=3Dsidebar=20
width=3D"80%">
              <TBODY>
              <TR>
                <TD>
                  <P><A name=3D"">
                  <P><STRONG class=3Dsubhead>Glossary</STRONG>=20
                  <TABLE border=3D0 cellPadding=3D4 cellSpacing=3D0>
                    <TBODY>
                    <TR>
                      <TD align=3Dleft =
vAlign=3Dbaseline><B>Balance</B></TD>
                      <TD align=3Dleft vAlign=3Dbaseline>The amount of =
money=20
                        currently in your account.</TD></TR>
                    <TR>
                      <TD align=3Dleft =
vAlign=3Dbaseline><B>Bank</B></TD>
                      <TD align=3Dleft vAlign=3Dbaseline>A =
parent.</TD></TR>
                    <TR>
                      <TD align=3Dleft =
vAlign=3Dbaseline><B>Credit</B></TD>
                      <TD align=3Dleft vAlign=3Dbaseline>A deposit to =
your account=20
                        made by the bank rather than yourself.</TD></TR>
                    <TR>
                      <TD align=3Dleft =
vAlign=3Dbaseline><B>Deposit</B></TD>
                      <TD align=3Dleft vAlign=3Dbaseline>The act of =
putting money=20
                        in the bank; increases your balance.</TD></TR>
                    <TR>
                      <TD align=3Dleft =
vAlign=3Dbaseline><B>Interest</B></TD>
                      <TD align=3Dleft vAlign=3Dbaseline>A credit given =
as a=20
                        reward for keeping your money in the bank. =
Interest is=20
                        computed daily by crediting to the account a =
fixed=20
                        percentage of the current account's balance (the =

                        "principle"). If the interest rate is 10%/month, =
you'd=20
                        multiply the balance by (.10/30) every day of =
that=20
                      month.</TD></TR>
                    <TR>
                      <TD align=3Dleft =
vAlign=3Dbaseline><B>Passbook</B></TD>
                      <TD align=3Dleft vAlign=3Dbaseline>A log of the =
transactions=20
                        that occurred in some account along with summary =

                        information. Kids must get their passbooks from =
the=20
                      bank.</TD></TR>
                    <TR>
                      <TD align=3Dleft =
vAlign=3Dbaseline><B>Withdrawal</B></TD>
                      <TD align=3Dleft vAlign=3Dbaseline>The act of =
removing money=20
                        from the bank; decreases your=20
                  balance.</TD></TR></TBODY></TABLE></P><A name=3D2>
                  <P><B>Implementation details:</B> <BR><I>This section =
is not=20
                  part of the problem statement per se. It's just a list =
of=20
                  things that occur to me as I'm putting together the =
problem=20
                  statement.</I></P>
                  <UL>
                    <LI>Parents can set up a password for themselves the =
first=20
                    time the program boots. Thereafter, you'll have to =
know your=20
                    password to log on as a parent. Parents can change =
the=20
                    password at any time.=20
                    <LI>Changes in interest rate take effect =
immediately, but do=20
                    not affect previous day's balances at all. =
(Passbooks do not=20
                    have to (but may) reflect the new rate for any =
deposits made=20
                    on the date the rate changed, even those made =
earlier in the=20
                    day.)=20
                    <LI>The kids must ask the bank for their passbook.=20
                    <LI>Passbooks are updated every time they're given =
to a kid.=20

                    <LI>Some means for parents to backup or restore the =
entire=20
                    bank must be provided. This could be a simple file =
copy or=20
                    something more elaborate. =
</LI></UL></A></TD></TR></TBODY></TABLE><!-- End sidebar -->
            <P></P></TD></TR></TBODY></TABLE><A name=3D3>
      <P><STRONG class=3Dsubhead>Verify and refine the problem =
statement</STRONG>=20
      <BR>Feeling pleased with myself for having prepared a reasonable =
problem=20
      statement, the next step was to do a design review. I pressed my =
wife, DJ,=20
      who is a programmer and domain expert -- a parent -- into service. =
She=20
      found various minor grammatical problems (which I must confess, I =
have=20
      fixed in the initial statement that you just read), but she found =
one=20
      serious flaw that I hadn't thought of. "You can't compute interest =
like=20
      that," she pointed out. "If you just divide the monthly interest =
by the=20
      days in the month, but compound it daily, you'll end up with a =
bigger=20
      balance at the end of the month than if you compute it once at the =
end of=20
      the month. What you need here is a <I>nominal</I> rate that's =
lower than=20
      5% per month that will give you an <I>effective</I> rate of 5%." =
Oops.=20
      Back to the books.</P>
      <P>In the current problem, it turns out there are two domains: =
parenting,=20
      of course, and to a lesser extent, finance. I had assumed that I =
knew=20
      enough about the latter, but clearly I was wrong. So, I dropped =
the design=20
      and hit the books until I understood enough about the second =
domain to=20
      proceed.</P>
      <P>This problem might have emerged sooner had I not left out an =
essential=20
      second step to the design process: after you've become familiar =
with the=20
      problem domain (step 1) but before you start modeling (step 3), =
you must=20
      interview your users to discover what they need. I didn't think I =
needed=20
      to do that since I was already a domain expert -- a parent. I was =
wrong.=20
      Had I interviewed a second domain expert, someone not as involved =
as I was=20
      in the actual design (my wife for example), I probably would have =
gotten=20
      this interest stuff right in the first place.</P><A name=3D4>
      <P><STRONG class=3Dsubhead>Don't step over the obvious</STRONG> =
<BR>There=20
      are lots of other issues here, but the most important is what I =
call the=20
      "the bathroom effect." This name stems from an (unpublished) =
article that=20
      I wrote for "Dr. Dobb's Journal" a few years ago that began, =
"Suppose we=20
      built houses the same way we build software." (We'd all be living =
in a=20
      poorly built version of the <A=20
      =
href=3D"http://www-106.ibm.com/developerworks/library/oo-design3.html?dwz=
one=3Dcomponents#resources">Winchester=20
      Mystery House</A>). Anyway, toward the end of the article, the =
buyer=20
      finally gets to see the house for the first time (after it's =
entirely=20
      built). Looking around with a puzzled expression, the buyer asks, =
"Where=20
      are the bathrooms?"</P>
      <P>
      <BLOCKQUOTE>"Bathrooms?" says the contractor, "there weren't any=20
        bathrooms in the spec. It will cost a fortune to add them now; =
we'll=20
        have to jack-hammer up concrete,and rip open walls. Why don't we =
just=20
        patch on an outhouse in the back yard?"</BLOCKQUOTE>
      <P></P>
      <P>
      <BLOCKQUOTE>"Waddya mean 'it wasn't in the spec'?" stammers the =
buyer,=20
        "Who'd be dumb enough to build a house without =
bathrooms?"</BLOCKQUOTE>
      <P></P>
      <P>And that's often the problem with software. It often doesn't =
occur to a=20
      user to mention something he needs, precisely because it's so =
fundamental=20
      to the problem. It's not that the users are "hiding things from =
me," as=20
      many programmers say. It's that the designer doesn't know enough =
about the=20
      problem domain to ask the right questions.</P><A name=3D5>
      <P><STRONG class=3Dsubhead>Don't just nod -- listen</STRONG> =
<BR>When=20
      conducting these interviews, <I>listen! Don't interpret</I>. It's =
very=20
      important not only to capture everything that comes out in the =
interview=20
      (someone who can take shorthand is a real asset), but also to =
record the=20
      domain expert's words exactly. I've sat in many meetings where the =
users=20
      went on for hours without anybody writing anything down. Later on, =
when=20
      the user wasn't around, nobody could accurately remember what had =
been=20
      discussed. There's also an unfortunate tendency on the part of =
programmers=20
      not to pay attention to what the users say. Instead, programmers =
have been=20
      known to distort the user's description of what a problem =
<I>is</I> into a=20
      description of what the programmer would <I>like</I> the problem =
to be.=20
      They'll restate things, shuffle words around, translate statements =
out of=20
      the problem domain into a more-familiar vocabulary, and otherwise =
distort=20
      or modify what they hear. More often than not, what gets captured =
is the=20
      programmer's flawed interpretation of the problem, not the problem =
that=20
      the domain expert actually described.</P>
      <P>Finally, bear in mind that most users have a long history of =
trying to=20
      deal with arrogant computer geeks who think that they know more =
about any=20
      problem than the user does. (After getting an incomprehensible set =
of=20
      directions, the city slicker says to the farmer, "You're not very =
smart,=20
      are you?" The farmer replies, "That may be so, but <I>I'm</I> not =
lost.")=20
      The problem is that many users just give up after a while. Why =
bother to=20
      communicate if the programmer doesn't listen? You'll have to break =
down=20
      these sorts of barriers.</P>
      <P>The main issue with respect to problem statements in general is =
whether=20
      this level of detail belongs in it at all. Normally, the problem =
statement=20
      itself wouldn't go so far as to define technical terms in the =
actual=20
      problem domain. You'd just consult a textbook or dictionary for =
that=20
      purpose. Here, however, the answer is "yes" because the =
distinction=20
      between nominal and effective interest is not part of the actual =
problem=20
      domain (which is parenting). Our domain experts are parents, not =
bankers=20
      or accountants. We are not developing a system for use by a bank =
or making=20
      any attempt to model the way that a real bank works. This is a =
piece of=20
      kid's software, not a turn-key banking system, so we can't assume=20
      knowledge of how interest is computed on the part of our domain =
experts.=20
      Interest computation is an important part of defining the problem, =