Do-It-Yourself UML

If you quickly flick through the rest of this chapter, it won’t take you long to figure out it’s a long one; and just sitting reading it from beginning to end could get a little tough, even with a big cup of coffee there to keep you going. And because we all know that the way to learn anything is to do it, not just to read about it, I recommend that you follow along with the exercises listed in this chapter, so you can start using UML right away.

Throughout this chapter, I’ll be examining each step in Five-Step UML; but before getting started, you should think about what kind of project you can use to get some practical UML experience.

You’ll need to select a problem domain which you’ll analyze and a solution which you’ll design with Five-Step UML. If you’re working by yourself, pick a domain in which you’re comfortable serving as customer, analyst, architect, and designer, but not one you know too well. If you’re working as a team, don’t pick a domain familiar to your team. Why shouldn’t you choose a familiar domain? Because experience shows that with a familiar domain, you’ll jump straight into designing

the system as it is when you should be analyzing the system as it should be. If you have no problem domain in mind, try one of these suggestions:

• Hotel room scheduling and reservations

• Flight scheduling and reservations

• Rental car scheduling and reservations

• Online travel service, including flight reservations, room reservations, car rental, and travel information (this will be less detailed than the preceding domains, but broader in scope).

• University course scheduling and enrollment

• Online banking

• Online pizza ordering service (a popular choice with many programmers)

• Package shipping and tracking

• A calculator

• A video game

• An electronic diary

Select one person to serve as the customer (and final arbiter of what the customer wants). Call this person the customer rep. The rest of the team will act as analysts and designers.

Five-Step UML is much more effective as a team exercise than as an individual exercise. The only student who has told me he didn’t learn from it was a conference attendee who chose to work by himself rather than join a group. UML is about communication, remember? Well, Five-Step UML is an exercise in team communication using UML. You’ll start to see the benefit when you draw the “perfect” picture, and your team members start tearing it apart, showing you what’s unclear, what you overlooked, and what you got wrong. And then, to make their points, they’ll have to produce even better pictures. I hate to use a management buzzword, but the synergism will astound you and sweep you up. Once you’ve done Five-Step UML with a good team, you may never want to design alone again. (This is the point of the Agile Modeling Core Practice, Model with Others.)

So I recommend you do the exercises in this chapter (and throughout the book) with a team of three to five people. Two is too few to generate enough disagreement; six or more can work, but some might have trouble getting at the paper. They don’t all have to have copies of this book (though it won’t break my heart if they do). They don’t even all have to be developers: managers, analysts, and end users should get a lot out of Steps 1 and 2; documenters and testers should get a lot out of Steps 1 through 4; and anyone who wants to learn more about the development process should learn something from all five steps. So rope in some coworkers, or friends, or relatives, or in-laws, or strangers off the street. For a team, these exercises should take about a day, if you try to do at least two of every diagram. Two diagrams make a good target. With the first diagram, you’re learning the process; with the second diagram, you’re practicing the process. If you try to analyze and design a whole system, this will take a lot longer.