This chapter is from the book
This chapter is from the book
This chapter is from the book
1.5 How Should I Use This Pattern Language?
Patterns can be very beneficial to a project when used correctly. However, it's not always easy to use them in the right way, especially when you don't understand them. Here are some common misconceptions about patterns.
Patterns offer a complete methodology in and of themselves. Patterns are supplements that fill in the gaps of our knowledge with solutions to specific problems; they do not give us the complete picture. However, some people mistakenly believe that patterns tell them everything they need to know about a subject. For example, some instructors go so far as to base their object-oriented design courses on the book Design Patterns, instead of a formally defined methodology. However, these patterns offer solutions to real problems encountered in object-oriented development, and as such are more diagnostic in nature—that is, try this solution when you have that problem (Coplien 1998).
Using patterns guarantees success. In his book Patterns of Software, Richard Gabriel (1996) recounts how Christopher Alexander discovered that several architectural projects using his pattern language failed to produce the better, "living" buildings he envisioned. Instead, the resulting buildings were no different nor better than other buildings, even though the architects believed that they were radically different. Alexander was convinced "that they failed because the geometry of the buildings was not as different from the standard modern geometry as it needed to be to generate the quality" (Gabriel 1996, p. 59). In other words, in these cases, using his patterns made little if any visible difference. He felt much of the blame lay in the process. The people controlling the process—the lenders, the zoning commissioner, and others—were not using the pattern language, yet they wielded a lot of control over the project. Gabriel goes on to claim that these findings hold for software development: "The structure of the system follows the structure of the organization that put it together, and to some extent, its quality follows the nature of the process used to produce it" (Gabriel 1996, p. 59).
Patterns offer new solutions to old problems. As Linda Rising (1998, p. 10) says, "Patterns are not theoretical constructs created in an ivory tower, they are artifacts that have been discovered in more than one existing system." Patterns are essentially a documentation mechanism that captures general, tried-and-true solutions to common, recurring problems. Accordingly, patterns rarely present new ideas or leading-edge research, but rather document solutions that have proved to be effective in many different situations and environments. In fact, experienced people reading a pattern language for the first time should be struck by the feeling that they have seen some of these solutions before.
Patterns are applicable in all situations. A pattern is a solution to a problem within a context (Coplien 1996). The key word here is context, the idea being that a pattern applies only within a well-defined area. The patterns in this book present solutions that carefully balance several competing forces within the problem space. Sometimes, however, a particular force becomes more important and takes on special meaning. For example, an organization writing use cases using sensitive company information might want to hide some details, or even actors, from their customers. Or a company describing a system that relies on several well-defined and complicated business rules that everyone involved in the project needs to understand might want to include these rules in their use cases. In this case, it might be more important for the company to publish their business rules in their use cases rather than make their use cases simple and easily understood. In both instances, these organizations need to balance the forces involved, to determine the advantages of following a specific guideline. In these situations, our recommendations are not necessarily the best, and you may need to tailor them to better fit your needs or even ignore them altogether.
So don't think of this pattern language as a complete methodology for writing use cases. Instead, treat it as a set of guidelines to help you fill in the gaps in your knowledge, evaluate the quality of your use cases, or augment your particular use case writing process. Take each of our guidelines with a grain of salt. Evaluate them, and determine if they apply to your use cases and your situation. They will apply in most instances, because they describe common techniques for everyday situations. But the world won't come to an end if you decide not to follow a particular guideline if you feel you have a good reason for avoiding it. Disasters are more likely to occur if you avoid using a guideline you should clearly follow, or try to force one to work when the situation clearly indicates otherwise.