A stored diagram has a section for each node, edge, view and shape (in no particular order) which follow after the required Storage and Document section. Each node type, edge type and shape type has its own keyword. A view has the keyword View. In figures B.3 to B.5 you can see which keywords (and accessory sections) are generated and read by which tool. After the node, edge, view or shape keyword there is an identifier which is unique within the file. These identifiers are used for referring from one section to another section. Figure B.6 gives an overview of the global structure of the diagram file format in which file format section types are represented as object classes. The CRD does not show the significant order of the fields in a section. On the other hand, the CRD shows specializations and other relationships between classes and also some cardinality constraints which can not be made explicit in the file format sections. Specific node sections would be subclasses of class Node, specific edge sections would be subclasses of class Edge and specific Shape sections would be subclasses of classes NodeShape or Line.
<NodeType> <id> # e.g. EntityType 123456.
{
{ Name <string> } # name of the node.
{ Annotation <string> } # annotation text of node.
{ Parent <id> } # parent node, always 0 in current TCM version.
# possibly other node attributes
}
The parent field is not used in the current TCM version but it will be used for hierarchical diagrams. The parent identifier refers to an existing node section. The idea is the following: a node in a diagram can be further specified as a sub-diagram. The newly created nodes and edges in that sub-diagram have that node as parent. Nodes and edges in the top-level diagram have parent (which means they have no parent). Furthermore, in sub-diagrams, shapes representing higher level nodes may also occur. In TGD these structures will be almost unconstrained. In TDFD (TDEFD) and TERD (TCRD) these structures are more constrained, for instance only data processes respectively subject areas can be parent nodes and flows respectively relationships have to be balanced. The parent relationship is also used in the tree editors (TFRT, TGTT) but here the entire hierarchy is presented in one view. In some other editors like TSTD the parent relationship will remain unused (at least in YSM) and in that case the entire diagram is treated as a top-level diagram and the parents of the subjects are always set to . In the current version of TCM there is also only a top-level diagram so the parent fields are always .
Other attributes of node types are:
{ Index <word> } # index label, e.g. 1.2.2
{ Index <word> } # index label, e.g. 1.2.2
{ ProcessGroup <bool> } # is data process a process group?
# possibly other data process attributes #
In this version of TCM, the process group field is always False (because
hierarchical DFDs are not implemented yet). When the data process would be
a process group ![[*]](foot_motif.gif)
then it is parent of a number of children
(processes, stores, flows and/or split-merge nodes.). When the data process
is not a process group then it is a primitive process and then the process
has the following attributes:
{ Persistence <persistence> } # Instantaneous or Continuing
{ Minispec <string> } # Mini specification text
# possibly other leaf node data process attributes #
In this version of TCM it is possible to set the persistence (by default it
is instantaneous) and to edit a minispec text, but they are further not used.
When the persistence is instantaneous then the data process section contains
the field:
{ ActivationMechanism <activation> } # only when Instantaneous
# possibly other discrete leaf node data process attributes #
The activation mechanism can be set in the current
DFD editors (by default it is unspecified). When the instantaneous
data process is activated by a stimulus then a stimulus field follows:
{ Stimulus <string> } # input edge name; only if activated by stimulus
Otherwise when it is activated by time, a TimeExpression field is given instead:
{ TimeExpression <string> }# only when activated by time
The activation mechanism can also be Trigger. The trigger
edge is then not given in this section but there should be
an input edge labeled `T' to this process.
So it is possible to set the activation mechanism and specify a stimulus or time expression and this information is written to file but it is further not used in the current version of TCM.
{ AtomicSubjects <number> } # number of entities/relationships
{ AtomicSubject <string> } # entities/relationships (>= 1 fields)
In a future version of TDFD and TDEFD you will be able to specify the
contents of data stores. For the moment the number of atomic subjects is
always set to .
{ ControlProcess <string> }# the control process.
{ Actions <number> } # number of actions of initial state.
{ Action <string> } # initial action (>= 0 action fields).
In the current version of TSTD the name of the control process can
not be specified. So the control process field contains an empty string.
The number of actions specifies how many initial action fields follow.
Actions are arbitrary single line strings (they cannot contain
a newline).
{ Attributes <number> } # number of attributes of object type
{ Attribute <string> } # attribute string (>= 0 fields).
{ Actions <number> } # number of actions of object type.
{ Action <string> } # action string (>= 0 fields).
The number of attributes specifies how many attribute fields follow
and the number of actions specifies how many action fields follow.
Each attribute and each action is a single-line string.
{ Operator <string> } # process operator, e.g. "*"
{ IsRoot <bool> } # is it a root process ?
{ IsAction <bool> } # is it an action (leaf) process ?
{ Sequence <number> } # sequence number in process tree.
The process operator is always a string of length 1 (when the process
has no operator the string is a single space).
<EdgeType> <id> # e.g. BinaryRelationship 654321
{
{ Name <string> } # name of edge.
{ Annotation <string> } # annotation of edge.
{ Parent <id> } # parent node.
{ Node1 <id> } # 'departure' node
{ Node2 <id> } # 'arrival' node
# possibly other edge attributes #
}
Edge types also have a parent field which is intended
to be used for hierarchical editors that are still to be build.
For the moment the Parent identifier is always .
The Node1 and Node2 identifiers should refer to existing node
sections in this file. The other attributes of edge types:
{ Constraint1 <string> } # first cardinality constraint.
{ Constraint2 <string> } # second cardinality constraint.
{ RoleName1 <string> } # first role name.
{ RoleName2 <string> } # second role name.
{ Constraint <string> } # cardinality constraint.
{ Event <string> } # event string (including condition).
{ Actions <number> } # number of actions in transition.
{ Action <string> } # action string (>= 0 action fields).
The actions field specifies how many action fields follow.
Each action string is a single line text string.
{ Components <number> } # number of sub-flows
{ Component <id> } # sub-flow (>= 0 fields)
When the components field is greater than zero then it has for each
component a distinct field.
This component field should refer to an existing data flow edge section.
In the current version of TCM it is not yet possible to specify
the components of a data flow. Therefore the components field is
always . When the flow has no components then it has a certain
data contents:
{ ContentType <contenttype> } # AtomicSubject, Attribute, DataType or Unspecified
This field is only present when components is . This field is by default
unspecified. It is not possible to set this field in the current
version of TDFD or TDEFD. When the ContentType is not unspecified then
according to the content type it has one of these three fields:
{ AtomicSubject <string> } # entity type/relationship name.
{ Attribute <attribute> } # attribute of an atomic subject.
{ DataType <datatype> } # values of a simple data type.
But again, these fields cannot be filled in by the current version of TCM.
Therefore data flow sections have no component fields and they have
Unspecified as content type.
{ Components <number> } # number of sub-flows
{ Component <id> } # sub-flow (>= 0 fields)
View <id>
{
{ Index <word> } # index of hierarchical view.
{ Parent <id> } # the parent node of the view.
}
The index of a view is the same kind of unique index that is used for
data and control processes. The top-level view has index . The
children of the top-level view are numbered 1 to n, the children of
non-top-level view x have index x.1 to x.n. Each view except the
top-level view has a parent node. The parent field therefore refers to
an existing node section. The top-level view has as parent .
The diagrams of the current version of TCM have only a top-level view.
The shapes that are contained in the view are not listed in the view section itself. But all shape sections have a reference to the view section in which they are contained.
<NodeShapeType> <id> # e.g. Box 214365
{
{ View <id> } # view in which the shape occurs.
{ Subject <id> } # the node that the shape represents.
{ Position <number> <number> } # center (x,y) position of shape.
{ Size <number> <number> } # width and height of shape.
{ Font <xlfd> } # text font of text strings.
{ TextAlignment <alignment> } # multi-line text alignment.
}
Each node shape is contained in an existing view and represents
an existing node. The name label of the node shape is not given
in this section but it is equal to the name of the node
subject, but attributes of the labels, i.e. the font and text alignment
are specified in this section. The current node shape sections do
not have other attributes than the ones that are given above.
<LineType> <id> # e.g. Arrow 563412
{
{ View <id> } # diagram in which the shape occurs.
{ Subject <id> } # edge that the line represents.
{ End1 <id> } # 'departure' node shape.
{ End2 <id> } # 'arrival' node shape.
{ Curved <bool> } # straight (False) or curved (True)
{ Points <number> } # number of line points
{ Point <number> <number> } # line point (>=2 points).
{ NamePosition <number> <number> }# position of name label.
{ Font <xlfd> } # text font of text labels.
{ TextAlignment <alignment> } # multi-line text alignment.
# possibly other line attributes
}
Each line is contained in an existing view and represents
an existing edge and connects two existing node shapes.
The points field specifies how many point fields follow.
A line has at least two points.
The name position field gives the position of the name label.
The text of the label can be found in the edge section.
Because line labels can be positioned at free will, whereas
node shape labels can not, only line sections have a name
position field. Other attributes of line types are:
{ C1Position <number> <number> } # position of constraint label.
{ C1Position <number> <number> } # position of 1st constraint label.
{ C2Position <number> <number> } # position of 2nd constraint label.
{ R1Position <number> <number> } # position of 1st role name label.
{ R2Position <number> <number> } # position of 2nd role name label.
These constraint and role name labels can also be positioned at free
will and therefore their positions are saved too.
{ AnchorPoint <number> <number> } # connection point with line.
{ Separator <direction> } # relative position of separator
{ LineNumber <number> } # (>=1) line segment to which separator belongs.
The HLineArrow is the presentation of a transition edge in a STD.
The separator field indicates whether the separator is above, below,
to the left or to the right of the transition arrow. When it is to
the left or right, the anchor point is the point where the
separator line is connected to the arrow. When it is above or below,
the anchor point is simply the middle of the separator line. Note
that the length of the separator line is determined by the lengths
of the event and action labels and it is not stored separately.
The line number indicates the line segment to which the
separator line belongs. The highest numbered line segment has
the arrow head of the transition.