the oo design process5.mht

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

must=20
            have been performed before the "customer withdrawing money" =
use case=20
            can be performed.</P>
            <P>What conditions must exist before this use case can =
complete=20
            successfully? The conditions can be internal, or external. =
For=20
            example: The account balance must be greater than the =
withdrawal=20
            amount.</P>
            <P><B>Scenarios</B><BR>Scenarios are small narrative =
descriptions of=20
            someone working through the use case. Use a fly-on-the-wall=20
            approach: Describe what happens as if you're a fly on the =
wall=20
            observing the events transpire.</P>
            <P>As is the case with the description, I try to keep the =
scenarios=20
            as abstract as possible (talking about how a bank, not a =
computer=20
            program that simulates a bank, is used). "Philip needs to =
make a=20
            withdrawal to buy groceries. He digs out his passbook from =
under the=20
            three-foot pile of dirty socks in the top drawer of his =
dresser, and=20
            finds that his balance is big enough to cover what he needs, =
and he=20
            heads off to the bank..."</P>
            <P>Some programmer-types dismiss the scenarios as worthless =
fluff,=20
            but I've found them useful. The most important use is in =
clarifying=20
            my own thinking. Often, when working through a scenario, =
I'll=20
            discover use cases that I haven't thought of, or I'll =
discover=20
            workflow issues that were not apparent. For example, a =
couple of=20
            questions naturally arise in the previous make-a-withdrawal=20
            fragment. (What if he can't find the passbook?) </P>
            <P>Consider a use case that might have several relevant =
scenarios.=20
            In a recent OO-design workshop that I conducted, we chose =
the=20
            class-registration system for Vanderbilt University as a =
sample=20
            project. There's only one high-level use case, here: =
"Registering=20
            for classes." Within this use case, several scenarios come =
to mind,=20
            however:=20
            <OL>
              <LI>I sit down, sign up for all my classes, get into them, =
and I'm=20
              happy. This sort of scenario -- in which everything works =
without=20
              a hitch -- is called (at least by me) the "happy path" =
scenario.=20
              <LI>I sign up for my classes, but one of them is full so =
I'm=20
              placed on a waiting list. Later on, a space becomes =
available in=20
              the class, I'm enrolled automatically, and am notified =
that I got=20
              into the class.=20
              <LI>Same as (2) above, but the class is required to =
graduate -- I=20
              <I>must</I> get into it.=20
              <LI>Etc. </LI></OL>
            <P></P>
            <P>In analyzing this set, I might decide that the second and =
third=20
            scenarios actually comprise a stand-alone use case that's =
distinct=20
            from the "happy-path" scenario.</P>
            <P>Note that some scenarios are failure scenarios, but it's =
a=20
            mistake to think of the set of scenarios as containing a =
single=20
            "happy-path" scenario and a large number of failure =
scenarios. In=20
            the class-registration, example, one real failure scenario =
is that=20
            you have to get into a class to graduate, but you can't get =
into the=20
            class.</P>
            <P>In fact, in most properly done use cases, there are no =
failure=20
            modes! This astonishing statement is not as shocking as it =
might, at=20
            first, appear. Most computer programs use error messages as =
a way to=20
            mask programmer laziness. The vast majority of "errors" =
could=20
            actually be handled just fine by the program itself. The =
error=20
            message is printed primarily because the programmers were =
too lazy=20
            to figure out how to handle the error, so they pushed the =
work onto=20
            the user. Take the class-is-full scenario. A lazy designer =
would say=20
            "Oh well, the class you want is full. That's just too bad. =
Nothing I=20
            can do about it" and classify this case as a failure =
scenario: A=20
            competent designer would work out a solution such as our=20
            waiting-list strategy. It's your job as a designer to solve =
the=20
            user's problems, not to push the problems back at the user. =
Alan=20
            Cooper goes so far as to say that well-written programs =
shouldn't=20
            print error messages at all. I'm not sure whether that goal =
is=20
            possible, but I'll bet you could eliminate 90% of the error =
messages=20
            from most programs, and end up with a more usable system as =
a=20
            consequence.</P>
            <P>Also, for you programmer types, note that serious fatal =
errors --=20
            the sorts of things that would cause exceptions to be thrown =
--=20
            don't appear in the use cases at all. These conditions =
represent the=20
            failure modes of the program -- they are implementation =
related and=20
            have nothing to do with the problem domain, so they don't =
belong in=20
            a use-case analysis. Remember, we are defining the problem =
to solve=20
            from the perspective of the user, we are not designing a =
computer=20
            program (yet). That will come later, after we fully =
understand the=20
            problem. An exception-toss error condition is really an=20
            implementation requirement (see below) and should be listed =
in the=20
            "Requirements" or "Implementation notes" sections.</P>
            <P>Don't take the foregoing discussion as an excuse not to =
think=20
            about failure conditions. Your goal is to think of every =
possible=20
            failure condition, and then make sure that every failure is =
handled=20
            gracefully every time it comes up. It can't hurt to make a =
working=20
            document on which you list all failure modes. You can then =
use that=20
            list as a checklist when you review the use cases to make =
sure that=20
            they're all covered.</P>
            <P>As a final note, the sales staff will find the scenarios =
really=20
            useful in putting together presentations. It's always good =
to sell=20
            the product that you're actually building.</P>
            <P><B>Workflow</B><BR>Often the use-case description is =
sufficient=20
            to describe the flow of work through a simple use case ("do =
A, then=20
            do B, then do C"). Sometimes the workflow is so complex that =
it=20
            would be inappropriate to attempt to describe all of it in =
the=20
            Description section, and sometimes a diagram (like a UML =
workflow=20
            diagram, which I'll discuss eventually) is needed to =
unambiguously=20
            define the workflow. That sort of information goes here.</P>
            <P><B>Postconditions</B><BR>Frequently a use case changes =
the state=20
            of a system (i.e. the account balance is now lower) rather =
than=20
            generating a physical product. Also, some use cases need to =
be=20
            followed by others in order to complete an entire task. This =
sort of=20
            information goes in the Postconditions section. That is, a=20
            postcondition is something that you can check after the use =
case=20
            completes in order to determine the success or failure of =
the use=20
            case. An example postcondition: the new balance is the old =
balance,=20
            less the amount withdrawn.</P>
            <P><B>Business rules</B><BR>Business rules are policies that =
the=20
            business establishes that might effect the outcome of the =
use case.=20
            For example, "You may not withdraw more than $20 dollars =
within a=20
            seven-day period." It's not a good idea to clutter up the =
use-case=20
            description with these rules, but they have to be specified =
somehow=20
            to make the document accurate enough to be usable. I've =
found that=20
            it's best to specify these rules in a separate document and =
then=20
            reference the individual relevant rules here in the =
"Business rules"=20
            section.</P>
            <P><B>Requirements</B><BR>Requirements are typically=20
            customer-specified behavioral constraints on the =
implementation of a=20
            system. ("You must support 10,000 transactions per minute.") =
They=20
            are, again, best specified in a separate document and =
referenced=20
            here.</P>
            <P>Note that some things that are called "requirements" =
actually=20
            aren't. UI design is often specified as a "requirement," but =
the=20
            real requirement is typically not how the program looks, but =
what it=20
            does. If the real users could care less whether the program =
uses=20
            kidney-shaped nested mauve buttons, then it's certainly not =
a=20
            "requirement" to use kidney-shaped nested mauve buttons, no =
matter=20
            how much you like them. (On the other hand, if the users do =
care,=20
            then it's indeed a requirement, no matter how silly it might =
seem to=20
            you. Live with it.)</P>
            <P>I once had a client who was fond of the phrase "The users =
demand=20
            [some feature.]" My response was "Which users? Give me their =
names=20
            so that I can call them up and discuss it." Since no such =
users=20
            actually existed, it was easy to discount these demands. =
This is not=20
            to say that designers don't occasionally think of useful =
features,=20
            but unless a real user is <I>enthusiastic</I> about your=20
            innovations, then they aren't real. It's really easy to =
browbeat=20
            your user community to accept some gawdawful innovation that =
will do=20
            nothing but annoy them for the life of the program. Resist =
the=20
            temptation.</P>
            <P>A good test for whether a requirement is valid is to =
reject any=20
            so-called requirement that specifies up front something that =
is a=20
            natural product of the design process (UI look and feel, =
program=20
            organization, etc.). Such "requirements" are just bad =
knee-jerk=20
            design. Expunge this junk from the requirements document. If =
you=20
            have a well-trained business-development team, these sorts =
of=20
            "requirements" won't be in the document to begin with.</P>
            <P>Finally, note that it's impossible for an OO designer to =
work=20
            from a list of "features." Feature lists tend to be long,=20
            disorganized collections of poorly thought out ideas that =
some=20
            customer suggested to a salesperson off the top of their =
heads. The=20
            salesperson then translates that suggestion into=20
            "OH-MY-GAWD-WE-HAVE-TO-HAVE-THIS-NOW!!!," and away we go. At =
best,=20
            they suggest avenues of research, but by themselves they are =
of=20
            dubious value. What you're interested in is <I>why</I> the =
feature=20
            was suggested. How would this particular feature make the =
user's job=20
            easier? What is the user trying to accomplish? Do any of =
your other=20
            customers need to accomplish the same thing? Is there some =
better=20
            way to accomplish the goal? Most importantly, is the task =
that the=20
            user wants to do really a use case that didn't occur to =
us?</P>
            <P><B>Implementation notes</B><BR>Though it's our goal to =
keep the=20
            use-case document as grounded in the problem domain as =
possible,=20
            it's natural for implementation details to occur to you as =
you work=20
            through the scenarios and workflow. You want to capture this =

            information when it pops into your head, so this section =
provides a=20
            place to jot down implementation notes. These notes aren't =
bolted in=20