Modeling Methodology = Process + Notation + Tool

According to Webster's dictionary, a methodology is

Note?/td>

A set of systematic procedures used by a discipline [to achieve a particular desired outcome].

A modeling methodology, OO or otherwise, ideally involves three components:

• A process: The "how to" steps for gathering the requirements and determining the abstraction to be modeled

• A notation: A graphical "language" for communicating the model

• A tool: An automated way of rendering the notation, typically in "drag-and-drop" fashion

Although these constitute the ideal components of a modeling methodology, they are not all of equal importance.

• Adhering to a sound process is certainly critical.

• However, we can sometimes get by with a narrative text description of an abstraction without having to resort to portraying it with formal graphical notation.

• And, when we do choose to depict an abstraction formally via a graphical notation, it isn't mandatory that we use a specialized tool for doing so.

In other words, following an organized process is the most critical aspect of object modeling; using a particular notation is important, but less so; and our choice of a particular tool for rendering the model is the least important aspect of the three (see Figure 8-1).

Many important contributions in the form of new processes, notations, and tools have been made in the OO methodology arena over the years by numerous well-known methodologists. In some sense, if you're just getting into objects for the first time now, you're fortunate, because you managed to avoid the "methodology wars" that raged for many years as methodologists and their followers argued about what were in some cases seemingly esoteric details.

Here is a partial list of contributions made in the object methodology arena over the past few decades; the list is in no particular order.

• James Rumbaugh et al.: The Object Modeling Technique (OMT)

• Grady Booch: The Booch Method

• Sally Schlaer and Stephen Mellor: Emphasis on state diagrams

• Rebecca Wirfs-Brock et al.: Responsibility-driven design; "Classes— Responsibilities—Collaborations" (CRC) cards

• Bertrand Meyer: The Eiffel programming language; the notion of programming by contract

• James Martin/James Odell: Retooling of their functional decomposition methodologies for use with object-oriented systems

• Peter Coad/Edward Yourdon: As in the preceding entry

• Ivar Jacobson: Use cases as a means of formalizing requirements

• Derek Coleman et al. (HP): The Fusion Method

• Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (the "Gang of Four"): Design pattern reuse

In recent years, there has been a major push in the industry to meld the best ideas of competing methodologies into a single approach, with particular emphasis being placed on coming up with a universal modeling notation. The resultant notation, known as the Unified Modeling Language (UML), represents the collaborative efforts of three of the leaders in the OO methodology field—James Rumbaugh, Grady Booch, and Ivar Jacobson—and has become the industry standard object modeling notation. (You'll learn the basics of UML in Chapters 10 and 11.)

Along with the UML, these three gentlemen—known affectionately in the industry as the "Three Amigos"—have also contributed heavily to the evolution of an overall methodology known as the Rational Unified Process (RUP), a full-blown software development methodology encompassing modeling, project management, and configuration management workflows. But we aren't going to dwell on the details of this particular methodology in this book, because as we mentioned in the Introduction, it isn't our intention to teach you any one specific methodology in great detail. By learning a sound, generic process for object modeling, you'll be armed with the knowledge you need to read about, evaluate, and select a specific methodology such as RUP, or to craft your own hybrid approach by mixing and matching the processes, notation, and tool(s) from various methodologies that make the most sense for your organization.

As for modeling tools, you don't need one, strictly speaking, to appreciate the material presented in this book. But, we've anticipated that you'll likely want to get your "hands dirty" with a modeling tool. Because of this, we include a general discussion of tool pros and cons a bit later in this chapter.

It's important to keep in mind that a methodology is but a means to an end, and it's the end—a usable, flexible, maintainable, reliable, and functionally correct software system, along with thorough, clear supporting documentation—that we care most about when all is said and done.

To help illustrate this point, let's use a simple analogy. Say that our goal is to cheer people up. We decide to hand draw (process) a smiley face (an abstraction of the desired behavior, rendered with a graphical notation) with a pencil (tool), as shown in Figure 8-2.

After we're done, we put our pencil away, hang our smiley face picture on the wall, and go about our business. A few days go by, and we note that people are indeed cheered up by our picture, and so our original goal has been achieved. In hindsight, we could have accomplished this same goal using

• A variety of different "processes"—hand drawing, rubber stamping, cutting pictures from a magazine

• A variety of different "notations"—the graphical notation of a smiley face, or a cartoon, or the narrative text of a joke or sign

• A variety of different "tools"—a pen, a pencil, a paintbrush, a crayon

Now, back to our homebuilding analogy. Long after the architect and construction crew have left a building site, taking their equipment and tools with them, the house that they have built will remain standing as a testimonial to the quality of the materials they used, how sound a construction approach was employed, and how elegant a blueprint they had to start with. The blueprint will come in handy later on when the time comes to remodel or maintain the home, so we certainly won't throw it away; but, the "livability" and ease/affordability of maintaining the home will be the primary measure of success.

The same is true for software development: the real legacy of a software development project is the resultant software system, which is, after all, the reason for using a methodology to produce a model in the first place. We must take care to avoid getting so caught up in debating the relative merits of one methodology versus another that we fail to produce useful software; as you can see in Figure 8-3, there are many paths to the same destination.