1.5 Graph Tool
 | See
also the Menu Reference, Section
3.1. |
The
Graph Tool
provides the functionality to access, view and
modify method specifications at the graph level (e.g. specifications of the Data
Flow Diagram technique and its elements, or similarly for
Entity-Relationship-Attribute Diagram, Class Diagram etc.). From this tool you
can also open the other method development tools on a graph type’s
components, e.g. open an Object Tool on an object type used in this graph type.
To open a Graph Tool select Metamodel | Graph Tool
or push the Graph Tool button in the MetaEdit+ Launcher. As a result, a Graph
Tool window opens. The Graph Tool window includes the same fields as the other
tools, thus the basic definition of a graph type consists of defining its name,
ancestor, project, properties and description.

Figure 1-8. Graph Tool.
The difference between the Graph
Tool and other method development tools (Object, Relationship, and Role tools)
is that where the others handle individual components of a method, the graph
tool connects these pieces together to form the modelling technique. The
components are managed by the various subwindows that can be opened from the
buttons at the bottom of the Graph Tool window.
The
Report button opens a Report Browser, described
in the User’s Guide (Section 4.1.4), on the report definitions of this
Graph type. The other buttons and the tools they open are described in the
following.
1.5.1 Types Tool
 | See
also the Menu Reference, Section
3.2. |
The
Types button
opens a Types
Tool
, which is used to select the Object, Relationship and
Role types of the method. The Types Tool has three lists (see
Figure 1-9), Relationship, Role and
Object lists, each containing items of that type in this graph type. Each list
has a menu, which allows you to
Add a new type or
Delete the
selected type from the graph type. You can also open the appropriate tool for
the selected type by double clicking the type, or by selecting
Edit Type
from the pop-up menu.

Figure 1-9. Defining components of the graph.
The types
specified here have two functions: firstly, they determine what types are
visible in the Types menu and Toolbar of editors. Secondly, while the Types Tool
allows you to add any type from any open project, in the Bindings Tool
(described below), you can add only those types selected with the Types Tool:
this makes the selection dialogs shorter, making defining bindings, constraints,
decompositions and explosions easier.
It is, however, possible to have types in bindings that
are not in the Types Tool list: add the type in the Types Tool list, add it in a
binding, and then remove it from the Types Tool list — it will still
remain in the binding. This is particularly useful when you have abstract
supertypes: include these in the types list while you use it in definitions of
bindings etc., then remove it from the types list to ensure that it does not
appear in the toolbar in
editors.
1.5.2 Bindings Tool
 | See
also the Menu Reference, Section
3.3. |
To
specify how the relations, roles and objects are connected to each other press
the
Bindings button
in the Graph Tool. A window
opens showing how the components of the technique are bound together. The tool
interface is similar to the Types Tool, but it shows the bindings of the method,
each binding
showing a possible way of connecting
certai
n object types with role types and
relationship types.

Figure 1-10. Specifying bindings.
A binding consists of a
relationship type, normally two role types, and for each of these role types a
list of object types that may participate in the relationship in that role. The
binding is defined by first adding a relationship type to the relations window,
selecting that relationship and adding role types for it (usually two for a
binary relationship), selecting one of the role types and adding the object
types that can take part in this relationship in that role.
If no bindings are defined, the default behaviour is that
no relationships can be created, as there is no way of knowing which role types
should be associated with which relationship types. Thus we must define bindings
that allow all the relationship-role-object type combinations we want, without
allowing any combinations that should be illegal. Note that it is possible to
define multiple bindings for each relationship type, and similarly role types
and object types may participate in as many bindings as you wish. Types may also
participate in several different graph types, with different bindings in
each.
The members of a binding are selected from the available
types currently in that graph type, defined in the Types Tool (Section
1.5.1). It is, however, possible to add
an abstract supertype into the object types for a graph type, add it in a
binding, and then remove it from the available types. In this way all subtypes
of that supertype are legal in the binding, but instances of the supertype
itself cannot be created into graphs of this type, nor is the supertype visible
in the Toolbar for graphs of this type. In some exceptional circumstances it may
be desirable to specify the supertype of all object types, Object: you can do
this by selecting
Add... with shift held down, and Object will then be
included in the list of types to select from. Note that relationships or roles
are always created to be instances of the exact type specified in the
bindings.
In the Binding Tool the three lists are chained together,
so that a binding is selected by selecting its relationship type in the
relationship list. This then changes the contents of the roles list to show the
role types used in that binding. We can then select a role type, and that will
show us the object types that can participate in that role in that
binding.
Role type order
The order of the role types
is important
for each relationship type, because a user preference allows MetaEdit+’s
tools to assume when drawing relationships that the object for the first role is
always selected first, that for the second role is selected second etc. Hence
you should try to select as the first role type in each binding the type which
is most likely to be at the ‘starting’ end of the relationship. You
can change the order of role types by choosing
Move... from the pop-up
menu related to the role types:
1) | Select
first the role type to be moved.
|
2) | Choose
Move... from the menu.
|
3) | Choose the
right place for the role type from the list that
opens. |
Role type cardinalities
Another difference between the user interfaces of the Types
Tool
and Binding
Tool is that in the
Binding Tool the role list can show cardinalities for each role type in a
binding. The cardinality
is a range with minimum and
maximum values and it defines how many times this role type with its object
types can appear in a single binding.
An example of setting cardinalities could be in a Class
Diagram, where an Inherit relationship has roles of two types. The first role
type, Superclass, defines the ancestor part of the relationship, and it should
have a cardinality of 1 in an inheritance relationship where only one class can
be in a superclass role. The second role type, Subclass, would have a
cardinality of 1..N to allow for any number of subclasses for an inheritance
relationship.
 | Note
that this only prevents multiple inheritance within a single binding: it would
still be possible for a class to have two ancestors, if it was a subclass in two
separate inheritance relationships. This is indeed the situation in many object
methods, which allow multiple inheritance, but do not allow it to be represented
in a single relationship. To totally forbid multiple inheritance, you could use
constraints: see Section
1.5.3. |
Cardinalities
are set in the Cardinality Dialog
, which is shown in
Figure 1-11 below.
To set cardinalities:
1) | Select
the role for which to add a cardinality
constraint. |
2) | Choose
Cardinality... from the pop-up menu.
|
3) | Enter minimum
and maximum cardinality values and press
OK. |
The values can be from 0 to
infinite, which is entered and shown as an N. If no cardinality is defined, the
default is one for minimum and one for maximum, i.e. an obligatory role that can
occur only once. If the upper limit is infinite set the maximum to N. You can of
course also add the same role twice in the same binding; in general using
cardinalities is a better way.

Figure 1-11. Cardinality Dialog.
1.5.3 Constraints Tool
 | See
also the Menu Reference, Section
3.4. |
Cardinality
defines the number of roles that a relationship can have. To specify the number
of roles or relationships an object can participate in press the
Constraints button in the graph tool.
A window
opens showing the constraint definitions of this graph type
(
Figure 1-12).

Figure 1-12. Constraint definitions.
A constraint is
defined for an object type, and either a role or a relationship type. An example
of a constraint with a role type would be a definition of single inheritance in
a Class Diagram. It defines that a class can participate at most in one
Specialization role. It must be noted that a class can participate in many
Generalization roles because it can have several subclasses.
An example of relationship related constraint is the
definition that an object instance can participate in only one instantiation
relationship. In other words, an object can not be an instance of several
classes. A second example would be a rule that a Process could be connected to
at most 10 flows in a single Data Flow Diagram.
A constraint applies only within a single graph of this
graph type. Hence, an object may be in more than the specified number of roles
or relationships in total over the whole repository, e.g. a class can be in one
Specialization role in one graph, and another Specialization role in another
graph.
Constraints are defined with a constraint dialog
(
Figure 1-13) which can be opened with
the
Edit and
Add buttons of the Constraints Definer window. The
Delete button deletes a selected constraint definition.
To edit a constraint, choose it from the list of
constraints and double click it (or alternatively push the Edit button).
As a result, a dialog opens for editing the constraint definition.

Figure 1-13. Defining constraints.
The elements of the
constraint are specified in the four fields of the Constraint Definer window.
The top field allows you to select the object type for the constrain from a
pull-down list. The second field specifies the upper limit for the constraint:
the initial value is one (if no constraint is defined, there is no upper
limit).
The radio buttons below determine whether the constraint
is related to role types or relationship types, changing the contents of the
pull-down list below. After choosing the correct radio button, you can choose
the relationship or role type from the bottom
list.
1.5.4 Subgraphs Tools
 | See
also the Menu Reference, Section
3.5. |
The
Explosions and
Decompositions buttons open tools where the
possible explosions and decompositions of types in this graph type can be
defined.

Figure 1-14. Explosions Tool.
The
Explosions button
opens a window as above. The left-hand list shows all the types of the method
for which an explosion has been defined. You can add types (object, relationship
and role types) to that list from its pop-up menu. When one of the types is
selected, the right hand list shows the graph types to which that type can
explode. New explosions can be added and old ones deleted for the selected type
by selecting the appropriate item from the right hand list’s pop-up menu.
The
Add... menu item presents a list of all available graph types, from
which one or several can be selected. The list dialog is represented in
Figure 1-15 below. Note that selecting a
Graph type also allows instances of subtypes of that Graph type to be targets of
explosion links. In some exceptional circumstances it may be desirable to
specify the supertype of all graph types, Graph: you can do this by selecting
Add... with shift held down, and Graph will then be included in the list
of types to select from.
Basically, the explosion structure allows you to select
one instance from the graph and explode that to a new graph. An instance can
have many explosions in a single graph, and a different set of explosions in
each graph where it is used.
Explosion is often used between graphs from different
methods. A typical example of explosion can be found from most object-oriented
methods, in which an object in an Object Diagram can be exploded into a State
Transition Diagram to describe the behaviour of the object.

Figure 1-15. Graph Selection Dialog.
The decomposition
definition works in the same way as the explosion definition, but the source of
the decomposition can only be an object type. Decomposition forms another way to
connect elements of a graph to other graphs. The difference from explosion is
that explosion creates a simpler link between an element and a graph whereas
decomposition also handles the relationships attached to the element. Unlike
decomposition, explosion allows you to make links from a design element to
several graphs, and different links for the same element used in different
graphs, whereas an object can have only one decomposition, which is the same
wherever that object is used.
All decomposition
structures are
defined in Graph Tool and they are always dependent both on the object type and
graph type. Therefore, for example an object type State can be decomposed when
it is a part of a State Transition Diagram but not when it is part of an Object
State Diagram. On the instance level, however, things work a little differently:
a given instance State always decomposes to the same graph, wherever it is. Thus
the type level defines where it is legal to
create new decomposition
structures: existing decomposition links are part of the object, and can be
followed anywhere.
A typical decomposition structure can be found from Data
Flow Diagrams, in which a Process can decompose into a new Data Flow Diagram.
Note that on the instance level only one decomposition is allowed for an object,
and applied in all graphs containing that object. On the type level, each object
type in a graph type can have several possible graph types which it could
legally decompose to.
1.5.5 Defining new graph types
To start an empty Graph Tool select Metamodel | Graph
Tool or the Graph Tool button in the MetaEdit+ Launcher. Now the Graph Tool
is ready for accepting the definition of a new graph type.
If you want the graph type to inherit properties from
another type than from the current ancestor, select Make Descendant...
from the pop-up menu of the name field and select the ancestor type from the
list of available graph types. In addition to inheriting properties, new Graph
types also receive a copy of the type, binding and constraint sets of their
supertype. These sets are not truly inherited, but simply copied as initial
values for the subtype.
To fill in a new Graph type:
1) | Give
the name of the graph type in the Name field. Use
unique names, because otherwise you might encounter difficulties in selecting
the right graph type (i.e. selection lists and dialogs have several methods with
the same
name). |
2) | Select
the project for the new graph type by pressing the Project button and by
selecting it from the list of loaded projects. If the project you want is not in
the list, you must first open it from the Launcher with Repository | Open
Project.... |
3) | Define
the properties of the graph type (see the Section
1.2.1 on the Object Tool for
details). |
4) | Generate
the new graph type. Press the Generate button to
save the definition of the graph type. After pressing Generate the Graph
Tool asks whether a default dialog should be generated for the graph type. If
you press Yes a standard dialog will be defined for the graph type.
Generally it is a good idea to define a default dialog, if you are not defining
a custom dialog immediately, because the dialog is needed to create instances of
this graph type. |

Figure 1-16. Generate default dialog –dialog.
5) | Define
the dialog for the graph type. If you answered Yes to the dialog that
prompted for the dialog definition in the previous step, there is no need to
perform this step. If, however, you want to modify the default dialog select
Edit Dialog from the Property list pop-up menu.
This operation opens the dialog definition, and you can modify the appearance of
the dialog (see Section 1.7 for
details). |
6) | Define
the object, relationship and role types to be used in this graph type. Press the
Types button and in the Types
Tool use the Add... menu item from each
list’s pop-up menu and select the appropriate types to be included in this
method. |
7) | Define
the bindings of object, relationship and role types. Press the Bindings
button and in the Binding Tool that opens select
Add... from the relationship list pop-up menu and select the appropriate
relationship types from the dialog. Each relationship type you selected now has
a (partially empty) binding. For each binding add the appropriate role types
with Add... in the role list. If necessary, give cardinalities for those
role types in this binding. For each of the role types add the object types that
can be in this role in this binding. Notice that the selection lists in each of
the relationship, role and object windows are much shorter than in Types
Tool, because only the types selected for this method are
available
here. |
8) | Specify
the possible constraints of object and role or relationship types. Press the
Constraints button to open Constraints list and press the Add
button. Choose first the object type whose instances you want to constrain, then
choose either the role or relationship type. Finally, change the maximum
constraint value if it is other than
one. |
9) | Define
the explosions and decompositions of the types in this graph type. Press the
Explosions and Decompositions buttons and add for each type the
graph types to which it can explode or
decompose. |
10) | Document
the graph type. Describe the graph type in the Description
field. |
11) | Press
the Modify button to accept the changes. (You can also omit steps 3 and 4
and press Generate now: if you did this, the graph type you are creating
is of course not available to decompose or explode to in step
8). |
1.5.6 Modifying existing graph types
To open the specification of a graph type (e.g. Data Flow
Diagram):
1) | Open
a pop-up menu from the first field of the Graph Tool (i.e. Name
field). |
2) | Select
Choose
Type... |
3) | Select
‘Data Flow Diagram’ from the selection
dialog. |
As a result of this selection you
should now have a Graph Tool open as in
Figure 1-8.
To view components that belong to Data Flow Diagrams press
the
Types button
in the Graph Tool. As a result, a
dialog appears (cf.
Figure 1-9) showing
three lists that include all the object (i.e. Process, Store and External),
relationship (Flow) and role types (Receives, Sends) of the Data Flow
Diagram.
Types can be added, deleted or edited by selecting the
type and choosing the appropriate operation from the pop-up menu. The changes
are not destructive: for example if you delete the Store type (e.g. to replace
it with Buffer) then any Stores that are already in existing graphs will remain
intact; but new ones cannot be added.
To specify how the relations, roles and objects are
connected to each other press the
Bindings button
.
The components of bindings can be added, removed and edited. As with the types,
the removal of types from bindings does not destroy existing bindings in graphs,
but new bindings must be legal according to the new definition.
Figure 1-10 in
Section
1.5.2 shows the dialog for
specifying bindings. In Data Flow Diagrams there are two types of bindings: one
for flows from Process and another for flows from Store and External. These
specifications are needed to define Data Flow Diagrams so that rules like:
“It is not possible to connect Externals directly to Stores” are
followed. Note that such negative rules are not directly possible: rather, you
define positive rules that say what is allowed, and simply do not create rules
that would allow bindings that are not legal in your method.