Up Previous Next Title Page Index Contents

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.

4)Press OK.

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.

Up Previous Next Title Page Index Contents