However, OPRR has limitations:
its structure is flat: it can not support recursive structures;
it does not support generalisation and specialisation hierarchies;
interconnected methods are not supported.
To overcome these limitations, we have extended the OPRR model. The resulting data model is called GOPRR, which comes from the words Graph-Object-Property-Role-Relationship.
recursive structures (i.e. decomposition, complex objects),
generalisation and specialisation of modelling concepts,
polymorphic modelling concepts,
multiple representations of the same underlying conceptual description (e.g. graphical, matrix, text),
interconnections of different descriptions,
rules for checking the model integrity.
The current implemented GOPRR model is fully object-oriented -- including both abstract and concrete inheritance of structure and behaviour, polymorphism, overloading, and class/object paradigm. It is also designed for reuse: both types and instances of object, relationship, role, property and graph can be reused within different graph or project types (or instances). During the design the original concepts of the GOPRR model have also been extended to include a larger unit, Project, which can contain Graphs, and subprojects, in addition to the storage capabilities of Graph. Project thus manages the allowed linkages between methods.
The Graph concept of GOPRR is a generalised decomposition graph. It can be included in a parent graph, attached to an object, role or relationship therein. The interface to the object, and hence to the elements in its decomposition graph, can be brought into the child graph to any degree between `not at all' and `include copies of external objects'. The interface is maintained distinct from the elements of the decomposition graph itself, allowing reuse of the decomposition graph in different parent graphs. The interface `specification' remains the same in all decompositions, but the elements attached to the interface at the higher level can be different in different parent graphs, thus allowing reuse of the graph as a white or black box. This use is common in computer-aided design of circuits and chips.
The design of Graph is such that many representational graphs can be made for one "conceptual" graph. For instance, a matrix and diagram representation can be made of the same conceptual Data Flow Diagram. Changes are propagated between the representational graphs according to their usefulness to the user: the implementation of this is open to change in the light of real user experience. At the moment, objects added in one graph are available to the other conceptual graph, but not automatically added. Changes to properties are made instantly (on transaction commit, if different users are working on different graphs -- similarly in the remainder of the paragraph), and additions to or changes of relationships or roles are made instantly (at present the changes are only shown instantly in the Matrix Editor).
In the implementation it is possible to attach rules to properties, in addition to the type restriction. For example, in modelling Data Flow Diagrams, a rule has been added to the property `DFD Number' which constrains the contents of the string property to be a dot separated sequence of numbers, disallowing combinations like `Fred', `2.', `3..2.1', `.', but permitting legal numbers such as `3', `2.1', `2.4.23.1'. It is also possible to add constraints on the collection of properties for a given object, role, relationship, graph or project type. For example, a rule could be added to specify that a `start date' must come before an `end date' in an activity modelling diagram. These rules, too, are inherited by descendant types, but may be overridden there.
Implementation
The GOPRR model and the majority of its operations have been implemented for the MetaEdit+ environment. The implementation of the remaining operations depends strongly on the desired user-visible behaviour within the tools, thus only low-level functions are available at present for such operations as sharing properties between objects. It has been discovered that, contrary to our expectations, there is no general way of specifying the behaviour of e.g. delete operations in a way independent of the tool / representational paradigm. This theoretically important result gives rise to some practical difficulties: each tool must now implement its own delete protocol, and the GOPRR implementation in MetaEngine can supply only low level operations, and a few higher-level protocols which work only on the conceptual level, with only minimal information sent to representations of the affected concepts.
The GOPRR model itself does not contain details of the links to different representations that is part of its power and flexibility. In the implementation, however, some concessions are made in the user interface for the sake of speed and ease of metamodeling: every object, relationship and role type can have associated with it a `default representation', which is accessed and designed from the same tools as are used to do all the conceptual modelling. This representation can be varied for different representational graph types, within the GOPRR model, thus allowing polymorphism.
The metamodeling tools implemented in MetaEdit+ have been tested so far by metamodeling SSADM Data Flow Diagrams, and modelling some example graphs. We have achieved some encouraging results: the time required to derive the metamodel has been reduced by an order of magnitude from MetaEdit itself faster than other metaCASE environments. Further, the removal of the draw-report-compile-update cycle previously required when making changes to an existing metamodel has made incremental method engineering a real possibility. Even changes to the rules of types are made instantaneously.
A new algorithm has been developed to establish the connectedness of groups of objects in graphs, recognising n-ary relationships, and multiple attachment of objects to a single role. The same algorithm is used to establish the possibility of connection of groups of objects, possibly restricted by a given relationship type, within a graph type. Thus, the same algorithm is useful on the instance level, on the type level, and on a mixture of types and instances.
The implementation of GOPRR has been described using the COM notation. (See section 3.4.2.)
Publications
One scientific paper on the interconnections of methods with GOPRR has been published and discussed at a conference (Kelly and Tahvanainen, 1994). We are currently working on a more general scientific document on the theory behind the implementation of relationships in metaCASE.
1. During the remainder of 1994, GOPRR will be tested using MetaEdit+ on an increasingly complex set of methods.
2. The expected behaviour of e.g. delete operations in different representational paradigms will be re-examined to establish a behaviour or set of behaviours for GOPRR that will maintain the desired ability to add new tools to MetaEdit+ with minimal effort.