📄 tij0029.html
字号:
<html><body>
<table width="100%"><tr>
<td>
<a href="http://www.bruceeckel.com/javabook.html">Bruce Eckel's Thinking in Java</a>
</td>
<td align="right">
<a href="tij_c.html">Contents</a> | <a href="tij0028.html">Prev</a> | <a href="tij0030.html">Next</a>
</td>
</tr></table>
<hr>
<H2 ALIGN=LEFT>
Analysis
and Design
<P><A NAME="Index54"></A><A NAME="Index55"></A><A NAME="Index56"></A></H2>
<DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">The
object-oriented paradigm is a new and different way of thinking about
programming and many folks have trouble at first knowing how to approach a
project. Now that you know that everything is supposed to be an object, you can
create a “good” design, one that will take advantage of all the
benefits that OOP has to offer.
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">Books
on OOP analysis and design are coming out of the woodwork. Most of these books
are filled with lots of long words, awkward prose and important-sounding
pronouncements.
</FONT><A NAME="fnB9" HREF="#fn9">[9]</A><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
I come away thinking the book would be better as a chapter or at the most a
very short book and feeling annoyed that this process couldn’t be
described simply and directly. (It disturbs me that people who purport to
specialize in managing complexity have such trouble writing clear and simple
books.) After all, the whole point of OOP is to make the <A NAME="Index57"></A>process
of software development easier, and although it would seem to threaten the
livelihood of those of us who consult because things are complex, why not make
it simple? So, hoping I’ve built a healthy skepticism within you, I shall
endeavor to give you my own perspective on analysis and design in as few
paragraphs as possible.
</FONT><a name="_Toc408018409"></a><P></DIV>
<A NAME="Heading53"></A><H3 ALIGN=LEFT>
Staying
on course
</H3>
<DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">While
you’re going through the development process, the most important issue is
this: don’t get lost. It’s easy to do. Most of these <A NAME="Index58"></A>methodologies
are designed to solve the largest of problems. (This makes sense; these are the
especially difficult projects that justify calling in that author as
consultant, and justify the author’s large fees.) Remember that most
projects don’t fit into that category, so you can usually have a
successful analysis and design with a relatively small subset of what a
methodology recommends. But some sort of process, no matter how limited, will
generally get you on your way in a much better fashion than simply beginning to
code.
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">That
said, if you’re looking at a methodology that contains tremendous detail
and suggests many steps and documents, it’s still difficult to know when
to stop. Keep in mind what you’re trying to discover:
</FONT><P></DIV>
<OL>
<LI><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"> What
are the objects? (How do you partition your project into its component parts?)
</FONT><LI><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"> What
are their interfaces? (What messages do you need to be able to send to each
object?)
</FONT></OL><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">If
you come up with nothing more than the objects and their interfaces then you
can write a program. For various reasons you might need more descriptions and
documents than this, but you can’t really get away with any less.
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">The
process can be undertaken in four phases, and a phase 0 which is just the
initial commitment to using some kind of structure.
</FONT><a name="_Toc408018410"></a><P></DIV>
<A NAME="Heading54"></A><H3 ALIGN=LEFT>
Phase
0: Let’s make a plan
</H3>
<DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">The
first step is to decide what steps you’re going to have in your process.
It sounds simple (in fact,
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><I>all</I></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
of this sounds simple) and yet, often, people don’t even get around to
phase one before they start coding. If your plan is “let’s jump in
and start coding,” fine. (Sometimes that’s appropriate when you
have a well-understood problem.) At least agree that this is the <A NAME="Index59"></A>plan.
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">You
might also decide at this phase that some additional process structure is
necessary but not the whole nine yards. Understandably enough, some programmers
like to work in “vacation mode” in which no structure is imposed on
the process of developing their work: “It will be done when it’s
done.” This can be appealing for awhile, but I’ve found that having
a few milestones along the way helps to focus and galvanize your efforts around
those milestones instead of being stuck with the single goal of “finish
the project.” In addition, it divides the project into more bite-sized
pieces and make it seem less threatening.
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">When
I began to study story structure (so that I will someday write a novel) I was
initially resistant to the idea, feeling that when I wrote I simply let it flow
onto the page. What I found was that when I wrote about computers the structure
was simple enough so I didn’t need to think much about it, but I was
still structuring my work, albeit only semi-consciously in my head. So even if
you think that your plan is to just start coding, you still go through the
following phases while asking and answering certain questions.
</FONT><a name="_Toc408018411"></a><P></DIV>
<A NAME="Heading55"></A><H3 ALIGN=LEFT>
Phase
1: What are we making?
</H3>
<DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">In
the previous generation of program design (procedural design), this would be
called “creating the <A NAME="Index60"></A><A NAME="Index61"></A></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><I>requirements
analysis
</I></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
and <A NAME="Index62"></A><A NAME="Index63"></A></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><I>system
specification
</I></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">.”
These, of course, were places to get lost: intimidatingly-named documents that
could become big projects in their own right. Their intention was good,
however. The requirements analysis says “Make a list of the guidelines we
will use to know when the job is done and the customer is satisfied.” The
system specification says “Here’s a description of
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><I>what</I></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
the program will do (not
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><I>how</I></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">)
to satisfy the requirements.” The requirements analysis is really a
contract between you and the customer (even if the customer works within your
company or is some other object or system). The system specification is a
top-level exploration into the problem and in some sense a discovery of whether
it can be done and how long it will take. Since both of these will require
consensus among people, I think it’s best to keep them as bare as
possible – ideally, to lists and basic diagrams – to save time. You
might have other constraints that require you to expand them into bigger
documents.
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">It’s
necessary to stay focused on the heart of what you’re trying to
accomplish in this phase: determine what the system is supposed to do. The most
valuable tool for this is a collection of what are called “<A NAME="Index64"></A>use-cases.”
These are essentially descriptive answers to questions that start with
“What does the system do if ...” For example, “What does the
auto-teller do if a customer has just deposited a check within 24 hours and
there’s not enough in the account without the check to provide the
desired withdrawal?” The use-case then describes what the auto-teller
does in that case.
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">You
try to discover a full set of use-cases for your system, and once you’ve
done that you’ve got the core of what the system is supposed to do. The
nice thing about focusing on use-cases is that they always bring you back to
the essentials and keep you from drifting off into issues that aren’t
critical for getting the job done. That is, if you have a full set of use-cases
you can describe your system and move onto the next phase. You probably
won’t get it all figured out perfectly at this phase, but that’s
OK. Everything will reveal itself in the fullness of time, and if you demand a
perfect system specification at this point you’ll get stuck.
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">It
helps to kick-start this phase by describing the system in a few paragraphs and
then looking for nouns and verbs. The nouns become the objects and the verbs
become the methods in the object interfaces. You’ll be surprised at how
useful a tool this can be; sometimes it will accomplish the lion’s share
of the work for you.
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">Although
it’s a black art, at this point some kind of <A NAME="Index65"></A>scheduling
can be quite useful. You now have an overview of what you’re building so
you’ll probably be able to get some idea of how long it will take. A lot
of factors come into play here: if you estimate a long schedule then the
company might not decide to build it, or a manager might have already decided
how long the project should take and will try to influence your estimate. But
it’s best to have an honest schedule from the beginning and deal with the
tough decisions early. There have been a lot of attempts to come up with
accurate scheduling techniques (like techniques to predict the stock market),
but probably the best approach is to rely on your experience and intuition. Get
a gut feeling for how long it will really take, then double that and add 10
percent. Your gut feeling is probably correct; you
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><I>can</I></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
get something working in that time. The “doubling” will turn that
into something decent, and the 10 percent will deal with final polishing and
details. However you want to explain it, and regardless of the moans and
manipulations that happen when you reveal such a schedule, it just seems to
work out that way.
</FONT><a name="_Toc408018412"></a><P></DIV>
<A NAME="Heading56"></A><H3 ALIGN=LEFT>
Phase
2: How will we build it?
</H3>
<DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">In
this phase you must come up with a design that describes what the classes look
like and how they will interact. A useful diagramming tool that has evolved
over time is the <A NAME="Index66"></A></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><I>Unified
Modeling Language
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -