the oo design process5.mht

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

            "system" of some sort, but it's certainly not your user's =
problem,=20
            and it's the user that's important here.</P>
            <P><B>Desired outcome</B><BR>By definition, a use case =
should have a=20
            useful outcome. Some sort of work that has value must be =
performed.=20
            Describe the outcome here. The outcome might be a report (in =
which=20
            case you should include an example of what the report will =
look=20
            like), an event or condition (an employee will now receive =
health=20
            benefits), or the like, but there must be a useful =
outcome.</P>
            <P><B>User goals</B><BR>What are the real goals of the user =
with=20
            respect to the use case? Note that goals are not the same =
thing as=20
            the use-case description. If the "Desired outcome" section =
describes=20
            <I>what</I> the user hopes to accomplish, the "Goals" =
section=20
            describes <I>why</I> the user is doing it.</P>
            <P>Knowing the user goals can influence the direction of a =
use case=20
            in radical ways. To borrow an example from Alan Cooper, =
let's say=20
            that we are charged with creating a meeting-scheduler =
program. A=20
            tempting use case is "scheduling a meeting." Visions of =
calendars=20
            and appointment books immediately pop into your mind. But =
that way=20
            lies Microsoft Outlook -- a bloated, hard-to-use program =
that does=20
            virtually nothing useful for anybody (now tell us what you =
really=20
            think, Allen).</P>
            <P>So how do we avoid the Outlookification of our system? By =

            considering goals. What is everybody's goal with respect to =
a=20
            meeting? I guarantee that we all have the same goal: not to =
go at=20
            all. Barring that, our goal is to get out as quickly as =
possible,=20
            and to make the meeting as productive as possible. The only =
way to=20
            achieve that goal is to have an agenda. Therefore, the first =
step in=20
            the "scheduling a meeting" use case is the subcase "creating =
an=20
            agenda." (More about subcases in a moment.) The actual =
deciding on a=20
            date and time turns out to be secondary.</P>
            <P><B>Participants/Roles</B><BR>The participants in a use =
case are=20
            not physical users, they are the roles that a physical user =
might=20
            have with respect to a system. For example, if we're doing a =

            time-sheet authorization system, two roles come to mind =
immediately:=20
            employees (who fill out time sheets) and managers (who =
authorize=20
            them). The fact that the same physical person might take on =
both=20
            roles at some juncture is irrelevant, there are two =
<I>logical</I>=20
            participants: the employee and the manager.</P>
            <P>The UML characterizes these roles as "actors." However, =
I've=20
            deliberately avoided that nomenclature. To my mind, the =
physical=20
            user is an actor who takes on several roles with respect to =
the=20
            system. The actors are often outside the system, and are =
irrelevant.=20
            What's important is the roles that the actors take on. (I'm =
not=20
            alone in feeling that "actor" is a bad choice of =
terminology; see <A=20
            =
href=3D"http://www-106.ibm.com/developerworks/library/co-design5.html?dwz=
one=3Dcomponents#resources">Resources</A>.)=20
            </P>
            <P>There is one important exception to the =
actors-are-external rule.=20
            Consider the issues surrounding access control: You are=20
            authenticating the actor to operate within the program in a =
given=20
            role. Consequently, the actor has a presence in the program, =
and a=20
            mapping of actors to roles is central to the way that the =
program=20
            works. </P>
            <TABLE align=3Dright border=3D1 cellPadding=3D0 =
class=3Dsidebar=20
              width=3D"35%"><TBODY>
              <TR>
                <TD><B>CRC cards</B><BR>For each role, we need to =
establish=20
                  two critical pieces of information:=20
                  <OL>
                    <LI>The <I>responsibilities</I> of actor when in =
this role.=20
                    For example, bank tellers get deposit and withdrawal =

                    requests from customers, and get approvals for =
withdrawals=20
                    from bank officers.=20
                    <LI>The actor's <I>collaborators</I> -- the roles =
with which=20
                    communication is necessary. For example, a bank =
teller=20
                    collaborates with both the customer and the bank =
officer,=20
                    but the officer never collaborates directly with the =

                    customer. </LI></OL></TD></TR></TBODY></TABLE>
            <P>These categories are two components of something called a =
CRC=20
            (for Class/Responsibility/Collaborator) card, which are used =
in some=20
            OO-design methodologies such as Kent Beck's Extreme =
Programming.=20
            (CRC cards were developed by Beck and Ward Cunningham as a =
teaching=20
            aid; see <A=20
            =
href=3D"http://www-106.ibm.com/developerworks/library/co-design5.html?dwz=
one=3Dcomponents#resources">Resources</A>.)</P>
            <P>Since this information is tied to participants rather =
than=20
            explicit use cases (that is, an actor in a particular role =
might=20
            participate in several use cases), it's sometimes useful to =
maintain=20
            the CRC cards as a separate document that's referenced from =
the=20
            individual use cases. Maintaining that list of =
responsibilities will=20
            be very important as we move to UML dynamic modeling. </P>
            <P><B>Dependencies</B><BR>Dependency relationships sometimes =
don't=20
            exist -- but that's unusual when a program is complex enough =
to have=20
            more than one use case. Often the dependency relationships =
are not=20
            immediately apparent, but are discovered as the use-case =
model and=20
            associated user interface evolve.</P>
            <P>Typical dependency relationships include one or more of =
the=20
            following:=20
            <OL>
              <LI><STRONG>Subset/Combines</STRONG><BR>A subset use case =
(which I=20
              call a <CODE>subcase</CODE>) typically appears when you =
start=20
              analyzing the top-level cases and discover that a complex =
task can=20
              be accomplished by performing several smaller, but =
standalone,=20
              tasks. Each of these standalone tasks is a subset of the =
main use=20
              case. Whether you use "subset" or "combines" is really =
just a=20
              matter of where you start. If you start with smaller use =
cases and=20
              realize that you can combine them together into a larger =
one, then=20
              use "combines." If you start with the larger case and =
decompose=20
              it, use "subset." For example, though identifying yourself =

              (logging on) is typically not a use case in its own right =
(you=20
              wouldn't approach the system with the end goal of =
identifying=20
              yourself, and then shut off the machine and go home), it =
might be=20
              a subcase of other use cases. More to the point, the=20
              identification process might be the same in all use cases =
that=20
              required identification. It's useful to create an =
"identifying=20
              yourself" subcase and spec it out as if it were a =
standalone use=20
              case, then incorporate it by reference into the main use =
cases.=20
              <LI><STRONG>Uses/Is-used-by</STRONG> (includes)<BR>This =
one is=20
              very similar to a subcase relationship; don't waste a lot =
of time=20
              worrying about whether a "uses" or "subcase" relationship =
is=20
              better, since the two relationships are treated much the =
same way=20
              when using the use-case document. The main distinction =
between=20
              "subset" and "uses" is that a "uses" relationship applies =
when a=20
              use case is a subcase that is also a standalone use case. =
(It=20
              defines a standalone operation that has a useful outcome.) =
A=20
              subset-style relationship is sometimes used to distinguish =
a=20
              subcase that is used by only one other top-level use case, =
while a=20
              "uses" relationship might characterize a subcase that is =
used all=20
              over the place.=20
              <LI><STRONG>Precedes/Follows</STRONG><BR>This establishes =
a=20
              workflow between use cases. For example, "registering a =
customer"=20
              must precede "specifying an order" or "browsing the =
catalog."=20
              <LI><STRONG>Requires</STRONG><BR>Precedes/follows =
relationships=20
              indicate sequence, but not dependency. That is, =
"registering a=20
              customer" is required by the "buying items in shopping =
cart" use=20
              case, but it simply precedes the "browsing the catalog" =
use case=20
              -- it's not a requirement.=20
              <LI><STRONG>Extends/Is-specialization-of</STRONG><BR>If =
use case B=20
              extends use case A (that is, adds subtasks, =
operations,etc.), then=20
              B is a specialization of A. (Typically the extra tasks are =
needed=20
              in order to satisfy some special requirement that doesn't =
occur in=20
              the normal use case). For example, "identifying a manager" =
might=20
              be a specialization of "identifying an employee" because =
the=20
              manager might have to be authenticated to a higher =
security=20
              standard than a normal employee. (This =
<I>specialization</I>=20
              relationship will be called <I>derivation</I> by =
programmer types,=20
              who would say that B "derives from" A to indicate that B =
is a=20
              specialization of A.)=20
              <LI><STRONG>Resembles</STRONG><BR>Often, you'll notice =
that two=20
              use cases appear to be similar to each other, though there =
are=20
              minor differences in workflow. <I>Resembles</I> =
relationships=20
              indicate that you want to look closely at similar use =
cases,=20
              trying to find commonality that can be factored out into =
"subset"=20
              cases or equivalents.=20
              <LI><STRONG>Equivalent</STRONG><BR>Two use cases can =
appear to be=20
              different from the perspective of the user, but may end up =
being=20
              implemented identically (in the Bank of Allen example, a =
logical=20
              distinction between equivalent use cases). It's irrelevant =
to the=20
              user whether the underlying code is the same -- deposits =
and=20
              withdrawals are different logical operations. In any =
event,=20
              equivalent use cases have a way of diverging over the =
course of a=20
              design. </LI></OL>
            <P></P>
            <P>I've found that diagramming these dependency =
relationships using=20
            a UML static-model diagram is quite useful. (On the other =
hand,=20
            UML's official use-case notation is singularly worthless.)=20
            Constantine and Lockwood have proposed a notation for =
diagramming=20
            use-case relationships, but I prefer to use standard UML,=20
            introducing stereotypes when no existing notation convention =
can be=20
            pressed into service. I'll give you a concrete example later =
on (in=20
            the context of the Bank of Allen project).</P>
            <P><B>Preconditions</B><BR>What assumptions are you making =
about the=20
            state of the world when the use case runs? For example, =
customers=20
            must have an account with the bank before they can withdraw =
money.=20
            As a consequence, the "customer opening an account" use case =