The area of patterns has prompted a great deal of work, both past and ongoing. The set of business patterns contained in this book represent only some of that work. Therefore, we list here a number of references that contain recommended additional reading on patterns, which in many ways have inspired the patterns defined in this book. Not all of the patterns described in these references are business patterns (or they’re not always referred to as business patterns); some of these sources describe architectural patterns, design patterns, or even patterns in other areas such as project management, or
Alexander’s work, which is directed toward house and city architectures.
Christopher Alexander. Timeless Way of Building, Oxford University Press, 1979.
Christopher Alexander. A Pattern Language, Oxford University Press, 1987.
Scott W. Ambler. Process Patterns: Delivering Large-Scale Systems Using Object Technology, Cambridge University Press, 1998.
Michael A. Beedle. “cOOherentBPR – A pattern language to build agile organizations,”
PLoP-97 Conference, 1997.
Frank Buschmann, Regine Meuiner, Hans Rohnert, Peter Sommerlad, Michael Stal.
Pattern-Oriented Software Architecture: A System of Patterns, John Wiley & Sons, Inc., 1996.
Martin Fowler. Analysis Patterns: Reusable Object Models, Addison-Wesley, 1997.
Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Design Patterns, Addison-Wesley, 1995.
David C. Hay. Data Model Patterns: Conventions of Thought, Dorset House, 1996.
James Coplien and Doug Schmidt (eds). Pattern Languages of Program Design, Addison-Wesley, 1995.
John Vlissides, James Coplien, and Norman Kerth (eds). Pattern Languages of Program Design 2, Addison-Wesley, 1996.
Robert Martin, Dirk Riehle, Frank Buschmann, and John Vlissides (eds). Pattern Languages of Program Design 3, Addison-Wesley, 1998.
Important, ongoing contributors to the work of patterns are the annual patterns conferences, such as PLoP, EuroPLoP, and ChiliPLoP. Each year, new papers on patterns of different types are presented and workshopped, and the state-of-the-art in pattern development is described.
Summary
Many of the problems that arise when modeling businesses have arisen before and have been solved before; there is no reason to solve them all over again. A pattern is a description of a common solution to a recurring problem that can be applied to a specific context. A pattern is described with a structure through a class diagram, that shows the participating classes in the pattern. It can also have behavior, which is illustrated with a sequence diagram that shows how the classes communicate in a specific situation.
There are many types of patterns, such as architectural patterns that show the high-level architecture of a system, design patterns that are more oriented toward programming, or even patterns that are used for project management. The patterns presented in this book are business patterns that describe common modeling solutions to use when doing business modeling: modeling resources, organizations, goals, processes, and rules.
There are three categories of business patterns: resource and rule patterns, process patterns, and goal patterns. Each of these categories addresses problems in their specific context. The next three chapters present a number of business patterns organized according to the business pattern categories introduced in this chapter.
Chapter 7: Resource and Rule Patterns
Overview
The patterns described in this chapter will help you to identify, represent, and structure business resources. Resource modeling is an important issue in business modeling. All businesses use resources, which include, but are not limited to, people, material, or information, and products, which act, are used, or are produced within the business.
Note To understand and use the patterns described in this chapter, you need to familiarize yourself fully with the business extensions to UML, described in Chapter 4, “Business Views”; you should also review the concept of powertype, discussed in Chapter 2, “UML Primer.”
Business resources are arranged in structures (modeled in the Business Structure view, explained in Chapter 4) and have relationships with each other; they take an active or passive part in the business processes, to achieve the goal of those processes. The 13 patterns defined in this chapter are used in that view.
As mentioned in Chapter 3, “Modeling the Business Architecture,” rules affect processes, resources, and goals. Most commonly, rules are used to define how to organize
resources. Rules are an inherent part of the resources, and, in particular, the structures and relationships among the resources, which means they cannot be easily separated.
Therefore, there are no separate “rule patterns”; instead, rules are part of the resource patterns.
The patterns in this chapter establish rules for structuring and representing resources.
The patterns are subsequently used for modeling the resources in a business. Without them, a modeler must define classes for some or all of the concepts found in the
business, then attempt to connect all of the concepts without benefit of an overall plan or structure.
These patterns enable you to:
§ Express a core business concept separately from the representation of that concept (Core-Representation), handle information about a resource in the business separately from the resource itself (Thing-Information), or represent a title separately from items of that title (Title-Item).
§ Depict and organize the business events that occur in a business (Business Event -Result History).
§ Model common business concepts and situations, such as contracts (Contract), documents and document copies/versions (Document), employment of persons in an organization (Employment), and addresses that might become obsolete (Geographic Location).
§ Separate an individual actor resource in the business from the different roles in the business (Actor-Role).
§ Structure the definition of common business terms used in the business (Business Definitions).
§ Define and represent a flexible business organization (Organization and Party).
§ Represent a complex product and all information about that product or parts of it (Product Data Management).
§ Model the relationship among a type, objects of that type, and values that those objects can have (Type-Object-Value).
Though most of these patterns have been used for more than 20 years in business process modeling, rarely have they involved object-oriented concepts; and, of course, they have not been modeled with UML. They have proven to be essential in the structure and representation of business resources. When resources are well structured and well represented in the business model, it’s easier to connect and use these resources in the process patterns (presented in Chapter 9).
Resource and rule patterns are often used when a client or employee describes an organization or a resource structure in terms of what that organization or structure looks like right now. For example, the names of the departments or the names of a product structure (which could be captured in a UML object diagram). Using these patterns, you, the modeler can abstract this information into a more generic model that isn’t applicable to the organization or structure as it looks today, but allows for future changes and extensions, such as a well-designed UML class diagram.
Example implementations of these patterns include:
§ Car manufacturing systems, to describe a very complex product structure and to link all related documents to the product part to which they refer.
§ Financial systems, to define abstract and complex financial instruments and to separate the core meaning of an instrument from a variety of representations.
§ Document handling systems to administrate document originals, different versions of those documents, information about the documents, and copies of those documents
As you can see from these examples, these resource and rule patterns are generic enough to be used in almost any kind of business.
The 13 patterns defined in this chapter are presented in alphabetical order. References that describe common combinations and relationships among the patterns can be found in the Related Patterns section for each pattern.