Forming Patterns by Abstracting


The requirements pattern we have been discussing is the result of analyzing many business eventsquite often from very different organizationsthat deal with the subject of a customer wanting to buy a product. We derived the pattern by making an abstraction that captures all of the common processing policy for this type of business event. Thus the pattern contains the business policy that applies when almost any customer wants to buy almost any kind of product. If your project includes a business event centered on a customer wanting to buy something, then this pattern is a realistic starting point.

The same rubric applies with other events and other domains. Form your patterns by eliminating the idiosyncrasies that exist in many businesses and looking for the general case. Look past the specific to see the general. Look away from the technology the organization currently uses to see the business policy that is being processed. Think of the work, not in its current incarnation, but as a model for work that can be done in the future.

Of course, you can have many patterns, covering many business events and domains. To file them so that they are accessible, we organize these patterns in a consistent way according to the following template (which is really a pattern itself):

Pattern Name: A descriptive name to make it easy to communicate the pattern to other people.

Forces: The reasons for the pattern's existence.

Context: The boundaries within which the pattern is relevant.

Solution: A description of the pattern using a mixture of words, graphics, and references to other documents.

Related Patterns: Other patterns that might apply in conjunction with this one; other patterns that might help to understand this one.


Patterns for Specific Domains

Suppose that you are working on a system for a library. One of the business events within your context is almost certain to be Library User Wants to Extend Book Loan. Figure 13.7 shows a model of the system's response to this event. When a Library User submits a Loan Extension Request, the product responds with either Refused Loan Extension or Loan Extension Approval.

Figure 13.7.

A summary of the library system's response to the event Library User Wants to Extend Book Loan.


Your work on the project in the library domain has led to the specification of detailed requirements for a particular product. As a by-product of doing this work, you have identified some useful requirements patterns, clusters of business-event-related requirements that are potentially reusable on other projects in the library domain.

When you specify requirements using a consistent discipline, you make them more accessible to other people and hence reusable. If you, or someone else, began another project for the library, a good starting point would be the specifications that you have already written. They are usually a prodigious source of recyclable requirements within this domain.

For many examples of reusable domain models, refer to Hay, David. Data Model Patterns: Conventions of Thought. Dorset House, 1995.


Now imagine that you are working on a system in a very different domain, that of satellite broadcasting. One business event within this context is Satellite Broadcaster Wants to Renew License. When the satellite broadcaster submits a Broadcast License Request, the product responds with either Rejected License or New License. Figure 13.8 summarizes the system's response to the event.

Figure 13.8.

A model of the satellite broadcasting product's response to the event Satellite Broadcaster Wants to Renew License.


When you work on the requirements for the satellite broadcasting project, you also discover requirements patterns that are potentially reusable on products within this domain.

Now let's look a little farther afield. We have talked about the idea of identifying and reusing requirements patterns within a specific subject matter domain. But how can we use patterns outside the originating domain?

Patterns Across Domains

At first glance, the event responses to Library User Wants to Extend Loan and Satellite Broadcaster Wants to Renew License appear to be very different. Indeed, they are different in that they come from very different domains. Nevertheless, let's revisit the two event responses, this time looking for similarities. If we find shared characteristics, we have a chance of deriving a more abstract pattern that could be applied to many other domains.

Both books and broadcasting licenses are Things to Be Renewed. The business decides whether to renew an item in response to requests from a Renewer. The business rules for renewing books or licenses share some similarities. For instance, the business checks whether the Renewer is eligible to renew the thing; it decides the conditions of renewal; it records the decision and informs the Renewer. By looking at several different responses, we can make an abstraction: We have some processing policy that is common to all renewable items. We also discover that some attributes of a Thing to Be Renewed are the same regardless of whether we are talking about a book or a broadcasting license. For example, each Thing to Be Renewed has a unique identifier, a standard renewal period, and a renewal fee.

Figure 13.9 shows the result when we make an abstraction of the processing policy from the two business use cases. Here we are using abstraction to identify common characteristics. This means we look past what we see on the surface, and find useful similarities or classifications. It also means we ignore some characteristics in our quest to find common ones.

Figure 13.9.

This business use case model is the result of finding the similarities between a business use case in the library domain and a business use case in the satellite broadcasting domain.


Ignore the physical artifacts and subject matters. For example, in Figure 13.9 ignore the artifacts of library books and broadcasting licenses. Instead, concentrate on the underlying actions of the two systems, with a view toward finding similarities that you can use to your advantage. If, for example, a part of a route allocation system has functional similarities to a container storage system (one of the authors actually found these similarities), then the work done for one system could be recycled for the other.

The skill of identifying and using patterns is tied to several other abilities:

  • The ability to see work at different levels of abstraction

  • The ability to categorize, or classify, in different ways

  • The ability to see that telescopes and glass spheres filled with water are both magnifying devices

  • The ability to spot similarities between apparently different things

  • The ability to disregard physical artifacts

  • The ability to see things in the abstract

Gamma, Erich, et al. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995. Gamma's book is a leading work on object-oriented design patterns.





Mastering the Requirements Process
Mastering the Requirements Process (2nd Edition)
ISBN: 0321419499
EAN: 2147483647
Year: 2006
Pages: 371

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net