This part of the book presents a collection of use-case patterns proven useful when developing maintainable and reusable use-case models. These patterns focus on designs and techniques used in high-quality models, and not on how to model specific usages. Each chapter in this part presents and discusses a group of related patterns.
All chapters in this part are organized in the same way:
Name of group—. A descriptive name of the patterns in a few words
Intent—. Captures what the intent is of applying one of these patterns
Characteristics—. States whether the patterns are simple or complex, common or infrequent
Keywords—. A list of keywords characterizing the patterns
For each pattern
Name—. A descriptive name of the pattern
Model—. A use-case model of the pattern
Description—. A description of the pattern model
Applicability—. States when the pattern should be used
Type—. States whether the pattern affects the structure of the use-case model or the description of a use case
Discussion—. A comprehensive discussion on the patterns in this chapter
Example—. An example where one or more of the patterns is applied, including use-case descriptions
Analysis model—. A platform-independent class model providing a realization of the use cases in the pattern models
The chapters containing the use-case patterns are sorted alphabetically within this part. For each chapter, we list its contained patterns together with their intent.
Chapter 16 Business Rules: Extract information originating from policies, rules, and regulations of the business from the description of the flow and describe this information as a collection of business rules referenced from the use-case descriptions.
Business Rules: Static Definition
Business Rules: Dynamic Modification
Chapter 17 Commonality: Extract a subsequence of actions that appear in multiple places in use case flows and express it separately.
Commonality: Reuse
Commonality: Addition
Commonality: Specialization
Commonality: Internal Reuse
Chapter 18 Component Hierarchy: Provide a mapping from top-level use cases describing the system behavior as a whole down to leaf elements in a containment hierarchy realizing the behavior.
Component Hierarchy: Black-Box with Use Cases
Component Hierarchy: Black-Box with Operations
Component Hierarchy: White-Box
Chapter 19 Concrete Extension or Inclusion: Model the same flow both as part of one use case and as a separate, complete use case of its own.
Concrete Extension or Inclusion: Extension
Concrete Extension or Inclusion: Inclusion
Chapter 20 CRUD: Merge short, simple use cases, such as Creating, Reading, Updating, and Deleting pieces of information, into a single use case forming a conceptual unit.
CRUD: Complete
CRUD: Partial
Chapter 21 Large Use Case: Structure a use case comprising a large number of actions. There are two “dimensions” along which a use case may be large: It may either be “long,” that is, consist of a very long sequence of actions, or it may be “fat,” that is, include many different flows.
Large Use Case: Long Sequence
Large Use Case: Multiple Paths
Chapter 22. Layered System: Structure the use-case model so that each use case is defined within one layer and use relationships between the use cases in different layers to allow use-case instances to span multiple layers.
Layered System: Reuse
Layered System: Addition
Layered System: Specialization
Layered System: Embedded
Chapter 23 Multiple Actors: Capture commonalities between actors while keeping separate roles apart.
Multiple Actors: Distinct Roles
Multiple Actors: Common Role
Chapter 24 Optional Service: Separate mandatory parts of the use cases from optional parts that can be ordered and delivered separately.
Optional Service: Addition
Optional Service: Specialization
Optional Service: Independent
Chapter 25 Orthogonal Views: Provide different views of the flows of a system that are perceived differently by different stakeholders.
Orthogonal Views: Specialization
Orthogonal Views: Description
Chapter 26 Use-Case Sequence: Express the temporal order between a collection of use cases that must only be invoked in a specific order, even though the use cases are functionally unrelated to each other.
Use-Case Sequence