the oo design process5.mht

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

            2001</P><!-- END title and author lines --><!-- Begin Table =
of Contents -->
            <P>
            <TABLE align=3Dright border=3D0 width=3D120>
              <TBODY>
              <TR>
                <TD align=3Dmiddle bgColor=3D#0033cc height=3D5><FONT =
color=3D#ffffff=20
                  face=3D"HELVETICA, HELV, ARIAL"=20
                size=3D-1><B>Contents:</B></FONT></TD></TR>
              <TR>
                <TD class=3Dtoc>&nbsp;<A=20
                  =
href=3D"http://www-106.ibm.com/developerworks/library/co-design5.html?dwz=
one=3Dcomponents#1">Introducing=20
                  use cases</A></FONT></TD></TR>
              <TR>
                <TD class=3Dtoc>&nbsp;<A=20
                  =
href=3D"http://www-106.ibm.com/developerworks/library/co-design5.html?dwz=
one=3Dcomponents#2">Presenting=20
                  a use case</A></FONT></TD></TR>
              <TR>
                <TD class=3Dtoc>&nbsp;<A=20
                  =
href=3D"http://www-106.ibm.com/developerworks/library/co-design5.html?dwz=
one=3Dcomponents#3">Summing=20
                  up</A></FONT></TD></TR>
              <TR>
                <TD class=3Dtoc>&nbsp;<A=20
                  =
href=3D"http://www-106.ibm.com/developerworks/library/co-design5.html?dwz=
one=3Dcomponents#resources">Resources</A></FONT></TD></TR>
              <TR>
                <TD class=3Dtoc>&nbsp;<A=20
                  =
href=3D"http://www-106.ibm.com/developerworks/library/co-design5.html?dwz=
one=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.ibm.com/i/c.gif"=20
            width=3D120></TD></TR></TBODY></TABLE></P><!-- End Table of =
Contents -->
            <P>In previous articles, we've refined the problem statement =
and=20
            mocked-up our educational software. In this article we'll =
look at=20
            use-case analysis.</P>
            <P>This article continues my series on the OO-design =
process. The=20
            first four parts are:=20
            <UL>
              <LI><A=20
              =
href=3D"http://www-4.ibm.com/software/developer/library/oo-design1/index.=
html">Getting=20
              started</A>=20
              <LI><A=20
              =
href=3D"http://www-4.ibm.com/software/developer/library/oo-design2/index.=
html">Beginning=20
              to design software</A>=20
              <LI><A=20
              =
href=3D"http://www-4.ibm.com/software/developer/library/oo-design3.html">=
Refining=20
              the problem definition</A>=20
              <LI><A=20
              =
href=3D"http://www-106.ibm.com/developerworks/components/library/co-desig=
n4.html">Verifying=20
              the analysis</A> </LI></UL>
            <P>This month I move on to analyzing the dynamic (runtime) =
behavior=20
            of the program. I'll do that by introducing the notion of a =
<I>use=20
            case</I> and talking about how one of these beasts is =
organized.=20
            Next month, I'll put this organization into the framework of =
the=20
            Bank of Allen. </P><A name=3D1></A>
            <P><STRONG class=3Dsubhead>Introducing use =
cases</STRONG><BR>The=20
            "problem statement" looks pretty good at this point. I've =
probably=20
            forgotten something critical, but there's no point in =
sitting around=20
            hoping that these missing pieces will spring from my head, =
fully=20
            armed, like Athena from the head of Zeus. By moving on and =
looking=20
            at the same problem in a different way, these missing pieces =
will=20
            become evident. The next step, then, is to look at the =
problem=20
            again, but this time from the perspective of dynamic (i.e. =
runtime)=20
            behavior. In a sense, the problem statement is a =
<I>static</I>=20
            definition of the problem -- it describes the problem that =
the user=20
            has to solve, but that's it. Eventually, I'll formalize this =
view of=20
            the system into something called a <I>static model</I>.</P>
            <P>The <I>dynamic</I> definition of the problem focuses, not =
on what=20
            has to be done, but on how you do it. That is, rather than =
looking=20
            at the problem itself, we'll look at the things the users =
have to do=20
            to solve the problem. The main tool we'll use to structure =
our=20
            thinking on that dynamic behavior is <I>use-case =
analysis</I>.=20
            Dynamic behavior can also be formalized into something =
called the=20
            <I>dynamic model</I>, but before we can do that, we have to =
figure=20
            out what the dynamic behavior <I>is</I>. We'll do this using =

            use-case analysis.</P>
            <P>First of all, a definition:=20
            <BLOCKQUOTE>A use case is a single task, performed by the =
end user=20
              of a system, that has some useful outcome. </BLOCKQUOTE>
            <P></P>
            <P>The definition of "end user" and "outcome" can vary -- an =
end=20
            user might be an automated subsystem, for example, and the =
nature of=20
            the outcome can vary radically from use case to use case. =
Sometimes=20
            the outcome is a physical product like a report, sometimes =
is an=20
            organizational goal, like hiring an employee. But there's =
always an=20
            outcome that has a perceived (by the user) value.</P>
            <P>You can think of a use case in terms of user intent. If a =
user=20
            walks up to the system with the intent of doing something, =
what is=20
            that "something?" Logging on is not a full-blown use case, =
for=20
            example, since nobody walks up to the system with the intent =
of=20
            doing nothing but logging on. You're logging on in order to=20
            accomplish some other larger end, to perform some useful =
task, and=20
            the use case is the definition of that larger task.</P><A=20
name=3D2></A>
            <P><STRONG class=3Dsubhead>Presenting a use =
case</STRONG><BR>As is=20
            often the case in software, an organized semiformal =
presentation of=20
            the use cases helps you get organized. The formal =
presentation=20
            typically involves several pieces, listed in <A=20
            =
href=3D"http://www-106.ibm.com/developerworks/library/co-design5.html?dwz=
one=3Dcomponents#table1">Table=20
            1</A>. (I'll explain what each section contains =
momentarily.) It's=20
            probably best to look at Table 1 as a checklist rather than =
a=20
            fill-in-the-blanks form. Not all sections are relevant in =
every=20
            use-case definition, and any of the sections can be combined =
(or=20
            omitted) in a real working document. </P>
            <P>Moreover, though the categories in Table 1 must all be =
addressed,=20
            they don't need to be addressed in the order specified in =
the table.=20
            Often, it's best to start with the scenarios, develop them =
into a=20
            formal workflow definition, and then fill in the other =
details. The=20
            ordering in Table 1 is really for the convenience of the=20
            implementer, not the creator, of the use case.</P>
            <P>We designers have several major goals in creating use =
cases:=20
            <OL>
              <LI>Develop an increased understanding of the problem.=20
              <LI>Communicate with the end users to make sure we're =
really=20
              solving their problems.=20
              <LI>Organize the dynamic behavior of the design (and the =
resulting=20
              program) to reflect the actual business model in the =
user's mind.=20
              In other words, assure that the program actually does =
something=20
              useful for a real user.=20
              <LI>Provide a road map and organizational framework for =
the actual=20
              development process. (More on this in a few months when we =
start=20
              talking about implementation.) </LI></OL>
            <P></P>
            <P><A name=3Dtable1><B>Table 1. The components of a formal =
use case=20
            presentation</B></A>=20
            <TABLE border=3D1 width=3D"80%">
              <TBODY>
              <TR>
                <TD>
                  <P>Name <BR>Description <BR>Desired outcome <BR>User =
goals=20
                  <BR>Participants/Roles <BR>Dependencies =
<BR>Preconditions=20
                  <BR>Scenarios <BR>Workflow <BR>Postconditions =
<BR>Business=20
                  rules <BR>Requirements <BR>Implementation notes=20
              </P></TD></TR></TBODY></TABLE>
            <P>Use-case definition is a collaborative process. Many of =
these=20
            components are specified by the business-side (typically =
marketing)=20
            organization, and others are filled in or expanded by the=20
            technical-side organization. The user-interface design is =
also an=20
            important component of use-case analysis. A UI mock up (not =
a=20
            prototype) provides a lot of useful feedback about whether =
we've=20
            captured the use cases correctly. I'll come back to =
use-case-based=20
            UI design next month.</P>
            <P>For now, let's expand on Table 1 and spell out the =
sections of=20
            the document in detail.</P>
            <P><B>Name</B><BR>All use cases should be named. Constantine =

            recommends using a gerund followed by a direct object (for =
example:=20
            "withdrawing funds" or "examining the passbook"). This =
convention=20
            encourages the use-case name to succinctly identify the =
operation=20
            being performed and the object (or subsystem) that's =
affected by the=20
            operation. I think that this recommendation is fine as far =
as it=20
            goes, but there's no particular benefit to rigidly following =
a=20
            formula if you end up omitting important information as a=20
            consequence. For example, "customer withdrawing funds from =
checking=20
            account" might be a different use case than "bank manager=20
            withdrawing funds from customer's checking account." A =
simple=20
            "withdrawing funds" is not a sufficiently descriptive =
name.</P>
            <P>Names should always be user-centric, not system-centric. =
For=20
            example, "making a deposit" (user-centric) versus "accepting =
a=20
            deposit (system-centric)." Name from the perspective of the =
user,=20
            not the system.</P>
            <P>A name, regardless of format, is critical -- you must be =
able to=20
            identify the use case unambiguously to be able to talk about =
it=20
            effectively. I also typically assign some sort of =
administrative=20
            identity to every use case so that it can be referenced =
easily from=20
            other documents. I usually prefer combining a very general=20
            description with a hierarchical numbering scheme (e.g.=20
            "<I>Withdrawal: 1.1</I>").</P>
            <P><B>Description</B><BR>Describe what the use case is=20
            accomplishing. What will the user be doing while =
"withdrawing funds"=20
            or "examining a passbook," for example. Go into detail, but =
don't=20
            describe how the user might use a computer program.</P>
            <P>For example, a bank customer might make a withdrawal by =
filling=20
            out a withdrawal slip and presenting the slip to the teller. =
The=20
            teller then takes the withdrawal slip to a bank officer for=20
            approval. The bank officer checks the account balance and =
issues an=20
            approval, etc. Note that nowhere in this discussion have I =
talked=20
            about computer programs, menus, dialog boxes, etc. These =
sorts of=20
            implementation details are <I>irrelevant</I> at this level. =
(Though,=20
            of course, you'll need well-defined implementation details =
before=20
            you can code. But we're not there yet).</P>
            <P>I have a particular pet peeve about an analysis-level =
document=20
            that mentions "the system." It might be your problem to =
create a=20