Because methods in IS development can use at least three different representation forms (graphical, matrix, and textual), we need graphical, matrix and text based tools in our environment. To allow flexibility these tools should all follow the underlying GOPRR behaviour so that we can change easily between them. For example, if we have a diagram in a graphical form we might want to look at the same information also in matrix or textual forms.
Another goal is to strive for richer methodology support. In addition to storing method data (see earlier section), we need activity and agent support.
Activity models describe the methodology dynamics. They capture information of the process: what kind of tasks have to be done in order to reach the deliverables (output products) such as IS models, reports and other descriptions. In addition to this, the activities can capture managerial information of the ISD (such as time information and measurement data). The main reason for activity modelling in MetaEdit+ is to increase understanding of and support for the software development process. An explicitly shown activity model acts as basis for discussions and group work and a "where we are map", improves consistency management for models (checkings, transformations), and links design documentation (models and design rationale) into tasks.
Activity models are composed of activity and deliverable types. Activity types are tailorable and modelled as GOPRR objects. These can include complex types such as phase, and simple types such as step, checking, and transformation. An activity type uses or produces deliverable types. A deliverable can be any kind of document or IS model (a GOPRR graph). So, if a deliverable type contains a graph type as its property, one can open this type of graph from the activity model tool. By attaching user roles (designer, programmer) to deliverable types, the access rights to create and modify deliverables are defined. Functionality for design tools can be performed by attaching e.g. transformation or checking rules as properties to corresponding tasks. Activity models are discussed in more detail in (Marttiin, 1994).
Agent models define the environment for the development group to work. The agent model handles information of an organisation's projects (groups) and users. It is integrated to the activity model through the concept of user role (see Marttiin, 1994).
The first task has been to build a drawing tool which will support graphical techniques. Conceptually techniques are defined by using GOPRR types (see Section 3.3.2.). For each conceptual type we want to represent in a drawing tool its graphical counterpart. The drawing tool needs to support any kind of symbols. These symbols can be attached to an object, a binary relationship (like in NIAM), a n-ary relationship (like most object-oriented whole-part structures) and a role (like arrows showing the flow directions). Also, a capability to collect simple symbols to complex ones should be possible because these are needed in fancy graphical modelling tools. The generic functionality of such a drawing tool includes e.g. zooming, gridding, selections, views, cut-copy-paste functions, and printing/exporting.
Secondly, we are building a matrix editor (Kelly, 1994). It will support those methods which use matrices, and also allows the user to adopt a different perspective on his graphical model. The matrix editor will also be usable as an input tool, with spatial information being added later, when dragging and dropping objects from a matrix (or object list) into the drawing editor. The user interface will be visually similar to that of a spreadsheet, with the axes containing objects, and the cells containing information about the relationships between those objects. The user will be able to create a hierarchy of groups of axis items, to divide up the functionality, data etc. of the modelled system. Diagonal, triangular, and multi-dimensional matrices all will be supported.
Thirdly, we have built a desktop environment to handle multiple WorkSpaces and tools. In addition to the editors above we need a graphical editor for activity and agent models, a graphical query editor using a query language (see below), and a direct repository access tool.
Fourth, we are building a comprehensive set of tools for tailoring MetaEdit for different purposes and methods, i.e. a CAME toolset. The CAME toolset utilises the above mentioned tools for method engineering and thus allows the users to develop and modify methods by means of drawings, matrixes and in addition to those, create new GOPRR objects by a form interface. This toolset will allow for incremental method engineering and instant propagation of changes into models, that are based on modified methods.
Fifth, a tool for creating symbols used in drawing tool is needed.
Both the activity model and the agent model need ways to define the structure of the development process and usage environment. These are currently being examined. The behaviour of basic activity and agent types and their links to GOPRR primitives have been defined. Later on, tools for designing activity and agent models will be built.
a single-user WorkSpace
a graphical editor based on OPRR, with features for printing, viewing, and zooming,
We have developed extended requirement specifications for
general UI facilities including multi-user WorkSpace concepts,
generalised and enhanced graphical drawing tool,
symbol editor,
a matrix editor, and
activity and agent models.
The user interface of the graphical drawing tool and matrix editor have been designed to the level described in objectives. Some parts of the drawing tool functionality (e.g. views) will be postponed. Both the drawing tool and the matrix editor are designed to use the hypertext links (see Section 3.3.6.). A SymbolEditor for creation of symbols used in the drawing and matrix tools has been developed. Symbols are composed of vector graphical shapes, label places and places for input/output connections. The symbols are collected into a symbol library, and thus can be reused for different types.
The impact of the matrix format on the data structures used in the repository has been assessed, and changes suggested for the management of this data, particularly in the area of relationships and roles, which play a larger part in the functionality of the matrix editor than in the graphical editor. The concept of a matrix format of a metamodel has been developed, further extending the possibilities of the editor, and several methods have been modelled in this way. It has been seen that the matrix format provides a much clearer view of the possible object-role-relationship-role-object type bindings than the graphical editor, and that it is also particularly useful when combining various graph types together in a methodology (Kinnunen and Leppänen, 1994).
The matrix editor is largely implemented, including support for multi-dimensional matrices, n-ary relationships, user-selectable functions for generating the contents of cells based on the axis elements, cell contents visible as text, symbols, or a mixture of both, sorting based on axis contents, diagonalising the matrix based on cell contents, adding and deleting relationships, roles and objects, editing properties of these, moving rows or columns, and altering various visual properties of the display (column widths, zooming etc.).
An undergraduate project has investigated various algorithms for adding the necessary position information to convert from a matrix format to a graphical format.
Requirements for flexible process modelling and a design example using SA methodology are described in (Marttiin, 1994). Different ways of modelling information of design decisions are examined in (Smolders, 1993).
After the development of the basic tool set (drawing tool, matrix editor, symbol editor, work space, and metamodeling dialogues) the next step is to implement the process supporting environment. This requires dialogues for creating activity and deliverable types as well as a graphical editor to manage and develop activity models.
The matrix editor will be extended by the addition of multiple-level, hierarchical axes, and the ability to change the view to that of a triangular or diagonal-axis matrix.