As we discussed in Chapter 2, when learning about something new, we automatically search our "mental archive" for other abstractions/models that we've previously built and mastered, to look for similarities that we can build upon. This technique of comparing features to find an abstraction that is similar enough to be reused effectively is known as pattern reuse. As it turns out, pattern reuse is an important technique for object-oriented software development.
Let's say that after we finish up our SRS class diagram, we're called upon to model a system for a small travel agency, Wild Blue Yonder (WBY). As a brand-new travel agency, WBY wishes to offer a level of customer service above and beyond their well-established competitors, and so they decide to enable their customers to make travel reservations online via the Web (most of WBY's competitors take such requests over the phone).
For any given travel package—let's say a 10-day trip to Ireland—WBY offers numerous trips throughout the year. Each trip has a maximum client capacity, so if a client can't get a confirmed seat for one of the trips, he or she may request a position on a first-come, first-served wait list.
In order to keep track of each client's overall experience with WBY, the travel agency plans on following up with each client after a trip to conduct a satisfaction survey, and will ask the client to rate his or her experience for that trip on a scale of 1 to 10, with 10 being outstanding. By doing so, WBY can determine which trips are the most successful, so as to offer them more frequently in the future, as well as perhaps eliminating those that are less popular. WBY will also be able to make more informed recommendations for future trips that a given client is likely to enjoy by studying that client's travel satisfaction history.
In reflecting on the requirements for this system, we experience d閖?vu! We recognize that many aspects of the WBY system requirements are similar to those of the SRS. In fact, we're able to reuse the overall structure, or pattern, of the SRS object model by making the following class substitutions:
Substitute TravelPackage for Course
Substitute Trip for Section
Substitute Client for Student
Substitute TripRecord for TranscriptEntry
Substitute TravelHistory for Transcript
Note that all of the relationships among these classes—their names, types, and even their multiplicities—remain unchanged from the SRS class diagram (see Figure 12-3).
Such an exact match is exceptionally rare when reusing design patterns; don't hesitate to change some things (eliminate classes or associations, change multiplicities, and so forth) in order to facilitate reuse.
Having recognized the similarities between these two designs, we're poised to take advantage of quite a bit of reuse with regard to the code of these two systems, as well. In fact, had we anticipated the need for developing these two systems prior to developing either one, we could have taken steps up front to develop a generic pattern that could have been used as the basis for both systems, as well as any future reservation systems we might be called upon to model, as illustrated in Figure 12-4.
Many useful, reusable patterns have been studied and documented; before embarking on a new object modeling project, it's worth exploring whether any of these may be a suitable starting point. Our "Recommended Reading" section in Chapter 17 suggests some references that you might wish to explore on this topic.