HomePractices Page 3 - Introducing UML: Object-Oriented Analysis and Design
UML - Practices
The purpose of UML, or Unified Modeling Language, is communication; to be specific, it is to provide a comprehensive notation for communicating the requirements, architecture, implementation, deployment, and states of a system. This article will offer an overview of Object Oriented Analysis and Design, focusing in on the three most important concepts it encompasses: objects, analysis, and design. It is excerpted from the book UML Applied: A .Net Perspective, by Martin Shoemaker (Apress, 2004; ISBN: 1590590872).
UML, the Unified Modeling Language, is a graphical language designed to capture the artifacts of an OOAD process. It provides a comprehensive notation for communicating the requirements, behavior, architecture, and realization of an Object-Oriented design. As you saw in the last section, UML provides you with a way to create and document a model of a system.
What Makes the UML Unified?
To answer that, you need to jump in the WayBack Machine and travel back to the ancient history of OOAD—say, 1995. At that time, Object-Oriented Programming had proven its worth as a way of building applications and systems; and the hot new topics in the OO world were OOA and OOD. Since these topics were larger in scope than mere programming, the practitioners needed a way of displaying large, complex concepts in a simple graphical fashion. A number of competing OO notations emerged, chief among them being the Booch Notation designed by Grady Booch and the Object Modeling Technique (OMT) designed by James Rumbaugh (and others). And then began the religious wars: fanatical adherents of the competing notations fought petty little battles over clouds (Booch’s symbol for a class) versus rectangles (OMT’s symbol for a class).
Booch and Rumbaugh looked on this confusion with dismay: they saw the differences between their notations as minor, unworthy of so much rancor. And worse, they saw the religious wars detracting from what they felt should be the new focus: the OOAD process itself, particularly as a means for capturing requirements and behavior. They were very impressed by some of Ivar Jacobson’s work on Sequence Diagrams and his Objectory methodology; but with all the shouting about notation, no one was talking about process. So Booch and Rumbaugh and Jacobson (the Three Amigos) went on retreat to hammer out differences in their notations in private, and to adopt other useful notations as well (chief among these being David Harel’s State Diagram notation). They emerged with the Unified Modeling Language 0.8, a response to the Object Management Group’s call for a standard object modeling notation; and Booch’s company, Rational6 (which had hired Rumbaugh and Jacobson) incorporated UML into Rational ROSE, their OOAD tool. The UML then went through a few cycles of response and revision by the OO community; and UML 1.1 was adopted as a standard by the OMG in 1997. UML has been further refined, and is currently at version 1.4, with version 2.0 on the near horizon.
What UML Isn’t
With so much in UML, it’s worth mentioning what’s not UML. The following sections describe some related concepts that are often confused with UML itself.
Remember the goal of the Three Amigos: to focus attention on the OOAD process, not on the notation. Their notation isn’t a process in itself; rather, it’s designed to support a wide range of OO processes. There are a number of UML-based OOAD processes, including Fowler’s outline process,7 controlled iteration,8 Texel and Williams’s complete OO process,9 and, of course, the Unified Process (formerly Objectory) from the Three Amigos.10 A full list would be much longer, but would have a lot in common with these prominent examples. These processes differ somewhat in the degree of formality and the order of operations; but all involve using UML to identify and refine requirements, allocate those requirements to functional modules, and refine those modules. Without a process, new UML students are often adrift in a sea of concepts, with nothing to guide their course.
In this book, you’ll learn UML within the framework of Five-Step UML, which I find to be a “just enough” process: just enough process to help you understand the purpose of UML, but not so much as to bury you in paperwork and obscure the benefits of UML. Five-Step UML isn’t a large, full-featured OOAD process, falling somewhere between an academic exercise and Ambler’s Agile Modeling.11 Still, I find that some particularly process-averse teams that tend to reject a more formal process will accept Five-Step UML.
In the next chapter, I’ll show you how the Five-Step process works, and along the way, you should pick up a broad working knowledge of UML. In Chapter 3, I’ll talk about some pragmatic rules I like to apply to the Five-Step (and indeed any other) modeling process. Throughout the core chapters of this book (Part Two), we’ll work through each of the five steps in more detail, applying it to a real-world case study. Although the focus of this book is on Five-Step UML, we will look in more detail at some other processes and how they work in Chapter 12.
Rational XDE (or Any Other Tool)
Many UML practitioners—and of course, many UML tool vendors—tend to blur the line between UML and a given tool. I myself am prone to equating “what XDE can do” with “what UML can do,” since I do most of my UML work with Rational’s XDE tool. This habit isn’t inherently bad, since it’s usually easier to work with your tools than against them; but it’s important to realize that the features and capabilities of any given tool—even the market-leading UML tool from the people who gave us UML—may differ from the features and capabilities of UML itself. If UML is a language, then every tool speaks with a unique accent.
You can find a list of available UML tools in Appendix B.
A Silver Bullet
Good code will still require blood, sweat, tears, pizza, good management, and lots of thought. UML will help you to organize these factors (except the pizza), but you won’t be able to avoid them.