Up Previous Next Title Page Index Contents

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 certain 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.

Up Previous Next Title Page Index Contents