Applying UML and Patterns: An Introduction to ObjectOriented Analysis and Design and Iterative Development, Third Edition [Electronic resources]

Introduction

Use cases can be related to each other. For example, a subfunction use case such as

Handle Credit Payment may be part of several regular use cases, such as

Process Sale and

Process Rental . Organizing use cases into relationships has no impact on the behavior or requirements of the system. Rather, it is simply an organization mechanism to (ideally) improve communication and comprehension of the use cases, reduce duplication of text, and improve management of the use case documents.

[View full size image]

Guideline: Avoid Agonizing Over Use Case Relationships

In some organizations working with use cases, way too much unproductive time is spent debating how to relate use cases in a use case diagram, rather than the important use case work:

writing text . It actually a reflects a deeper problem in analysis-oriented work on software projects: Too much time wasted on low-value analysis and modeling. It's part of the larger problem of waterfall thinking rather than iterative and evolutionary thinking; if you think you have to "get it right" at the start, everything becomes bogged down in analysis paralysis.

Consequently, although this chapter discusses relating use cases, the subject and its effort should be put in perspective: It has some value, but the important work is writing use case text. Specifying the requirements is done by writing text, not by organizing use casesan optional step to possibly improve their comprehension or reduce duplication. If a team starts off use-case modeling by spending hours (or worse, days) discussing a use case diagram and use case relationships ("Should that be an

include or an

extend relationship? Should we

specialize this use case?"), rather than quickly focusing on writing the key use case text, relative effort was misplaced.

Plus, in the UP and other iterative methods, the organization of use cases into relationships can iteratively evolve in small steps over the elaboration phase; it is not helpful to attempt a waterfall-like effort of fully defining and refining a complete use case diagram and set of relationships in one step near the start of a project.