14.2 Diagram Subject Area 187
14.2 Diagram Subject Area
A generic diagram is a picture that conveys the meaning of the underlying model. Figure
14.3 and Figure 14.4 support discrete tabs for attaching lines. The gray shading is for entity
types that involve metadata.
An Icon is a picture that is symbolic of something. Examples of Icons include an oval in
a data flow diagram and a compressor symbol in an equipment flow diagram. Each Icon has
a name, as well as a scale and position that are applied to its corresponding IconType. For ex-
ample, Figure 14.2 has two Icons for heat exchangers (IconTypes). One Icon is named “Evap-
orator” and the other Icon is named “Condenser”. Each Icon belongs to a specific Diagram.
Figure 14.1 Example: Data flow diagram for designing a database (no ports).
reqmts
prepare
reqmts
UML
UML
model
prepare
IDEF1X
IDEF1X
model
generate
SQL
DDL
SQL
DDL
SQL
design database
model model
DDL
Figure 14.2 Example: Equipment flow diagram for an air conditioner (with ports).

E1:Expansion valve
C1:Compressor
CondenserEvaporator
refrigerant
outside air
tube
out
tube
in
tube
in
tube
out
warm air cool air
inout
in out
188 Chapter 14 / Generic Diagrams
Figure 14.3 Diagram subject area, with tabs: UML model. A generic diagram
is a picture that suggests the meaning of the underlying model.
Icon
name {unique}
Diagram
name
1
*
scale
position
IconType
DiagramType
*

Tab
name
scale
position
1
*
Line
11source target
TabType
1
*
LineType
1
*
1
1
*
*
1
1
*
0 10 1
Figure 14.4 Diagram subject area, with tabs: IDEF1X model.
iconID
Icon
iconName (AK1.1)
scale
position
iconTypeID
IconType

. . .
diagramID
Diagram
diagramName
diagramTypeID (FK)
iconTypeID (FK)
diagramID (FK)
diagramTypeID
DiagramType
. . .
tabID
Tab
tabName
scale
position
iconID (FK)
tabTypeID (FK)
lineID
Line
lineTypeID (FK)
diagramID (FK)
sourceTabID (FK) (AK1.1)
targetTabID (FK) (AK2.1)
tabTypeID
TabType
. . .
lineTypeID
LineType
. . .
14.3 Model Subject Area 189

A Tab is a discrete position on an Icon for attaching a Line. A Tab has a name, as well
as a scale and position that are applied to its corresponding TabType. The relationships be-
tween Tab and Line illustrate the Node–Edge directed graph (see Chapter 3). The relation-
ships between Icon, IconType, Ta b, and TabType form a homomorphism (see Chapter 5).
A Line is a means for coupling two Tabs. A Diagram is a set of Icons and Lines. Section
14.5 defines DiagramType, IconType, Tab Type, and LineType.
Figure 14.5 and Figure 14.6 forego Tabs and permit lines to connect anywhere on an
Icon.
14.3 Model Subject Area
A semantic diagram has a model that expresses the meaning. Figure 14.7 and Figure 14.8
show the model with discrete ports.
Figure 14.5 Diagram subject area, no tabs: UML model.
Icon
name {unique}
Diagram
name
1
*
scale
position
IconType
DiagramType
*
Line
11
**
source target
LineType
1
*

1
1
*
*
1
iconTypeID
IconType
. . .
Figure 14.6 Diagram subject area, no tabs: IDEF1X model.
iconID
Icon
iconName (AK1.1)
scale
position
diagramID
Diagram
diagramName
diagramTypeID (FK)
iconTypeID (FK)
diagramID (FK)
lineID
Line
lineTypeID (FK)
diagramID (FK)
sourceIconID (FK)
targetIconID (FK)
lineTypeID
LineType
. . .
diagramTypeID

DiagramType
. . .
190 Chapter 14 / Generic Diagrams
Figure 14.7 Model subject area, with ports: UML model. A semantic
diagram has an underlying model that expresses the meaning.
Entity
name
EntityType
name {unique}
*
1
SimpleEntityExpandableEntity
PortType
name {unique}
1
*
Port
name
*
1
1
*
Model
1
*
1
*
Connection
0 1
0 1

1
1
input
output
ExpansionMapping
1
*
1
*
inner outer11
0 1
0 1
subModel
name
Figure 14.8 Model subject area, with ports: IDEF1X model.
entityDiscrim
entityID
Entity
entityName
entityDiscrim
entityTypeID (FK)
ExpandableEntity
expandableEntityID (FK)
submodelID (FK)
SimpleEntity
simpleEntityID (FK)
entityTypeID
EntityType
entityTypeName (AK1.1)
portTypeID

PortType
portTypeName (AK1.1)
entityTypeID (FK)
modelID (FK)
portID
Port
portName
portTypeID (FK)
entityID (FK)
connectionID
Connection
modelID (FK)
inputPortID (FK) (AK1.1)
outputPortID (FK) (AK2.1)
expansionMappingID
ExpansionMapping
expandableEntityID (FK)
innerPortID (FK) (AK1.1)
outerPortID (FK) (AK2.1)
modelID
Model
modelName
14.3 Model Subject Area 191
An Entity is a thing with semantic meaning. Examples of Entities include a data flow in
a data flow diagram and a piece of equipment in an equipment flow diagram. An Entity can
be represented by an Icon in a generic diagram. An Entity name may or may not be unique
within a model.
A Port is a defined place for an Entity, available for a connection. Just as Icons have
Ta bs , so too Entities have Ports. For example, an expansion valve has inlet and outlet ports.
An Entity has many Ports and each Por t belongs to a specific Entity.

An Entity may have multiple Ports with the same name. For example, a piping tee has
two outputs that are interchangeable (and consequently have the same name). A minimum
value function could have up to ten inputs and one output that is the minimum value.
Ports are helpful for some kinds of models and unnecessary for others. If a diagram
omits Ports , then connections go directly to Entities.
An EntityType is a classification of Entities. For example, E101 (an Entity) is a heat ex-
changer (an EntityType). The EntityType specifies the kinds of ports (PortType) that apply.
It would be clumsy to define ports individually. It is better to define them for an Entity-
Type. Thus, an EntityType can have PortTypes. A PortType is a classification of Ports. Each
PortTy p e belongs to a specific EntityType. Then each Entity defines Ports corresponding to
the PortTypes for its EntityType. Such a mechanism enforces uniformity. Note that the rela-
tionships among Entity, EntityType, Port, and PortType form a homomorphism (see Chapter
5).
A Model is a set of Entities and Connections and has a meaning that a diagram illus-
trates. Each Entity and Connection belong to a single Model. Some of the Entities in a Model
are ExpandableEntities and lead to submodels. Hence Models can be structured as a hierar-
chy of arbitrary depth.
There are two kinds of Entities: ExpandableEntities and SimpleEntities. An Expand-
ableEntity provides a placeholder for a submodel. In an implementation, double clicking the
corresponding icon leads to the expansion into a lower-level diagram. As Figure 14.1 illus-
trates, some Entities can be expanded into submodels with a finer level of detail. A submodel
is reusable and can be embedded in multiple places. A SimpleEntity encompasses all other
Entities that do not lead to a submodel.
A Connection is a binding between an input Port and an output Port. A Port may, or
may not, have a Connection. The various Connections establish the direction of flow through
Ports . Port and Connection illustrate the Node–Edge directed graph (see Chapter 3).
The ExpansionMapping takes a Po rt on an interface (outer Port for an ExpandableEn-
tity) and couples it to a Port (an inner Port) within the corresponding subModel. A Po rt may
participate in one ExpansionMapping as an inner Port, one ExpansionMapping as an outer
Port, or in no ExpansionMapping at all. The inner Port must belong to an Entity that is di-

rectly contained within the subModel.
Figure 14.9 and Figure 14.10 simplify the Model subject area and permit Connections
anywhere on an Entity.