next up previous contents index
Next: B.5 Table Editor File Up: B TCM File format Previous: B.3 Storage and Document


B.4 Diagram Editor File Format

Figure B.2: Node types and the tools in which they occur.

\includegraphics {p/nodetype.eps}\end{center}\end{figure}

Figure B.3: Edge types and the tools in which they occur.

\includegraphics {p/edgetype.eps}\end{center}\end{figure}

Figure B.4: Node shape types and the tools in which they occur.

\includegraphics {p/nodeshapetype.eps}\end{center}\end{figure}

Figure B.5: Line types and the tools in which they occur.

\includegraphics {p/linetype.eps}\end{center}\end{figure}

Figure B.6: Diagram file format sections seen as a CRD.

\includegraphics {p/fileformat.eps}\end{center}\end{figure}

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.

Node sections

  You can see what node types exist in figure B.2. Each node has a name, annotation and parent field. Some node types have additional fields which are given below.
<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:

Edge sections

  For which edge types are generated by which tools see figure B.3.

<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: When components > 0 then it has for each component a distinct field. This component field should refer to an existing event flow edge. In the current version of TDEFD it is not possible to specify the components of an event flow. Therefore the components fields is always .

View sections

  A view is a set of shapes that represents a sub-diagram. Sub-diagrams are hierarchical and are defined by a parent relationship between nodes. Which shapes exactly may occur in the view is determined by the diagram technique. For instance, in a DFD a view shows the refinement of a data process and in an ERD a view shows the refinement of a subject area. The current version of TCM has no hierarchical sub-diagrams implemented. So there is one single view that contains all the shapes of the diagram.

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.

Node shape sections

  See figure B.4 for which node shape types are made by which tool.
<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.

Line sections

  See figure B.5 for which line type is made by which tool.
<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:

next up previous contents index
Next: B.5 Table Editor File Up: B TCM File format Previous: B.3 Storage and Document
Frank Dehne,Faculty of Mathematics and Computer Science, Vrije Universiteit Amsterdam