the oo design process8.mht

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

            (equivalent?)</FONT> </TD></TR>
        <TR>
          <TD align=3Dleft vAlign=3Dbaseline><FONT face=3D"HELVETICA, =
HELV, ARIAL"=20
            size=3D-1>Follows:</FONT> </TD>
          <TD align=3Dleft vAlign=3Dbaseline><FONT face=3D"HELVETICA, =
HELV, ARIAL"=20
            size=3D-1>4.0. Parent opening an account</FONT> </TD></TR>
        <TR>
          <TD align=3Dleft vAlign=3Dbaseline><FONT face=3D"HELVETICA, =
HELV, ARIAL"=20
            size=3D-1>Includes:</FONT> </TD>
          <TD align=3Dleft vAlign=3Dbaseline><FONT face=3D"HELVETICA, =
HELV, ARIAL"=20
            size=3D-1>6.1. Parent authorizing a single deposit</FONT> =
</TD></TR>
        <TR>
          <TD align=3Dleft vAlign=3Dbaseline><FONT face=3D"HELVETICA, =
HELV, ARIAL"=20
            size=3D-1>Followed by:</FONT> </TD>
          <TD align=3Dleft vAlign=3Dbaseline><FONT face=3D"HELVETICA, =
HELV, ARIAL"=20
            size=3D-1>6.0. Parent authorizing prior deposits</FONT>=20
      </TD></TR></TBODY></TABLE>
      <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>This list is tentative. For example, the "Similar to"=20
            relationship with use case 2.0 might actually be an =
"equivalent"=20
            relationship.</P></FONT></TD>
          <TD width=3D"5%">&nbsp;&nbsp;</TD></TR></TBODY></TABLE>
      <DT><B>Preconditions</B> <BR>
      <DD>The account must exist.=20
      <DT><B>Inputs</B> <BR>
      <DD>The kid has earned some money. <A name=3Dscenarios>
      <P><B>Scenarios</B></A></P>
      <OL>
        <LI>(Happy path)<BR>Philip has completed his chores for the day =
and has=20
        decided to deposit the resulting $2.25 into the Bank of Allen. =
(If he=20
        did his chores every day, I'd be broke by now.) He enters the =
bank, asks=20
        the teller for a deposit slip, fills it out, and returns the =
deposit=20
        slip along with his passbook to the teller. The teller asks for =
some=20
        identification before she accepts the deposit slip, then sends =
the slip=20
        to the bank officer for approval. The bank officer (a parent) =
authorizes=20
        the deposit by signing the slip, and sends it back to the =
teller, who=20
        updates Philip's passbook to show the transaction. The teller =
then=20
        returns the Passbook to Philip so he can gleefully ponder his =
growing=20
        account balance.
        <P></P>
        <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>Note that I've carefully used the vocabulary of the =
problem=20
              statement (discussed in previous installments of this =
series) in=20
              this scenario description (for example, "passbook," =
"teller,"=20
              etc.). Had I introduced new concepts here -- and that does =
happen=20
              -- I'd have to go back and modify the problem statement to =

              introduce the new vocabulary. A significant (and =
difficult) goal=20
              of the designer is to keep all design documents "in phase" =
with=20
              each other. If a change in one document impacts another, =
then both=20
              documents must be changed immediately. For example, I have =

              deliberately not said "The teller makes a journal entry =
reflecting=20
              the deposit transaction," because "journal" is not in the =
domain=20
              vocabulary while "passbook" is in the domain. Whether you =
call it=20
              a "journal" or a "passbook" makes no difference to the =
design.</P>
              <P>Also note that I have not used the phrase "the system." =
The=20
              system doesn't do anything; rather, all work is done by =
actors who=20
              take on well-defined roles. Some of those actors (the kid) =
are=20
              real people. Other actors (the teller) are entirely =
automated.=20
              Other actors (the bank officer) are partially automated =
and=20
              partially real (some of the responsibilities of the bank =
officer=20
              are executed by a parent rather than a computer). It's the =
role=20
              that's important; It's immaterial whether the actor =
performing=20
              that role is or is not automated.</P></FONT></TD>
            <TD width=3D"5%">&nbsp;&nbsp;</TD></TR></TBODY></TABLE><BR>
        <LI>
        <P>In this scenario, the money isn't actually added to the =
account;=20
        rather, the deposit is entered into the passbook as =
"unapproved." Any=20
        parent can approve the transaction at some subsequent time. In =
other=20
        words, the deposit is "on hold" until it "clears." The teller =
returns=20
        the passbook to the kid, and the deposit will show up in the =
passbook,=20
        but the funds cannot be withdrawn from the account until the =
parent=20
        signs the deposit slip. (This scenario differs from the happy =
path in=20
        that no parents are around to authorize the deposit.) =
<BR><BR></P>
        <LI>In this scenario, the parent deposits funds for the kid (as =
compared=20
        to the kid initiating, and the parent authorizing, the =
transaction).
        <P></P>
        <UL></UL>
        <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>By this juncture, I've gotten rather tired of the word =
"kid,"=20
              as compared to something a bit less flip. I'm deliberately =

              continuing to use the word kid -- rather than =
<I>child</I>,=20
              <I>customer</I>, or some other equivalent term -- because =
it's=20
              important that the nomenclature of the entire set of =
design=20
              documents be internally consistent. I'm wishing that I had =
chosen=20
              my terms a bit more carefully, though.</P>
              <P>The second scenario actually introduces a new use case, =
which=20
              hadn't occurred to me earlier: "Parent authorizing prior=20
              deposits." This is really a stand-alone use case, even =
though=20
              authorization is also an operation in the current use case =

              (implying a subcase: Parent authorizes a single=20
              deposit.)</P></FONT></TD>
            <TD width=3D"5%">&nbsp;&nbsp;</TD></TR></TBODY></TABLE>
        <P><B>Workflow</B> <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>This=20
              section is the critical one, so I'll deviate a bit from =
the format=20
              I've been using hitherto and show how the workflow =
evolves. I=20
              start out by modeling the happy path as a simple list. =
</FONT></TD>
            <TD width=3D"5%">&nbsp;&nbsp;</TD></TR></TBODY></TABLE>
        <P>The happy path scenario: <BR><BR>
        <OL>
          <LI>Kid requests a deposit slip from teller and fills it out.=20
          <LI>Kid submits the deposit slip and passbook to the teller.=20
          <LI>Teller verifies the kid's identity as valid.=20
          <LI>Teller sends the deposit slip to bank officer for =
approval.=20
          <LI>Bank officer returns the deposit slip to teller, marked as =

          approved.=20
          <LI>Teller makes an entry in kid's passbook showing the =
deposit.=20
          <LI>Teller returns the passbook to the kid. </LI></OL>
        <P></P>
        <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>Though a linear list is sufficient for a simple =
workflow, it=20
              doesn't cut the mustard when the workflow gets =
complicated.</P>
              <P>Constantine and Lockwood recommend that you represent =
nonlinear=20
              operations using phrases like "In any order:" followed by =
a list.=20
              You could also use "Simultaneously" followed by a list to=20
              represent concurrency.</P>
              <P>Maybe I'm just a visual kind of guy, but I find these=20
              words-only representation of use cases to be confusing. I =
prefer=20
              UML workflow diagrams when the use case is at all =
complicated. The=20
              UML for the simple happy path is shown in Figure =
1.</P></FONT></TD>
            <TD width=3D"5%">&nbsp;&nbsp;</TD></TR></TBODY></TABLE>
        <P><A name=3D_figure1_><B>Figure 1. The happy path workflow =
diagram</B>=20
        <BR><IMG border=3D0=20
        =
src=3D"http://www-106.ibm.com/developerworks/library/co-design8/activity1=
.gif"></A></P>
        <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>The notation is more-or-less self explanatory. Each box =
is an=20
              activity, flow is indicated by arrows. You start at a =
solid circle=20
              and end at a target. The columns, called <I>swim =
lanes</I>,=20
              identify the class of objects (or the subsystems) that are =

              responsible for performing the activity.</P>
              <P>Looking at the diagram, I notice that there is some =
scope for=20
              parallelism. That is, some activities (verifying the kid's =

              identity and approving the deposit) could be done in =
parallel.=20
              (You could also say that the order in which these =
activities are=20
              executed is unimportant, provided that they are all =
executed=20
              before moving on to the next step.)</P>
              <P><A=20
              =
href=3D"http://www-106.ibm.com/developerworks/library/co-design8/index.ht=
ml#_figure2_">Figure=20
              2</A> shows the modifications required to <A=20
              =
href=3D"http://www-106.ibm.com/developerworks/library/co-design8/index.ht=
ml#_figure1_">Figure=20
              1</A> to reflect this parallelism. The heavy horizontal =
lines that=20
              begin (are at the top of) a set of parallel activities are =
called=20
              <I>forks</I>. The lines at the bottom, which represent the =
point=20
              where the activities must synchronize before further work =
is=20
              possible, are called <I>joins</I>.</P></FONT></TD>
            <TD width=3D"5%">&nbsp;&nbsp;</TD></TR></TBODY></TABLE>
        <P><A name=3D_figure2_><B>Figure 2. The happy path, modified to =
reflect=20
        parallelism</B><BR><IMG border=3D0=20
        =
src=3D"http://www-106.ibm.com/developerworks/library/co-design8/activity2=
.gif"></A></P>
        <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>Now I go back and look at the other two scenarios, and =
try to=20
              merge them into the happy path activity diagram. (The =
modified=20
              diagram is in <A=20
              =
href=3D"http://www-106.ibm.com/developerworks/library/co-design8/index.ht=
ml#_figure3_">Figure=20