the oo design process8.mht

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

              3</A>.) In general, if it's not possible to merge the =
scenarios,=20
              or if the diagram that results from the merge is too =
ungainly,=20
              then the additional scenarios are probably stand-alone use =
cases,=20
              not scenarios of the current use case. The current batch =
of=20
              scenarios merge quite nicely, though. </P>
              <P>The parent-makes-deposit-for-kid scenario turns out to =
be a no=20
              brainer once I realize that the workflow is identical to =
the happy=20
              path -- provided that I permit to parent to masquerade as =
a kid.=20
              That is, a parent's password can be used to log on a kid. =
I put a=20
              comment to this effect in both the activity diagram (<A=20
              =
href=3D"http://www-106.ibm.com/developerworks/library/co-design8/index.ht=
ml#_figure3_">Figure=20
              3</A>) and the <A=20
              =
href=3D"http://www-106.ibm.com/developerworks/library/co-design8/index.ht=
ml#business_rules">business=20
              rules</A> section (below).</P>
              <P>The second scenario (where the parent isn't present) is =

              slightly more difficult because I have to introduce a=20
              <I>branch</I> (indicated in <A=20
              =
href=3D"http://www-106.ibm.com/developerworks/library/co-design8/index.ht=
ml#_figure3_">Figure=20
              3</A> as a diamond with one incoming and multiple outgoing =

              arrows). The conditions that control which outgoing path =
to follow=20
              (called <I>guards</I>) are just text labels on the lines. =
A=20
              <I>merge</I> (also indicated with a diamond, but this one =
with=20
              multiple incoming and one outgoing arrow) marks the end of =
the=20
              conditional behavior. Every branch should have an =
associated=20
              merge. </P>
              <P>You could express all the complicated stuff between the =
fork=20
              and the join as follows: In any order, verify the identity =
of the=20
              kid and also mark the deposit as approved if a parent is =
present,=20
              or unapproved if the parent is absent. Update the passbook =
after=20
              both activities (verification and marking) have =
completed.</P>
              <P>Note that the original scenario description specified =
that the=20
              teller hold unapproved deposits. It became apparent while =
working=20
              with the diagram that it would be a lot easier for the =
unapproved=20
              deposits to be held in the passbook, not by the teller, so =
I did=20
              that. I went back and modified the scenario description to =
reflect=20
              this change.</P></FONT></TD>
            <TD width=3D"5%">&nbsp;&nbsp;</TD></TR></TBODY></TABLE>
        <P><A name=3D_figure3_></A><B>Figure 3. Additional scenarios =
added to=20
        happy path</B> <BR><IMG border=3D0=20
        =
src=3D"http://www-106.ibm.com/developerworks/library/co-design8/activity3=
.gif">=20
        </P>
        <DT><B>Postconditions</B>=20
        <DD>new account balance =3D old account balance + deposit amount =

        <P>Note that the use case encompasses two distinct operations =
(deposit=20
        request and deposit authorization) that don't have to occur at =
the same=20
        time. Nonetheless, this is a single use case with a single =
outcome. The=20
        account balance is always affected, even if some days elapse =
between the=20
        deposit and approval activities. </P>
        <DT><B>Outputs</B>=20
        <DD>An updated passbook.=20
        <P>This section would be the place where you'd actually show =
what the=20
        output will look like (in the case of a report, for example). =
I'll defer=20
        that until I start work on the UI in a subsequent article. =
</P><A=20
        name=3Dbusiness_rules>
        <DT><B>Business rules</B> (domain-related)<BR></A><BR>
        <DD>
        <OL>
          <LI>Deposits must be authorized by a parent before they take =
effect.=20
          <LI>Interest starts accruing on the day the deposit is made, =
even if=20
          authorization occurs on some subsequent day.=20
          <LI>Unauthorized deposits can remain in the unauthorized =
state,=20
          waiting for a parent signature, indefinitely. They do not =
become=20
          "stale."=20
          <LI>A parent's password will authenticate a kid. That is, =
parents can=20
          log on as kids. </LI></OL><BR>
        <DT><B>Requirements</B> (implementation-related)<BR><BR>
        <DD>
        <OL>
          <LI>Deposits must be "saved" automatically. There is no =
"File/Save"=20
          menu. An explicit "undo" isn't necessary or desirable. Undo a =
deposit=20
          with a withdrawal.=20
          <LI>The "held" deposits must be displayed when kids view their =

          passbooks. Held deposits will be displayed in gray. </LI></OL>
        <P>Had I said "highlighted in some way" rather than "displayed =
in gray,"=20
        I would be running the risk of writing a worthless =
specification. By the=20
        time we're done, the specification simply can't be ambiguous. =
Since all=20
        decisions have to be made eventually, you may as well get them =
out of=20
        the way now. You can always go back and change things if you =
make a=20
        wrong decision (until the specification is formally approved, of =

        course.)</P>
        <P>It seems better to me to make a wrong decision than to make =
no=20
        decision at all. I've seen many so-called specifications that =
were so=20
        mealymouthed that several hundred distinct programs could be =
generated=20
        from the spec, and all of these programs would be conforming. =
This sort=20
        of ambiguity is worse than useless, since it encourages you to =
do=20
        incorrect work.</P>
        <P>In the current case, I suppose, the issue is so trivial that =
a=20
        decision may well be unnecessary. It doesn't matter in the least =

        <I>how</I> the entry is highlighted, as long as it <I>is</I>=20
        highlighted. Consequently, this decision could be deferred to =
the formal=20
        UI-design process. If you leave the notion of highlighting=20
        indeterminate, the various programmers who are implementing the =
design=20
        will each implement their own notion of highlighting, with the =
resulting=20
        UI being inconsistent and harder to use as a consequence.</P>
        <DT><B>Implementation notes</B>=20
        <DD>
        <OL>
          <LI>There's currently no notion of logging in. Looking at the=20
          scenarios, Philip is not likely to make several transactions =
at once.=20
          In fact, it's more likely that he'll make a single =
transaction, but=20
          forget to log off. (This is an observed behavior from my home =
testing=20
          lab -- Philip often plays a game in the morning, and I'll find =
the=20
          game still running 12 hours later, after he's gone to bed.) =
Given this=20
          behavior, it seems more secure to ask for some sort of =
authentication=20
          as part of accepting a deposit slip. This is essentially the =
way a=20
          real bank works.=20
          <LI>The analog of logging in would be identifying yourself to =
a guard=20
          as you were admitted to the bank. (Which might be a reasonable =

          approach, it's just not the one I chose.) Note that there's =
nothing in=20
          this use case to prohibit the teller from remembering who =
Philip is.=20
          That is, it's within the scope of the use case for the =
customer to be=20
          somehow labeled as "trusted" so that subsequent transactions =
can be=20
          performed without needing to repeat the authentication =
process. The=20
          "trusted" attribute could be cancelled by a log out, or it =
could=20
          simply time out. (For example, you would become untrusted if =
two=20
          minutes elapsed without any activity within the bank.)=20
          <LI>(This note may not be clear to you until we start the =
actual=20
          object modeling, so don't worry it if it doesn't make sense, =
yet.) The=20
          kid is, for the most part, an external object. That is, there =
is no=20
          programmatic object within the system that will represent the =
kid;=20
          rather, the kid is a physical user of the system. On the other =
hand,=20
          the notion of a kid's identity will almost certainly be =
modeled, since=20
          some object in the system must handle authentication.=20
          <LI>There's a difference between "available funds" and =
"current=20
          balance." (The latter doesn't reflect unauthorized =
transactions.)=20
          Since the kid treats a deposit as a deposit, regardless of =
whether or=20
          not it's authorized, the passbook should display both values. =
In any=20
          event, it can't hurt to teach kids how a "hold" works.<BR><BR>
          <TABLE border=3D0 cellPadding=3D5 cellSpacing=3D0>
            <TBODY>
            <TR>
              <TD width=3D"5%">&nbsp;&nbsp;</TD>
              <TD =
background=3Dhttp://www-106.ibm.com/developerworks/i/bg-gold.gif=20
              width=3D"90%"><FONT face=3D"HELVETICA, HELV, ARIAL" =
size=3D-1>
                <P>
                <P>I'm not sure how best to present holds in the UI. One =

                solution is for the deposit slip to be shown to any kids =
who=20
                look at their passbooks, but the deposit won't show up =
in the=20
                passbook proper until the deposit slip is authorized by =
a=20
                parent. Another possibility would be for the deposit to =
show up=20
                in the passbook like an authorized deposit, but with =
some visual=20
                indication (gray text?) that the deposit is being =
held.</P>
                <P>The latter makes more sense, but this means that the=20
                parent-authorizing-current-deposit use case will =
probably be=20
                significantly different from the=20
                parent-authorizing-pending-deposits use case.</P>
                <P>Note that, if the teller holds deposit slips for =
parent=20
                authorization, the kid will have to ask the teller to =
see the=20
                passbook so that the teller can display the held deposit =
slips=20
                as well as the passbook.</P></FONT></TD>
              <TD width=3D"5%">&nbsp;&nbsp;</TD></TR></TBODY></TABLE>
          <P></P>
          <LI>Probably the best way to handle parent authorization is on =
the UI=20
          for the deposit slip itself. Maybe an "Authorized" box, which, =
when=20
          checked, pops up a small dialog onto which a signature can be =
entered.=20
          Another possibility is a "authorized signature" line on the =
deposit=20
          slip itself into which a parent can type a pass phrase. (Note =
that=20
          some indication that the transaction has been authorized -- a=20
          facsimile of a signature, for example -- should appear on an=20
          authorized deposit slip ). Don't print x's in the =
authorized-signature=20
          line (or at least replace the x's once the signature is =
verified);=20
          there's no point in giving away the number of characters in =
the=20
          passphrase.=20
          <LI>There are some access-control issues here. Someone in the =
role of=20
          kid has permission to specify deposits, but not to authorize =
deposits.=20
          (An authorization causes the account balance and passbook to =
be=20
          updated.) Someone in the parent role may both specify deposits =
and=20
          authorize deposits. The system must be able to distinguish =
between=20
          actors in these two roles -- password authentication is =
adequate.=20
          <LI>Interest accumulates on held funds, even if these funds =
are not=20
          accessible. Probably the best way to handle interest is to =
think of=20
          the passbook as a list of transactions, sorted by date. When a =
deposit=20
          slip is authorized, it's inserted into the transaction list in =
sorted=20
          order. Interest is then recomputed, starting at the point =
immediately=20
          above the most recently inserted transaction. This way an =
unauthorized=20