the oo design process7.mht

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

      that you use it, though. I've presented the use case in the =
template=20
      order, but I was skipping around in the form when I actually put =
the thing=20
      together. I started out with the name and description, then =
skipped down=20
      and worked on the scenarios a bit, then skipped down and added an=20
      implementation note, then skipped back up and worked on the =
scenarios some=20
      more. Then, I filled in the Desired outcome section, and skipped =
down and=20
      added a postcondition, and around and around I went.</P>
      <P>Moreover, in a real-world situation, it's rare that a person =
would=20
      develop an entire use case singlehandedly. Ideally, the =
business-related=20
      components (the use-case name, the description, the scenarios, the =
user=20
      goals, perhaps the desired outcome) would be developed primarily =
by the=20
      marketing side, with engineering in a consulting role. The =
technical items=20
      (dependencies, preconditions and postconditions, formal workflow =
analysis,=20
      implementation requirements and notes) would come primarily from=20
      engineering, with the marketing organization in a consulting role. =

      Business rules and Requirements are typically created jointly. =
It's even=20
      better if a real-live customer -- an actual user of the product -- =

      participates in the process, too.</P>
      <P>You'll also work on several design artifacts in parallel. It's =
natural=20
      to uncover hitherto unknown aspects of the problem as you work on =
the use=20
      cases, and you should go back and add these to the problem =
statement=20
      before you forget them. Keeping the various documents that =
comprise the=20
      design in phase with each other is a real problem with a large =
design, but=20
      it is critical. As soon as you discover some flaw in your thinking =
about a=20
      problem, you have to change <I>all</I> the relevant documents =
immediately.=20
      I typically have the problem statement, any relevant use-case=20
      descriptions, the UML diagrams, and the code all in front of me at =
the=20
      same time as I work. It's also important to be able to roll back =
to=20
      previous designs if you go down a wrong path, though I don't know =
of any=20
      automated document-management packages that make rollback truly =
painless=20
      since many types of document -- drawings, formatted text, ASCII =
source=20
      code, etc. -- comprise the design, and they might all be affected =
by the=20
      change. (If anybody knows of a document-management system that's =
up to=20
      this task, <A href=3D"mailto:[e-mail]">send me =

      e-mail</A>.)</P>
      <P>Now let's look at the first use case.</P><A name=3D1></A>
      <P><B class=3Dsubhead>An example use case</B><BR>
      <TABLE border=3D1 cellPadding=3D5 cellSpacing=3D0>
        <TBODY>
        <TR>
          <TD width=3D110><FONT face=3D"HELVETICA, HELV, ARIAL"=20
          size=3D-1>Name</FONT></TD>
          <TD><FONT face=3D"HELVETICA, HELV, ARIAL" size=3D-1>1.0. Kid =
depositing=20
            funds into account</FONT></TD></TR>
        <TR>
          <TD vAlign=3Dtop width=3D110><FONT face=3D"HELVETICA, HELV, =
ARIAL"=20
            size=3D-1>Description</FONT></TD>
          <TD><FONT face=3D"HELVETICA, HELV, ARIAL" size=3D-1>A kid =
(customer)=20
            deposits money into his or her account. Deposits must be =
authorized=20
            by a bank-officer/parent before they go into=20
        effect.</FONT></TD></TR></TBODY></TABLE>
      <P>This is the first time that the notion of authorization has =
popped up=20
      in this context, and it's an example of how writing a use case can =
find=20
      flaws in the problem statement. During my first pass on this use =
case, I=20
      wrote "parents aren't involved in this use case," but my next =
thought was=20
      "but what prevents the kid from just depositing arbitrary sums of =
money?"=20
      The notion of authorization solves the problem, but introduces a =
few=20
      interesting scenarios, which I'll discuss below.</P>
      <P>The original problem statement did cover security issues, but =
not in a=20
      way that's workable. Here's the relevant portion from the =
original:</P>
      <P><B>Original problem statement</B><BR>
      <TABLE =
background=3Dhttp://www-106.ibm.com/developerworks/i/bg-gold.gif=20
      border=3D0 cellPadding=3D5 cellSpacing=3D0>
        <TBODY>
        <TR>
          <TD>&nbsp;</TD>
          <TD><FONT face=3D"HELVETICA, HELV, ARIAL" size=3D-1>There are =
a few=20
            security issues. Like a real bank, kids can't make a deposit =
or=20
            withdrawal by modifying their passbooks; they have to ask =
the bank=20
            to do it. The bank processes the transaction and updates the =

            passbook. That is, the kid gives money to the bank, which =
puts it=20
            into the account. The bank takes money out of the account, =
and=20
            dispenses it to the kid. (Practically speaking, this means =
that only=20
            parents can make deposits or withdrawals, but parents should =
process=20
            withdrawal requests when asked or the kids will assume that =
the bank=20
            is a ruse for not letting them get at their own =
money.)</FONT>=20
        </TD></TR></TBODY></TABLE></P>
      <P>In retrospect, that business of the bank taking money out of an =
account=20
      and dispensing it doesn't work, because banks don't do that =
(tellers do,=20
      bank officers do, banks do not). So, I now go back and modify the =
problem=20
      statement to bring the notion of parent approval of certain =
transactions=20
      more in line with what I've discovered in the use case.</P>
      <P>Here's the revised section:</P><B>Revised problem =
statement</B><BR>
      <TABLE =
background=3Dhttp://www-106.ibm.com/developerworks/i/bg-gold.gif=20
      border=3D0 cellPadding=3D5 cellSpacing=3D0>
        <TBODY>
        <TR>
          <TD>&nbsp;</TD>
          <TD>
            <P><FONT face=3D"HELVETICA, HELV, ARIAL" size=3D-1>There are =
a few=20
            security issues. Only a bank officer (that is, a parent) can =
change=20
            the interest rate, set up a new account (and the initial =
balance),=20
            or close an account. <BR><BR>Though, for the most part, kids =
can use=20
            the bank entirely on their own, some transactions (deposits =
and=20
            loans) require parent/bank officer approval before they can =
be=20
            completed. Transactions like this will be visible to kids, =
and will=20
            show up in the passbook, but unapproved deposits are not =
available=20
            for withdrawal. <BR><BR>Withdrawals don't require parent =
approval. A=20
            withdrawal request will cause a check to be printed. These =
checks=20
            work like real-world checks. If it's lost, then a =
stop-payment order=20
            can be issued (for a fee). The check can be presented to the =
bank (a=20
            parent) for conversion to cash.</FONT> =
</P></TD></TR></TBODY></TABLE>
      <P></P>
      <P>The issue of checks came to me as I was writing -- yet another =
example=20
      of how the design process works. You discover missing pieces of =
the=20
      problem as you look at the problem from different =
perspectives.</P>
      <P>Of course, having made a change to the problem statement, I now =
need to=20
      get domain-expert approval before I can check in the new version. =
(Since=20
      I'm my own domain expert in the current case, that's easy.)</P>
      <TABLE border=3D1 cellPadding=3D5 cellSpacing=3D0>
        <TBODY>
        <TR>
          <TD vAlign=3Dtop width=3D120><FONT face=3D"HELVETICA, HELV, =
ARIAL"=20
            size=3D-1>Desired outcome</FONT></TD>
          <TD vAlign=3Dtop><FONT face=3D"HELVETICA, HELV, ARIAL" =
size=3D-1>The=20
            account balance gets larger</FONT></TD></TR>
        <TR>
          <TD vAlign=3Dtop width=3D110><FONT face=3D"HELVETICA, HELV, =
ARIAL"=20
            size=3D-1>User goals</FONT></TD>
          <TD><FONT face=3D"HELVETICA, HELV, ARIAL" size=3D-1>Kid: To =
make the=20
            account balance as large as possible and to watch wealth=20
            accumulate</FONT> <BR><BR><FONT face=3D"HELVETICA, HELV, =
ARIAL"=20
            size=3D-1>Parent: To make sure that kids don't inflate the =
account=20
            balance with an arbitrary deposits to which they're not=20
            entitled</FONT></TD></TR></TBODY></TABLE>
      <P>Note that different users of the system have different goals, =
and that=20
      these goals are often mutually exclusive. Kids want the account =
balance to=20
      be arbitrarily large, but parents want to assure that only real =
funds --=20
      funds actually available to the kids -- are deposited. This sort =
of goal=20
      clash is commonplace, and one of the points of the current =
exercise is to=20
      identify (and address) these clashes.</P>
      <P><B>Participants/Roles</B> <BR>I'll identify the roles using the =

      CRC-card format I discussed last month. This list, again, is =
developed=20
      over time as I work on the scenarios; what you see here is the =
final form=20
      of the list.</P>
      <P>Note that some of the participants are automated (the Teller) =
and=20
      others are real people. Also note that some of the participants =
are=20
      passive objects in the system (Passbook). This is one place where =
a use=20
      case that's intended for program development might vary from one =
that's=20
      used for UI development. A UI-style use case would typically be =
interested=20
      only in the roles taken on by the physical users of the system. In =
OO=20
      systems, though, even objects that you think of as passive have=20
      responsibilities and operations defined on them. (For example, the =

      passbook might print itself.)</P>
      <TABLE border=3D1 cellPadding=3D4 cellSpacing=3D0>
        <TBODY>
        <TR>
          <TD align=3Dleft vAlign=3Dbaseline><FONT face=3D"HELVETICA, =
HELV, ARIAL"=20
            size=3D-1>Class</FONT> </TD>
          <TD align=3Dleft vAlign=3Dbaseline><FONT face=3D"HELVETICA, =
HELV, ARIAL"=20
            size=3D-1>Responsibilities</FONT> </TD>
          <TD align=3Dleft vAlign=3Dbaseline><FONT face=3D"HELVETICA, =
HELV, ARIAL"=20
            size=3D-1>Collaborators</FONT> </TD></TR>
        <TR>
          <TD align=3Dleft vAlign=3Dbaseline><FONT face=3D"HELVETICA, =
HELV, ARIAL"=20
            size=3D-1>Kid (bank customer)</FONT> </TD>
          <TD align=3Dleft vAlign=3Dbaseline>
            <UL><FONT face=3D"HELVETICA, HELV, ARIAL" size=3D-1>
              <LI>Fills out deposit slip.=20
              <LI>Holds the passbook.</FONT> </LI></UL></TD>
          <TD align=3Dleft vAlign=3Dbaseline><FONT face=3D"HELVETICA, =
HELV, ARIAL"=20
            size=3D-1>Teller (handles the Kid's requests)</FONT> =
</TD></TR>
        <TR>
          <TD align=3Dleft vAlign=3Dbaseline><FONT face=3D"HELVETICA, =
HELV, ARIAL"=20
            size=3D-1>Parent (bank officer)</FONT> </TD>
          <TD align=3Dleft vAlign=3Dbaseline>
            <UL>
              <LI><FONT face=3D"HELVETICA, HELV, ARIAL" =
size=3D-1>Authorizes=20
              deposits</FONT></LI></UL></TD>
          <TD align=3Dleft vAlign=3Dbaseline><FONT face=3D"HELVETICA, =
HELV, ARIAL"=20
            size=3D-1>Teller (requests deposits from)</FONT> </TD></TR>
        <TR>
          <TD align=3Dleft vAlign=3Dbaseline><FONT face=3D"HELVETICA, =
HELV, ARIAL"=20
            size=3D-1>Teller</FONT> </TD>
          <TD align=3Dleft vAlign=3Dbaseline>
            <UL><FONT face=3D"HELVETICA, HELV, ARIAL" size=3D-1>
              <LI>Solicits deposit slip.=20