the oo design process6.mht

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

        lot of material to cover, so we'll take our time and look at the =
issues=20
        thoroughly. This month we focus on how to decide which use cases =
to=20
        pursue, and other things we need to keep in mind as we plan our =
use=20
        cases.</BLOCKQUOTE>
      <P></P><A name=3D1></A>
      <P><B class=3Dsubhead>Creating use cases</B><BR>Let's start with a =
reprise=20
      of the definition of <I>use case</I> from last month:</P>
      <BLOCKQUOTE>A <I>use case</I> is a single task, performed by the =
end=20
        user of a system, that has some useful outcome.</BLOCKQUOTE>
      <P>Looking at the Bank of Allen problem statement from prior =
months, a few=20
      use cases spring out at me:=20
      <UL>
        <LI>Kid depositing funds into an account=20
        <LI>Kid withdrawing funds from an account=20
        <LI>Kid or parent viewing a passbook=20
        <LI>Parent opening an account=20
        <LI>Parent changing an account=20
        <LI>Parent closing an account=20
        <LI>Bank loaning funds to a kid (defer to version 2) </LI></UL>
      <P></P>
      <P>At this stage, this list is just guesswork. I'm sure that I'll =
discover=20
      additional use cases as the process unfolds. Moreover, some of =
these use=20
      cases might turn out to be large enough that they will have to be=20
      decomposed into smaller chunks. (In general, by the time we get to =
an=20
      implementation-level design, no use case should take longer than a =
month=20
      to implement. In fact, one-person-month-per-use-case is a good=20
      rule-of-thumb metric for rough estimation. Some methodologies -- =
such as=20
      Kent Beck's XP -- want use cases that are small enough to be =
implementable=20
      in a couple of weeks.) Note that the low-level atomic operations =
-- such=20
      as computing interest -- aren't listed, since they aren't =
stand-alone use=20
      cases. These will almost certainly be subcases, though.</P>
      <P>Now that I have <I>something</I> down on paper, I can start =
designing.=20
      Looking at the previous list, I've several thoughts. First, I'm =
not sure=20
      whether "depositing" and "withdrawing" are separate use cases. The =

      alternative would be something like "perform a transaction," where =

      "transaction" was either a deposit or withdrawal operation. Two =
use cases=20
      that turn out to have the same workflow are certainly equivalent, =
but I=20
      don't yet know whether that will be the case. For now, I'll keep =
both use=20
      cases since they appear to be different from the user's =
perspective, and=20
      they have different apparent outcomes. (Deposit <I>increases</I> =
the=20
      balance and withdrawal <I>decreases</I> it. The "perform a =
transaction"=20
      use case <I>modifies</I> the balance.)</P>
      <P>Turning my attention to "viewing a passbook," I'm not sure that =
it's a=20
      use case at all. There's no particular outcome, and the passbook =
will most=20
      likely be displayed during the course of the other use cases. On=20
      consideration, I change this one to "playing what-if games," which =
does=20
      have an outcome: learning financial planning.</P>
      <P>Next, I consider opening, closing, and changing an account. =
There are=20
      certainly distinct outcomes from the user perspective, but again, =
I can=20
      imagine that the workflow would be identical for the "opening" and =

      "changing" cases. Certainly the UI would be identical -- it's just =
that=20
      various fields would be blank when you opened the account. The =
trivial=20
      differences could be handled with simple conditional branches ("if =
account=20
      is new, then ...") in the workflow.</P>
      <P>I decide that "closing an account" is a real, though trivial, =
use case=20
      since the UI will be different than the UI for the =
opening/changing case.=20
      I don't want to do what a normal bank does and automatically close =
an=20
      account if the balance is exactly $0.00, because I can easily =
imagine kids=20
      taking their accounts down to a zero balance, and I don't want to =
redo the=20
      setup in that situation.</P>
      <P>Finally, I decide to toss the "loaning funds" use case. It's a =
good=20
      version 2 feature, but I don't need it immediately.</P>
      <P>Note that as I make these decisions, I'm imagining =
implementation=20
      details (the UI). I am, after all, designing a computer program, =
so I need=20
      to look forward toward implementation. Nonetheless, I'm =
simultaneously=20
      trying to keep my thinking in the problem domain for as long as =
possible.=20
      I'm using an imagined implementation to help understand =
domain-level=20
      issues, but I'm not designing that implementation, and I'm not =
wedded to=20
      it. The UI, then, is a design aid that helps me clarify my =
thinking about=20
      domain-level problems. This is a very different approach than the =
VB-style=20
      approach recommended by Alan Cooper, in which the UI design drives =
the=20
      program-design process. Here, the program will fall from the =
conceptual=20
      model, and the UI is just a convenient tool in developing that =
conceptual=20
      model.</P>
      <P>Things like "backing up," "saving," etc, are not use cases =
because they=20
      don't occur in the problem domain. This also tells us something =
about how=20
      the program should work, however. It shouldn't be necessary to =
explicitly=20
      "save" before exiting <I>any</I> program, especially this one. If =
you make=20
      a deposit, you make a deposit. It's just unnatural to require an=20
      additional operation like saving for that deposit to be realized. =
I can=20
      guarantee that your average 10-year-old won't think about saving =
before=20
      exiting. If you think about it, requiring a "save" operation is =
the same=20
      thing as making "throw away all my work" the default behavior of a =
program=20
      -- not a particularly good default, if you ask me. Same for =
"backing up."=20
      Either the program should back up automatically as a side effect =
of=20
      changing the state of an account, or the program must maintain an =
audit=20
      trail that lets you undo the changes. It's rare that <I>any</I> =
operation=20
      that doesn't appear at the domain level should appear in the UI. =
Possible=20
      exceptions might include "help," but if the UI is sufficiently =
intuitive,=20
      help shouldn't be necessary. You could also argue that the program =
should=20
      notice when you need help by watching your behavior, and offer it =
to you=20
      at that time. Most configuration options are never changed by =
users, so=20
      there's no point in cluttering up the UI with that kind of junk.=20
      (Exceptions, of course, being configuration issues that appear in =
the=20
      problem domain, such as currency representation, though even that =
could be=20
      done automatically by detecting the current locale.) </P>
      <P>The tentative use-case list now looks like this.=20
      <UL>
        <LI>Kid depositing funds into an account=20
        <LI>Kid withdrawing funds from an account=20
        <LI>Playing what-if games=20
        <LI>Parent opening or changing an account=20
        <LI>Parent closing an account </LI></UL>
      <P></P>
      <P>Over the next two columns, I'll continue the exercise by =
formally=20
      specifying the "depositing funds" use case in depth. I'll present =
the=20
      specification itself along with extensive comments about what I'm=20
      doing.</P><!-- Enter list of article resources here --><A =
name=3Dresources>
      <P><B class=3Dsubhead>Resources</B>=20
      <UL>
        <LI>See the first five parts of my series on the OO-design =
process:=20
        <UL>
          <LI><A=20
          =
href=3D"http://www-106.ibm.com/developerworks/library/oo-design1/index.ht=
ml">Getting=20
          started</A>=20
          <LI><A=20
          =
href=3D"http://www-106.ibm.com/developerworks/library/oo-design2/index.ht=
ml">Beginning=20
          to design software</A>=20
          <LI><A=20
          =
href=3D"http://www-106.ibm.com/developerworks/library/oo-design3.html">Re=
fining=20
          the problem definition</A>=20
          <LI><A=20
          =
href=3D"http://www-106.ibm.com/developerworks/library/co-design4.html">Ve=
rifying=20
          the analysis</A>=20
          <LI><A=20
          =
href=3D"http://www-106.ibm.com/developerworks/library/co-design5.html">Us=
e=20
          cases, an introduction</A>=20
          <LI><A=20
          =
href=3D"http://www-106.ibm.com/developerworks/components/library/co-desig=
n7.html">Use=20
          cases applied, Part 1</A> </LI></UL><BR>
        <LI>Kent Beck's XP methodology wants use cases that are small =
enough to=20
        be implementable in a couple of weeks. Read about it at the <A=20
        href=3D"http://c2.com/cgi/wiki?ExtremePlanning">Extreme Planning =
wiki</A>.=20

        <LI>Alan Cooper recommends that UI design drives the =
program-design=20
        process. Read more about Alan Cooper's ideas in this =
uidesign.net <A=20
        =
href=3D"http://www.uidesign.net/2000/interviews/cooper1.html">interview</=
A>=20

        <LI>Workflow diagrams (along with the rest of UML) are described =
nicely=20
        in Martin Fowler and Kendall Scott's <A=20
        =
href=3D"http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=3D0201=
65783X&amp;from=3DNCN454"=20
        target=3D_blank>UML Distilled, 2nd Ed</A>. </LI></UL><!-- Enter =
author bios here; make author heading singular or plural as needed --><A =

      name=3Dauthor1>
      <P><B class=3Dsubhead>About the author</B> <BR><!-- <img =
src=3D"[author.jpg]" border=3D"0" width=3D"64" height=3D"71" =
align=3D"left"> -->Allen=20
      Holub is the CTO at NetReliance, a San Francisco-based company =
that's=20
      building a secure global infrastructure for conducting trusted =
business=20
      transactions over the net. (Yes, we're hiring.) He has worked in =
the=20
      computer industry since 1979, and is widely published. Allen has =
<A=20
      href=3D"http://www.holub.com/allenholub.html#books">eight =
books</A> to his=20
      credit, including his latest, <A=20
      =
href=3D"http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=3D1893=
115100&amp;from=3DNCN454"=20
      target=3D_blank>Taming Java Threads</A>, which covers the traps =
and pitfalls=20
      of Java threading.</P>
      <P>He's been designing and building OO software for longer than he =
cares=20
      to remember (in C++ and Java). He teaches OO Design and Java for =
the=20
      University of California, Berkeley, Extension (since 1982). =
Contact Allen=20
      at <A href=3D"mailto:[e-mail]">[e-mail]</A> or at <A =

      =
href=3D"mailto:[e-mail]">[e-mail]=
</A>.=20
      Allen is also a composer, artist, and instrument-rated commercial =
pilot.=20
      He holds B.A. degrees from the University of California, Berkeley, =
in=20
      Medieval History and Computer Science.</P><BR clear=3Dall><IMG =
alt=3D""=20
      border=3D0 height=3D5 src=3D"http://www.ibm.com/i/c.gif" =