P. 1


|Views: 34|Likes:
Published by api-3777165

More info:

Published by: api-3777165 on Oct 16, 2008
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as DOC, PDF, TXT or read online from Scribd
See more
See less





I got my introduction to Object Oriented Modeling (OOM) by using Grady Booch’s methodology.

I was writing a series of C++ books for McGraw-Hill at the time, and Grady sent me a (hand marked up) copy of his manuscript for a book on OOM. At the time, there were over ten different methodologies a literal ”Tower of Babel” situation in design notations. UML borrowed ideas from the Booch notation, Rumbaugh notation, and Jacobson’s notation. UML is now widely accepted as the standard notation for performing OOM activities. Most books on UML (e.g., the book Paul Harmon and I wrote, ”Understanding UML”) go into some great detail on all UML diagram types. My approach here is a little different: in my own work, I find myself usually only using three types of diagrams and we will only discuss these three types of diagrams here:
• • •

Use Case describes how users of a system interact with it Class documents the public and (optionally) private APIs for a class Sequence shows how objects of different classes interact as a function of time

A word of warning: be aware that we are just looking at the most commonly used aspects of UML in this book; if you will be using UML with other team members, they are likely to want to use additional types of diagrams. That said, this chapter exposes you to the basics and provide a good starting point.

5.1 Use Case Diagrams
Even programmers who do not like to perform a lot of up front design work will find use case diagrams a very effective method to both understand customer requirements and as a type of contract between you and your customers. Like all aspects of good design, use case diagrams not only will help you to reduce the costs of writing all but the most trivial programs, they will also serve as insurance that you are developing what your customers really want. In the next chapter, we will see an example use case diagram (Figure Figure 6.1). As a developer, you will base the use cases that you write on conversations with your customer. A set of use cases can be refined until both you and your customer agree on the way that a system will be used and, in keeping with the philosophy of Extreme Programming, can be used to define test cases early in the development cycle. A good alternative to using UML modeling tool to create use case diagrams is to use 3x5 cards. Write a (very) brief description of each use case on a separate 3x5 card. In either case, the idea is to develop a set of independent example uses of the system under development.

5.2 Class Diagrams

Class diagrams are used to show both the APIs for a class and internal data and also to show the relationships between classes. I find class diagrams to be most useful when used to get a top-level overview of the major classes in a system and how they inter relate. For a complex system implemented with hundreds of classes, I do not think that it makes sense to produce class diagrams for all classes. Most UML modeling tools (e.g., Poseidon) offer ”round trip” capabilities: if you already have source code, then they can import the source code and automatically produce diagrams. If you modify a diagram in the modeling tool, for example: adding a few methods and extra class data, then the modeling tool can automatically update your source code. If I need to quickly produce high-level UML class diagrams for a new project, I find it fastest to use a text editor to write skeleton code (i.e., just method signatures and data definitions) for the top level classes and import this source code into my UML modeling tool. I use the tool to clean up the layout of the diagrams, and tweak the initial class design before allowing the modeling tool to update the original source code. While I find modeling the high level classes for a new project useful, I also have a word of warning: design is far from a perfect science. You will be modifying your design as you get experience implementing the system. For this reason, I prefer for my own work to cycle between design and implementation work. Too much up front design time can be wasted if during early implementation you discover errors in requirements analysis (which I consider part of design, not a separate step) or design that requires large modifications. I consider best practices to be a cyclical development style. Figure 6.2 in the next chapter I an example of a top-level class diagram for an automated help desk system.

5.3 Sequence Diagrams
Sequence diagrams are a great way to understand and to explain to other people how the objects in a system inter relate as a function of time. The utility of sequence diagrams is incredible for at least three reasons:
• • •

Allows developers to really understand the time-sequenced interaction between system objects. Allows technically oriented customers to get a better understanding of how the system will function. Allows developers to identify ”failure points” and facilitates setting up test cases.

I personally consider UML sequence diagrams as one of the ”big wins” for UML that does the most to justify the time required for UML modeling. We will see an example sequence diagram in Figure 6.3.

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->