6.3 Designing with
MetaEdit+
6.3.1 Starting MetaEdit+
To start MetaEdit+ double-click the MetaEdit+ icon (for
further information, see your installation instructions).
When MetaEdit+ is started it first opens a Startup
Launcher as shown in
Figure 6-2. Most of
the functions available from the Startup Launcher are related to the management
of the repository, and are explained in Sections
2.1.1 and
5.1.1. Here
we just describe the login process.

Figure 6-2. Startup Launcher.
Login
To login for the tutorial:
1) | Press
Login button in the Startup
Launcher. |
2) | Select
the demo repository from the list that opens and press OK
(Figure 6-3). If ‘demo’ is
not available, please install it from your MetaEdit+
media. |

Figure 6-3. Choose a repository.
3) | Enter
your user name and password
(Figure 6-4). When MetaEdit+ is
delivered the default user name and password are both ‘user’: use
tab or the mouse to move between the fields, not
return. |

Figure 6-4. Entering user name and password.
After a successful login the
Startup Launcher will close, and the main MetaEdit+ Launcher opens
(
Figure 6-5).

Figure 6-5. MetaEdit+ Launcher.
 | If
you are using an evaluation version of MetaEdit+ and you are logging in for the
first time you are asked here for the evaluation password
(Figure 6-6). Please note that the
window for entering the evaluation license code can be hidden behind another
application, e.g. if you are viewing this manual in a browser. Fill the field in
exactly as written in the evaluation instructions and press OK. The
launcher will briefly flash red and then
green. |

Figure 6-6. Window for entering evaluation license code.
Choosing a method
Together with the main Launcher
(
Figure 6-5) you will get a dialog list
where you can select the projects you want to load
(
Figure 6-7). Projects can consist of
pre-defined methods, such as ‘SA/SD’ or ‘UML’, or
include models based on one or several methods, such as ‘Tutorial’
and ‘Examples’: opening a project with models will automatically
load any necessary methods.

Figure 6-7. Choosing a method.
Since we have not made yet any
models about the Ball Game application we shall first choose the method.
1) | Select
‘UML’ from the list of projects and press OK.
|
MetaEdit+ now reads all the method
definitions related to UML from the repository. Next MetaEdit+ asks for the
project into which new models should be stored. Since UML is the only project
opened yet select it and press OK. We shall change the default project
later during this tutorial.
Creating a project
As we are starting a new project, we should make a new area of
the repository where the models we make can be stored (see Section
5.1). To create a project for the game
application:
1) | Choose
Repository | New Project... in the
Launcher. |
2) | Give
a name for the project (e.g. Ball Game) in the dialog that opens
(Figure 6-8). |

Figure 6-8. Entering a name for new project.
Next the tool
asks information about the other users who should have access (read and write)
to the models in the new project. If you are using a single user version the
list of other users will be empty, as the only other user defined is the system
administrator, and system administrator users always receive access to new
projects.
3) | Press
OK. As a result, MetaEdit+ creates a new project into the repository,
commits it, and opens it. |
Choosing the default project
After creating a project, there are now two possible projects
into which new models can be stored. The ‘UML’ project opened during
login was automatically set as the default, where new models would be stored. To
store new models into the ‘Ball Game’ project we must select it as
the default project.
The default project can be set from the Browsers. To set
the default project from a Type Browser:
1) | Click
the Types button or select Browsers | Type Browser in the
Launcher. |
2) | Choose
‘Ball Game’ from the pull-down list under the project list on the
left. |
We have now started MetaEdit+, selected
a method to be used and created a new project for our designs. Now we are ready
for modelling.
Exiting and saving changes
At any point of tutorial you may stop working and save your
changes. You can then later on continue the tutorial by logging in to MetaEdit+
as described at the beginning of this Section
(
6.3.1), and opening the Ball Game
project.
If you want to stop working with the tutorial and continue
it later you must save your changes (see also Section
5.1.1). To do this choose
Repository
| Exit... in the Launcher. You should choose
Normal Exit in the first
dialog that opens, and then
Commit in the second dialog: abandon would
undo all operations back to the last commit.
6.3.2 Using the Table Editor
We start the design by finding and defining classes. Because
the Ball Game is a relatively user-interface centred application many of the
object candidates can be found from
Figure 6-1. Some of these object
candidates are
Ball,
Paddle, and
Wall.
If we are building a large application it is often useful
to collect object candidates first as lists instead of applying graphical
notations and building one or several
diagrams
[2]. We thus first make an initial class
list using the simple Table Editor.
Opening a Table Editor
To open a Table Editor:
1) | Choose
Editors | Table Editor in the
Launcher. |
2) | Select
‘Class Diagram [UML]’ from the method list
(Figure 6-9), and click OK. You
can also double-click the item on the list to make a selection and accept it. If
you can not select the UML class diagram close the dialog by pressing
Cancel and open the UML method as described in the earlier section for
choosing a method. |

Figure 6-9. Method selection dialog.
 | The
dialog for creating a new graph does not necessarily appear immediately. If you
have already opened other projects which include models, MetaEdit+ first asks
you to select one of the existing graphs; at the bottom of the list is the
option ‘Create new graph’
(Figure 6-10). For the tutorial you
should select this and press OK, then the dialog above will
open. |

Figure 6-10. ‘Create new graph’.
As a result a
dialog asking information about the graph opens as in
Figure 6-11. Enter the model name (e.g.
‘Ball game structure – Analysis’) and other information to the
property fields and press the
OK button. Note that the Status field has a
pull-down menu that allows you to select one of the predefined values from the
list; typing a new value will add it to the list of possible values used for
this property in this project. The author field in the dialog is a collection
property type allowing you to enter several ‘Author’ objects, each
with its own properties (e.g. name, address). To add authors select
Add
Element... from the Authors field’s pop-up menu.

Figure 6-11. A dialog for entering information about the ‘Ball Game structure - Analysis’ graph.
After
you have entered the information about the graph and pressed
OK, a
selection dialog will appear
(
Figure 6-12) asking you to choose the
type of model element to be shown (a Table Editor can only show instances of one
type). Choose ‘Class [UML]’ and an empty Table Editor opens
(
Figure 6-13).

Figure 6-12. Selecting an object type.
Although the Table
Editor is empty, i.e. no Classes have been defined, it already contains several
column items: e.g. class name, attributes and operations. Thus, each of the
properties of the Class is represented in the columns of the table and each
Class will form a row of the table.

Figure 6-13. Table Editor.
Adding objects
Next we shall start to fill in the table by adding the object
candidates
Ball,
Paddle, and
Wall found from
Figure 6-1. To add Class objects (i.e.
row elements) in the Table Editor:
1) | Select
the row before which you want to add the object. If none of the rows is selected
objects will be added to the end of the table. |

Figure 6-14. Table Editor pop-up menu.
2) | Open
the pop-up menu in the main table area with the right mouse button.
Figure 6-14 shows the Table Editor with
the pop-up menu
open. |
3) | Select
Add... from the menu. |
As a result, a
dialog opens allowing you to enter information about the new design object. Move
the cursor to the class name field and enter the name of the class.
Figure 6-15 shows such a dialog for a
Class [UML]: the user has filled in the name Ball. With the
Tab key
(Ctrl-Tab in text fields) you can move between the fields and buttons of the
dialog.

Figure 6-15. Entering information about Ball.
When you
press
OK the
Ball Class is created and added to the table as shown
in
Figure 6-16.
Similarly, add the other object candidates found from
Figure 6-1 to the table (i.e.
Paddle and
Wall). You can also add other possible candidates like
Brick into the table.

Figure 6-16. First object candidate added.
If you already
have an idea of some attributes and operations for these Classes, you can add
them to the appropriate field when you are creating the Class. Later you can
open a Class’s property dialog again by double clicking it or
alternatively by selecting Properties... from its pop-up menu.
To illustrate this feature we add an attribute called
position to Ball. To do this double click the Ball in the
table:
As a result the property dialog of the Ball object
appears. To add an attribute to the list of attributes for Ball:
1) | Move
the mouse to the attributes
field. |
2) | Open
the pop-up menu with the right mouse button
(Figure 6-17). |

Figure 6-17. Property dialog for Ball.
3) | Select
Add
Element... |
4) | A
dialog for properties of the attribute appears
(Figure 6-18). Enter information about
the position attribute as in the figure. |

Figure 6-18. Entering information about the position attribute.
5) | After
pressing OK the position attribute is added to the property dialog
of the Ball. Choose OK in the dialog and the table shows
position in the attribute column. |
You
can add other attributes or operations of the Classes in the same way. Finally,
to view all information about the object choose
Format | Autowidth.
Figure 6-19 shows an example of the
Table Editor when all candidates have been added.

Figure 6-19. Candidate objects in Table Editor.
Printing the table
Now we have developed an initial list of objects that we
believe should be modelled for this system. If we want to document it or send it
for a possible user to review we can print it by selecting
Graph | Print...
(see also Section
4.2).
Exporting table
Alternatively you can export the table into a spreadsheet tool
by selecting Graph | Reports | ASCII Export and by pasting the generated
table into a spreadsheet.
You may also want to read the table with a web browser. To
export the table in HTML format, select Graph | Reports | HTML Export and
save the generated table into a HTML file
Exiting Table Editor
When you have added the objects you can close the Table Editor
with
Graph |
Exit.
6.3.3 Using the Diagram Editor
Now we have an initial list of classes we can start to build a
graphical class diagram. With a class diagram we can focus on other aspects of
the design, such as finding relationships and structures between
classes.
Opening Diagram Editor
Basically the architecture of MetaEdit+ allows you to view any
of the graphs as a diagram, as a matrix or as a table. Since we already have
defined one graph that includes the objects, an obvious approach would be to use
it as a basis. Therefore we shall open the existing graph as a diagram.
To open Diagram Editor:
1) | Choose
Editors | Diagram Editor in the Launcher. Alternatively, if you have the
graph already open in a Table Editor you may choose Graph | View | Open as
Diagram... in the Table
Editor. |
2) | In the
dialog (Figure 6-20), select the graph
‘Ball game structure - analysis’, which you created with the Table
Editor, and click OK. Alternatively, you may double click the graph
name. |

Figure 6-20. Selecting a graph for Diagram Editor.
The
Diagram Editor has now been opened and it contains the same graph and design
information that was originally made with the Table Editor, but represented as a
graphical diagram.
Moving objects
Because the objects are automatically placed in the beginning
you can move them to new places. To move the Ball object:
1) | Select
it with the left mouse button and hold the button down.
|
2) | Drag the
object to a new location. |
You can move
multiple objects similarly by selecting them all first with the left mouse
button, keeping the shift key pressed. You can continue moving and organising
the objects in the diagram until you are satisfied.
Adding objects
To demonstrate how new objects are created in Diagram Editor
we will add two additional objects called BallGame and Sides. The
former object is the game object and the latter forms the three sides of the
game field.
To add these objects into the diagram:
1) | Click
the left mouse button at the place that you want to add an object.
|
2) | Choose
‘Class [UML]’ from the object type list
(Figure 6-21). |

Figure 6-21. Selecting an object type to be added.
 | If
you have selected an object type from the Types menu or from the toolbar,
this dialog will not
open. |
3) | An
empty dialog opens allowing you to enter design information about the
BallGame (Figure 6-22). Enter the
information about the object and click OK.
|

Figure 6-22. Property dialog for BallGame.
As you will have
noticed, creating an object in the Diagram Editor is basically similar to the
same operation in the Table Editor. In fact, many functions are the same in all
three editors.
Next create a Sides object in the diagram. You may
continue and create other possible objects or enter information about their
attributes or operations.
You may also organise the diagram layout by moving the
related objects closer together. For example, Wall and Brick could
be moved closer together.
Scaling objects
You can scale an object symbol by selecting it and dragging
any of the selection points at its corners or the midpoints of its sides. You
can also use choose to use a simple symbol presentation for Classes (a rectangle
showing only the class name) by checking the ‘Simple symbol?’ field
from the Class’s property dialog. You can then scale the object symbol to
be smaller.
Adding relationships
According to the analysis method followed the second phase
after defining objects is to identify structures and relationships between the
objects.
First we identify some structures between the existing
objects. For example, the ball game consists of a ball, a paddle, a wall and
sides. Further, the wall itself is composed of bricks. In UML these structures
are specified by forming aggregation relationships: e.g. Wall is a whole and
Brick is a part.
To add an aggregation relationship between the Wall
and Brick objects:
1) | Optionally,
select Types | Aggregation, or press the Aggregation relationship button
in the toolbar. If you omit this step the tool will prompt you in step 5 with
all possible relationship types between these two
objects. |
2) | Click
the Wall object with the left mouse
button. |
3) | Open
the object’s pop-up menu with the right mouse
button. |
4) | Choose
Connect.... |
5) | Click
the other object (Brick) to be in the relationship.
|
This creates a straight line relationship: if
you wanted extra points on the line, you could have added them by clicking one
or more times on the empty drawing area before step 4. After the objects to be
connected have been selected a dialog like
Figure 6-23 appears asking you to choose
the right kind of roles: which one of the objects is the part and which is the
whole?
 | Note
that if you have chosen first role option from the Options Tool (Section
2.1.3) MetaEdit+ will automatically
choose the first object selected when creating the relationship (i.e. Wall) to
be in the ‘whole’
role. |
6) | Select
‘(Whole Wall) (Part Brick)’ and press
OK. |

Figure 6-23. Selecting roles.
Next the tool will open a
dialog containing a notebook for entering more detailed information about the
aggregation relationship and the roles of its objects. According to the current
method, an aggregation relationship can be specified by entering information for
example about how many bricks the wall has
(
Figure 6-24). The tab labels of the
notebook page tell you which role you are specifying: labels in italics mean
there are no properties to enter for that role.
7) | Choose
each role page and enter the right values for multiplicity values for each role.
Here, Wall consist of multiple bricks (role Part: Brick has
multiplicity value zero to many (*)), and Brick must always belong to exactly
one Wall (Whole: Wall has multiplicity value one (1, or can be
omitted)). |

Figure 6-24. Entering range/amount values.
Add the other
aggregation relationship, i.e. BallGame is the whole and Ball,
Paddle, Sides and Wall are parts of it. Note that it is not
necessary to add all multiplicity values for each aggregation relationship and
you can omit them (especially if the multiplicity is one (1)).
8) | Press
All OK button to accept the creation of the aggregation
relationship. |
You can move the relationships
in the same way as you moved the objects, so as to make the diagram look better.
Figure 6-25 illustrates an example of a
Diagram Editor after all the aggregation relationships have been
added.

Figure 6-25. Aggregation structures of the Ball Game.
In a
similar fashion you can also create other relationships between the objects.
Before creating other kinds of relationships check that the Types menu or
toolbar do not have the wrong relationship type selected.
Figure 6-26 shows
an example of the Class Diagram with some association relationships between
classes added. It shows that the ball is somehow related to the brick and to the
wall (the ball hits the brick and wall), as well as to the paddle (which hits
the ball).

Figure 6-26. Example of Class Diagram ‘Ball game structure - Analysis’
Printing the diagram
To print out your designs from the Diagram Editor choose
Graph | Print... (see Section
4.2
for printing instructions).
Exiting Diagram Editor
To close the Diagram Editor choose Graph |
Exit.
Creating a new diagram
Next we shall continue with our Ball Game example by
identifying generalisation structures, defining attributes and by defining
operations.
Before we go into this more serious design we can choose
whether we want to update the ‘Analysis’ Class Diagram
(
Figure 6-26) or to start with a new
class diagram focusing more on design issues, and leave the analysis phase
diagram for possible future use.
To demonstrate some of the reuse capabilities (use of
analysis model elements at the design phase) we shall create a new diagram. To
create a new diagram:
1) | Select
Editors | Diagram Editor in the Launcher. Select the last item in the
dialog ‘create new graph’
or
select Graph | New... in a Diagram
Editor. |
2) | Select
‘Class Diagram’ as the method from the
dialog. |
3) | Enter
properties for the new graph to be created, such as its name (e.g. Ball game
structure - Design) and some additional
information. |
4) | Press
the OK button. |
As a result, a Diagram
Editor window opens with an empty diagram.
Adding existing objects
Since we have already defined the basic elements of the Ball
Game it would be best to reuse these elements.
To reuse design information in a Diagram Editor:
1) | Keep
the shift key pressed and click the left mouse button in the drawing area, where
you want to add the object. |

Figure 6-27. Selecting reuse strategy.
As a result a dialog
(
Figure 6-27) opens allowing you to
select one of the objects in the graph (there are none) or one of two other
reuse strategies. In the following we shall use both reuse strategies for
demonstration purposes.
Reusing an object by choosing from another graph
The first of the selections in the dialog, ‘Get an
object from another graph’ opens a new dialog for selecting a target graph
from which the elements are reused
(
Figure 6-28).
2) | Select
‘Get an object from another graph’ and press
OK. |
3) | Select
‘Ball game structure - Analysis’ and press
OK. |

Figure 6-28. Selecting source graph for reuse.
As a result
a dialog like
Figure 6-29 appears
showing all the appropriate objects that can be added to the new
diagram.

Figure 6-29. Selecting object to be reused.
4) | Choose
for example ‘Ball’ from the list and press
OK. |
As a result of the selection the
Class
Ball is added into the diagram. Reuse of the
Ball means that
all modifications made to the
Ball class during design are automatically
updated to the
Ball class used in the analysis models. If you do not want
to maintain design information between two phases you can naturally create a
totally new
Ball class into the design model. Later on if you find that
the analysis phase classes have some information (e.g. attributes or operations)
that you want to reuse you can do this with Component Selection Tool through the
Add Existing menu function (cf. Section
2.3.1).
 | Please
note that only those objects can be reused whose type is legal in the target
diagram. For example in a Class Diagram you can only fetch classes, objects,
packages, or notes. Thus, if you select an incompatible graph such as a Data
Flow Diagram, there will be no objects available from there for reuse in the
Class Diagram. Depending on your dialog answer preferences (see Section
2.1.3) the tool will not add any objects
to the diagram, or it will open an empty dialog showing that no objects can be
reused from that graph. |
Reusing an object according to its type
The second reuse option, ‘Get an object of a type legal
in this graph’, offers a dialog for selecting first the object type to be
reused (similar to that in
Figure 6-27)
and then fetches all the objects of the selected type.
The good side of this is that there is no danger of
selecting an incompatible graph. The down side is that only those objects
currently loaded are shown. If you have not yet used some objects of that time,
or accessed them a long time ago, they may not be currently loaded, and so will
not appear in the dialog. In this case, you could load more objects (choose
Repository | Load More Repository in the Launcher, cf. Section
2.1.2), or apply the graph based reuse
option explained above.
To use object reuse based on the object type:
1) | Keep
the shift key pressed and click the left mouse button in the drawing area, where
you want to add the
object. |
2) | Select
‘Get an object of a type legal in this graph’ from the dialog that
opens
(Figure 6-27). |
3) | Select
‘Class [UML]’ from the list of object
types. |
After the object type selection a
dialog like
Figure 6-30 opens showing
all the Classes currently loaded.
 | If
you have made other graphs with Classes or you have loaded the Tutorial project
the dialog will include more objects. The dialog also includes those Classes
that are part of the diagram already opened in the Diagram Editor (i.e.
Ball). |
4) | Select
all the appropriate classes from the list that you want to reuse in your design.
To follow the modelling tasks in the rest of the tutorial select at least the
Paddle class. |

Figure 6-30. List of all Classes to be reused.
Adding n-ary relationships
Next we shall continue our design efforts by focusing on
inheritance structures among the objects. In the following object-oriented
method the inheritance relationship is called Generalization. The Superclass
part of the relationship refers to an ancestor class and the Specialization part
denotes a descendant (subclass).
From the Ball Game example at least two kinds of
inheritance strategies can be found: classification can be based on
moving/non-moving objects, or on composite/non-composite objects.
For making an inheritance structure based on object
movement we must create an abstract class called MovingObject in the
diagram. This moving object has properties (e.g. position and
direction) and behaviour that the other objects like Ball and
Paddle can inherit. Hence in a Generalization relationship
MovingObject is the Superclass and Ball and Paddle are
Specializations.
Before we can create the relationship, we must first
create the superclass, MovingObject. Classes that are created just for
inheritance purposes and do not have any instances are called abstract classes,
and in UML Class Diagram abstract classes are specified by checking the
Abstract? field in the property dialog. As a result the class symbol for
MovingObject includes an ‘{abstract}’ text label below the
class name.
Two basic alternatives are available for creating a
generalisation relationship: you can either create binary relationships between
two objects as we did with aggregation relationships, or you can create n-ary
relationships. We will create our Generalization structure as an n-ary
relationship between MovingObject, Ball and Paddle. The
relationship has three parts or roles: one Superclass role and two
Specialization roles.
To create the n-ary relationship between
MovingObject, Ball and Paddle:
1) | Select
the Generalization relationship type on the toolbar (Ge) or Types menu.
|
2) | Select all
three objects (with the superclass MovingObject last) by clicking the
first object with the left mouse button, and then by keeping the shift key
pressed click the others. You now have a group
selected. |
3) | Open
the group’s pop-up menu with the right mouse
button. |
4) | Choose
Connect. |
5) | Click
the left mouse button for the relationship
position. |
A dialog opens for choosing the
right relationship type and assignment of roles to objects.
Figure 6-31 shows an example for
selecting a relationship.
6) | Select
‘(Specialization Paddle) (Specialization Ball) (Superclass
MovingObject)’ from the list and press
OK. |

Figure 6-31. Selecting roles for inheritance structure.
 | If
the first role option is selected from the Options Tool (see Section
2.1.3) MetaEdit+ assumes that object
selected last is in the superclass role. As a result, you will not be asked for
the roles to be selected. Normally, selecting the objects in a relationship in
the natural order (e.g. Specializations first, then superclass, or From first,
then To) will make the first set of roles given for that relationship type the
one you want. Hence, the default for drawing ‘directed’
relationships is towards the
arrowhead. |
After the relationship
selection is made a new dialog containing a notebook appears for asking more
information about the Generalization relationship and its roles. This dialog is
appropriate for entering discriminator information and for entering some
language (e.g. C++) specific rules (e.g. is the inheritance virtual?).
7) | Add
information about the generalisation and change the default visibility if needed
and press All OK. If you press Cancel the relationship creation is
cancelled. |
The Generalization relationship is
created between the chosen objects as illustrated in
Figure 6-32.

Figure 6-32. Generalization Structure in Diagram Editor.
Before
proceeding with your design you can add other classes for generalisation. For
example, Brick could also be a subclass of the MovingObject.
To link another Class as a Specialization
in
an existing Generalization relationship:
1) | Choose
the Generalization relationship by clicking the cross point of the relationship
lines. |
2) | Open
its pop-up menu with the right mouse
button. |
3) | Select
Add a New Role... from the pop-up
menu. |
4) | Click
the Brick object with the left mouse
button. |
As a result, a new role line appears
to the Brick. The Brick is automatically in a Specialization role because
the UML method (and the metamodel of the UML implemented in MetaEdit+) does not
allow multiple superclasses in the same Generalization relationship structure:
each superclass must have its own Generalization relationship.
Adding properties to objects
Next we shall continue our design by defining attributes and
operations for the classes of the Ball Game. We can add attributes like position
and colour to the superclass MovingObject for Ball and
Paddle to inherit.
To add attributes:
1) | Select
MovingObject with the left mouse
button. |
2) | Press
Enter (keyboard shortcut)
or
Open the object pop-up menu with the right mouse button and choose
Properties.... . |
Because we have
already defined an attribute position it would be appropriate to reuse
that definition rather than creating a new one. Therefore in the following we
apply the Component Selection Tool for attributes.
3) | Open
the pop-up menu for attributes as shown in
Figure 6-33 and select Add
Existing.... |

Figure 6-33. Adding attributes to the class.
As a result a
Component Selection Tool opens showing a list of available attribute definitions
in the list on the left.
4) | Double
click position in the list and press OK. Alternatively you may
select position in the list, then choose Add & OK from its
pop-up menu. |
The position attribute definition
is now added to the attributes for the
MovingObject class
(
Figure 6-34). Since it is still
included in the
Ball subclass, we will later edit
Ball and remove
it from the list of attributes there.
 | You
may resize the dialogs by dragging the small triangular ridged area at the
bottom right. Figure 6-34 illustrates
the resized dialog for MovingObj. |

Figure 6-34. A property dialog of MovingObject with an attribute added.
If
you want to create totally new attributes choose Add Element... from the
attribute field pop-up menu. Attributes like colour and velocity
could for instance be defined. You can also edit the attribute definitions by
double clicking it or by selecting Edit Element... from the pop-up menu.
 | If
you edit the properties of an attribute that has been reused, e.g. position,
note that the changes to the specification affect all designs where the
attribute definition is used. Thus, when changing information about the
attribute position, the changes are propagated to all places it is used.
|
Similarly to attributes, we could also
identify some operations to be added: adding works in the same way. Therefore,
to add operation move to MovingObject:
1) | Select
MovingObject with the left mouse button if the property dialog of the
object is not already open, otherwise go to step
4. |
2) | Press
Enter
or
Open the object pop-up menu with the right mouse button and choose
Properties....
. |
3) | Open the
pop-up menu from the operations field and select Add
Element... |
An empty property dialog for a
new operation opens, allowing you to enter information about the operation.
Figure 6-35 shows an example of the
specification of a
move method.

Figure 6-35. A property dialog for move.
The
specifications of the method show the following information: the name of the
method is ‘move’, it has two parameters (position and
direction) and the documentation field explains that ‘Move method
changes the location of the MovingObject according to the given position and
direction. It also updates the screen according to the movement
operation’.
Moreover, the visibility level of the method is
‘public’ (default visibility in UML), it is an instance method, and
according to the protocols of the Smalltalk language it has been defined to
belong to a protocol ‘actions’ via the stereotype concept of UML.
The stereotype list includes some predefined ones, but you can also add new
stereotypes by entering the new stereotype name in the field.
You can continue the design task by adding attributes and
operations for other classes as well. When making superclasses and giving them
attributes and operations, remember to remove the attribute and operation
definitions from any subclasses that previously included them. For example,
remove the attribute
position from the
Ball class: this attribute
is now inherited from the superclass
MovingObject. The
Remove
Element function can be seen in
Figure 6-33.
Levelling diagrams
A Class Diagram describes only the static aspects of the
classes. Therefore, if the behaviour of each class needs to be specified the UML
method includes a graph type called State
Diagram
[3].
In the following we shall define the behaviour of the
Ball by using a State Diagram. We describe the states of the ball and
possible transitions between the states.
To make a State Diagram for the
Ball:
1) | Select
Ball in a Diagram Editor with the left mouse
button. |
2) | Choose
Explosions... from the object pop-up menu or alternatively use the
keyboard shortcut Ctrl-E. |
Next a dialog
opens showing all possible explosions and asking whether an explosion graph
should be added to the Ball. As no explosion graphs are made, the only
item in the dialog is to add a new explosion graph. Later you may select other
explosion graphs or remove links to the explosion graphs with this
dialog.
3) | Select
‘Add an explosion’ and press OK.
|
As a result a dialog opens allowing you to
select a graph type. As the
Figure 6-36
shows, there are several candidate graph types that an object like
Ball
can explode to: e.g. State Diagram or Collaboration Diagram.
4) | Select
‘State Diagram [UML]’ and press
OK. |

Figure 6-36. Selecting a graph type for explosion.
As there
are no existing State Diagrams to explode to, you should create a new graph
(depending on the dialog settings a selection for creating a new graph may also
appear, see Section
2.1.3) and fill in
the properties. Enter information like a model name: ‘States of the
Ball’ etc., press
OK and a new Diagram Editor opens.
Later on, after this State Diagram Editor is closed you
can open it again by selecting the Ball object in the Class Diagram and
choosing Explosions... from its popup menu. All explosion and
decomposition links from the Class Diagram can be seen with Graph |
Info....
Adding objects to the new diagram
Now we can start to identify the states of the Ball as
well as some transitions between the states. Examples of states are:
initialized (i.e. a ball is put on the field at the beginning),
moving and behind the paddle (i.e. player has missed the ball). We
can also identify separate start and end states.
In the following we shall add a state moving. To
add a state:
1) | Optionally,
select ‘State’ from the Types menu or the toolbar. If you
omit this step, after step 2 you will be prompted with a dialog for the type of
the new
object. |
2) | Click
the left mouse button where you want to add the state.
|
3) | An empty
dialog opens allowing you to enter design information about the state
(Figure 6-37). Enter a description and
click OK. |

Figure 6-37. Property dialog for state moving.
Create
the other possible states into the diagram as described above. An example
diagram with possible states can be seen from
Figure 6-38.

Figure 6-38. States of the ball.
Adding relationships to the diagram
Next we shall identify transitions between the states. An
example of a transition is between the states moving and behind the
paddle. To create this transition:
1) | Click
the moving state with the left mouse
button. |
2) | Open
the pop-up menu with the right mouse
button. |
3) | Choose
Connect. |
4) | Click
the state to which the transition will go (Behind the
paddle). |
 | If
the first role option is selected from the Options Tool (see Section
2.1.3) MetaEdit+ assumes that object
selected first is in the sending role and the role selection dialog will not
appear. Note also that MetaEdit+ has selected the right relationship and role
constraints based on your modelling situation: other relationship types are not
possible in State
Diagrams. |
5) | Enter
the transition properties and press the All OK
button. |
Figure 6-39
below shows an example of the states and transitions identified. Note that other
states and transitions could also be possible. For example, we could use just
one state for a ball that hits the paddle, brick and sides (called e.g. hitting)
since they all cause the same kind of action, i.e. calculating a new
direction.

Figure 6-39. Object State Diagram of the Ball.
The
identification of several states allows us also to identify connections between
several objects. For example, the difference between state Hits a brick
and Hits the paddle is that the former invokes an operation at class
Brick to remove itself. This kind of a relationship could also be added
to the Class Diagram as an association. Alternatively a Collaboration Diagram
can be specified for describing the communication between objects of different
classes.
While adding information between the diagrams, notice also
that you can share the whole operation definitions defined in class diagrams or
in state diagrams. For example, operations of classes can be used as operations
called in states.
The Ball Game example has shown some of the most commonly
used features of the Diagram Editor. However, the Ball Game example itself is
not ready yet: Generalization relationships could be specified in more detail,
the Class Diagram of the
Ball could be improved, and new Class Diagrams
could be created for other classes of the game. Moreover, you can also apply
explosion structures for specifying collaboration between classes. To do that
choose ‘Collaboration Diagram’ from the explosion dialog (see
Figure 6-36).
To demonstrate other parts of the MetaEdit+ environment we
shall stop our design efforts with the Diagram Editor and continue the tutorial
with other tools.
If you want to study example graphs of the Ball Game open
the ‘Tutorial’ project included in the demo repository.
To open the ‘Tutorial’ project:
1) | Choose
Repository | Open Project... from the
Launcher. |
2) | Select
‘Tutorial’ from the list of
projects. |
Note that this will cause the
objects and graphs in the Tutorial project to be available in dialogs etc. As
many of these will be duplicates of the ones you have created, continuing in the
tutorial may be confusing. To clear these objects and continue with the
tutorial, close the Tutorial project from a Graph Browser, and commit your
transaction with
Repository | Commit in the
Launcher.
6.3.4 Using the Matrix Editor
The Matrix Editor is a tool for managing design information in
a matrix form. It is an especially useful tool in situations where the size of
the graph grows or your interest focuses especially on the connections between
objects.
Opening a Matrix Editor
The same design information that has been previously created
with Diagram Editor can also be edited in the Matrix Editor. To start the Matrix
Editor you can either:
1) | Select
Editors | Matrix Editor in the Launcher or select Graph | View | Open
as Matrix... from the Diagram
Editor. |
2) | If you
selected the former, a dialog opens to select a graph. Choose ‘States of
the Ball’. |
A Matrix Editor opens and
shows you the states of the Ball as a matrix.
Figure 6-40 shows an example of the
Matrix Editor.
 | Note
that the item shown in the cell can be selected. In case of State Diagrams the
item in the cell should be relationships as it has specifications. For
displaying different cell contents select View | Relationship, or
Column Role, or Row Role. |

Figure 6-40. Matrix Editor with State Diagram ‘States of the Ball’.
Showing symbols
Currently the matrix is showing only text on the axes and in
the cells. You can show the same symbols as in the Diagram Editor for the
objects on the axes or the relationships or roles in the cells.
To show symbols for the states on the axes:
1) | Select
Axis | Show Text +
Symbol. |
Figure 6-41
illustrates the Matrix Editor when symbols and text are shown for the objects on
the axes. You can adjust the widths of the columns automatically with
Format
| Autowidth, or manually with
Format | Column Widths...

Figure 6-41. Matrix Editor with symbols.
Next, open a Class
Diagram in a Matrix Editor by choosing the Ball Game analysis or design graphs,
similarly to above.
 | Note
that Matrix Editor can not show n-ary relationships and thus the matrix may seem
to lack some relationships. |
To view
symbols and text for both axes and cells:
1) | Select
Axis | Show Text +
Symbol. |
2) | Select
Cell | Show Text + Symbol. |
The first
selection shows symbols for all classes on the axes and the second selection
shows symbols for the relationships, where they exist. If you want to see only
where exists relationships choose
Cell | Text Display... and select
‘Just an X’, then turn off symbol display with
Cell | Show
Text (see
Figure 6-42 below for the
result).
Managing objects and relationships
Basically all the operations needed for adding, updating, and
removing objects on the axes as well as relationships and roles in cells are
similar to those in the Diagram Editor.
To test these you can create an additional object into the
matrix or a new relationship and follow the instructions given earlier for the
Diagram Editor in Section
6.3.3.

Figure 6-42. Matrix Editor with Class Diagram ‘Ball Game’.
If
you add new objects or relationships in a matrix remember to add them to the
diagram representation with the Add Existing... or Graph | Import
Graph function: otherwise they will not be visible there. You can also
change the properties of the objects or relationships. These are automatically
updated to the diagram, and if you have both tools open you can test this with
View | Refresh.
Printing the matrix
The current state of the matrix can be printed with Graph |
Print....
Exiting a Matrix Editor
To close a Matrix Editor select
Graph |
Exit.
6.3.5 Running reports
During the design it is often useful to run reports on your
design information. For this task MetaEdit+ includes several pre-defined
reports: you can also add your own.
To use reporting:
1) | Select
Graph | Reports | Run... in the Diagram Editor or Matrix Editor
previously opened. |
As a result a dialog like
Figure 6-43 opens asking you to select a
report to be run. Reports are available for this graph type and all its
supertypes, including generic reports in the Graph metatype itself. Most code
generation and documentation reports will write directly to files in the
MetaEdit+ directory. Simpler generic reports will open a Report Output tool with
the report result.

Figure 6-43. Selecting reports to be run.
2) | Select
for example ‘Object list’ and press
OK. |
The selected report is executed and
the output is shown in Report Output tool, as in
Figure 6-44. The Report Output tool has
functions for editing the output as well as saving it to a file.

Figure 6-44. Report Output.
6.3.6 Using the Report Browser
In addition to running pre-defined reports you can also modify
them or even create your own reports. This can be done with the Report Browser.
To demonstrate the Report Browser we shall make a new report definition to find
out which classes are inherited and what are their superclasses.
Opening Report Browser
Open a Report Browser from a Diagram Editor or Matrix Editor
that has the Class Diagram ‘Ball game structure - Design’
opened:
1) | Select
Graph | Reports | Create. |
A Report
Browser opens showing all the report definitions available in the Class Diagram
type (
Figure 6-45). The report
definition of the currently selected report, ‘States of a class’ is
shown in the bottom pane of the window.
 | Notice
that the Report Browser is opened for making reports to a particular graph type,
e.g. Class Diagram here. To manage report definitions for other methods use
Report | Change Graph Type... in the Report
Browser. |

Figure 6-45. Report Browser.
Making a new report
Reports are always defined for certain methods. The following
report definition is therefore appropriate only for Class Diagrams but can be
easily modified to work with other object-oriented methods.
The rough process for report definition is the
following:
1) | Select
the objects to be
reported. |
2) | Select
the properties to be
reported. |
3) | Select
the related objects to be
reported. |
4) | Define
the descriptive texts for the report. |
Thus,
the first step is to analyse what is needed in a report and in which order. To
make a new report select
Report | New... and the tool will ask the name
of the new report (
Figure 6-46).
Enter the name ‘Generalization structures’ and press
OK.

Figure 6-46. Entering a name for the new report.
The
contents of the editing area are now:
Report 'Generalization structures'
endreport
The meaning of the text is described in more
detail in Section
4.1.5. The next step
is to select the operation and object type that we are searching for. To proceed
with the report definition:
1) | Select
‘Templates’ from the middle list (with the left mouse button).
|
2) | Select
ForEach from the right
list. |
3) | Select
Insert from the pop-up menu for ForEach. Alternatively, you may double
click the operation from the choice box (the right list
box). |
The report definition now looks like
this:
Report 'Generalization structures'
foreach objectType
{
}
endreport
After selecting an operation we proceed by
selecting an object type. Because we are interested in all objects we use a pair
of parentheses:
1) | Delete
the text objectType and write
“.()” instead. |
Next we shall
define the information about object types that we are interested in. We also add
additional literal text into the report definition. Notice that every statement
of the body ends with a semicolon ‘;’, and statements are preceded
with spaces, tabs or line breaks.
Add the body of the foreach loop as follows:
Report 'Generalization structures'
foreach .()
{ id;
' Is a subclass of : ';
}
endreport
Next we follow the inheritance relationships
found from the diagram by asking each element for its superclass. The selection
of the relationship can be selected through relationship and role types from the
upper windows as described in Section
4.1.4 or by typing them directly in the
report. Once you have some experience of reporting you can also copy and paste
parts of report definitions from other available reports, or even download new
report definitions from
http://www.metacase.com.
Edit the report definition so that it looks like
Figure 6-47.

Figure 6-47. Report definition of ‘Generalization structures’.
Running reports
Now, if we think that this report might work, we can test it
by running it with
Report | Run..., and by choosing the graph ‘Ball
game structure - Design’ from the selection list. This operation runs the
report specification against the chosen graph. The report output is shown in a
Report Output tool as
Figure 6-48
illustrates. If you are not satisfied with the contents and layout of the report
you can close the output, adjust the report definition and try running it again.

Figure 6-48. An example of a report output.
Saving report definitions
Finally, when you are satisfied with the report definition
save it by choosing Report | Save.
Exiting a Report Browser
To close the Report Browser choose
Graph | Exit. If you
have not saved report definitions after modifications the tool asks whether they
should be saved before exiting.
6.3.7 Generating code
The ability to generate code from models is a major factor in
increasing the integration of CASE tools with the implementation phase of
software development. MetaEdit+ includes predefined code generation definitions,
implemented with the Report Browser. These code generation report definitions
can thus be modified by the user in exactly the same way as other reports, and
you can even make your own generation definitions.
We can generate Smalltalk code from our Ball Game
designs:
1) | If
a Graph Browser is not already open, choose Browsers | Graph Browser in
the
Launcher. |
2) | Select
the ‘Ball game structure – Design’ graph in the Graph
Browser. |
3) | Choose
Reports | Run... from the graph’s popup
menu. |
4) | Select
the ‘Smalltalk code’ report in the dialog that opens, and press
OK. |
Alternatively, you could select
Graph | Reports | Run... from an editor open on the ‘Ball game
structure - Design’ Class Diagram.
As a result, Smalltalk class description files are created
for each individual class in the working directory of MetaEdit+. As the report
is generated into files instead of a Report Output Tool, MetaEdit+ opens a
dialog showing all generated files (cf.
Figure 6-49 below).

Figure 6-49. Information about generated files.
The
generated files can be accessed with any ASCII editor.
Figure 6-50 shows part of the generated
Smalltalk code from the class
MovingObject.

Figure 6-50. Part of the generated Smalltalk code.
You
could improve the code generation reports to also execute your compiler on the
resulting code files. See Section
4.1
for more details, in particular, the External command, and look at the UML Class
Diagram report for autobuilding Java
applications
6.3.8 Documenting designs
Design information can be published outside MetaEdit+ to
review
designs and document a project. For these purposes
MetaEdit+ has pre-defined project and graph documentation reports which create
HTML
files for web browsers and a
.DOC document file
for Microsoft
Word.
Creating graph documentation
Graph documentation
reports are
available for all graphs. To create graph documentation:
1) | Select
any graph (e.g. ‘Ball game structure – Design’) in a Graph
Browser. |
2) | Open
the pop-up menu with the right mouse button and select Reports |
Run.... |
3) | Choose
‘Export graph in HTML’ or ‘Export graph in Word’, and
press OK. |
| The
resulting documentation is shown in a browser or in Microsoft
Word. |
Creating project
documentation
In addition to creating documentation about individual graphs
project documentation can be created for the whole project. Generating for each
graph would be time consuming, and not reflect the structure of the project
well. To improve this, the graphs used in a project can be specified in a
Project Model graph. Project Model
is a specific
modelling technique for illustrating a project and the graphs it contains,
relationships between graphs, and possible subprojects, which can be decomposed
into other project models. The Project Model can also form a useful starting
point (like a homepage) for investigating a project: graphs can be opened from
there via decomposition links.
Note that the Project Model is not created automatically
according to the graphs made in a project. By manually selecting existing graphs
(attach existing graph in graph related property) you can choose those models
you want to use as a basis for project documentation. You can also have several
Project Models to generate different sets of documentation, e.g. one for
analysis phase and another for design phase.
We shall thus first create a basic project
model:
1) | From
the Launcher choose Editors | Diagram
Editor... |
2) | Choose
Create New Graph and press
OK. |
3) | Choose
Project Model and press
OK. |
4) | Fill
in a name for the project model, e.g. ‘Ball Game project’ and press
OK. You could also fill in the other properties, e.g. the project manager
and other authors of graphs in the
project. |
5) | Create
a new object of type Graph by clicking in the Diagram Editor. From its Graph
property popup menu choose Attach existing graph..., and select
‘Ball game structure – Analysis’. Press OK in the
Component Selection Tool, and again OK in the property
dialog. |
6) | Repeat
step 5 twice more, for other graphs to be documented, e.g. ‘Ball game
structure – Design’ and ‘States of the
ball’. |
We could later add relationships
between graphs, and decomposition links from these objects to their respective
graphs. The graph can also be opened from the object’s property field with
Open Graph...: remember you need to close the property dialog before you
can work in the graph.
The resulting Diagram Editor will look like that in
Figure 6-51. The model shows that
Tutorial project includes three models: two Class Diagrams and one State
Diagram.

Figure 6-51. Project Model of the Ball Game.
As with graph
documentation reports,
project
documentation
reports can make either HTML or Word
document files. To generate project documentation:
1) | Select
Graph | Reports |
Run.... |
2) | Choose
‘Export to HTML’ and press
OK. |
This report creates documentation
files and opens them in a web browser
(
Figure 6-52), if your system supports
this. The root file or home page for the project is the name of the project
model.

Figure 6-52. Project Model of the Ball Game.
[2] This is
especially true in all early phases of requirements engineering or analysis and
design.
[3] For more
detailed information about the State Diagram and the method see e.g. Unified
Modeling Language: User Guide, Booch, G., Rumbaugh, J., Jacobson, I., Addison
Wesley Longman Inc., 1999.