Five-Step UML: OOAD for Short Attention Spans - Define, Refine, Assign

IN THIS CHAPTER, I’ll introduce you to Five-Step UML. We’ll work through the whole process from beginning to end, and along the way, I’ll be introducing all the UML notation that you’ll need to understand the relevant diagrams. I’ll also show you how the whole thing works from the point of view of .NET development.

By way of examples, I’ll be using lots of diagrams from the Kennel Management System case study, which was introduced at the end of the last chapter. I’m not going to show you everything in exhaustive detail at this stage, however, because we’ll be examining that case study more slowly throughout Part Two of the book. The aim of this chapter is simply to give you an overview of the whole process, a feel for how it all fits together, and a chance to get started with some modeling yourself.

So, I’ll begin this chapter with an overview of Five-Step UML to give you the big picture. Next we’ll focus in on the various steps. With each step, I’ll start by showing you the relevant UML notation that you’ll need, then walk through the process, and then we’ll look at some examples from the KMS.

Using a Process

OOAD and UML form a chicken-and-egg paradox: a good OOAD process requires a good notation; but when you study the notation, the most common question is, “Why would I do that?” where that means drawing a particular diagram to show a particular piece of your model. Often, the answer is, “Because we need it for this stage of the process.” The best way to teach UML effectively is to teach a software development process. And that’s when the groaning begins: Oh, no, not another process!

What’s Wrong with Process?

Why is it that programmers and process don’t mix well? Here are some of the common perceptions:

• We’re too busy. Process means steps to follow, things to do. Well, we’re all overworked already. Who wants yet more work? We’ve got code to crank out!

• It’s too much hassle. There are too many steps in a process. They just get in our way. The steps are too difficult or too poorly explained. We spent a lot of time learning to write code; now we have to learn all this other stuff, too? This is just make-work imposed on us by “the suits.” Let’s just crank out code!

• It’s too complex. Look, we all know how to write code. Why are we making it all so complicated? Let’s just start cranking out the code.

• It never works. Every so often, some pointy-haired manager type comes along with a “brilliant” plan that will “fix” everything. Then next year, there’s another plan, and another after that. And nothing ever really changes around here. So why waste time trying? We’re better off just cranking out code.

• It’s too boring. Hey, code is fun! Process is work. Which would you rather do?

Whether these perceptions are true or not—and there’s some element of truth in each of them—they certainly make it harder to teach or learn process.

The Answer: Five-Step UML

In order to learn UML, then, we’ll start with Five-Step UML, a lightweight OOAD process that specifically addresses the common perceptions about process:

• You’re not too busy. Five-Step UML is an aid to thinking about the problem and will give you focus and actually save you time. This isn’t about extra steps for you to follow; it’s about saving you steps by getting the design right in advance, so you spend less time rewriting code you’ve done wrong.

• It’s not a lot of hassle. Although you can use a modeling tool, Five-Step UML can be performed with paper, Post-it notes, and a pencil. It doesn’t get in your way; it helps you to talk about the problem.

• It’s not too complex. Five steps. Four diagram types (five, if you need Deployment Diagrams). Paper, Post-it notes, and pencil. How complex can it be?

• It will work. Trust me. Or don’t trust me, and prove me wrong. But give it a try. Five-Step UML should be just enough process to show the benefits of UML, but not so much process as to drag you down.

• It’s not boring, it’s fun! Well, that’s what I think anyway, and I have a lot of student feedback to support me. But you be the judge.

Now I don’t want to mislead you: Five-Step UML isn’t a full-featured OOAD process suitable for the development of complex systems. It has none of the management, testing, documentation, and review features that you expect from a complete process. It’s only a learning tool, a skeletal process suitable for learning UML, and not much more.

---

I’m a fan of processes for complex system development. I think you should encourage your team to adopt more than Five-Step UML. But perhaps your team is particularly averse to process. Perhaps after looking at Five-Step UML, they may see it as the maximum process they’re willing to implement.

Is that bad? Not necessarily. According to Scott W. Ambler, “Agile Modeling (AM) is a chaordic, practice-based methodology for effective modeling and documentation of software-based systems.” 1 Ambler’s book describes lightweight modeling practices that might be characterized as “just enough”: just enough modeling and just enough process to get the job done. Five-Step UML is compatible with many of the Core Practices of Agile Modeling:

• Apply the Right Artifacts

• Create Several Models in Parallel

• Iterate to Another Artifact

• Model in Small Increments

• Model with Others

• Active Stakeholder Participation

• Collective Ownership

• Display Models Publicly

• Create Simple Content

• Depict Models Simply

• Use the Simplest Tools

As Ambler says, “AM is not a prescriptive process. In other words, it doesn’t define detailed procedures for how to create a given type of model; instead it provides advice for how to be effective as a modeler.” Similarly, you might apply Five-Step UML as a modeling strategy inside of a larger process, whether it be a prescriptive process like the Unified Process or an agile process like Extreme Programming or Scrum.

1. Scott W. Ambler, Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process (John Wiley & Sons, 2002) Chapter 2

---

Overview of Five-Step UML

Five-Step UML is also an example of what I call Model-Driven Development, in which the models become the central artifacts of the process, the central repository of all that is known about the system.

In this chapter, I’ll walk you through the complete process of Five-Step UML, but I won’t go into a lot of detail or tie together all the tasks outside of modeling, architecture, design, and coding. Later in the book, in Chapters 6 through 11, we’ll go though each step in more detail and see how you can tie the models to management, testing, and documentation tasks.

The Five Steps are as follows:

1. Define. Identify the requirements of your system via Use Case Diagrams. Add other diagrams where they shed light on the use cases.

2. Refine. Detail the steps in each requirement via scenarios captured in Activity Diagrams. Add other diagrams where they shed light on the activities.

3. Assign. Use the Activity Diagrams to assign the steps to elements of your system.

4. Design. Show the relations among the elements with Component Diagrams. Add other diagrams where they shed light on the components.

5. Repeat/iterate/drill down/divide and conquer. Narrow the scope of your process to individual elements (designed with Class Diagrams); or expand it out to whole systems (designed with Deployment Diagrams). Add other diagrams wherever they help you understand the system. Repeat Steps 1 through 4 as appropriate for the current scope. Like Boehm’s Spiral development process, Evolutionary Development, and many other modern processes, Five-Step UML is an incremental, recursive approach.

---

What happens when you learn something or know something that doesn’t “fit” your current step in Five-Step UML? Suppose your requirements tell you beyond a doubt that you’ll need a Web server, a DB server, and a firewall box? You can’t model that as a set of use cases.

In that case, read the first guideline in Chapter 3, Do What Works. These steps and the order they are in form a useful set of guidelines, not a rigid set of rules.

You can either read ahead in Five-Step UML to find the right way to handle the information; or you can simply write it down and set it aside, then revisit it until you find a step where you learn how to model the information.

Do What Works usually implies “update the model and draw the diagrams that fit what you know.” But right now, you’re just learning UML, so you can’t be expected to know how to model every piece of information. Just write it down and move along.

I’ll talk about this idea in more detail in the next chapter, along with a whole bunch of pragmatic guidelines to help you find your way through the modeling maze.

---

>>> More Practices Articles          >>> More By Apress Publishing

blog comments powered by Disqus