When we try to pick out anything by itself, we find it hitched to everything else in the Universe.
—John Muir
Every pattern-based methodology has as its ultimate goal the construction of object models from patterns. The popular metaphor compares patterns to “building blocks” that connect and snap together to build larger structures. Streamlined object modeling takes a different approach by starting with the elements of the patterns instead of the patterns themselves. This approach proposes elementary pattern players, similar to chemical elements, and pairs them up to form “molecules.” Which pattern players can pair up and form molecules depends on their individual characteristics. Ultimately, only 12 pairs of the pattern players form stable molecules called collaboration patterns. This chapter takes the chemical analogy to the next level and shows how to create compound collaboration molecules from the original 12 collaboration patterns.
Because collaboration patterns reflect real-world relationships between objects that are the stable over time, they form sturdy molecules for constructing object models. By placing one of the two collaborating pattern players into another collaboration pair, two collaborations are combined, making a bigger but still stable molecule.1 Compound collaboration molecules come in two varieties: snap-togethers and overlays. Snap-together collaboration molecules connect two or more collaboration patterns into a larger structure. Overlay collaboration molecules merge pattern players from two or more collaboration patterns, creating new kinds of pattern players, with new characteristics derived from the originals.
Since combining collaborations depends on the pattern players involved, it is essential to understand what the pattern players represent in the real world and how they participate in collaborations. To this end, every pattern player can be categorized into an empirical category and one or more fundamental pattern categories.
The empirical categories indicate what an object represents in the real world. An object represents either a single real-world entity or a collection of real-world entities.
Objects representing single real-world entities2 fall into one or more of the following categories:
• People – Individuals or collections of individuals participating in contexts and events
• Places – Locations or hierarchies of locations where events happen
• Things – Tangible entities that are not people or a places
• Events – Point-in-time or time-interval interactions between people, places, and things
Objects representing collections of real-world objects are one of the following:
• Classification – A group of entities matching some criteria
• Receptacle – A container for receiving and storing entities
• Ensemble – A whole viewed as a collection of its parts3
The fundamental categories indicate how an object participates in its collaborations. Since all collaborations can be generalized into one of the fundamental patterns, an object can be categorized as one or more of the fundamental pattern players. As shown in previous chapters, putting an object in a fundamental category determines much of its implementation. An object participates in collaborations as one or more of the following:
• generic
• specific
• transaction
• whole
• part
Table 9.1 summarizes the collaboration pattern players in terms of their empirical and fundamental categories.
Table 9.1. Pattern Player Table.
People objects represent entities that can participate in contexts. Typically an actor is a person and a role is his description and behavior in a context; however, things and places can be actors and take on roles, too. A more precise category name might be “entity-context” objects, but since giving things and places roles is really making them anthropomorphic, plain “people” does just fine.
Pattern players in the generic row are parents to pattern players in the specific row. A people specific requires a people generic; a thing specific requires an thing generic; and an event specific requires an event generic.
EXAMPLE—A truck can take on the role of delivery vehicle, and a person can take on the role of a customer. But a truck cannot be a customer, and a person cannot be a delivery vehicle.
Events record the interactions of people, places, and things. Pattern players with event interactions are specific people, specific things, or local places. When a transaction has interactions captured by a follow-up transaction4 it is acting like a specific thing.
Whole – Part Pattern Players.Whole and part pattern players in the classification, receptacle, and ensemble categories represent collections of people, places, things, and events. Spatial containment for places is also handled by whole – part. The composite transaction – line item pattern has some aspects of the whole – part relationship, but the dominant relationship between the entities is object inheritance. Therefore, these go in the table as generic – specific.
The simplest forms of collaboration combinations are the “snap-togethers.” Two collaborations snap together if they share a common pattern player, meaning that the same object acts as the same pattern player in both collaborations.
Transactions are the glue that brings people, places, and things together. As such, they are involved in many of the snap-together collaborations. Further, since the transaction is a sort of common denominator, all of the snap-together collaborations can then be snapped together themselves as shown in Figure 9.1.
Figure 9.1. Transactions snap together many collaboration pairs.
The transaction – role – actor pattern represents people participating in a context and interacting with things and places that are recorded as events. The role pattern player represents the people object in the context and is the common pattern player between the collaboration patterns.
The transaction – specific item – item pattern represents an event involving a distinct individual thing that shares a common description with several related things.
The transaction – place – outer place pattern represents an event happening at a place that can be contained in a hierarchy of larger places.
Follow-up transactions happen after the original event recorded by a transaction, and they can involve the same people, places, and thing as the original, or they can involve new ones.
Snap-togethers for follow-up events involving the same people, places, and things are:
• role – transaction – follow-up transaction
• place – transaction – follow-up transaction
• specific item – transaction – follow-up transaction
Snap-togethers for follow-up events involving different people, places, and things are:
• transaction – follow-up transaction – role
• transaction – follow-up transaction – place
• transaction – follow-up transaction – specific item
EXAMPLE—A vehicle registration happens in a county of a state, and involves a particular vehicle and its owner. Each vehicle maps to a vehicle description that includes its make, model, year, and manufacturer. A registration can be renewed multiple times for the same owner and vehicle at the same or a different county. See Figure 9.2.
Figure 9.2. Example of a follow-up transaction that can happen at a different place.
A composite transaction represents a complex event involving many things. Line items and specific items represent the involvement of the things in the event. See Figure 9.3.
Figure 9.3. Composite transaction snap-together collaborations.
EXAMPLE—The infamous store order is an example of a composite transaction where the things involved are specific products with SKUs. For each specific product ordered, an order line item records the order quantity. To track sales regionally, each order remembers the store where it occurred, and each store belongs to a geographic region that is itself contained in zero to one geographic regions. See Figure 9.4.
Figure 9.4. Example of a composite transaction snapping together several collaborations.
In their book, Java Modeling in Color with UML, Peter Coad, Eric Lefebvre, and Jeff De Luca5 propose a “domain-neutral component” that resembles the snap-together collaborations shown in Figure 9.1. Coad and his co-authors use archetypes instead of pattern players as the basic units for object collaborations, but the resulting component has a similar structure: a central event with collaborating people, places, and things. The archetypes loosely map to the fundamental patterns players as shown in Table 9.2.
Table 9.2. Archetypes Compared to Pattern Players
Even more intriguing, Coad and his co-authors show archetypal interactions (Table 9.3), which are typical interactions involving the archetypes in the domain-neutral component, and these match very nicely with the three types of services shown in this book.
Table 9.3. Archetype Interactions Compared to Streamlined Services
An overlay collaboration involves an object acting as different pattern players in multiple collaborations. This section shows some common overlapping collaborations, how they are derived, and an example of each. These are by no means the exhaustive set, just enough to give a general idea.
EXAMPLE—In the nomination example, a team member is both a role for a person and a member of a group (see Figure 9.5).
Figure 9.5. TeamMember is both a role and a member of a group.
Domains that use qualifications to schedule resources gather required qualifications in role definitions. Each role definition is a specific thing that can be classified, grouped, or sorted, and a generic thing that can have many specific instantiations. Project management and resource planning use role definitions.
This pattern combines the actor – role and item – specific item collaborations. Use this collaboration combination when an actor is assigned to take on a role with requirements described in a role definition. Record in the specific role the individual details of the actor’s assignment, and use the specific role as the role for transactions entered into while acting in that role definition. See Figure 9.6.
Figure 9.6. A specific role combines the role and specific item pattern players.
EXAMPLE—A trucking company has trucks that can be configured to take on some number of the following delivery roles: non-food cargo, perishable food cargo, and non-perishable food cargo. The company creates scheduled cargo deliveries according to the delivery role types, and then assigns the actual cargo delivery to a truck with the appropriate delivery role. See Figure 9.7.
Figure 9.7. Using DeliveryRoleType to schedule deliveries and assign trucks.6
A specific role has two parents, its actor and its role definition, and it object inherits from both of them. To implement double object inheritance, the specific role implements the profile interfaces of both its parents (see pp. 161–162, “Define: The Parent Profile Interface”). Some care must be taken to avoid collision of service names
Subsequent roles appear in domains that include a context within a context. Nested contexts occur when a context of interactions includes a subset that requires additional information or qualifications for participation. A subsequent role captures the additional information required to participate in the more specific context.
This pattern combines the actor – role collaboration with itself. The fundamental role represents the basic requirements for participation and is the parent to the subsequent role that contains the additional information required to participate in a specialized context. Use this pattern in a domain that offers different services to nested levels of memberships (see Figure 9.8).
Figure 9.8. A fundamental role serves as an actor for a subsequent role.
EXAMPLE—An airline frequent flyer program requires a member to travel 25,000 miles or more within a year to qualify for their elite services. Elite frequent flyers can obtain free first-class upgrades and bonus miles for flights. See Figure 9.9.
Figure 9.9. An EliteFrequentFlyer is a subsequent role of a FrequentFlyer.
Domains that describe things differently based on context require items to become actors. An item actor is a description that can have further descriptions for different contexts.
This pattern combines the item – specific item, actor – role, and group – member collaboration patterns. The member role is the further description of the item actor. Use this pattern when the further description of the item actor can appear in multiple contexts. See Figure 9.10.
Figure 9.10. An item actor is a description that takes on roles.7
Item Actor - Content Role - Container. This is another item actor pattern. It combines the item – specific item, actor – role, and container – content collaboration patterns. The content role is the further description of the item actor. Use this pattern when the further description of the item actor can appear in only one context.
EXAMPLE—A retailer keeps multiple marketing descriptions for each of its products. A marketing description can be reused in many advertisements. The retailer also groups its products into categories and has a professional shopper assign a rank to each product in a category (see Figure 9.11). Here, the product rank is the container role, and the marketing description is the member role.
Figure 9.11. A Product collaborating as an actor with content and member roles.
Domains tracking a sequence of events involving multiple things require composite follow-up transactions. Just as a composite transaction records the individual interactions of many things, a composite follow-up transaction records the individual follow-up events for the many things in the original event.
This pattern combines the composite transaction – line item and transaction – follow-up transaction collaborations. Use this combination only when follow-up details are needed for each specific item in the original composite transaction. See Figure 9.12.
Figure 9.12. Composite transactions often require composite follow-up transactions.
Often, multiple follow-up events are required for a single composite event, and not all things handled in the original event are handled in each follow-up event. Together these explain why each line item in the original composite transaction has zero to many follow-up line items.
EXAMPLE—An order is followed by some number of shipments. When more than one unit of a single product is ordered, it can be involved in multiple shipments to the same or different locations. Each shipment line item indicates the quantity shipped of the specific product, and collaboration rules prevent shipping more of the specific product than the quantity ordered. See Figure 9.13.
Figure 9.13. An Order followed by some number of Shipments.
Item assemblies appear in domains using templates to construct complex structures. An item assembly is a template whose parts are also templates or generic descriptions. Specific assemblies created from an item assembly contain parts created from part templates.
This pattern combines the assembly – part and item – specific item collaborations. As an assembly, the item assembly must have parts, and any structure created from it must have parts, too. Use this combination when complex structures are created from common templates. See Figure 9.14.
Figure 9.14. Item assemblies are templates for specific assemblies.
EXAMPLE—A proposal generation system constructs proposals by selecting chapters from a proposal template. Subchapters are then chosen based on the selected chapters. To ensure the latest versions are always incorporated into the proposal, it contains references to chapters and subchapters, rather than copies of their text. The “paper” proposal is a report generated by extracting the text from the chapters and subchapters referenced in the proposal object. See Figure 9.15.
Figure 9.15. An assembly structure for creating Proposals.
Domains that allow generic descriptions to be used in events require definite generics. A definite generic acts as the parent description for a set of specific things, and can itself be involved in interactions. Typically, an event involving a definite generic is followed by an event involving one of its specific things.
This pattern combines the item pattern player in the item – specific item collaboration and the specific item in the specific item – transaction collaboration. The resulting pattern player, a definite generic, acts like a generic toward its child objects and like a specific that can interact in events. Transactions involving definite generics are object inheritable. See Figure 9.16.
Figure 9.16. A definite generic is an item that has transactions and specific items.
EXAMPLE—A video title can be reserved, and one of its videotapes can later be rented as a follow-up to the reservation (see Figure 9.17).
Figure 9.17. A VideoTitle has Reservations that are followed by Rentals of children.
Plan executions appear in domains that have templates for events. A plan execution records the details of an event described by a generic plan. Typically, the plan describes a regularly scheduled event, and a plan execution records the details of one such event.
This pattern combines the item – specific item and transaction – specific item collaborations. In the same way that a specific item is a variation of its item, a plan execution is one particular run of its plan. Since this run is also an event, the plan execution acts like a transaction involving a specific thing, the plan. See Figure 9.18.
Figure 9.18. Plan executions are created from plan templates.
EXAMPLE—A bottling plant has production lines that can be configured with different production plans. Each plan describes the package size, line speed, and fill rate of the line configuration. A production line execution records the actual line speed and fill rates, and how much was produced during the run. See Figure 9.19.
Figure 9.19. ProductionLineRuns are transactions created from plan templates.
Domains involving extensive or configurable workflows require process executions. A workflow is an ordered sequence of events. Simple, non-configurable workflows can be handled by successions of events, but when the chain of events is very lengthy or can be re-ordered, then it becomes necessary to model the sequence as a series of steps.
This pattern combines the plan – plan execution pattern and the assembly – part collaboration. A process is an assembly because, unlike a plan, which is a single intended action, a process is made up of an ordered sequence of actions8. Like a plan, a process can run over and over again, and each run is modeled as a child execution; however, each process execution is itself made up of step executions for some or all of the steps within the parent process. See Figure 9.20.
Figure 9.20. A process execution is created from a process assembled out of steps .
EXAMPLE—A construction company has multiple procurement processes for each type of component it procures during a project. When a specific construction component is to be procured, one of its type’s processes is selected to generate a procurement schedule with the various steps needed to request, approve, and create purchases for that component. See Figure 9.21.
Figure 9.21. Generic ProcurementProcesses generate ProcurementSchedules for ConstructionComponents.
Membership plans appear in domains where the enrollment of a person or thing in the system is tracked as history and governed by terms laid out in a plan, typically one plan of many. A membership records the details of an individual’s participation, such as when the person or thing enrolled, the membership status, and the membership privileges. The membership object inherits the enrollment terms from its membership plan, including the length of the membership, fees, discount policies, and renewal methods.
This pattern combines the plan – plan execution pattern and actor – role collaboration. As a role, the membership and its transactions describe the actor’s participation in the system; as a plan execution, the membership is one particular “run” of the membership plan, with a creation timestamp and usually an expiration date9. See Figure 9.22.
Figure 9.22. A membership plan has plan executions that are also roles for actors.
EXAMPLE—An online application offers expert information and accredited training videos for credit to certified professionals who enroll as subscribers to the site. Individuals who join by responding to a promotion are enrolled under the subscription plan associated with the promotion. Persons may renew as subscribers under the same or a different subscription plan. See Figure 9.23.
Figure 9.23. A SubscriptionPlan generates time-limited Subscriber roles for Persons.
Parameterized children appear in domains where a thing can be described in multiple ways. Usually a thing is tightly bound to its description, but a parameterized child can be assigned to one or more descriptions, much like assigning a person or thing to one or more groups. Any interaction of the thing with other objects requires first specifying which description applies. Choosing a description is often modeled as a distinct event, followed by the interaction involving the thing.10 Without that interaction tying it to a choice of a description, the thing cannot respond to certain requests for information; thus, many requests to the thing require a parameter to help disambiguate which description applies.
This pattern combines the group – member, item – specific item, transaction – specific item, and transaction – follow-up transaction collaborations. The group – member and item – specific item combination models the assignment of multiple descriptions to the parameterized child, and the nature of the parameterized child as a specialization of its descriptions. These combinations, along with the transaction collaborations, model the selection of a particular item as the relevant description and the follow-up interaction of one of its child objects. See Figure 9.24.
Figure 9.24. A parameterized child needs child transactions to determine its object inheritance.
EXAMPLE—A conference planning system schedules conferences for specific dates and times. Each conference can be described in multiple ways depending on the target demographic. An XML conference might target engineers and developers with a description like “XML Devcon.” The same conference might then market itself to managers as “XML for Dummies.” An attendee receives an invitation for a particular conference description, and confirms he will attend one of the scheduled conferences. See Figure 9.25.
Figure 9.25. A Confirmation selects a parent for a ScheduledConference with multiple descriptions.
Two rules govern the behavior of parameterized child objects:
• No parent, no interaction. A parameterized child cannot interact with other objects, unless one of its parents is designated by the interaction.
• No interaction, no object inheritance. A parameterized child cannot perform object inheritance except in the context of an interaction that includes or follows the selection of one of the parents.
The “no parent” rule follows from specific item collaboration rules that prevent a specific item without a parent from collaborating with a transaction. This rule explains why a child transaction involving the parameterized child is always a follow-up to a parent transaction involving one of its parents. The exception is when the parent is selected simultaneously with the interaction involving the child, and the selection and interaction are captured in a single transaction.
The “no interaction” rule states the simple fact that without some context, a parameterized child cannot know which parent to use for object inheritance, and from the “no parent” rule, it follows that context is provided by a child transaction.
Two implementation approaches for parameterized child objects are recommended:
• Implement the non-parameterized parent profile interface plus a parameterized version that takes a child transaction.
• Implement a method that given a child transaction returns an object that implements the parent profile interface.