1
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
2
<!--Converted with LaTeX2HTML 98.1p1 release (March 2nd, 1998)
3
originally by Nikos Drakos (nikos@cbl.leeds.ac.uk), CBLU, University of Leeds
4
* revised and updated by: Marcus Hennecke, Ross Moore, Herb Swan
5
* with significant contributions from:
6
Jens Lippmann, Marek Rouchal, Martin Wilck and others -->
9
<TITLE>9. Mini-tutorial on Notation Techniques</TITLE>
10
<META NAME="description" CONTENT="9. Mini-tutorial on Notation Techniques">
11
<META NAME="keywords" CONTENT="User">
12
<META NAME="resource-type" CONTENT="document">
13
<META NAME="distribution" CONTENT="global">
14
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
15
<LINK REL="STYLESHEET" HREF="User.css">
16
<LINK REL="next" HREF="usersguidenode12.html">
17
<LINK REL="previous" HREF="usersguidenode10.html">
18
<LINK REL="up" HREF="User.html">
19
<LINK REL="next" HREF="usersguidenode12.html">
22
<!--Navigation Panel-->
23
<A NAME="tex2html1041"
24
HREF="usersguidenode12.html">
25
<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next" SRC="next_motif.gif"></A>
26
<A NAME="tex2html1037"
28
<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up" SRC="up_motif.gif"></A>
29
<A NAME="tex2html1031"
30
HREF="usersguidenode10.html">
31
<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous" SRC="previous_motif.gif"></A>
32
<A NAME="tex2html1039"
33
HREF="usersguidenode1.html">
34
<IMG WIDTH="65" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="contents" SRC="contents_motif.gif"></A>
35
<A NAME="tex2html1040"
36
HREF="usersguidenode15.html">
37
<IMG WIDTH="43" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="index" SRC="index_motif.gif"></A>
39
<B> Next:</B> <A NAME="tex2html1042"
40
HREF="usersguidenode12.html">10. Frequently Asked Questions</A>
41
<B> Up:</B> <A NAME="tex2html1038"
42
HREF="User.html">Toolkit for Conceptual Modeling</A>
43
<B> Previous:</B> <A NAME="tex2html1032"
44
HREF="usersguidenode10.html">8. Tree Editing</A>
47
<!--End of Navigation Panel-->
48
<!--Table of Child-Links-->
49
<A NAME="CHILD_LINKS"><strong>Subsections</strong></A>
51
<LI><A NAME="tex2html1043"
52
HREF="usersguidenode11.html#SECTION001110000000000000000">9.1 Structured Analysis Notations</A>
54
<LI><A NAME="tex2html1044"
55
HREF="usersguidenode11.html#SECTION001111000000000000000">9.1.1 Entity-Relationship Diagrams (TESD)</A>
57
<LI><A NAME="tex2html1045"
58
HREF="usersguidenode11.html#SECTION001111100000000000000">9.1.1.1 Entity types</A>
59
<LI><A NAME="tex2html1046"
60
HREF="usersguidenode11.html#SECTION001111200000000000000">9.1.1.2 Binary relationships</A>
61
<LI><A NAME="tex2html1047"
62
HREF="usersguidenode11.html#SECTION001111300000000000000">9.1.1.3 Cardinality properties</A>
63
<LI><A NAME="tex2html1048"
64
HREF="usersguidenode11.html#SECTION001111400000000000000">9.1.1.4 Relationships of higher arity</A>
65
<LI><A NAME="tex2html1049"
66
HREF="usersguidenode11.html#SECTION001111500000000000000">9.1.1.5 Attributes</A>
67
<LI><A NAME="tex2html1050"
68
HREF="usersguidenode11.html#SECTION001111600000000000000">9.1.1.6 Associative entities</A>
69
<LI><A NAME="tex2html1051"
70
HREF="usersguidenode11.html#SECTION001111700000000000000">9.1.1.7 Is-a relationships</A>
72
<LI><A NAME="tex2html1052"
73
HREF="usersguidenode11.html#SECTION001112000000000000000">9.1.2 Data and Event Flow Diagrams (TEFD)</A>
75
<LI><A NAME="tex2html1053"
76
HREF="usersguidenode11.html#SECTION001112100000000000000">9.1.2.1 The components of a DFD</A>
77
<LI><A NAME="tex2html1054"
78
HREF="usersguidenode11.html#SECTION001112200000000000000">9.1.2.2 Hierarchical DFDs</A>
79
<LI><A NAME="tex2html1055"
80
HREF="usersguidenode11.html#SECTION001112300000000000000">9.1.2.3 Control processes</A>
81
<LI><A NAME="tex2html1056"
82
HREF="usersguidenode11.html#SECTION001112400000000000000">9.1.2.4 Event flows</A>
83
<LI><A NAME="tex2html1057"
84
HREF="usersguidenode11.html#SECTION001112500000000000000">9.1.2.5 Time-Discrete and time-continuous flows</A>
86
<LI><A NAME="tex2html1058"
87
HREF="usersguidenode11.html#SECTION001113000000000000000">9.1.3 State Transition Diagrams (TSTD)</A>
88
<LI><A NAME="tex2html1059"
89
HREF="usersguidenode11.html#SECTION001114000000000000000">9.1.4 Transaction-Use Tables (TTUT)</A>
90
<LI><A NAME="tex2html1060"
91
HREF="usersguidenode11.html#SECTION001115000000000000000">9.1.5 Function-Entity Type Tables (TFET)</A>
92
<LI><A NAME="tex2html1061"
93
HREF="usersguidenode11.html#SECTION001116000000000000000">9.1.6 Function Refinement Trees (TFRT)</A>
95
<LI><A NAME="tex2html1062"
96
HREF="usersguidenode11.html#SECTION001120000000000000000">9.2 UML Notations</A>
98
<LI><A NAME="tex2html1063"
99
HREF="usersguidenode11.html#SECTION001121000000000000000">9.2.1 Use case diagrams (TUCD)</A>
101
<LI><A NAME="tex2html1064"
102
HREF="usersguidenode11.html#SECTION001121100000000000000">9.2.1.1 Actors</A>
103
<LI><A NAME="tex2html1065"
104
HREF="usersguidenode11.html#SECTION001121200000000000000">9.2.1.2 Use cases</A>
106
<LI><A NAME="tex2html1066"
107
HREF="usersguidenode11.html#SECTION001122000000000000000">9.2.2 Static structure diagrams (TSSD)</A>
109
<LI><A NAME="tex2html1067"
110
HREF="usersguidenode11.html#SECTION001122100000000000000">9.2.2.1 Stereotypes and properties</A>
111
<LI><A NAME="tex2html1068"
112
HREF="usersguidenode11.html#SECTION001122200000000000000">9.2.2.2 Behavior</A>
113
<LI><A NAME="tex2html1069"
114
HREF="usersguidenode11.html#SECTION001122300000000000000">9.2.2.3 Objects</A>
116
<LI><A NAME="tex2html1070"
117
HREF="usersguidenode11.html#SECTION001123000000000000000">9.2.3 Activity diagrams (TATD)</A>
119
<LI><A NAME="tex2html1071"
120
HREF="usersguidenode11.html#SECTION001123100000000000000">9.2.3.1 Activity</A>
121
<LI><A NAME="tex2html1072"
122
HREF="usersguidenode11.html#SECTION001123200000000000000">9.2.3.2 Transition</A>
123
<LI><A NAME="tex2html1073"
124
HREF="usersguidenode11.html#SECTION001123300000000000000">9.2.3.3 Choice nodes</A>
125
<LI><A NAME="tex2html1074"
126
HREF="usersguidenode11.html#SECTION001123400000000000000">9.2.3.4 Fork and join nodes</A>
127
<LI><A NAME="tex2html1075"
128
HREF="usersguidenode11.html#SECTION001123500000000000000">9.2.3.5 Initial and final state</A>
130
<LI><A NAME="tex2html1076"
131
HREF="usersguidenode11.html#SECTION001124000000000000000">9.2.4 Statechart diagrams (TSCD)</A>
132
<LI><A NAME="tex2html1077"
133
HREF="usersguidenode11.html#SECTION001125000000000000000">9.2.5 Collaboration diagrams (TCBD)</A>
135
<LI><A NAME="tex2html1078"
136
HREF="usersguidenode11.html#SECTION001125100000000000000">9.2.5.1 Messages</A>
138
<LI><A NAME="tex2html1079"
139
HREF="usersguidenode11.html#SECTION001126000000000000000">9.2.6 Component diagrams (TCPD)</A>
140
<LI><A NAME="tex2html1080"
141
HREF="usersguidenode11.html#SECTION001127000000000000000">9.2.7 Deployment diagrams (TDPD)</A>
143
<LI><A NAME="tex2html1081"
144
HREF="usersguidenode11.html#SECTION001130000000000000000">9.3 Miscellaneous Notations</A>
146
<LI><A NAME="tex2html1082"
147
HREF="usersguidenode11.html#SECTION001131000000000000000">9.3.1 Classic Entity-Relationship Diagrams (TERD)</A>
149
<LI><A NAME="tex2html1083"
150
HREF="usersguidenode11.html#SECTION001131100000000000000">9.3.1.1 Entity types</A>
151
<LI><A NAME="tex2html1084"
152
HREF="usersguidenode11.html#SECTION001131200000000000000">9.3.1.2 Binary relationships</A>
153
<LI><A NAME="tex2html1085"
154
HREF="usersguidenode11.html#SECTION001131300000000000000">9.3.1.3 Cardinality constraints</A>
155
<LI><A NAME="tex2html1086"
156
HREF="usersguidenode11.html#SECTION001131400000000000000">9.3.1.4 Relationships of higher arity</A>
157
<LI><A NAME="tex2html1087"
158
HREF="usersguidenode11.html#SECTION001131500000000000000">9.3.1.5 Value types</A>
159
<LI><A NAME="tex2html1088"
160
HREF="usersguidenode11.html#SECTION001131600000000000000">9.3.1.6 Attributes</A>
161
<LI><A NAME="tex2html1089"
162
HREF="usersguidenode11.html#SECTION001131700000000000000">9.3.1.7 Is-a relationships</A>
164
<LI><A NAME="tex2html1090"
165
HREF="usersguidenode11.html#SECTION001132000000000000000">9.3.2 Class-Relationship Diagrams (TCRD)</A>
167
<LI><A NAME="tex2html1091"
168
HREF="usersguidenode11.html#SECTION001132100000000000000">9.3.2.1 Classes</A>
169
<LI><A NAME="tex2html1092"
170
HREF="usersguidenode11.html#SECTION001132200000000000000">9.3.2.2 Relationships</A>
171
<LI><A NAME="tex2html1093"
172
HREF="usersguidenode11.html#SECTION001132300000000000000">9.3.2.3 Is-a relationships</A>
174
<LI><A NAME="tex2html1094"
175
HREF="usersguidenode11.html#SECTION001133000000000000000">9.3.3 Data Flow Diagrams (TDFD)</A>
176
<LI><A NAME="tex2html1095"
177
HREF="usersguidenode11.html#SECTION001134000000000000000">9.3.4 Process Structure Diagrams (TPSD)</A>
178
<LI><A NAME="tex2html1096"
179
HREF="usersguidenode11.html#SECTION001135000000000000000">9.3.5 System Network Diagrams (TSND)</A>
180
<LI><A NAME="tex2html1097"
181
HREF="usersguidenode11.html#SECTION001136000000000000000">9.3.6 Recursive Process Graphs (TRPG)</A>
182
<LI><A NAME="tex2html1098"
183
HREF="usersguidenode11.html#SECTION001137000000000000000">9.3.7 Transaction Decomposition Tables (TTDT)</A>
185
<!--End of Table of Child-Links-->
188
<H1><A NAME="SECTION001100000000000000000"> </A>
189
<A NAME="MiniTut"> </A><A NAME="8283"> </A><A NAME="8284"> </A>
191
9. Mini-tutorial on Notation Techniques
195
This appendix contains a short tutorial on the use of
196
the notation techniques that are supported by TCM.
197
Detailed information on the notations of structured analysis and
198
the UML is given in R.J. Wieringa, <EM>Design
199
Methods for reactive Systems: Yourdon, Statemate and the UML</EM>,
200
Department of Computer Science, University of Twente,
202
The miscellaneous notations are documented in [<A
203
HREF="usersguidenode14.html#Wieringa96-01">22</A>].
207
<H1><A NAME="SECTION001110000000000000000">
208
9.1 Structured Analysis Notations</A>
213
<H2><A NAME="SECTION001111000000000000000"> </A><A NAME="TUT-ESD"> </A><A NAME="8290"> </A>
215
9.1.1 Entity-Relationship Diagrams (TESD)
219
The TCM convention for TESD is described in detail
221
HREF="usersguidenode14.html#Wieringa99-01">23</A>].
225
<H3><A NAME="SECTION001111100000000000000"> </A><A NAME="8293"> </A>
231
As usual, a named rectangle represents a named entity type.
235
<H3><A NAME="SECTION001111200000000000000"> </A><A NAME="8295"> </A>
237
9.1.1.2 Binary relationships
241
Binary relationships are presented by lines.
245
<H3><A NAME="SECTION001111300000000000000"> </A><A NAME="8297"> </A>
247
9.1.1.3 Cardinality properties
251
Cardinality properties are represented by
252
annotations placed at the end points of these lines.
253
(Cardinality properties are also called ``cardinality constraints''
256
<DIV ALIGN="CENTER"><A NAME="fig.ESDcard"> </A><A NAME="8900"> </A>
258
<CAPTION><STRONG>Figure A.1:</STRONG>
259
The placement of Cardinality constraints.</CAPTION>
261
WIDTH="424" HEIGHT="42"
262
SRC="usersguideimg176.gif"
264
\centerline{\epsfig{figure=p/ESDcard.eps}} %
266
\end{figure}"></TD></TR>
270
For example, in figure <A HREF="usersguidenode11.html#fig.ESDcard">A.1</A>, each business has an employment
271
relationship to more than zero persons and each person has 0 or 1
272
employment relationships to a business.
273
The end points of the line can also be annotated with the role that the
274
entity at that end of the line plays in the relationship.
275
Figure <A HREF="usersguidenode11.html#fig.ESDroles">A.2</A> gives an example.<A NAME="8304"> </A>
277
<DIV ALIGN="CENTER"><A NAME="fig.ESDroles"> </A><A NAME="8902"> </A>
279
<CAPTION><STRONG>Figure A.2:</STRONG>
280
The placement of role names.</CAPTION>
282
WIDTH="435" HEIGHT="39"
283
SRC="usersguideimg177.gif"
285
\centerline{\epsfig{figure=p/ESDroles.eps}} %
287
\end{figure}"></TD></TR>
294
<DIV ALIGN="CENTER"><A NAME="fig.ESDcon"> </A><A NAME="8904"> </A>
296
<CAPTION><STRONG>Figure A.3:</STRONG>
297
The meaning of cardinality properties.</CAPTION>
299
WIDTH="308" HEIGHT="39"
300
SRC="usersguideimg178.gif"
302
\centerline{\epsfig{figure=p/ESDcon.eps}} %
304
\end{figure}"></TD></TR>
308
In general, a cardinality property is represented by a set of natural
309
numbers (see figure <A HREF="usersguidenode6.html#ESDCardSyntax">4.9</A> for the syntax).
310
For example, if <I>c</I> is a set of natural numbers, the property
311
in figure <A HREF="usersguidenode11.html#fig.ESDcon">A.3</A> is that each instance of <I>E1</I> is related
312
to <I>n</I> instances of <I>E2</I>, where <IMG
313
WIDTH="29" HEIGHT="28" ALIGN="MIDDLE" BORDER="0"
314
SRC="usersguideimg179.gif"
318
each <EM>existing</EM> instance of <I>E1</I> is related
319
to <I>n</I> <EM>existing</EM> instances of <I>E2</I>.)
320
If no cardinality property is shown, the convention is that <I>c</I> is
321
the entire set of natural numbers.
322
For example, in figure <A HREF="usersguidenode11.html#fig.ERDcon">A.25</A>, each instance of <I>E2</I> is
324
to any number instances of <I>E1</I>.
325
This includes the case that it is related to 0 instances of <I>E1</I>.
329
<DIV ALIGN="CENTER"><A NAME="fig.ESDreverse"> </A><A NAME="8906"> </A>
331
<CAPTION><STRONG>Figure A.4:</STRONG>
332
The line representation of binary relationships is direction-independent.</CAPTION>
334
WIDTH="378" HEIGHT="39"
335
SRC="usersguideimg180.gif"
337
\centerline{\epsfig{figure=p/ESDreverse.eps}} %
339
\end{figure}"></TD></TR>
343
Note that there is no natural reading direction for a
345
For example, figure <A HREF="usersguidenode11.html#fig.ESDreverse">A.4</A> conveys the same information as
346
figure <A HREF="usersguidenode11.html#fig.ESDcard">A.1</A>.
347
If there is a reading direction, one can adorn the relationship name
348
with a small arrow that indicates this.
349
See figure <A HREF="usersguidenode11.html#fig.direction">A.5</A>.
351
<DIV ALIGN="CENTER"><A NAME="fig.direction"> </A><A NAME="8908"> </A>
353
<CAPTION><STRONG>Figure A.5:</STRONG>
354
Reading direction of a
355
relationship name.</CAPTION>
357
WIDTH="332" HEIGHT="51"
358
SRC="usersguideimg181.gif"
360
\centerline{\epsfig{figure=p/direction.eps}} %
362
\end{figure}"></TD></TR>
366
Often, a directed relationship name is really a role name of one of
367
the participating entity types.
371
<DIV ALIGN="CENTER"><A NAME="fig.ESDmanyone"> </A><A NAME="8910"> </A>
373
<CAPTION><STRONG>Figure A.6:</STRONG>
374
Different conventions for representing the same constraints.
375
TESD supports the convention used in the top diagram.</CAPTION>
377
WIDTH="319" HEIGHT="599"
378
SRC="usersguideimg182.gif"
380
\centerline{\epsfig{figure=p/ESDmanyone.eps}} %
382
\end{figure}"></TD></TR>
387
<DIV ALIGN="CENTER"><A NAME="fig.ESDmay"> </A><A NAME="8912"> </A>
389
<CAPTION><STRONG>Figure A.7:</STRONG>
390
Different conventions for representing the same constraints.
391
TESD supports the convention used in the top diagram.</CAPTION>
393
WIDTH="319" HEIGHT="507"
394
SRC="usersguideimg183.gif"
396
\centerline{\epsfig{figure=p/ESDmay.eps}} %
398
\end{figure}"></TD></TR>
402
There are many other conventions to represent binary relationships.
403
Figure <A HREF="usersguidenode11.html#fig.ESDmanyone">A.6</A> shows different ways of representing the following
407
Each existing <I>E1</I> is related to at least one existing <I>E2</I> and
409
Each existing <I>E2</I> is related to exactly one existing <I>E1</I>.
410
</UL>Figure <A HREF="usersguidenode11.html#fig.ESDmay">A.7</A> shows different ways of representing the following
414
Each existing <I>E1</I> is related to at any number (including 0)
415
existing <I>E2</I> and
417
Each existing <I>E2</I> is related to exactly one existing <I>E1</I>.
421
<H3><A NAME="SECTION001111400000000000000"> </A><A NAME="8361"> </A>
423
9.1.1.4 Relationships of higher arity
427
<A NAME="8362"> </A>
429
<DIV ALIGN="CENTER"><A NAME="fig.ESDdiam"> </A><A NAME="8914"> </A>
431
<CAPTION><STRONG>Figure A.8:</STRONG>
432
The diamond representation for relationships.</CAPTION>
434
WIDTH="435" HEIGHT="56"
435
SRC="usersguideimg184.gif"
437
\centerline{\epsfig{figure=p/ESDdiam.eps}} %
439
\end{figure}"></TD></TR>
443
A relationship is a Cartesian product of two or more entity
444
types, called its <EM>components</EM>.
445
(To be more precise, it is a <EM>labeled</EM> Cartesian
446
product.)<A NAME="8369"> </A><A NAME="8370"> </A>
447
Relationships can always be represented by a
448
diamond, connected by lines to the boxes that represent its
451
represent the projection functions of a Cartesian product on
454
figure <A HREF="usersguidenode11.html#fig.ESDdiam">A.8</A> contains exactly the same information as
455
figure <A HREF="usersguidenode11.html#fig.ESDcard">A.1</A>.
458
Relationships with arity higher than 2 cannot be represented by a
460
They can only be represented by a diamond.
461
Figure <A HREF="usersguidenode11.html#fig.ESDternary">A.9</A> gives an example.
463
<DIV ALIGN="CENTER"><A NAME="fig.ESDternary"> </A><A NAME="8916"> </A>
465
<CAPTION><STRONG>Figure A.9:</STRONG>
466
A ternary relationship with a
467
cardinality property.</CAPTION>
469
WIDTH="435" HEIGHT="153"
470
SRC="usersguideimg185.gif"
472
\centerline{\epsfig{figure=p/ESDternary.eps}} %
474
\end{figure}"></TD></TR>
478
The figure also illustrates the notation for a cardinality property
479
of a relationship with arity higher than 2.
480
A cardinality property is expressed by an expression <I>c</I> written at
481
the end of a line, close to an entity type box.
482
It represents the number of instances of that entity that
483
participate in the relationship simultaneously.
484
The property in figure <A HREF="usersguidenode11.html#fig.ESDternary">A.9</A> says that each transport
485
company participates in at least one delivery.
486
(This is not very realistic but is does illustrate the convention.)
490
<H3><A NAME="SECTION001111500000000000000"> </A><A NAME="8380"> </A>
497
<DIV ALIGN="CENTER"><A NAME="fig.attr"> </A><A NAME="8918"> </A>
499
<CAPTION><STRONG>Figure A.10:</STRONG>
500
Representation of attributes.</CAPTION>
502
WIDTH="89" HEIGHT="76"
503
SRC="usersguideimg186.gif"
505
\centerline{\epsfig{figure=p/attr.eps}} %
507
\end{figure}"></TD></TR>
511
Entity attributes are represented by listing them in a separate
512
compartment below the entity type name.
513
Representation of entity attributes is optional.
517
<H3><A NAME="SECTION001111600000000000000">
518
9.1.1.6 Associative entities</A>
522
If a relationship itself has attributes, it is represented by an
523
entity box that contains the relationship name and the attribute
524
declarations, connected to the relationship line or relationship
525
diamond with a dashed line.
526
See figures <A HREF="usersguidenode11.html#fig.assoc1">A.11</A> and <A HREF="usersguidenode11.html#fig.assoc2">A.12</A> for illustrations.
528
<DIV ALIGN="CENTER"><A NAME="fig.assoc1"> </A><A NAME="8920"> </A>
530
<CAPTION><STRONG>Figure A.11:</STRONG>
531
Representation of associative
532
entities (line representation).</CAPTION>
534
WIDTH="366" HEIGHT="160"
535
SRC="usersguideimg187.gif"
537
\centerline{\epsfig{figure=p/assoc1.eps}} %
539
\end{figure}"></TD></TR>
544
<DIV ALIGN="CENTER"><A NAME="fig.assoc2"> </A><A NAME="8922"> </A>
546
<CAPTION><STRONG>Figure A.12:</STRONG>
547
Representation of associative
548
entities (diamond representation).</CAPTION>
550
WIDTH="401" HEIGHT="172"
551
SRC="usersguideimg188.gif"
553
\centerline{\epsfig{figure=p/assoc2.eps}} %
555
\end{figure}"></TD></TR>
562
<H3><A NAME="SECTION001111700000000000000"> </A><A NAME="8397"> </A>
564
9.1.1.7 Is-a relationships
569
<DIV ALIGN="CENTER"><A NAME="fig.ESDisa"> </A><A NAME="8924"> </A>
571
<CAPTION><STRONG>Figure A.13:</STRONG>
572
The representation of is-a relationships.</CAPTION>
574
WIDTH="319" HEIGHT="39"
575
SRC="usersguideimg189.gif"
577
\centerline{\epsfig{figure=p/ESDisa.eps}} %
579
\end{figure}"></TD></TR>
583
An is-a relationship is a binary relationship that is an inclusion
585
For example, figure <A HREF="usersguidenode11.html#fig.ESDisa">A.13</A> shows that each <I>CAR</I> instance
586
is also a <I>VEHICLE</I> instance.
587
Extensionally, the set of all possible cars is a subset of the set of all
589
Intensionally, the set of properties shared by all cars includes the set of
590
properties shared by all vehicles.
591
<I>CAR</I> is called a <EM>specialization</EM> of <I>VEHICLE</I> and <I>VEHICLE</I> is called a <EM>generalization</EM> of
592
<I>CAR</I>.<A NAME="8411"> </A><A NAME="8412"> </A>
595
If there is more than one specialization of an entity type, then these must
596
be grouped into <EM>specialization groups</EM>.<A NAME="8414"> </A>
597
This is represented by connecting the rectangles representing the
599
to a small circle<A NAME="8415"> </A>
600
called the <EM>taxonomy junction</EM> or <EM>generalization node</EM> and
601
connecting this with an <I>is-a</I> arrow to the rectangle representing the
602
generalization. The generalization node must be annotated as follows:
605
A ``<I>d</I>'' means that the
606
specializations are mutually disjoint.<A NAME="8421"> </A>
608
An ``<I>c</I>'' means that the specializations
609
jointly covers the generalization.<A NAME="8423"> </A>
611
A ``<I>dc</I>'' means the conjunction of ``<I>d</I>'' and
612
``<I>c</I>'', i.e. the specializations partitions the generalization.
613
</UL><A NAME="8428"> </A>
614
A generalization can be specialized by any number of specialization groups.
615
For example, figure <A HREF="usersguidenode6.html#ESDTaxonomyExample">4.10</A> means the following:
617
<LI>Cars are vehicles and trucks are vehicles.
619
The union of the set of all cars and all trucks equals the set of all
621
So vehicles are trucks or cars (or both).
622
<LI>Diesel vehicles are vehicles and gas vehicles are vehicles.
624
There is no vehicle both a diesel and a gas vehicle.
625
<LI>There may be vehicles that are neither diesel nor gas vehicles.
629
<H2><A NAME="SECTION001112000000000000000"> </A><A NAME="TUT-EFD"> </A><A NAME="subsec.control"> </A><A NAME="8435"> </A>
631
9.1.2 Data and Event Flow Diagrams (TEFD)
635
Data flow diagrams (DFDs)
636
are are available in two TCM editors, called TDFD
637
(one of the miscellaneous editors)
638
and TEFD (one of the structured analysis editors).
639
TEFD allows you to do everything that TDFD can, and it additionally
640
allows you to draw control processes, event flows and to distinguish
641
time-discrete from time-continuous flows.
642
This section explains both editors.
643
DFDs are described in detail in [<A
644
HREF="usersguidenode14.html#Wieringa99-01">23</A>].
648
<H3><A NAME="SECTION001112100000000000000">
649
9.1.2.1 The components of a DFD</A>
653
A DFD is a directed graph with three kinds of nodes:
655
<LI>Circles represent processes, also called data transformations or<A NAME="8439"> </A>
656
functions. A process is some computation by a software system.
657
There are two kinds of processes: Data processes and control processes
658
(the latter are not supported in TDFD). TEFD supports both processes.
659
<LI>Squares represent external entities, these are entities with<A NAME="8440"> </A>
660
which the software system must interact.
661
<LI>Two parallel lines represent a data store, which is a piece of<A NAME="8441"> </A>
662
software memory (e.g. a file or a variable).
663
</UL>The directed edges represent data flows between these nodes.<A NAME="8443"> </A>
666
In figure <A HREF="usersguidenode8.html#DFDExample1">6.3</A>, there are three processes, <I>Confirm
667
Registration</I>, <I>Check Request</I> and <I>Register
669
When the external entity <I>STUDENT</I> sends a message
670
<I>test_request</I>, which is a request to participate in a
671
test, then the process
672
<I>Check Request</I> retrieves the identifier of the test from
673
the data store <I>TESTS</I>
674
and the student identifier from the <I>STUDENTS</I>
675
data store (the data stores are most likely implemented as files or
677
If the test and student exist, and the student is allowed to
678
participate in the test, then process
680
students</I> stores this fact in the <I>TEST_REGISTRATIONS</I> data
683
Registration</I> confirms this to the external entity.
684
To make the DFD in figure <A HREF="usersguidenode8.html#DFDExample1">6.3</A> more precise, this model must be
685
supplemented with precise process
686
specifications, and a specification of the structure of the data
687
stores and data flows.
691
<H3><A NAME="SECTION001112200000000000000"> </A><A NAME="8458"> </A><A NAME="8459"> </A>
693
9.1.2.2 Hierarchical DFDs
697
DFDs can be hierarchical.
698
This means that a process can be specified by means of another DFD,
699
which has the same external interface as the process being specified.
700
Such a process is called a <EM>compound</EM> process.<A NAME="8461"> </A><A NAME="8462"> </A>
701
A process specified in another way (e.g. by means of a piece of text)
702
is called <EM>primitive</EM>.<A NAME="8464"> </A>
703
This can be indicated by the letter <I>P</I> in the node that
704
represents the process.
707
Compound processes give rise to a tree of DFDs.
708
Processes in this tree are labeled by means of a Dewey numbering<A NAME="8466"> </A>
709
system that indicates the location of the process in the tree.
710
For example, process 1.2 is the process with label 2 in the DFD that
711
specifies the compound process with label 1.
712
The current version of TCM does not support hierarchical DFD editing.
716
<H3><A NAME="SECTION001112300000000000000"> </A><A NAME="8468"> </A>
718
9.1.2.3 Control processes
722
DEFDs extend DFDs with a new kind of node, the control process, and
723
new kinds of edges: event flows and time-continuous flows.
724
See subsection <A HREF="usersguidenode11.html#TUT-DFD">A.3.3</A> for DFDs.
725
A control process is represented by a dashed circle and represents an
727
It must be specified by means of a STD that has the same interface as
729
This means that the event flows entering the control process must
730
occur as events in the Mealy STD, and vice versa, and that the event
732
control process must occur as actions in the STD, and vice versa.
733
Figure <A HREF="usersguidenode11.html#fig.robot">A.14</A> contains a DEFD of which the control process is
734
specified in figure <A HREF="usersguidenode11.html#fig.robotctr">A.15</A>.
736
<DIV ALIGN="CENTER"><A NAME="fig.robot"> </A><A NAME="8926"> </A>
738
<CAPTION><STRONG>Figure A.14:</STRONG>
739
A DEFD for a robot control process.</CAPTION>
741
WIDTH="562" HEIGHT="374"
742
SRC="usersguideimg190.gif"
744
\centerline{\epsfig{figure=p/robot.eps}} %
746
\end{figure}"></TD></TR>
751
<DIV ALIGN="CENTER"><A NAME="fig.robotctr"> </A><A NAME="8928"> </A>
753
<CAPTION><STRONG>Figure A.15:</STRONG>
754
STD for the robot control process of figure <A HREF="usersguidenode11.html#fig.robot">A.14</A>.</CAPTION>
756
WIDTH="304" HEIGHT="533"
757
SRC="usersguideimg191.gif"
759
\centerline{\epsfig{figure=p/robotctr.eps}} %
761
\end{figure}"></TD></TR>
768
<H3><A NAME="SECTION001112400000000000000"> </A><A NAME="8482"> </A>
774
Event flows are represented by dashed arrows.
775
An event flow can carry a signal without any data contents.
776
The precise meaning depends upon the method that uses this technique.
777
See for example the YSM manual [<A
778
HREF="usersguidenode14.html#YSM93">31</A>].
782
<H3><A NAME="SECTION001112500000000000000"> </A><A NAME="8485"> </A><A NAME="8486"> </A>
784
9.1.2.5 Time-Discrete and time-continuous flows
788
A time-discrete flow carries a value that changes in discrete steps, a
789
time-continuous flow carries a value that changes in a continuous way.
790
Time-discrete flows are represented by arrows with a single arrowhead,
791
time-continuous flows are represented by arrows with a double arrowhead.
792
Again, the precise meaning depends upon the method used.
796
<H2><A NAME="SECTION001113000000000000000"> </A><A NAME="TUT-STD"> </A><A NAME="8489"> </A>
798
9.1.3 State Transition Diagrams (TSTD)
802
State transition diagrams (Mealy, Moore and statechart)
804
HREF="usersguidenode14.html#Wieringa99-01">23</A>]
808
<DIV ALIGN="CENTER"><A NAME="fig.std"> </A><A NAME="8930"> </A>
810
<CAPTION><STRONG>Figure A.16:</STRONG>
811
The Mealy representation of state transition diagrams.</CAPTION>
813
WIDTH="110" HEIGHT="214"
814
SRC="usersguideimg192.gif"
816
\centerline{\epsfig{figure=p/std.eps}} %\end{figure}"></TD></TR>
820
TCM supports the Mealy notation for finite state transition diagrams
821
(figure <A HREF="usersguidenode11.html#fig.std">A.16</A>).
822
States are named, and are represented by rectangles.<A NAME="8496"> </A>
823
State transitions are represented by arrows and are labeled by
824
<I>event [guard] / action</I>
825
pairs.<A NAME="8498"> </A><A NAME="8499"> </A><A NAME="8500"> </A>
826
The event is the <EM>trigger</EM><A NAME="8502"> </A><A NAME="8503"> </A>
827
of the transition and can be viewed as the occurrence of an input.
828
The guard is a condition.<A NAME="8504"> </A>
829
The precise meaning of the guard depends upon the method in which the
831
A minimalistic interpretation is that if the guard is false, an
832
occurrence of the event will not trigger the transition.
833
A more closed interpretation is that additionally, if the guard is
834
true, an occurrence of the event will trigger the transition.
837
The action part of the transition label is the output action generated
841
Each Mealy STD must have an initial state, pointed at by an arrow that<A NAME="8505"> </A>
842
leaves from no node, and that can be labeled by an initialization
843
action.<A NAME="8506"> </A><A NAME="8507"> </A>
846
TCM also has <EM>decision points</EM><A NAME="8509"> </A>
847
which are intermediary states
848
that the machine may have between system transactions. Decision
849
points are represented by a hexagon.
851
<DIV ALIGN="CENTER"><A NAME="fig.transit"> </A><A NAME="8932"> </A>
853
<CAPTION><STRONG>Figure A.17:</STRONG>
854
State transition diagrams.</CAPTION>
856
WIDTH="501" HEIGHT="583"
857
SRC="usersguideimg193.gif"
859
\centerline{\epsfig{figure=p/transit.eps}} %
861
\end{figure}"></TD></TR>
865
Figure <A HREF="usersguidenode11.html#fig.transit">A.17</A> shows the a Mealy diagram for a simple coffee
866
machine in which at two points, an external process is triggered (the
867
actions that start with <I>T:</I>) that must send the Mealy
869
While waiting for an answer, the machine is in the decision point.
872
Mealy machines are used in Yourdon-style structured analysis, where
873
they are used to specify control processes [<A
874
HREF="usersguidenode14.html#YSM93">31</A>].
875
The interface of the control process must equal the interface of the
877
See section <A HREF="usersguidenode11.html#subsec.control">A.1.2</A> for control processes.
881
<H2><A NAME="SECTION001114000000000000000"> </A><A NAME="TUT-TUT"> </A><A NAME="8520"> </A>
883
9.1.4 Transaction-Use Tables (TTUT)
887
A transaction-use table is a simple way to discover entity types from
888
required system transactions.
889
The leftmost column lists external system functions and the top row
890
lists the basic Create, Read, Update and Delete actions.
891
The entries list the entity types or relationships that are created,
892
read, updated or deleted during the function.
893
See figure <A HREF="usersguidenode9.html#TUTExample">7.8</A>.
894
Elaborate examples are given elsewhere [<A
895
HREF="usersguidenode14.html#Wieringa96-01">22</A>].
899
<H2><A NAME="SECTION001115000000000000000"> </A><A NAME="TUT-FET"> </A><A NAME="8525"> </A>
901
9.1.5 Function-Entity Type Tables (TFET)
905
The top row of a function-entity
906
table lists system functions and the leftmost
907
column represents, for example, entity types.
908
The entries contain C, R, U or D,
909
to indicate that this function Creates, Reads, Updates or Deletes
910
entities of this type.
911
Instead of entity types, the leftmost column may list relationships,
912
or subject areas, or data stores in a DFD, with corresponding changes
913
in the meaning of the CRUD entries.
916
A function-entity type table is a kind of traceability table
918
HREF="usersguidenode14.html#Wieringa99-01">23</A>]).
919
It is almost the same as a transaction
920
decomposition table (see section <A HREF="usersguidenode11.html#TUT-TDT">A.3.7</A>).
921
Function-entity types are used in Information Engineering to find
924
by clustering subject areas and functions in such a way to minimize
925
data flows between the clusters.
927
HREF="usersguidenode14.html#Wieringa96-01">22</A>] for details and examples of their use in
928
Information Engineering.
932
<H2><A NAME="SECTION001116000000000000000"> </A><A NAME="TUT-FRT"> </A><A NAME="8531"> </A>
934
9.1.6 Function Refinement Trees (TFRT)
938
A function refinement tree is a tree in which the root represents the
939
entire system mission and the leaves represent system functions.
940
The hierarchy of nodes represents the refinement of functions into
942
All nodes in the tree represent <EM>external</EM> functions.<A NAME="8533"> </A>
945
A FRT can be used in combination with a hierarchical DFD to represent
946
the hierarchy of DFDs.
947
It is used in information engineering to represent external functions
948
of an information system [<A
949
HREF="usersguidenode14.html#Wieringa96-01">22</A>].
950
Of course, a tree can be used to represent any hierarchical
951
decomposition and TCM imposes no constraints on the syntax of the tree.
955
<H1><A NAME="SECTION001120000000000000000">
956
9.2 UML Notations</A>
960
This section lists the UML notations available in TCM, as they are
962
HREF="usersguidenode14.html#Wieringa99-01">23</A>].
963
This is a subset of the full UML notation.
967
<H2><A NAME="SECTION001121000000000000000"> </A><A NAME="TUT-UCD"> </A><A NAME="8539"> </A>
969
9.2.1 Use case diagrams (TUCD)
973
A use case is a functionality of a system, and actor is a user (person
974
or device) of the system.
975
A use case diagram is a graph in which the nodes represent actors and
976
use cases, and the lines represent connections between use cases and
978
The meaning of a line is that the actor is involved in a use case.
981
A use case diagram is actually a special case of a class diagram with
982
two special kinds of nodes.
983
Nodes of the same kind can be connected by a generalization arrow.
987
<H3><A NAME="SECTION001121100000000000000">
992
An actor is represented by a match stick figure or by a rectangle
994
WIDTH="20" HEIGHT="28" ALIGN="MIDDLE" BORDER="0"
995
SRC="usersguideimg194.gif"
996
ALT="$\ll$"><I>actor</I><IMG
997
WIDTH="20" HEIGHT="28" ALIGN="MIDDLE" BORDER="0"
998
SRC="usersguideimg195.gif"
1000
Both shapes can be labeled by an actor name.
1001
Two actors can be connected by a generalization arrow.
1002
Actor names must be unique.
1003
Use ``duplicate node'' if you want to represent one actor several
1004
times in the diagram.
1008
<H3><A NAME="SECTION001121200000000000000">
1009
9.2.1.2 Use cases</A>
1013
A use case is represented by an ellipse.
1015
Two use cases can be connected by a generalization arrow.
1019
<H2><A NAME="SECTION001122000000000000000"> </A><A NAME="TUT-SSD"> </A><A NAME="8545"> </A>
1021
9.2.2 Static structure diagrams (TSSD)
1025
A static structure diagram is an extension of an ER diagram.
1026
What is an entity in an ESD is an object in a SSD.
1027
The extensions of TSSD with respect to TESD are the
1028
possibility to declare the behavior of an object and to represent
1030
There is a change in terminology when we change from ESDs to SSDs:
1031
<DIV ALIGN="CENTER">
1032
<TABLE CELLPADDING=3 BORDER="1">
1033
<TR><TD ALIGN="LEFT">Entity-relationship diagram</TD>
1034
<TD ALIGN="LEFT">UML static structure diagram</TD>
1036
<TR><TD ALIGN="LEFT">entity type</TD>
1037
<TD ALIGN="LEFT">class</TD>
1039
<TR><TD ALIGN="LEFT">entity</TD>
1040
<TD ALIGN="LEFT">object</TD>
1042
<TR><TD ALIGN="LEFT">relationship</TD>
1043
<TD ALIGN="LEFT">association</TD>
1045
<TR><TD ALIGN="LEFT">tuple</TD>
1046
<TD ALIGN="LEFT">link</TD>
1048
<TR><TD ALIGN="LEFT">associative entity</TD>
1049
<TD ALIGN="LEFT">associative object</TD>
1051
<TR><TD ALIGN="LEFT">cardinality property</TD>
1052
<TD ALIGN="LEFT">multiplicity property</TD>
1057
<H3><A NAME="SECTION001122100000000000000">
1058
9.2.2.1 Stereotypes and properties</A>
1061
We can give a diagram element a special meaning by labeling it with a
1062
special name between
1063
<!-- MATH: $\langle\hspace{-0.15em}\langle$ -->
1065
WIDTH="14" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
1066
SRC="usersguideimg196.gif"
1067
ALT="$\langle\hspace{-0.15em}\langle$">guillemets
1068
<!-- MATH: $\rangle\hspace{-0.15em}\rangle$ -->
1070
WIDTH="14" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
1071
SRC="usersguideimg197.gif"
1072
ALT="$\rangle\hspace{-0.15em}\rangle$">.
1073
Such a diagram element is called a <B>stereotype</B>.
1074
For example, in a static structure diagram, we can specialize classes
1075
into stereotypes with a special meaning, by writing the stereotype
1076
name in guillemets above the class name.
1077
See figure <A HREF="usersguidenode11.html#fig.stereo">A.18</A>.
1079
<DIV ALIGN="CENTER"><A NAME="fig.stereo"> </A><A NAME="8934"> </A>
1081
<CAPTION><STRONG>Figure A.18:</STRONG>
1082
Stereotypes and properties.</CAPTION>
1084
WIDTH="233" HEIGHT="109"
1085
SRC="usersguideimg198.gif"
1087
\centerline{\epsfig{figure=p/stereo.eps}} %
1089
\end{figure}"></TD></TR>
1095
Figure <A HREF="usersguidenode11.html#fig.stereo">A.18</A> also shows that we can annotate the name
1096
compartment of a class box with properties.
1097
A property is represented by a user-defined property name and a
1099
This is included in the name compartment as a comment between curly
1100
braces, and it has no UML-defined semantics.
1101
You are free to include any text between curly braces.
1105
<H3><A NAME="SECTION001122200000000000000">
1106
9.2.2.2 Behavior</A>
1110
The behavior of an object is declared in a third compartment below the
1111
attribute compartment of a class box.
1112
The UML allows the declaration of the operations that the instances of
1113
the class can perform and of the signals that the instances can
1116
HREF="usersguidenode14.html#Wieringa99-01">23</A>] for details.
1120
<H3><A NAME="SECTION001122300000000000000">
1125
An object is represented by a named rectangle with an attribute
1128
<DIV ALIGN="CENTER"><A NAME="fig.objects"> </A><A NAME="8936"> </A>
1130
<CAPTION><STRONG>Figure A.19:</STRONG>
1131
Representation of objects.</CAPTION>
1133
WIDTH="582" HEIGHT="161"
1134
SRC="usersguideimg199.gif"
1136
\centerline{\epsfig{figure=p/objects.eps}} %
1138
\end{figure}"></TD></TR>
1142
The name of an instance is underlined.
1143
The attribute compartment contains the attribute values of the
1145
See figure <A HREF="usersguidenode11.html#fig.objects">A.19</A>.
1146
Notice the association from John to the class <I>City</I>.
1147
This tells us that John has exactly one birthplace but it does not
1148
tell us which one this is, because <I>City</I> is a class.
1152
<H2><A NAME="SECTION001123000000000000000"> </A><A NAME="TUT-ATD"> </A><A NAME="8571"> </A>
1154
9.2.3 Activity diagrams (TATD)
1158
An activity diagram is a graph in which the nodes represent activities
1159
and the arrows represent transitions between activities.
1160
Figure <A HREF="usersguidenode11.html#fig.coffee">A.20</A> gives an example.
1164
<DIV ALIGN="CENTER"><A NAME="fig.coffee"> </A><A NAME="8938"> </A>
1166
<CAPTION><STRONG>Figure A.20:</STRONG>
1167
An activity diagram.</CAPTION>
1169
WIDTH="457" HEIGHT="663"
1170
SRC="usersguideimg200.gif"
1172
\centerline{\epsfig{figure=p/coffee.eps}} %
1174
\end{figure}"></TD></TR>
1181
<H3><A NAME="SECTION001123100000000000000">
1182
9.2.3.1 Activity</A>
1186
Activities are represented by two parallel lines connected by
1188
The name of the activity can be entered in the shape.
1192
<H3><A NAME="SECTION001123200000000000000">
1193
9.2.3.2 Transition</A>
1197
Transitions are represented by unlabeled arrows.
1198
A transition represents the completion of the activity from which it
1203
<H3><A NAME="SECTION001123300000000000000">
1204
9.2.3.3 Choice nodes</A>
1208
A choice node is represented by a diamond.
1209
A transition that emanates from a diamond can be labeled by a
1210
<I>[condition]</I> that tells us when this branch is taken.
1211
A choice point is not a state of the system.
1215
<H3><A NAME="SECTION001123400000000000000">
1216
9.2.3.4 Fork and join nodes</A>
1220
Fork and join nodes are represented by fat horizontal or vertical
1222
If more than one arrow leaves the node, it is a fork node and there
1223
must be exactly one arrow entering it.
1224
A join node represents the start of two or more parallel processes.
1227
If more than one arrow terminates at the node, it is a join node and
1228
there must be exactly one arrow that departs from it.
1229
A join node represents the merging of two or more parallel process
1234
<H3><A NAME="SECTION001123500000000000000">
1235
9.2.3.5 Initial and final state</A>
1239
The start of an activity diagram is represented by a bullet.
1240
There must be exactly one bullet in a completed diagram.
1243
A final state of an activity is represented by a bull's eye.
1244
There must be at least one final state in an activity completed diagram.
1248
<H2><A NAME="SECTION001124000000000000000"> </A><A NAME="TUT-SCD"> </A><A NAME="8585"> </A>
1250
9.2.4 Statechart diagrams (TSCD)
1254
TSCD is used to draw <EM>statecharts.</EM>
1255
Statecharts are based on state-transition diagrams known from TSTD.
1258
A statechart describes the behaviour of a system,
1259
i.e., the possible orders of events and states.
1260
A state in a statechart may consist of one or several <EM>state nodes.</EM>
1261
A state node can be refined in two ways:
1264
<DT><STRONG>An <I>or</I> node</STRONG>
1265
<DD>serves to describe substates.
1266
If the state of the system contains the <I>or</I> node,
1267
it contains exactly one of the subnodes.
1270
The subnodes of an <I>or</I> node are simply drawn inside the
1272
The initial subnode has an arrow starting at a black dot.
1275
<DT><STRONG>An <I>and</I> node</STRONG>
1276
<DD>serves to describe parallel behaviour.
1277
If the state of the system contains the <I>and</I> node,
1278
it contains all of the subnodes.
1279
These subnodes are typically refined further,
1280
to describe in which state the single parallel components can stay.
1283
The subnodes of an <I>and</I> node are drawn as compartments which
1284
partition the <I>and</I> node.
1285
As there is no space left for the <I>and</I> node's name, it is
1286
attached to a small box on the outside.
1289
</DL>Possible state changes are indicated by <EM>transitions.</EM>
1290
They are drawn as arrows with a label
1291
<!-- MATH: $\mathsf{e} [\mathsf{g}] / \mathsf{a}$ -->
1293
WIDTH="44" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
1294
SRC="usersguideimg201.gif"
1295
ALT="$\mathsf{e} [\mathsf{g}] / \mathsf{a}$">,
1297
<!-- MATH: $\mathsf{e}$ -->
1299
WIDTH="11" HEIGHT="13" ALIGN="BOTTOM" BORDER="0"
1300
SRC="usersguideimg202.gif"
1302
denotes the event which triggers the transition,
1304
<!-- MATH: $\mathsf{g}$ -->
1306
WIDTH="13" HEIGHT="28" ALIGN="MIDDLE" BORDER="0"
1307
SRC="usersguideimg203.gif"
1309
is a guard (the transition can only be taken if the guard holds),
1311
<!-- MATH: $\mathsf{a}$ -->
1313
WIDTH="12" HEIGHT="13" ALIGN="BOTTOM" BORDER="0"
1314
SRC="usersguideimg204.gif"
1316
denotes the action executed when the transition is taken
1317
(for example, send an event to another statechart).
1320
In addition to these basic elements,
1321
one can indicate the initial state with an arrow from a black dot
1322
and the final state with a bull's eye.
1325
For an example of a statechart, see figure <A HREF="usersguidenode11.html#fig.statechart">A.21</A>.
1326
The statechart describes a fan's behaviour.
1327
This kind of fan can produce a cold or hot, and a slow or fast air stream.
1328
Its initial state is <I>Off</I>.
1330
it enters the <I>and</I> node <I>On</I> and its subnodes.
1331
Here, it again selects the initial nodes <I>Slow</I> and <I>Cold</I>.
1332
If the user sends event <I>f</I> to the system,
1333
it switches to <I>Fast</I>.
1334
When the user switches the fan off (by sending an <I>off</I> event),
1335
the fan leaves the <I>On</I> node and all its subnodes
1336
(forgetting the slow/fast and cold/hot settings),
1337
and enters the <I>Off</I> node again.
1339
<DIV ALIGN="CENTER"><A NAME="fig.statechart"> </A><A NAME="8940"> </A>
1341
<CAPTION><STRONG>Figure A.21:</STRONG>
1342
Example of a statechart.</CAPTION>
1344
WIDTH="519" HEIGHT="278"
1345
SRC="usersguideimg205.gif"
1347
\center{\epsfig{file=p/statechart.eps} }
1348
\end{figure}"></TD></TR>
1354
<H2><A NAME="SECTION001125000000000000000"> </A><A NAME="TUT-CBD"> </A><A NAME="8623"> </A>
1356
9.2.5 Collaboration diagrams (TCBD)
1360
A collaboration diagram is an object diagram that shows the objects
1361
and links involved in a scenario, and also shows the messages passed
1366
<H3><A NAME="SECTION001125100000000000000">
1367
9.2.5.1 Messages</A>
1371
In addition to other UML diagrams a collaboration diagram has
1372
message flows representing messages being sent between objects via
1374
figure <A HREF="usersguidenode11.html#fig.messages">A.22</A> for an example of the initial dialog
1375
between a client and a ATM.
1379
<DIV ALIGN="CENTER"><A NAME="fig.messages"> </A><A NAME="8942"> </A>
1381
<CAPTION><STRONG>Figure A.22:</STRONG>
1382
Collaboration diagram messages.</CAPTION>
1384
WIDTH="317" HEIGHT="94"
1385
SRC="usersguideimg206.gif"
1387
\centerline{\epsfig{figure=p/tut_messages.eps}} %
1389
\end{figure}"></TD></TR>
1396
<H2><A NAME="SECTION001126000000000000000"> </A><A NAME="TUT-CPD"> </A><A NAME="8632"> </A>
1398
9.2.6 Component diagrams (TCPD)
1402
A UML component diagram is a directed graph in which the nodes
1403
represent components and the edges, which are directed, represent
1405
A component is, roughly, any software-like resource delivered during
1406
software development or needed by the delivered software.
1407
This includes the executables and sources of the software system,
1408
utilities needed by the software system, shared libraries, etc.
1409
A dependency may be a compilation dependency, and import dependency,
1411
The exact meaning of the nodes and edges must be described in the
1412
diagram documentation.
1415
The interface of an executable component is represented by small
1416
rectangles protruding from the component box.
1419
Each class in the class model must be allocated to an executable
1421
This can be represented in a component diagram by enclosing a class icon
1422
inside a component icon.
1423
Alternatively, it can be represented by drawing a dependency arrow from
1424
the class to the component(s) it is allocated to.
1428
<H2><A NAME="SECTION001127000000000000000"> </A><A NAME="TUT-DPD"> </A><A NAME="8635"> </A>
1430
9.2.7 Deployment diagrams (TDPD)
1434
A UML deployment diagram is a graph in which the nodes represent
1435
resources and the edges represent communication channels.
1436
A resource is a hardware/software combination that offers computing
1438
This includes mainframes, servers, workstations, PC's, laptops,
1439
handheld computers, organizers, mobile telephones, faxes, printers,
1441
A channel is any hardware/software combination that offers communication
1442
possibility to resources.
1443
This includes local and wide area networks, wireless communications,
1447
Each executable component can be allocated to one or more resources.
1448
This can be represented in a UML deployment diagram by drawing a
1449
component icon inside a resource icon.
1450
Alternatively, it can be represented by drawing a dependency arrow from
1451
the component to the resource(s) it is allocated to.
1455
<H1><A NAME="SECTION001130000000000000000">
1456
9.3 Miscellaneous Notations</A>
1461
<H2><A NAME="SECTION001131000000000000000"> </A><A NAME="TUT-ERD"> </A><A NAME="8639"> </A>
1463
9.3.1 Classic Entity-Relationship Diagrams (TERD)
1467
The TCM convention for ERDs is described in detail
1469
HREF="usersguidenode14.html#Wieringa96-01">22</A>].
1473
<H3><A NAME="SECTION001131100000000000000"> </A><A NAME="8642"> </A>
1475
9.3.1.1 Entity types
1479
As usual, a named rectangle represents a named entity type.
1483
<H3><A NAME="SECTION001131200000000000000"> </A><A NAME="8644"> </A>
1485
9.3.1.2 Binary relationships
1489
Binary relationships are presented by lines.
1493
<H3><A NAME="SECTION001131300000000000000"> </A><A NAME="8646"> </A>
1495
9.3.1.3 Cardinality constraints
1499
Cardinality constraints are represented by
1500
annotations placed at the end points of these lines.
1502
<DIV ALIGN="CENTER"><A NAME="fig.ERDcard"> </A><A NAME="8944"> </A>
1504
<CAPTION><STRONG>Figure A.23:</STRONG>
1505
The placement of cardinality constraints.</CAPTION>
1507
WIDTH="354" HEIGHT="45"
1508
SRC="usersguideimg207.gif"
1510
\centerline{\epsfig{figure=p/ERDcard.eps}} %
1512
\end{figure}"></TD></TR>
1516
For example, in figure <A HREF="usersguidenode11.html#fig.ERDcard">A.23</A>, each business has an employment
1517
relationship to more than zero persons and each person has 0 or 1
1518
employment relationships to a business.
1519
The end points of the line can also be annotated with the role that the
1520
entity at that end of the line plays in the relationship.
1521
Figure <A HREF="usersguidenode11.html#fig.ERDroles">A.24</A> gives an example.<A NAME="8653"> </A>
1523
<DIV ALIGN="CENTER"><A NAME="fig.ERDroles"> </A><A NAME="8946"> </A>
1525
<CAPTION><STRONG>Figure A.24:</STRONG>
1526
The placement of role names.</CAPTION>
1528
WIDTH="458" HEIGHT="45"
1529
SRC="usersguideimg208.gif"
1531
\centerline{\epsfig{figure=p/ERDroles.eps}} %
1533
\end{figure}"></TD></TR>
1540
<DIV ALIGN="CENTER"><A NAME="fig.ERDcon"> </A><A NAME="8948"> </A>
1542
<CAPTION><STRONG>Figure A.25:</STRONG>
1543
The meaning of cardinality constraints.</CAPTION>
1545
WIDTH="343" HEIGHT="45"
1546
SRC="usersguideimg209.gif"
1548
\centerline{\epsfig{figure=p/ERDcon.eps}} %
1550
\end{figure}"></TD></TR>
1554
In general, a cardinality constraint is represented by a set of natural
1555
numbers (see figure <A HREF="usersguidenode6.html#CardSyntax">4.4</A> for the syntax).
1556
For example, if <I>c</I> is a set of natural numbers, the constraint
1557
in figure <A HREF="usersguidenode11.html#fig.ERDcon">A.25</A> is that each instance of <I>E1</I> is related
1558
to <I>n</I> instances of <I>E2</I>, where <IMG
1559
WIDTH="29" HEIGHT="28" ALIGN="MIDDLE" BORDER="0"
1560
SRC="usersguideimg179.gif"
1562
<I>c</I> <A NAME="tex2html176"
1563
HREF="#foot8949"><SUP>9.1</SUP></A>.
1564
If no constraint label is shown, the convention is that the constraint is
1565
the entire set of natural numbers, i.e. it is no constraint.
1566
For example, in figure <A HREF="usersguidenode11.html#fig.ERDcon">A.25</A>, each instance of <I>E2</I> is
1568
to any number instances of <I>E1</I>.
1569
This includes the case that it is related to 0 instances of <I>E1</I>.
1573
<DIV ALIGN="CENTER"><A NAME="fig.ERDarrow"> </A><A NAME="8951"> </A>
1575
<CAPTION><STRONG>Figure A.26:</STRONG>
1576
The arrow representation of many-one constraints.</CAPTION>
1578
WIDTH="319" HEIGHT="126"
1579
SRC="usersguideimg210.gif"
1581
\centerline{\epsfig{figure=p/ERDarrow.eps}} %
1583
\end{figure}"></TD></TR>
1587
There are various conventions for the placement of the cardinality
1588
constraints, all of which are a source of confusion.
1589
The choice made in TCM is motivated as follows.
1590
We use the convention that a cardinality constraint of 1 can be abbreviated
1592
So the two diagrams in figure <A HREF="usersguidenode11.html#fig.ERDarrow">A.26</A> are equivalent as far as
1593
their cardinality constraints are concerned.
1594
They both mean that each person is related to exactly 1 business and that
1595
each business is related to at least one person.
1596
This means that the relationship is a mathematical function from persons to
1597
businesses, which explains the arrow convention.
1598
To facilitate a smooth transformation between these two representations,
1599
the cardinality constraint labels must be placed where they now are.
1603
<DIV ALIGN="CENTER"><A NAME="fig.ERDreverse"> </A><A NAME="8953"> </A>
1605
<CAPTION><STRONG>Figure A.27:</STRONG>
1606
The line representation of binary relationships is direction-independent.</CAPTION>
1608
WIDTH="297" HEIGHT="45"
1609
SRC="usersguideimg211.gif"
1611
\centerline{\epsfig{figure=p/ERDreverse.eps}} %
1613
\end{figure}"></TD></TR>
1617
Note that the naming of the relationship usually must change when we switch
1618
to the arrow notation.
1619
In the line notation, there is no natural reading direction for the
1621
For example, figure <A HREF="usersguidenode11.html#fig.ERDreverse">A.27</A> conveys the same information as
1622
figure <A HREF="usersguidenode11.html#fig.ERDcard">A.23</A>.
1623
In the arrow representation, by contrast, there is a natural reading
1624
direction and we adapt the relationship name accordingly.
1625
Often, the role name of the entity type at the arrowhead becomes the
1630
<DIV ALIGN="CENTER"><A NAME="fig.ERDmanyone"> </A><A NAME="8955"> </A>
1632
<CAPTION><STRONG>Figure A.28:</STRONG>
1633
Different conventions supported by the
1634
classic TERD editor for representing the same constraints. </CAPTION>
1636
WIDTH="342" HEIGHT="137"
1637
SRC="usersguideimg212.gif"
1639
\centerline{\epsfig{figure=p/ERDmanyone.eps}} %
1641
\end{figure}"></TD></TR>
1646
<DIV ALIGN="CENTER"><A NAME="fig.ERDmay"> </A><A NAME="8957"> </A>
1648
<CAPTION><STRONG>Figure A.29:</STRONG>
1649
Different conventions supported by the
1650
classic TERD editor for representing the same constraints.</CAPTION>
1652
WIDTH="342" HEIGHT="137"
1653
SRC="usersguideimg213.gif"
1655
\centerline{\epsfig{figure=p/ERDmay.eps}} %
1657
\end{figure}"></TD></TR>
1661
There are many other conventions to represent binary relationships.
1662
Figure <A HREF="usersguidenode11.html#fig.ERDmanyone">A.28</A> shows different ways of representing the following
1666
Each existing <I>E1</I> is related to at least one existing <I>E2</I> and
1668
Each existing <I>E2</I> is related to exactly one existing <I>E1</I>.
1669
</UL>Figure <A HREF="usersguidenode11.html#fig.ERDmay">A.29</A> shows different ways of representing the following
1673
Each existing <I>E1</I> is related to at any number (including 0)
1674
existing <I>E2</I> and
1676
Each existing <I>E2</I> is related to exactly one existing <I>E1</I>.
1680
<H3><A NAME="SECTION001131400000000000000"> </A><A NAME="8710"> </A>
1682
9.3.1.4 Relationships of higher arity
1686
<A NAME="8711"> </A>
1688
<DIV ALIGN="CENTER"><A NAME="fig.ERDdiam"> </A><A NAME="8959"> </A>
1690
<CAPTION><STRONG>Figure A.30:</STRONG>
1691
The diamond representation for relationships.</CAPTION>
1693
WIDTH="412" HEIGHT="45"
1694
SRC="usersguideimg214.gif"
1696
\centerline{\epsfig{figure=p/ERDdiam.eps}} %
1698
\end{figure}"></TD></TR>
1702
A relationship is a Cartesian product of two or more entity
1703
types, called its <EM>components</EM>.<A NAME="tex2html178"
1704
HREF="#foot8960"><SUP>9.2</SUP></A><A NAME="8718"> </A><A NAME="8719"> </A>
1705
Relationships of arity higher than 2 are represented by a
1706
diamond, connected by arrows to the boxes that represent its components.
1707
These arrows represent the projection functions of a Cartesian product on
1709
Figure <A HREF="usersguidenode11.html#fig.ERDdiam">A.30</A> contains exactly the same information as
1710
figure <A HREF="usersguidenode11.html#fig.ERDcard">A.23</A>.
1711
Note the placement of the cardinality constraints, which is at the root of
1713
This agrees with the placement convention of constraints on relationship
1715
In fact, one can view the arrows in figure <A HREF="usersguidenode11.html#fig.ERDdiam">A.30</A> as binary
1716
relationships between <I>EMPLOYMENT</I> and its two components.
1717
The meaning is that each business is related to at least one employment
1718
instance (and hence to exactly one person),
1719
and that each person is related to exactly one employment instance (and
1720
hence to exactly one business).
1721
This agrees with the meaning of figure <A HREF="usersguidenode11.html#fig.ERDcard">A.23</A>.
1725
<H3><A NAME="SECTION001131500000000000000"> </A><A NAME="8726"> </A>
1731
Value types (often called ``data types'') are represented by ovals.
1735
<H3><A NAME="SECTION001131600000000000000"> </A><A NAME="8728"> </A>
1741
Entity attributes are represented by arrows from an entity type to an
1743
and relationship attributes are represented by arrows from a relationship
1745
This means that the TCM convention does not distinguish between
1746
``ordinary'' relationships, which do not have attributes, and ``associative
1747
entity types'', which are relationships that can have attributes.
1751
<H3><A NAME="SECTION001131700000000000000"> </A><A NAME="8730"> </A>
1753
9.3.1.7 Is-a relationships
1758
<DIV ALIGN="CENTER"><A NAME="fig.ERDisa"> </A><A NAME="8962"> </A>
1760
<CAPTION><STRONG>Figure A.31:</STRONG>
1761
The representation of is-a relationships.</CAPTION>
1763
WIDTH="285" HEIGHT="45"
1764
SRC="usersguideimg215.gif"
1766
\centerline{\epsfig{figure=p/ERDisa.eps}} %
1768
\end{figure}"></TD></TR>
1772
An is-a relationship is a binary relationship that is an inclusion
1774
For example, figure <A HREF="usersguidenode11.html#fig.ERDisa">A.31</A> shows that each <I>CAR</I> instance
1775
is also a <I>VEHICLE</I> instance.
1776
Extensionally, the set of all possible cars is a subset of the set of all
1778
Intensionally, the set of properties shared by all cars includes the set of
1779
properties shared by all vehicles.
1780
<I>CAR</I> is called a <EM>specialization</EM> of <I>VEHICLE</I> and <I>VEHICLE</I> is called a <EM>generalization</EM> of
1781
<I>CAR</I>.<A NAME="8744"> </A><A NAME="8745"> </A>
1784
If there is more than one specialization of an entity type, then these must
1785
be grouped into <EM>specialization groups</EM>.<A NAME="8747"> </A>
1786
This is represented by connecting the rectangles representing the
1788
to a small circle<A NAME="8748"> </A>
1789
called the <EM>taxonomy junction</EM> and connecting this with an
1790
<I>is-a</I> arrow to the rectangle representing the generalization.
1791
The taxonomy junction must be annotated as follows:
1794
A ``<I>d</I>'' means that the
1795
specializations are mutually disjoint.<A NAME="8753"> </A>
1797
An ``<I>e</I>'' means that the specializations
1798
jointly exhaust the generalization.<A NAME="8755"> </A>
1800
A ``<I>de</I>'' means the conjunction of ``<I>d</I>'' and
1801
``<I>e</I>'', i.e. the specializations partition the generalization.
1802
</UL><A NAME="8760"> </A>
1803
A generalization can be specialized by any number of specialization groups.
1804
For example, figure <A HREF="usersguidenode6.html#TaxonomyExample">4.5</A> means the following:
1806
<LI>Cars are vehicles and trucks are vehicles.
1808
The union of the set of all cars and all trucks equals the set of all
1810
So vehicles are trucks or cars (or both).
1811
<LI>Diesel vehicles are vehicles and gas vehicles are vehicles.
1813
There is no vehicle both a diesel and a gas vehicle.
1814
<LI>There may be vehicles that are neither diesel nor gas vehicles.
1818
<H2><A NAME="SECTION001132000000000000000"> </A><A NAME="TUT-CRD"> </A><A NAME="8766"> </A>
1820
9.3.2 Class-Relationship Diagrams (TCRD)
1825
<H3><A NAME="SECTION001132100000000000000"> </A><A NAME="8768"> </A>
1831
The CRD notation of TCM follows the convention that a class is represented
1832
by a rectangle subdivided into three areas, that contain, from top to
1833
bottom, the class name, the attributes, and the events that can occur in
1834
the life of the class instances.
1835
TCM can hide one or both of the event and attribute areas from view.
1836
<A NAME="8769"> </A>
1840
<H3><A NAME="SECTION001132200000000000000"> </A><A NAME="8771"> </A><A NAME="8772"> </A>
1842
9.3.2.2 Relationships
1845
<DIV ALIGN="CENTER"><A NAME="fig.crd"> </A><A NAME="8964"> </A>
1847
<CAPTION><STRONG>Figure A.32:</STRONG>
1848
The CRD representation of relationships.</CAPTION>
1850
WIDTH="435" HEIGHT="45"
1851
SRC="usersguideimg216.gif"
1853
\centerline{\epsfig{figure=p/crd.eps}} %
1855
\end{figure}"></TD></TR>
1859
Relationships are represented by rectangles just as classes are.
1860
They are connected to their components by means of dashed arrows.
1861
The meaning is exactly the same as in the ERD case.
1862
Figure <A HREF="usersguidenode11.html#fig.crd">A.32</A> has exactly the same information content as
1863
figures <A HREF="usersguidenode11.html#fig.ERDcard">A.23</A>, <A HREF="usersguidenode11.html#fig.ERDreverse">A.27</A> and <A HREF="usersguidenode11.html#fig.ERDdiam">A.30</A>.
1864
The line representation (figure <A HREF="usersguidenode11.html#fig.ERDcard">A.23</A>) is also allowed in the
1866
The advantage of the CRD convention over the diamond representation
1867
is that a rectangle allows easier
1868
placement of text inside the area.
1869
In addition, the CRD convention used in TCM allows representation of such
1870
complex structures as represented in figure <A HREF="usersguidenode11.html#fig.complex">A.33</A>, which cannot
1871
be represented in the ERD convention.
1873
<DIV ALIGN="CENTER"><A NAME="fig.complex"> </A><A NAME="8966"> </A>
1875
<CAPTION><STRONG>Figure A.33:</STRONG>
1876
The CRD convention can represent complex mathematical structures.</CAPTION>
1878
WIDTH="306" HEIGHT="278"
1879
SRC="usersguideimg217.gif"
1881
\centerline{\epsfig{figure=p/complex.eps}} %
1883
\end{figure}"></TD></TR>
1887
Figure <A HREF="usersguidenode11.html#fig.complex">A.33</A> represents the following structures.
1888
(To reduce clutter in the notation, we ignore the fact that
1889
relationships are actually <EM>labeled</EM> Cartesian products.)<UL>
1891
WIDTH="17" HEIGHT="28" ALIGN="MIDDLE" BORDER="0"
1892
SRC="usersguideimg218.gif"
1896
<!-- MATH: $\rightarrow$ -->
1898
WIDTH="20" HEIGHT="14" ALIGN="BOTTOM" BORDER="0"
1899
SRC="usersguideimg129.gif"
1900
ALT="$\rightarrow$">
1903
<!-- MATH: $\rightarrow$ -->
1905
WIDTH="20" HEIGHT="14" ALIGN="BOTTOM" BORDER="0"
1906
SRC="usersguideimg129.gif"
1907
ALT="$\rightarrow$">
1910
WIDTH="17" HEIGHT="28" ALIGN="MIDDLE" BORDER="0"
1911
SRC="usersguideimg218.gif"
1918
<H3><A NAME="SECTION001132300000000000000"> </A><A NAME="8792"> </A>
1920
9.3.2.3 Is-a relationships
1925
<DIV ALIGN="CENTER"><A NAME="fig.static"> </A><A NAME="8969"> </A>
1927
<CAPTION><STRONG>Figure A.34:</STRONG>
1928
Static specialization.</CAPTION>
1930
WIDTH="343" HEIGHT="252"
1931
SRC="usersguideimg219.gif"
1933
\centerline{\epsfig{figure=p/static.eps}} %
1935
\end{figure}"></TD></TR>
1939
The CRD convention for representing is-a relationships extends the ERD
1940
convention with constructs to represent static and dynamic specialization.
1941
A static specialization group is represented by a small closed circle,
1942
called a taxonomy junction,
1944
a dynamic specialization group is represented by a dashed circle, called a
1945
mode junction (see figure <A HREF="usersguidenode6.html#CRRepresentations">4.12</A>).<A NAME="8798"> </A>
1946
In figure <A HREF="usersguidenode11.html#fig.static">A.34</A>, an instance of <I>CAR</I> will never
1947
become an instance of <I>AIRPLANE</I> and vice versa.
1948
An instance is a member of a specialization for life.
1949
By contrast, in figure <A HREF="usersguidenode6.html#ModeExample">4.16</A>, an instance of <I>MARRIED PERSON</I>
1950
may move to another of the subclasses of <I>PERSON</I>.
1951
Here, an instance is an instance of a specialization only for part of its
1953
We call these specialization <EM>mode classes</EM>.<A NAME="8806"> </A>
1954
For example, <I>MARRIED PERSON</I> is a mode class of <I>PERSON</I>, because a married person is a mode of a person.
1955
Details of static and dynamic specialization are given<A NAME="8809"> </A><A NAME="8810"> </A>
1957
HREF="usersguidenode14.html#Wieringa94-01">24</A>,<A
1958
HREF="usersguidenode14.html#Wieringa95-04">25</A>].
1962
<H2><A NAME="SECTION001133000000000000000"> </A><A NAME="TUT-DFD"> </A><A NAME="8814"> </A>
1964
9.3.3 Data Flow Diagrams (TDFD)
1968
TDFD contains a subset of TEFD. Please see section <A HREF="usersguidenode11.html#TUT-EFD">A.1.2</A>.
1972
<H2><A NAME="SECTION001134000000000000000"> </A><A NAME="TUT-PSD"> </A><A NAME="8818"> </A><A NAME="8819"> </A>
1974
9.3.4 Process Structure Diagrams (TPSD)
1979
<DIV ALIGN="CENTER"><A NAME="fig.psd"> </A><A NAME="8971"> </A>
1981
<CAPTION><STRONG>Figure A.35:</STRONG>
1982
A process structure diagram.</CAPTION>
1984
WIDTH="582" HEIGHT="333"
1985
SRC="usersguideimg220.gif"
1987
\centerline{\epsfig{figure=p/psd.eps}} %
1989
\end{figure}"></TD></TR>
1993
Process structure diagrams are used in JSD to represent behavior.
1994
A PSD is a tree in which the nodes are
1996
HREF="usersguidenode14.html#Jackson83">11</A>,<A
1997
HREF="usersguidenode14.html#Wieringa96-01">22</A>].
1998
The leaves of the tree represent atomic actions and the root
1999
represents the entire process.
2000
Sequence is represented by a left-to-right ordering of the children of
2002
Iteration is represented by an asterisk label and choice by a small
2003
circle in the nodes that represent the options.
2004
Figure <A HREF="usersguidenode11.html#fig.psd">A.35</A> gives an example.
2007
PSDs are equivalent to regular expressions.
2011
<DIV ALIGN="CENTER"><A NAME="fig.psdstd"> </A><A NAME="8973"> </A>
2013
<CAPTION><STRONG>Figure A.36:</STRONG>
2014
A Mealy diagram roughly equivalent
2015
to figure <A HREF="usersguidenode11.html#fig.psd">A.35</A>.</CAPTION>
2017
WIDTH="133" HEIGHT="425"
2018
SRC="usersguideimg221.gif"
2020
\centerline{\epsfig{figure=p/psdstd.eps}} %
2022
\end{figure}"></TD></TR>
2026
A Mealy machine roughly equivalent to this is shown in
2027
figure <A HREF="usersguidenode11.html#fig.psdstd">A.36</A>.
2028
The names of the nodes in a PSD can be reused as state names in a
2030
However, the Mealy convention forces us to categorize an action as an
2031
input or output action, whereas in PSDs this is not the case.
2032
In figure <A HREF="usersguidenode11.html#fig.psdstd">A.36</A>
2033
we arbitrarily categorized all PSD actions as output actions.
2036
In JSD, PSDs are used to represent processes in reality and to
2037
represent processes in the machine.
2038
If used to represent processes in reality, common actions between PSDs
2039
represent synchronous communication between these processes.
2040
If used to represent processes in the software, communication between
2041
processes is represented by means of system network diagrams, described
2042
in section <A HREF="usersguidenode11.html#subsec.snd">A.3.5</A> below.
2046
<H2><A NAME="SECTION001135000000000000000"> </A><A NAME="TUT-SND"> </A><A NAME="subsec.snd"> </A><A NAME="8837"> </A>
2048
9.3.5 System Network Diagrams (TSND)
2052
SNDs are used by JSD [<A
2053
HREF="usersguidenode14.html#Jackson83">11</A>] to represent communication
2055
SNDs are directed graphs with two kinds of nodes, that represent
2056
processes and communications.
2057
A process node must be specified by a PSD, just as a control process
2058
in a DEFD must be specified by a STD.
2059
There are three kinds of communication nodes:
2061
<LI><EM>Data streams</EM><A NAME="8841"> </A>, represented by a circle.
2062
These are FIFO queues, somewhat like Unix pipes between two processes.
2063
Communication through a data stream connection is asynchronous.
2065
<EM>State vector connections</EM><A NAME="8843"> </A>,
2066
in which the reader process reads the state of the writer process.
2067
Initiative of the communication lies with the reader.
2068
The writer is not disturbed by the read action.
2069
The communication is synchronous.
2070
A state vector connection is represented by a diamond connected to the
2071
reader by an arrow and to the writer by an undirected line.
2072
The direction of the arrow represents the direction of data flow.
2073
<LI><EM>Controlled data stream connections</EM><A NAME="8845"> </A>,
2074
represented by a circle with a small vertical line in it.
2075
The circle is connected to a reader and a writer, where an arrow is
2076
used to indicate the direction of data flow.
2077
Communication is synchronous and takes place on the initiative of the
2079
The reader checks the current state of the writer and if this
2080
satisfies a certain condition, may update this state by sending it a
2084
<DIV ALIGN="CENTER"><A NAME="fig.snd"> </A><A NAME="8975"> </A>
2086
<CAPTION><STRONG>Figure A.37:</STRONG>
2087
An SND of the robot controller of figure <A HREF="usersguidenode11.html#fig.robot">A.14</A>.</CAPTION>
2089
WIDTH="574" HEIGHT="348"
2090
SRC="usersguideimg222.gif"
2092
\centerline{\epsfig{figure=p/snd.eps}} %
2094
\end{figure}"></TD></TR>
2098
Figure <A HREF="usersguidenode11.html#fig.snd">A.37</A> shows a SND of the robot controller
2099
of figure <A HREF="usersguidenode11.html#fig.robot">A.14</A>.
2100
All rectangles represent software entities.
2101
External entities are not shown.
2102
We used the convention to end the name of
2103
a software entity that represents an
2104
external entity with an <I>S</I> (for ``surrogate''), and to end
2106
software entity that embodies a software function with an <I>F</I>.
2107
Each of the surrogate and function processes in the model must be
2112
<H2><A NAME="SECTION001136000000000000000"> </A><A NAME="TUT-RPG"> </A><A NAME="8858"> </A>
2114
9.3.6 Recursive Process Graphs (TRPG)
2119
<DIV ALIGN="CENTER"><A NAME="fig.rpg1"> </A><A NAME="8977"> </A>
2121
<CAPTION><STRONG>Figure A.38:</STRONG>
2122
A recursive process graph.</CAPTION>
2124
WIDTH="160" HEIGHT="309"
2125
SRC="usersguideimg223.gif"
2127
\centerline{\epsfig{figure=p/rpg1.eps}} %
2129
\end{figure}"></TD></TR>
2134
<DIV ALIGN="CENTER"><A NAME="fig.rpg2"> </A><A NAME="8979"> </A>
2136
<CAPTION><STRONG>Figure A.39:</STRONG>
2137
A recursive process graph with labeled nodes.</CAPTION>
2139
WIDTH="196" HEIGHT="437"
2140
SRC="usersguideimg224.gif"
2142
\centerline{\epsfig{figure=p/rpg2.eps}} %
2144
\end{figure}"></TD></TR>
2148
A recursive process graph is a rooted directed graph in which the
2149
nodes represent states and the edges represent atomic actions or other
2151
Figure <A HREF="usersguidenode11.html#fig.rpg1">A.38</A> shows a RPG equivalent to the PSD of
2152
figure <A HREF="usersguidenode11.html#fig.psd">A.35</A>.
2153
Nodes in RPGs can be labeled, just as in Mealy STDs.
2154
Figure <A HREF="usersguidenode11.html#fig.rpg2">A.39</A> shows a RPG with labeled nodes.
2157
An RPG has an initial node, which is pointed at by a small arrow and<A NAME="8870"> </A>
2158
which can be labeled by the name of the process.
2162
<DIV ALIGN="CENTER"><A NAME="fig.rpg3"> </A><A NAME="8981"> </A>
2164
<CAPTION><STRONG>Figure A.40:</STRONG>
2165
A recursive process graph with a call to another process.</CAPTION>
2167
WIDTH="413" HEIGHT="437"
2168
SRC="usersguideimg225.gif"
2170
\centerline{\epsfig{figure=p/rpg3.eps}} %
2172
\end{figure}"></TD></TR>
2176
An edge in a RPG can be labeled with the name of an action or of a
2178
If it is labeled with a process name, the transition is equivalent to
2179
performing this process.
2180
Figure <A HREF="usersguidenode11.html#fig.rpg3">A.40</A> illustrates this.
2181
The RPG in figure <A HREF="usersguidenode11.html#fig.rpg3">A.40</A> is equivalent to that of
2182
figure <A HREF="usersguidenode11.html#fig.rpg2">A.39</A>.
2186
<DIV ALIGN="CENTER"><A NAME="fig.rpg4"> </A><A NAME="8983"> </A>
2188
<CAPTION><STRONG>Figure A.41:</STRONG>
2189
A recursive process graph with a recursive call.</CAPTION>
2191
WIDTH="115" HEIGHT="172"
2192
SRC="usersguideimg226.gif"
2194
\centerline{\epsfig{figure=p/rpg4.eps}} %
2196
\end{figure}"></TD></TR>
2200
The call to another process can be recursive, as illustrated in
2201
figure <A HREF="usersguidenode11.html#fig.rpg4">A.41</A>.
2202
This describes the process with possible traces
2203
<!-- MATH: ${\mbox{\sf
2204
a}}^n{\mbox{\sf c}}$ -->
2206
WIDTH="28" HEIGHT="14" ALIGN="BOTTOM" BORDER="0"
2207
SRC="usersguideimg227.gif"
2209
a}}^n{\mbox{\sf c}}$">
2211
WIDTH="43" HEIGHT="28" ALIGN="MIDDLE" BORDER="0"
2212
SRC="usersguideimg228.gif"
2216
Recursive process graphs are defined formally by Spruit and
2218
HREF="usersguidenode14.html#Wieringa91-08">26</A>], based upon the idea of recursive transition
2220
HREF="usersguidenode14.html#Woods70">27</A>].
2224
<H2><A NAME="SECTION001137000000000000000"> </A><A NAME="TUT-TDT"> </A><A NAME="8889"> </A>
2226
9.3.7 Transaction Decomposition Tables (TTDT)
2230
A transaction decomposition table is used to set off software entities
2231
against external atomic system functions, called <EM>transactions</EM>.<A NAME="8891"> </A>
2232
The entries of the table then represent the work performed by the
2233
software entities during the transaction.
2234
For example, figure <A HREF="usersguidenode9.html#TDTExample">7.7</A> says that the transaction
2235
<BR> <I>start_controlling_temperature</I> requires some actions to be taken by
2237
A <I>BATCH</I> object must perform action <I>do_temperature_ramp</I>, etc.
2240
Transaction decomposition tables can also be used in combination with
2242
The left-hand column then represents entity types or data stores, and
2243
the entries contain the letters C, R, U or D to indicate whether an
2244
instance of the entity type is created, read, updated or deleted
2245
during the transaction.
2246
The resulting table is also called a <EM>CRUD table</EM>.<A NAME="8897"> </A>
2249
Transaction decomposition tables can also be used in JSD to discover
2251
They also help to maintain traceability.
2252
Methodological details are provided elsewhere [<A
2253
HREF="usersguidenode14.html#Wieringa96-01">22</A>,<A
2254
HREF="usersguidenode14.html#Wieringa95-03">21</A>].
2257
<BR><HR><H4>Footnotes</H4>
2259
<DT><A NAME="foot8949">...
2260
<I>c</I> </A><A NAME="foot8949"
2261
HREF="usersguidenode11.html#tex2html176"><SUP>9.1</SUP></A>
2263
each <EM>existing</EM> instance of <I>E1</I> is related
2264
to <I>n</I> <EM>existing</EM> instances of <I>E2</I>.
2266
<DT><A NAME="foot8960">... <EM>components</EM>.</A><A NAME="foot8960"
2267
HREF="usersguidenode11.html#tex2html178"><SUP>9.2</SUP></A>
2268
<DD>To be more precise, it is a <EM>labeled</EM> Cartesian
2272
<!--Navigation Panel-->
2273
<A NAME="tex2html1041"
2274
HREF="usersguidenode12.html">
2275
<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next" SRC="next_motif.gif"></A>
2276
<A NAME="tex2html1037"
2278
<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up" SRC="up_motif.gif"></A>
2279
<A NAME="tex2html1031"
2280
HREF="usersguidenode10.html">
2281
<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous" SRC="previous_motif.gif"></A>
2282
<A NAME="tex2html1039"
2283
HREF="usersguidenode1.html">
2284
<IMG WIDTH="65" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="contents" SRC="contents_motif.gif"></A>
2285
<A NAME="tex2html1040"
2286
HREF="usersguidenode15.html">
2287
<IMG WIDTH="43" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="index" SRC="index_motif.gif"></A>
2289
<B> Next:</B> <A NAME="tex2html1042"
2290
HREF="usersguidenode12.html">10. Frequently Asked Questions</A>
2291
<B> Up:</B> <A NAME="tex2html1038"
2292
HREF="User.html">Toolkit for Conceptual Modeling</A>
2293
<B> Previous:</B> <A NAME="tex2html1032"
2294
HREF="usersguidenode10.html">8. Tree Editing</A>
2295
<!--End of Navigation Panel-->
2297
<I>Henk van de Zandschulp</I>
2298
<BR><I>2003-01-20</I>
added
removed
doc/usersguide/usersguidenode11.html
