2.4 Unification: The Methods Wars Are Over

2.4 Unification: The Methods Wars Are Over

In a widely read column in the April 1998 issue of Object magazine, Ivar Jacobson declared that "the methods war is over" after a period of confusion and uncertainty that accompanied the transition from a world dominated by structured approaches to one in which the object paradigm became champion (1998, 72).

Ivar was actually repeating in a (hopefully) tongue-in-cheek fashion a comment that Booch and Rumbaugh made publicly a couple of years earlier one that prompted sizeable dissent in the object-oriented community.

The earlier war cry predated Jacobson's conversion to Rational, and so it was definitely premature because Jacobson's Objectory had substantial mindshare even then. However, the methods being replaced, aided, and abetted by a unified approach to modeling aren't just the object-oriented ones. Rather, as Jacobson explained it in the article, "all the different methods in the software industry are now moving to one modeling language: UML" (1998, 72).

Although Jacobson's observation may have been premature (and certainly self-serving), it points to the most significant meaning behind the UML: It unifies everything under one flag. The UML Specification makes it clear that:

[T]he UML is the proper successor to the object modeling languages of three previously leading object-oriented methods (Booch, OMT, and OOSE). The UML is the union of these modeling languages and more (Object Management Group 1999, xi)

Beyond the ideal of convergence, unified has other levels and shades of meaning, all of which contribute to a better understanding of the purpose of the UML.

With the UML, all of the hidden non-engineering purposes of modeling are brought to the forefront and made connectable, consistent, and applicable. UML models can be used to help conceptualize the context for an application. They can organize the requirements and package the work. They can, of course, embody the design. After that, they can provide the basis for generating usable results and the means to package the end result for deployment. Software architects and managers can use the same set of notations and conventions as designers and programmers to suit their purposes, as well as the purposes of engineering.

So, the UML helps to unify the practices of developing, planning, and managing software development by making modeling a pertinent part of all these activities.

2.4.1 Best Practices: In the Eye of the Beholder

Essentially, the UML brings together the best practices of an increasingly mature software development community. In a phrase used over and over again in books and articles about the UML, the introduction to the specification claims that it "represents the convergence of best practices in the object-technology industry" (Object Management Group 1999, xi).

Of course, as with all best practices, many are most notably so in the eyes of the beholder. They are beliefs rather than empirically substantiated reality and meant to be taken with a grain of salt. And, as with beliefs of any kind, they are subject to the usual "religious" squabbles and/or interpretations.

The idea of best practices emerged in the manufacturing world. There, it is tightly coupled to benchmarking processes and measured performance. As an idea, it was adopted in software development with none of the rigor of manufacturing management. There is little benchmarking (more in Europe than North America) and, given the churn of technologies and processes within software development, there is little likelihood of any meaningful benchmarks for awhile. In IT, best practices is an inherited management idea with many meanings.

Shoshanna Zuboff described the evolution of management ideas in her book, In the Age of the Smart Machine. She uses a geological metaphor that adds some useful nuances to Kuhn's notions of the way a paradigm shift works. Zuboff suggests that "each period leaves a layer of sedimented beliefs," like the eons of previous geologies that can be seen in layered cliff walls (1988, 233). A paradigm shift is not a complete change. It encapsulates the beliefs of previous generations, but then moves on.

The evolution of software engineering ideas can be viewed the same way. The UML brings with it a great deal of baggage from earlier periods in software development (in particular, Structured Analysis and Design) and from the beginnings of object-oriented analysis and design. Not all of this baggage is excess baggage.

The gurus of previous modeling approaches articulated a number of sound, valuable insights into their work. The best results have a resonance that transcends their packaging, becoming best practices in the informal way that the software community thinks of such things.

I attempted to capture as many of them as possible in the patterns themselves. In some cases, because these insights have been translated directly into the UML, the patterns are specifically about using the UML. In other cases, I use patterns to show how these insights shape the practice of modeling in general, and how they work in the UML.

2.4.2 An Independent-Minded Modeling Language

The miracle of the UML is that it unifies without being tied to a prescriptive methodology or process. This is the second significant characteristic of the UML: its independence of process, programming language, and technique.

By being process-independent, it is unique among modeling languages. All of the structured modeling techniques and object-oriented modeling languages that existed previously were extensions of a methodology or process.

Originally, the creators of UML wanted to unify their different object-oriented development methods into one process. Initial discussions showed the task to be more difficult than they imagined. Booch, Rumbaugh, and Jacobson determined that merging their notations was the best thing to do first. One of the insights that the creators of the UML had was the notion that a one-size-fits-all process wasn't possible or even desirable. They intentionally left the choice of process up to the individual users of UML. Therefore, the UML is deliberately process-independent.

Although there is now a Unified Process available from Rational that exemplifies the type of process that maps well to the UML, it does not have to be the process that you use. The process chosen for a particular development project is determined by a variety of factors such as project size, organizational standards, tool support, architectural goals, and so on. It isn't likely that a single process can satisfy the requirements of all possible variations of these factors, and there is any number of processes available to a developer that all use the UML as their modeling language. Examples include Objects, Components and Frameworks with UML: The Catalysis Approach from Desmond D'Souza and Alan Wills (1998), with its emphasis on component-based development and the offerings of Sally Shlaer and Ward Mellor, with their slant toward real-time systems (1999).

The UML is also programming-language-independent, which has a number of dimensions. On the one hand, the UML is not unnecessarily biased toward any implementation via a particular programming language, so it can reflect the generic needs of programmers for a standard way of communicating the blueprint for a system.

On the other hand, a number of the constructs in the UML do not map to any programming language. They are modeling abstractions that always need translation.

On top of this, although it is language-independent, the UML does reflect the underlying conceptual framework of object-orientation. As has been acknowledged in some small ways already, it will need to be reworked to accommodate more recent approaches, such as component-based development. But, to its credit, the UML has already accommodated patterns and frameworks during its brief evolution.

Finally, the UML is technique-independent. For example, a process that calls for use cases as the primary vehicle for communicating functional requirements may describe techniques. However, the streetwise practitioner recognizes that prescribed techniques work well in some circumstances and not in others. In situations where they don't, the end result is what's important. The UML does not tie artifacts to techniques any more than methods or processes.

The agile modeler will appreciate the UML's independence. Process, language, and technique neutrality make it a relatively easy task for designs to be communicated across the boundaries of projects, environments, and tools. Instead of notational factions and models separated by walls of incompatibility, the UML provides a generalized language for modeling that eliminates artificial boundaries and permits the free flow of models and design information in a way that wasn't previously possible.



A UML Pattern Language
A UML Pattern Language (Software Engineering)
ISBN: 157870118X
EAN: 2147483647
Year: 2005
Pages: 100
Authors: Paul Evitts

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net