Up Previous Next Title Page Index Contents

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.

Up Previous Next Title Page Index Contents