This chapter is from the book
This chapter is from the book
This chapter is from the book
1.6 What Is the Use Case Pattern Form?
Pattern aficionados like to refer to the template they use to write patterns as a "form." Like all standards, everyone seems to have their own, and of course we're no different. Each one of our patterns is presented using a template or form that is based on Christopher Alexander's form presented in A Pattern Language (Alexander 1977). This form is frequently referred to as the Alexandrian form.
Our form includes the following sections:
- The Pattern Name
- A Picture
- The Context
- The Problem Statement
- A Metaphoric Story
- The Forces Affecting the Problem
- The Solution
- Examples
Stepping through a Sample Pattern
The best illustration is the real thing. Consider the pattern UserValuedTransactions (p. 95) shown here as Figure 1.1.
)
Figure 1.1 A sample pattern
As this example shows, a pattern contains several sections, including the ones described next.
The Name
Each of our patterns begins with a name in bold text, usually a noun phrase that emphasizes a common characteristic of the solution being proposed. A good name sets the tone for the pattern and should evoke a picture of its solution in your mind. The name becomes part of our vocabulary for discussing the signs of quality that good use cases possess, or those that are missing from a poor use case. For example, a colleague can criticize a use case model because the services offered are too low level and therefore offer no UserValuedTransactions value to the users:
Jan: Look, Bob, this is not going to help me. Use cases called Display Form and Read File don't tell me anything about what this system actually does. These are not UserValuedTransactions.
Bob: So what are some UserValuedTransactions for our users?
Jan: How about Apply for Mortgage, and File Supporting Documentation?
The name of our example, UserValuedTransactions, hopefully brings an image to mind of a service that is valuable to someone, the kind of service for which someone will say, "Yes, this helps me do my job," or "This is something for which I would pay real money."
Patterns frequently refer to other patterns by name. UserValuedTransactions makes several references to SharedClearVision (p. 80), ClearCastOfCharacters (p. 90), CompleteSingleGoal (p. 118), and EverUnfoldingStory (p. 102) during the course of its discussion.
A Picture
Each pattern contains a picture that is intended to provide a visual metaphor for the pattern. While not shown in this example, the visual metaphor for UserValuedTransactions is a line of people waiting to place a bet with a bookie. Their willingness to stand in line to pay money illustrates that they believe this action to be worthwhile. The fact that other people may feel otherwise about this service does not detract from the image because any one person is likely to value only a portion of the services that a system offers. Illustrations provide a nice touch to the pattern as well as underscore the pattern's intent. (We obtained most of our photos from the Library of Congress American Memory Collection, because we feel that they provide a pleasant, unified visual theme.)
The Context
A problem doesn't occur in a vacuum. Certain conditions must hold for a problem to be consequential. This section provides the context that makes the problem relevant. It describes the boundaries that constrain the pattern and the arena in which its solution is pertinent. It also describes how this pattern relates to other patterns in the language (Alexander 1977) and specifies which, if any, patterns are prerequisites to this one.
The context for UserValuedTransactions is:
You have established a SharedClearVision (p. 80) of the project and have defined a ClearCastOfCharacters (p. 90) who need services from the system.
This statement tells us that we need to know who the actors are before we can find out what they need the system to do for them. It is pointless to start describing the services that a system is supposed to provide if we don't know who needs them. Before you can identify any UserValuedTransactions, you must understand the project's SharedClearVision and know who will be using the system—that is, its ClearCastOfCharacters. If you do not know these, then you cannot possibly determine which services are valuable.
The Problem Statement
Each of our patterns describes a problem that people often experience when writing use cases. Our problem statements consist of one or two sentences in bold type that describe what can happen when a use case fails to meet a certain standard. The statement also reflects the risks associated with not following that standard.
The problem statement for UserValuedTransactions is expressed this way:
A system is deficient if it cannot deliver services that are valuable to its users and it does not support the goals and objectives specified by the system vision.
This problem statement informs you that you need to write use cases that meet the user's real needs if you wish to sell them your system. While this assertion appears to state the obvious, we shall soon see that several factors exist that cause people to write use cases that fail to address the user's need.
We could have written the problem statement as "How do you find the fundamental services a system offers?" except that expressing the problem as a question does not really convey the problem's consequences. It does not tell us why the pattern is significant, nor does it describe the consequences of ignoring it. Therefore, we write our problem statements to describe what would happen if your use case model did not follow this guideline.
The Metaphoric Story
Some patterns describe simple problems, while others address complex, hard-to-understand issues. Yet simple and complex are relative terms that depend on the reader's experience. We include either a metaphoric story or a lightweight case study to make the pattern easier to understand and to provide you with an intuitive feel for the problem and its solution. These stories usually have nothing to do with use cases, or even software development, but serve to illustrate the pattern in a practical, easy-to-understand manner. Although analogies are not normally part of the Alexandrian form, we believe they provide a good synopsis of the pattern's intent.
In the example in Figure 1.1, the metaphoric story describes a company that developed a product that very few customers found valuable. It emphasizes the problem statement by demonstrating what can happen to a product when its intended users don't find it to be particularly useful.
The Forces Affecting the Problem
This section outlines the various factors that affect the problem, and the trade-offs between them that complicate and constrain the solution. Pattern writers refer to these trade-offs as "forces" because they will push or pull you in different and sometimes competing directions as you attempt to solve a problem. In our forces section, we describe the important trade-offs that you as the use case writer must resolve for the specific situation that you are facing. Each force is written in a specific format. The first statement, written in italics, summarizes the force. The remainder of the paragraph(s) describes the force and its trade-offs in more detail.
So what are the forces that we are trying to balance when finding UserValuedTransactions (p. 95)? Briefly, they are:
A set of use cases should capture the fundamental value-added services the users and stakeholders need from the system.
It is relatively easy to identify low-level transactions, but it can be difficult to identify useful services.
Use cases need to be relatively stable because they form "anchor points" for the rest of the product development process.
Readers want to see easily how the system will meet its goals (see SharedClearVision).
People tend to work at a level that is either too high or too low.
The first force in this example states the obvious fact that we want to know what basic services the system offers to its users. Yet this information is important because it helps us grapple with the next force, which if not countered, can lead to us writing ridiculously small use cases. Without other guidance, people will always take the path of least resistance, and it is usually very easy to describe low-level system services.
At first glance it might seem absurd that someone would intentionally write use cases that describe how a system offers useless services to its users (perhaps the antithesis of a use case is a useless case). But this is where the forces come into play. These are the competing trade-offs that complicate the problem, which if taken too far can lead to suboptimal solutions. The purpose of a pattern is to provide instructions to bring these forces into an optimal balance for your particular situation. The forces are the things that if taken too far will make us do something absurd, like writing use cases that are useless to the users.
Why do we go to these lengths to explain the problem in this manner? Because we want you to grasp the richness of the problem and gain an in-depth understanding of the trade-offs that push most people to the solution. Few problems have a one-size-fits-all solution, and the better your understanding of the problem's trade-offs, the better you can adapt the solution to your specific situation, or determine that the solution is not appropriate for your needs.
The Solution
This section of the pattern presents a common, well-tried solution that balances the competing forces and reflects the characteristics of well-written use cases. The essence of the solution is written in bold text and follows a "Therefore" in the pattern. The bold text summarizes the solution that attempts to bring the forces into balance. A discussion follows the solution, explaining it further and identifying other patterns that complete this one.
The essential solution for our UserValuedTransactions pattern is this:
Therefore:
Identify the valuable services that the system delivers to the actors to satisfy their business purposes.
This solution aims to solve the problem within the constraints imposed by the forces. "Identify the valuable services . . ." limits the goal set to use cases that benefit the users instead of smaller, implementation-oriented use cases that are not particularly valuable to the user. ". . . that the system delivers to the actors to satisfy their business purposes" implies that we should focus on the actors and define transactions that are meaningful to them, rather than system or implementation details.
The solution may often seem familiar, or even obvious, but that is what patterns are all about. A pattern should not be some grand revelation but rather a piece of advice that your grandmother could have told you (assuming Grandma wrote use cases, but then, hey, Dilbert's mom is apparently a telecommunications engineer). Our patterns capture the tried and true experience of those who have had success writing use cases. Our contribution is that we have given a name to that knowledge, and packaged it with other like pieces of knowledge and experience.
The Examples
Each pattern has one or more examples demonstrating either the benefit of implementing the solution recommended by the pattern or the consequences of what happens when you don't. We based many of these examples on live projects, but we sanitized and simplified many of them because real use cases are often long and can be quite complicated, especially the ones demonstrating bad practices. Many of our examples follow a group of developers from a national travel agency as they write some use cases for their new product, the Wings Over the World travel reservation system. We based these examples on our experiences and many of them are composites of real people, events, conversations, and use cases.