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:
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.
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.
ICONIX Software Engineering, Inc./2800 28th Street, Suite 320/Santa Monica, CA 90405/Tel (310)458-0092/Fax (310)396-3454/email: UMLtraining@iconixsw.com