G EN GE D A Development Environment for Visual Languages Roswitha Bardohl, Magnus Niemann, Manuel Schwarze Department of Computer Science Technical University Berlin, Germany frosi,maggi,
[email protected]
Abstract Within this contribution G EN GE D is presented, a development environment for visual languages. G EN GE D offers a hybrid language for defining the syntax of visual languages consisting of an alphabet and a grammar. Correspondingly, the main components of G EN GE D are given by an alphabet and a grammar editor. The syntax description is the input of a diagram editor allowing the syntax-directed manipulation of diagrams. The grammar definition as well as the manipulation of diagrams is based on algebraic graph transformation and graphical constraint solving. Keywords: visual language, algebraic graph transformation, constraint solving, ruleand constraint-based editor.
1 Introduction Visual languages (VLs) are emerging in various application areas, compare for example [Shu88,Cha90,BGL95,Sch98]. Usually they are tightly integrated with a corresponding visual environment (VE). This is the main disadvantage when the concepts of a language or the visual notations are changed. Then a partial reimplementation of the VE is necessary. These reimplementations are time consuming and costly. For this reason more and more generators of VEs are appearing whose input is mostly a textual syntax description of a specific VL. In general, visual statements are difficult to describe textually because of their graphical structure. On the other hand, visual descriptions are usually not sufficient to define all necessities [Sch98]. To avoid such problems we propose G EN GE D, a development environment for VLs. G EN GE D implements the visual definition of VLs, whereas the textual parts are concerned with graphical constraints and common datatypes like strings or integers. Within G EN GE D the syntax of a VL is defined by an alphabet and a grammar. Accordingly, the main components of G EN GE D, as illustrated by Figure 1, are given by an alphabet and a grammar editor. The constraint-based alphabet editor allows for the definition of a VL-alphabet. Such an alphabet is a set of templates which can be instantiated to build diagrams. The grammar editor then is used to construct more complex rules using simple insertion/deletion rules automatically generated from an alphabet. The user-defined VL-grammar is the input of a rule- and constraint-based diagram editor allowing the syntax-directed manipulation of VL-diagrams by applying grammar rules.
GENGED Alphabet Editor
VL-alphabet
Grammar Editor
VL-grammar
Rule- and constraint-based Diagram Editor
Figure 1 . The G EN GE D components.
Usually a diagram comprises several symbols and connections between symbols. In G EN GE D a diagram is represented by an attributed graph structure consisting of a logical level (abstract syntax) which is connected with the layout level (concrete syntax) by suitable operations [BTMS99]. On the implementation side, the logical level of a diagram is mapped onto an attributed graph where the nodes represent the symbols of the diagram and the edges the connections. Common datatypes like strings or integers, which are also interpreted as symbols, are mapped onto the attributes of a node. Based on attributed graphs the manipulation of diagrams is supported by the integrated graph transformation machine A GG [TER99]. The layout level of a diagram is given by a set of graphics and graphical constraints. These constraints pertain mainly to positions and sizes of graphics. The solving of graphical constraints is supported by the integrated constraint solver PAR C ON [Gri96]. To make the work with G EN GE D as easy as possible, the editors have a similar graphical user interface (GUI). So the GUI comprises mainly a structural view and a drawing area for the elements belonging to the VL-alphabet, VL-grammar or diagram. The structural view holds the (textual) logical level of symbols and connections which can be selected for further manipulation. This paper is organized as follows: In Section 2 the components of the alphabet editor are discussed. The grammar editor and additionally the rule- and constraint-based diagram editor is topic of Section 3. Related work is presented in Section 4. Some concluding remarks will be made in Section 5.
2 Alphabet Editor The alphabet editor supports the definition of a VL-alphabet consisting of symbols and connections. For example, symbols of a VL for class diagrams are given by a class represented by three rectangles, or an association represented by an arrow. Usually, the association arrow is connected with classes, so it begins and ends at a class symbol. Accordingly, the alphabet editor comprises a symbol and a connection editor. In order to test the defined alphabet we developed a simple test editor (not illustrated in Figure 1). It supports the purely constraint-based drawing of diagrams, not considering any VLrules. Symbol Editor The symbol editor works similar to a common graphical editor: Several primitive graphics are available, such as rectangle, circle, ellipse, polygon, line, etc. The user can change the form of every primitive and change default properties like fill and line color, style, etc. As usual, primitives can be translated, scaled, rotated and stretched. Not only the drawing of symbol graphics is supported, but also the import of bitmap graphics (GIF, JPG).
Figure 2 . Alphabet Editor with activated Symbol Editor.
In contrast to a common graphical editor, the final size as well as the grouping of graphical primitives in order to build up a symbol graphic is done via constraints. So, for example, the three rectangles of a class symbol must be connected by constraints as shown in Figure 2. A constraint menu is available where suitable constraints can be selected (see Figure 3). Constraints are used automatically to connect certain attachment points to a primitive. Such points are useful for defining connections within the connection editor. Internally they are treated like normal primitives. Datatypes like strings, integers or lists of strings are predefined symbols. They are implemented by predefined components. A corresponding choice is given as for common primitives. For each datatype the predefined default value can be changed by the user. In addition to the properties of primitives, visual datatype properties like color or font can be set by the user. For each symbol a unique name must be defined which is interpreted as the symbol type. The symbol graphic, comprising primitives and constraints, defines the default layout which is used for instances. The same is true for datatype symbols where the default layout is given by the default value and visual properties. Connection Editor Connections between symbols can be defined using the connection editor. On the logical level each connection is represented by a unary operation (connection type). Accordingly, there is a set of constraints for the layout level. So for every connection a source and target symbol must be selected from the structure view and suitable constraints must be defined using the same mechanisms as are available within the symbol editor.
Figure 3 . Constraint dialog to apply constraints to primitives.
Connections can be defined by considering these semantical aspects of a VL. Consider for example the begin and end connection between an association and a class symbol. On the logical level, for both connections or operations defining the association symbol as the source and the class as the target requires the existence of the classes at the time the association is to be inserted. This follows from the underlying formalism of attributed graph structures [BTMS99]. High Level Constraints Within the alphabet editor graphical constraints are used, on the one hand to connect primitive graphics in order to build up symbol graphics and on the other hand to define the connections. The constraint solving is done by PAR C ON [Gri96], a constraint solver for so-called low level constraints (LLCs). Such LLCs are not very user-friendly which is the reason why we provide high level constraints (HLCs) whose names and parameters are shown in the constraint dialog (see Figure 3). Possible types for parameters can be declared by object-oriented mechanisms, like inheritance. For the declaration of HLCs we developed a textual definition language supporting mathematical functions, intervals, overloading of constraints, use of “subconstraints”, casting of types, support of parameter sets, etc. [Sch99]. Internally a HLC is mapped onto arbitrarily many LLCs, which are processed by PAR C ON. A LLC can be one of the following forms: normal linear formula, product formula, formula to set a point-topoint distance, or a formula to set the equality of two points. In every LLC we can use the parameters of a HLC as well as local variables. For example, the following simple HLC sets a minimal length for a line and uses a local variable, a linear formula as well as an expression for a point-to-point distance: constraint MinLength(Line l, ConstValue minLength) { Value length; # local variable length >= minLength; # linear formula l.s R= length * l.t; # distance between start and end point }
Many HLCs are predefined in the HLC database which can be extended by a user’s own HLCs. When HLCs are applied by using the constraint dialog, consistency checks are done by the constraint component of G EN GE D to avoid contradictory constraints.
3 Grammar and Diagram Editor The grammar of a VL comprises a start diagram and a set of VL-rules. Each VL-rule consists of a left hand side (LHS), a right hand side (RHS) and an optional set of negative application conditions (NACs). NACs describe certain diagram constellations which must not exist before a rule is to be applied. Both LHS and RHS, and also each NAC are themselves diagrams. The elements of a diagram (symbols and connections) are instances of the corresponding templates in the VL-alphabet. The grammar editor is based on a given VL-alphabet. It uses, for example, the defined symbols and connections to generate a set of edit commands, called alphabet rules. Alphabet rules control the insertion and deletion of symbols and connections in the corresponding diagram. Such diagrams are the start diagram as well as the LHS, RHS, and NACs of the desired VL-rules. According to the alphabet editor, the names of the alphabet rules are illustrated in the structural view of the grammar editor. They can be selected for display in the corresponding drawing area (see Fig. 4).
Figure 4 . Grammar Editor.
A match must be defined between the alphabet rule’s LHS and the current diagram when a rule is applied. Symbols can be selected for a match but not connections which are represented by constraints. These are mapped implicitely. It is possible to add and remove mappings to and from a match and to complete the match. During a transformation step, first the logical level of the diagram is taken into account and then the layout level, where graphical constraints are solved. The transformation of the logical level is done by the integrated graph transformation machine A GG. After transformation, the structural correctness of the resulting diagram is checked. This means, that some side effects may occur after transformation, because of the mapping from the diagram’s graph structure to a simple graph. Therefore, we have to make sure that for every symbol all outgoing connections with the appropriate target symbols exist. If the resulting diagram is not correct, the transformation is cancelled and the user gets a corresponding message. The layout level of the resulting transformation is built up according to the logical level: For each added (deleted) element a graphical object or constraint set respectively, is added (deleted). After constraint solving via PAR C ON the layout level is displayed. Once you finished constructing the diagrams of a VL-rule (LHS, RHS, NACs), the mappings between their symbols can be defined in the same way as matches for rule application are defined. For example, it is possible to add and remove mappings to and from the rule, even to complete the rule or NAC mappings. Datatypes and Rule Parameters Datatypes are predefined symbols which are defined through algebraic operations and constants. A “list of strings” datatype, for example, can be defined by the empty list as a constant and operations like first or add. Default datatype values set in the symbol editor are constants. When defining a VLrule these constants can be changed by variables or complex expressions. In order to make the treatment of datatypes as easy and extendable as possible we use Java objects and Java expressions as available in the attribute component of A GG. The only extension to the AGG concepts lies in the graphical representation, so datatype objects are represented by graphics, not only by textual expressions. Datatype objects (constants, variables or complex expressions) must be declared using a corresponding menu. On the LHS of a VL-rule only variables may occur as attributes of a symbol. When a rule is applied the variables are matched implicitely, and the values are transformed in a way given by the expression on the RHS. VL-rules may additionally have rule parameters for datatype values which can be defined textually using a corresponding menu. A rule parameter is, similar to a variable, given by a name and a type like x:String. Such parameters may already express some semantical aspects of a VL. In the case of class diagrams for example we could enforce that every class is inserted into a diagram with a user-defined class name. This name can be added by a rule parameter. Whenever the VL-rule, which allows for the insertion of a class, is applied, the user is forced to define a class name. Diagram Editor The user-defined VL-grammar is the input of the desired diagram editor allowing the syntax-directed manipulation of diagrams. The diagram editor comprises one drawing area instead of the four in the grammar editor for defining VL-rules. However, the edit commands of the diagram editor are the VL-rules. Matching is then
done by successively asking the user to provide the symbols corresponding to the symbols occuring in the rule’s LHS. When all symbols are mapped, the match is completed by connection mappings, and the transformation takes place (including the check for correctness). Whenever a VL-rule comprises rule parameters, the user is successively asked to define suitable values for these parameters. These values are (graphically) placed after transformation by considering the defined connection constraint.
4 Related Work Many different formalisms have been proposed for the definition of VLs [MM98]. ¨ In contrast to existing approaches using either algebraic techniques [DU98] or graph grammar approaches as presented by G¨ottler [G¨ot87], Andries, Engels, Rekers, Sch¨urr [RS96,AER98] and Minas, Viehstaedt [MV95,Min98] our approach uses both for defining an alphabet and a language grammar [BTMS99]. We use algebraic specification techniques to define graphical symbols, links and layout constraints in an axiomatic way. This seems to meet the definition of the very basic issues of a visual language in a natural way. The grammatical structure of a language is described by graph transformation which is again a very natural formalism for this purpose. Many different tools just as formalisms have been proposed supporting the definition of VLs. In contrast to other approaches G EN GE D allows for the explicit definition of alphabets and grammars for VLs. In [CODL95] the vlcc-environment is introduced that supports the visual definition of VLs, too. A symbol editor can be used to define terminal and non-terminal symbols. The defined symbols are then available within a production editor allowing the definition of context-free positional grammar rules. In contrast, we use algebraic graph grammars which are not restricted to be context-free. Nevertheless, vlcc offers not only a nice possibility to define VLs visually. Moreover, it generates free-hand editors for defined VLs.
5 Conclusion In this paper we introduced the G EN GE D environment supporting the visual definition of VLs. The VL definition comprises an alphabet and a grammar. The alphabet is the basis to define the grammar. The user-defined grammar is the input of a syntax-directed diagram editor whose edit commands are the VL-rules occurring in a grammar. Diagrams are represented by attributed graph structures which are mapped to attributed graphs. The manipulation of diagrams is done by the integrated graph transformation system AGG [TER99] together with the constraint solver PAR C ON [Gri96]. The current implementation of G EN GE D is done using Java 1.1, as is the graph transformation system A GG. PAR C ON is used as a server and is implemented in Objective C. The implementation of G EN GE D as well as some case studies are described in [Sch99] (alphabet and test editor) and in [Nie99] (grammar and diagram editor). G EN GE D can be used to define several VLs because it allows any kind of connections. The case studies comprise box-like Nassi-Shneiderman diagrams as well as a restricted kind of graph-like Statecharts. The modeling of graph-like class diagrams is sketched in [BTMS99]. Further case studies are in preparation.
G EN GE D is available at http://tfs.cs.tu-berlin.de/genged. The current implementation is not complete with respect to several desirable features. For example, parsing is not provided nor is code generation. With respect to industrial relevance, both features are important as well as the connection of several generated diagram editors. These are the main topics for future work.
References [AER98] M. Andries, G. Engels, and J. Rekers. How to Represent a Visual Specification? In [MM98], pages 245–259, 1998. [BGL95] Margaret M. Burnett, Adele Goldberg, and Ted G. Lewis, editors. Visual ObjectOriented Programming: Concepts and Environments. Manning Publications Co., Greenwich, 1995. [BTMS99] R. Bardohl, G. Taentzer, M. Minas, and A. Sch¨urr. Application of Graph Transformation to Visual Languages. In [Roz99], pages 103–180, 1999. [Cha90] Shi-Kuo Chang, editor. Principles of Visual Programming Systems. International Editions. Prentice Hall, Englewood Cliffs, NJ, 1990. [CODL95] G. Costagliola, S. Orefice, and A. De Lucia. Automatic Generation of Visual Programming Environments. IEEE Computer, 28(3):56–66, March 1995. ¨ ¨ udarlı. Input and Output for Specified Visual Languages. [DU98] T.B. Dinesh and S.M. Usk¨ In [MM98], pages 325–351, 1998. [G¨ot87] Herbert G¨ottler. Graph Grammars and Diagram Editing. In H. Ehrig, M. Nagl, G. Rozenberg, and A. Rosenfeld, editors, Graph Grammars and Their Application to Computer Science, volume 291 of Lecture Notes in Computer Science, pages 216– 231, 1987. [Gri96] P. Griebel. ParCon - Paralleles L¨osen von grafischen Constraints. PhD thesis, Paderborn University, February 1996. [Min98] M. Minas. Hypergraphs as a Uniform Diagram Representation Model. In Proc. Theory and Application of Graph Transformation, pages 24–31, Paderborn, Germany, November 1998. [MM98] K. Marriott and B. Meyer, editors. Visual Language Theory. Springer, New York, 1998. [MV95] M. Minas and G. Viehstaedt. DiaGen: A Generator for Diagram Editors Providing Direct Manipulation and Execution of Diagrams. In Proc. IEEE Symp. on Visual Languages, pages 203–210, Darmstadt, Germany, September, 5-9 1995. [Nie99] M. Niemann. Konzeption und Implementierung eines generischen Grammatikeditors f¨ur visuelle Sprachen. Master’s thesis, TU Berlin, 1999. [Roz99] G. Rozenberg, editor. Handbook of Graph Grammars and Computing by Graph Transformaitons, Volume 2: Applications. World Scientific, Singapore, 1999. [RS96] J. Rekers and A. Sch¨urr. A Graph Based Framework for the Implementation of Visual Environments. In Proc. IEEE Symp. on Visual Languages, pages 148–155, Boulder, Colorado, September 1996. [Sch98] J. Schiffer. Visuelle Programmierung. Addison-Wesley, 1998. [Sch99] M. Schwarze. Konzeption und Implementierung eines generischen Alphabeteditors f¨ur visuelle Sprachen. Master’s thesis, TU Berlin, 1999. [Shu88] N.C. Shu, editor. Visual Programming. Van Nostrand Reinhold, New York, 1988. [TER99] G. Taentzer, C. Ermel, and M. Rudolf. The AGG Approach: Language and Tool Environment. In [Roz99], pages 551-604, 1999.
