next up previous
Next: Some example use case Up: Essential Use Cases and Previous: Example

Patterns of Use Cases

 

While writing and designing software using essential use cases, we noticed that particular sequences of user intentions and system responsibilities reoccurred, both within single systems, and, more importantly across systems as different as network help systems, supermarket stocktaking, and micro-controller programming environments. Importantly we did not write the use case models for the majority of these systems ourselves.

As we investigated these recurring sequences in use case bodies, we realized that they represented solutions to particular problems in use case modeling: the sequences were common because they provided solutions to common problems in modeling the interfaces of systems to the actors surrounding them, that is, to the world outside. Following other patterns work [10, 12], we then identified (or ``mined'' in patterns terminology) a series of patterns for essential use cases [6].

To move from descriptions of repeating use case sequences to patterns, we also analyzed the forces acting in the use case, that is, the important considerations impacting on the use case [1]. For essential use case patterns, the forces capture characteristics of the interaction between actor and system: issues of initiative, information flow, and usability, such as preferring selection (from menus) over memory (for obscure command names), and promoting safety by requiring confirmation of irreversible actions. Each pattern gives positive and negative consequences of in terms of some of these forces.

These essential use case patterns are philosophically closer to Analysis Patterns [10] than they are to Design Patterns [12] or other user interface patterns [13, 7]. Like Analysis Patterns, these patterns describe analysis artifacts, rather that object-oriented designs or user interface designs for completed systems. Essential use case patterns describe patterns in essential use cases -- that is, characteristic dialogues of user intention and system responsibility -- while Analysis Patterns describe patterns in business domain models.