Up Previous Next Title Page Index Contents

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.

 The empty Object Tool is in Figure 2-2.
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.

Up Previous Next Title Page Index Contents