Flylib.com

Books Software

 
 
 

Chapter 2. The Unified Modeling Language

Chapter 2. The Unified Modeling Language

Who controls the past commands the future .

Who commands the future conquers the past .

—attributed to George Orwell

The UML has resurrected modeling as a respectable practice within software development. Indeed, it has moved modeling back into the development spotlight and made it an equal player with coding as an essential skill.

The UML has done this by providing a comprehensive language for modeling. It is every bit as expressive, flexible, and useful as programming languages are for coding—and it is at least as complicated in a similar way. More to the point, the UML has made it possible to see object-oriented models as having a legitimate existence outside of the realm of code-production—in business modeling, workflow design, and enterprise architecture, for example. These are realms that have been dominated by other modeling approaches until now.

Despite its evolutionary nature, the UML is very different from the modeling tools and languages that preceded it. These differences are what make UML so important to understand (not to mention the reasons why the UML is superseding them all).

This chapter will explore the roots of the UML within the traditions of software development. It will show how the UML is part of those traditions with appropriate history to justify a patterns-based approach for describing good UML modeling practices—using patterns based on practical traditions and rules of thumb and allowing for the beneficial inclusion of selected UML-specific idioms.

Chapter 10, "The UML in Context," will explore modeling and the UML (the nature of models and modeling), and Chapter 3, "UML Essentials, Elements, and Artifacts," will provide an introduction to the basic elements and artifacts of the UML and the connections between the UML and patterns. Essentially, it discusses how patterns can contribute to working with the UML in a way that fits the new kind of modeling the UML makes possible.

So, rather than seeing the UML as just another tool, you will be able to see how it can affect the way you work as a software developer—how it makes possible a new way to think about modeling.

Just to be clear, the intention of these few chapters is not to provide the ultimate guide to the UML. They will only provide enough context to make the pattern language useful and meaningful. Unlike the built world from which Alexander wove a pattern language, the UML is new fabric. So, we all need a little help with the basics.

Note

I use the terms methodology , process , and method . For this book, the meanings are as follows :

  • A methodology is a formal packaging of a set of activities, techniques, and end products. It typically has an underlying theoretical basis and an associated modeling language.

  • A method is a smaller and less-comprehensive version of a methodology. It focuses on the techniques and engineering elements, and it puts less emphasis on the sequencing of specific activities.

  • A process is like an instance of a methodology with less emphasis on techniques, more emphasis on sequencing of activities, and elements added to support the practical needs of using the methodology (such as management, metrics, and deployment).


2.1 The UML, Briefly Put

With some sensitivity to the needs of the busy reader, I'll start with a shorthand version of a definition that can be used to consider the flavors and variations that will follow.

Briefly, the UML is a formally defined, object-oriented development notation. The formal definition is complete and consistent enough to qualify the UML as a type of language, but it is a formal one (as opposed to a natural language). The object-oriented aspect is a horse-and-cart situation; in many ways, the effort to specify the UML is to provide new ways to think about object-orientation itself.

The UML encompasses the entire scope of a typical development process—from requirements to deployment planning. In addition, it offers the basis for documenting the releases of a software product and is the basis for a repository of critical knowledge about the domain.

It unifies the modeling approaches of the three key players in the area of contemporary software: Grady Booch, Jim Rumbaugh, and Ivar Jacobson (the self-described "Three Amigos" of Rational Software) and adds substantial chunks from a number of other major players who are currently active. It aims to provide a standard notation for modeling systems—in particular, software- intensive systems where an object-oriented implementation is anticipated.

It is the first successful unification of its kind, not just in object-oriented development, but within the larger arena of information technology. Its status as a standard comes from the institutional imprimatur of the Object Management Group (OMG), an industry consortium and self-appointed standards body in the area of object technology.

UML is a standard modeling language, not a standard modeling method. It is independent of programming language and development techniques and processes. As a result, it is dependent for its usefulness on how it is implemented within a methodology and/or a development process.

On the other hand, UML allows (and perhaps encourages) tool and methodology/ process vendors to step up to the plate to support it, and it competes in providing features and services that will differentiate their product offerings. The notation standards envisage tool vendors having some flexibility in implementingthe specifics; the language itself assumes that modern tool software will be available to make it work.

Whatever the variations provided by the supporting vendors, UML allows users of whatever method, process, and tool set to communicate and interchange models by using a consistent set of model elements and concepts.

Finally, UML is collaboratively developed, extensible, scalable, and flexible—and, most important, it is evolving. Nothing is carved in stone.