For a given document, there may be no decomposition, one level of decomposition, or multiple levels of decomposition.. And final-ly a SpecificDoc can be the basis for generating Convert
Trang 1DocumentComposition 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
parameterValue parameter *
1
*
*
format language
Attribute
name {unique}
Value
value
Trang 2130 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)
Trang 310.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 ActualPublished-FlightLegs 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 1 0 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)
Trang 4132 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
0 1 1 expirationDate flightNumber
PublishedFlightLeg
scheduledDepartureTime scheduledDuration
ActualFlightLeg
actualDepartureTime actualDuration
1 {ordered}
*
departureDate 0 1
*
*
1 1 scheduledOrigin
scheduledDest
tailNumber {unique}
Aircraft
actualOrigin 1 1 actualDestination
*
*
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)
Trang 510.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 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
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)