The Related patterns section within the pattern template contains important clues to other patterns that might be applicable in the context of the object. For example, according to the pattern catalog, the State pattern is often related to Flyweight and Singleton[GoF]. This information must trigger a new set of questions to the software engineer - for example, "Are there any parts of my solution that could also benefit from the use of the Flyweight or the Singleton pattern?" - and cause the engineer to examine the existing approach.

Our solution using the State pattern currently has one drawback. If our timesheet system will handle, say, 5,000 timesheets in the approved state, we would also carry 5,000 instances of the Approved state. Also, with every state change, we would create a new instance of a new state and the Java garbage collector would need to collect the old state objects. This might not be very critical for our timesheet application, but in other scenarios this could be very expensive in terms of resources. Figure 9 shows just a small number of timesheets and associated states that would multiply thousands of times in our application, as it is thus far designed.

In our timesheet example, the states "approved, submitted. and entered" are good candidates for Flyweight objects because there is no need to add any additional attributes to one of the states to distinguish these instances. With the Flyweight pattern, we are actually able to improve the State pattern solution even further, as shown in Figure 10.

Our timesheet application now contains only three different state instances at any given moment, which increases maintainability and performance.

However, applying the Flyweight [GoF] pattern raises a new challenge for our designer. Instead of creating a new instance of a particular state object or carrying the flyweight objects around as parameters, we would like to achieve visibility to this one instance of state in that particular situation. The Singleton [GoF] pattern serves exactly this purpose. We could either implement each state as a Singleton, or create a factory of states which creates and manages the states. The latter method would increase maintainability even more through separation of concerns.

In pattern-driven development, the destination may be the origin for new patterns. For example, the State pattern often harmonizes with the Flyweight and Singleton patterns. However, Flyweight and Singleton have further associations to even more patterns, and so on. For simplicity, I have limited my illustration of these pattern relationships to the GoF catalog; the Also Known As section of the pattern template opens the door to other catalogs as well.

Pattern-Driven Development in Service-Oriented Architectures
In service-oriented architectures (SOA), there are services, providers, and consumers, just as there are responsibilities, receivers, and senders in object-oriented architectures. The difference is that the application-centric design approach, (e.g. the timesheet application) is elevated to the orchestration of services aligning the IT system with, for example, the business processes. So far, our design for the timesheet application has been driven by technology and a requirements change. To include the timesheet application in a SOA, services must be exposed so that human and non-human interfaces can be consumed.

In SOA design, the isolated view of the timesheet application would be replaced by a view of how the services of the timesheet application harmonize with other services from other applications. Depending on business requirements, the timesheet application could be seen in light of an organizational payroll process or in combination with a cost-breakdown-structure for product management. Exposing or modifying existing services or creating new services becomes a critical task for the enterprise and application architect. A more flexible and maintainable system built with patterns is therefore a critical element for a successful SOA.

Earlier in this article, I showed how patterns promote the application of additional related patterns, even across catalogs. We also saw that patterns exist in various forms, from helping with design decisions on an object level to patterns on an application level (i.e., assigning responsibilities vs. GoF patterns). The pattern-driven approach helps provide flexible and maintainable services in an SOA, and the SOA itself can drive and stimulate the pattern-driven approach. Business modeling patterns as well as architectural/network patterns motivated through an SOA can drive pattern-driven development top-down, whereas the pattern-driven application design prepares a successful SOA bottom-up.

Conclusion
Finding a matching pattern for a problem not only presents a solution to a problem, but also means in many cases the beginning of a new search and further evaluation of related patterns. This type of search/discovery/exploration activity should be familiar to you if you've ever used an Internet search engine to explore a topic you only vaguely understand. You often start with terms you're not sure about, but as you see more accepted terms and areas of knowledge unfold in your result set(s), you gain insight into the "patterns" of thinking and solutions that exist. Soon, you are able to enhance your own queries, eventually expanding your original lines of thought.

When properly documented and cataloged, patterns provide a common roadmap, encourage engineers to investigate the problem space, and, more importantly, allow us to apply a set of proven solutions rather than only one particular solution. I have used a basic enhancement request to illustrate the impact of change to a pattern-driven solution for a system in maintenance mode. Following an iterative-incremental process model, projects face very similar situations during construction, and we can easily map the benefits of pattern-driven development to incremental improvements in the project.

The Rational Software Architect (RSA) provides capabilities to support a pattern-driven engineering process by starting with common design patterns (for example GoF), or by creating its own pattern catalog. Publishing a pattern catalog with RSA and sharing the library of patterns on an enterprise level increases adoption rate which results in more reliable and flexible IT design. The ability to react to and adapt to organizational change is a fundamental strategy for a SOA.

References
• Gamma, E., Johnson, R., Helm, R., and Vlissides, J.M. (1995). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley.
• Larman, Craig. (2004). Applying UML and Patterns - An Introduction to Object-Oriented Analysis and Design and Iterative Development 3rd Edition. Prentice Hall.
• Alexander, C. (1979). A Timeless Way of Building. Oxford University Press.
• Cooper, J.W. (2001). Java Design Patterns -- A Tutorial. Addison-Wesley.
• Alpert,S., Brown, K., and Woolf, B. (1998). The Design Patterns - Smalltalk Companion. Addison-Wesley.