8.1. The "Big Picture" Goal of Object Modeling

Our goal in object modeling is to render a precise, concise, understandable object-oriented (OO) model, or blueprint, of the system to be automated. This model will serve as an important tool for communication:

• To the future users of the system that we are about to build, an object model communicates part of the understanding of the system requirements (along with screen mock-ups, architecture diagrams, infrastructure design, and so on). Having the users review and "bless" the model will ensure that we get off on the right foot with a project because a mistake in judgment at the requirements analysis stage can prove much more costly to fix—by orders of magnitude—than if such a misunderstanding is found and corrected when the system is still just a "gleam in the user's eye."

• To the software development team, an object model communicates the structure and function of the software that needs to be built in order to satisfy those requirements. The object model bridges the semantic gap between users and developers. It facilitates communication between the two groups to help enable the folks responsible for quality assurance, testing, and documentation to identify potential problems early on in the development process (they would know exactly what the program was supposed to do and how it was designed to do it).

• Long after the application is operational, an object model lives on as a schematic diagram to help the myriad folks responsible for supporting and maintaining an application understand its structure and function.

8.1.1. Modeling Methodology = Process + Notation + Tool

According to Webster's dictionary, a methodology is

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 they 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. 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, you're fortunate if you're just getting into objects for the first time now 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

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

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

• Sally Shlaer 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 OO systems

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

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

• Martin Fowler: Enterprise patterns and architecture

Some years ago there was 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. (A brief introduction to UML is provided 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 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 anticipated that you'll likely want to get your hands dirty with a modeling tool, so 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, so our original goal has been achieved. In hindsight, we could have accomplished this same goal using the following:

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

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

• A variety of different tools: a pen, a pencil, a paintbrush, or 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.