Next: 5. Behavior View Editors Up: Toolkit for Conceptual Modeling Previous: 3. Diagram Editing
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.
This editor manipulates ER diagrams with the syntax defined in .
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.
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.
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.
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.
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.
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.
This editor manipulates ER diagrams with the syntax defined in . These ER diagrams are a subset of UML Static Structure diagrams.
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.
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).
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'.
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.
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.
TESD checks also the soft and immediately enforced constraints that are summarized in figure 4.11.
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.
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.
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.2. See figure 4.15 for an example.
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:
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.
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.
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.
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.
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.
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.
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.
TSSD checks also the soft and immediately enforced constraints that are summarized in figure 4.23.
Next: 5. Behavior View Editors Up: Toolkit for Conceptual Modeling Previous: 3. Diagram Editing Henk van de Zandschulp