Chapter 10

Archetypes

Archetypes are abstractions that often occur and transcend individual applications. You should keep them in mind as you construct models. The use of an archetype can lead to a breakthrough. By necessity, the list in this chapter is arbitrary and incomplete. The archetypes themselves are also incomplete so you will need to add detail as you include them.

Many of the archetypes relate to each other. This chapter uses an entity type icon (UML—no attribute section, IDEF1X—ellipsis for attributes) for references to entity types that are defined elsewhere in the chapter.

Throughout the chapter the shaded boxes are metadata and the white boxes are data.

10.1 Account

An Account is a label for recording, reporting, and managing a quantity of something. Applications involve a variety of account types:

• accounting applications — general ledger account, account payable, account receivable
• business applications — bank account, credit card account, customer account, expense account, purchase account, sales account
• computing applications — computing account, email account
• travel applications — frequent flyer account, travel account

Each Account has an owner (a TangibleActor, in this case a person or organization, see Section 10.2). Typically an owner can have multiple accounts for an account type (Figure 10.1, Figure 10.2). Some of these accounts might be unwanted duplicates and remain undetected until after data has been posted. The notion of AccountEquivalence can logically combine accounts without having to move data (see the Symmetric Relationship Antipattern). In addition, since the merge is logical and not physical, it can be undone.

10.2 Actor

An Actor is someone or something that is notable in terms of data or relationships. An actor is not the real world thing but is the computing counterpart for attaching information.

An actor provides a “hook” for interchangeable data (Figure 10.3, Figure 10.4). An Actor is a Person, Application, Organization, ActorRole, or ActorRoleType. An application includes this model and relates relevant entities. As an example, an actor can provide the basis for assigning permissions. Sales documents may be accessible by Joe Smith (a Person), the sales department (an Organization), and the head of marketing (an ActorRoleType). Additional examples involve approval and logging. For many business processes, the efforts of Persons, Applications, Organizations, ActorRoles, and ActorRoleTypes are interchangeable and Actor can abstract across them.

A Person is someone who is important to an application. An Application is a reference to software — an intelligent Application can take the place of a Person in some situations. For example, expert system logic can determine whether to grant approval for a credit card charge. An Organization can be a business entity, a grouping of organizations, or a part of an organization. A TangibleActor is a Person, Application, or Organization.

An ActorRoleType is a job function that a TangibleActor can perform; examples include clerk, manager, administrator, customer, and vendor. An ActorRole is the combination of a TangibleActor and an ActorRoleType (see Section 10.18). Examples include John Doe the manager and John Doe the user. You can think of an ActorRole as a TangibleActor wearing a hat (the hat is an ActorRoleType).

The Actor archetype is highly generic. You can capture data for individual actors either by using softcoded values (see Chapter 13) or by creating specific entity types as this chapter does for customer (Section 10.7) and vendor (Section 10.20).

10.3 Address

An Address is a means for communicating with an Actor (Figure 10.5, Figure 10.6). An address can be a postal address, email address, phone number, or URL. An address can serve various purposes (AddressRoleTypes, see Section 10.18) such as shipping, billing, business, and home. Thus the same address might be used both as a business address and a home address.

10.4 Asset

An Asset is something of value (Figure 10.7, Figure 10.8). An OwnedAsset is an asset that is owned outright. A RentedAsset is the use of an OwnedAsset for some time period. Thus, for example, a bicycle that is owned is an OwnedAsset. A bicycle that is rented for some time period is a RentedAsset. An OwnedAsset may or may not be individually identified — if an OwnedAsset lacks identity, AssetOwnership can involve a multiple quantity.

For another example, consider a timeshare. The underlying property is an OwnedAsset. The timeshare itself is a RentedAsset available for some time interval. Timeshares can be issued for a particular unit but are often tradeable and substitutable by a comparable unit.

10.5 Contract

A Contract is an agreement for the supply of products (Figure 10.9, Figure 10.10). (Section 10.17 discusses Product.) Many Actors (various persons and organizations in a variety of roles) can participate in a contract. Businesses use contracts as a means for conducting commerce. The financial markets use contracts for trading and capture specialized details, such as various kinds of securities, long and short quantities, as well as bid and ask price ranges.

There are various ContractTypes including purchase order, sales order, construction, lease, advertising, and employment.

10.6 Course

A Course is a series of lessons about a subject (Figure 10.11, Figure 10.12). A ListedCourse is an entry in a course catalog and is sponsored by a SchoolDistrict or some other education forum. A ScheduledCourse is a specific offering of a ListedCourse and is delivered by a Teacher at a School using any number of Textbooks. There is a CourseRegistration for each Student who participates in a ScheduledCourse. Note that the Course archetype has two Item Description templates (see Chapter 5). ListedCourse corresponds to ItemDescription and ScheduledCourse corresponds to Item. Similarly, ScheduledCourse corresponds to ItemDescription and CourseRegistration corresponds to Item.

10.7 Customer

A Customer is someone involved in the purchase of products (Figure 10.13, Figure 10.14). Customer reifies the customer role for a TangibleActor (in this case a person or organization, see Section 10.2). Customers are critically important to business and there is special data to collect for them, such as sales data, credit information, and discount schedules. You could use softcoding (see Chapter 13) to capture customer data, but an alternative is to define a distinct Customer entity type as shown here.

10.8 Document

A Document is a physical or electronic representation of a body of information (Figure 10.15, Figure 10.16).

DocumentComposition enables a document to combine lesser documents. For example, a product specification sheet may consist of various paragraphs, pictures, and tables. For a given document, there may be no decomposition, one level of decomposition, or multiple levels of decomposition. DocumentComposition is a directed acyclic graph as some documents are reusable in multiple contexts. Note that DocumentComposition avoids symmetry (see Chapter 8) with the distinction between parent and child.

There is also DocumentFlow. A Document starts out as a concept (ConceptualDoc) and is then expressed in one or more languages (LanguageDoc). For example, a product specification sheet may have English, German, and Japanese translations. LanguageDocs can be parameterized; a SpecificDoc assigns a value to each parameter. For example, a LanguageDoc may have a picture of an electric motor with placeholders (parameters) for length and diameter; the SpecificDoc specifies the actual length and diameter for each motor. And finally a SpecificDoc can be the basis for generating ConvertedDocs in formats such as PDF, HTML, and XML. The model permits meaningless sequences, but this explanation describes the intended flow and application code must enforce a proper sequence.

Thus there is a flow to the progression of documents. Documents start out as concepts, are expressed in various languages, have parameters added, and then are converted into the desired formats.

10.9 Event

An Event is an occurrence at some point in time (Figure 10.17, Figure 10.18). The notion of an event often appears in application models. An EventType is a general category of Events. This archetype involves data and metadata and uses the shading convention from Chapter 5.

EventTypes can be organized into a generalization hierarchy. For example, a superevent could be pressing a key on a keyboard. A subevent would be pressing an alphanumeric key and a further subevent would be pressing the letter X. Sometimes it is helpful to organize the definition of events by their similarities and differences using generalization.

There is also a simple model of cause and effect. A group of causes might lead to a group of effects. By multiple traversals of EventCausality there can be a cascade of events.

10.10 Flight

A Flight is the travel by an airplane between airports (Figure 10.19, Figure 10.20). The Flight archetype is representative of many transportation routing problems. A published flight is the planned travel and an actual flight is the realized travel. The frequency indicates the days of the week for a PublishedFlight. The effectiveDate and expirationDate bracket the time period for which the PublishedFlight is in effect. A PublishedFlightLeg refers to the scheduled travel between airports with one takeoff and landing. (A through flight has multiple legs.)

In contrast, an ActualFlightLeg refers to the actual travel made by an aircraft on a particular date. The actual origin, destination, departure time, and duration can vary because of weather and equipment problems. Normally there is one ActualFlightLeg for a PublishedFlightLeg and departureDate, but flight problems can lead to multiple ActualFlightLegs.

Each AircraftModel has a manufacturer and model number. Each individual Aircraft has a tail number and refers to an AircraftModel. Note that PublishedFlightLeg to ActualFlightLeg and AircraftModel to Aircraft illustrate the Item Description template (see Chapter 5).

10.11 Item

An Item is a part or a service (Figure 10.21, Figure 10.22). A RenderedService is a group of tasks that are performed. In Section 10.14 many PhysicalParts can correspond to a Catalog-Part. Similarly many RenderedServices can correspond to an OfferedService.

An example of an OfferedService is a business audit. Corresponding RenderedServices would be business audits performed on particular dates.

A physical item can break down into lesser physical items, leading to a decomposition tree. The parent-child relationship on PhysicalItem is redundant with the Contains relationship of PhysicalPart (Section 10.14). If PhysicalItem and PhysicalPart are in the same model, you should omit the Contains relationship on PhysicalPart. The PhysicalItem decomposition is broader in scope and subsumes PhysicalPart decomposition. Section 10.14 shows relationships for CatalogPart and PhysicalPart.

10.12 Location

A Location is a physical place in space (Figure 10.23, Figure 10.24).

A Region is a geographical area. A parent Region may contain child Regions. For example, the United States can be divided into states and the states further divided into counties. Alternatively, the United States can be divided into time zones. The division into political units and time zones are two examples of PartitionBasis. Note the use of the Overlapping Tree template (see Chapter 2).

A RegionType is a kind of Region, such as a country, state/province, and county. Region-Types can be organized into a hierarchy ranging from broad to fine categories.

A Facility is a building, a campus, or a part of a building where business can be conducted. The postal address for a location can change; an example is the creation of a new postal code. Furthermore a large building may have multiple postal addresses.

10.13 Opportunity

An Opportunity is an inquiry that can result in business (Figure 10.25, Figure 10.26). Opportunities often arise in the context of sales. Organizations devote many resources to cultivating sales and managing their response to them. Opportunities can be represented with a progression of steps as they progress in the sales cycle. Organizations collect data as an opportunity proceeds.

The subtypes in the model show some possible steps. The precise steps vary by organization. A RawLead begins the sales cycle. After some investigation that the lead is bona fide it is called a QualifiedLead. An opportunity that has closed and culminated in business is called a Deal. OpportunityProgression connects the steps.

10.14 Part

A Part is a specific good that can be described (Figure 10.27, Figure 10.28). A PhysicalPart is a tangible thing while a CatalogPart is a description of a similar group of things. As an example, consider cars. Physical cars have individual serial numbers and each is a facsimile of a car model (Ford Escort, Mazda 626). Customer service records refer to physical cars, while design documents describe car models. A PhysicalPart may have a Batch specified (such as a batch of drugs) for manufacturing traceability.

A catalog part may describe multiple physical parts. Each catalog part and physical part may contain lesser parts. A catalog part may belong to multiple assemblies (because the design of a part is reusable), but a physical part may belong to at most one assembly (because the individual part is consumed in constructing the assembly).

Catalog parts may have a quantity specified within a context of usage. For example, there are left and right windshield wipers and there may also be a wiper on the rear window. A role, such as left windshield, right windshield, and rear window, may be specified to differentiate the various uses of a wiper.

Physical parts may also have a quantity. Parts with serial numbers always have a quantity of one, since each part is individually noted. In contrast, other parts are interchangeable, such as nuts and bolts taken from a bin. Interchangeable parts lack a serial number.

The occurrences for physical parts form a collection of trees. The part at the root of a tree does not belong to any assembly, and all other parts within a tree belong to exactly one assembly.

In contrast, the occurrences for catalog parts form a directed acyclic graph. (See Chapter 3.) An assembly may have multiple components and a component may belong to multiple assemblies.

10.15 Payment

A Payment is the assignment of money in return for something of value (Figure 10.29, Figure 10.30). There are different kinds of payment, each with their own associated data. A check is written against a bank account (see Section 10.1).

10.16 Position

A Position is a job held by someone in an organization (Figure 10.31, Figure 10.32). An Organization can have many Positions and each Position is for a specific Organization.

A Person may hold multiple Positions over time and a Position may be held by multiple Persons. Furthermore, the model permits a Person to hold multiple Positions at the same time (intended) and also allows a Position to be held by multiple Persons at the same time (unintended). In reality, at most one Person can hold a Position at a time and application code must enforce this constraint.

The model does not require that the position structure be a hierarchy, although that is the usual case. The model instead supports matrix management (a Position may report to multiple parent Positions).

10.17 Product

A Product is the packaging of a physical item for a particular marketplace (Figure 10.33, Figure 10.34). For example, a bank can have a checking account service and tailor the service into products for various markets. One product might be an interest-bearing checking account. Another might couple a checking account with discounts for various businesses. A third product might have low fees for students. A product can consist of multiple items.

10.18 Role

A Role is a function played by someone or something (Figure 10.35, Figure 10.36). Each Role corresponds to one Entity and can also have a Relationship. Similarly, each RoleType corresponds to one EntityType and can also have a RelationshipType.

This archetype is an excerpt from a metamodel but the notion of a role often arises for application models. Sometimes it is helpful to have explicit role tables as the Actor and Address archetypes illustrate.

Note that the role archetype has two homomorphisms.

• EntityType to Entity corresponds to RoleType to Role.
• RelationshipType to Relationship corresponds to RoleType to Role.

10.19 Transaction

A Transaction is an exchange that must be completed in its entirety or not at all (Figure 10.37, Figure 10.38). There are two major usages — in finance and in computing.

A financial transaction is an exchange of assets (information, goods, services, money) between two parties. For example, a stock holding might be sold on a stock exchange. A company may split its stock awarding additional shares to the owner as well as money in lieu of partial shares.

A computing transaction (often involving a database) is a group of commands that is treated as a unit of work. All commands must be completed before the transaction is successful. Partial work is not permitted; if the transaction cannot be completed all work is undone.

Each Transaction has a TransactionType that determines the precise processing. A transaction outcome is committed or rolled back. The TransactionElements are either the details of a financial transaction or the constituent commands for a computing transaction.

10.20 Vendor

A Vendor is someone involved in the sale of products (Figure 10.39, Figure 10.40). Vendor reifies the vendor role for a TangibleActor (usually an organization, see Section 10.2). Vendors often have special data to collect, such as supply data, credit information, and order lead time. You could use softcoding (see Chapter 13) to capture vendor data, but an alternative is to define a distinct entity type as shown here.

10.21 Chapter Summary

Archetypes are abstractions that often occur and transcend individual applications. You should keep them in mind as you construct models. Table 10.1 summarizes the archetypes.

Bibliographic Notes

In some regards, this chapter is similar in style to other data pattern books and their emphasis on seed models. The difference is that this chapter emphasizes the core concepts rather than the details that applications add. My purpose is to call attention to concepts that often occur and can be overlooked.

The term archetype is taken from [Arlow-2004]. I had used critical concept in an earlier draft, but there is no point to creating a new term when the literature already has a suitable term.

The actor model is consistent with the literature but is more robust. [Arlow-2004], [Hay-1996], and [Silverston-2001a] define a party as a person or an organization. [Fowler-1997] defines a party as a person, organization, or role type (Fowler's term is post). The model in this book broadens the notion to include roles and applications. The term actor is also consistent with UML terminology.

Chapters 2 and 3 of [Silverston-2009] have an especially good discussion of party (comparable to actor in this book). The authors distinguish between a declarative role (a role that a person or organization plays within an entire enterprise) and a contextual role (a role in a specific relationship).

[Arlow-2004] discusses party roles, but their representation is flawed as there is no need to distinguish between a client and supplier in a party relationship, given that they have a role type. I suspect that the authors are thinking in terms of directed relationships, which is an inferior approach. (See Section 8.7.4.)

[Blaha-1998] has a further discussion of catalog parts and physical parts.

The Wikipedia Web site was helpful for constructing some definitions. Table 10.2 shows significant coverage by other books of the archetypes.

References

[Arlow-2004] Jim Arlow and Ila Neustadt. Enterprise Patterns and MDA: Building Better Software with Archetype Patterns and UML. Boston, Massachusetts: Addison-Wesley, 2004.

[Blaha-1998] Michael Blaha and William Premerlani. Object-Oriented Modeling and Design for Database Applications. Upper Saddle River, New Jersey: Prentice-Hall, 1998.

[Fowler-1997] Martin Fowler. Analysis Patterns: Reusable Object Models. Boston, Massachusetts: Addison-Wesley, 1997.

[Hay-1996] David C. Hay. Data Model Patterns: Conventions of Thought. New York, New York: Dorsett House, 1996.

[Silverston-2001a] Len Silverston. The Data Model Resource Book, Volume 1. New York, New York: Wiley, 2001.

[Silverston-2001b] Len Silverston. The Data Model Resource Book, Volume 2. New York, New York: Wiley, 2001.

[Silverston-2009] Len Silverston and Paul Agnew. The Data Model Resource Book, Volume 3. New York, New York: Wiley, 2009.

[Wikipedia] www.wikipedia.org