the oo design process2.mht

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

              <TR>
                <TD class=3Dtoc>&nbsp;<A=20
                  =
href=3D"http://www-106.ibm.com/developerworks/library/oo-design2/index.ht=
ml?dwzone=3Dcomponents#1">OO=20
                  requirements gathering</A></FONT></TD></TR>
              <TR>
                <TD class=3Dtoc>&nbsp;<A=20
                  =
href=3D"http://www-106.ibm.com/developerworks/library/oo-design2/index.ht=
ml?dwzone=3Dcomponents#2">The=20
                  problem statement</A></FONT></TD></TR>
              <TR>
                <TD class=3Dtoc>&nbsp;<A=20
                  =
href=3D"http://www-106.ibm.com/developerworks/library/oo-design2/index.ht=
ml?dwzone=3Dcomponents#3">Crafting=20
                  your statement</A></FONT></TD></TR>
              <TR>
                <TD class=3Dtoc>&nbsp;<A=20
                  =
href=3D"http://www-106.ibm.com/developerworks/library/oo-design2/index.ht=
ml?dwzone=3Dcomponents#4">Problems=20
                  and solutions</A></FONT></TD></TR>
              <TR>
                <TD class=3Dtoc>&nbsp;<A=20
                  =
href=3D"http://www-106.ibm.com/developerworks/library/oo-design2/index.ht=
ml?dwzone=3Dcomponents#5">Pre-code=20
                  details</A></FONT></TD></TR>
              <TR>
                <TD class=3Dtoc>&nbsp;<A=20
                  =
href=3D"http://www-106.ibm.com/developerworks/library/oo-design2/index.ht=
ml?dwzone=3Dcomponents#6">Happy=20
                  trails</A></FONT></TD></TR>
              <TR>
                <TD class=3Dtoc>&nbsp;<A=20
                  =
href=3D"http://www-106.ibm.com/developerworks/library/oo-design2/index.ht=
ml?dwzone=3Dcomponents#resources">Resources</A></FONT></TD></TR>
              <TR>
                <TD class=3Dtoc>&nbsp;<A=20
                  =
href=3D"http://www-106.ibm.com/developerworks/library/oo-design2/index.ht=
ml?dwzone=3Dcomponents#author">About=20
                  the author</A></FONT></TD></TR>
              <TR>
                <TD bgColor=3D#0033cc height=3D5><IMG height=3D1=20
                  =
src=3D"http://www-106.ibm.com/developerworks/images/c.gif"=20
                  width=3D120></TD></TR></TBODY></TABLE></P><!-- End =
Table of Contents -->
            <BLOCKQUOTE>
              <P>In July we started this series by talking about <A=20
              =
href=3D"http://www-106.ibm.com/developerworks/library/oo-design1/">how=20
              to prioritize your design process</A>. This month, I'll =
start=20
              actually designing a piece of software. I wanted a project =
that=20
              would be nontrivial, yet compact enough that we can do it =
in a=20
              reasonable timeframe. I also wanted to use a program that =
was=20
              honestly useful, rather than a pure pedagogic exercise. I =
decided=20
              on a piece of educational software that is described in =
this=20
              article. Over the course of several months, I'll present a =

              complete design and (Java) implementation of the program, =
so=20
              you'll be able to see the whole process, from start to =
finish.=20
              I've also (deliberately) not edited my mistakes out of the =
process=20
              so that you'll have an honest look at the way things =
happen in the=20
              real world. So let's get started. </P></BLOCKQUOTE><A =
name=3D1>
            <P><STRONG class=3Dsubhead>OO requirements gathering =
</STRONG><BR>I=20
            once came across the statistic that something like 60 =
percent of the=20
            programs written each year are discarded within a few months =
of=20
            completion, not because the program doesn't work, but =
because it=20
            doesn't do anything useful. The resulting loss of =
productivity is=20
            staggering, of course. Moreover, much of this code is =
produced by=20
            shops that are very "high-ceremony" -- they generate =
enormous=20
            volumes of paper in the pursuit of what they think is =
design.=20
            Clearly, what they're doing isn't working (see Steve =
McConnell's=20
            editorial listed in <A=20
            =
href=3D"http://www-106.ibm.com/developerworks/library/oo-design2/index.ht=
ml?dwzone=3Dcomponents#resources">Resources</A>),=20
            but equally clearly, proceeding with no design at all =
doesn't work=20
            either. Given the failure rate of high-tech start-up =
companies, I'd=20
            guess that the percentage is now even higher than 60 =
percent. </P>
            <P>I strongly believe that one of the main reasons for this =
failure=20
            is the fact that most programmers embark on the journey of =
software=20
            development without a clear idea of where they're going. For =
a=20
            program to be useful, it's essential to ask someone who's =
going to=20
            use it what it has to do. Often this stage is omitted =
entirely.=20
            Instead, self-appointed proxies for the real users (such as=20
            salespeople) make up fantasies that they call =
"requirements." Many=20
            times real users are indeed consulted, but in such a way =
that they=20
            don't or can't make their needs known. Our first task, then, =
is to=20
            figure out what has to be done, not how to do it. (Most =
programmers=20
            immediately focus on the how: What database will we use? =
What will=20
            the data model look like? What will the UI look like? What =
is the=20
            data structure? The how is irrelevant at this stage -- try =
to=20
            suppress the impulse!) </P>
            <P>In OO parlance, this first stab at problem definition is =
called a=20
            formal <I>problem statement</I>, and building one of these =
will be=20
            our task for the next couple months.</P>
            <P>In a procedural system, the problem statement is often =
omitted in=20
            favor of something called requirements gathering. I prefer =
the term=20
            problem definition because "requirements gathering" usually =
carries=20
            a lot of incorrect (at least from the OO perspective) =
assumptions=20
            about what a requirement is and how you go about gathering =
it. In a=20
            traditional procedural environment, you would produce a =
Functional=20
            Requirements Specification, often working from a list of =
features=20
            provided by some outside third party, such as a marketing=20
            department. In fact, often the "requirements" are a fait =
accompli,=20
            over which you have no control. You'll find that in an OO=20
            environment, these sorts of documents -- the feature list, =
in=20
            particular -- are almost worthless. Those "functional =
requirements"=20
            that provide algorithms and specify performance requirements =
will=20
            make a useful appendix to the OO deliverables, but they are =
not=20
            central. The "functional requirements" that specify UI =
behavior,=20
            workflow, and so on, are virtually worthless, for reasons =
that we'll=20
            see over the next few months. </P><A name=3D2>
            <P><STRONG class=3Dsubhead>The problem statement =
</STRONG><BR>Crafting=20
            the problem statement, then, is always the first step in any =
design.=20
            Your goal, here, is to succinctly, but accurately, state the =
problem=20
            that you're trying to solve. Again, you're interested in =
what and=20
            why, but not how. </P>
            <P>Before you can start defining the problem, you must first =
learn=20
            something about the problem domain, however. Although every =
OO=20
            design team must have a domain expert (ideally an end user) =
as a=20
            team member, the other members of the design team must also =
know the=20
            domain, though not as thoroughly as the expert. You have =
sufficient=20
            domain knowledge when you can hold an intelligent =
conversation using=20
            the vocabulary of the domain itself, without the expert =
having to=20
            stop and explain the basic concepts. </P>
            <P>Consequently, you must begin any design project with a =
research=20
            phase. If you're doing an accounting program, go take an =
Accounting=20
            101 class at a local junior college. Again, you don't have =
to be an=20
            expert, because that's your user's job, but you do have to =
be able=20
            to hold your own in conversations with domain experts. =
Without some=20
            knowledge of the subject, you won't even know what questions =
to ask=20
            or how to ask them. </P><A name=3D3>
            <P><STRONG class=3Dsubhead>Crafting your statement</STRONG> =
<BR>It's=20
            critical to the success of the entire design effort that the =
problem=20
            statement be a well-crafted essay. A bunch of bullet points =
and=20
            sentence fragments simply won't do, as they rarely capture =
the=20
            subtlety of the problem in any detail. If you can't say it =
in clear,=20
            well-structured English, then you don't understand the =
problem well=20
            enough to design anything. Good grammar is also important; =
it gives=20
            structure and precision to otherwise disorganized thoughts. =
A good=20
            copy editor is an important member of any OO design team. =
</P>
            <P>There's also something about the writing process itself =
-- that=20
            is, the need for accuracy that you typically don't have in=20
            conversation -- that helps you discover new facets of the =
problem. I=20
            find that the only time I'm not stumped by something when I =
start=20
            coding is when I've written out the problem first. This =
reasoning=20
            applies even to simple method definitions -- if you write =
the=20
            comments before you write the code, the coding will go much =
faster=20
            and the code will be less buggy. </P>
            <P>The discussion has to be couched entirely in the =
vocabulary of=20
            the problem domain. If you're solving an accounting problem, =
the=20
            problem statement should be written entirely in the =
vocabulary of=20
            accounting. That is, any competent accountant should be able =
to make=20
            sense of the problem statement without having to ask any =
questions.=20
            It is a general rule of thumb about the completeness of a =
design=20
            that a competent programmer who's familiar with the domain =
at the=20
            level of an intelligent layman must be able to read through =
the=20
            design documents and completely understand both the specific =
problem=20
            being solved and the general solution to that problem. If =
this level=20
            of understanding isn't possible, then, again, the design =
document=20
            isn't complete. </P>
            <P>I cannot emphasize too greatly that <I>a problem =
statement is not=20
            a discussion of a computer program</I>. A problem statement =
should=20
            define the problem itself, not a computer-based solution to =