2.2 Method modelling process
The process of defining new methods is roughly the
following:
1) | Identify
and define the object types of the
method. |
2) | Define
the properties of the object
types. |
3) | Identify
the relationship types of the
method. |
4) | Define
the properties of the relationship
types. |
5) | Define
the role types of the
method. |
6) | Define
the properties of the role
types. |
7) | Define
the necessary symbols for objects, relationships and
roles. |
8) | Define
the graph types and add the object, relationship and role types into
them. |
9) | Define
the bindings of the relationships in the graph
types. |
10) | Define
constraints for objects participating in relationships or
roles. |
11) | Define
explosions and decomposition of the object types in the graph
type. |
12) | Specify
reports for checking and documenting models, exporting them into other tools, or
for generating code. |
The steps can be
performed iteratively and partly in parallel and the definitions of the types
can be modified later, but this is the rough model of the
process.
2.2.1 Defining the object types
In this section we develop the new State object type for the
State Diagram. We reuse the existing definition of the object type State used
already in UML method and specialise it to suit our needs.
Opening the Object Tool
To open an Object Tool for defining the improved State object
type:
1) | Open
the Object Tool by selecting Metamodel | Object Tool or pressing the
Object Tool button in the MetaEdit+ Launcher.
|
2) | Select
Make Descendant... from the Name field related pop-up menu.
|
3) | Select
‘State [UML]’ from the type selection dialog. The list shows
all currently loaded object types: State [UML] was loaded as it is part of the
‘UML’ project which you
opened. |
This operation prepares the Object
Tool to make a new object type, that is a descendant of the State [UML] object
type. The descendant object type inherits the properties of its ancestor: as you
can see, the Properties List in the middle of the Object Tool window is filled
with the properties of State [UML]. These inherited properties are shown with
dark red text and they cannot be changed here: they can only be changed in the
ancestor that defines them.
Now you can start to define the improved State object
type.

Figure 2-2. An empty Object Tool.
Naming the new object type
1) | Type
the name of the new type (call it ‘Class state’) in the Name
field. |
The name is used for selecting the
object type in the normal development tools and as the name of the property
window of the object type. The name can be changed afterwards, then the new name
appears after that in all places that use this object type.
Quite often there can be two object types which would have
the same name, e.g. the object type ‘Class’ appears in many
object-oriented methods. In such cases it is a good idea to use names such as
‘Class [UML]’ and ‘Class [OMT]’ to distinguish the
types.
Adding a new property type to an object type
The ancestor State [UML] defines several properties, such as
State name and Documentation, and they are already in the Properties list. Thus
you need only add one new property to the Class state: a property whose value
refers to a Class [UML] object. Whilst there already exists such a property type
in the method (Object [UML] uses it to refer to its Class), we will create our
own new property type for the sake of experience.
To add a new property:
1) | Move
the mouse over the Properties list, and press the right mouse button to open the
list’s pop-up menu. From the menu select Add Property..., choose
New Property Type from the selection list and press OK. This
starts an empty Property Tool, where we can define the new property type.
|
2) | In the
Property Tool type the name of the new Property type in the Name field
(call it ‘Related class’). |

Figure 2-3. Property Tool with Class property type.
3) | Press
the Datatype button, to define what kind of values this property may
hold. Select Object from the list of data types that appears and press
OK. Object here refers to the GOPRR meta-type: we will choose which
object type in the next step. |

Figure 2-4. Data type selection dialog.
4) | Select
‘Class [UML]’ from the list of object types that appears and press
OK. |

Figure 2-5. Selecting content for Object date type.
5) | Type
a description of the Class in the Description field, for example:
‘A property that refers to one UML
class’. |
6) | Press
the Generate button at the bottom of the window. Now a new property
type has been added to the MetaEdit+ method base. The property type can later be
reused in other methods as
well. |
7) | As we
opened the property tool whilst adding a new property to an object type, a
dialog appears and asks whether this property should be added to the Class state
object type. Press the Yes button.
|
8) | In the last
phase of property definition for an object type you are asked for the local name
of the property within this object type
(Figure 2-6). The local name is useful
when reusing a general property type from the library, to make it fit the local
terminology of a certain object type. To demonstrate the local property name, we
can just type ‘Class’ and accept this local name by pressing the
OK button. |

Figure 2-6. Local name dialog.
| Now
the created property has been added to the Class state object
type. |
9) | Close
the Property Tool window. |
Now you have defined
a new property type ‘Related class’ for the ‘Class
state’ object type. The new property type is available for use in other
types as well.
Documenting the object type
The object type should be documented for later reuse purposes
and especially to provide help for the method users: when the user selects
Help | Method in any of the MetaEdit+ tools these descriptions are shown
to provide method guidance for the user.
1) | Type
a description for Class state into the description
field. |
Generating the new object type
When the object type has been defined by its properties, name
and description, it can be saved into MetaEdit+’s repository. Notice that
everything from the object type definition can be changed even after that,
except the ancestor type.
To define the object type:
1) | Press
the Generate button at the bottom of the
window. |
Now a new object type has been added
to the MetaEdit+ method base. The object type can later be reused in other
methods as well.
All object types with properties should have a dialog, to
allow the user to enter property values when he creates an instance of that
type. As there is no dialog yet defined, MetaEdit+ asks you whether to
automatically create a default property dialog.
2) | Install
a default dialog for the new object type by selecting Yes in the dialog
that appears. |
When the object type has been
generated, it is ready for use. To make it more usable, we can continue to
define a better layout for the dialog, and add a symbol to represent objects of
this type in diagrams.
Defining a dialog for the object type
To define the appearance of the property dialog of the Class
state:
1) | Press
the right mouse button in the Properties list to open its pop-up menu, and
select Edit Dialog. |
This opens a
default dialog for the Class state object type
(
Figure 2-7).
The default dialog contains an appropriate widget for each property type
(depending on its data type and, for string types, widget setting), laid out one
under another. At the bottom are the standard
OK,
Cancel and
Info... buttons, which must be in all property dialogs. As the length of
the dialog is greater than the height of a standard VGA screen, a vertical
scrollbar has been added automatically.

Figure 2-7. Property Dialog for Class state.
Next we shall
adjust the appearance of the property dialog by changing the order of properties
and tab order between the fields.
Set order of properties
First, the property dialog could be easier to use, if the
Class state property is closer to the name field. To change the order of
properties and size of the dialog:
1) | Select
all the components in the dialog window: to select them, either shift click
each, or drag to select an area from the top left corner to the bottom right
corner. Press Esc-F to make all components have fixed positions.
|
2) | Scale the
dialog window larger by selecting the right bottom corner of the window and move
it to the right to double the width of the window, leaving space for another
column of properties. No components should move when you resize the window.
|
3) | Select the
label ‘Class’ with the mouse, press the shift key and select the
Class field, which is next to the label.
|
| If
the selections succeeded you should have both items marked by black boxes in
their corners. Note that the label and field should always be moved together, so
the user knows which field is
which. |
4) | To
move the items together, click somewhere in one of the selected items and drag
them up and to the right, to the top of the empty column.
|
5) | To align the
Class label and field with the State name field, select the State name field and
then by keeping the shift key pressed select the Class label and field
again. |
6) | Open
the pop-up menu with the right mouse button, and choose
Align.... |
7) | In
the alignment tool (Figure 2-8) select
‘on horizontal line’ and press OK. The other setting should
be ‘first selection’. |

Figure 2-8. Setting alignment.
The Class label and field
are now moved horizontally to be in line with the State name field.
8) | Next
move the remaining fields of ‘Documentation’ and ‘Symbol
transparent?’ along with their labels to below the ‘Class’
field. |
9) | Select
the buttons together, and move them to below the fields in the right
column. |
10) | The
vertical scroll bar is no longer necessary, so it can be removed by choosing
Toggle Vertical Scroll Bar from the dialog’s pop-up
menu. |
11) | If
necessary, adjust the dialog components’ positions and sizes to look like
Figure 2-9.
|
12) | Scale the
dialog window smaller by selecting the bottom right corner of the window and
moving it up so that the bottom of the window is close to the lowest
component. |
You may use the alignment tool as
in Step 7 and also the Equalize tool to set the size and position of fields to
be similar to each other. You may also save your changes by closing the window
and pressing Yes button in the dialog asking for dialog definition
installation.

Figure 2-9. Adjusted dialog for Class state.
The current
dialog does not yet include scaling information for fields and for labels, so
next we set these. If you have closed the property dialog to save it, open it
again be choosing Edit Dialog from the properties list of ‘Class
state’ Object Tool.
Because dialog elements (fields, labels, buttons) scale
differently scaling information is set for each individual element with the
Properties tool. To open Properties tool for one of the dialog elements (e.g.
for ‘Operations’):
1) | Choose
the ‘Operations’ field with the
mouse. |
2) | Press
Esc-P. |
3) | Click
the Position page of the Properties
tool. |
4) | Choose
to keep the current visible position by pressing the small buttons on the right
of each Offset field.
|
5) | Move the
slider in the proportions fields to set the correct proportions for the
‘Operations’ field as shown in
Figure 2-10: do not change any settings
in the Offset
fields. |
6) | Accept
proportions by pressing Apply button in the bottom of the Properties
tool, and the Offset fields will be recalculated to keep the component in its
current visible place. |
A left proportion of 0
and offset of 117 means that the left side of the field is fixed to the location
of 117 pixels from the left side of the window. A top proportion of 0.5 and
offset of 14 is 14 pixels from the middle of the window. Thus if the window is
scaled and the vertical middle of the window moves the top position of the
‘Operations’ field also moves. A left proportion of 0.5 and offset
of -23 means that the left side of the field is always 23 pixels left from the
imaginary horizontal middle line of the window. A bottom proportion of 1 and
offset of -26 means respectively that the bottom of the field is always 26
pixels above the bottom of the whole window.

Figure 2-10. Properties tool for ‘Operations’.
Enter
correct proportions values for other dialog elements similarly. You may use the
currently open Properties tool by clicking the dialog element in the property
dialog and then move back to the Properties tool. Alternatively you may also
Prev and Next buttons to retrieve Proportion values directly from
the Properties tool.
The correct values for proportions (and offsets)
are:
State name field: L 0 (117), T 0 (10), R 0.5 (-23), B 0
(35)
Variables field: L 0 (117), T 0 (45), R 0.5 (-23), B 0.5
(4)
Operations field: L 0 (117), T 0.5 (45), R 0.5 (-23), B 1
(-26)
Class field: L 0.5 (141), T 0 (10), R 1 (-11), B 0
(35)
Documentation field: L 0.5 (5), T 0 (65), R 1 (-11), B 1
(-120)
Symbol transparent?: L 0.5 (142), T 1 (-110), R 0.5 (-11),
B 1 (-90)
State name label: X 0 (10) Y 0 (10)
Variables label: X 0 (10) Y 0 (45)
Operations label: X 0 (10) Y 0.5 (14)
Class label: X 0.5 (5) Y 0 (10)
Documentation label: X 0.5 (5) Y 0 (45)
Symbol transparent? label: X 0.5 (5) Y 1 (-110)
All buttons should have values L 0.75, T 1, R 0.75, B
1.
Setting the tab order
Because we have changed the visual order of properties will
want to change the tab order as well. The tab order is the sequence of fields
and buttons the user can move through using the tab key. To change the tab
order:
1) | Select
fields (not label texts) and buttons in the following order: State name,
Variables, Operations, Class, Documentation, Symbol transparent?, OK, Cancel,
and
Info... |
2) | Open
the pop-up menu with the right mouse
button. |
3) | Choose
Tab Order from the menu. |
The tab order
has now been set for the dialog of Class state.
Saving dialog definition
To finish the window definition close the window from its
title bar. A dialog will appear
(
Figure 2-11) asking you to save the
definition of the dialog. Press
Yes.

Figure 2-11. Save dialog definition dialog.
The window
definition is now ready.
Defining a symbol for the object type
When the object type and its property dialog have been
defined, the only thing left is to define a symbol for use in the graphical
state diagrams. If no symbol is defined, the object type can be used, but will
be represented by a blank square. To define a better symbol, we will use the
Symbol Editor for this type:
1) | Open
the Symbol Editor by clicking the Symbol button in the Object Tool. This
will open an empty Symbol Editor for the Class state object
type. |
| Now
you can draw the symbol of the Class state with the Symbol Editor, which is a
drawing tool much like any basic vector graphic editor. The Class state symbol
contains a rounded rectangle with a number of property fields, including the new
field to show the class. We could copy this symbol directly from the existing
UML class, but to demonstrate the functions of the Symbol Editor we shall define
the whole symbol from the
beginning. |
2) | Select
the rectangle tool from the button in the Symbol Editor
toolbar. |
3) | To
draw a rounded rectangle at the default size, hold shift down and click in the
drawing area with the left mouse button. The point you click is the top left of
the rectangle, and should be on the left of the drawing area, and level with
about half-way down the
toolbar. |
4) | Enter
50 for the radius of the rounded rectangle corners and press
OK. |
Now you have created the first part
of the symbol definition. Because the default zoom level in Symbol Editor is
400% (at this zoom factor, symbol manipulation is most accurate) the created
symbol will look large. You may need to resize the window to see all of it. To
check the size that will be used in the Diagram Editor you can look at the
symbol at 100% zoom by selecting View | Zoom... in Symbol
Editor.
We shall continue the symbol creation by adding property
labels and conditional symbols.
Adding a property label to the symbol
A symbol normally include one or more property labels to show
the name and other values for the design elements in diagrams. You must choose
which of the Class state’s properties should be show in the symbol, and
where. The identifying property ‘State name’ should obviously be
shown, as well as the new property we added showing the class the State
characterises. To show more complex properties, you can add also the Operations
collection property to the symbol.
To add the State name property:
1) | Select
the State name property from the properties list (in the lower left corner of
the
window). |
2) | Drop
the property inside the rectangle symbol by clicking and dragging the mouse from
just outside the top left corner to fill the width of the rectangle. As this is
a rounded rectangle, we should leave a little space around the property label,
so the first character does not start outside the rounded corner (see
Figure 2-13). |
If
necessary you may also scale the property label or the rectangle symbol to fit
the property inside the rectangle symbol. To do this, first make sure the top
left corner of the element is where you want it: scaling only moves the bottom
right corner. Then:
1) | Select
the property label of State name
property. |
2) | Select
the scale button (the bottom right button on the toolbar, with a letter j and
scaling arrow
symbol). |
3) | Click
the property label again and move the bottom right corner of the property box to
the right position. |
The size of the property
box limits how many rows of the property text may be shown in the symbol,
depending of course on the font size. Therefore it is useful to scale the
property box so it fits the number of rows you would like to reserve for the
text. In our case the State name and Class could have one row and the Operations
three rows. This means that each time a Class state is created by default size
it can show State and class names of ordinary size and up to three operations.
If the names are longer or there are more than three operations the Class state
may be scaled in the Diagram Editor.
Choosing font, size and style
The choice of font and size is slightly different from what
you may be used to. As MetaEdit+ works on several platforms, platform-specific
fonts cannot be used directly, but instead generic fonts are used, which are
mapped to an appropriate font on each platform. Similarly, the most important
factor in sizing text is that it fits within the relevant box, whose height is
measured in pixels: pixels thus form a more appropriate measure of font size for
symbol elements than the more normal points. By default the property label has a
16 pixels high sans serif font, roughly corresponding to 12pt Arial on Windows
platforms. This setting can be changed individually for each property or text
label.
To change the property label font:
1) | Select
the State name property
label. |
2) | Select
Font... from the property label’s pop-up
menu. |
| Now
you have opened the font setting tool of the Symbol Editor
(Figure 2-12). You may choose the font,
size and style. |
Figure 2-12. Font settings for the State name label.
3) | Select
14 pixels and bold, as in Figure 2-12
and press OK. |
This font selection is
immediately shown in the symbol definition. If necessary you may now move and
scale the property box as described above.
You may continue the symbol definition by adding the
remaining two properties to the symbol and adjusting their size and location.
The Class property goes above the rounded rectangle, and the Operations property
fills the remaining space in the rounded rectangle below the State name. The
result after this stage should look like
Figure 2-13.

Figure 2-13. Class state symbol with properties.
Alignment of property label text
Next we shall modify the alignment and justification of the
property label. By default the text is aligned with the top of its label box,
left-justified, and word wrapping is turned on.
To change the alignment to horizontally and vertically
centred:
1) | Select
the Class property
label. |
2) | Open
the text alignment tool by choosing Text Alignment... from the property
label’s pop-up menu (or Label | Text Alignment from the menu bar).
|
| A
dialog will appear asking how the property value should be aligned within the
label box
(Figure 2-14). |
3) | Click
the radio button in the middle (as in
Figure 2-14) and press
OK. |

Figure 2-14. Text alignment dialog.
The resulting alignment
can be seen from the property’s name, which is shown in place of the
property value in the Symbol Editor. Repeat this alignment for the State name
property.
Setting word wrapping
Word wrapping means that if the property box is not wide
enough for the current line of text, it will wrap round to the next row. Text
will not however wrap down outside the boundaries of the property label box. By
default word wrap is on. The default setting is correct for most cases, but for
collection properties we often want to show only one operation in each row,
cutting it off at the right boundary of the label box rather than letting it
wrap round to the next row.
The Operations label shows such a collection property. To
change the word wrapping:
1) | Select
the Operations property
label. |
2) | Open
the alignment tool from the pop-up
menu. |
3) | Click
the word wrap off and press OK. |
This
setting has now changed the wrapping. To test it you may try to scale the
property box to be thinner, and see that the Operations string no longer wraps
to the second line.
Adding conditional symbol elements
By default the class symbol is represented as we have drawn it
now. In some cases, it could be more suitable to show a transparent and larger
symbol, which could then visually contain substates inside this state. For this
purpose we define a conditional representation using the ‘Symbol
transparent?’ property type, inherited from the ancestor of the Class
state, the standard State [UML] symbol.
Each symbol element may have a condition attached to it,
which determines whether that element is drawn for a given instance, depending
on a property value in the instance. In the Symbol Editor, all symbol elements
are shown, regardless of their conditions. The ‘Symbol transparent?’
property allows us to make two versions of the symbol, one for when the property
is false, and one for when the property is true. Each version will contain a
number of elements, each of which will have the same condition.
We first enter conditions for the existing symbol
elements, then we add the ‘superstate’ version of the symbol and
attach conditions for it.
To specify conditions for the symbols:
1) | Select
all the current symbol elements by choosing Edit | Select
All. |
2) | Choose
Set Condition... from the pop-up menu or from the menu bar item
Edit.
|
3) | Select
‘Symbol transparent?’ from the Property
list. |
4) | Enter
condition value ‘F’ for false (like in
Figure 2-15) and press OK. This
means that if property Symbol transparent? is false the current symbol elements
are shown; conversely, if the property value is true, these elements will not be
shown. |

Figure 2-15. Entering condition for displaying symbols.
Next
we shall add the ‘superstate’ symbol. The symbol creation process is
similar to that used earlier, but we keep in mind that this symbol will normally
be scaled to be much larger when it is used. This means it is better to use a
normal rectangle than a rounded rectangle, so we do not lose so much drawing
space at the corners. Also, property label’s font sizes do not scale when
instance symbols are scaled, since the purpose of scaling is normally to fit
more text in. This means we can make the property label boxes smaller than
normal, so that whilst the text will not be fully visible in the default scale,
it will work fine at the larger scales where this version of the symbol will be
used.
First we will add the main rectangle:
1) | Select
the rectangle tool from the button in Symbol Editor
toolbar. |
2) | Click
and drag in the drawing area with the left mouse button, to insert a rectangle
of the correct size. Make the rectangle the same size as the rounded
rectangle. |
Next we can change the colour of
the superstate symbol to distinguish it from the ordinary state symbol, and to
make it transparent. To set the colour:
1) | Select
the superstate
rectangle. |
2) | Choose
Foreground Colour... from the pop-up menu or from the Colours
menu. A window with possible colours will
appear. |
3) | Select
the blue colour button.
|
4) | Choose
Background Colour... from the pop-up menu or from the Colours
menu. A window with possible colours will
appear. |
5) | Select
the Tran colour button, for ‘transparent’ colour, so the
rectangle will not be filled, and other states can be seen ‘through’
it.
|
 | You
may find it easier at this point to move the blue rectangle to the side, away
from the other symbol, and work there. After you have finished working with the
elements of the superstate version of the symbol, you should select them all and
drag them back on top of the normal
version. |
In addition to the blue rectangle
we may attach the State name and Class property labels to the alternative
symbol. First change the default colour to be black, if it is not already. Add a
new State name property label to the top left corner of the blue Class state
rectangle and Class property label above it. Use alignment and font setting
tools to make the State and Class names stay near the top line of the symbol
when it is scaled. To do this:
1) | Make
sure the bottom of the Class label, the top of the State name label, and the top
of the blue rectangle are all on the same line. For instance, to align the Class
label with the top of the blue rectangle first select the blue rectangle and
then the Class label. From the menu bar choose Align | Bottom to Top.
This selection moves the bottom of the Class label to the top of the blue
rectangle. |
2) | Set
the alignment of the State name for the superstate symbol to be top-centered
(select it and choose Text Alignment... from its pop-up
menu). |
3) | Set the
alignment of the Class label to be bottom-centered.
|
In this way the property labels remain close
to each other even when the superstate symbol is scaled to be large.
To complete the alternative representation for the Class
state we must add conditions to all its elements.
1) | Select
the blue rectangle and the new property
labels. |
2) | Select
Set Condition... as before but choose now ‘T’ for the value
of the ‘Symbol transparent?’ property and click
OK. |
 | If
you moved the alternative version of the symbol away from on top of the other
version, you should now drag it back. |
Now
you have added quite a complex symbol for the Class state. It has two different
shapes and different numbers of properties are shown, depending on the value of
each state’s properties. Because the symbols are overlapping you may
change of the order of them by choosing
Edit | Bring To Front or
Edit
| Send to Back. If you have created the symbol according to the instructions
given above the symbol should look now like
Figure 2-16.

Figure 2-16. Symbol for Class state.
Add connection points
Although the symbol is now ready we must attach connection
points to it to define where the role lines end. In most cases the connection
points form a rectangle which contains all the elements of the symbol. In our
case the connection points will include only the symbols but not the Class
property labels above the rectangle and box. Hence we must set the connection
points around the superstate symbol. Although the symbols are of the same size,
the selection of the ordinary Class state symbol with rounded corners is not
suitable because then the role lines to the corners would be drawn partially
inside the superstate symbol. Since connection points may not have conditions,
we must make a choice that works well for both versions of the symbol.
1) | Select
the blue rectangle. You may need to use Edit | Bring To Front or Edit
| Send to Back to make the rectangle the front-most element, so you can
select
it. |
2) | Choose
Connections | Add Points for Selection from the menu bar.
|
As a result of the connection point creation
four green dots appear in the corners of the blue superstate symbol. If you
would like to see the size of the Class state symbol used in the Diagram Editor
set the zoom factor to 100% by selecting View | Zoom... and setting the
slider to 100%. If you feel that the symbol is too small or large you may scale
the whole symbol:
1) | Select
Edit | Select
All. |
2) | Click
the scale button in the
toolbar. |
3) | Click
on the selected symbols and drag the bottom right corner to scale the symbol to
a new size. |
Saving the symbol
Finally you must save the created symbol by selecting
Symbol | Save from the menu bar. This will save the symbol
and connect it to the Class state object type. You may also save the symbol to
the library for reuse by selecting Save | Add to Library....
Now you have defined the Class state object type both from
the conceptual and representational point of view and it is ready to be used as
a part of the improved State Diagram. To close the Symbol Editor select
Symbol | Exit.
2.2.2 Defining the relationship types
After the object types have been defined you should specify
the relationship types of the method. The relationships are defined within the
Relationship Tool, which can be started by selecting Metamodel | Relationship
Tool in the MetaEdit+ Launcher. The Relationship Tool looks similar to
Object Tool, and is used in the same way.
Because our method modification task do not require any
new relationship types we shall just briefly look at one relationship type used
in the State Diagram of UML.
To view the definitions of the Transition relationship
type:
1) | Press
the right mouse button in the Name field. In the menu select Choose
Type.... |
2) | Select
‘Transition [UML]’ from the list (it is a descendant of
‘Communication’, and so listed under that) and press
OK. |
This operation retrieves the
definitions of the Transition relationship type into the Relationship Tool as
illustrated in
Figure 2-17. This
relationship type has already been defined in the MetaEdit+ standard method
base, and the same type can be reused for our new improved State Diagram.
Transition [UML] is a descendant of the ‘Communication’ relationship
type and it has several properties, such as Event name and
Send-clauses.

Figure 2-17. Relationship Tool for Transition.
If our
method modifications required it, we could now change the relationship
definition by adding new properties or symbols to the Transition.
Symbol definition to relationships
Although the definitions of relationship types are similar to
object types, the symbol definition and especially the connection points are
often made differently. This is because object types normally have a visible
symbol which has four (or more) connection points around it, but relationship
types often only have property label boxes, whose values may often be empty.
Using connection points around the whole relationship symbol would lead to an
apparent gap in the role lines between objects. A better solution is to allow
the role lines to pass through the property labels, as it hardly affects
readability. We can arrange the property labels so the role lines will often not
pass through them, e.g. when they are horizontal, and add only one connection
point to the symbol. For this purpose the Symbol Editor can add a single
connection point in the middle of the symbol (Connections | Add Point at
Center).

Figure 2-18. Symbol for transition.
Adding a point at the
center, however, does not work well if some of the elements are larger than
others and the center is not in an empty area. For example, if the event name in
the
Figure 2-18 would be two lines high
the center would then be inside the event name property label.
In this situation, a useful technique is to add a large
text label whose contents are just a space, giving it an area a little bigger
than the total area of the other components, and then adding a connection point
at the middle of this symbol. This empty text element can be seen in
Figure 2-18 as the red text label line
around all symbol elements. One connection point can be added with
Connections | Add Point. The connection point can then be easily aligned
by first selecting the large text label, then the single connection point and
then choosing
Align | Centres. This is what has been done for Transition
[UML] (see
Figure 2-18). Note that the
point must be exactly in the centre, otherwise ‘straight’
relationship lines will not be perfectly straight.
You may now close the Symbol Editor by selecting
Symbol
| Exit; do not save any modifications you may have
made.
2.2.3 Defining the role types
Each relationship needs at least two roles, which define the
appearance of the lines and ends of the relationship, and any properties
associated with them. The role types are defined in a Role Tool, in the same way
as object and relationship types.
Typically roles contain some information about the part
the object plays in the relationship, and some have symbols such as arrows,
forks etc.
Because our method modification task does not require any
new role types we shall briefly look at one role type called Receives. This role
type is already defined in the MetaEdit+ standard method base and used in
several methods including the UML State Diagram.
To view the definitions of the Receives role
type:
1) | Start
a Role Tool by selecting Metamodel | Role Tool in the MetaEdit+
Launcher. |
2) | Press
the right mouse button in the Name field. In the menu select Choose
Type.... |
3) | Select
‘Receives’ from the list and press OK
button. |
This operation fetches the definition
of the Receives role type into the Role Tool. As illustrated in
Figure 2-19 the Role Tool is very
similar to other method development tools. From the Role Tool we can find that
the Receives role type is a descendant of Sends role type and that it does not
have any properties.
Note that the Receives role type is stored in the
‘mcc’ project, because it is used in many methods. The
‘mcc’ project includes those method elements that are used in more
than one method and thus it is normally always loaded together with a method
project. This is simply a design decision we made to maximise reuse: the
‘mcc’ project is a perfectly normal project.

Figure 2-19. Role Tool for Receives role type.
Because the
role symbols rotate, and are placed in diagrams at the intersection of the role
line and the object symbol, their symbol definition differs slightly from object
and relationship types. This difference can best be demonstrated by opening the
symbol definition from the
Symbol button. This opens a Symbol Editor for
Roles (
Figure 2-20). Note that the
Symbol Editor is opened with 400% scale and thus the arrow symbol is not
necessarily visible in the window: resize the window or scroll to the right to
see it.

Figure 2-20. Symbol Editor for Receives role type.
The
Symbol Editor for Roles always contains a line coming from the left edge to the
middle of the window. The line represents the relationship from its middle point
to the end where it connects to an object. Hence, the role symbol elements
should be located relative to the right-hand end of the line. For example, in
the Receives role symbol the tip of the arrow is exactly on the end-point of the
line. The result in a Diagram Editor is shown in
Figure 2-1.
You may now close the Symbol Editor by selecting
Symbol
| Exit. Do not save the possible modifications you
made.
2.2.4 Defining the Graph Types
The last thing to do for the method definition is to gather
the method components together with the Graph Tool. The Graph Tool defines not
only the name and other properties of the graph type, but also defines the
object, relationship and role types that are included in the graph type. A graph
type usually represents one method or kind of diagram within a method
(technique), e.g. UML is a method that contains several diagram types or
techniques, and so there are several graph types for UML. One of these is the
State Diagram.
To define the improved State Diagram with a Graph Tool:
1) | Open
the Graph Tool by selecting Metamodel | Graph Tool in the MetaEdit+
Launcher. |
2) | In
the Graph Tool name field select Make Descendant... from the pop-up
menu. |
3) | Select
‘State Diagram [UML]’ from the window that opens
(Figure 2-21) and press
OK. |

Figure 2-21. Selecting ancestor graph type.
| This
operation fetches the definitions of the UML State Diagram into the Graph Tool,
as illustrated in Figure 2-22. The
descendant graph type inherits the properties of its ancestor: as you can see,
the Properties List in the middle of the Graph Tool window is filled with the
properties of State Diagram [UML]. These inherited properties are shown with
dark red text. Inherited properties cannot be changed here: they can only be
changed in the ancestor that defines
them. |
| In
addition to property types, the Make Descendant operation also copies the types,
bindings, constraints, explosions and decompositions defined in the ancestor
graph type. Note that these are only copied (not inherited) and therefore you
can change them. The copy is simply to speed up the definition of the subtype,
as demonstrated in the following. |

Figure 2-22. Graph Tool for State Diagram.
4) | In
the Graph Tool write ‘State Diagram for Classes’ in the Name
field. |
5) | Give a
brief description of the method in the description
field. |
6) | Press
the Generate button to define the new graph type, and select Yes
to generate the default dialog. |
Defining the components of the method
After defining the graph type you can now define which object,
relationship and role types are used in this method. As we already mentioned,
the new graph type has been initialised to include the types of its ancestor.
Now we just need to replace the old State object type with our new Class
state.
To replace the type:
1) | Press
the Types button to start the type definition tool. An open Types Tool is
shown in the
Figure 2-23. |

Figure 2-23. Types Tool.
2) | In
the Types Tool select Add... from the Objects list’s pop-up menu.
|
| This
will open a selection dialog, such as the one in
Figure 2-24.
|

Figure 2-24. Object type selection dialog.
3) | Select
the type you defined, ‘Class state’, from the dialog, and press
OK. This type will then appear in the objects
list. |
Next we need to remove the old
unnecessary type:
1) | Select
‘State [UML]’ from the Objects
list. |
2) | Open the
list’s pop-up menu and choose
Delete. |
Now we have added a new object
type and removed the old one. Next we need to define the roles and relationships
the new object type can participate in.
Defining bindings of the components of the method
An important part of the definition of a method is the
definition of its bindings, i.e. the connections between object types. Each
binding of types consists of one relationship type, two or more role types and
one or more object types in each of the roles. Thus a binding defines which
objects can play which role in a given relationship.
To define the binding
for the new
Class state object type, we would normally have to replace every occurrence of
State [UML] in a binding with Class state. In this case, however, we created
Class state as a subtype of State [UML], and bindings take inheritance into
account for object types. Thus the bindings are already correct.
For the sake of illustration, we will however change one
binding:
1) | Open
the Bindings Tool by pressing the Bindings button
in the Graph
Tool. |
2) | Select
Note connection from the Relationships list. The roles for this binding will be
shown. |
3) | Select
Object part from the roles list (i.e. middle list). The objects for this role
will be
shown. |
4) | In the
objects list of the Bindings Tool
(Figure 2-25) select Add... from
the pop-up menu and from the dialog that appears select Class state and press
OK. Note that this selection dialog only shows the object types currently
in the Types
Tool. |
5) | Select
State [UML] from the object list, and choose Delete from its pop-up
menu. |

Figure 2-25. Bindings Tool.
Now you have replaced State
[UML] in one binding related to making note connections. To finalise binding
creation you would have to replace State [UML] with Class state in the remaining
bindings by repeating the steps described above for each role of each binding.
In this case, though, the bindings will already work as we want them to, so we
can proceed to the next step.
Defining explosions and
decompositions of the method
The last thing to do for a graph type definition is the
selection of possible explosions of objects, relationships and roles, and
possible decompositions of objects. Explosions define into which graph types
objects, relationships, or roles of a certain type can explode, for example
States in a State Diagram could explode into Operation tables. Decompositions
show which object types can be functionally decomposed, often into graphs of the
same type as the original. For example, the Class state can decompose into our
new State Diagram for Classes.
To allow a decomposition from the Class state into the
improved State Diagram for Classes:
1) | Press
the Decompositions button in the Graph Tool. The decomposition definer
window shows the currently defined possible
decompositions. |

Figure 2-26. Decomposition definer.
2) | Choose
Add... from the pop-up menu of the left-hand list. This opens a list of
object, relationship, and role types belonging to the graph type.
|
3) | Select the
type for which you want to add decompositions (i.e. Class state) and press
OK. |
4) | Select
the new Class state type in the left-hand list.
|
5) | In the
Graphs list choose Add... from the pop-up menu. This will open a
dialog that shows the available graph types. Select State Diagram for Classes
and press
OK. |
| Now
a State class in a State Diagram for Classes can decompose into another State
Diagram for Classes. We should also remove the old decomposition of State
[UML]: |
6) | Select
the State [UML] object type from the Objects
list. |
7) | Choose
Delete from the pop-up menu of the Objects list.
|
Next we need to change the decomposition of
Package to point to the new State Diagram for Classes:
1) | Select
the Package object type from the Objects
list. |
2) | Select
Add... from the pop-up menu of the right-hand list, the Graphs list. This
opens a list of graph types.
|
3) | Select State
Diagram for Classes and press
OK. |
4) | Select
the old State Diagram [UML] from the Graphs list, and choose Delete from
its pop-up
menu. |
5) | Close
the Decompositions definer window. |
You should
now replace all explosions from the old State [UML] with explosions from the new
State class:
1) | Press
the Explosions button in the Graph Tool. An Explosions definer
opens. |
2) | Select
State [UML] in the Objects list. Its current explosion to an Operation Table is
shown in the Graphs
list. |
3) | Choose
Delete from the Objects list’s pop-up
menu. |
4) | Choose
Add... from the Objects list’s pop-up menu. In the dialog that
opens, select Class state and press
OK. |
5) | In
the Graphs list, choose Add... from the pop-up menu. In the dialog that
opens, select Operation Table and press
OK. |
Completing the graph definition
After defining the explosions and decompositions you have
defined the improved State modelling technique. You can now accept the changes
in the Graph Tool and are ready to test the method.
1) | Press
the Modify button in the Graph Tool to accept the changes (or
Generate if you did not create Graph definition
earlier). |
2) | Start
any editor (Diagram, Matrix or Table) from the MetaEdit+ Launcher and create a
new State Diagram for Classes graph. See MetaEdit+ User’s Guide for
details of creating new graphs with the selected
tool. |
Defining explosions to the new graph type
In addition to the explosions and decompositions from
the new graph type, we must add also explosions and decompositions to the
new graph type, from other types. This means that we replace the links to old
State Diagram with links to State Diagram for Classes. Alternatively, we could
add the new diagram as an alternative, and keep the old links.
For example, to define that Class in Class Diagrams should
now explode to the new State Diagram for Classes:
1) | Open
another Graph Tool by selecting Metamodel | Graph Tool in the MetaEdit+
Launcher. |
2) | In
the Graph Tool name field select Choose Type... from the pop-up
menu. |
3) | Select
‘Class Diagram [UML]’ from the window that opens press
OK. |
4) | Press
the Explosions
button. |
5) | Select
Class [UML] from the Objects
list. |
6) | Select
State Diagram [UML] from the Graphs list and choose Delete from the
pop-up menu. Now we have removed the old explosion link and we must create a new
one to the State Diagram for
Classes. |
7) | In
the Graphs list choose Add... from the pop-up
menu. |
8) | Select
State Diagram from Classes from the list dialog and press OK (cf.
Figure 2-27). |

Figure 2-27. Updated explosion for Class.
9) | Press
Modify in the Graph Tool, and close
it. |
The same procedure should also be done for
the other explosions and decompositions in the Class Diagram, and any other
graph type from which there is an explosion or decomposition to the old UML
State Diagram. You can find such graph types easily with the Metamodel Browser:
type ‘State*’ as a filter for the Graphs types list and choose the
Explosion from the Tree pull-down menu. Now the Graphs types list only
shows State Diagram [UML], and any graph that explodes to it.
Finishing the tutorial
If you are satisfied with the method and want to keep it,
commit the transaction from the Launcher. If you want to get rid of the method,
press Abandon in the Launcher.
Now you have finished the MetaEdit+ Method Workbench
tutorial and you are ready to start real method development.