the oo design process2.mht

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

the=20
            problem. It is a discussion of the real-world problem that =
your end=20
            user is trying to solve. Words like "computer," "menu," =
"dialog=20
            box," "internet," "Worldwide Web," and so forth typically =
have no=20
            place here. A problem statement never contains a sentence =
like "The=20
            system must..." or "We need to write a computer program =
that..."=20
            Writing a computer program might be your problem, but =
computers are=20
            rarely involved in the problem that your end user is =
struggling with=20
            (though they may be involved in the solution). Most problems =
can be=20
            described and solved perfectly well without computers, =
though the=20
            computer might make the solution easier or faster. </P>
            <P>Though you will eventually have to write a description of =
the=20
            computer-based solution, we're going to focus, for now, on =
the=20
            domain-level part of the document. Remember that computer =
jargon=20
            simply has no place here, and any accountant should be able =
to=20
            clearly understand our accounting-domain problem statement. =
</P><A=20
            name=3D4>
            <P><STRONG class=3Dsubhead>Acknowledge problems and =
solutions when=20
            possible </STRONG><BR>Conversely, solutions to the problem =
that are=20
            part of the problem domain itself should certainly be =
discussed. All=20
            OO systems must model something. If an existing problem has =
a good=20
            solution, and the real problem is that the existing solution =
can't=20
            be performed fast enough by real people, then just model the =

            existing solution. That is, often the automation of an =
existing=20
            manual process is all that's required, and your problem =
statement=20
            will be a complete description of that manual process.</P>
            <P>One critical thing to identify in a problem statement is =
the goal=20
            of the user. What exactly is the user trying to accomplish? =
The goal=20
            can drastically affect the direction of the solution. (For =
example,=20
            is it your goal to schedule a meeting or to maintain a =
calendar? In=20
            the first case, the only place in the program where you =
might see=20
            something that looks like a traditional calendar is in the =
output.)=20
            Alan Cooper, in his book <I>About Face</I>, calls this way =
of=20
            working "goal-directed design." (See <A=20
            =
href=3D"http://www-106.ibm.com/developerworks/library/oo-design2/index.ht=
ml?dwzone=3Dcomponents#resources">Resources</A>.)=20
            </P>
            <P>You also have to address the desired outcomes. What are =
the end=20
            products of the solving the problem? What information do =
these end=20
            products have to convey? (Note that we're interested in the=20
            informational content at this stage, not the physical layout =
or the=20
            way that the content will be presented.) </P>
            <P>Insofar as it's possible, ignore the existence of legacy =
systems.=20
            It's rarely the goal of a user to improve a legacy system; =
rather,=20
            the user has to get some job done and is coming to you =
because the=20
            legacy system isn't working. Start with a clean sheet. </P>
            <P>Don't try to get too formal in the problem statement. =
Just=20
            describe what you want to do as if you were having a =
conversation=20
            with a peer. (I've often been asked "how do I say <SOMETHING =

            complicated>?" My response, invariably, is, "Just like that =
-- you=20
            just said it.")</P>
            <P>Normally, the next step is to have several conversations =
with=20
            real users and domain experts and to try to define the =
problem=20
            cogently. Then, capture the problem on paper using domain=20
            vocabulary, and run the problem statement back by your users =
to make=20
            sure you got it right. Thinking that I could skip the =
interviewing=20
            process since I am myself a domain expert (a parent), I just =
started=20
            writing. (It turns out that I was mistaken in taking this =
shortcut,=20
            but I'll get into that next month.) </P>
            <P>So, here's what I came up with: </P>
            <TABLE align=3Dcenter border=3D1 cellPadding=3D2 =
class=3Dsidebar=20
width=3D"80%">
              <TBODY>
              <TR>
                <TD>
                  <P><B>The Bank of Allen?/b&gt; <BR>One of the best =
ways to=20
                  teach kids how to manage money (and how interest =
works) is by=20
                  setting up a bank account for them. Real banks, =
however, don't=20
                  pay enough interest to catch a kid's interest, so to =
speak.=20
                  (At a nominal annual rate of 3.5%, $20.00 earns a big =
$0.72 in=20
                  a year, after all). Taking my cue from a piece I heard =
on=20
                  National Public Radio's "Marketplace," I decided to =
open the=20
                  Bank of Allen (or BofA), which pays out an effective =
5%/month=20
                  (that's right, per month -- 60% annually), but =
compounded=20
                  daily. At this rate, $20.00 deposited in the Bank of =
Allen=20
                  earns $15.91 over a year. Despite the high interest =
rate, the=20
                  Bank of Allen works like a real bank. Kids have their =
own=20
                  accounts, over which they have control of everything =
but the=20
                  interest rate. They can look at (or print) their =
passbooks=20
                  whenever they want. They can make deposits and =
withdrawals at=20
                  will. </P>
                  <P>To make saving more interesting to the kids, the =
passbooks=20
                  must show them how much money they're earning from =
interest in=20
                  addition to the usual stuff (deposits, withdrawals, =
running=20
                  balance).</P>
                  <P>The kid must also be able to play what-if games =
with=20
                  projected interest: "How much money will I have if I =
don't=20
                  withdraw any money for two whole months?" The point is =
to=20
                  demonstrate that you can make money by not spending =
it. </P>
                  <P>There are a few security issues. Only the bank =
(that is,=20
                  the parents) can change the interest rate or set up a =
new=20
                  account (and the initial balance). Like a real bank, =
kids=20
                  can't make a deposit or withdrawal by modifying their =
pass=20
                  books; they have to ask the bank to do it; the bank =
processes=20
                  the transaction and updates the passbook. That is, the =
kid=20
                  gives money to the bank, which puts it into the =
account. The=20
                  bank takes money out of the account, and dispenses it =
to the=20
                  kid. (Practically speaking, this means that only =
parents can=20
                  make deposits or withdrawals, but parents should =
process=20
                  withdrawal requests when asked or the kids will assume =
that=20
                  the bank is a ruse for not letting them get at their =
own=20
                  money.) </P>
                  <P>Goals (ranked by importance):=20
                  <UL>
                    <LI>To teach kids to save money=20
                    <LI>To show how compound interest works </LI></UL>
                  <P>The "Bank of Allen" is a trademark of Allen I. =
Holub. This=20
                  program, and the design thereof, is (c) 2000, Allen I. =
Holub.=20
                  All rights reserved.</P></B></TD></TR></TBODY></TABLE>
            <P>I don't pretend that this problem statement is complete, =
but it's=20
            a start. In general, a problem statement is not complete if =
any=20
            reasonable questions have not been addressed. This is =
typically a=20
            tremendous amount of detail. A problem statement for an =
average=20
            small program -- one that might take a small team six to =
eight=20
            months to implement -- can easily get to 80 pages or so =
before all=20
            the details are hashed out. So, obviously what I've done so =
far is=20
            way too brief. </P><A name=3D5>
            <P><STRONG class=3Dsubhead>Pre-code details </STRONG><BR>The =
point of=20
            the exercise is to think about as many details as possible =
before=20
            you start coding. You are not trying to bolt things into =
concrete.=20
            Don't kid yourself into thinking that you'll be able to =
capture all=20
            the details up front. Unless you're working in a very static =

            environment, it's nigh on impossible for all of the details =
to be=20
            settled (or even discovered) in advance, and in any event, =
as the=20
            system goes into production and is actually used, the end =
users=20
            themselves will discover things that they hadn't thought =
about=20
            initially. This after-the-fact discovery is natural, and any =
design=20
            methodology that can't handle the late-breaking changes will =
be too=20
            brittle to use in most programming environments. In =
practice, then,=20
            the problem definition will change as the design and =
implementation=20
            evolve. That's why it's essential to have an end-user on the =
design=20
            team: to make sure that you don't break things rather than =
improve=20
            them. </P>
            <P>Nonetheless, the initial problem definition should be as =
complete=20
            as possible. Do a total brain dump to paper. Don't leave out =
any=20
            details, even simple ones. One of the things I do for a =
living is=20
            mentor teams through their first OO design effort, and often =
I don't=20
            get called in until the effort is already underway. Usually, =
I ask=20
            for my clients to send me their design documents so I can =
prepare=20
            for our first meeting, and, more often than not, I'm told =
that I'll=20
            have to come in and talk in order to fully understand what =
the=20
            problem is. That response sets off all sorts of warning =
bells. If=20
            the problem hasn't been written down in enough detail that =
an=20
            outsider can understand the problem by reading, then I know =
that the=20
            client probably doesn't understand the problem well enough =
to have=20
            started designing. Though I certainly believe that "analysis =

            paralysis" exists, I've never witnessed it; rather, I've =
seen the=20
            opposite: teams who have jumped to coding way too early =
without=20