2.1 Method to be modelled
When creating new method specifications
(metamodels) for MetaEdit+, you should first focus on the conceptual structure
of the method to be modelled — i.e. on identifying the objects and their
relationships in the method. When these central components have been identified
and named, they can be defined in MetaEdit+ by using the method development
tools.
In the following we clarify how methods can be specified
using MetaEdit+ and the underlying GOPRR metamodel
. We
shall begin with a conceptual specification by showing how to analyse and
represent the conceptual structure underlying a method. Then we continue by
specifying the generic representation of a
method.
2.1.1 Conceptual specification of a method
The conceptual specification
starts
with resolving what kinds of objects the method uses, and what are the possible
roles and relationships of these objects.
The starting point for this tutorial is the limitations of
State Diagrams. In the State Diagram, the behaviour of a system element is
described in terms of the different states that element can be in. Each state
describes a possible combination of data values held by the state, and the
transitions between different states specify the operation invoked in that
transition. In some versions, start and end states are identified as separate
method components. An example of a UML State Diagram is illustrated in
Figure 2-1.
Most states in the example diagram are for one object,
‘Ball’, taken from the tutorial project of the ‘demo’
repository. As can be seen, the ‘Ball’ can be in 6 different states:
initialised, moving, hitting the paddle, hitting the wall, hitting the brick,
and behind the paddle.
The remaining two states in the diagram (at the bottom)
belong to two other objects, and are thus particularly interesting to us as we
extend the method to show which objects these states belong to. When the
‘Ball’ hits a brick the state of that ‘Brick’ object
changes. Hence, the state labelled ‘Brick removed’ is a state of the
‘Brick’ not state of the ‘Ball’. Similarly, the state
‘Point added’ probably belongs to yet another object, not
‘Ball’ or ‘Brick
’. It could be a
state of the whole BallGame. This type of information, however, can not be seen
from most State Diagrams in object-oriented methods. To support conceptual
references and a diagrammatic representation for showing the states of multiple
objects within one state diagram, we must modify the underlying metamodel of the
State Diagram.

Figure 2-1. An example of State Diagram.
Before making any
method modifications we must first understand the underlying structure of the
existing method. For this purpose the
Figure 2-1 also includes information
about the GOPRR meta-types. These are printed in
ITALICS and refer with a
double-lined arrow to method elements.
From the example diagram we can identify three object
types. The most common, a rounded rectangle with two horizontal lines,
represents a State object type. The other two object types are the Start and
Stop states. The Start state is illustrated with a large black dot and the Stop
state with a circle around a dot.
The relationship types between objects can be identified
by looking at the documentation of the method and the examples (like
Figure 2-1). The example diagram uses
only one relationship type: Transition. This relationship type is attached to
object types with two role types. The Send role type specifies the object from
which the transition starts, and the Receives role type specifies the object to
which the transition goes. Both of these role types use a solid black line, but
Receive also has an arrowhead, helping to show the direction of the
transition.
Now that we have identified the components of the method,
we are ready to start defining the method with MetaEdit+ Method
Workbench.
In the following sections we model the object types,
relationship types and their roles and the improved State Diagram graph type. We
also define the graphical appearance of the method. The tutorial example is not
intended to be an in-depth analysis of features, but rather to give a guided
tour to the method engineering tools of MetaEdit+. For more information about
individual tools, please consult the particular tool section of this
manual.