Next: 5. Behavior View Editors Up: Toolkit for Conceptual Modeling Previous: 3. Diagram Editing

Subsections

4. Data View Editors

Data view editors manipulate diagrams commonly used for data modeling. This includes various entity-relationship as well as class diagram editors. They are described in a particular order in this chapter because this is the way TCM, and hence the user interface, is built up : TSSD specializes TCRD, which specializes TESD, which specializes TERD, the oldest of the lot. Each section may therefore refer to a previous section in this chapter.

4.1 The classic Entity-Relationship Diagram Editor (TERD)

This editor manipulates ER diagrams with the syntax defined in [22].

4.1.1 Nodes and Edges

See figure 4.1 for the subjects and the representing shapes that are used in TERD. In figure 4.2 you can see which node types can be connected by which edge types. The constraints of which node types can be connected by which edge types are immediately enforced. Note that function edges can be represented by two shape types, uni-directional (single) arrows and bidirectional (double) arrows. The latter denotes a one-one relationship. So, in figure 4.2 a single function arrow may also be a bidirectional arrow.

Figure 4.1: Entity-relationship diagram nodes and edges.

$\includegraphics{p/box.eps}$	Entity type	$\includegraphics{p/ellipse.eps}$	Value type
$\includegraphics{p/taxonomyjunction.eps}$	Taxonomy junction	$\includegraphics{p/diamond.eps}$	Relationship
$\includegraphics{p/c2line.eps}$	Binary relationship	$\includegraphics{p/c1arrow.eps}$	Function
$\includegraphics{p/isaarrow.eps}$	Is-a relationship	$\includegraphics{p/predefinedline.eps}$	Empty edge
$\includegraphics{p/doublearrow.eps}$	(One-one) Function

**Figure 4.2:** Permitted Entity-relationship connections.
$\includegraphics{p/ERconnections.eps}$

4.1.2 Cardinality Constraints and Role Names

Most edge types have a name label, which is shown as an L in figure 4.1. The default position of a name label is near the center of the middlemost segment of the edge. The middlemost segment is ``number of segments div 2''. When the label is first edited, the default position becomes the center of the segment where the line is selected for editing. When the line is not vertical, the name label is by default positioned at a fixed distance above the line, preventing that the label goes through the line and becomes unreadable. When the line is vertical, the label is positioned slightly to the left of the line, preventing that a short label goes through the line and becomes unreadable. Some edge types like Binary relationships and Functions also have role names and/or cardinality constraints. See figure 4.3 for the default positions of the roles names (r1 and r2) and cardinality constraints (c1 and c2). These labels are editable just like the name labels. The role name r1 and the cardinality constraint c1 have their default positions near the middle of the first quarter of the first segment of the line. r2 and c2 have their default positions near the middle of the last quarter of the last segment of the line ^4.1. When the line is more or less horizontal, role names are positioned above the line and when the line is more or less vertical, role names are positioned at the left side of the line (just like the name label). Cardinality constraint labels are positioned at the side opposing the role name labels. See figure 3.3 for an example ER diagram with role names and cardinality constraints.

Remark: A binary relationship whose c2 cardinality constraint is 1, is equivalent to a function edge. The difference is that, instead of a 1, an arrow head is drawn. Nevertheless, TERD considers them as separate edge types.

**Figure 4.3:** Default label positions of a binary relationship edge.
$\includegraphics{p/defaultpositions.eps}$

TERD enforces immediately that cardinality constraints conform to the BNF syntax of figure 4.4. But TERD does not check if subranges are contradictory such as the constraints 1..0 and 2,>=3.

**Figure 4.4:** Cardinality constraint syntax.
$\begin{figure} \begin{center} \begin{math} \begin{array}{lll} constraint & \righ... ...rt{\bf 8}\vert{\bf 9} \\ \nonumber \end{array}\end{math}\end{center}\end{figure}$

4.1.3 Taxonomic Structures

A taxonomic relationship (also called specialization, generalization, inheritance or is-a hierarchy) is constructed from a taxonomy junction node connected to an entity type by a single is-a relationship edge and connected to two or more other entity types by two or more empty edges. The entity type where the is-a relationship edge ends is the generalization (or supertype), the other entity types are specializations (or subtypes). See, for example, figure 4.5. If two entity types are is-a related then a single is-a relationship arrow can be drawn between them, but when an entity type is specialized into more than one different entity type then it is customary to draw one compound is-a relationship with a taxonomy junction.

**Figure 4.5:** Example taxonomic structure.
$\includegraphics{p/taxonomyexample.eps}$

The Show ISA Hierarchy toggle in the View menu of TERD shows the shapes which constitute the is-a hierarchy. When you turn it on, the shapes that are not part of the hierarchy are made invisible. When you turn it off, all shapes are made visible again.

An is-a relationship has a built-in name label "is_a", an empty edge does not have a label. Taxonomy junctions should have one of the following labels : "", "d", "e" or "de". A "d" stands for disjunctive and an "e" stands for exhaustive. These constraints are immediately enforced.

4.1.4 Constraint Checking

In addition to the connection constraints, the syntax of cardinality constraints and the other graphical conventions that TERD enforces, TERD checks a lot of immediately enforced and soft constraints. These are summarized in figure 4.6.

Some of these constraints are enforced immediately during most but not all editor commands. If that is the case, they are additionally checked by Check Diagram as a soft constraint.

Note that the unique name constraints do not concern duplicate node shapes. This is one of the reasons for the existence of duplicate shapes, i.e. showing the same node on different places in the diagram.

**Figure 4.6:** Immediately checked and soft constraints on ERDs.
$\includegraphics{p/ERconstraints.eps}$

4.2 The Entity-Relationship Diagram Editor (TESD)

This editor manipulates ER diagrams with the syntax defined in [23]. These ER diagrams are a subset of UML Static Structure diagrams.

4.2.1 Nodes and Edges

See figure 4.7 for the subjects and the representing shapes that are used in TESD. In figure 4.8 you can see which node types can be connected by which edge types. The constraints of which node types can be connected by which edge types are immediately enforced. Note that entity types can be represented by two different box types. In figure 4.8 only the single box type variant is shown but each single box could be replaced by a double box.

Figure 4.7: Entity-relationship diagram nodes and edges.

$\includegraphics{p/box.eps}$	Entity type	$\includegraphics{p/diamond.eps}$	Relationship
$\includegraphics{p/doublebox.eps}$	Entity type	$\includegraphics{p/UMLtaxonomyjunction.eps}$	Generalization junction
$\includegraphics{p/c2line.eps}$	Binary relationship	$\includegraphics{p/dashedline.eps}$	Association entity type link
$\includegraphics{p/rcline.eps}$	Participant link (in N-ary relationship)	$\includegraphics{p/generalizationarrow.eps}$	Generalization

**Figure 4.8:** Permitted Entity-relationship connections.
$\includegraphics{p/ESconnections.eps}$

4.2.2 Cardinality Constraints

TESD enforces immediately that cardinality constraints conform to the BNF syntax of figure 4.9. TESD does not check if subranges are contradictory such as the constraints 1..0 and 2,3..*. Mind that the syntax differs from the syntax in TERD (figure 4.4).

**Figure 4.9:** ESD Cardinality constraint syntax.
$\begin{figure} \begin{center} \begin{math} \begin{array}{lll} constraint & \righ... ...r&\rightarrow&{\bf *} \\ \nonumber \end{array}\end{math}\end{center}\end{figure}$

4.2.3 Read direction arrows

Binary relationships in TESD (and TSSD) can optionally have a read direction arrow connected to the name label. This arrow is a clue for the user for how to read the label. It has no semantics. Via the submenu called ``Change Read Direction'' in the Edit menu a read direction arrow can be added or removed. The option ``None'' removes the arrow from all selected binary relationships. The option ``From Shape'' shows an arrow directed to the ``from''-shape, i.e.` the shape from which the relationship line originates when it was drawn. The option ``To Shape'' shows an arrow directed to the ``to''-shape. Or simply just click on the 'read direction area' behind the name label to switch between the three options 'To Shape', 'From Shape' and 'None'.

4.2.4 Taxonomic Structures

The is-a relationship in TERD is called generalization in TESD, being represented by a open arrow.

A taxonomic relationship consists of a taxonomy or generalization node connected to three or more entity types by generalization edges. On connecting a generalization edge from an entity type to a generalization node, the open arrow end will disappear, resulting in an empty edge representation. See, for example, figure 4.10.

**Figure 4.10:** ESD Example taxonomic structure.
$\includegraphics{p/ESDtaxonomyexample.eps}$

The Show ISA Hierarchy toggle in the View menu of TESD shows the shapes which constitute the is-a hierarchy. When you turn it on, the shapes that are not part of the hierarchy are made invisible. When you turn it off, all shapes are made visible again.

An is-a relationship can have a label name, with the exception of a generalization arrow leading towards a generalization node which can not have a label. Generalization nodes should have one of the following labels : "", "d", "c", "dc" or "cd". A "d" stands for disjunctive and a "c" stands for complementary. These constraints are immediately enforced.

4.2.5 Constraint Checking

TESD checks also the soft and immediately enforced constraints that are summarized in figure 4.11.

**Figure 4.11:** Immediately checked and soft constraints on ERDs.
$\includegraphics{p/ESconstraints.eps}$

4.3 The Class-Relationship Diagram Editor (TCRD)

4.3.1 Nodes and Edges

See figure 4.12 for the subjects and the representing shapes that are used in TCRD. In figure 4.13 you can see which node types can be connected by which edge types. These are immediately enforced constraints. Note that classes can be represented by three different box types. In figure 4.13 only the double box type variant is shown but each double box could be replaced by a single or triple box.

Figure 4.12: Class-relationship diagram nodes and edges.

$\includegraphics{p/box.eps}$	Class	$\includegraphics{p/triplebox.eps}$	Class
$\includegraphics{p/doublebox.eps}$	Class
$\includegraphics{p/taxonomyjunction.eps}$	Taxonomy junction	$\includegraphics{p/modejunction.eps}$	Mode junction
$\includegraphics{p/c2line.eps}$	Binary relationship	$\includegraphics{p/c1arrow.eps}$	Function
$\includegraphics{p/dashedc1arrow.eps}$	Component function	$\includegraphics{p/isaarrow.eps}$	Is-a relationship
$\includegraphics{p/predefinedline.eps}$	Empty edge	$\includegraphics{p/oneonefunction.eps}$	(One-one) function

**Figure 4.13:** Permitted Class-relationship connections.
$\includegraphics{p/CRconnections.eps}$

4.3.2 Classes and Relationships

The class node type of TCRD can be seen as an extension of the entity type node type of TERD. Like TERD, TCRD has binary relationships and functions. Value type nodes are not needed in TCRD because attribute names and value types are now included in the class in the form of attribute definitions. Also unlike TERD, TCRD does not have a separate node type for relationships. Relationship nodes can be represented by the same type of class box. The only difference between a real class instance and a relationship instance, is that the latter has two or more components. A relationship instance is called a link. The components make up the identity of a link. The components of a link are classes or other links. The component relationship is a projection function represented by a dashed arrow. This function is called a component function. Like ordinary functions, component functions can have a cardinality constraint label (see figure 4.14). There is no other visual difference between a class instance and a relationship instance in TCRD than the component functions. So, in TCRD a link can have attributes, operations and it can be part of a taxonomic structure.

**Figure 4.14:** Example CR diagram, showing a relationship class.
$\includegraphics{p/componentexample.eps}$

TCRD inherits all the applicable constraints of TERD, on the understanding that classes in TCRD replace the entity types from TERD. Furthermore, see section 4.1.2 for the use of cardinality constraints and role names, see section 4.1.3 for the use of taxonomies and see figure 4.6 for all the other constraints that are checked in TERD.

4.3.3 Attributes and Operations

The class-relationship editor TCRD offers classes that can have a number of attributes and a number of operations ^4.2. See figure 4.15 for an example.

**Figure 4.15:** Example class with attribute and operation definitions.
$\includegraphics{p/classexample.eps}$

A class can be represented by a single box in which only the name label is visible, by a double box in which the name label and all the attributes are visible, or by a triple box in which the name label, all the attributes and all the operations are visible. For each representing shape type there is a separate tiled button in the list of nodes in the main window, but they are all representations of the same node type, Class. You can change the representation of an existing class by the change box type command in a submenu of the Edit menu. These commands modify only the shapes of the selected boxes. The other shapes, unselected boxes and shapes that are not boxes, are not updated. These commands only change the shape; the attributes and operations are preserved.

Each attribute definition and each operation definition occupies a single text line. Any text on a single line in the appropriate part of a box is considered as an attribute or operation definition. Attribute names are in the second compartment and operation names are in the third compartment of the class box. You can perform the following operations on attributes and operations:

Append one or more attributes or operations. To add attributes or operations to the end of the attributes or operations list of a class, click the mouse pointer in the empty part at the bottom of the compartment in the class box and start editing. You can add more than one attribute or operation at a time by separating them by newlines. When you stop editing and the autoresize is on, the size of the class box is adjusted to the width and the height of the new list of attributes and operations and the new attributes and operations in the box are always left adjusted.
Insert one or more attributes or operations. To insert new attributes or operations somewhere in the current attribute or operation list, click the text line that should precede them and go into edit mode. First enter a newline and then add the new attributes or operations like described above.
Update an attribute or operation. To update an existing attribute or operation, click its text line and edit it.
Remove an attribute or operation. To remove an existing attribute or operation, click its text line for editing and delete the text with <Escape> (in-line editor) or do a delete all in the out-line editor. If you stop editing, the attribute or operation is deleted and the size of the class box is adjusted.

4.3.4 Taxonomic Structures

Like TERD, TCRD has taxonomic structures with taxonomy junctions, is-a relationships and empty edges. TCRD offers a second kind of taxonomy junction which is called mode junction and which is represented by a small dashed circle instead of a small solid circle. Mode junctions are used for constructing mode specializations. For an example mode specialization, see figure 4.16. The concept of mode specialization as a form of type migration is explained in appendix A. Except the different shape of the circle, mode specializations are drawn in the same way as static specializations, having the same constraints as in section 4.1.3.

**Figure 4.16:** Example mode specialization.
$\includegraphics{p/modeexample.eps}$

An is-a relationship (without a junction) between two classes, and an is-a relationship connected to a taxonomy junction are considered as static specializations, whereas is-a relationships connected to a mode junctions are considered as dynamic specializations. Both kinds of specializations can be combined, with the exception that a mode type should not be specialized statically. This is an immediately enforced constraint.

4.3.5 Constraint Checking

TCRD checks also the soft and immediately enforced constraints that are summarized in figure 4.17. Note that TCRD checks a lot of constraints but it does not check yet all plausible constraints on CRDs. For instance, name conflicts between operations and attributes of classes that are is-a related are not yet discovered and the syntax of attributes and operations is still very liberal.

**Figure 4.17:** Immediately checked and soft constraints on CRDs.
$\includegraphics{p/CRconstraints.eps}$

4.4 The Static Structure Diagram Editor (TSSD)

4.4.1 Nodes and Edges

See figure 4.18 for the subjects and the representing shapes that are used in TSSD. In figure 4.19 you can see which node types can be connected by which edge types. These are immediately enforced constraints. Note that classes can be represented by three different box types, whereas objects can be represented by two different box types. In figure 4.19 for classes only the double box type variant is shown but each double box could be replaced by a single or triple box. For objects only the single box variant is shown but each single box could be replaced by a double box.

Figure 4.18: Static structure diagram nodes and edges.

$\includegraphics{p/box.eps}$	Class	$\includegraphics{p/objbox.eps}$	Object
$\includegraphics{p/doublebox.eps}$	Class	$\includegraphics{p/objdoublebox.eps}$	Object
$\includegraphics{p/triplebox.eps}$	Class	$\includegraphics{p/diamond.eps}$	N-ary association
$\includegraphics{p/UMLtaxonomyjunction.eps}$	Generalization node (extension to UML)	$\includegraphics{p/aggregationjunction.eps}$	Aggregation node (extension to UML)
$\includegraphics{p/c2line.eps}$	Binary association	$\includegraphics{p/objectlink.eps}$	Object link
$\includegraphics{p/generalizationarrow.eps}$	Generalization	$\includegraphics{p/dashedline.eps}$	Association link
$\includegraphics{p/aggregation.eps}$	Aggregation	$\includegraphics{p/composition.eps}$	Composition
$\includegraphics{p/rcline.eps}$	Participant Link

**Figure 4.19:** Permitted Static structure connections.
$\includegraphics{p/SSDconnections.eps}$

4.4.2 N-ary Associations

TSSD inherits all the applicable constraints of TESD. TSSD also supports N-ary associations, being represented by a diamond node shape, connecting the associated classes or objects. See figure 4.20.

**Figure 4.20:** Example of a n-ary association.
$\includegraphics{p/n-ary-association2.eps}$

4.4.3 Objects

In addition to classes, objects can be specified. An object is an instance of a class, which can be represented by the same type of class box with the name of the instance being underlined. Objects can be represented by two different box types : single boxes where only the name label is visible, or double boxes in which the name label and all the attributes are visible. The top compartment contains the object and class name in the form of objectname:classname. The bottom compartment may list the attribute names and values. Operations are not shown in objects, because they are all the same for all objects of a class. See figure 4.21 for permitted object notations. Object nodes can be connected to other objects by means of an object link edge. Use a participant link to connect an object to a n-ary relationship node.

**Figure 4.21:** Example Object notations.
$\includegraphics{p/SSDobjects.eps}$

4.4.4 Taxonomic Structures

In addition to UML, TSSD supports taxonomic structures using generalization and aggregation nodes. A generalization node is being represented by a small circle. Classes may be connected to a generalization node using the generalization edges. Like TESD, generalization nodes may have a label. The following labels are permitted : "", "d", "c", "dc" or "cd". A "d" stands for disjunctive and a "c" stands for complementary. These constraints are immediately enforced. The open arrow of the generalization arrow will disappear on connecting it from a class box to a generalization node; an empty edge will be shown instead.

An aggregation node is being represented by a small black circle. Classes may be connected to an aggregation node using the aggregation or composition edges. The open diamond of the aggregation arrow and the black diamond of the composition arrow will disappear on connecting it from a class box to an aggregation node; an empty edge will be shown instead. See figure 4.22 for some permitted notations.

**Figure 4.22:** Example taxonomic notations.
$\includegraphics{p/SSDtaxonomic.eps}$

4.4.5 Constraint Checking

TSSD checks also the soft and immediately enforced constraints that are summarized in figure 4.23.

**Figure 4.23:** Immediately checked and soft constraints on SSDs.
$\includegraphics{p/SSDconstraints.eps}$

Footnotes

... line ^4.1: Or more pedantic: what is the first and what is the last segment of a line is actually determined by the direction in which the edge was originally drawn. For undirected edges like a binary relationship this direction is irrelevant, as both sides have possibly a cardinality constraint and a role name. For directed edges like functions, this direction is visible by the shape of the line.
... operations ^4.2: In the past, an operation in TCRD was also called event, transition or action.

Next: 5. Behavior View Editors Up: Toolkit for Conceptual Modeling Previous: 3. Diagram Editing

Henk van de Zandschulp
2003-01-20