Chapter 5
|
In this chapter we will briefly cover the basic ideas of UML and object modeling. In the next chapter, we will look at the UML models for a simple commercial product that I wrote (a help desk system). It would be best to read this and the next chapter in one sitting because we will not see actual diagrams in this chapter you have to wait for Chapter 6.
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:
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.
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.
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.
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:
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.