Technology for rapid graphical diagram editor development
Results of IMCS in ESPRIT project No 23287 ADDE
The world around us can be described in two ways – either verbally or by employing diagrams. It has been widely recognised that visual representations can be of high value when analysing or synthesising complex systems. Diagram drawing requires sophisticated computerised tools. Tools can be purchased, but they are either too inflexible to be adapted for different diagram semantics and visual representations that they have been designed for, or offer only drawing functionality without the possibility to link diagrams to some underlying repository. Development of custom high quality graphical editors is a complex and time-consuming task. During the ADDE project we have demonstrated that it is possible to develop customised editors fast, and we have built the necessary technology and basic building blocks for this task.
The two main cornerstones of our technology are the following:
The editors generated by the Editor Factory rely on basic graphical diagram manipulation
facilities provided by the set of GEC.
The experience that was needed to develop these components and basic technologies come
from development of the system modeling tool
GRADE. In the ADDE project GRADE has been used as the main tool for metamodel
maintenance.
<Back to IMCS>
Main features of the set of graphical editor components
For the set of graphical editor components (GEC) there are two main application areas:
GEC provide the following functionality:
This functionality is documented and accessible through standard ActiveX interface.
The key element which distinguishes GEC from existing editor components sets on the market is the autolayout feature, with several selectable autolayout principles corresponding to typical diagram layouts. The autolayout mode can be freely combined with application-controlled or manual layout. The other distinguished feature is the simplicity of API, with low number of different methods.
The main purpose of EF is providing support for very fast development of graphical editors. Not only purely graphical manipulations are supported (this is the purpose of GEC), but also logical consequences of changes made in a diagram are implemented in this framework and can be very easily customised for specific diagram types. Editors produced by EF technology are not just “drawing machines” like VISIO (although can be used in such manner); they interface with underlying repository, storing and maintaining objects drawn in diagrams into appropriate persistent data structures and maintaining synchronisation between diagrammatic representations and repository contents. Thus graphical editor components of complicated software tools and data base applications can be easily built using EF.
The core of the Editor Factory framework is Logical Layer Kernel (LLK). LLK is the run-time engine on which any editor generated via EF relies. Customisation of LLK to suit needs of some particular diagram type is driven through Logical Layer Definition (LLD). When LLK is run against a particular LLD, from the end user point of view it performs any editing actions specified in this editor definition. One of the main tasks of LLK is to maintain the relevant objects in the repository and represent them in diagrams in the specified way. LLK interacts with the repository via a thin layer – Repository Interface (RI). Only this layer depends on the particular repository type (relational database, Softlab Enabler etc.). All graphical manipulations of object representations in diagrams are performed via calls to GEC, consequently the autolayout features of GEC are available in any editor generated via EF.
Editor building via EF consists of the following steps. It is necessary to start with metamodel of the repository (in the form of a UML class diagram). If the contents of the repository is to be filled and maintained through a set of graphical diagrams, a set of LLDs tied to this repository metamodel and corresponding to each diagram type must be obtained. To obtain a LLD for a diagram type, it is necessary to start with repository metamodel fragment (view) representing the relevant concepts in the form of a UML class diagram in GRADE tool and annotate that metamodel fragment with additional information necessary to describe graphical and dynamical properties of repository objects. The resulting annotated class diagram is compiled by Annotation Compiler, obtaining an LLD for the diagram type. Finally, LLDs for all diagram types are concatenated together. When LLK is run on the composite LLD, it plays for the end user the role of set of editors for all selected diagram types, acting in a coordinated way on the common repository.
In the case of defining editor set for ADDE metamodel these views were ADDE reports (workproducts). Each annotated view served as the basis for a separate diagram type. E.g., Business Activities and Dependencies between them in ADDE metamodel (Activity Decomposition report) can be represented by one diagram type, while Basic Tasks, inclusion of Business Activities into Basic Tasks and Dependencies between Tasks (Basic Task report) – by another diagram type. Thus, end-user can work with ADDE repository using a set of diagram types.
In this picture the top level architecture of the Editor Factory framework is shown. The upper row corresponds to the customization stage, when metamodel views are chosen, annotated and processed to generate LLD.
The lower row shows the editor in action, where LLK interacts with GEC (the graphical layer) and Repository Interface. One more important feature shown there is that non-standard logical actions in editors (wizards, generators etc.) can be developed separately and easily attached to LLK using "hooks" defined in the annotation.
Concepts of the annotation language
In this section, the overview of central concepts of the annotation language will be presented, giving some insight into the set of features that can be easily customised. In the next section, other (default) services provided by LLK will be presented.
EF is used to suit needs of a specific repository structure by defining a set of editors. Each editor can be used for creating diagrams of some type. Diagram type specification is created by taking some view of the repository structure definition (in the form of a UML class diagram) and annotating it and, possibly, supplementing with additional classes and associations (metamodel extensions). A rule that has to be strictly observed is that logical metamodel cannot be changed, it can only be supplemented; this guarantees that the repository can still be accessed by other tools.
The annotation consists of diagram type annotation (describing general properties of the diagram as a whole) and annotation elements that can be attached to classes, associations or attributes present in the original (logical) metamodel or in the metamodel extensions.
Diagram type annotation can include menu definition (LLK provides default menu for all diagram types, however it can be changed, e.g., by deleting some items or adding items that correspond to some external operations) and consolidation strategy specification (different consolidation strategies are described in the next section). By term consolidation we mean the process of keeping diagrams in sync with repository.
Class annotation can include the following items:
Possible elements of association annotations:
Navigation service monitors user’s activities and, if the user clicks on some compartment for which navigation service is specified, highlights the corresponding graphical object, probably also opening (if not already open) some other diagram.
Prompting service is described below together with attribute annotations.
Attribute annotations can include the following elements:
Navigation service already was described above. Its specification consists of an association annotation (which association to navigate …) and attribute annotation (… when clicked on which compartment).
Prompting service provides the following features. The edit control corresponding to the annotated attribute is supplemented with drop-down list functionality, and in this list values of some attribute of instances of some (usually other) class are collected. If the user picks some value from this list, an association instance is established between the current object and the object identified by the picked value. In the annotation language, just like for navigation, prompting is defined in two parts – an attribute annotation (edit control of which attribute should be supplemented with drop down list …) and association annotation (… to provide a possibility of creating instances of which association).
Default services provided by Logical Layer Kernel
All actions that are supported by LLK could be subdivided into global actions and actions inside some diagram.
Global actions Load diagram, Save diagram, Consolidate diagram are provided. Logical objects are stored/updated/deleted in the repository as soon as they are created/modified/deleted in a diagram. Diagram saving involves storing the diagram as a large object into a special repository table (a part of metamodel extensions) so that it could later be retrieved by Load diagram, retaining graphical characteristics of the diagram (object positions, styles, etc).
Consolidation process restores graphical diagram from logical repository contents in a consistent manner, using some autolayout algorithm. Two consolidation modes are supported. The first is graphical ("light") consolidation, where visible object attribute values are updated according to values in repository, objects registered in the repository as belonging to the current diagram (this registration also is done using metamodel extensions) are added to the diagram if not already present, and objects contained in the current diagram are removed if not any longer registered in the repository as belonging to the current diagram. This consolidation mode is useful in the cases when:
Logical ("strong") consolidation is useful when it is necessary for a single diagram to represent all instances of the appropriate classes. This consolidation registers all objects (of classes that are relevant for the current diagram type) as being part of the current diagram.
Consolidation mode is specified using annotation language. Consolidation can be offered to the user as a stand-alone operation, or it could be performed automatically when the diagram is opened (or even regains focus). Thus automatic graphical consolidation is the main solution in EF approach to keep automatically diagrams consistent with each other and with repository contents.
Export to file, Import from file, Export to WMF, Export to HTML actions are supported.
Logical change support provides means of manipulating repository contents.
Graphical changes – do not affect part of the repository specified by the logical metamodel; only GEC are involved in providing this functionality:
Selection – two modes are supported: single symbol selection and selection of several symbols through drawing a lasso around them or by Ctrl-clicking.
Service actions:
Editor options – possibility to set global options such as diagram background color, default layout algorithms etc.
A typical scenario of using the Editor Factory is described below.
Suppose that a graphical editor allowing editing and browsing BusinessActivity Decomposition diagrams in ADDE is needed.
Four classes from ADDE metamodel together with associations between them are included in a view (the view corresponding to Activity Decomposition report) that serves as a starting point for defining the corresponding diagram type. These classes are ‘Business Activity’, ‘Business Event’, ‘Dependency’, and ‘Bus_Act_Decomp’ (Business Activity Decomposition).
Suppose we want Business Activities to be shown as rectangular boxes with rounded corners, and dependencies between two Business Activities – as arrows. Then we change the graphical style of Business Activity class to be a rectangular box with rounded corners, and we also annotate Dependency with Line and change the line style for the associations (Dependency from/to Business Activity) to be the same as we want corresponding lines to look like.
End users will be able to draw an arrow representing a Dependency by clicking on one Business Activity box and dragging to another Business Activity box. In this case direction is important, because for LLK it is necessary to know which Business Activity is in from relation with the created Dependency and which one is in to relation, and where to put the arrowhead. Therefore, the two associations between Business Activity and Dependency are annotated with Start and End.
LLK has to know how to represent the symbol palette used for picking graphical objects. In our example Dependency is annotated by Icon(23) specifying that icon representing Dependency line should be the 23rd icon in icon library. Certainly, the generation of icon library itself is outside the scope Editor Factory, this job is performed using any bitmap editor.
Some attributes of Business Activity are annotated with compartment(n). Such attributes should be depicted by drawing their values inside boxes representing Business Activities. Text drawing is done inside compartments; by default, a compartment is a horizontal area inside a box that spans the whole box width. It may be separated from upper and lower compartments by a horizontal line. Compartment (vertical) ordering is specified as first parameters of compartment annotations.
Attribute Activity Name is also annotated with PK (for "primary key"). Such annotation means that LLK should ensure that the corresponding attribute could serve as an identifier of instances of that class, i.e., every two instances of the class should have different values of this attribute.
Not only individual classes, but also the class diagram view as a whole can be annotated to specify the properties pertaining to the corresponding diagram in general. An additional class ‘Activity Decomposition Diagram’ is added to the annotated view. This class (together with associations linking it with other classes in the diagram) specifies how diagrams should be stored in the repository and how object occurrences in diagrams should be registered (for consolidation purposes). In our example diagram class annotations are Diagram(multiple) and Consolidate…. The first one means that several diagrams of this type will be permitted. The second annotation defines the consolidation strategy.
We want that each pair of a Business Event box and a Business Activity box is connected with a line if corresponding instances of Business Event and Business activity are linked by ‘unit of work start/trigger of’ association instance. That is, we want that an association is represented as a graphical object. This is specified by annotation Line(association) and visual representation of the line style.
The presented annotation is a complete specification of the graphical editor. Thus, the customisation process takes only as much time as necessary to draw the following picture, i.e., it is very fast provided there is some experience with the Annotation Language.
When view annotation is finished, the diagram is passed to the Annotation Language Compiler that generates a LLD file. When LLK interprets this LLD, the resulting screenshot looks like this:
For end-user it is just a normal Activity Decomposition editor, he/she cannot see any features specific to this interpretation technology. The icon bar of the editor is automatically formed from the icons referenced in the annotation. The menu in this example is the default menu of LLK, but additional items could be added via diagram class annotation.
Suppose that after some experiments with such editor we decide that it would be better to represent the hierarchy of Business Activities by including boxes corresponding to lower lever activities inside boxes of higher level activities. Such transition would require only small changes in the annotation, and it would be just a matter of minutes to obtain the new editor. Besides that, the consolidation feature would guarantee that diagrams drawn by the old version can be imported into the new version with appropriately changed visual representation of the hierarchy relation. A screenshot of the new version of the editor is shown here:
Tool building with EF approach
Now nearly all system design methods are to a certain degree related to the Universal Modeling Language (UML). Therefore one of the feasibility checks for the EF approach was to implement the main diagrams and features of UML. Annotation Language design and LLK functionality covers the needs of UML diagrams (except sequence diagrams that are quite different in terms of necessary graphical primitives). Some examples of UML diagrams created by using a tool obtained with EF approach:
Note that it was quite easy to implement also activity diagram, typically not present in UML tools.
If UML is used as a language for certain design methodology, it is frequently extended with some new diagrams and features. The flexibility of EF approach can be demonstrated namely in such situations.
Together with ADDE partners (particularly OSI) a specific design methodology was chosen. This methodology is used by a number of European companies, and one of them already has expressed an interest to obtain a tool supporting this methodology. In the framework of ADDE a prototype for such tool was developed, covering a substantial part of the methodology.
Class, state and collaboration diagrams from UML were used as the basis. A method-specific name prompting mechanism for state diagrams and some additional structuring for texts in transition symbols was added. Support for extended text structure for operations in class diagrams was added. According to the methodology, it is possible to automatically generate skeletons of collaboration diagrams from class or state diagrams. The specifications of editors for extended class and state diagrams were obtained in an easy way as extensions of specifications for standard UML. A new diagram for refining objects in collaboration diagrams was added.
The tool prototype demonstrates feasibility of our technology in the sense of permitting to mix Annotation Language usage to specify features of typical actions in editors and use of external functions for non-standard actions such as collaboration diagram generation.
We have demonstrated that Editor Factory technology is good for easy building of tools supporting custom methodologies. In particular, it is important for tools based on small extensions to UML. Most existing commercial UML-type tools support just the language and very straightforward code skeleton generation from class diagrams, but not any particular design methodology. Methodology-intensive UML tools have a significant perspective, and our technology is suitable for rapid development of such tools.
Although EF technology was developed mainly for applications to modeling tool building, it can equally successfully be used for other application areas, e.g., for building database browsers and editors. There is a tendency for modern database applications to process not only information that is best presented in a table-like manner using standard GUI forms, but also information that, although kept in a relational database using tables, is best presented in a graph-like form (e.g., workflow data). Our technology can be used also for such domains. Here is a screenshot of PERT chart editor taking data from a workflow database developed with EF:
We have developed, first, a reusable component (graphical engine) that provides the basic diagram drawing and maintenance services, and, second, a technology that incorporates this engine and that can be used for rapid development of repository-based diagrammatic tools. Feasibility of this technology for UML-like tools have been studied with positive results. However, UML is only a small portion of possible application areas of our technology.
It is planned that commercial quality version of both GEC and EF will be ready till August 1999.