Next: 10. Frequently Asked Questions Up: Toolkit for Conceptual Modeling Previous: 8. Tree Editing
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, Design Methods for reactive Systems: Yourdon, Statemate and the UML, Department of Computer Science, University of Twente, 1999. The miscellaneous notations are documented in .
The TCM convention for TESD is described in detail in .
As usual, a named rectangle represents a named entity type.
Binary relationships are presented by lines.
Cardinality properties are represented by
annotations placed at the end points of these lines.
(Cardinality properties are also called ``cardinality constraints''
by many authors.)
For example, in figure A.1, 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 A.2 gives an example.
In general, a cardinality property is represented by a set of natural numbers (see figure 4.9 for the syntax). For example, if c is a set of natural numbers, the property in figure A.3 is that each instance of E1 is related to n instances of E2, where c. (More precisely, each existing instance of E1 is related to n existing instances of E2.) If no cardinality property is shown, the convention is that c is the entire set of natural numbers. For example, in figure A.25, each instance of E2 is related to any number instances of E1. This includes the case that it is related to 0 instances of E1.
Note that there is no natural reading direction for a relationship name. For example, figure A.4 conveys the same information as figure A.1. If there is a reading direction, one can adorn the relationship name with a small arrow that indicates this. See figure A.5.
Often, a directed relationship name is really a role name of one of the participating entity types.
There are many other conventions to represent binary relationships. Figure A.6 shows different ways of representing the following constraints:
A relationship is a Cartesian product of two or more entity types, called its components. (To be more precise, it is a labeled Cartesian product.) 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 A.8 contains exactly the same information as figure A.1.
Relationships with arity higher than 2 cannot be represented by a
They can only be represented by a diamond.
Figure A.9 gives an example.
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 c 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 A.9 says that each transport company participates in at least one delivery. (This is not very realistic but is does illustrate the convention.)
Entity attributes are represented by listing them in a separate compartment below the entity type name. Representation of entity attributes is optional.
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 A.11 and A.12 for illustrations.
An is-a relationship is a binary relationship that is an inclusion function. For example, figure A.13 shows that each CAR instance is also a VEHICLE 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. CAR is called a specialization of VEHICLE and VEHICLE is called a generalization of CAR.
If there is more than one specialization of an entity type, then these must be grouped into specialization groups. This is represented by connecting the rectangles representing the specializations to a small circle called the taxonomy junction or generalization node and connecting this with an is-a arrow to the rectangle representing the generalization. The generalization node must be annotated as follows:
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 DFD is a directed graph with three kinds of nodes:
In figure 6.3, there are three processes, Confirm Registration, Check Request and Register students. When the external entity STUDENT sends a message test_request, which is a request to participate in a test, then the process Check Request retrieves the identifier of the test from the data store TESTS and the student identifier from the STUDENTS 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 Register students stores this fact in the TEST_REGISTRATIONS data store and Confirm Registration confirms this to the external entity. To make the DFD in figure 6.3 more precise, this model must be supplemented with precise process specifications, and a specification of the structure of the data stores and data flows.
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 compound process. A process specified in another way (e.g. by means of a piece of text) is called primitive. This can be indicated by the letter P in the node that represents the process.
Compound processes give rise to a tree of DFDs. Processes in this tree are labeled by means of a Dewey numbering 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.
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 A.3.3 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 A.14 contains a DEFD of which the control process is
specified in figure A.15.
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 .
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.
State transition diagrams (Mealy, Moore and statechart) are described in 
TCM supports the Mealy notation for finite state transition diagrams (figure A.16). States are named, and are represented by rectangles. State transitions are represented by arrows and are labeled by event [guard] / action pairs. The event is the trigger of the transition and can be viewed as the occurrence of an input. The guard is a condition. 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.
The action part of the transition label is the output action generated by the transition.
Figure A.17 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 T:) that must send the Mealy machine an answer. While waiting for an answer, the machine is in the decision point.
Mealy machines are used in Yourdon-style structured analysis, where they are used to specify control processes . The interface of the control process must equal the interface of the Mealy machine. See section A.1.2 for control processes.
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 7.8. Elaborate examples are given elsewhere .
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.
A function-entity type table is a kind of traceability table (see ). It is almost the same as a transaction decomposition table (see section A.3.7). 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  for details and examples of their use in Information Engineering.
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 external functions.
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 . Of course, a tree can be used to represent any hierarchical decomposition and TCM imposes no constraints on the syntax of the tree.
This section lists the UML notations available in TCM, as they are treated in . This is a subset of the full UML notation.
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.
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.
An actor is represented by a match stick figure or by a rectangle labeled actor. 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.
A use case is represented by an ellipse. It can be labeled. Two use cases can be connected by a generalization arrow.
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:
Figure A.18 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.
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  for details.
An object is represented by a named rectangle with an attribute
The name of an instance is underlined. The attribute compartment contains the attribute values of the instance. See figure A.19. Notice the association from John to the class City. This tells us that John has exactly one birthplace but it does not tell us which one this is, because City is a class.
An activity diagram is a graph in which the nodes represent activities and the arrows represent transitions between activities. Figure A.20 gives an example.
Activities are represented by two parallel lines connected by semicircles. The name of the activity can be entered in the shape.
Transitions are represented by unlabeled arrows. A transition represents the completion of the activity from which it departs.
A choice node is represented by a diamond. A transition that emanates from a diamond can be labeled by a [condition] that tells us when this branch is taken. A choice point is not a state of the system.
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.
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.
The start of an activity diagram is represented by a bullet. There must be exactly one bullet in a completed diagram.
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.
TSCD is used to draw statecharts. Statecharts are based on state-transition diagrams known from TSTD.
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 state nodes. A state node can be refined in two ways:
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.
For an example of a statechart, see figure A.21.
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 Off.
When switched on,
it enters the and node On and its subnodes.
Here, it again selects the initial nodes Slow and Cold.
If the user sends event f to the system,
it switches to Fast.
When the user switches the fan off (by sending an off event),
the fan leaves the On node and all its subnodes
(forgetting the slow/fast and cold/hot settings),
and enters the Off node again.
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.
In addition to other UML diagrams a collaboration diagram has message flows representing messages being sent between objects via links. See figure A.22 for an example of the initial dialog between a client and a ATM.
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.
The interface of an executable component is represented by small rectangles protruding from the component box.
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.
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.
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.
The TCM convention for ERDs is described in detail in .
As usual, a named rectangle represents a named entity type.
Binary relationships are presented by lines.
Cardinality constraints are represented by
annotations placed at the end points of these lines.
For example, in figure A.23, 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 A.24 gives an example.
In general, a cardinality constraint is represented by a set of natural numbers (see figure 4.4 for the syntax). For example, if c is a set of natural numbers, the constraint in figure A.25 is that each instance of E1 is related to n instances of E2, where c 9.1. 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 A.25, each instance of E2 is related to any number instances of E1. This includes the case that it is related to 0 instances of E1.
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 A.26 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.
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 A.27 conveys the same information as figure A.23. 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.
There are many other conventions to represent binary relationships. Figure A.28 shows different ways of representing the following constraints:
A relationship is a Cartesian product of two or more entity types, called its components.9.2 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 A.30 contains exactly the same information as figure A.23. 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 A.30 as binary relationships between EMPLOYMENT 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 A.23.
Value types (often called ``data types'') are represented by ovals.
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.
An is-a relationship is a binary relationship that is an inclusion function. For example, figure A.31 shows that each CAR instance is also a VEHICLE 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. CAR is called a specialization of VEHICLE and VEHICLE is called a generalization of CAR.
If there is more than one specialization of an entity type, then these must be grouped into specialization groups. This is represented by connecting the rectangles representing the specializations to a small circle called the taxonomy junction and connecting this with an is-a arrow to the rectangle representing the generalization. The taxonomy junction must be annotated as follows:
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.
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 A.32 has exactly the same information content as figures A.23, A.27 and A.30. The line representation (figure A.23) 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 A.33, which cannot be represented in the ERD convention.
Figure A.33 represents the following structures. (To reduce clutter in the notation, we ignore the fact that relationships are actually labeled Cartesian products.)
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 4.12). In figure A.34, an instance of CAR will never become an instance of AIRPLANE and vice versa. An instance is a member of a specialization for life. By contrast, in figure 4.16, an instance of MARRIED PERSON may move to another of the subclasses of PERSON. Here, an instance is an instance of a specialization only for part of its life. We call these specialization mode classes. For example, MARRIED PERSON is a mode class of PERSON, because a married person is a mode of a person. Details of static and dynamic specialization are given elsewhere [24,25].
TDFD contains a subset of TEFD. Please see section A.1.2.
Process structure diagrams are used in JSD to represent behavior. A PSD is a tree in which the nodes are labeled [11,22]. 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 A.35 gives an example.
PSDs are equivalent to regular expressions.
A Mealy machine roughly equivalent to this is shown in figure A.36. 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 A.36 we arbitrarily categorized all PSD actions as output actions.
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 A.3.5 below.
SNDs are used by JSD  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:
Figure A.37 shows a SND of the robot controller of figure A.14. 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 S (for ``surrogate''), and to end the name of a software entity that embodies a software function with an F. Each of the surrogate and function processes in the model must be specified by a PSD.
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 A.38 shows a RPG equivalent to the PSD of figure A.35. Nodes in RPGs can be labeled, just as in Mealy STDs. Figure A.39 shows a RPG with labeled nodes.
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 A.40 illustrates this. The RPG in figure A.40 is equivalent to that of figure A.39.
The call to another process can be recursive, as illustrated in figure A.41. This describes the process with possible traces for .
A transaction decomposition table is used to set off software entities
against external atomic system functions, called transactions.
The entries of the table then represent the work performed by the
software entities during the transaction.
For example, figure 7.7 says that the transaction
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 CRUD table.
Next: 10. Frequently Asked Questions Up: Toolkit for Conceptual Modeling Previous: 8. Tree Editing Henk van de Zandschulp