10.8 Document 129
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 docu-
ments 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 specifi-
cation sheet may have English, German, and Japanese translations. LanguageDocs can be
parameterized; a SpecificDoc assigns a value to each parameter. For example, a Language-
Doc 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 final-
ly a SpecificDoc can be the basis for generating ConvertedDocs in formats such as PDF,
Figure 10.14 Archetype Customer: IDEF1X model.
tangibleActorID
TangibleActor
. . .
customerID
Customer
salesData
creditInformation
discountSchedules
tangibleActorID (FK) (AK1.1)
DocumentFlow
Figure 10.15 Archetype Document: UML model. A Document is a physical
or electronic representation of a body of information.
Document
name
creationDate
size

comment
ConceptualDoc LanguageDoc SpecificDoc ConvertedDoc
DocumentComposition
*
*
*
0 1
parent
child
parent
child
parameterValueparameter
*
1
*
*
1
*
formatlanguage
Attribute
name {unique}
Value
value
130 Chapter 10 / Archetypes
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.
Figure 10.16 Archetype Document: IDEF1X model.
documentDiscrim
documentID
Document
documentName
creationDate
size
comment
LanguageDoc
languageDocID (FK)
language
ConceptualDoc
conceptualDocID (FK)
ConvertedDoc
convertedDocID (FK)
format
SpecificDoc
specificDocID (FK)
documentDiscrim
DocComposition
parentDocID (FK)

childDocID (FK)
parentDocID (FK)
attributeID
Attribute
attributeName (AK1.1)
valueID
Value
value
specificDocID (FK)
attributeID (FK)
LangDoc_parameter
languageID (FK)
parameterID (FK)
10.10 Flight 131
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 peri-
od 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 par-
ticular date. The actual origin, destination, departure time, and duration can vary because of
weather and equipment problems. Normally there is one ActualFlightLeg for a Published-
FlightLeg 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 ActualFlight-
Leg and AircraftModel to Aircraft illustrate the Item Description template (see Chapter 5).
Figure 10.17 Archetype Event: UML model. An Event is an occurrence
at some point in time.

Event
datetime
*
1
EventCausality
cause effect
**
**
0 10 1
1
*
subevent superevent
EventGeneralization
EventType
name {unique}
Figure 10.18 Archetype Event: IDEF1X model.
eventGeneralizationID
EventGeneralization
superEventTypeID (FK) (AK1.1)
eventCausalityID
EventCausality
eventID
Event
datetime
eventTypeID
EventCausality_cause
eventCausalityID (FK)
causeEventID (FK)
EventCausality_effect
eventCausalityID (FK)

effectEventID (FK)
eventTypeID
EventType
eventTypeName (AK1.1)
eventGeneralizationID (FK)
132 Chapter 10 / Archetypes
Figure 10.19 Archetype Flight: UML model. A Flight is the travel by
an airline between airports.
modelNumber {unique}
manufacturer
AircraftModel
PublishedFlight
frequency
effectiveDate
airlineCode {unique}
airlineName
Airline
*
1
0 11
expirationDate
flightNumber
PublishedFlightLeg
scheduledDepartureTime
scheduledDuration
ActualFlightLeg
actualDepartureTime
actualDuration
1
{ordered}

*
departureDate
0 1
*
*
1
1
scheduledOrigin
scheduledDest
tailNumber {unique}
Aircraft
actualOrigin actualDestination11
*
*
1
*
1
*
iataCode {unique}
airportName
Airport
*
{ordered}
Figure 10.20 Archetype Flight: IDEF1X model.
publishedFlightID
PublishedFlight
frequency
effectiveDate
expirationDate
aircraftModelID (FK)

airlineID (FK) (AK1.1)
flightNumber (AK1.2)
publishedFlightLegID
PublishedFlightLeg
scheduledDepartureTime
scheduledDuration
publishedFlightID (FK) (AK1.1)
sequenceNumber (AK1.2)
scheduledOrigin (FK)
scheduledDestination (FK)
actualFlightLegID
ActualFlightLeg
actualDepartureTime
actualDuration
publishedFlightLegID (FK) (AK1.1)
departureDate (AK1.2)
sequenceNumber (AK1.3)
airlineID
Airline
airlineCode (AK1.1)
airlineName
aircraftModelID
AircraftModel
modelNumber (AK1.1)
manufacturer
aircraftID
Aircraft
tailNumber (AK1.1)
aircraftModelID (FK)
airportID

Airport
iataCode (AK1.1)
airportName
actualOrigin (FK)
actualDestination (FK)
aircraftID (FK)
10.11 Item 133
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-
Par t. 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 relation-
ship of PhysicalPart (Section 10.14). If PhysicalItem and PhysicalPart are in the same mod-
el, 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.
RenderedService
Figure 10.21 Archetype Item: UML model. An Item is a part or a service.
PhysicalItem
parent
child
*
0 1
quantity
startDatetime
PhysicalPart
OfferedService

name
CatalogPart
0 1
*
endDatetime
CatalogItem
Figure 10.22 Archetype Item: IDEF1X model.
catalogItemDiscrim
catalogItemID
CatalogItem
catalogItemDiscrim
OfferedService
offeredServiceID (FK)
offeredServiceName
CatalogPart
catalogPartID (FK)
physicalItemDiscrim
physicalItemID
PhysicalItem
physicalItemDiscrim
RenderedService
renderedServiceID (FK)
startDatetime
PhysicalPart
physicalPartID (FK)
endDatetime
offeredServiceID (FK)
. . . . . .
parPhyItem_childPhyItem
childPhyItemID (FK)

quantity
parentPhyItemID (FK)