~ubuntu-branches/ubuntu/utopic/tcm/utopic : contents of doc/usersguide/usersguidenode11.html at revision 1

~ubuntu-branches/ubuntu/utopic/tcm/utopic : (revision 1)
<!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>9. Mini-tutorial on Notation Techniques</TITLE>
<META NAME="description" CONTENT="9. Mini-tutorial on Notation Techniques">
<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="usersguidenode12.html">
<LINK REL="previous" HREF="usersguidenode10.html">
<LINK REL="up" HREF="User.html">
<LINK REL="next" HREF="usersguidenode12.html">
</HEAD>
<BODY >
<!--Navigation Panel-->
<A NAME="tex2html1041"
 HREF="usersguidenode12.html">
<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next" SRC="next_motif.gif"></A> 
<A NAME="tex2html1037"
 HREF="User.html">
<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up" SRC="up_motif.gif"></A> 
<A NAME="tex2html1031"
 HREF="usersguidenode10.html">
<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous" SRC="previous_motif.gif"></A> 
<A NAME="tex2html1039"
 HREF="usersguidenode1.html">
<IMG WIDTH="65" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="contents" SRC="contents_motif.gif"></A> 
<A NAME="tex2html1040"
 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="tex2html1042"
 HREF="usersguidenode12.html">10. Frequently Asked Questions</A>
<B> Up:</B> <A NAME="tex2html1038"
 HREF="User.html">Toolkit for Conceptual Modeling</A>
<B> Previous:</B> <A NAME="tex2html1032"
 HREF="usersguidenode10.html">8. Tree Editing</A>
<BR>
<BR>
<!--End of Navigation Panel-->
<!--Table of Child-Links-->
<A NAME="CHILD_LINKS"><strong>Subsections</strong></A>
<UL>
<LI><A NAME="tex2html1043"
 HREF="usersguidenode11.html#SECTION001110000000000000000">9.1 Structured Analysis Notations</A>
<UL>
<LI><A NAME="tex2html1044"
 HREF="usersguidenode11.html#SECTION001111000000000000000">9.1.1 Entity-Relationship Diagrams (TESD)</A>
<UL>
<LI><A NAME="tex2html1045"
 HREF="usersguidenode11.html#SECTION001111100000000000000">9.1.1.1 Entity types</A>
<LI><A NAME="tex2html1046"
 HREF="usersguidenode11.html#SECTION001111200000000000000">9.1.1.2 Binary relationships</A>
<LI><A NAME="tex2html1047"
 HREF="usersguidenode11.html#SECTION001111300000000000000">9.1.1.3 Cardinality properties</A>
<LI><A NAME="tex2html1048"
 HREF="usersguidenode11.html#SECTION001111400000000000000">9.1.1.4 Relationships of higher arity</A>
<LI><A NAME="tex2html1049"
 HREF="usersguidenode11.html#SECTION001111500000000000000">9.1.1.5 Attributes</A>
<LI><A NAME="tex2html1050"
 HREF="usersguidenode11.html#SECTION001111600000000000000">9.1.1.6 Associative entities</A>
<LI><A NAME="tex2html1051"
 HREF="usersguidenode11.html#SECTION001111700000000000000">9.1.1.7 Is-a relationships</A>
</UL>
<LI><A NAME="tex2html1052"
 HREF="usersguidenode11.html#SECTION001112000000000000000">9.1.2 Data and Event Flow Diagrams (TEFD)</A>
<UL>
<LI><A NAME="tex2html1053"
 HREF="usersguidenode11.html#SECTION001112100000000000000">9.1.2.1 The components of a DFD</A>
<LI><A NAME="tex2html1054"
 HREF="usersguidenode11.html#SECTION001112200000000000000">9.1.2.2 Hierarchical DFDs</A>
<LI><A NAME="tex2html1055"
 HREF="usersguidenode11.html#SECTION001112300000000000000">9.1.2.3 Control processes</A>
<LI><A NAME="tex2html1056"
 HREF="usersguidenode11.html#SECTION001112400000000000000">9.1.2.4 Event flows</A>
<LI><A NAME="tex2html1057"
 HREF="usersguidenode11.html#SECTION001112500000000000000">9.1.2.5 Time-Discrete and time-continuous flows</A>
</UL>
<LI><A NAME="tex2html1058"
 HREF="usersguidenode11.html#SECTION001113000000000000000">9.1.3 State Transition Diagrams (TSTD)</A>
<LI><A NAME="tex2html1059"
 HREF="usersguidenode11.html#SECTION001114000000000000000">9.1.4 Transaction-Use Tables (TTUT)</A>
<LI><A NAME="tex2html1060"
 HREF="usersguidenode11.html#SECTION001115000000000000000">9.1.5 Function-Entity Type Tables (TFET)</A>
<LI><A NAME="tex2html1061"
 HREF="usersguidenode11.html#SECTION001116000000000000000">9.1.6 Function Refinement Trees (TFRT)</A>
</UL>
<LI><A NAME="tex2html1062"
 HREF="usersguidenode11.html#SECTION001120000000000000000">9.2 UML Notations</A>
<UL>
<LI><A NAME="tex2html1063"
 HREF="usersguidenode11.html#SECTION001121000000000000000">9.2.1 Use case diagrams (TUCD)</A>
<UL>
<LI><A NAME="tex2html1064"
 HREF="usersguidenode11.html#SECTION001121100000000000000">9.2.1.1 Actors</A>
<LI><A NAME="tex2html1065"
 HREF="usersguidenode11.html#SECTION001121200000000000000">9.2.1.2 Use cases</A>
</UL>
<LI><A NAME="tex2html1066"
 HREF="usersguidenode11.html#SECTION001122000000000000000">9.2.2 Static structure diagrams (TSSD)</A>
<UL>
<LI><A NAME="tex2html1067"
 HREF="usersguidenode11.html#SECTION001122100000000000000">9.2.2.1 Stereotypes and properties</A>
<LI><A NAME="tex2html1068"
 HREF="usersguidenode11.html#SECTION001122200000000000000">9.2.2.2 Behavior</A>
<LI><A NAME="tex2html1069"
 HREF="usersguidenode11.html#SECTION001122300000000000000">9.2.2.3 Objects</A>
</UL>
<LI><A NAME="tex2html1070"
 HREF="usersguidenode11.html#SECTION001123000000000000000">9.2.3 Activity diagrams (TATD)</A>
<UL>
<LI><A NAME="tex2html1071"
 HREF="usersguidenode11.html#SECTION001123100000000000000">9.2.3.1 Activity</A>
<LI><A NAME="tex2html1072"
 HREF="usersguidenode11.html#SECTION001123200000000000000">9.2.3.2 Transition</A>
<LI><A NAME="tex2html1073"
 HREF="usersguidenode11.html#SECTION001123300000000000000">9.2.3.3 Choice nodes</A>
<LI><A NAME="tex2html1074"
 HREF="usersguidenode11.html#SECTION001123400000000000000">9.2.3.4 Fork and join nodes</A>
<LI><A NAME="tex2html1075"
 HREF="usersguidenode11.html#SECTION001123500000000000000">9.2.3.5 Initial and final state</A>
</UL>
<LI><A NAME="tex2html1076"
 HREF="usersguidenode11.html#SECTION001124000000000000000">9.2.4 Statechart diagrams (TSCD)</A>
<LI><A NAME="tex2html1077"
 HREF="usersguidenode11.html#SECTION001125000000000000000">9.2.5 Collaboration diagrams (TCBD)</A>
<UL>
<LI><A NAME="tex2html1078"
 HREF="usersguidenode11.html#SECTION001125100000000000000">9.2.5.1 Messages</A>
</UL>
<LI><A NAME="tex2html1079"
 HREF="usersguidenode11.html#SECTION001126000000000000000">9.2.6 Component diagrams (TCPD)</A>
<LI><A NAME="tex2html1080"
 HREF="usersguidenode11.html#SECTION001127000000000000000">9.2.7 Deployment diagrams (TDPD)</A>
</UL>
<LI><A NAME="tex2html1081"
 HREF="usersguidenode11.html#SECTION001130000000000000000">9.3 Miscellaneous Notations</A>
<UL>
<LI><A NAME="tex2html1082"
 HREF="usersguidenode11.html#SECTION001131000000000000000">9.3.1 Classic Entity-Relationship Diagrams (TERD)</A>
<UL>
<LI><A NAME="tex2html1083"
 HREF="usersguidenode11.html#SECTION001131100000000000000">9.3.1.1 Entity types</A>
<LI><A NAME="tex2html1084"
 HREF="usersguidenode11.html#SECTION001131200000000000000">9.3.1.2 Binary relationships</A>
<LI><A NAME="tex2html1085"
 HREF="usersguidenode11.html#SECTION001131300000000000000">9.3.1.3 Cardinality constraints</A>
<LI><A NAME="tex2html1086"
 HREF="usersguidenode11.html#SECTION001131400000000000000">9.3.1.4 Relationships of higher arity</A>
<LI><A NAME="tex2html1087"
 HREF="usersguidenode11.html#SECTION001131500000000000000">9.3.1.5 Value types</A>
<LI><A NAME="tex2html1088"
 HREF="usersguidenode11.html#SECTION001131600000000000000">9.3.1.6 Attributes</A>
<LI><A NAME="tex2html1089"
 HREF="usersguidenode11.html#SECTION001131700000000000000">9.3.1.7 Is-a relationships</A>
</UL>
<LI><A NAME="tex2html1090"
 HREF="usersguidenode11.html#SECTION001132000000000000000">9.3.2 Class-Relationship Diagrams (TCRD)</A>
<UL>
<LI><A NAME="tex2html1091"
 HREF="usersguidenode11.html#SECTION001132100000000000000">9.3.2.1 Classes</A>
<LI><A NAME="tex2html1092"
 HREF="usersguidenode11.html#SECTION001132200000000000000">9.3.2.2 Relationships</A>
<LI><A NAME="tex2html1093"
 HREF="usersguidenode11.html#SECTION001132300000000000000">9.3.2.3 Is-a relationships</A>
</UL>
<LI><A NAME="tex2html1094"
 HREF="usersguidenode11.html#SECTION001133000000000000000">9.3.3 Data Flow Diagrams (TDFD)</A>
<LI><A NAME="tex2html1095"
 HREF="usersguidenode11.html#SECTION001134000000000000000">9.3.4 Process Structure Diagrams (TPSD)</A>
<LI><A NAME="tex2html1096"
 HREF="usersguidenode11.html#SECTION001135000000000000000">9.3.5 System Network Diagrams (TSND)</A>
<LI><A NAME="tex2html1097"
 HREF="usersguidenode11.html#SECTION001136000000000000000">9.3.6 Recursive Process Graphs (TRPG)</A>
<LI><A NAME="tex2html1098"
 HREF="usersguidenode11.html#SECTION001137000000000000000">9.3.7 Transaction Decomposition Tables (TTDT)</A>
</UL></UL>
<!--End of Table of Child-Links-->
<HR>

<H1><A NAME="SECTION001100000000000000000">&#160;</A>
<A NAME="MiniTut">&#160;</A><A NAME="8283">&#160;</A><A NAME="8284">&#160;</A>
<BR>
9. Mini-tutorial on Notation Techniques
</H1>

<P>
This appendix contains a short tutorial on the use of
the notation techniques that are supported by TCM.
Detailed information on the notations of structured analysis and 
the UML is given in R.J. Wieringa, <EM>Design
Methods for reactive Systems: Yourdon, Statemate and the UML</EM>,
Department of Computer Science, University of Twente,
1999.
The miscellaneous notations are documented in&nbsp;[<A
 HREF="usersguidenode14.html#Wieringa96-01">22</A>].

<P>

<H1><A NAME="SECTION001110000000000000000">
9.1 Structured Analysis Notations</A>
</H1>

<P>

<H2><A NAME="SECTION001111000000000000000">&#160;</A><A NAME="TUT-ESD">&#160;</A><A NAME="8290">&#160;</A>
<BR>
9.1.1 Entity-Relationship Diagrams (TESD)
</H2>

<P>
The TCM convention for TESD is described in detail
in&nbsp;[<A
 HREF="usersguidenode14.html#Wieringa99-01">23</A>].

<P>

<H3><A NAME="SECTION001111100000000000000">&#160;</A><A NAME="8293">&#160;</A>
<BR>
9.1.1.1 Entity types
</H3>

<P>
As usual, a named rectangle represents a named entity type.

<P>

<H3><A NAME="SECTION001111200000000000000">&#160;</A><A NAME="8295">&#160;</A>
<BR>
9.1.1.2 Binary relationships
</H3>

<P>
Binary relationships are presented by lines.

<P>

<H3><A NAME="SECTION001111300000000000000">&#160;</A><A NAME="8297">&#160;</A>
<BR>
9.1.1.3 Cardinality properties
</H3>

<P>
Cardinality properties are represented by
annotations placed at the end points of these lines.
(Cardinality properties are also called ``cardinality constraints''
by many authors.)
<BR>
<DIV ALIGN="CENTER"><A NAME="fig.ESDcard">&#160;</A><A NAME="8900">&#160;</A>
<TABLE WIDTH="50%">
<CAPTION><STRONG>Figure A.1:</STRONG>
The placement of Cardinality constraints.</CAPTION>
<TR><TD><IMG
 WIDTH="424" HEIGHT="42"
 SRC="usersguideimg176.gif"
 ALT="\begin{figure}
\centerline{\epsfig{figure=p/ESDcard.eps}} %
%
\end{figure}"></TD></TR>
</TABLE>
</DIV>
<BR>
For example, in figure&nbsp;<A HREF="usersguidenode11.html#fig.ESDcard">A.1</A>, each business has an employment
relationship to more than zero persons and each person has 0 or 1
employment relationships to a business.
The end points of the line can also be annotated with the role that the
entity at that end of the line plays in the relationship.
Figure&nbsp;<A HREF="usersguidenode11.html#fig.ESDroles">A.2</A> gives an example.<A NAME="8304">&#160;</A>
<BR>
<DIV ALIGN="CENTER"><A NAME="fig.ESDroles">&#160;</A><A NAME="8902">&#160;</A>
<TABLE WIDTH="50%">
<CAPTION><STRONG>Figure A.2:</STRONG>
The placement of role names.</CAPTION>
<TR><TD><IMG
 WIDTH="435" HEIGHT="39"
 SRC="usersguideimg177.gif"
 ALT="\begin{figure}
\centerline{\epsfig{figure=p/ESDroles.eps}} %
%
\end{figure}"></TD></TR>
</TABLE>
</DIV>
<BR>

<P>
<BR>
<DIV ALIGN="CENTER"><A NAME="fig.ESDcon">&#160;</A><A NAME="8904">&#160;</A>
<TABLE WIDTH="50%">
<CAPTION><STRONG>Figure A.3:</STRONG>
The meaning of cardinality properties.</CAPTION>
<TR><TD><IMG
 WIDTH="308" HEIGHT="39"
 SRC="usersguideimg178.gif"
 ALT="\begin{figure}
\centerline{\epsfig{figure=p/ESDcon.eps}} %
%
\end{figure}"></TD></TR>
</TABLE>
</DIV>
<BR>
In general, a cardinality property is represented by a set of natural
numbers (see figure&nbsp;<A HREF="usersguidenode6.html#ESDCardSyntax">4.9</A> for the syntax).
For example, if <I>c</I> is a set of natural numbers, the property
in figure&nbsp;<A HREF="usersguidenode11.html#fig.ESDcon">A.3</A> is that each instance of <I>E1</I> is related
to <I>n</I> instances of <I>E2</I>, where <IMG
 WIDTH="29" HEIGHT="28" ALIGN="MIDDLE" BORDER="0"
 SRC="usersguideimg179.gif"
 ALT="$n \in$">
<I>c</I>. 
(More precisely,
each <EM>existing</EM> instance of <I>E1</I> is related
to <I>n</I> <EM>existing</EM> instances of <I>E2</I>.)
If no cardinality property is shown, the convention is that <I>c</I> is
the entire set of natural numbers.
For example, in figure&nbsp;<A HREF="usersguidenode11.html#fig.ERDcon">A.25</A>, each instance of <I>E2</I> is
related 
to any number instances of <I>E1</I>.
This includes the case that it is related to 0 instances of <I>E1</I>.

<P>
<BR>
<DIV ALIGN="CENTER"><A NAME="fig.ESDreverse">&#160;</A><A NAME="8906">&#160;</A>
<TABLE WIDTH="50%">
<CAPTION><STRONG>Figure A.4:</STRONG>
The line representation of binary relationships is direction-independent.</CAPTION>
<TR><TD><IMG
 WIDTH="378" HEIGHT="39"
 SRC="usersguideimg180.gif"
 ALT="\begin{figure}
\centerline{\epsfig{figure=p/ESDreverse.eps}} %
%
\end{figure}"></TD></TR>
</TABLE>
</DIV>
<BR>
Note that there is no natural reading direction for a
relationship name.
For example, figure&nbsp;<A HREF="usersguidenode11.html#fig.ESDreverse">A.4</A> conveys the same information as
figure&nbsp;<A HREF="usersguidenode11.html#fig.ESDcard">A.1</A>. 
If there is a reading direction, one can adorn the relationship name
with a small arrow that indicates this.
See figure&nbsp;<A HREF="usersguidenode11.html#fig.direction">A.5</A>.
<BR>
<DIV ALIGN="CENTER"><A NAME="fig.direction">&#160;</A><A NAME="8908">&#160;</A>
<TABLE WIDTH="50%">
<CAPTION><STRONG>Figure A.5:</STRONG>
Reading direction of a
relationship name.</CAPTION>
<TR><TD><IMG
 WIDTH="332" HEIGHT="51"
 SRC="usersguideimg181.gif"
 ALT="\begin{figure}
\centerline{\epsfig{figure=p/direction.eps}} %
%
\end{figure}"></TD></TR>
</TABLE>
</DIV>
<BR>
Often, a directed relationship name is really a role name of one of
the participating entity types.

<P>
<BR>
<DIV ALIGN="CENTER"><A NAME="fig.ESDmanyone">&#160;</A><A NAME="8910">&#160;</A>
<TABLE WIDTH="50%">
<CAPTION><STRONG>Figure A.6:</STRONG>
Different conventions for representing the same constraints.
TESD supports the convention used in the top diagram.</CAPTION>
<TR><TD><IMG
 WIDTH="319" HEIGHT="599"
 SRC="usersguideimg182.gif"
 ALT="\begin{figure}
\centerline{\epsfig{figure=p/ESDmanyone.eps}} %
%
\end{figure}"></TD></TR>
</TABLE>
</DIV>
<BR>
<BR>
<DIV ALIGN="CENTER"><A NAME="fig.ESDmay">&#160;</A><A NAME="8912">&#160;</A>
<TABLE WIDTH="50%">
<CAPTION><STRONG>Figure A.7:</STRONG>
Different conventions for representing the same constraints.
TESD supports the convention used in the top diagram.</CAPTION>
<TR><TD><IMG
 WIDTH="319" HEIGHT="507"
 SRC="usersguideimg183.gif"
 ALT="\begin{figure}
\centerline{\epsfig{figure=p/ESDmay.eps}} %
%
\end{figure}"></TD></TR>
</TABLE>
</DIV>
<BR>
There are many other conventions to represent binary relationships.
Figure&nbsp;<A HREF="usersguidenode11.html#fig.ESDmanyone">A.6</A> shows different ways of representing the following
constraints: 
<UL>
<LI>
Each existing <I>E1</I> is related to at least one existing <I>E2</I> and
<LI>
Each existing <I>E2</I> is related to exactly one existing <I>E1</I>.
</UL>Figure&nbsp;<A HREF="usersguidenode11.html#fig.ESDmay">A.7</A> shows different ways of representing the following
constraints: 
<UL>
<LI>
Each existing <I>E1</I> is related to at any number (including 0)
existing <I>E2</I> and
<LI>
Each existing <I>E2</I> is related to exactly one existing <I>E1</I>.
</UL>
<P>

<H3><A NAME="SECTION001111400000000000000">&#160;</A><A NAME="8361">&#160;</A>
<BR>
9.1.1.4 Relationships of higher arity
</H3>

<P>
<A NAME="8362">&#160;</A>
<BR>
<DIV ALIGN="CENTER"><A NAME="fig.ESDdiam">&#160;</A><A NAME="8914">&#160;</A>
<TABLE WIDTH="50%">
<CAPTION><STRONG>Figure A.8:</STRONG>
The diamond representation for relationships.</CAPTION>
<TR><TD><IMG
 WIDTH="435" HEIGHT="56"
 SRC="usersguideimg184.gif"
 ALT="\begin{figure}
\centerline{\epsfig{figure=p/ESDdiam.eps}} %
%
\end{figure}"></TD></TR>
</TABLE>
</DIV>
<BR>
A relationship is a Cartesian product of two or more entity
types, called its <EM>components</EM>.
(To be more precise, it is a <EM>labeled</EM> Cartesian
product.)<A NAME="8369">&#160;</A><A NAME="8370">&#160;</A>
Relationships can always be represented by a
diamond, connected by lines to the boxes that represent its
components.
These lines actually
represent the projection functions of a Cartesian product on
its components.
For example, 
figure&nbsp;<A HREF="usersguidenode11.html#fig.ESDdiam">A.8</A> contains exactly the same information as
figure&nbsp;<A HREF="usersguidenode11.html#fig.ESDcard">A.1</A>. 

<P>
Relationships with arity higher than 2 cannot be represented by a
line.
They can only be represented by a diamond.
Figure&nbsp;<A HREF="usersguidenode11.html#fig.ESDternary">A.9</A> gives an example.
<BR>
<DIV ALIGN="CENTER"><A NAME="fig.ESDternary">&#160;</A><A NAME="8916">&#160;</A>
<TABLE WIDTH="50%">
<CAPTION><STRONG>Figure A.9:</STRONG>
A ternary relationship with a
cardinality property.</CAPTION>
<TR><TD><IMG
 WIDTH="435" HEIGHT="153"
 SRC="usersguideimg185.gif"
 ALT="\begin{figure}
\centerline{\epsfig{figure=p/ESDternary.eps}} %
%
\end{figure}"></TD></TR>
</TABLE>
</DIV>
<BR>
The figure also illustrates the notation for a cardinality property
of a relationship with arity higher than 2.
A cardinality property is expressed by an expression <I>c</I> written at
the end of a line, close to an entity type box.
It represents the number of instances of that entity that 
participate in the relationship simultaneously.
The property in figure&nbsp;<A HREF="usersguidenode11.html#fig.ESDternary">A.9</A> says that each transport
company participates in at least one delivery.
(This is not very realistic but is does illustrate the convention.)

<P>

<H3><A NAME="SECTION001111500000000000000">&#160;</A><A NAME="8380">&#160;</A>
<BR>
9.1.1.5 Attributes
</H3>

<P>
<BR>
<DIV ALIGN="CENTER"><A NAME="fig.attr">&#160;</A><A NAME="8918">&#160;</A>
<TABLE WIDTH="50%">
<CAPTION><STRONG>Figure A.10:</STRONG>
Representation of attributes.</CAPTION>
<TR><TD><IMG
 WIDTH="89" HEIGHT="76"
 SRC="usersguideimg186.gif"
 ALT="\begin{figure}
\centerline{\epsfig{figure=p/attr.eps}} %
%
\end{figure}"></TD></TR>
</TABLE>
</DIV>
<BR>
Entity attributes are represented by listing them in a separate
compartment below the entity type name.
Representation of entity attributes is optional.

<P>

<H3><A NAME="SECTION001111600000000000000">
9.1.1.6 Associative entities</A>
</H3>

<P>
If a relationship itself has attributes, it is represented by an
entity box that contains the relationship name and the attribute
declarations, connected to the relationship line or relationship
diamond with a dashed line.
See figures&nbsp;<A HREF="usersguidenode11.html#fig.assoc1">A.11</A> and &nbsp;<A HREF="usersguidenode11.html#fig.assoc2">A.12</A> for illustrations.
<BR>
<DIV ALIGN="CENTER"><A NAME="fig.assoc1">&#160;</A><A NAME="8920">&#160;</A>
<TABLE WIDTH="50%">
<CAPTION><STRONG>Figure A.11:</STRONG>
Representation of associative
entities (line representation).</CAPTION>
<TR><TD><IMG
 WIDTH="366" HEIGHT="160"
 SRC="usersguideimg187.gif"
 ALT="\begin{figure}
\centerline{\epsfig{figure=p/assoc1.eps}} %
%
\end{figure}"></TD></TR>
</TABLE>
</DIV>
<BR>
<BR>
<DIV ALIGN="CENTER"><A NAME="fig.assoc2">&#160;</A><A NAME="8922">&#160;</A>
<TABLE WIDTH="50%">
<CAPTION><STRONG>Figure A.12:</STRONG>
Representation of associative
entities (diamond representation).</CAPTION>
<TR><TD><IMG
 WIDTH="401" HEIGHT="172"
 SRC="usersguideimg188.gif"
 ALT="\begin{figure}
\centerline{\epsfig{figure=p/assoc2.eps}} %
%
\end{figure}"></TD></TR>
</TABLE>
</DIV>
<BR>

<P>

<H3><A NAME="SECTION001111700000000000000">&#160;</A><A NAME="8397">&#160;</A>
<BR>
9.1.1.7 Is-a relationships
</H3>

<P>
<BR>
<DIV ALIGN="CENTER"><A NAME="fig.ESDisa">&#160;</A><A NAME="8924">&#160;</A>
<TABLE WIDTH="50%">
<CAPTION><STRONG>Figure A.13:</STRONG>
The representation of is-a relationships.</CAPTION>
<TR><TD><IMG
 WIDTH="319" HEIGHT="39"
 SRC="usersguideimg189.gif"
 ALT="\begin{figure}
\centerline{\epsfig{figure=p/ESDisa.eps}} %
%
\end{figure}"></TD></TR>
</TABLE>
</DIV>
<BR>
An is-a relationship is a binary relationship that is an inclusion
function. 
For example, figure&nbsp;<A HREF="usersguidenode11.html#fig.ESDisa">A.13</A> shows that each <I>CAR</I> instance
is also a <I>VEHICLE</I> instance.
Extensionally, the set of all possible cars is a subset of the set of all
possible vehicles.
Intensionally, the set of properties shared by all cars includes the set of
properties shared by all vehicles.
<I>CAR</I> is called a <EM>specialization</EM> of <I>VEHICLE</I> and <I>VEHICLE</I> is called a <EM>generalization</EM> of
<I>CAR</I>.<A NAME="8411">&#160;</A><A NAME="8412">&#160;</A>

<P>
If there is more than one specialization of an entity type, then these must
be grouped into <EM>specialization groups</EM>.<A NAME="8414">&#160;</A>
This is represented by connecting the rectangles representing the
specializations 
to a small circle<A NAME="8415">&#160;</A>
called the <EM>taxonomy junction</EM> or <EM>generalization node</EM> and 
connecting this with an <I>is-a</I> arrow to the rectangle representing the 
generalization. The generalization node must be annotated as follows:
<UL>
<LI>
A ``<I>d</I>'' means that the
specializations are mutually disjoint.<A NAME="8421">&#160;</A>
<LI>
An ``<I>c</I>'' means that the specializations
jointly covers the generalization.<A NAME="8423">&#160;</A>
<LI>
A ``<I>dc</I>'' means the conjunction of ``<I>d</I>'' and
``<I>c</I>'', i.e. the specializations partitions the generalization.
</UL><A NAME="8428">&#160;</A>
A generalization can be specialized by any number of specialization groups.
For example, figure&nbsp;<A HREF="usersguidenode6.html#ESDTaxonomyExample">4.10</A> means the following:
<UL>
<LI>Cars are vehicles and trucks are vehicles.
<LI>
The union of the set of all cars and all trucks equals the set of all
vehicles. 
So vehicles are trucks or cars (or both).
<LI>Diesel vehicles are vehicles and gas vehicles are vehicles.
<LI>
There is no vehicle both a diesel and a gas vehicle.
<LI>There may be vehicles that are neither diesel nor gas vehicles.
</UL>
<P>

<H2><A NAME="SECTION001112000000000000000">&#160;</A><A NAME="TUT-EFD">&#160;</A><A NAME="subsec.control">&#160;</A><A NAME="8435">&#160;</A>
<BR>
9.1.2 Data and Event Flow Diagrams (TEFD)
</H2>

<P>
Data flow diagrams (DFDs)
are are available in two TCM editors, called TDFD
(one of the miscellaneous editors)
and TEFD (one of the structured analysis editors).
TEFD allows you to do everything that TDFD can, and it additionally
allows you to draw control processes, event flows and to distinguish
time-discrete from time-continuous flows.
This section explains both editors.
DFDs are described in detail in [<A
 HREF="usersguidenode14.html#Wieringa99-01">23</A>].

<P>

<H3><A NAME="SECTION001112100000000000000">
9.1.2.1 The components of a DFD</A>
</H3>

<P>
A DFD is a directed graph with three kinds of nodes:
<UL>
<LI>Circles represent processes, also called data transformations or<A NAME="8439">&#160;</A>
functions. A process is some computation by a software system.
There are two kinds of processes: Data processes and control processes 
(the latter are not supported in TDFD). TEFD supports both processes.
<LI>Squares represent external entities, these are entities with<A NAME="8440">&#160;</A>
which the software system must interact.
<LI>Two parallel lines represent a data store, which is a piece of<A NAME="8441">&#160;</A>
software memory (e.g. a file or a variable).
</UL>The directed edges represent data flows between these nodes.<A NAME="8443">&#160;</A>

<P>
In figure&nbsp;<A HREF="usersguidenode8.html#DFDExample1">6.3</A>, there are three processes, <I>Confirm
Registration</I>, <I>Check Request</I> and <I>Register
students</I>.
When the external entity <I>STUDENT</I> sends a message
<I>test_request</I>, which is a request to participate in a
test, then the process 
 <I>Check Request</I> retrieves the identifier of the test from
the data store <I>TESTS</I>
 and the student identifier from the <I>STUDENTS</I>
data store  (the data stores are most likely implemented as files or
in a database).
If the test and student exist, and the student is allowed to
participate in the test, then process
<I>Register
students</I> stores this fact in the <I>TEST_REGISTRATIONS</I> data
store and 
 <I>Confirm
Registration</I> confirms this to the external entity.
To make the DFD in figure&nbsp;<A HREF="usersguidenode8.html#DFDExample1">6.3</A> more precise, this model must be
supplemented with precise process
specifications, and a specification of the structure of the data
stores and data flows.

<P>

<H3><A NAME="SECTION001112200000000000000">&#160;</A><A NAME="8458">&#160;</A><A NAME="8459">&#160;</A>
<BR>
9.1.2.2 Hierarchical DFDs
</H3>

<P>
DFDs can be hierarchical.
This means that a process can be specified by means of another DFD,
which has the same external interface as the process being specified.
Such a process is called a <EM>compound</EM> process.<A NAME="8461">&#160;</A><A NAME="8462">&#160;</A>
A process specified in another way (e.g. by means of a piece of text)
is called <EM>primitive</EM>.<A NAME="8464">&#160;</A>
This can be indicated by the letter <I>P</I> in the node that
represents the process.

<P>
Compound processes give rise to a tree of DFDs.
Processes in this tree are labeled by means of a Dewey numbering<A NAME="8466">&#160;</A>
system that indicates the location of the process in the tree.
For example, process 1.2 is the process with label 2 in the DFD that
specifies the compound process with label 1.
The current version of TCM does not support hierarchical DFD editing.

<P>

<H3><A NAME="SECTION001112300000000000000">&#160;</A><A NAME="8468">&#160;</A>
<BR>
9.1.2.3 Control processes
</H3>

<P>
DEFDs extend DFDs with a new kind of node, the control process, and 
new kinds of edges: event flows and time-continuous flows.
See subsection&nbsp;<A HREF="usersguidenode11.html#TUT-DFD">A.3.3</A> for DFDs.
A control process is represented by a dashed circle and represents an
aspect of behavior.
It must be specified by means of a STD that has the same interface as
the control process.
This means that the event flows entering the control process must
occur as events in the Mealy STD, and vice versa, and that the event
flows leaving the 
control process must occur as actions in the STD, and vice versa.
Figure&nbsp;<A HREF="usersguidenode11.html#fig.robot">A.14</A> contains a DEFD of which the control process is
specified in figure&nbsp;<A HREF="usersguidenode11.html#fig.robotctr">A.15</A>.
<BR>
<DIV ALIGN="CENTER"><A NAME="fig.robot">&#160;</A><A NAME="8926">&#160;</A>
<TABLE WIDTH="50%">
<CAPTION><STRONG>Figure A.14:</STRONG>
A DEFD for a robot control process.</CAPTION>
<TR><TD><IMG
 WIDTH="562" HEIGHT="374"
 SRC="usersguideimg190.gif"
 ALT="\begin{figure}
\centerline{\epsfig{figure=p/robot.eps}} %
%
\end{figure}"></TD></TR>
</TABLE>
</DIV>
<BR>
<BR>
<DIV ALIGN="CENTER"><A NAME="fig.robotctr">&#160;</A><A NAME="8928">&#160;</A>
<TABLE WIDTH="50%">
<CAPTION><STRONG>Figure A.15:</STRONG>
STD for the robot control process of figure&nbsp;<A HREF="usersguidenode11.html#fig.robot">A.14</A>.</CAPTION>
<TR><TD><IMG
 WIDTH="304" HEIGHT="533"
 SRC="usersguideimg191.gif"
 ALT="\begin{figure}
\centerline{\epsfig{figure=p/robotctr.eps}} %
%
\end{figure}"></TD></TR>
</TABLE>
</DIV>
<BR>

<P>

<H3><A NAME="SECTION001112400000000000000">&#160;</A><A NAME="8482">&#160;</A>
<BR>
9.1.2.4 Event flows
</H3>

<P>
Event flows are represented by dashed arrows.
An event flow can carry a signal without any data contents.
The precise meaning depends upon the method that uses this technique.
See for example the YSM manual&nbsp;[<A
 HREF="usersguidenode14.html#YSM93">31</A>].

<P>

<H3><A NAME="SECTION001112500000000000000">&#160;</A><A NAME="8485">&#160;</A><A NAME="8486">&#160;</A>
<BR>
9.1.2.5 Time-Discrete and time-continuous flows
</H3>

<P>
A time-discrete flow carries a value that changes in discrete steps, a
time-continuous flow carries a value that changes in a continuous  way.
Time-discrete flows are represented by arrows with a single arrowhead,
time-continuous flows are represented by arrows with a double arrowhead.
Again, the precise meaning depends upon the method used.

<P>

<H2><A NAME="SECTION001113000000000000000">&#160;</A><A NAME="TUT-STD">&#160;</A><A NAME="8489">&#160;</A>
<BR>
9.1.3 State Transition Diagrams (TSTD)
</H2>

<P>
State transition diagrams (Mealy, Moore and statechart)
are described in [<A
 HREF="usersguidenode14.html#Wieringa99-01">23</A>]

<P>
<BR>
<DIV ALIGN="CENTER"><A NAME="fig.std">&#160;</A><A NAME="8930">&#160;</A>
<TABLE WIDTH="50%">
<CAPTION><STRONG>Figure A.16:</STRONG>
The Mealy representation of state transition diagrams.</CAPTION>
<TR><TD><IMG
 WIDTH="110" HEIGHT="214"
 SRC="usersguideimg192.gif"
 ALT="\begin{figure}
\centerline{\epsfig{figure=p/std.eps}} %\end{figure}"></TD></TR>
</TABLE>
</DIV>
<BR>
TCM supports the Mealy notation for finite state transition diagrams
(figure&nbsp;<A HREF="usersguidenode11.html#fig.std">A.16</A>). 
States are named, and are represented by rectangles.<A NAME="8496">&#160;</A>
State transitions are represented by arrows and are labeled by
<I>event [guard] / action</I>
pairs.<A NAME="8498">&#160;</A><A NAME="8499">&#160;</A><A NAME="8500">&#160;</A> 
The event is the <EM>trigger</EM><A NAME="8502">&#160;</A><A NAME="8503">&#160;</A>
of the transition and can be viewed as the occurrence of an input.
The guard is a condition.<A NAME="8504">&#160;</A>
The precise meaning of the guard depends upon the method in which the
notation is used.
A minimalistic interpretation is that if the guard is false, an
occurrence of the event will not trigger the transition.
A more closed interpretation is that additionally, if the guard is
true, an occurrence of the event will trigger the transition.

<P>
The action part of the transition label is the output action generated
by the transition.

<P>
Each Mealy STD must have an initial state, pointed at by an arrow that<A NAME="8505">&#160;</A>
leaves from no node, and that can be labeled by an initialization
action.<A NAME="8506">&#160;</A><A NAME="8507">&#160;</A>

<P>
TCM also has <EM>decision points</EM><A NAME="8509">&#160;</A>
which are intermediary states
that the machine may have between system transactions. Decision
points are represented by a hexagon.
<BR>
<DIV ALIGN="CENTER"><A NAME="fig.transit">&#160;</A><A NAME="8932">&#160;</A>
<TABLE WIDTH="50%">
<CAPTION><STRONG>Figure A.17:</STRONG>
State transition diagrams.</CAPTION>
<TR><TD><IMG
 WIDTH="501" HEIGHT="583"
 SRC="usersguideimg193.gif"
 ALT="\begin{figure}
\centerline{\epsfig{figure=p/transit.eps}} %
%
\end{figure}"></TD></TR>
</TABLE>
</DIV>
<BR>
Figure&nbsp;<A HREF="usersguidenode11.html#fig.transit">A.17</A> shows the a Mealy diagram for a simple coffee
machine in which at two points, an external process is triggered  (the
actions that start with <I>T:</I>) that must send the Mealy
machine an answer.
While waiting for an answer, the machine is in the decision point.

<P>
Mealy machines are used in Yourdon-style structured analysis, where
they are used to specify control processes&nbsp;[<A
 HREF="usersguidenode14.html#YSM93">31</A>].
The interface of the control process must equal the interface of the
Mealy machine.
See section&nbsp;<A HREF="usersguidenode11.html#subsec.control">A.1.2</A> for control processes.

<P>

<H2><A NAME="SECTION001114000000000000000">&#160;</A><A NAME="TUT-TUT">&#160;</A><A NAME="8520">&#160;</A>
<BR>
9.1.4 Transaction-Use Tables (TTUT)
</H2>

<P>
A transaction-use table is a simple way to discover entity types from
required system transactions.
The leftmost column lists external system functions and the top row
lists the basic Create, Read, Update and Delete actions.
The entries list the entity types or relationships that are created,
read, updated or deleted during the function.
See figure&nbsp;<A HREF="usersguidenode9.html#TUTExample">7.8</A>.
Elaborate examples are given elsewhere&nbsp;[<A
 HREF="usersguidenode14.html#Wieringa96-01">22</A>].

<P>

<H2><A NAME="SECTION001115000000000000000">&#160;</A><A NAME="TUT-FET">&#160;</A><A NAME="8525">&#160;</A>
<BR>
9.1.5 Function-Entity Type Tables (TFET)
</H2>

<P>
The top row of a function-entity
table lists system functions and the leftmost
column represents, for example, entity types.
The entries contain C, R, U or D,
to indicate that this function Creates, Reads, Updates or Deletes
entities of this type.
Instead of entity types, the leftmost column may list relationships,
or subject areas, or data stores in a DFD, with corresponding changes
in the meaning of the CRUD entries.

<P>
A function-entity type table is a kind of traceability table
 (see&nbsp;[<A
 HREF="usersguidenode14.html#Wieringa99-01">23</A>]). 
It is almost the same as a transaction
decomposition table (see section&nbsp;<A HREF="usersguidenode11.html#TUT-TDT">A.3.7</A>).
Function-entity types are used in Information Engineering to find
subsystems. 
These are identified
by clustering subject areas and functions in such a way to minimize
data flows between the clusters.
See&nbsp;[<A
 HREF="usersguidenode14.html#Wieringa96-01">22</A>] for details and examples of their use in
 Information Engineering.

<P>

<H2><A NAME="SECTION001116000000000000000">&#160;</A><A NAME="TUT-FRT">&#160;</A><A NAME="8531">&#160;</A>
<BR>
9.1.6 Function Refinement Trees (TFRT)
</H2>

<P>
A function refinement tree is a tree in which the root represents the
entire system mission and the leaves represent system functions.
The hierarchy of nodes represents the refinement of functions into
subfunctions.
All nodes in the tree represent <EM>external</EM> functions.<A NAME="8533">&#160;</A>

<P>
A FRT can be used in combination with a hierarchical DFD to represent
the hierarchy of DFDs.
It is used in information engineering to represent external functions
of an information system&nbsp;[<A
 HREF="usersguidenode14.html#Wieringa96-01">22</A>].
Of course, a tree can be used to represent any hierarchical
decomposition and TCM imposes no constraints on the syntax of the tree.

<P>

<H1><A NAME="SECTION001120000000000000000">
9.2 UML Notations</A>
</H1>

<P>
This section lists the UML notations available in TCM, as they are
treated in [<A
 HREF="usersguidenode14.html#Wieringa99-01">23</A>].
This is a subset of the full UML notation.

<P>

<H2><A NAME="SECTION001121000000000000000">&#160;</A><A NAME="TUT-UCD">&#160;</A><A NAME="8539">&#160;</A>
<BR>
9.2.1 Use case diagrams (TUCD)
</H2>

<P>
A use case is a functionality of a system, and actor is a user (person
or device) of the system.
A use case diagram is a graph in which the nodes represent actors and
use cases, and the lines represent connections between use cases and
actors.
The meaning of a line is that the actor is involved in a use case.

<P>
A use case diagram is actually a special case of a class diagram with
two special kinds of nodes.
Nodes of the same kind can be connected by a generalization arrow.

<P>

<H3><A NAME="SECTION001121100000000000000">
9.2.1.1 Actors</A>
</H3>

<P>
An actor is represented by a match stick figure or by a rectangle
labeled <IMG
 WIDTH="20" HEIGHT="28" ALIGN="MIDDLE" BORDER="0"
 SRC="usersguideimg194.gif"
 ALT="$\ll$"><I>actor</I><IMG
 WIDTH="20" HEIGHT="28" ALIGN="MIDDLE" BORDER="0"
 SRC="usersguideimg195.gif"
 ALT="$\gg$">.
Both shapes can be labeled by an actor name.
Two actors can be connected by a generalization arrow.
Actor names must be unique.
Use ``duplicate node'' if you want to represent one actor several
times in the diagram.

<P>

<H3><A NAME="SECTION001121200000000000000">
9.2.1.2 Use cases</A>
</H3>

<P>
A use case is represented  by an ellipse.
It can be labeled.
Two use cases can be connected by a generalization arrow.

<P>

<H2><A NAME="SECTION001122000000000000000">&#160;</A><A NAME="TUT-SSD">&#160;</A><A NAME="8545">&#160;</A>
<BR>
9.2.2 Static structure diagrams (TSSD)
</H2>

<P>
A static structure diagram is an extension of an ER diagram.
What is an entity in an ESD is an object in a SSD.
The extensions of TSSD with respect to TESD are the
possibility to declare the behavior of an object and to represent
instances.
There is a change in terminology when we change from ESDs to SSDs:
<DIV ALIGN="CENTER">
<TABLE CELLPADDING=3 BORDER="1">
<TR><TD ALIGN="LEFT">Entity-relationship diagram</TD>
<TD ALIGN="LEFT">UML static structure diagram</TD>
</TR>
<TR><TD ALIGN="LEFT">entity type</TD>
<TD ALIGN="LEFT">class</TD>
</TR>
<TR><TD ALIGN="LEFT">entity</TD>
<TD ALIGN="LEFT">object</TD>
</TR>
<TR><TD ALIGN="LEFT">relationship</TD>
<TD ALIGN="LEFT">association</TD>
</TR>
<TR><TD ALIGN="LEFT">tuple</TD>
<TD ALIGN="LEFT">link</TD>
</TR>
<TR><TD ALIGN="LEFT">associative entity</TD>
<TD ALIGN="LEFT">associative object</TD>
</TR>
<TR><TD ALIGN="LEFT">cardinality property</TD>
<TD ALIGN="LEFT">multiplicity property</TD>
</TR>
</TABLE></DIV>
<P>

<H3><A NAME="SECTION001122100000000000000">
9.2.2.1 Stereotypes and properties</A>
</H3>
 
We can give a diagram element a special meaning by labeling it with a
special name between 
<!-- MATH: $\langle\hspace{-0.15em}\langle$ -->
<IMG
 WIDTH="14" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
 SRC="usersguideimg196.gif"
 ALT="$\langle\hspace{-0.15em}\langle$">guillemets
<!-- MATH: $\rangle\hspace{-0.15em}\rangle$ -->
<IMG
 WIDTH="14" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
 SRC="usersguideimg197.gif"
 ALT="$\rangle\hspace{-0.15em}\rangle$">.
Such a diagram element is called a <B>stereotype</B>.
For example, in a static structure diagram, we can specialize classes
into stereotypes with a special meaning, by writing the stereotype
name in guillemets above the class name.
See figure&nbsp;<A HREF="usersguidenode11.html#fig.stereo">A.18</A>.
 <BR>
<DIV ALIGN="CENTER"><A NAME="fig.stereo">&#160;</A><A NAME="8934">&#160;</A>
<TABLE WIDTH="50%">
<CAPTION><STRONG>Figure A.18:</STRONG>
Stereotypes and properties.</CAPTION>
<TR><TD><IMG
 WIDTH="233" HEIGHT="109"
 SRC="usersguideimg198.gif"
 ALT="\begin{figure}
\centerline{\epsfig{figure=p/stereo.eps}} %
%
\end{figure}"></TD></TR>
</TABLE>
</DIV>
<BR>

<P>
Figure&nbsp;<A HREF="usersguidenode11.html#fig.stereo">A.18</A> also shows that we can annotate the name
compartment of a class box with properties.
A property is represented by a user-defined property name and a
property value.
This is included in the name compartment as a comment between curly
braces, and it has no UML-defined semantics.
You are free to include any text between curly braces.

<P>

<H3><A NAME="SECTION001122200000000000000">
9.2.2.2 Behavior</A>
</H3>

<P>
The behavior of an object is declared in a third compartment below the
attribute compartment of a class box.
The UML allows the declaration of the operations that the instances of
the class can perform and of the signals that the instances can
receive.
See [<A
 HREF="usersguidenode14.html#Wieringa99-01">23</A>] for details.

<P>

<H3><A NAME="SECTION001122300000000000000">
9.2.2.3 Objects</A>
</H3>

<P>
An object is represented by a named rectangle with an attribute
compartment.
<BR>
<DIV ALIGN="CENTER"><A NAME="fig.objects">&#160;</A><A NAME="8936">&#160;</A>
<TABLE WIDTH="50%">
<CAPTION><STRONG>Figure A.19:</STRONG>
Representation of objects.</CAPTION>
<TR><TD><IMG
 WIDTH="582" HEIGHT="161"
 SRC="usersguideimg199.gif"
 ALT="\begin{figure}
\centerline{\epsfig{figure=p/objects.eps}} %
%
\end{figure}"></TD></TR>
</TABLE>
</DIV>
<BR>
The name of an instance is underlined.
The attribute compartment contains the attribute values of the
instance.
See figure&nbsp;<A HREF="usersguidenode11.html#fig.objects">A.19</A>.
Notice the association from John to the class <I>City</I>.
This tells us that John has exactly one birthplace but it does not
tell us which one this is, because <I>City</I> is a class.

<P>

<H2><A NAME="SECTION001123000000000000000">&#160;</A><A NAME="TUT-ATD">&#160;</A><A NAME="8571">&#160;</A>
<BR>
9.2.3 Activity diagrams (TATD)
</H2>

<P>
An activity diagram is a graph in which the nodes represent activities
and the arrows represent transitions between activities.
Figure&nbsp;<A HREF="usersguidenode11.html#fig.coffee">A.20</A> gives an example.

<P>
<BR>
<DIV ALIGN="CENTER"><A NAME="fig.coffee">&#160;</A><A NAME="8938">&#160;</A>
<TABLE WIDTH="50%">
<CAPTION><STRONG>Figure A.20:</STRONG>
An activity diagram.</CAPTION>
<TR><TD><IMG
 WIDTH="457" HEIGHT="663"
 SRC="usersguideimg200.gif"
 ALT="\begin{figure}
\centerline{\epsfig{figure=p/coffee.eps}} %
%
\end{figure}"></TD></TR>
</TABLE>
</DIV>
<BR>

<P>

<H3><A NAME="SECTION001123100000000000000">
9.2.3.1 Activity</A>
</H3>

<P>
Activities are represented by two parallel lines connected by
semicircles.
The name of the activity can be entered in the shape.

<P>

<H3><A NAME="SECTION001123200000000000000">
9.2.3.2 Transition</A>
</H3>

<P>
Transitions are represented by unlabeled arrows.
A transition represents the completion of the activity from which it
departs.

<P>

<H3><A NAME="SECTION001123300000000000000">
9.2.3.3 Choice nodes</A>
</H3>

<P>
A choice node is represented by a diamond.
A transition that emanates from a diamond can be labeled by a
<I>[condition]</I> that tells us when this branch is taken.
A choice point is not a state of the system.

<P>

<H3><A NAME="SECTION001123400000000000000">
9.2.3.4 Fork and join nodes</A>
</H3>

<P>
Fork and join nodes are represented by fat horizontal or vertical
lines.
If more than one arrow leaves the node, it is a fork node and there
must be exactly one arrow entering it.
A join node represents the start of two or more parallel processes.

<P>
If more than one arrow terminates at the node, it is a join node and
there must be exactly one arrow that departs from it.
A join node represents the merging of two or more parallel process
into one process.

<P>

<H3><A NAME="SECTION001123500000000000000">
9.2.3.5 Initial and final state</A>
</H3>

<P>
The start of an activity diagram is represented by a bullet.
There must be exactly one bullet in a completed  diagram.

<P>
A final state of an activity is represented by a bull's eye.
There must be at least one final state in an activity completed diagram.

<P>

<H2><A NAME="SECTION001124000000000000000">&#160;</A><A NAME="TUT-SCD">&#160;</A><A NAME="8585">&#160;</A>
<BR>
9.2.4 Statechart diagrams (TSCD)
</H2>

<P>
TSCD is used to draw <EM>statecharts.</EM>
Statecharts are based on state-transition diagrams known from TSTD.

<P>
A statechart describes the behaviour of a system,
i.e., the possible orders of events and states.
A state in a statechart may consist of one or several <EM>state nodes.</EM>
A state node can be refined in two ways:
<DL>
<DD><P>
<DT><STRONG>An <I>or</I> node</STRONG>
<DD>serves to describe substates.
	If the state of the system contains the <I>or</I> node,
	it contains exactly one of the subnodes.

<P>
The subnodes of an <I>or</I> node are simply drawn inside the 
<I>or</I> node.
	The initial subnode has an arrow starting at a black dot.

<P>
<DT><STRONG>An <I>and</I> node</STRONG>
<DD>serves to describe parallel behaviour.
	If the state of the system contains the <I>and</I> node,
	it contains all of the subnodes.
	These subnodes are typically refined further,
	to describe in which state the single parallel components can stay.

<P>
The subnodes of an <I>and</I> node are drawn as compartments which 
partition the <I>and</I> node.
	As there is no space left for the <I>and</I> node's name, it is 
attached to a small box on the outside.

<P>
</DL>Possible state changes are indicated by <EM>transitions.</EM>
They are drawn as arrows with a label 
<!-- MATH: $\mathsf{e} [\mathsf{g}] / \mathsf{a}$ -->
<IMG
 WIDTH="44" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
 SRC="usersguideimg201.gif"
 ALT="$\mathsf{e} [\mathsf{g}] / \mathsf{a}$">,
where 
<!-- MATH: $\mathsf{e}$ -->
<IMG
 WIDTH="11" HEIGHT="13" ALIGN="BOTTOM" BORDER="0"
 SRC="usersguideimg202.gif"
 ALT="$\mathsf{e}$">
denotes the event which triggers the transition,

<!-- MATH: $\mathsf{g}$ -->
<IMG
 WIDTH="13" HEIGHT="28" ALIGN="MIDDLE" BORDER="0"
 SRC="usersguideimg203.gif"
 ALT="$\mathsf{g}$">
is a guard (the transition can only be taken if the guard holds),
and 
<!-- MATH: $\mathsf{a}$ -->
<IMG
 WIDTH="12" HEIGHT="13" ALIGN="BOTTOM" BORDER="0"
 SRC="usersguideimg204.gif"
 ALT="$\mathsf{a}$">
denotes the action executed when the transition is taken
(for example, send an event to another statechart).

<P>
In addition to these basic elements,
one can indicate the initial state with an arrow from a black dot
and the final state with a bull's eye.

<P>
For an example of a statechart, see figure&nbsp;<A HREF="usersguidenode11.html#fig.statechart">A.21</A>.
The statechart describes a fan's behaviour.
This kind of fan can produce a cold or hot, and a slow or fast air stream.
Its initial state is <I>Off</I>.
When switched on,
it enters the <I>and</I> node <I>On</I> and its subnodes.
Here, it again selects the initial nodes <I>Slow</I> and <I>Cold</I>.
If the user sends event <I>f</I> to the system,
it switches to <I>Fast</I>.
When the user switches the fan off (by sending an <I>off</I> event),
the fan leaves the <I>On</I> node and all its subnodes
(forgetting the slow/fast and cold/hot settings),
and enters the <I>Off</I> node again.
<BR>
<DIV ALIGN="CENTER"><A NAME="fig.statechart">&#160;</A><A NAME="8940">&#160;</A>
<TABLE WIDTH="50%">
<CAPTION><STRONG>Figure A.21:</STRONG>
Example of a statechart.</CAPTION>
<TR><TD><IMG
 WIDTH="519" HEIGHT="278"
 SRC="usersguideimg205.gif"
 ALT="\begin{figure}
\center{\epsfig{file=p/statechart.eps} }
\end{figure}"></TD></TR>
</TABLE>
</DIV>
<BR>
<P>

<H2><A NAME="SECTION001125000000000000000">&#160;</A><A NAME="TUT-CBD">&#160;</A><A NAME="8623">&#160;</A>
<BR>
9.2.5 Collaboration diagrams (TCBD)
</H2>

<P>
A collaboration diagram is an object diagram that shows the objects 
and links involved in a scenario, and also shows the messages passed
in the scenario.

<P>

<H3><A NAME="SECTION001125100000000000000">
9.2.5.1 Messages</A>
</H3>

<P>
In addition to other UML diagrams a collaboration diagram has 
message flows representing messages being sent between objects via 
links. See
figure&nbsp;<A HREF="usersguidenode11.html#fig.messages">A.22</A> for an example of the initial dialog 
between a client and a ATM.

<P>
<BR>
<DIV ALIGN="CENTER"><A NAME="fig.messages">&#160;</A><A NAME="8942">&#160;</A>
<TABLE WIDTH="50%">
<CAPTION><STRONG>Figure A.22:</STRONG>
Collaboration diagram messages.</CAPTION>
<TR><TD><IMG
 WIDTH="317" HEIGHT="94"
 SRC="usersguideimg206.gif"
 ALT="\begin{figure}
\centerline{\epsfig{figure=p/tut_messages.eps}} %
%
\end{figure}"></TD></TR>
</TABLE>
</DIV>
<BR>

<P>

<H2><A NAME="SECTION001126000000000000000">&#160;</A><A NAME="TUT-CPD">&#160;</A><A NAME="8632">&#160;</A>
<BR>
9.2.6 Component diagrams (TCPD)
</H2>

<P>
A UML component diagram is a directed graph in which the nodes
represent  components and the edges, which are directed, represent
dependencies.
A component is, roughly, any software-like resource delivered during
software development or needed by the delivered software.
This includes the executables and sources of the software system,
utilities needed by the software system,   shared libraries, etc.
A dependency may be a compilation dependency, and import dependency,
etc.
The exact meaning of the nodes and edges must be described in the
diagram documentation.

<P>
The interface of an executable component is represented by small
rectangles protruding from the component box.

<P>
Each class in the class model must be allocated to an executable
component.
This can be represented in a component diagram by enclosing a class icon
inside a component icon.
Alternatively, it can be represented by drawing a dependency arrow from
the class to the component(s)  it is allocated to.

<P>

<H2><A NAME="SECTION001127000000000000000">&#160;</A><A NAME="TUT-DPD">&#160;</A><A NAME="8635">&#160;</A>
<BR>
9.2.7 Deployment diagrams (TDPD)
</H2>

<P>
A UML deployment diagram is a graph in which the nodes represent
resources and the edges represent communication channels.
A resource is a hardware/software combination that offers computing
power.
This includes mainframes,  servers, workstations, PC's,  laptops,
handheld  computers, organizers, mobile telephones, faxes, printers,
etc.
A channel is any hardware/software combination that offers communication
possibility to resources.
This includes local and  wide area networks, wireless communications,
cables, etc.

<P>
Each executable component can be allocated to one or more resources.
This can be represented in a UML deployment diagram by drawing a
component icon inside a resource icon.
Alternatively, it can be represented by drawing a dependency arrow from
the component to the resource(s) it is allocated to.

<P>

<H1><A NAME="SECTION001130000000000000000">
9.3 Miscellaneous Notations</A>
</H1>

<P>

<H2><A NAME="SECTION001131000000000000000">&#160;</A><A NAME="TUT-ERD">&#160;</A><A NAME="8639">&#160;</A>
<BR>
9.3.1 Classic Entity-Relationship Diagrams (TERD)
</H2>

<P>
The TCM convention for ERDs is described in detail
in&nbsp;[<A
 HREF="usersguidenode14.html#Wieringa96-01">22</A>].

<P>

<H3><A NAME="SECTION001131100000000000000">&#160;</A><A NAME="8642">&#160;</A>
<BR>
9.3.1.1 Entity types
</H3>

<P>
As usual, a named rectangle represents a named entity type.

<P>

<H3><A NAME="SECTION001131200000000000000">&#160;</A><A NAME="8644">&#160;</A>
<BR>
9.3.1.2 Binary relationships
</H3>

<P>
Binary relationships are presented by lines.

<P>

<H3><A NAME="SECTION001131300000000000000">&#160;</A><A NAME="8646">&#160;</A>
<BR>
9.3.1.3 Cardinality constraints
</H3>

<P>
Cardinality constraints are represented by
annotations placed at the end points of these lines.
<BR>
<DIV ALIGN="CENTER"><A NAME="fig.ERDcard">&#160;</A><A NAME="8944">&#160;</A>
<TABLE WIDTH="50%">
<CAPTION><STRONG>Figure A.23:</STRONG>
The placement of cardinality constraints.</CAPTION>
<TR><TD><IMG
 WIDTH="354" HEIGHT="45"
 SRC="usersguideimg207.gif"
 ALT="\begin{figure}
\centerline{\epsfig{figure=p/ERDcard.eps}} %
%
\end{figure}"></TD></TR>
</TABLE>
</DIV>
<BR>
For example, in figure&nbsp;<A HREF="usersguidenode11.html#fig.ERDcard">A.23</A>, each business has an employment
relationship to more than zero persons and each person has 0 or 1
employment relationships to a business.
The end points of the line can also be annotated with the role that the
entity at that end of the line plays in the relationship.
Figure&nbsp;<A HREF="usersguidenode11.html#fig.ERDroles">A.24</A> gives an example.<A NAME="8653">&#160;</A>
<BR>
<DIV ALIGN="CENTER"><A NAME="fig.ERDroles">&#160;</A><A NAME="8946">&#160;</A>
<TABLE WIDTH="50%">
<CAPTION><STRONG>Figure A.24:</STRONG>
The placement of role names.</CAPTION>
<TR><TD><IMG
 WIDTH="458" HEIGHT="45"
 SRC="usersguideimg208.gif"
 ALT="\begin{figure}
\centerline{\epsfig{figure=p/ERDroles.eps}} %
%
\end{figure}"></TD></TR>
</TABLE>
</DIV>
<BR>

<P>
<BR>
<DIV ALIGN="CENTER"><A NAME="fig.ERDcon">&#160;</A><A NAME="8948">&#160;</A>
<TABLE WIDTH="50%">
<CAPTION><STRONG>Figure A.25:</STRONG>
The meaning of cardinality constraints.</CAPTION>
<TR><TD><IMG
 WIDTH="343" HEIGHT="45"
 SRC="usersguideimg209.gif"
 ALT="\begin{figure}
\centerline{\epsfig{figure=p/ERDcon.eps}} %
%
\end{figure}"></TD></TR>
</TABLE>
</DIV>
<BR>
In general, a cardinality constraint is represented by a set of natural
numbers (see figure&nbsp;<A HREF="usersguidenode6.html#CardSyntax">4.4</A> for the syntax).
For example, if <I>c</I> is a set of natural numbers, the constraint
in figure&nbsp;<A HREF="usersguidenode11.html#fig.ERDcon">A.25</A> is that each instance of <I>E1</I> is related
to <I>n</I> instances of <I>E2</I>, where <IMG
 WIDTH="29" HEIGHT="28" ALIGN="MIDDLE" BORDER="0"
 SRC="usersguideimg179.gif"
 ALT="$n \in$">
<I>c</I>&nbsp;<A NAME="tex2html176"
 HREF="#foot8949"><SUP>9.1</SUP></A>.
If no constraint label is shown, the convention is that the constraint is
the entire set of natural numbers, i.e. it is no constraint.
For example, in figure&nbsp;<A HREF="usersguidenode11.html#fig.ERDcon">A.25</A>, each instance of <I>E2</I> is
related 
to any number instances of <I>E1</I>.
This includes the case that it is related to 0 instances of <I>E1</I>.

<P>
<BR>
<DIV ALIGN="CENTER"><A NAME="fig.ERDarrow">&#160;</A><A NAME="8951">&#160;</A>
<TABLE WIDTH="50%">
<CAPTION><STRONG>Figure A.26:</STRONG>
The arrow representation of many-one constraints.</CAPTION>
<TR><TD><IMG
 WIDTH="319" HEIGHT="126"
 SRC="usersguideimg210.gif"
 ALT="\begin{figure}
\centerline{\epsfig{figure=p/ERDarrow.eps}} %
%
\end{figure}"></TD></TR>
</TABLE>
</DIV>
<BR>
There are various conventions for the placement of the cardinality
constraints, all of which are a source of confusion.
The choice made in TCM is motivated as follows.
We use the convention that a cardinality constraint of 1 can be abbreviated
by an arrowhead.
So the two diagrams in figure&nbsp;<A HREF="usersguidenode11.html#fig.ERDarrow">A.26</A> are equivalent as far as
their cardinality constraints are concerned.
They both mean that each person is related to exactly 1 business and that
each business is related to at least one person.
This means that the relationship is a mathematical function from persons to
businesses, which explains the arrow convention.
To facilitate a smooth transformation between these two representations,
the cardinality constraint labels must be placed where they now are.

<P>
<BR>
<DIV ALIGN="CENTER"><A NAME="fig.ERDreverse">&#160;</A><A NAME="8953">&#160;</A>
<TABLE WIDTH="50%">
<CAPTION><STRONG>Figure A.27:</STRONG>
The line representation of binary relationships is direction-independent.</CAPTION>
<TR><TD><IMG
 WIDTH="297" HEIGHT="45"
 SRC="usersguideimg211.gif"
 ALT="\begin{figure}
\centerline{\epsfig{figure=p/ERDreverse.eps}} %
%
\end{figure}"></TD></TR>
</TABLE>
</DIV>
<BR>
Note that the naming of the relationship usually must change when we switch
to the arrow notation.
In the line notation, there is no natural reading direction for the
relationship name.
For example, figure&nbsp;<A HREF="usersguidenode11.html#fig.ERDreverse">A.27</A> conveys the same information as
figure&nbsp;<A HREF="usersguidenode11.html#fig.ERDcard">A.23</A>. 
In the arrow representation, by contrast, there is a natural reading
direction and we adapt the relationship name accordingly.
Often, the role name of the entity type at the arrowhead becomes the
relationship name.

<P>
<BR>
<DIV ALIGN="CENTER"><A NAME="fig.ERDmanyone">&#160;</A><A NAME="8955">&#160;</A>
<TABLE WIDTH="50%">
<CAPTION><STRONG>Figure A.28:</STRONG>
Different conventions supported by the 
classic TERD editor for representing the same constraints. </CAPTION>
<TR><TD><IMG
 WIDTH="342" HEIGHT="137"
 SRC="usersguideimg212.gif"
 ALT="\begin{figure}
\centerline{\epsfig{figure=p/ERDmanyone.eps}} %
%
\end{figure}"></TD></TR>
</TABLE>
</DIV>
<BR>
<BR>
<DIV ALIGN="CENTER"><A NAME="fig.ERDmay">&#160;</A><A NAME="8957">&#160;</A>
<TABLE WIDTH="50%">
<CAPTION><STRONG>Figure A.29:</STRONG>
Different conventions supported by the 
classic TERD editor for representing the same constraints.</CAPTION>
<TR><TD><IMG
 WIDTH="342" HEIGHT="137"
 SRC="usersguideimg213.gif"
 ALT="\begin{figure}
\centerline{\epsfig{figure=p/ERDmay.eps}} %
%
\end{figure}"></TD></TR>
</TABLE>
</DIV>
<BR>
There are many other conventions to represent binary relationships.
Figure&nbsp;<A HREF="usersguidenode11.html#fig.ERDmanyone">A.28</A> shows different ways of representing the following
constraints: 
<UL>
<LI>
Each existing <I>E1</I> is related to at least one existing <I>E2</I> and
<LI>
Each existing <I>E2</I> is related to exactly one existing <I>E1</I>.
</UL>Figure&nbsp;<A HREF="usersguidenode11.html#fig.ERDmay">A.29</A> shows different ways of representing the following
constraints: 
<UL>
<LI>
Each existing <I>E1</I> is related to at any number (including 0)
existing <I>E2</I> and
<LI>
Each existing <I>E2</I> is related to exactly one existing <I>E1</I>.
</UL>
<P>

<H3><A NAME="SECTION001131400000000000000">&#160;</A><A NAME="8710">&#160;</A>
<BR>
9.3.1.4 Relationships of higher arity
</H3>

<P>
<A NAME="8711">&#160;</A>
<BR>
<DIV ALIGN="CENTER"><A NAME="fig.ERDdiam">&#160;</A><A NAME="8959">&#160;</A>
<TABLE WIDTH="50%">
<CAPTION><STRONG>Figure A.30:</STRONG>
The diamond representation for relationships.</CAPTION>
<TR><TD><IMG
 WIDTH="412" HEIGHT="45"
 SRC="usersguideimg214.gif"
 ALT="\begin{figure}
\centerline{\epsfig{figure=p/ERDdiam.eps}} %
%
\end{figure}"></TD></TR>
</TABLE>
</DIV>
<BR>
A relationship is a Cartesian product of two or more entity
types, called its <EM>components</EM>.<A NAME="tex2html178"
 HREF="#foot8960"><SUP>9.2</SUP></A><A NAME="8718">&#160;</A><A NAME="8719">&#160;</A>
Relationships of arity higher than 2 are represented by a
diamond, connected by arrows to the boxes that represent its components.
These arrows represent the projection functions of a Cartesian product on
its components.
Figure&nbsp;<A HREF="usersguidenode11.html#fig.ERDdiam">A.30</A> contains exactly the same information as
figure&nbsp;<A HREF="usersguidenode11.html#fig.ERDcard">A.23</A>. 
Note the placement of the cardinality constraints, which is at the root of
the arrow.
This agrees with the placement convention of constraints on relationship
lines. 
In fact, one can view the arrows in figure&nbsp;<A HREF="usersguidenode11.html#fig.ERDdiam">A.30</A> as binary
relationships between <I>EMPLOYMENT</I> and its two components.
The meaning is that each business is related to at least one employment
instance (and hence to exactly one person), 
and that each person is related to exactly one employment instance (and
hence to exactly one business).
This agrees with the meaning of figure&nbsp;<A HREF="usersguidenode11.html#fig.ERDcard">A.23</A>.

<P>

<H3><A NAME="SECTION001131500000000000000">&#160;</A><A NAME="8726">&#160;</A>
<BR>
9.3.1.5 Value types
</H3>

<P>
Value types (often called ``data types'') are represented by ovals.

<P>

<H3><A NAME="SECTION001131600000000000000">&#160;</A><A NAME="8728">&#160;</A>
<BR>
9.3.1.6 Attributes
</H3>

<P>
Entity attributes are represented by arrows from an entity type to an
oval 
and relationship attributes are represented by arrows from a relationship
diamond to an oval.
This means that the TCM convention does not distinguish between
``ordinary'' relationships, which do not have attributes, and ``associative
entity types'', which are relationships that can have attributes.

<P>

<H3><A NAME="SECTION001131700000000000000">&#160;</A><A NAME="8730">&#160;</A>
<BR>
9.3.1.7 Is-a relationships
</H3>

<P>
<BR>
<DIV ALIGN="CENTER"><A NAME="fig.ERDisa">&#160;</A><A NAME="8962">&#160;</A>
<TABLE WIDTH="50%">
<CAPTION><STRONG>Figure A.31:</STRONG>
The representation of is-a relationships.</CAPTION>
<TR><TD><IMG
 WIDTH="285" HEIGHT="45"
 SRC="usersguideimg215.gif"
 ALT="\begin{figure}
\centerline{\epsfig{figure=p/ERDisa.eps}} %
%
\end{figure}"></TD></TR>
</TABLE>
</DIV>
<BR>
An is-a relationship is a binary relationship that is an inclusion
function. 
For example, figure&nbsp;<A HREF="usersguidenode11.html#fig.ERDisa">A.31</A> shows that each <I>CAR</I> instance
is also a <I>VEHICLE</I> instance.
Extensionally, the set of all possible cars is a subset of the set of all
possible vehicles.
Intensionally, the set of properties shared by all cars includes the set of
properties shared by all vehicles.
<I>CAR</I> is called a <EM>specialization</EM> of <I>VEHICLE</I> and <I>VEHICLE</I> is called a <EM>generalization</EM> of
<I>CAR</I>.<A NAME="8744">&#160;</A><A NAME="8745">&#160;</A>

<P>
If there is more than one specialization of an entity type, then these must
be grouped into <EM>specialization groups</EM>.<A NAME="8747">&#160;</A>
This is represented by connecting the rectangles representing the
specializations 
to a small circle<A NAME="8748">&#160;</A>
called the <EM>taxonomy junction</EM> and connecting this with an
<I>is-a</I> arrow to the rectangle representing the generalization.
The taxonomy junction must be annotated as follows:
<UL>
<LI>
A ``<I>d</I>'' means that the
specializations are mutually disjoint.<A NAME="8753">&#160;</A>
<LI>
An ``<I>e</I>'' means that the specializations
jointly exhaust the generalization.<A NAME="8755">&#160;</A>
<LI>
A ``<I>de</I>'' means the conjunction of ``<I>d</I>'' and
``<I>e</I>'', i.e. the specializations partition the generalization.
</UL><A NAME="8760">&#160;</A>
A generalization can be specialized by any number of specialization groups.
For example, figure&nbsp;<A HREF="usersguidenode6.html#TaxonomyExample">4.5</A> means the following:
<UL>
<LI>Cars are vehicles and trucks are vehicles.
<LI>
The union of the set of all cars and all trucks equals the set of all
vehicles. 
So vehicles are trucks or cars (or both).
<LI>Diesel vehicles are vehicles and gas vehicles are vehicles.
<LI>
There is no vehicle both a diesel and a gas vehicle.
<LI>There may be vehicles that are neither diesel nor gas vehicles.
</UL>
<P>

<H2><A NAME="SECTION001132000000000000000">&#160;</A><A NAME="TUT-CRD">&#160;</A><A NAME="8766">&#160;</A>
<BR>
9.3.2 Class-Relationship Diagrams (TCRD)
</H2>

<P>

<H3><A NAME="SECTION001132100000000000000">&#160;</A><A NAME="8768">&#160;</A>
<BR>
9.3.2.1 Classes
</H3>

<P>
The CRD notation of TCM follows the convention that a class is represented
by a rectangle subdivided into three areas, that contain, from top to
bottom, the class name, the attributes, and the events that can occur in
the life of the class instances.
TCM can hide one or both of the event and attribute areas from view.
<A NAME="8769">&#160;</A>

<P>

<H3><A NAME="SECTION001132200000000000000">&#160;</A><A NAME="8771">&#160;</A><A NAME="8772">&#160;</A>
<BR>
9.3.2.2 Relationships
</H3>
<BR>
<DIV ALIGN="CENTER"><A NAME="fig.crd">&#160;</A><A NAME="8964">&#160;</A>
<TABLE WIDTH="50%">
<CAPTION><STRONG>Figure A.32:</STRONG>
The CRD representation of relationships.</CAPTION>
<TR><TD><IMG
 WIDTH="435" HEIGHT="45"
 SRC="usersguideimg216.gif"
 ALT="\begin{figure}
\centerline{\epsfig{figure=p/crd.eps}} %
%
\end{figure}"></TD></TR>
</TABLE>
</DIV>
<BR>
Relationships are represented by rectangles just as classes are.
They are connected to their components by means of dashed arrows.
The meaning is exactly the same as in the ERD case.
Figure&nbsp;<A HREF="usersguidenode11.html#fig.crd">A.32</A> has exactly the same information content as
figures&nbsp;<A HREF="usersguidenode11.html#fig.ERDcard">A.23</A>,&nbsp;<A HREF="usersguidenode11.html#fig.ERDreverse">A.27</A> and&nbsp;<A HREF="usersguidenode11.html#fig.ERDdiam">A.30</A>.
The line representation (figure&nbsp;<A HREF="usersguidenode11.html#fig.ERDcard">A.23</A>) is also allowed in the
CRD convention.
The advantage of the CRD convention over the diamond representation
is that a rectangle allows easier
placement of text inside the area.
In addition, the CRD convention used in TCM allows representation of such
complex structures as represented in figure&nbsp;<A HREF="usersguidenode11.html#fig.complex">A.33</A>, which cannot
be represented in the ERD convention.
<BR>
<DIV ALIGN="CENTER"><A NAME="fig.complex">&#160;</A><A NAME="8966">&#160;</A>
<TABLE WIDTH="50%">
<CAPTION><STRONG>Figure A.33:</STRONG>
The CRD convention can represent complex mathematical structures.</CAPTION>
<TR><TD><IMG
 WIDTH="306" HEIGHT="278"
 SRC="usersguideimg217.gif"
 ALT="\begin{figure}
\centerline{\epsfig{figure=p/complex.eps}} %
%
\end{figure}"></TD></TR>
</TABLE>
</DIV>
<BR>
Figure&nbsp;<A HREF="usersguidenode11.html#fig.complex">A.33</A> represents the following structures.
(To reduce clutter in the notation, we ignore the fact that
relationships are actually <EM>labeled</EM> Cartesian products.)<UL>
<LI>R1 = E1 <IMG
 WIDTH="17" HEIGHT="28" ALIGN="MIDDLE" BORDER="0"
 SRC="usersguideimg218.gif"
 ALT="$\times$">
E2
<LI>f : E3 
<!-- MATH: $\rightarrow$ -->
<IMG
 WIDTH="20" HEIGHT="14" ALIGN="BOTTOM" BORDER="0"
 SRC="usersguideimg129.gif"
 ALT="$\rightarrow$">
R1
<LI>g : R1 
<!-- MATH: $\rightarrow$ -->
<IMG
 WIDTH="20" HEIGHT="14" ALIGN="BOTTOM" BORDER="0"
 SRC="usersguideimg129.gif"
 ALT="$\rightarrow$">
E4
<LI>R2 = R1 <IMG
 WIDTH="17" HEIGHT="28" ALIGN="MIDDLE" BORDER="0"
 SRC="usersguideimg218.gif"
 ALT="$\times$">
E5
</UL>

<P>

<H3><A NAME="SECTION001132300000000000000">&#160;</A><A NAME="8792">&#160;</A>
<BR>
9.3.2.3 Is-a relationships
</H3>

<P>
<BR>
<DIV ALIGN="CENTER"><A NAME="fig.static">&#160;</A><A NAME="8969">&#160;</A>
<TABLE WIDTH="50%">
<CAPTION><STRONG>Figure A.34:</STRONG>
Static specialization.</CAPTION>
<TR><TD><IMG
 WIDTH="343" HEIGHT="252"
 SRC="usersguideimg219.gif"
 ALT="\begin{figure}
\centerline{\epsfig{figure=p/static.eps}} %
%
\end{figure}"></TD></TR>
</TABLE>
</DIV>
<BR>
The CRD convention for representing is-a relationships extends the ERD
convention with constructs to represent static and dynamic specialization.
A static specialization group is represented by a small closed circle,
called a taxonomy junction,
and
a dynamic specialization group is represented by a dashed circle, called a
mode junction (see figure&nbsp;<A HREF="usersguidenode6.html#CRRepresentations">4.12</A>).<A NAME="8798">&#160;</A>
In figure&nbsp;<A HREF="usersguidenode11.html#fig.static">A.34</A>, an instance of <I>CAR</I> will never
become an instance of <I>AIRPLANE</I> and vice versa.
An instance is a member of a specialization for life.
By contrast, in figure&nbsp;<A HREF="usersguidenode6.html#ModeExample">4.16</A>, an instance of <I>MARRIED PERSON</I>
may move to another of the subclasses of <I>PERSON</I>.
Here, an instance is an instance of a specialization only for part of its
life. 
We call these specialization <EM>mode classes</EM>.<A NAME="8806">&#160;</A>
For example, <I>MARRIED PERSON</I> is a mode class of <I>PERSON</I>,  because a married person is a mode of a person.
Details of static and dynamic specialization are given<A NAME="8809">&#160;</A><A NAME="8810">&#160;</A>
elsewhere&nbsp;[<A
 HREF="usersguidenode14.html#Wieringa94-01">24</A>,<A
 HREF="usersguidenode14.html#Wieringa95-04">25</A>].

<P>

<H2><A NAME="SECTION001133000000000000000">&#160;</A><A NAME="TUT-DFD">&#160;</A><A NAME="8814">&#160;</A>
<BR>
9.3.3 Data Flow Diagrams (TDFD)
</H2>

<P>
TDFD contains a subset of TEFD. Please see section&nbsp;<A HREF="usersguidenode11.html#TUT-EFD">A.1.2</A>.

<P>

<H2><A NAME="SECTION001134000000000000000">&#160;</A><A NAME="TUT-PSD">&#160;</A><A NAME="8818">&#160;</A><A NAME="8819">&#160;</A>
<BR>
9.3.4 Process Structure Diagrams (TPSD)
</H2>

<P>
<BR>
<DIV ALIGN="CENTER"><A NAME="fig.psd">&#160;</A><A NAME="8971">&#160;</A>
<TABLE WIDTH="50%">
<CAPTION><STRONG>Figure A.35:</STRONG>
A process structure diagram.</CAPTION>
<TR><TD><IMG
 WIDTH="582" HEIGHT="333"
 SRC="usersguideimg220.gif"
 ALT="\begin{figure}
\centerline{\epsfig{figure=p/psd.eps}} %
%
\end{figure}"></TD></TR>
</TABLE>
</DIV>
<BR>
Process structure diagrams are used in JSD to represent behavior.
A PSD is a tree in which the nodes are
labeled&nbsp;[<A
 HREF="usersguidenode14.html#Jackson83">11</A>,<A
 HREF="usersguidenode14.html#Wieringa96-01">22</A>].
The leaves of the tree represent atomic actions and the root
represents the entire process.
Sequence is represented by a left-to-right ordering of the children of
a node.
Iteration is represented by an asterisk label and choice by a small
circle in the nodes that represent the options.
Figure&nbsp;<A HREF="usersguidenode11.html#fig.psd">A.35</A> gives an example.

<P>
PSDs are equivalent to regular expressions.

<P>
<BR>
<DIV ALIGN="CENTER"><A NAME="fig.psdstd">&#160;</A><A NAME="8973">&#160;</A>
<TABLE WIDTH="50%">
<CAPTION><STRONG>Figure A.36:</STRONG>
A Mealy diagram roughly equivalent
to figure&nbsp;<A HREF="usersguidenode11.html#fig.psd">A.35</A>.</CAPTION>
<TR><TD><IMG
 WIDTH="133" HEIGHT="425"
 SRC="usersguideimg221.gif"
 ALT="\begin{figure}
\centerline{\epsfig{figure=p/psdstd.eps}} %
%
\end{figure}"></TD></TR>
</TABLE>
</DIV>
<BR>
A Mealy machine roughly equivalent to this is shown in
figure&nbsp;<A HREF="usersguidenode11.html#fig.psdstd">A.36</A>.
The names of the nodes in a PSD can be reused as state names in a
Mealy STD.
However, the Mealy convention forces us to categorize an action as an
input or output action, whereas in PSDs this is not the case.
In figure&nbsp;<A HREF="usersguidenode11.html#fig.psdstd">A.36</A>
we arbitrarily categorized all PSD actions as output actions.

<P>
In JSD, PSDs are used to represent processes in reality and to
represent processes in the machine.
If used to represent processes in reality, common actions between PSDs
represent synchronous communication between these processes.
If used to represent processes in the software, communication between
processes is represented by means of system network diagrams, described
in section&nbsp;<A HREF="usersguidenode11.html#subsec.snd">A.3.5</A> below.

<P>

<H2><A NAME="SECTION001135000000000000000">&#160;</A><A NAME="TUT-SND">&#160;</A><A NAME="subsec.snd">&#160;</A><A NAME="8837">&#160;</A>
<BR>
9.3.5 System Network Diagrams (TSND)
</H2>

<P>
SNDs are used by JSD&nbsp;[<A
 HREF="usersguidenode14.html#Jackson83">11</A>] to represent communication
between processes.
SNDs are directed graphs with two kinds of nodes, that represent
processes and communications.
A process node must be specified by a PSD, just as a control process
in a DEFD must be specified by a STD.
There are three kinds of communication nodes:
<UL>
<LI><EM>Data streams</EM><A NAME="8841">&#160;</A>, represented by a circle.
These are FIFO queues, somewhat like Unix pipes between two processes.
Communication through a data stream connection is asynchronous.
<LI>
<EM>State vector connections</EM><A NAME="8843">&#160;</A>, 
in which the reader process reads the state of the writer process.
Initiative of the communication lies with the reader.
The writer is not disturbed by the read action.
The communication is synchronous.
A state vector connection is represented by a diamond connected to the
reader by an arrow and to the writer by an undirected line.
The direction of the arrow represents the direction of data flow.
<LI><EM>Controlled data stream connections</EM><A NAME="8845">&#160;</A>, 
represented by a circle with a small vertical line in it.
The circle is connected to a reader and a writer, where an arrow is
used to indicate the direction of data flow.
Communication is synchronous and takes place on the initiative of the
reader.
The reader checks the current state of the writer and if this
satisfies a certain condition, may update this state by sending it a
message.
</UL>
<BR>
<DIV ALIGN="CENTER"><A NAME="fig.snd">&#160;</A><A NAME="8975">&#160;</A>
<TABLE WIDTH="50%">
<CAPTION><STRONG>Figure A.37:</STRONG>
An SND of the robot controller of figure&nbsp;<A HREF="usersguidenode11.html#fig.robot">A.14</A>.</CAPTION>
<TR><TD><IMG
 WIDTH="574" HEIGHT="348"
 SRC="usersguideimg222.gif"
 ALT="\begin{figure}
\centerline{\epsfig{figure=p/snd.eps}} %
%
\end{figure}"></TD></TR>
</TABLE>
</DIV>
<BR>
Figure&nbsp;<A HREF="usersguidenode11.html#fig.snd">A.37</A> shows a SND of  the robot controller
of figure&nbsp;<A HREF="usersguidenode11.html#fig.robot">A.14</A>.
All rectangles represent software entities.
External entities are not shown.
We used the convention to end the name of 
a software entity that represents an
external entity with an <I>S</I> (for ``surrogate''), and to end
the name of a 
software entity  that embodies a software function with an <I>F</I>.
Each of the surrogate and function processes in the model must be
specified by a PSD.

<P>

<H2><A NAME="SECTION001136000000000000000">&#160;</A><A NAME="TUT-RPG">&#160;</A><A NAME="8858">&#160;</A>
<BR>
9.3.6 Recursive Process Graphs (TRPG)
</H2>

<P>
<BR>
<DIV ALIGN="CENTER"><A NAME="fig.rpg1">&#160;</A><A NAME="8977">&#160;</A>
<TABLE WIDTH="50%">
<CAPTION><STRONG>Figure A.38:</STRONG>
A recursive process graph.</CAPTION>
<TR><TD><IMG
 WIDTH="160" HEIGHT="309"
 SRC="usersguideimg223.gif"
 ALT="\begin{figure}
\centerline{\epsfig{figure=p/rpg1.eps}} %
%
\end{figure}"></TD></TR>
</TABLE>
</DIV>
<BR>
<BR>
<DIV ALIGN="CENTER"><A NAME="fig.rpg2">&#160;</A><A NAME="8979">&#160;</A>
<TABLE WIDTH="50%">
<CAPTION><STRONG>Figure A.39:</STRONG>
A recursive process graph with labeled nodes.</CAPTION>
<TR><TD><IMG
 WIDTH="196" HEIGHT="437"
 SRC="usersguideimg224.gif"
 ALT="\begin{figure}
\centerline{\epsfig{figure=p/rpg2.eps}} %
%
\end{figure}"></TD></TR>
</TABLE>
</DIV>
<BR>
A recursive process graph is a rooted directed graph in which the
nodes represent states and the edges represent atomic actions or other
processes.
Figure&nbsp;<A HREF="usersguidenode11.html#fig.rpg1">A.38</A> shows a RPG equivalent to the PSD of
figure&nbsp;<A HREF="usersguidenode11.html#fig.psd">A.35</A>.
Nodes in RPGs can be labeled, just as in Mealy STDs.
Figure&nbsp;<A HREF="usersguidenode11.html#fig.rpg2">A.39</A> shows a RPG with labeled nodes.

<P>
An RPG has an initial node, which is pointed at by a small arrow and<A NAME="8870">&#160;</A>
which can be labeled by the name of the process.

<P>
<BR>
<DIV ALIGN="CENTER"><A NAME="fig.rpg3">&#160;</A><A NAME="8981">&#160;</A>
<TABLE WIDTH="50%">
<CAPTION><STRONG>Figure A.40:</STRONG>
A recursive process graph with a call to another process.</CAPTION>
<TR><TD><IMG
 WIDTH="413" HEIGHT="437"
 SRC="usersguideimg225.gif"
 ALT="\begin{figure}
\centerline{\epsfig{figure=p/rpg3.eps}} %
%
\end{figure}"></TD></TR>
</TABLE>
</DIV>
<BR>
An edge in a RPG can be labeled with the name of an action or of a
process.
If it is labeled with a process name, the transition is equivalent to
performing this process.
Figure&nbsp;<A HREF="usersguidenode11.html#fig.rpg3">A.40</A> illustrates this.
The RPG in figure&nbsp;<A HREF="usersguidenode11.html#fig.rpg3">A.40</A> is equivalent to that of
figure&nbsp;<A HREF="usersguidenode11.html#fig.rpg2">A.39</A>.

<P>
<BR>
<DIV ALIGN="CENTER"><A NAME="fig.rpg4">&#160;</A><A NAME="8983">&#160;</A>
<TABLE WIDTH="50%">
<CAPTION><STRONG>Figure A.41:</STRONG>
A recursive process graph with a recursive call.</CAPTION>
<TR><TD><IMG
 WIDTH="115" HEIGHT="172"
 SRC="usersguideimg226.gif"
 ALT="\begin{figure}
\centerline{\epsfig{figure=p/rpg4.eps}} %
%
\end{figure}"></TD></TR>
</TABLE>
</DIV>
<BR>
The call to another process can be recursive, as illustrated in
figure&nbsp;<A HREF="usersguidenode11.html#fig.rpg4">A.41</A>.
This describes the process with possible traces 
<!-- MATH: ${\mbox{\sf
a}}^n{\mbox{\sf c}}$ -->
<IMG
 WIDTH="28" HEIGHT="14" ALIGN="BOTTOM" BORDER="0"
 SRC="usersguideimg227.gif"
 ALT="${\mbox{\sf
a}}^n{\mbox{\sf c}}$">
for <IMG
 WIDTH="43" HEIGHT="28" ALIGN="MIDDLE" BORDER="0"
 SRC="usersguideimg228.gif"
 ALT="$n \geq 1$">.

<P>
Recursive process graphs are defined formally by Spruit and
Wieringa&nbsp;[<A
 HREF="usersguidenode14.html#Wieringa91-08">26</A>], based upon the idea of recursive transition
networks&nbsp;[<A
 HREF="usersguidenode14.html#Woods70">27</A>].

<P>

<H2><A NAME="SECTION001137000000000000000">&#160;</A><A NAME="TUT-TDT">&#160;</A><A NAME="8889">&#160;</A>
<BR>
9.3.7 Transaction Decomposition Tables (TTDT)
</H2>

<P>
A transaction decomposition table is used to set off software entities
against external atomic system functions, called <EM>transactions</EM>.<A NAME="8891">&#160;</A>
The entries of the table then represent the work performed by the
software entities during the transaction.
For example, figure&nbsp;<A HREF="usersguidenode9.html#TDTExample">7.7</A> says that the transaction
<BR> <I>start_controlling_temperature</I> requires some actions to be taken by
software entities:
A <I>BATCH</I> object must perform action <I>do_temperature_ramp</I>, etc.

<P>
Transaction decomposition tables can also be used in combination with
ERDs and DFDs.
The left-hand column then represents entity types or data stores, and
the entries contain the letters C, R, U or D to indicate whether an
instance of the entity type is created, read, updated or deleted
during the transaction.
The resulting table is also called a <EM>CRUD table</EM>.<A NAME="8897">&#160;</A>

<P>
Transaction decomposition tables can also be used in JSD to discover
communications.
They also help to maintain traceability.
Methodological details are provided elsewhere&nbsp;[<A
 HREF="usersguidenode14.html#Wieringa96-01">22</A>,<A
 HREF="usersguidenode14.html#Wieringa95-03">21</A>].

<P>
<BR><HR><H4>Footnotes</H4>
<DL>
<DT><A NAME="foot8949">...
<I>c</I>&nbsp;</A><A NAME="foot8949"
 HREF="usersguidenode11.html#tex2html176"><SUP>9.1</SUP></A>
<DD>More precisely,
each <EM>existing</EM> instance of <I>E1</I> is related
to <I>n</I> <EM>existing</EM> instances of <I>E2</I>.

<DT><A NAME="foot8960">... <EM>components</EM>.</A><A NAME="foot8960"
 HREF="usersguidenode11.html#tex2html178"><SUP>9.2</SUP></A>
<DD>To be more precise, it is a <EM>labeled</EM> Cartesian
product.

</DL><HR>
<!--Navigation Panel-->
<A NAME="tex2html1041"
 HREF="usersguidenode12.html">
<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next" SRC="next_motif.gif"></A> 
<A NAME="tex2html1037"
 HREF="User.html">
<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up" SRC="up_motif.gif"></A> 
<A NAME="tex2html1031"
 HREF="usersguidenode10.html">
<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous" SRC="previous_motif.gif"></A> 
<A NAME="tex2html1039"
 HREF="usersguidenode1.html">
<IMG WIDTH="65" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="contents" SRC="contents_motif.gif"></A> 
<A NAME="tex2html1040"
 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="tex2html1042"
 HREF="usersguidenode12.html">10. Frequently Asked Questions</A>
<B> Up:</B> <A NAME="tex2html1038"
 HREF="User.html">Toolkit for Conceptual Modeling</A>
<B> Previous:</B> <A NAME="tex2html1032"
 HREF="usersguidenode10.html">8. Tree Editing</A>
<!--End of Navigation Panel-->
<ADDRESS>
<I>Henk van de Zandschulp</I>
<BR><I>2003-01-20</I>
</ADDRESS>
</BODY>
</HTML>