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. So far, 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) emerge in an increasing frequency (cf. [VLxx] for more details). Usually, they are fixed implemented in a visual environment (VE). This is the main disadvantage when regarding VLs for e.g., software modeling or programming. Whenever the concepts of a language or visual means are changed a partly reimplementation of the supporting VE is necessary leading to a time and so far cost expensive affair. This is the reason why generators of VEs emerge more and more whose input is at least a textual syntax description of a specific VL. However, visual statements are difficult to describe textually because of their graphical structure. In the opposite, visual descriptions are mostly not sufficient enough to define all necessities [Sch98]. To avoid such problems we propose G EN GE D, a development environment for VLs. G EN GE D allows mainly the visual definition of VLs. 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 the definition of a VL-alphabet. Such an alphabet is a type description for instances as they occur within diagrams. The grammar editor is rule- and constraint-based because we use attributed graph grammars, respectively graph transformation, as underlying formalisms. The defined VL-alphabet is the input of both, a pure constraint-based editor
for testing the alphabet description as well as the grammar editor. Within the grammar editor so-called alphabet rules are generated from the alphabet. These rules are the edit commands of the grammar editor. The user defined VL-grammar is the input of a ruleand constraint-based diagram editor allowing the syntax-directed manipulation of VLdiagrams by applying grammar rules. GENGED Alphabet Editor
VL-alphabet
Grammar Editor
VL-grammar
Rule- and constraint-based Diagram Editor
Constraint-based Test Editor
Figure 1 . The G EN GE D compontents.
Parsing facilities as provided by D IAG EN [MV95] or V LCC [CODL95] are still not supported within G EN GE D. In the opposite, a textual syntax description is the input of D IAG EN and not a visual one. V LCC supports the visual definition of an alphabet but in the current state the grammar must be defined textually. In addition, within a generated diagram editor the movement of graphics do not lead to the movement of inherent graphics which is one of the main necessities of a diagram editor. 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]. In the implementation, 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. The logical level of 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 treat mainly 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 similiar GUI. I.e., the GUI comprises mainly a structure view and a drawing area for the elements belonging to the VL-alphabet, VL-grammar or diagram, respectively. The structure view holds the (textual) logical level of symbols and connections which can be selected for further progress. This paper is organized as follows: In Section 2 the components of the alphabet editor are discussed together with the test editor. The grammar editor is topic of Section 3 and additionally, the rule- and constraint-based diagram editor. Some conclusional remarks can be found in Section 4.
2 Alphabet and Test Editor The alphabet editor supports the definition of a VL-alphabet consisting of symbols and connections. Accordingly, the alphabet editor comprises a symbol and a connection edi-
tor. E.g., 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, i.e., it begins and ends at a class symbol. In order to test the defined alphabet we developed a simple test editor. It supports the pure constraint-based drawing of diagrams, i.e., without regarding any VL-rules. Symbol Editor The symbol editor works similar to a common graphical editor: Several primitive graphics are available like 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). In contrast to a common graphical editor, the grouping of graphical primitives in order to build up a symbol graphic is done via constraints. E.g., the three rectangles of a class symbol must be connected by constraints. A constraint menu is available where suitable constraints can be selected. Constraints must be used also to define certain attachment points which are useful for defining connections within the sequently toggled connection editor. Such attachment points are treated as primitives, too, and so far, they are to be connected with other primitives by constraints. Datatypes like strings, integers or list of strings are predefined symbols, i.e., they are given by implemented components. A corresponding button is given like for common primitives. For every choosen datatype the predefined default value can be changed by the user. Similar to changeable properties of primitives, also datatype specific visual properties can be changed, e.g., color or font for strings. For each symbol a unique name must be defined which is interpreted as the symbol type. The symbol graphic, i.e., primitives and constraints, defines the default layout which is used for instances. The same is true wrt. 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) and a set of constraints according to the layout level. I.e., for every connection a source and target symbol must be selected from the structure view, and suitable constraints must be defined using the same constraint menu as it is available within the symbol editor. Connections can be defined under consideration of semantical aspects of a VL. Consider e.g. the begin and end connection between an association and a class symbol. For both connections, i.e., operations according to the logical level, defining the association symbol as the source and the class as the target, requires already the presence of classes when an association is to be inserted. This fact results from the underlying formalism of attributed graph structures [BTMS99]. Test Editor In order to test the behaviour of defined constraints a pure constraint-based test editor is available. Here instances are derived from the templates of the VL-alphabet when elements of the editor’s structure view are selected. Then, the corresponding symbol graphics are visualized in the drawing area. Connections between symbols can be established under consideration of the corresponding types. The connection constraints are solved automatically.
High-Level-Constraints Within the alphabet editor graphical constraints are used intensively, once to connect primitive graphics in order to build up symbol graphics and once 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 that High-Level-Constraints (HLCs) are available whose names and parameters are visualized in the constraint menu. For the declaration of HLCs we developed a textual definition language, which supports mathematical functions, intervals, overloading of constraints, calling of “subconstraints”, casting of types, etc. [Sch99]. Internally, a HLC is mapped onto arbitrarily many LLCs processable by PAR C ON. A LLC can be one the following forms: normal linear formula, product formula, formula to set a point-to-point distance, or a formula to set the equality for two points. In every LLC we can use the parameters of a HLC as well as local variables. For instance, 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 }
There are already a lot of predefined HLCs stored within the HLC database which can be extended by own HLCs. Nevertheless, although the declaration of HLCs can be done only textually, the constraint menu allows the user to select and apply suitable HLCs. Consistency checks are also done by the constraint component of G EN GE D, i.e., some contradictionarily constraints can be detected.
3 Grammar and Diagram Editor The grammar of a VL comprises a start diagram and a set of VL-rules. Each VLrule 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 when a rule is to be applied. Both, LHS and RHS, and also each NAC are itself diagrams. The elements of a diagram (symbols and connections) are instances of the corresponding templates in the VL-alphabet, i.e., they are typed over the alphabet [BE98]. The grammar editor is based on a given VL-alphabet, i.e., it uses the defined symbols and connections to generate a set of edit commands, called alphabet rules. Alphabet rules allow to insert and delete symbols and connections in the corresponding diagram. Such diagrams are the start diagram as well as the LHS, RHS, and NACs of the aimed VL-rules. According to the alphabet editor, the names of the alphabet rules are illustrated in the structure view of the grammar editor. They can be selected for visualizing them in the corresponding drawing area. A match must be defined between the alphabet rule’s LHS and the current diagram when a rule should be applied. Concretely, symbols can be selected for a match but not connections which are represented by constraints. They are mapped implicitely. It is possible to add and remove mappings to and from a match. During a transformation
step mainly the logical level of the diagram is taken into account and thereafter the layout level, where graphical constraints are solved. The transformation of the logical level is done by the integrated graph transformation machine AGG. After transformation the correctness of the resulting diagram is checked. I.e., because of the mapping from the diagram’s graph structure to a simple graph some side effects may occur after transformation. 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 accordingly to the logical level: For each added (deleted) element a graphical object, respectively constraint set, is added (deleted). After constraint solving via PAR C ON the layout level is viewed. Once finished 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. I.e., it is possible to add and remove mappings to and from the rule, even to complete the rule or NAC mappings in order to make them total. Datatypes and Rule Parameters Datatypes are predefined symbols which are defined through algebraic operations and constants. A list of string 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 VL-rule 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 AGG [Mel99]. 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) have to 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 have additionally 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 express already some semantical aspects of a VL. In the case of class diagrams this may be classes, where each one must have a certain user defined class name. This fact can be expressed by a rule parameter. Whenever the VL-rule allowing to insert 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 aimed diagram editor allowing the syntax-directed manipulation of diagrams. The edit commands are the VL-rules. In order to apply a VL-rule, a rule name appearing in the structure view must be selected. 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 under consideration of the defined connection constraint.
4 Conclusion In this paper we introduced the G EN GE D environment supporting the syntax definition of VLs. This definition is twofold: it consists of an alphabet and a grammar definition supported by corresponding editors. The user-defined grammar is the input of a syntaxdirected diagram editor whose edit commands are the VL-rules. G EN GE D can be used to define several kinds of diagrammatic VLs because it allows any kind of connections. Furthermore, G EN GE D offers a hybrid language allowing the user to annotate common graphical symbols with datatype symbols, and to connect graphics by constraints. In this framework, VLs are represented by algebraic graph grammars. 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., so is the graph transformation system A GG. PAR C ON is used as a server. It 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 is available at http://tfs.cs.tu-berlin.de/genged. We have to mention that the current implementation is not complete concerning several desirable features. E.g., parsing is not provided as well as 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 the future.
References [BE98]
R. Bardohl and H. Ehrig. Conceptual Model of the Graphical Editor G EN GE D . In Proc. Theory and Application of Graph Transformation, Paderborn, Germany, November 1998. [BTMS99] R. Bardohl, G. Taentzer, M. Minas, and A. Sch¨urr. Application of Graph Transformation to Visual Languages. In [Roz99]. 1999. [CODL95] G. Costagliola, S. Orefice, and A. De Lucia. Automatic Generation of Visual Programming Environments. IEEE Computer, 28(3):56–66, March 1995. [Gri96] P. Griebel. ParCon - Paralleles L¨osen von grafischen Constraints. PhD thesis, Paderborn University, February 1996. [Mel99] B. Melamed. Grundkonzeption und -implementierung einer Attributkomponente f¨ur ein Graphtransformationssystem. Diploma Thesis, Computer Science, TU Berlin, 1999. [MV95] M. Minas and G. Viehstaedt. DiaGen: A Generator for Diagram Editors providing Direct Manipulation and execution of Diagrams. In Proc. Symp. on Visual Languages, Darmstadt, Germany, September, 5-9 1995. IEEE Computer Society Press. [Nie99] M. Niemann. Konzeption und Implementierung eines generischen Grammatikeditors f¨ur visuelle Sprachen. Diploma Thesis, Computer Science, TU Berlin, 1999. [Roz99] G. Rozenberg, editor. Handbook of Graph Grammars and Computing by Graph Transformations, Volume 2: Applications. World Scientific Publishing, 1999. [Sch98] J. Schiffer. Visuelle Programmiersprachen. Addison-Wesley, 1998. [Sch99] M. Schwarze. Konzeption und Implementierung eines generischen Alphabeteditors f¨ur visuelle Sprachen. Diploma Thesis, Computer Science, TU Berlin, 1999. [TER99] G. Taentzer, C. Ermel, and M. Rudolf. The AGG Approach: Language and Tool Environment. In [Roz99]. 1999. [VLxx] Proc. IEEE Symposium/Workshop on Visual Languages, Los Alamitos, CA, 19xx. IEEE Computer Society Press.
