|
We've written this book
with the following presumptions about you, the reader:
You'd like to write some code, eventually, but you've decided
that first you're going to do good, thorough OO analysis and design,
expressed in the UML.
You'd like to write this code during the useful life of your project.
You'd like this code to meet the requirements of your users (in
other words, you'd like to be use case driven in your modeling
efforts).
You'd like a solid, maintainable, resilient OO architecture within
which to organize your code.
This book is designed to help you get from point A (use cases)
to point B (code) in the most efficient manner possible, using
an approach that's been proven to work on a wide variety of projects.
In short, I'm aiming to answer the following question:
Theory vs. Practice
The difference between theory and practice is that, in theory,
there is no difference between theory and practice.
More specifically: the reason this book is subtitled A Practical
Approach is that the three amigos-Grady Booch, Jim Rumbaugh, and
Ivar Jacobson-write what amounts to OO theory, even in the new
(as I write this) Unified Modeling Language User Guide.
Allow me to explain.
The cold, hard reality of the world of software development is
that there is simply never enough time for modeling. This means
that even though the UML generally provides at least three different
ways to describe a given aspect of development, project schedules
usually make it impractical to use more than one, let alone all
three. To make things worse, just trying to decide whether to
use this UML technique or that one can be incredibly time-consuming.
Therefore, I offer a simplified view that makes no attempt to
cover everything that the UML offers. Some of the more esoteric
topics that I don't talk about, or mention but don't discuss in
detail, are activity diagrams, deployment diagrams, use case collaborations,
multi-level statecharts, and types and roles. Rather, I'm presenting
a streamlined approach to software development that includes a
minimal set of diagrams and techniques that you can use to get
from use cases to code quickly and efficiently. You can always
elect to use other aspects of the UML if you find them helpful;
my approach is flexible and open.
In a couple of cases, I use extensions to standard UML, where
they make the job easier. I make no apologies for doing this:
the UML was designed to be extensible, and rightly so. The extensions
that I advocate in this book work-they save time and money, and
yield good results as well. The positive results associated with
my six years of teaching experience, in connection with dozens
of projects in a wide range of industries, offer backup to that
last statement.
Organization of This
Book
This book has eight chapters. Let's start with our desired destination
(code, of course) and work backwards.
Before we can get to code, which I address in Chapter 8, Implementation,
we need to have a complete set of classes with accompanying attributes
and methods.
We only have enough information to make good decisions about which
classes are responsible for which methods while we are drawing
sequence diagrams (the subject of Chapter 5, Interaction Modeling).
So, we need to do a sequence diagram for every use case. We will
allocate methods to classes as we do this.
Before we can draw a sequence diagram for a use case, we need
to have a pretty good idea what objects will be participating
in that use case, and what functions the system will perform as
a result of user actions. We get this information from robustness
diagrams, which result from Robustness Analysis (Chapter 4). will
discover new objects, and add attributes to classes, as we draw
robustness diagrams.
Before we draw a robustness diagram, though, we need to describe
system usage in the context of the object model; in other words,
we need to write use case text, following the guidelines I present
in Chapter 3, Use Case Modeling. We also need to explicitly name
our "boundary objects," which the "actors"
will use to interface with our new system, and account for special
cases of behavior. We will discover new objects as we do these
things. Before we can write use case text, we need to identify
the main abstractions present in the problem domain. In other
words, we need a domain model (thus, Chapter 2: Domain Modeling).
Chapter 1 describes the overall approach. Chapter 6 discusses
collaboration diagrams and state diagrams, which are optional
within the approach. And Chapter 7 talks about how to deal with
requirements throughout a project. I'd like to highlight two features
that I think help make this book unique in the world of OO.
"Top 10" lists appear at the end of each chapter after
Chapter 1. These summarize the points I make within the preceding
text in ways that I hope you will find to be handy for repeated
reference.
"Analysis paralysis" alerts are scattered throughout
the main text. I've written these to highlight those points in
a software development project at which it's all to easy to get
bogged down in non-productive activities. I should also point
out that this book is considerably more fun, not to mention funnier,
than most OO books.
|
