The central task of a natural science is to make the wonderful commonplace: to show that complexity, correctly viewed, is only a mask for simplicity; to find pattern hidden in apparent chaos.
—Herb Simon
Patterns started when object modelers noticed certain groups of collaborating objects occurring consistently in many object models, and generalized them. As powerful as they were, these patterns did not always play well together because they did not convey a consistent understanding of the real world and its interactions. To get an integrated set of patterns, we set out to find the optimal principles for modeling real-world entities and interactions, theorizing that these would lead us to the fundamental patterns. By scrutinizing past object models involving people, places, things, and events, and considering new hypothetical ones, we hoped to understand what our preferred objects and collaborations represented about real-world entities. This inquiry into the meaning of objects resulted in the object selection principles and pattern players discussed in the previous chapter.
Armed with the object selection principles and the pattern players, we reevaluated our favorite object modeling patterns. We discovered that the majority obeyed the principles and could be expressed in terms of the pattern player objects; in fact, many patterns that appeared unrelated because they contained different objects were shown to contain objects that were several pattern players combined. These combination patterns were considered second-generation. In the end, only 12 patterns were irreducible; from these or combinations of these, we theorized that we could model nearly all real-world entities and their interactions.
As proof to ourselves, which became material for this book, we used the 12 patterns to build object models for commercial applications. In doing so, we determined that not only could object models be constructed from the patterns, but also that the patterns simplified the construction, organization, and coding of the object model. This chapter presents the 12 patterns; later chapters show how to organize behaviors, properties, and business rules around the 12 patterns, how to implement them in code, and how to use them to construct larger patterns.
Any comprehensive methodology for modeling the real world requires a viewpoint, a vocabulary, and an organizational method. Our viewpoint is that the real world consists of entities having simple or complex structures, interacting with one another in space, time, and over a multitude of contexts. Our vocabulary consists of the people, place, thing, and event objects discussed in the previous chapter and known as pattern players. And our organizational method is to decompose all domains into collaborations between people, place, thing, and event objects, and to distribute all domain information and behaviors around these collaborations using object think principles.
No object is an island.1 An object isolated in an object model without any collaborators is an obvious mistake. Given that collaborations are so essential, any object modeling methodology lacking a theory of collaborations must be considered incomplete. At a minimum, a collaboration theory should specify the allowable collaborations between different types of objects. With all collaborations limited to a known set, validation of the collaborations within any object model becomes feasible. A repository of collaborations also simplifies finding objects, because the presence of a given type of object suggests the presences of its likely collaborators. Finally, as will be shown in later chapters, most domain business rules involve deciding which objects can collaborate, when they can collaborate, which collaborations can be dissolved, and when they can be dissolved. For all these reasons, we selected collaboration patterns as the natural foundation for building an object modeling methodology.
Collaboration patterns are the embodiments of the object selection principles presented in the pervious chapter. While the object selection principles describe the meaning and relevance of the objects, the collaboration patterns with their graphical formats concisely and unambiguously illustrate the interactions between the objects. By laying out the principles graphically, and revealing the common pattern players, collaboration patterns make clear how the principles work together to create object models.
Collaboration patterns are not design patterns. Design patterns focus on efficiency, reuse, and pluggability, and while these are important goals, they are concerned more with “how” to effect an interaction, not “what” is involved in it. Collaboration patterns describe the “what” of an interaction—the objects involved and the rules governing those interactions. This book focuses on specifying the “what” through object modeling and prototyping in code. It is not enforcing design principles, but it is expected that those will be applied at the appropriate time. These early chapters introduce collaboration patterns for object modeling, and later chapters introduce implementation patterns for translating collaboration patterns into program code.
Collaboration patterns are, by definition, patterns involving two pattern players. Each collaboration pattern involves two of the pattern players described by the object selection principles.2 Larger patterns arise when two collaborations are “snapped together” by sharing a common pattern player, or when collaborations are merged by sharing an object that is acting as several different pattern players.3
The collaboration patterns are shown in Figure 3.1. The remainder of this chapter describes each collaboration pattern by indicating what its pattern players represent, and what their responsibilities are. This information is summarized in Appendix B. Equally important are the rules governing the interactions between two pattern players, but these will not be described until the next chapter. Documentation formats for precisely specifying collaborations are discussed in Chapter 10.
Figure 3.1. Collaboration patterns.
Some of the collaboration patterns described below are the same as or were derived from patterns depicted in the Object Models book.4 These patterns are indicated.
The actor – role pattern models entities interacting in multiple contexts. It is most frequently applied to people, but can also be applied to places and things.5 This pattern arises from the People, Context, and Role Principles (Principles 11, 12, and 13) that suggest two objects—one describing the person or organization (actor), and a second describing the person or organization within a context (role). For each context, a new role is created
Use the actor – role pattern shown in Figure 3.2 to model people, places, or things participating in one or more contexts.6
Figure 3.2. The actor – role pattern.
An actor can know about multiple roles, but can take on only one of each kind. The actor is responsible for knowing information—properties, services, and collaborations—that is relevant across all contexts.
EXAMPLE—An e-commerce startup tracks people who are customers, employees, and brokers. A person (actor) can play multiple roles, but can only take on at most one customer role, one employee role, and one broker role (see Figure 3.3).
Figure 3.3. Multiple roles for an actor.
A role knows about exactly one actor, and without its actor, a role is not valid. Changes in the actor—new property values or new collaborations—may also impact the role. This dependency on an actor follows because a role is an individualized description of an actor, the guise of an actor within a context. If the collaboration is dissolved, then the role must be destroyed, because a different actor cannot reuse a role; for example, a customer profile cannot be transferred from one person to another. A role also knows the type of actors with which it can collaborate; some roles only work with organization actors.
EXAMPLE—In a supply-chain application, a company can be both a supplier of goods and services and a distributor that buys from suppliers (see Figure 3.4).
Figure 3.4. An organizational actor with multiple roles.
Sometimes a role serves double duty as an actor for another role.
EXAMPLE—A project team collaborates online. Within the team there are specialized roles: administrators and team chairs. Since these additional roles are on top of team membership, the team member role becomes the actor for them (see Figure 3.5).
Figure 3.5. TeamMember is a role for Person and an actor for TeamAdministrator and TeamChair.
The outer place – place pattern models locations where interactions between people and things happen. This pattern arises from the Place Principle (Principle 14) that models a location for interactions with two types of objects—one describing the event location ( place), and an optional second object (outer place) when the location is hierarchical.
Use the outer place – place pattern shown in Figure 3.6 to model locations for interactions between people and things.
Figure 3.6. The outer place – place pattern.
An outer place knows at least one place, and serves as the container of its places.
EXAMPLE—A manufacturing warehouse receives deliveries in its loading areas and dispenses shipments from its shipping areas (see Figure 3.7).
Figure 3.7. An outer place and two places.
A place knows at most one outer place, which contains it.7 Places are also responsible for knowing about events that happen at their locations. For a hierarchical place, its location depends on its own position and its outer place’s position.
EXAMPLE—An airplane flight arrives at and departs from a specific gate within a terminal (see Figure 3.8).
Figure 3.8. Flight events happen at a Gate located within a Terminal.
Sometimes a place serves double duty by acting as an outer place. Allowing the place to serve as an outer place enables modeling of hierarchical locations of arbitrary depths.
EXAMPLE—Within a manufacturing warehouse, each loading area contains loading bins; deliveries happen at loading areas, and each delivery is subdivided into loads that are placed into loading bins (see Figure 3.9).
Figure 3.9. A LoadingArea is both a place and an outer place.
The item – specific item pattern models things that interact with people at given places, and that exist in multiple variations. Two objects are needed. The item describes the information that is common across all variations. The specific item describes the information that makes each variation distinctive. Also, the specific item participates in events. This pattern supports the Thing Principle (Principle 15).
Use the item – specific item pattern shown in Figure 3.10 to model things that come in varieties.8
Figure 3.10. The item – specific item pattern.
An item collaborates with zero or more specific items. The item has properties, collaborations, and behaviors that are shared by its specific items.
EXAMPLE—Everyone’s favorite example is the video store. A video title, for example, Big Sinking Ship, describes a set of videotapes available for renting. The video title has information about the movie and about how the movie is classified within the video store (see Figure 3.11).
Figure 3.11. VideoTitle is the description for a set of VideoTapes.
A specific item collaborates with exactly one item, and is dependent on it, much like a role is dependent on its actor; a specific item cannot exist without its item, and is affected by changes in its item.9 Because a specific item relies on its item for existence, the item is often designed as an object factory10 for creating its specific items.11 Each specific item knows properties that serve to distinguish it from other specific items of the same item, and knows about interactions with people at given places.
EXAMPLE—In the video store example, each videotape has its own unique tracking number to distinguish it from other videotapes of the same title, and each videotape has its own history of rentals and returns.
Sometimes items perform double duty by acting as specific things.
EXAMPLE—In a video store with both DVDs and videotapes for rent, different descriptions for the same movie are required because DVDs have additional options such as subtitles and dual formats not available on videotapes. DVDs are modeled with their own DVD titles, and videotapes with their own video titles. The DVD title and video title are described by a movie title description, which has the characteristics common to all media versions of it. See Figure 3.12.12
Figure 3.12. VideoTitle and DVDTitle acting like items and specific items.
The assembly – part pattern is one of the patterns for modeling things with complex structures. It is used to model a thing that is constructed from other things. This pattern comes from the Aggregate Thing Principle (Principle 16), but an assembly differs from the other complex structures, container and group, because it cannot exist without at least one part.
Use the assembly – part pattern shown in Figure 3.13 to model a thing constructed from other things.13
Figure 3.13. The assembly – part pattern.
An assembly collaborates with one or more parts, and its parts determine many of its properties.
EXAMPLE—A computer workstation is assembled from computer components. The price, weight, and availability of the workstation are partly determined from the characteristics of its parts14 (see Figure 3.14).
Figure 3.14. A Workstation assembled from Components.
A part collaborates with at most one assembly; it may exist independently of its assembly, like a component in stock, but once a part is placed into an assembly, it cannot simultaneously be placed into another.15
EXAMPLE—In the workstation example, the computer components can be ordered and sold individually. Thus, for each part, the multiplicity constraints on its assembly are zero or one, implying that the part can be in zero or one assembly (see Figure 3.14).
As with places, assemblies can be nested into multiple layers. Allowing a part to serve double duty as an assembly supports modeling assemblies at different levels of granularity.
EXAMPLE—Some of the components in the computer workstation assembly are constructed out of smaller subcomponents; for example, the video card component is an assembly of a circuit board, graphics processors, memory, and so on16 (see Figure 3.15).
Figure 3.15. A Workstation with Components that are also assemblies.
The container – content pattern is the second of the patterns for modeling things with complex structures. It is used to model a thing that is a receptacle or storage place for other things. This pattern comes from the Aggregate Thing Principle (Principle 16).
Use the container – content pattern shown in Figure 3.16 when a thing is a receptacle or storage place for other things.17
Figure 3.16. The container – content pattern.
A container holds zero or more content objects. Notice that unlike an assembly, a container can be empty.
EXAMPLE—In a distribution center for a manufacturing plant, cases of product are stored in pallets that are then loaded onto delivery trucks (see Figure 3.17).
Figure 3.17. A Pallet is a container for some number of Cases.
A content object collaborates with at most one container at a time. It can exist outside a container and can be moved between containers, but it cannot be in two containers at once.
EXAMPLE—In the distribution center example, a case can be moved from one pallet to another, or stacked on the floor so that it is not in any pallet.
Containment can be hierarchical, meaning that a container can act as content in another container.
EXAMPLE—A pallet of cases is placed within a truck (see Figure 3.18).
Figure 3.18. A Pallet is both a container of Cases and content within a Truck.
The group – member pattern is the third and final pattern for modeling things with complex structures. This pattern also comes from the Aggregate Thing Principle (Principle 16). It is frequently used to model collections and classifications of things, and it can also be used for collections of people and places.
Use the group – member pattern shown in Figure 3.19 when classifying people, places, or things.18
Figure 3.19. The group – member pattern.
A group knows about zero or more members.
EXAMPLE—A product catalog puts products into categories, such as sportswear, home and garden, etc. (see Figure 3.20).
Figure 3.20. A Product can be in multiple CatalogCategories.
A member knows about zero or more groups. This means that unlike parts and content objects, members can belong to more than one group.
EXAMPLE—In the product catalog example, products can belong to multiple catalog categories (see Figure 3.21).
Figure 3.21. CatalogCategories can be contained within other CatalogCategories.
Sometimes a group serves double duty as a member. This occurs when groups are themselves classified within groups.
EXAMPLE—Product catalog categories can be subdivided into smaller categories; for instance, the home and garden category may contain the kitchen and bathroom categories (see Figure 3.21).
The transaction – role pattern models an entity interacting with things at places. Usually the entity participating in the interaction is a person or organization, but occasionally, it is a thing or place. The point is that the entity is a real-world doer of the interaction. The role pattern player is used instead of actor because the role describes an entity’s participation within a context, and an interaction always occurs within a context. This pattern comes from the Event Principle (Principle 17).
Use the transaction – role pattern shown in Figure 3.22 to describe an entity’s interactions.19
Figure 3.22. The transaction – role pattern.
A transaction knows one role, which represents the real-world doer of the event modeled by the interaction. Occasionally, events coincide with two or more real-world doers engaged in a mutual interaction. If the event details for each doer are the same and simultaneous, then one transaction will work for both.20 Using a single transaction to model simultaneous events is a common modeling shortcut, which results in combining two transaction – role collaborations (see Figure 3.23). Combining collaborations is discussed in Chapter 9.
Figure 3.23. A transaction with two roles combines two simultaneous and related events.
In general, a transaction can know about multiple roles, but can take on only one of each kind.21 Each role represents one of the real-world doers of the event modeled by the transaction. The transaction records details to pinpoint the event in time.
EXAMPLE—In the office supplies example, a sales order placed over the telephone includes the participation of the sales rep taking the order (see Figure 3.24).
Figure 3.24. A SalesOrder can have two role objects.
A role describes an entity within a context, including the information and behaviors necessary to participate in events within the context. A role is also responsible for remembering the events in which it participated. These events are recorded with transactions; and so a role knows about zero or more transactions.
EXAMPLE—An office supplies system takes orders from people participating as customers and brokers. Brokers create purchase orders for businesses; their methods of payment and price lists differ from those of customers. Customers have customer identifiers and create sales orders. See Figure 3.25.
Figure 3.25. A Person participates in transactions through his roles.
The transaction – place pattern models the fact that interactions between entities and things occur at a given location. This pattern comes from the Place Principle (Principle 14).
Use the transaction – place pattern shown in Figure 3.26 when describing the location where an event occurred.
Figure 3.26. The transaction – place pattern.
A transaction knows about one place. When a time-interval transaction occurs in more than one place, then it is best to model that event as a composite transaction containing multiple single transactions, each at a different location. In these cases, the single transactions are acting like line items within the composite transaction (see p. 46.) In some small domains where all transactions occur at the same location, the place may be eliminated as redundant, but then the system is unable to handle new locations being added.
EXAMPLE—A delivery at a loading area is actually a composite transaction consisting of many delivery loads that are deposited into individual loading bins. The loading bins are constrained to be in the same loading area where the delivery is located. See Figure 3.27.
Figure 3.27. A Delivery contains smaller transactions that happen at different locations.
A place knows about zero to many transactions; collectively, these transactions represent a history of interactions occurring at the place. A place also knows information sufficient to define a precise, unique location for events.
EXAMPLE—In a manufacturing warehouse, deliveries arrive to one loading area. To track deliveries, loading areas must be uniquely identified (see Figure 3.28).
Figure 3.28. A Delivery occurs at a precise LoadingArea.
The transaction – specific item pattern models the involvement of a thing in an interaction. Here the thing is involved as the subject of the interaction, not the doer of the interaction, and only one thing is involved. The specific item pattern player is used instead of the item pattern player because an event requires a thing with distinguishing details, whereas an item is a common description for a set of things.22 This pattern comes from the Event Principle (Principle 20).
Use the transaction – specific item pattern shown in Figure 3.29 when describing a transaction involving a single thing.23
Figure 3.29. The transaction – specific item pattern.
A transaction knows one specific item. The transaction includes details about the specific item’s involvement in the event.24
EXAMPLE—In the online cattle breeding site, ranchers can browse the history of breeding events for a given bull and see individual event statistics as well as historical statistics about its success rates.
A specific item knows about zero to many transactions. Collectively, these represent the history of the interactions in which the specific item has been involved.
EXAMPLE—An online cattle breeding site allows ranchers to search for and reserve bulls for breeding services with their cows. A bull object belonging to a cattle breed that contains the general characteristics of the breed represents each bull on the site (see Figure 3.30).
Figure 3.30. Examples of the transaction – specific item pattern.
The composite transaction – line item pattern models the involvement of multiple things in an interaction. Each line item describes the details of involvement for one of the things involved. This pattern differs from the transaction – specific item pattern that includes all the interaction details in a single transaction and involves just one thing. This pattern comes from the Composite Event Principle (Principle 19).
Use the composite transaction – line item pattern shown in Figure 3.31 to describe an interaction of people with multiple things at a given location.25
Figure 3.31. The transaction – line item pattern.
A composite transaction must contain at least one line item. The composite transaction acts like a transaction in that it knows about the role and place of the event.
EXAMPLE—An online entertainment site contracts with content (usually video) producers for the rights to show portions of the producer’s content titles on the site. The license agreement26 contains title terms for each content title covered. See Figure 3.32.
Figure 3.32. A TitleLicenseAgreement contains TitleTerms for each ContentTitle covered by it.
A line item knows exactly one composite transaction, and it is entirely dependent on that composite transaction; the line item cannot be in a valid state without its composite transaction, and it cannot be transferred to another composite transaction. The line item contains details about one of the things involved in the event.
EXAMPLE—In the online entertainment example, each title terms object includes the number of minutes of content that can be extracted from the content title for viewing on the site, the payment terms for viewing the title, and the commission rates for the title when the content showing results in any e-commerce revenues (see Figure 3.32).
The specific item – line item pattern models the interaction of a single thing in a composite event. This pattern comes from the Composite Event Principle (Principle 19).
Use the specific item – line item pattern shown in Figure 3.33 to describe one thing’s interaction in an event involving many things.27
Figure 3.33. The specific item – line item pattern.
A specific item can be involved in zero to many line items. The collection of line items a specific item knows about is part of its history of interactions.
EXAMPLE—In a video store customers can rent multiple videotapes in a single rental transaction (see Figure 3.34).
Figure 3.34. A RentalLineItem knows one VideoTape.
A line item knows exactly one specific item. The line item captures details about the specific item’s interaction with a composite transaction.
EXAMPLE—In the video store example, when a videotape is rented, its due date and actual return date are recorded in a rental line item. The rental line item can also used to record the state of a videotape when it is returned.28 See Figure 3.34.
The transaction – follow-up transaction pattern models a subsequent interaction of some of the same people, places, and things involved in an original interaction. Typically, the things are the same but the people and/or places may be different. This pattern follows from the Follow-up Event Principle (Principle 20).
Use the transaction – follow-up transaction pattern shown in Figure 3.35 to model interactions that follow from earlier interactions.29
Figure 3.35. The transaction – follow-up transaction pattern.
A transaction knows about some number of follow-up transactions. These are often the next steps in processes.
EXAMPLE—An e-commerce site allows a product (an SKU) to be ordered and shipped. Depending on the availabilities of the products ordered and if there are multiple ship-to addresses, multiple shipments may be required to deliver the entire order to the customer (see Figure 3.36).
Figure 3.36. A Shipment is a follow-up transaction to an Order.
A follow-up transaction knows about one transaction; it cannot exist prior to this transaction or be in a valid state without it. Also, since the follow-up transaction is itself a transaction, it may know its own role and place, or it may be a composite transaction.
EXAMPLE—For each line item of product ordered from the e-commerce site, there are some follow-up shipment line items to track how many of the product were sent in each follow-up shipment (see Figure 3.36).
To model a sequential chain of events, a follow-up transaction can act as a transaction for a subsequent follow-up transaction.
EXAMPLE—All or part of a shipment can be returned (see Figure 3.37).
Figure 3.37. A Shipment serves as a transaction for a Return follow-up transaction.
