How to Find Business Objects
This chapter is from the book
This chapter is from the book
This chapter is from the book
Object Selection
Finding objects is easy if you know how and where to look for them. How to look is simple; use object think to ask questions of domain experts. Where to look is straightforward, too; look for objects in the following four categories: people, places, things, and events.
People
People play a big part in nearly all domains. Information to capture about people includes details identifying individuals, the different contexts in which they can participate, their privileges and duties in those contexts, and records of their interactions. To model a person or an organization that can participate in the system, use an actor object. Model the participation and actions of the person or organization with separate objects.
A simple rule of object modeling is that every action by a person or an organization happens within a context. A context is a focused piece of the business domain that concentrates on the information and rules necessary to reach a single goal. Putting an action within a context helps ensure the action is only undertaken by those able to participate in that context, and that the action only involves other people, places, and things within that context.
Whenever a person or organization participates in a context, two things inevitably happen. First, the system endows the person or organization with permissions, IDs, and passwords necessary to distinguish and track that person or organization within that context. Second, the person or organization's participation acquires its own history, recording the events undertaken within that context. Objectify the obvious. For each context a person or organization participates in, create a role object that has the permissions, IDs, and passwords necessary to participate in the context, and that has associated to it the records of interactions within the context.
Example
In an e-commerce system, create separate role objects for each goal-based action: customer orders products; business buyer orders products for organization; supplier agent sells products; and system administrator creates and manages the accounts and other information in the system. Fred has two role objects: a customer role for his personal orders, and a business buyer role for his company orders. His personal billing and shipping information is held with his customer role, along with his personal orders. His company billing and shipping information, along with his company orders, are held with his business buyer role. Both roles are associated to the person object representing Fred; this common object allows Fred to get to both roles through a single login.
Places
Another simple rule of object modeling is that every recorded action by a person or organization happens in a given place. (An example of a non-recorded action is a search. While it generates results that may be modeled as objects, the search is typically discarded after the user logs out, so it is not permanent history stored with the user role.)
In a simple system where all actions occur at the same location, having an explicit place object maybe be redundant; however, adding it now simplifies expansion to a system with multiple locations later.
Example
A retail clothing store seeks to consolidate all its orders in one database, but wants to be able to distinguish those that were purchased online, from those that occurred in a physical store, from those that were catalog telephone orders. In the model, an order can occur in one of three places: physical store, online store, or telephone catalog store.
Places are often hierarchical for the following reasons: (1) a position for a localized place cannot be fully specified without putting it inside a larger place (an example of this is a gate at an airport; its position is within a particular terminal that is within a particular airport), and (2) recorded actions in localized places are rolled up into larger places for auditing or statistical comparison. The smallest place of interest is where recorded actions occur. A location that merely contains things, but is not a location for recorded actions, is not a place, but a container (see Section 2.2.6). To model a location where recorded actions occur, use a place object; to model a location that contains places, use an outer place object.
Example
In the retail clothing store example, each physical store is assigned to a geographical region overseen by a regional supervisor. The performance of each geographical region is determined by rolling up the orders placed at the physical stores within it.
Things
Every real-world action involves a subject that is the entity being acted upon. A tangible entity that can be the subject of an action is considered a thing. When people and places are the subjects of actions, they are acting like things. (Examples include selecting a particular individual as your insurance agent, or reserving a particular cabin at a ski lodge.)
To describe a real-world thing requires two objects. The first object provides a general, high-level description of the thing that is abstract enough to be shared with other similar things. In effect, this general description defines a set of related things. The second object is a specific description that extends the general description and distinguishes the thing from others in the set.
Decomposing a thing into general and specific descriptions resembles a data modeling technique called normalization; but this is not normalization because the goal of normalization is to avoid replicating data. Objects are more than just data; they have behaviors, too. Having one general description for many specific descriptions allows data sharing, but it also allows for behaviors within the general description that work across all the specific objects, for instance, rank them from best to worst.
To model the general description of a set of things, use an item object, which is a reusable description for many particular things. Use a specific item to model the properties that distinguish a particular thing from other things with the same item description.
Example
An automobile belongs to a set that is defined as all cars with a certain manufacturer, make, model, and production year, but it also has unique characteristics, such as its color, options, and vehicle identification number. Model the automobile with two objects: an automobile description containing the general characteristics, and an automobile object containing its unique characteristics. The automobile description object is reusable for all similar automobiles.
Aggregate Things
As with places, a thing can be tracked at different hierarchical levels of scale. Going up the scale, a thing can be placed within a container, classified within one or more groups, or fitted as a part into an assembly; going down the scale, a thing can act as a container, a group, or an assembly. It is quite common for a thing to exist at both levels; for example, a part in an assembly may itself be assembled out of smaller parts.
To model a thing that is a receptacle or storage place for other things, use a container object. Use a content object to represent a thing that is placed in a container. A content object can only be in at most one container at a given time, although its container may be a content object in another container.
Example
A television network sends its master videotapes to a videotape storage library. Each videotape is bar-coded and assigned a storage location. When the network recalls the videotape, and later returns it to the library, the videotape is again assigned a storage location that may or may not be the same as its previous location.
To categorize a collection of things, use a group object. A group is different from a container, because it denotes categorization, not physical containment. A group is also different from an item. Recall that an item acts a common description for all things in a set, whereas the things belonging to a group need not be related other than by their inclusion in the group. Use a member object to represent a thing that belongs to one or more groups.
Example
The television network has a classification scheme for its videotapes that includes categories such as news, sports, documentary, comedy, drama, children's, and talk show. A videotape is classified into one or more of the categories.
To model a thing constructed from other things, use an assembly object. Unlike a container and a group, an assembly cannot exist without its constituent parts. Use a part object to represent the component things that make up an assembly.
Example
A made-to-order computer workstation is assembled from components selected by online by a customer.
Events
An event is an interaction between people, places and things. Because they tie together the other three categories of objects, events are considered the historical glue in the object model. A simple event involves people interacting at a place with only one thing. Complex events involve multiple things and are discussed in the next section.
Example
A mechanic inspects an automobile on a given date and time, and records the results and success or failure of the inspection.
To model simple events involving only one thing, use a transaction object. Transactions are either point-in-time events that represent a momentary interaction, or they are time-interval events that occur over a long-term duration.
Example
Common point-in-time events are orders, purchases, returns, deposits, withdrawals, arrivals, departures, shipments, and deliveries. Common time-interval events are leases, rentals, job assignments, memberships, and itineraries.
To model a point-in-time event, use a transaction that knows about a single timestamp. For a time-interval event, use a transaction that knows about the starting and the ending timestamps.
Composite Events
Composite events involve people interacting at a place with one or more things. To distinguish and track each interaction with a single thing, a composite event contains smaller events, one for each thing. (Recall objects can play in many ways. People and places can act like things in a composite event. In those cases, they have their own smaller events within the composite event.)
The composite event is responsible for summary information and behaviors that work across all the interacting things.
To model a composite event, use a composite transaction. Use a line item to record the interaction details for a single thing within a composite transaction. A line item is a dependent event in that it cannot exist by itself; it exists only as part of the composite transaction.
Example
An e-commerce order is a composite transaction with a line item for each product included in the order. The line item for a single product contains the quantity ordered, shipping information, and gift wrap and gift message options.
Follow-Up Events
Often, an interaction between a given set of people, places, and things is followed by another interaction with some of the same people, places, and things. In general, simple events are followed by simple events, and composite events are followed by composite events.
Example
Common follow-up events are a delivery following a shipment, an arrival at one place following a departure at another, and a return at one store branch following a sale at a different store branch.
To model an event following another event, use a follow-up transaction object. Follow-up transactions are not the same as line items. A line item records details about a thing inside a composite event. A follow-up transaction describes another event at a later time.
Pattern Players
The 12 collaboration patterns are assembled from the vocabulary of objects discussed in the object selection principles. Because these objects play parts in one or more of the collaboration patterns, we call them pattern players. Table 1 lists the pattern players, loosely organized according to the people, place, thing, and event categories.
Table 1 The Pattern Players
|
People |
Actor Role |
|
Places |
Place Outer Place |
|
Things |
Item Specific Item Assembly Part Container Content Group Member |
|
Events |
Transaction Composite Transaction Line Item Follow-up Transaction |