File: usersguidenode13.html

package info (click to toggle)
tcm 2.20%2BTSQD-1
links: PTS
area: main
in suites: sarge
size: 20,068 kB
ctags: 17,471
sloc: ansic: 78,531; makefile: 1,343; sh: 1,218; perl: 753; yacc: 558; lex: 260
file content (966 lines) | stat: -rwxr-xr-x 41,081 bytes
parent folder | download | duplicates (9)
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<!--Converted with LaTeX2HTML 98.1p1 release (March 2nd, 1998)
originally by Nikos Drakos (nikos@cbl.leeds.ac.uk), CBLU, University of Leeds
* revised and updated by:  Marcus Hennecke, Ross Moore, Herb Swan
* with significant contributions from:
  Jens Lippmann, Marek Rouchal, Martin Wilck and others -->
<HTML>
<HEAD>
<TITLE>11. TCM File format</TITLE>
<META NAME="description" CONTENT="11. TCM File format">
<META NAME="keywords" CONTENT="User">
<META NAME="resource-type" CONTENT="document">
<META NAME="distribution" CONTENT="global">
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<LINK REL="STYLESHEET" HREF="User.css">
<LINK REL="next" HREF="usersguidenode14.html">
<LINK REL="previous" HREF="usersguidenode12.html">
<LINK REL="up" HREF="User.html">
<LINK REL="next" HREF="usersguidenode14.html">
</HEAD>
<BODY >
<!--Navigation Panel-->
<A NAME="tex2html1163"
 HREF="usersguidenode14.html">
<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next" SRC="next_motif.gif"></A> 
<A NAME="tex2html1159"
 HREF="User.html">
<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up" SRC="up_motif.gif"></A> 
<A NAME="tex2html1153"
 HREF="usersguidenode12.html">
<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous" SRC="previous_motif.gif"></A> 
<A NAME="tex2html1161"
 HREF="usersguidenode1.html">
<IMG WIDTH="65" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="contents" SRC="contents_motif.gif"></A> 
<A NAME="tex2html1162"
 HREF="usersguidenode15.html">
<IMG WIDTH="43" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="index" SRC="index_motif.gif"></A> 
<BR>
<B> Next:</B> <A NAME="tex2html1164"
 HREF="usersguidenode14.html">Bibliography</A>
<B> Up:</B> <A NAME="tex2html1160"
 HREF="User.html">Toolkit for Conceptual Modeling</A>
<B> Previous:</B> <A NAME="tex2html1154"
 HREF="usersguidenode12.html">10. Frequently Asked Questions</A>
<BR>
<BR>
<!--End of Navigation Panel-->
<!--Table of Child-Links-->
<A NAME="CHILD_LINKS"><strong>Subsections</strong></A>
<UL>
<LI><A NAME="tex2html1165"
 HREF="usersguidenode13.html#SECTION001310000000000000000">11.1 Introduction</A>
<LI><A NAME="tex2html1166"
 HREF="usersguidenode13.html#SECTION001320000000000000000">11.2 Elements of a TCM document</A>
<LI><A NAME="tex2html1167"
 HREF="usersguidenode13.html#SECTION001330000000000000000">11.3 Storage, Document and Page Information</A>
<UL>
<LI><A NAME="tex2html1168"
 HREF="usersguidenode13.html#SECTION001330100000000000000">11.3.0.1 Storage section</A>
<LI><A NAME="tex2html1169"
 HREF="usersguidenode13.html#SECTION001330200000000000000">11.3.0.2 Document section</A>
<LI><A NAME="tex2html1170"
 HREF="usersguidenode13.html#SECTION001330300000000000000">11.3.0.3 Page section</A>
<LI><A NAME="tex2html1171"
 HREF="usersguidenode13.html#SECTION001330400000000000000">11.3.0.4 Scale section</A>
</UL>
<LI><A NAME="tex2html1172"
 HREF="usersguidenode13.html#SECTION001340000000000000000">11.4 Diagram Editor File Format</A>
<UL>
<LI><A NAME="tex2html1173"
 HREF="usersguidenode13.html#SECTION001340100000000000000">11.4.0.1 Node sections</A>
<LI><A NAME="tex2html1174"
 HREF="usersguidenode13.html#SECTION001340200000000000000">11.4.0.2 Edge sections</A>
<LI><A NAME="tex2html1175"
 HREF="usersguidenode13.html#SECTION001340300000000000000">11.4.0.3 View sections</A>
<LI><A NAME="tex2html1176"
 HREF="usersguidenode13.html#SECTION001340400000000000000">11.4.0.4 Node shape sections</A>
<LI><A NAME="tex2html1177"
 HREF="usersguidenode13.html#SECTION001340500000000000000">11.4.0.5 Line sections</A>
</UL>
<LI><A NAME="tex2html1178"
 HREF="usersguidenode13.html#SECTION001350000000000000000">11.5 Table Editor File Format</A>
<UL>
<LI><A NAME="tex2html1179"
 HREF="usersguidenode13.html#SECTION001350100000000000000">11.5.0.1 Table section</A>
<LI><A NAME="tex2html1180"
 HREF="usersguidenode13.html#SECTION001350200000000000000">11.5.0.2 Row sections</A>
<LI><A NAME="tex2html1181"
 HREF="usersguidenode13.html#SECTION001350300000000000000">11.5.0.3 Column sections</A>
</UL></UL>
<!--End of Table of Child-Links-->
<HR>

<H1><A NAME="SECTION001300000000000000000">&#160;</A> <A NAME="FileFormat">&#160;</A><A NAME="10510">&#160;</A><A NAME="10511">&#160;</A>
<BR>
11. TCM File format
</H1>

<H1><A NAME="SECTION001310000000000000000">
11.1 Introduction</A>
</H1>
Each TCM document is stored in a separate Unix file 
as plain text. This chapter contains a specification of the TCM 
file format of documents that are generated by the TCM version that
is described in this manual (<A NAME="10513">&#160;</A>file format 
version 1.31). The TCM editors read also older file formats, 
down to file format version 1.0, but they only generate the
latest file format of that TCM tool.
Older file format versions are not described here.
Each file can be converted to the latest format by reading
it in with an editor of the latest version and then saving it 
back to file.

<P>
You can see and even modify a document file within TCM. With
Document Source from the Document menu, the contents of the 
file, from which the TCM document was loaded, is read into a text 
edit dialog. You can then view and edit these file contents 
and save it back to the file (or to another file). You can
see the updates when you append or load that file again.

<P>

<H1><A NAME="SECTION001320000000000000000">
11.2 Elements of a TCM document</A>
</H1>
A document is stored as a number of <B>sections</B><A NAME="10518">&#160;</A>
consisting of a number of <B>fields</B>. The order of fields<A NAME="10520">&#160;</A>
within a section is significant. The order of the sections in 
a diagram file is not significant except that the file should 
start with first the Storage section and then the Document and Page 
sections. The order of the row and column sections of a table is 
significant as is explained in section&nbsp;<A HREF="usersguidenode13.html#TableFormat">C.5</A>.

<P>
A section starts with a keyword indicating the kind of section and, 
when there is possibly more than one section of a certain keyword in the same 
file, it has an identifier which makes the section unique within 
the file. The rest of the section is enclosed by curly braces. 
Sections are separated by white space. <B>white space</B> is a sequence
of one or more spaces, tabs, carriage-return or newline characters.

<P>
A field is an attribute-value pair enclosed by curly<A NAME="10523">&#160;</A>
braces. The order of the fields in a section is significant.
Attribute values are of one of the types listed in figure&nbsp;<A HREF="usersguidenode13.html#attrval">C.1</A>.
Fields within a section are separated by white space.
The attribute name and the value within a field are also 
separated by white space. Section names and attribute names 
are case sensitive.

<P>
It is possible to include comment text in a TCM file.
Comments in a file start with a hash (#). The text in the same line 
after the hash is comment text and is ignored.

<P>
<BR>
<DIV ALIGN="CENTER"><A NAME="attrval">&#160;</A><A NAME="10528">&#160;</A>
<TABLE WIDTH="50%">
<CAPTION><STRONG>Figure C.1:</STRONG>
The value types of attributes stored in a file.</CAPTION>
<TR><TD>
<DIV ALIGN="CENTER">

<!-- MATH: $\includegraphics{p/valuetypes.eps}$ -->
<IMG
 WIDTH="503" HEIGHT="895" ALIGN="BOTTOM" BORDER="0"
 SRC="usersguideimg229.gif"
 ALT="\includegraphics{p/valuetypes.eps}"></DIV></TD></TR>
</TABLE>
</DIV>
<BR>
<P>
When a file is read, TCM checks the syntax and checks
the semantics, i.e. that all required fields are present, that
the attribute values have the correct type and it checks references
(such as that an edge section has subject fields referring to existing 
subject sections). TCM reports errors that are found together with 
a line number in the file where the error is encountered.
The errors are displayed in the error log pop-up-window.

<P>

<H1><A NAME="SECTION001330000000000000000">
11.3 Storage, Document and Page Information</A>
</H1>
Each TCM document in a file starts with the Storage section 
with information about the file such as the file format number.
This is followed by the Document section in which you can find 
general information about the document, like the name and the 
author. Then you have the Page section with some information about 
the page layout and then the Scale section that contains (only) the
scale of the diagram.

<P>

<H3><A NAME="SECTION001330100000000000000">&#160;</A><A NAME="10534">&#160;</A>
<BR>
11.3.0.1 Storage section
</H3>
<PRE>
Storage 
{
   { Format &lt;rational&gt; }   # File format, e.g. 1.26.
   { GeneratedFrom &lt;word&gt; }# Tool name and version e.g. TGD-version-1.84.
   { WrittenBy &lt;word&gt; }    # Unix login name that has generated this file.
   { WrittenOn &lt;string&gt; }  # Writing date/time (in Unix ctime format).
}
</PRE>
<H3><A NAME="SECTION001330200000000000000">&#160;</A><A NAME="10538">&#160;</A>
<BR>
11.3.0.2 Document section
</H3><PRE>
Document
{
    { Type &lt;string&gt; }      # Document type: e.g. "Generic Diagram".
    { Name &lt;word&gt; }        # Document name, e.g. mydocument.gd.
    { Author &lt;word&gt; }      # Unix login name of document creator.
    { CreatedOn &lt;string&gt; } # Creation time 
                           # e.g. "Wed Sep 24 15:42:47 MET DST 1997".
    { Annotation &lt;string&gt; }# Free annotation text about this document.
    { Hierarchy &lt;bool&gt; }   # For diagram types that allow hierarchic
                           # documents only: Is this document hierarchic?
}
</PRE>

<H3><A NAME="SECTION001330300000000000000">&#160;</A><A NAME="10542">&#160;</A>
<BR>
11.3.0.3 Page section
</H3><PRE>
Page
{
    { PageOrientation &lt;word&gt; } # Portrait or Landscape
    { PageSize &lt;word&gt; }        # PageSize: A4, A3, Letter, Legal,...
    { ShowHeaders &lt;bool&gt; }     # Show a header on every page?
    { ShowFooters &lt;bool&gt; }     # Show a footer on every page?
    { ShowNumbers &lt;bool&gt; }     # Show a page number on every page?
}
</PRE>

<H3><A NAME="SECTION001330400000000000000">&#160;</A><A NAME="10546">&#160;</A>
<BR>
11.3.0.4 Scale section
</H3><PRE>
Scale
{
    { ScaleValue &lt;rational&gt; }  # The scale of the diagram. Normally 1.00.
}
</PRE>

<P>

<H1><A NAME="SECTION001340000000000000000">
11.4 Diagram Editor File Format</A>
</H1>

<P>
<BR>
<DIV ALIGN="CENTER"><A NAME="nodetype">&#160;</A><A NAME="10553">&#160;</A>
<TABLE WIDTH="50%">
<CAPTION><STRONG>Figure C.2:</STRONG>
Node types and the tools in which they occur.</CAPTION>
<TR><TD>
<DIV ALIGN="CENTER">

<!-- MATH: $\includegraphics{p/nodetype.eps}$ -->
<IMG
 WIDTH="587" HEIGHT="1045" ALIGN="BOTTOM" BORDER="0"
 SRC="usersguideimg230.gif"
 ALT="\includegraphics{p/nodetype.eps}"></DIV></TD></TR>
</TABLE>
</DIV>
<BR>
<P>
<BR>
<DIV ALIGN="CENTER"><A NAME="edgetype">&#160;</A><A NAME="10560">&#160;</A>
<TABLE WIDTH="50%">
<CAPTION><STRONG>Figure C.3:</STRONG>
Edge types and the tools in which they occur.</CAPTION>
<TR><TD>
<DIV ALIGN="CENTER">

<!-- MATH: $\includegraphics{p/edgetype.eps}$ -->
<IMG
 WIDTH="571" HEIGHT="650" ALIGN="BOTTOM" BORDER="0"
 SRC="usersguideimg231.gif"
 ALT="\includegraphics{p/edgetype.eps}"></DIV></TD></TR>
</TABLE>
</DIV>
<BR>
<P>
<BR>
<DIV ALIGN="CENTER"><A NAME="nodeshapetype">&#160;</A><A NAME="10567">&#160;</A>
<TABLE WIDTH="50%">
<CAPTION><STRONG>Figure C.4:</STRONG>
Node shape types and the tools in which they occur.</CAPTION>
<TR><TD>
<DIV ALIGN="CENTER">

<!-- MATH: $\includegraphics{p/nodeshapetype.eps}$ -->
<IMG
 WIDTH="578" HEIGHT="848" ALIGN="BOTTOM" BORDER="0"
 SRC="usersguideimg232.gif"
 ALT="\includegraphics{p/nodeshapetype.eps}"></DIV></TD></TR>
</TABLE>
</DIV>
<BR>
<P>
<BR>
<DIV ALIGN="CENTER"><A NAME="linetype">&#160;</A><A NAME="10574">&#160;</A>
<TABLE WIDTH="50%">
<CAPTION><STRONG>Figure C.5:</STRONG>
Line types and the tools in which they occur.</CAPTION>
<TR><TD>
<DIV ALIGN="CENTER">

<!-- MATH: $\includegraphics{p/linetype.eps}$ -->
<IMG
 WIDTH="320" HEIGHT="375" ALIGN="BOTTOM" BORDER="0"
 SRC="usersguideimg233.gif"
 ALT="\includegraphics{p/linetype.eps}"></DIV></TD></TR>
</TABLE>
</DIV>
<BR>
<P>
<BR>
<DIV ALIGN="CENTER"><A NAME="FileFormatCRD">&#160;</A><A NAME="10581">&#160;</A>
<TABLE WIDTH="50%">
<CAPTION><STRONG>Figure C.6:</STRONG>
Diagram file format in the form of a class-diagram.</CAPTION>
<TR><TD>
<DIV ALIGN="CENTER">

<!-- MATH: $\includegraphics{p/fileformat.eps}$ -->
<IMG
 WIDTH="585" HEIGHT="761" ALIGN="BOTTOM" BORDER="0"
 SRC="usersguideimg234.gif"
 ALT="\includegraphics{p/fileformat.eps}"></DIV></TD></TR>
</TABLE>
</DIV>
<BR>
<P>
A stored diagram contains a section for each node, edge, view and
shape (in no particular order) which follow after the three obligatory 
storage, document and page sections. Each node type, edge type and shape 
type section starts with a keyword. A view has the keyword <TT>View</TT>.
In figures&nbsp;<A HREF="usersguidenode13.html#nodetype">C.2</A> to&nbsp;<A HREF="usersguidenode13.html#linetype">C.5</A> 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&nbsp;<A HREF="usersguidenode13.html#FileFormatCRD">C.6</A> 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.

<P>

<H3><A NAME="SECTION001340100000000000000">&#160;</A><A NAME="10590">&#160;</A>
<BR>
11.4.0.1 Node sections
</H3>
You can see what node types exist in figure&nbsp;<A HREF="usersguidenode13.html#nodetype">C.2</A>.
Each node has a name, annotation and parent field. Some node
types have additional fields which are mentioned below.<PRE>
&lt;NodeType&gt; &lt;id&gt;                     # e.g. EntityType 123456.
{
    { Name &lt;string&gt; }               # name label of the node.
    { Annotation &lt;string&gt; }         # annotation text of the node.
    { Parent &lt;id&gt; }                 # parent node (always 0 in this TCM version).
    { Index &lt;string&gt; }              # index label of the node.
    # possibly other node attributes
}
</PRE>

<P>
The parent field is not used in the current TCM
version but it will be used for hierarchical diagrams. 
In hierarchical diagrams the parent identifier refers to an existing node 
section. That would mean that a node in a diagram is 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 
0 (which means they have no parent). 
Furthermore, in sub-diagrams, shapes representing higher level nodes may 
also occur. In the generic editor, TGD, these structures will be almost 
unconstrained. In data flow diagram editors (TDFD and TEFD) and 
data view editors (TERD and 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 can also used in the tree editors (TFRT, TGTT) 
but here the entire hierarchy is presented in one view.

<P>
When the parent relationship is not used in some editor then the entire 
diagram is treated as a top-level diagram and the parents of the subjects 
are always set to 0.
In the current version of TCM there are only top-level diagrams
so the parent fields are always 0.

<P>
Other attributes of node types are:
<UL>
<LI>DataProcess (TDFD, TEFD)<PRE>
    { ProcessGroup &lt;bool&gt; }          # is data process a process group?
    # possibly other data process attributes #
</PRE>
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&nbsp;<A NAME="tex2html249"
 HREF="#foot10708"><SUP>11.1</SUP></A> 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:<PRE>
    { Persistence &lt;persistence&gt; }    # Instantaneous or Continuing
    { Minispec &lt;string&gt; }            # Mini specification text
    # possibly other leaf node data process attributes #
</PRE>
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: <PRE>
    { ActivationMechanism &lt;activation&gt; } # only when Instantaneous
    # possibly other discrete leaf node data process attributes #
</PRE>
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,  the following stimulus field is
added:<PRE>
    { Stimulus &lt;string&gt; }       # input edge name; 
                                # only if activated by stimulus
</PRE>
Otherwise when it is activated by time, a TimeExpression field is given instead:<PRE>
    { TimeExpression &lt;string&gt; } # only when activated by time
</PRE>
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. 

<P>
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.

<P>
<LI>DataStore (TDFD, TEFD)<PRE>
    { AtomicSubjects &lt;number&gt; } # number of entities/relationships
    { AtomicSubject &lt;string&gt; }  # entities/relationships (&gt;= 1 fields)
</PRE>
In a future version of TDFD and TEFD you will be able to specify the 
contents of data stores. For the moment the number of atomic subjects is 
always set to 0.

<P>
<LI>InitialState (TSTD)<PRE>
    { ControlProcess &lt;string&gt; }# the control process.
    { Actions &lt;number&gt; }       # number of actions of initial state.
    { Action &lt;string&gt; }        # initial action (&gt;= 1 action fields).
</PRE>
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).

<P>
<LI>ClassNode (TCRD), SSDClassNode (TSSD, TESD)<PRE>
    { Attributes &lt;number&gt; }     # number of attributes of class.
    { Attribute &lt;string&gt; }      # attribute string (&gt;= 1 fields).
    { Operations &lt;number&gt; }     # number of operations of class.
    { Operation &lt;string&gt; }      # operation string (&gt;= 1 fields).
</PRE>
The number of attributes specifies how many attribute fields follow 
and the number of operations specifies how many operation fields follow.
Each attribute and each operation is a single-line string.
The class nodes in TSSD have after the operations also the following
two attributes:<PRE>
    { Stereotype &lt;string&gt; }     # class stereotype string.
    { Properties &lt;string&gt; }     # class properties string.
</PRE>

<P>
<LI>SSDObjectNode (TSSD)<PRE>
    { Attributes &lt;number&gt; }     # number of attributes of object node.
    { Attribute &lt;string&gt; }      # attribute string (&gt;= 1 fields).
</PRE>
Object nodes in TSSD do not have operations.
<LI>PSProcess (TPSD)<PRE>
    { Operator &lt;string&gt; }       # process operator, e.g. "*"
    { IsRoot &lt;bool&gt; }           # is it a root process ?
    { IsAction &lt;bool&gt; }         # is it an action (leaf) process ?
    { Sequence &lt;number&gt; }       # sequence number in process tree.
</PRE>
The process operator is always a string of length 1 (when the process
has no operator the string is a single space).

<P>
</UL>
<P>

<H3><A NAME="SECTION001340200000000000000">&#160;</A><A NAME="10621">&#160;</A>
<BR>
11.4.0.2 Edge sections
</H3>
For which edge types are generated by which tools see figure&nbsp;<A HREF="usersguidenode13.html#edgetype">C.3</A>.

<P><PRE>
&lt;EdgeType&gt; &lt;id&gt;                # e.g. BinaryRelationship 654321
{
    { Name &lt;string&gt; }          # name of edge.
    { Annotation &lt;string&gt; }    # annotation of edge.
    { Parent &lt;id&gt; }            # parent node.
    { Subject1 &lt;id&gt; }          # 'departure' subject
    { Subject2 &lt;id&gt; }          # 'arrival' subject
    # possibly other edge attributes #
}
</PRE>
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 0.
The Subject1 and Subject2 identifiers should refer to existing 
subject sections in this file. It is in principle possible
that and edge (line) connects another edge (line).
At this moment this feature of edge-edge connections is
only available in TGD and in a limited form in TSSD (for
association link edges and connection of notes).

<P>
The other attributes of edge types:
<UL>
<LI>BinaryRelationship (TERD,TCRD), 
SSDBinaryAssociationEdge (TSSD,TESD), SSDAggregationEdge (TSSD), 
SSDCompositionEdge (TSSD), UCDBinaryAssociationEdge (TUCD)<PRE>
    { Constraint1 &lt;string&gt; }   # first cardinality constraint.
    { Constraint2 &lt;string&gt; }   # second cardinality constraint.
    { RoleName1 &lt;string&gt; }     # first role name.
    { RoleName2 &lt;string&gt; }     # second role name.
</PRE>

<P>
<LI>ClassLinkEdge, ObjectLinkEdge (TCBD) <PRE>
    { Constraint1 &lt;string&gt; }   # first cardinality constraint.
    { Constraint2 &lt;string&gt; }   # second cardinality constraint.
    { RoleName1 &lt;string&gt; }     # first role name.
    { RoleName2 &lt;string&gt; }     # second role name.
    { Messages &lt;number&gt; }      # number of messages of edge.
    { Message &lt;string&gt; }       # message string (&gt;= 1 message fields)
    { Direction &lt;direction&gt; }  # message direction (ToShape, FromShape)	(&gt;= 1)
    { Flow &lt;flow type&gt; }       # flow type (FlatFlow, NestedFlow, Asynchronous) (&gt;= 1)
</PRE>

<P>
<LI>Function (TERD, TCRD), ComponentFunction (TCRD), 
ConnectionStart (TSND), ConnectionEnd (TSND)<PRE>
    { Constraint &lt;string&gt; }    # cardinality constraint.
</PRE>

<P>
<LI>SSDObjectLinkEdge (TSSD)<PRE>
    { RoleName1 &lt;string&gt; }    # first role name.
    { RoleName2 &lt;string&gt; }    # second role name.
</PRE>

<P>
<LI>SSDParticipantLinkEdge (TSSD, TESD)<PRE>
    { Constraint &lt;string&gt; }  # cardinality constraint.
    { RoleName &lt;string&gt; }    # role name.
</PRE>

<P>
<LI>Transition (TSTD)<PRE>
    { Event &lt;string&gt; }         # event string (including condition).
    { Actions &lt;number&gt; }       # number of actions in transition.
    { Action &lt;string&gt; }        # action string (&gt;= 1 action fields).
</PRE>
The actions field specifies how many action fields follow.
Each action string is a single line text string.

<P>
<LI>DataFlow (TDFD, TEFD), BidirectionalDataFlow (TDFD, TEFD), 
ContinuousDataFlow (TEFD)<PRE>
    { Components &lt;number&gt; }    # number of sub-flows
    { Component &lt;id&gt; }         # sub-flow (&gt;= 1 component fields)
</PRE>
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 0. When the flow has no components then it has a certain 
data contents:

<P><PRE>
    { ContentType &lt;contenttype&gt; } # AtomicSubject, Attribute, 
                                  # DataType or Unspecified
</PRE>
This field is only present when components is 0. This field is by default
unspecified. It is not possible to set this field in the current
version of TDFD or TEFD. When the ContentType is not unspecified then 
according to the content type it has <I>one</I> of these three fields:<PRE>
    { AtomicSubject &lt;string&gt; } # entity type/relationship name.
    { Attribute &lt;attribute&gt; }  # attribute of an atomic subject.
    { DataType &lt;datatype&gt; }    # values of a simple data type.
</PRE>
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.

<P>
<LI>EventFlow (TEFD), ContinuousEventFlow (TEFD)<PRE>
    { Components &lt;number&gt; }    # number of sub-flows
    { Component &lt;id&gt; }         # sub-flow (&gt;= 1 component fields)
</PRE>
</UL>When components &gt; 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 TEFD it is not possible to specify
the components of an event flow. Therefore the components fields is
always 0.

<P>

<H3><A NAME="SECTION001340300000000000000">&#160;</A><A NAME="10649">&#160;</A>
<BR>
11.4.0.3 View sections
</H3>
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, a view in a DFD shows the refinement of 
a data process and a view in an ERD 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.

<P><PRE>
View &lt;id&gt;
{
    { Index &lt;word&gt; }           # index of hierarchical view.
    { Parent &lt;id&gt; }            # the parent node of the view.
}
</PRE>
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 0. The
children of the top-level view are numbered 1 to <I>n</I>, the children of
non-top-level view x have index <I>x</I>.1 to <I>x</I>.<I>n</I>. Each view, except the
top-level view, has a parent node. The parent field should refer to
an existing node section. The top-level view has as parent 0.
The diagrams of the current version of TCM have only a top-level view.
The indexes of the individual nodes are stored separately in the node
section. The reason is that not all nodes need to have an index, and
in some editors a different naming scheme could be used (for instance,
in TGD, nodes can have an arbitrary index label and in TDFD, data stores
do not have an index label).

<P>
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.

<P>

<H3><A NAME="SECTION001340400000000000000">&#160;</A><A NAME="10653">&#160;</A>
<BR>
11.4.0.4 Node shape sections
</H3>
See figure&nbsp;<A HREF="usersguidenode13.html#nodeshapetype">C.4</A> for which node shape types are
made by which tool.<PRE>
&lt;NodeShapeType&gt; &lt;id&gt;               # e.g. Box 214365
{
    { View &lt;id&gt; }                  # view in which the shape occurs.
    { Subject &lt;id&gt; }               # the node that the shape represents.
    { Position &lt;number&gt; &lt;number&gt; } # center (x,y) position of shape.
    { Size &lt;number&gt; &lt;number&gt; }     # width and height of shape.
    { Color &lt;color&gt; }              # the line color of the shape.
    { LineWidth &lt;number&gt; }         # the line width of the shape.
    { LineStyle &lt;linestyle&gt; }      # the line style of the shape.
    { FillStyle &lt;fillstyle&gt; }      # the way the shape is filled.
    { FillColor &lt;color&gt; }          # the fill color when the shape not unfilled.
    { FixedName &lt;bool&gt; }           # string of name-textshape is fixed?
    { Font &lt;xlfd&gt; }                # text font of text strings.
    { TextAlignment &lt;alignment&gt; }  # multi-line text alignment.
    { TextColor &lt;color&gt; }          # the color of the text in the shape.
    { NameUnderlined &lt;bool&gt; }      # name-textshape is underlined?
}
</PRE>
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 the node shape section but it is equal to the name of the node
subject, but some other attributes of the labels, i.e. the font and 
text alignment are specified in this section.

<P>
Node shapes have a (line) color, a text color, and a fill color (only visible
with a fill style that is not unfilled). By default the line color and 
text color are black, the shape is unfilled and the line width is 1.

<P>
The node shapes SSDSingleClassBox, SSDDoubleClassBox and SSDTripleClassBox 
in TSSD and TESD have additionally the following two attributes to 
indicate whether the stereotype and properties labels of the subject 
should be shown: <PRE>
    { ShowStereotype &lt;bool&gt; }
    { ShowProperties &lt;bool&gt; }
</PRE>

<P>

<H3><A NAME="SECTION001340500000000000000">&#160;</A><A NAME="10660">&#160;</A>
<BR>
11.4.0.5 Line sections
</H3>
See figure&nbsp;<A HREF="usersguidenode13.html#linetype">C.5</A> for which line type is made by which tool.<PRE>
&lt;LineType&gt; &lt;id&gt;                       # e.g. Arrow 563412
{
    { View &lt;id&gt; }                     # diagram in which the shape occurs.
    { Subject &lt;id&gt; }                  # edge that the line represents.
    { FromShape &lt;id&gt; }                # 'departure' shape.
    { ToShape &lt;id&gt; }                  # 'arrival' shape.
    { Curved &lt;bool&gt; }                 # straight (False) or curved (True)
    { End1 &lt;line-end&gt; }               # type of line end at departure side.
    { End2 &lt;line-end&gt; }               # type of line end at arrival side.
    { Points &lt;number&gt; }               # number of line points
    { Point &lt;number&gt; &lt;number&gt; }       # line point (&gt;=2 points).
    { NamePosition &lt;number&gt; &lt;number&gt; }# position of name label.
    { Color &lt;color&gt; }                 # the color of the line (default=black).
    { LineWidth &lt;number&gt; }            # the width of the line (default=1).
    { LineStyle &lt;linestyle&gt; }         # the style (solid, dashed etc.).
    { FixedName &lt;bool&gt; }              # string of name-textshape is fixed?
    { Font &lt;xlfd&gt; }                   # text font of text labels.
    { TextAlignment &lt;alignment&gt; }     # multi-line text alignment.
    { TextColor &lt;color&gt; }             # the color of the text (default=black).
    { NameUnderlined &lt;bool&gt; }         # name-textshape is underlined?
    # possibly other line attributes 
}
</PRE>
Each line is contained in an existing view and represents
an existing edge and connects two existing (not necessarily different)
shapes, called FromShape and ToShape. 
Both at the beginning point as at the end point of the line there is
some <B>line end</B><A NAME="10665">&#160;</A> which can be some kind of arrow head or 
a little circle, diamond or triangle or the line end is just Empty. 
The Points field in the line section specifies how many 
point fields will follow. A line has at least two points. Each point
has a distinct Point field.
The name position field gives the coordinates of the name label.
The text of this label can be found in the edge section of the subject,
in its Name field. Because the labels of a line can be positioned at free will, 
whereas node shape labels can not, only line sections have a 
distinct name position field. For the rest, line sections have a number 
of fields that also occur in node shape section, like for the colors, text 
alignment and line width. Extra attributes for some specific line types are:

<P>
<UL>
<LI>T1Arrow (TSND), T1Line (TERD, TCRD, TSND)<PRE>
    { T1Position &lt;number&gt; &lt;number&gt; }  # position of an extra label.
</PRE>
<LI>SSDRCLine (TSSD, TESD)<PRE>
    { T1Position &lt;number&gt; &lt;number&gt; }  # position of 1st extra label.
    { T2Position &lt;number&gt; &lt;number&gt; }  # position of 2nd extra label.
</PRE>
<LI>SSDR2Line (TSSD)<PRE>
    { T1Position &lt;number&gt; &lt;number&gt; }  # position of 1st extra label.
    { T2Position &lt;number&gt; &lt;number&gt; }  # position of 2nd extra label.
    { NameDirection &lt;namedirection&gt;}  # direction to read the name.
</PRE>

<P>
<LI>C2R2Line (TERD, TCRD, TSSD, TESD, TUCD)<PRE>
    { T1Position &lt;number&gt; &lt;number&gt; }  # position of 1st extra label.
    { T2Position &lt;number&gt; &lt;number&gt; }  # position of 2nd extra label.
    { T3Position &lt;number&gt; &lt;number&gt; }  # position of 3rd extra label.
    { T4Position &lt;number&gt; &lt;number&gt; }  # position of 4th extra label.
    { NameDirection &lt;namedirection&gt;}  # direction to read the name.
</PRE>
These labels can also be positioned at free will and therefore their 
positions are saved separately.

<P>
<LI>C2R2MListLine (TCBD)<PRE>
    { T1Position &lt;number&gt; &lt;number&gt; }  # position of 1st extra label.
    { T2Position &lt;number&gt; &lt;number&gt; }  # position of 2nd extra label.
    { T3Position &lt;number&gt; &lt;number&gt; }  # position of 3rd extra label.
    { T4Position &lt;number&gt; &lt;number&gt; }  # position of 4th extra label.
    { NameDirection &lt;namedirection&gt;}  # direction to read the name.
    { Messages &lt;number&gt; }             # number of message labels.
    { TnPosition &lt;number&gt; &lt;number&gt; }  # position of xth message label.  
                                        (&gt;= 1 message label fields)
</PRE>
These labels can also be positioned at free will and therefore their 
positions are saved separately.

<P>
<LI>TransitionArrow (TSTD)<PRE>
    { AnchorPoint &lt;number&gt; &lt;number&gt; } # connection point with separator.
    { Separator  &lt;direction&gt; }        # relative position of separator
    { LineNumber &lt;number&gt; }           # line segment to which separator 
                                      # belongs (number&gt;=1).
</PRE>
The transition arrow 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.
</UL>
<P>

<H1><A NAME="SECTION001350000000000000000">&#160;</A> <A NAME="TableFormat">&#160;</A><A NAME="10682">&#160;</A>
<BR>
11.5 Table Editor File Format
</H1>

<P>
Like diagrams, the table editor file format starts first with a
Storage section and then a Document section and a Page section.
Directly after the Page section follows the Table section with
some attributes of the entire table.

<P>

<H3><A NAME="SECTION001350100000000000000">&#160;</A><A NAME="10684">&#160;</A>
<BR>
11.5.0.1 Table section
</H3><PRE>
Table {
    { TopLeft &lt;number&gt; &lt;number&gt; }    # top-left (x,y) of entire table.
    { NumberOfRows &lt;number&gt; }        # nr. of rows in table (cells per column).
    { NumberOfColumns &lt;number&gt; }     # nr. of columns in table (cells per row).
    { MarginWidth &lt;number&gt; }         # min. distance text and column line.
    { MarginHeight &lt;number&gt; }        # min. distance text and line.
}
</PRE>
In an earlier version of TCM other attributes where stored as well such 
as DefaultLineStyle, DefaultRowAlignment, DefaultColumnAlignment etc. but they are now treated as attributes of the table editor itself
not of a table stored in a file.

<P>

<H3><A NAME="SECTION001350200000000000000">&#160;</A><A NAME="10688">&#160;</A>
<BR>
11.5.0.2 Row sections
</H3>
After the Table section follow the row sections in consecutive 
order (they are numbered from 0 to NumberOfRows-1).
Each row section starts with the following three attributes:<PRE>
Row &lt;number&gt; {
    { Height &lt;number&gt; }           # all cells in row have the same height.
    { Alignment &lt;alignment&gt; }     # all texts in row have the same alignment.
    { NumberOfCells &lt;number&gt; }    # a row having n cells has n+1 lines
    ... rest of the row attributes.
}
</PRE>
The NumberOfCells of a row has to be equal to the NumberOfColumns field in 
the table section. This field indicates how many cells the rows contain.
The rest of the row attributes consist of the attributes of the cells
and lines (line pieces) in a row.
The line pieces to the left and to the right of the cells in a row are seen 
as part of the row too. For each line piece a separate line style and width field
are stored. About the cell itself, the cell text string, the fonts 
and some annotation text is stored. So for every cell the following information
is stored:

<P><PRE>
    ...
    { LineStyle &lt;linestyle&gt; }        # Line style of the line piece
    { LineWidth &lt;number&gt; }           # Line width of the line piece
    { Text &lt;string&gt; }                # texts in a cell.
    { Font &lt;xlfd&gt; }                  # XLFD font description.
    { Annotation &lt;string&gt; }          # annotation text of this cell.
    ...
}
</PRE>

<P>
The size of the cell is determined by the sizes of its row and column.
Text alignment of a cell is determined by the combined row and 
column alignment. In a row section, the two line fields and the three 
cell fields alternate and, because the number of line pieces is the
number of cells plus one, the row always end with two extra fields
for the line style and line width of the last line piece.

<P>

<H3><A NAME="SECTION001350300000000000000">&#160;</A><A NAME="10694">&#160;</A>
<BR>
11.5.0.3 Column sections
</H3>
After the Table section follow the column sections (numbered from 0 to NumberOfColumns-1):<PRE>
Column &lt;number&gt; {
    { Width &lt;number&gt; }          # all cells in column have the same width.
    { Alignment &lt;alignment&gt; }   # all texts in column have the same alignment.
    { NumberOfCells &lt;number&gt; }  # a column having n cells has n+1 lines
    ...
}
</PRE>

<P>
The NumberOfCells of a column has to be equal to the NumberOfRows field in
the table section. Because the cell texts are already specified in the row
sections, a column section only needs the line style and width fields for
horizontal line pieces. There are NumberOfCells+1 line style and width fields 
in a column. Therefore the rest of the column section consists of 
NumberOfRows+1 times the following two attributes:

<P><PRE>
    ...
    { LineStyle &lt;linestyle&gt; }        # line style of a line piece
    { LineWidth &lt;number&gt; }           # line width of a line piece
    ...
</PRE>

<P>
<FONT SIZE="-1">
<A NAME="biblio">&#160;</A></FONT>
<BR><HR><H4>Footnotes</H4>
<DL>
<DT><A NAME="foot10708">... group&nbsp;</A><A NAME="foot10708"
 HREF="usersguidenode13.html#tex2html249"><SUP>11.1</SUP></A>
<DD>A process group is 
also called a <I>compound process</I>
or a <I>decomposed process</I>.

</DL><HR>
<!--Navigation Panel-->
<A NAME="tex2html1163"
 HREF="usersguidenode14.html">
<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next" SRC="next_motif.gif"></A> 
<A NAME="tex2html1159"
 HREF="User.html">
<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up" SRC="up_motif.gif"></A> 
<A NAME="tex2html1153"
 HREF="usersguidenode12.html">
<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous" SRC="previous_motif.gif"></A> 
<A NAME="tex2html1161"
 HREF="usersguidenode1.html">
<IMG WIDTH="65" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="contents" SRC="contents_motif.gif"></A> 
<A NAME="tex2html1162"
 HREF="usersguidenode15.html">
<IMG WIDTH="43" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="index" SRC="index_motif.gif"></A> 
<BR>
<B> Next:</B> <A NAME="tex2html1164"
 HREF="usersguidenode14.html">Bibliography</A>
<B> Up:</B> <A NAME="tex2html1160"
 HREF="User.html">Toolkit for Conceptual Modeling</A>
<B> Previous:</B> <A NAME="tex2html1154"
 HREF="usersguidenode12.html">10. Frequently Asked Questions</A>
<!--End of Navigation Panel-->
<ADDRESS>
<I>Henk van de Zandschulp</I>
<BR><I>2003-01-20</I>
</ADDRESS>
</BODY>
</HTML>