In-Depth

UML Hits the Street

• By Jack Vaughan
• September 1, 2001

When people initially get down to work with the Unified Modeling Language (UML), it is typically the first time they take up the practice of use cases.

These are an important element of UML, intended to help gather functional requirements, as well as to provide a means of communication among development team members.

But use cases are not without controversy. And for long-time industry observers, the controversy may be somewhat familiar.

Many of the brickbats loosed years ago upon Case tools and structural analysis are now aimed at UML and use cases. Use cases lead to "analysis paralysis." Use cases are "shelfware." These are just some of the criticisms unloaded by influential software consultants and authors, many of whom are counted among the ranks of eXtreme Programming (XP) advocates.

At times, the XP squad, although it includes a number of individuals who see some merit in use cases, seems to echo the arguments of Rapid Application Development (RAD) advocates of the client/server era. These earlier RAD advocates challenged development orthodoxy of the day, which centered on "waterfall" processes. The RAD folk also took some arrows for creating a few allegedly non-scalable and non-repeatable systems.

On one level, the battle—and "battle" is probably too powerful a word—between UML and XP is new evidence of the timeless divide between designers who want just a little more time to do a little more analysis of system needs, and developers who just want to start coding.

This situation is natural. UML had something of a honeymoon. It arose in the late 1990s out of the combined efforts of notable software methodologists Grady Booch, James Rumbaugh and Ivar Jacobson, who came to work at Rational Software Corp. and who came to be known in a series of road shows as "The Three Amigos." The battle of the object methodologies was effectively ended as UML standardization responsibility was eventually ceded to the Object Management Group (OMG). Now, as UML is increasingly used, developers have had some mixed experiences, so there is a higher likelihood that UML will take a few shots.

While the recent UML World 2001 conference held in New York City featured sessions that considered new UML extensions and studied best practices in UML use case gathering, the conference was just as notable for a use case panel at which UML and XP proponents traded verbal barbs.

In technology, such battles are common. But if you are getting ready to sit down to a slug fest between UML and XP, I'm sorry—this is not that article. Rather than focus on the guerre du jour, this effort will instead uncover some user experiences with use cases. This will hopefully provide a useful backdrop for development managers trying to visualize their next steps in design and development.

Capturing behaviors
UML use cases can play an important role in harvesting system requirements, said Ellen Gottesdiener, president, EBG Consulting Inc., Carmel, Ind. "They can be good at capturing behavioral requirements where there is human interaction—from a black box point of view," she noted.

"But there are good things and bad things [about use cases] and they can easily become what people have called 'abuse cases,'" said Gottesdiener.

"One of the problems you can get is if you try to put everything in the use cases. People try to throw in GUI stuff—that's a very common problem. They describe buttons and icons, which should be removed from use cases," she said. Moreover, she added, teams should not try to throw business rules in with UML use cases. For some, this is tempting. Similar problems occur when teams try to represent a lot of data via use cases, said Gottesdiener. She and others point out that there are aspects of use cases that are handy even if a designer is taking the XP route.

One must to find out what users need. And use cases can provide a springboard for test generation, which is a requirement in XP development. Some documentation may also be useful, although at this point any rivers of agreement between UML and XP tend to part. Documentation is a hot button for XP folk.

Surprisingly, perhaps, use cases are similar in some ways to traditional requirements gathering, as well as to the scenarios used by some developers or the "stories" required by formal XP design principles. But some among the XP crew will tend to fault UML use cases as excessive. "We don't need no stinkin' documentation," they might say, paraphrasing the bandits in "The Treasure of the Sierra Madre."

A common XP assertion is that good code is self-documenting. And the ideal XP story—again, for some—would fit on a common index card. Even then, there are arguments in online XP discussion threads about whether or not the index cards should be discarded when the project is done.

Users on use cases
Broadly speaking, use cases specify interactions that a customer (or in use case parlance, an "actor") may have with a system or class. Sequences of interactions may also be described. They are best gathered in bull sessions not unlike the sessions traditionally used to assemble user and system requirements. A word processor can be an adequate tool, although more elaborate tools are available.

Today, the experience of some architects, business analysts and systems analysts, as well as many programmers, is that use cases are simple in theory but complex in implementation.

"A good use case describes a business transaction that provides some meaningful value to the actor," said Gary Evans, consultant, instructor and evangelist at Evanetics, Columbia, S.C.

While Evans sees value in the effective use of use cases, he also sees problems. "In practice, use cases have become painful. They are difficult to develop and control," he said.

Among the common pitfalls, Evans, like EBG Consulting's Gottesdiener, counts use case overuse. Teams may create too many individual use cases, said Evans. And this is not just a novice's mistake. "Even experienced case writers don't know what to leave out," Evans told a packed room of attendees at June's UML World 2001 conference.

"You can have too many use cases, or too few use cases doing too much," Evans warned. This problem arises because UML does not tell you how to create use cases, said both Evans and Gottesdiener.

Like others, Evans said there are aspects of UML that superficially seem similar to older methods. If the designer does not learn that use cases are, for example, different from conventional requirements, problems may ensue. Evans said UML use cases do not capture all or even most systems requirements, yet designers familiar with requirements-based systems analysis may approach use cases as a means of gathering requirements. "Use cases are a portion of how you capture requirements," Evans noted.

But you do not have to—and, in fact, should not try to—put all requirements in use cases, Evans said. To depict this fallacy, he summons an adage long referenced by engineers: "Give someone a hammer and every problem looks like a nail." All requirements should not look like use cases.

You must understand the use case's purpose in order to succeed, urged Evans. And use cases can best serve the design team as "a vehicle for obtaining consensus on goals," he said.

CRUD goes to school
From experience garnered in taking on parts of projects that had seemingly stumbled on use cases, Evans and his colleague and UML World co-presenter William Nazzaro of Nazzaro & Associates Inc., Collegeville, Pa., have identified "use case killers" of which would-be UMLers should be aware. These use case killers are: CRUD-based use case partitioning; design by use case; actor misclassification; exploiting use cases to obtain all requirements; and use case normalization.

Here we take a brief look at one of these killers, CRUD-based partitioning.

CRUD, or Create-Retrieve-Update-Delete, is a database-centric view of design that does not translate well into UML. "A lot of people did relational work in school," said Nazzaro, and thus feel comfortable with CRUD techniques. Sometimes such methods seem like a quick way to get the attention of the eventual system developer.

"We usually focus on immediate value to [the] developer; people are naturally ready to get down to work," said Nazzaro. But some patience is in order. "The immediate focus should be on the [use case] actor, rather than on the developer," he said.

CRUD methods have appeal because they are closely related to means of relational modeling. But with CRUD, the focus on transactions can become an issue. "It seemed very logical when I did it," said Nazzaro, who once took such a tack, but has since sworn off this approach, which can produce negative results. In the UML setting, CRUD can lead to a tendency to "take a business process and carve it up into all its atomic elements," he said.

Too much, too soon?
UML is not just a specification, it is an industry replete with many tools, books and experts. And, from the early days, experts have envisioned elements that might be added to it.

But even some of the individuals suggesting extensions to UML admit that it is already large.

Doug Rosenberg, president, Iconix Software Engineering Inc., Santa Monica, Calif., sees some need for extending UML. As part of the Iconix design process, Rosenberg and his associates rely on robust analysis, an aspect of Ivar Jacobson's object design practices that did not come over to the UML spec. Yet Rosenberg admits one of the problems with UML is that "it's too big."

Others concur.

"UML is great, but big," said Hedley Apperly, director of marketing at Aonix, San Diego. Apperly came to Aonix recently when the company purchased the Select modeling tools family from Princeton Softech. "People will take the bits [of UML] that are useful to the business organization," said Apperly.

"If you feel compelled to use each feature of UML every time, that's too much," said Michael Burnett, CTO at Blueprint Technologies, Falls Church, Va. However, he added that each feature may be useful to somebody.

For successful projects, said Iconix Software Engineering's Rosenberg, teams must effectively move from use cases, which can be somewhat fuzzy, through robustness analysis, to more detailed UML sequence diagrams. Rosenberg and colleague Kendall Scott offer tips based on several years of UML experience in Applying Use Case Driven Object Modeling with UML (Boston: Addison–Wesley, 2001).

Rosenberg is adamant that in distributed computing, you have to design. "If your design is invisible until you write the code, it's too late," he said.

Don Clayton, president, Intertech Consulting Inc., Houston, agrees that the move from two-tier client/server computing to "four- and five-tier" distributed architectures tends to require more up-front modeling. "I think the appropriate point to use the use cases is when you are trying to scope out the system and figure out the high-level processes of it," said Clayton.

Clayton uses Sybase's PowerDesigner tool for some modeling. He estimated that Sybase has "effectively added UML support to what was [initially] an IE [information engineering] tool for DBAs" in recent revisions of the product. "It's good at reconciling object models with RDB designs," said Clayton.

Products help propel UML UML designs can be created using a word processor, but tools abound for teams looking to interlink their analysis efforts with development software. In its infancy, the Unified Modeling Language (UML) was solely associated with Rational Software, workplace of Booch, Rumbaugh and Jacobson—the "Three Amigos" who formulated the language—and was most visibly supported in Rational Rose. In recent years, UML has quickly become an industry standard, supported by a wide variety of tools vendors. Many of these vendors' traditional modeling strengths may lie outside the realm of systems modeling epitomized by UML. Some of these gained their UML tools via acquisition. However these vendors have gotten into the UML game, recent innovations are contributing to make the UML area a far-from-boring showground. New offerings include releases from Embarcadero Technologies Inc., San Francisco; Popkin Software, New York; and Sybase Inc., Emeryville, Calif. Embarcadero recently introduced Describe, a UML design and development tool that represents the next-generation version of software more widely known as GDPro. GDPro joined the Embarcadero camp when Embarcadero acquired Advanced Software. In this release, the focus is on improving interaction between the UML design tool and popular Java IDEs. Describe automatically keeps design artifacts synchronized with the actual code, and it allows simultaneous viewing and manipulation of both the class models and the underlying code. It also provides a bridge to database modeling within Embarcadero's ER/Studio database design tool. At the UML World 2001 conference, Popkin Software announced its System Architect modeling tool. Jan Popkin, founder and CEO, said this version includes richer semantic and notational support for UML 1.4 and a new package-based interface. The newest release also supports UML customizations and extensions. The UML Web Application Extensions (WAE) profile is also supported. Also at UML World, Sybase shared information on Neptune, a beta preview of an upcoming of version of PowerDesigner. While still supporting non-UML modeling, Neptune offers UML activity diagram and component diagram support for developers and designers. Moreover, it further extends support for Enterprise JavaBean definition, including persistence layer generation for popular application servers. Looking ahead, a recently announced Reference Project for the Rational Developer Network should lead to automatic requirements generation and test-case generation from use cases modeled in Rational Rose. Iconix Software Engineering, Santa Monica, Calif., is pursuing this project jointly with Rational Software. —Jack Vaughan

Actors play roles
The troublesome issues of UML use case implementation can sometimes start to obscure the benefits of the modeling language. In some ways, UML is an effort to codify best practices as uncovered through the history of software development.

Marvin Yonke, staff software engineer, Microsoft Great Plains Business Solutions, Fargo, N.D., feels there has always been a notion of something like a use case that drives development work. "Nobody called them use cases in former days. They called them requirements," he said. "But use cases are somewhat different—they are behavioral requirements."

Yonke is responsible for next-generation tools and process development at Microsoft Great Plains. By way of background, he worked with Case tools and Booch methodologies in the early 1990s prior to the advent of UML, and found them "kind of clumsy." He came to Great Plains in 1999, and began looking at tools and methodologies.

Today, Yonke works with the Rational Rose modeling tool. "It does a good job of providing UML syntax and diagramming support," he said.

How does he depict the use of use cases? Use cases are useful because they drive interaction between designers and users, said Yonke. They describe the "functionality that we expect from a system," he continued.

"That makes up most of what a use case is," said Yonke, although he admonished, "use cases always involve actors, typically representing the requestor of the functionality provided by the use case."

Like other observers, Yonke chides that use cases' similarity to traditional requirement cases, and the pressing attraction to pack technical requirements into use cases, can cause trouble.

"Use cases can be difficult unless you can think in an object-oriented manner. With use cases, for example, you are not just thinking in terms of a UI," said Yonke. This may be the essence of the transition some teams have to make as they move to use case-driven analysis and design.

"If you think in terms of the UI, you tend to get very detailed," noted Yonke. There are other ways to spec what layers are under the UI, he said, adding that the designer should spec an environment, not in terms of the interface, but in terms of the expected behavior of the system.

The important thing is for teams to discuss features of the interface that tell the user to do something, note Iconix Software Engineering's Rosenberg and Scott. They discuss the top 10 use case errors in their aforementioned book (see the sidebar "Top 10 use case modeling errors").

Top 10 use case modeling errors 10. Write functional requirements instead of usage scenario text. 9. Describe attributes and methods rather than usage. 8. Write the use cases too tersely. 7. Divorce yourself completely from the user interface. 6. Avoid explicit names for your boundary objects. 5. Write using a perspective other than the user's, in passive voice. 4. Describe only user interactions; ignore system responses. 3. Omit text for alternative courses of action. 2. Focus on something other than what's "inside" a use case, such as how you get there or what happens afterward. 1. Spend a month deciding whether to use includes or extends. Source: Applying Use Case Driven Object Modeling with UML by Doug Rosenberg and Kendall Scott, Boston: Addison–Wesley, 2001.

This is only a test
Rational and other vendors continue to forge tools that link UML design to "back-end" aspects of the development life cycle, especially where software testing is concerned. "UML use cases are especially important for testing," said Yonke at Microsoft Great Plains. "Use cases can be used for purposes of validating what the software is going to do. The use case is the initial point of reference for doing the tests."

Can test cases be derived from use cases? Definitely, said David Olvey, senior consultant at Houston-based system integrator Conchango. Yet he points to exceptions. Writing test cases against non-functional requirements is not a good idea, he suggested.

"I have found that non-functional requirements tend to be communicated better to testing groups as a story or narrative," he said, taking a term from the XP programmer community's book.

Flexibility in using use cases is important to Olvey. He has worked with UML and use cases for the past three years. In the last year, acting as business analyst and project manager, he has mostly been required to work on largely enterprise application integration projects using a variety of technologies.

"The one thing I have learned is that UML compliance must always be the goal, but it rarely becomes a reality," said Olvey, whose experience with integration projects led him to conclude, "Use cases are best served when the actors are human."

Olvey describes the transition from business requirements to technical requirements as probably the most troublesome pitfall in UML-oriented design.

"It's not that the use cases are a poor representation of the actor's interaction with business events and objects," he said, "it is more an issue with the process of decomposition." It is important to be mindful of the level of granularity in use cases that are employed to communicate with programmers.

"Programmers want to code, and analysts want to diagram," remarked Olvey. "Ideally, you want the outputs of design to be the inputs of development."

Programmers like to mock the generalizations, he added. They look for something specific with which they can work. For example: a time zone, a type of currency, ANSI code or Unicode, or date/time vs. data references.

In fact, Olvey, a user of TogetherSoft's modeling automation tools, said TogetherSoft has made progress toward shrinking the gap between business requirements and technical requirements.

In any case, said Olvey, "If use cases are to be used as a method of documenting requirements, there is a level of decomposition that must be achieved by the product manager, business analyst or designer that initiates a smooth transition into further decomposition by the programmer."

Successful designs must employ a steady process, said Yonke at Microsoft Great Plains. "One should iterate through the analysis and design process, selecting specific use cases to drive the focus of work for each pass through the process, adding more functionality through each iteration."

Teams should "keep circling up to the highest level use case, or cases, to ensure the work is complete for each iteration," said Yonke.

"Beside use cases, you need to look at [UML] sequence diagrams, since they add the interactions between actors and objects, providing a basis for test," he added.

The twain meet
Steve Ropa, a development manager at Lucent Technology's Denver software development center, is among those who think good aspects of UML can be combined with good aspects of XP.

"I'm leading a double life. I'm moving to XP, but I've been doing up-front design for years. Now, I'm converting my office to eXtreme Programming," he said.

Ropa leads teams that work quickly to write software for billing and customer software solutions. This means writing drivers, integrating diverse systems and basically "bridging gaps."

"We're writing complementary software that is custom," he said. The average project time spans three to five weeks, said Ropa, who states he has been a "Booch kind of guy" since 1994, and has used use cases for about four years.

"If there is anything truly misunderstood, it is use cases," said Ropa. In an early design, he admitted he used too many use cases, and further deemed they were not always true use cases.

He echoes some of the laments of XP enthusiasts who tire of arcane aspects of UML use cases, noting he has been in meetings where people "argued for two hours about the format" for use cases. As far as Ropa is concerned, use cases are meant to describe what the system is going to accomplish. Their usefulness is not as a model, but as a means of communication. "In XP, you don't model up-front," said Ropa. "Any modeling you have is used as a communication tool."

Yet the use case has a place in XP settings. "It fits in beautifully in XP," said Ropa. "UML is an elegant description language for building systems.

"There's a loose correlation between UML use cases and XP stories," he added. "In most cases, a use case ends up not being as lengthy as the [UML] books may teach, and ends up like an XP user story."

As part of his development process, Ropa uses Embarcadero Technologies' Describe UML tool. Describe, which came to Embarcadero as part of its acquisition of Advanced Software, was formerly known as GDPro. Ropa sometimes uses the reverse engineering capabilities of Describe to uncover object problems. "The steps in XP are short. You do this once a day or every few hours, which is why you need a fast tool," he said.

Call for authors
Who should write the use cases? That is an important issue to consider, and mistakes here may be at the root of some failed development efforts. Most UML experts see use case writing as the province of the analyst working with a system's eventual users. "Programmers should not write use cases. Absolutely not," said Ropa.

Others agree, commenting that programmers are eager to wrestle with technical implementation issues. Tackling these issues in the context of use case creation can skew the project, they say. This can become a niggling point.

But while Ropa repeated that programmers should not write use cases, he added, "programmers may be all you have."

The practice of eXtreme Programming (see "'Extreme' method simplifies development puzzle," ADT, July 2000, p. 20) as envisioned by its founders, is pretty precise in describing a number of elements needed to proceed.

"It's actually a very disciplined approach," said Ropa."The biggest danger in XP is to take just some of the pieces. Then it becomes hacking."

EBG Consulting's Gottesdiener agrees that there are similarities between the XP story and a "light type of use case." The important thing, she said, is to remember that use cases are to be created in collaboration with customers.

"But you can pick the level of precision you want to define," she said. "You don't have to have a low level of precision.

"Because they are so hot, people think they are the catchall solution for requirements," added Gottesdiener. But for some problem domains, for example a data warehouse or a query-intensive system, she continued, use cases can be "a waste of time."

Gottesdiener still places importance on modeling. You must always multi-model, she said, mentioning business rules, data schema, prototypes and exceptions as just some examples of worthwhile modeling that is outside the purview of UML.

"Use cases should never be used alone," said Gottesdiener. "You should use each model to do what it does well."

The modeling must serve the purpose, added Conchango's Olvey, otherwise it is merely "a time-consuming formality that keeps designers busy and programmers waiting to miss deadlines."

UML has come a long way in creating a uniform visual of system descriptors, he indicated, but UML alone will never cover every situation. Said Olvey, "Finding an effective mix of modeling types is necessary."

Over time, designers will need to continue to find new ways to work with use cases. Uncovering successful strategies is one of the goals of a workshop planned later this year by the OMG. UML for Enterprise Applications, set by the OMG for December in San Francisco, said Fred Waskiewicz, director of standards, is an effort to "have a meeting of the minds and share experiences." Also considered will be UML profiles specific for application technologies such as CORBA, EJB and XML, as well as industry-specific UML extensions, he said.