GrTP: Transformation Based Graphical Tool Building Platform Jānis Bārzdiņš, Andris Zariņš, Kārlis Čerāns, Audris Kalniņš, Edgars Rencis, Lelde Lāce, Renārs Liepiņš and Artūrs Sproģis Institute of Mathematics and Computer Science, University of Latvia Raina bulvaris 29 Riga, LV-1459, LATVIA {Janis.Barzdins, Andris.Zarins, Karlis.Cerans, Audris.Kalnins, Edgars.Rencis, Lelde.Lace, Renars.Liepins, Arturs.Sprogis}@mii.lu.lv ABSTRACT model and the Mapping meta-model, by means of which In this paper we introduce a novel wide-profile graphical mappings between the previous ones can be defined. The tool-building platform GrTP which is based on the specification of a concrete tool is done by building principle of separating semantic domain model processing instances of all the abovementioned meta-models. The next and user interface components. This principle is enabled in step is the generation of Java classes (C# classes in case of GrTP by a meta-model for visual information presentation MS DSL); by compiling these classes an executable tool is (“interface meta-model”). A novel feature of GrTP is that it obtained. consistently bases all work of connecting the domain and This architecture is well suited in cases when the domain interface models on model transformations. These and graphical notation meta-models have sufficiently transformations can be produced for different domain similar structure. In these cases the above described static models, thus obtaining concrete tools tailored to specific mapping facilities are sufficient to define the tool domains within GrTP. The visualization component of functionality in an adequate way. However, frequently the GrTP is based on an original high-performance graphical domain and its graphical presentation are not so similar, diagram presentation engine which embodies advanced and the only option is a manual code extension in Java (or graph drawing algorithms. The paper explains the GrTP C#, respectively), that requires a deep understanding of the platform along with the first practical experience of its generated code. usage. A question arises, whether it is possible to build a very Keywords simple (both from the architecture and user point of view) Tool-building platforms, model transformations, interface platform, where the only link between the domain and meta-models, domain meta-models. interface meta-models is by means of model transformations. This would allow describing connections 1.INTRODUCTION of any complexity between domain and interface meta- Increasingly more information is stored in repositories as models in a uniform and structured way. instances of meta-models (we will call them domain meta- At the core of our approach is an interface meta-model of a models), e.g. semantic web ontologies and UML diagrams. principally new kind, which directly contains both the This information must be viewed and edited by diverse classes of graphical presentation elements themselves and types of users with different needs. Usually each group their types, as well as classes of events and commands. In requires a different view of underlying meta-model that is other words, our interface meta-model describes all tailored to their needs. Generally, graph diagrams provide a possible graph diagram "screenshots" and all possible end convenient way to view this information. We propose a user actions (events). The presentation engine, the main new framework GrTP for building such interfaces. control unit of GrTP, is in a sense an interpreter of interface The basic difference between our proposed framework and models that are instances of the abovementioned interface traditional tool building platforms such as Eclipse GMF [7, meta-model. It is capable to visualise elements in 17], Microsoft DSL [1], MetaEdit+ [13, 14], Pounamu/ accordance with their types, as well as to call Marama [8, 18], Diagen/Diameta [2, 3], GME [5, 11] is in transformations as responses to end user actions. the principles of the general architecture of the framework. Let us explain this in some detail, using Eclipse GMF as a 2.OVERVIEW OF GrTP typical example. According to the GMF approach [7], Figure 1 schematically depicts the structure of GrTP. GrTP besides the EMOF meta-model for defining ECore models consists of control unit, called GrTP Engine (or (domain meta-models), the following three meta-models Presentation Engine, or PE, for short), and repository. The are used: the Graphical definition meta-model for defining repository contains a fixed interface meta-model (IMM) types of graphical presentation elements, the Tooling meta- and its instances that are interface models, as well as a domain meta-model (DMM) and its instances that are domain models (e.g., concrete UML activity diagrams that connecting the transformations to the concrete correspond to the UML activity diagram meta-model). events of presentation engine; Each interface model contains a graphical view reflecting The work of the specialized tool can be perceived as the corresponding domain model, plus it contains instances cooperation between PE and TE. PE detects user actions, of IMM classes that correspond to symbol palette and its creates corresponding event instance and calls TE. The elements, toolbars and popup menus, as well as user actions transformations, on the other hand, are processing the (called events) on concrete interface elements. events created by PE. This usually involves making changes to instances of IMM and DMM. Transformations may also issue commands for PE that are visualization instructions to be executed by PE. We note that both Event and Command classes are included in IMM, and their instances can be linked to instances of other IMM classes. 3.INTERFACE META-MODEL The interface meta-model is the core of the framework. It can be viewed as the interface between the presentation engine (hard-coded part) and transformations (adapted for a particular tool). Here we consider a simplified version of the interface meta-model (subset of the full interface meta- model) depicted in figure 2. We let the role names of associations, if not explicitly specified, to coincide with the corresponding class names, with first letter in lowercase. The visual elements of the interface correspond to the classes GraphDiagr, Node and Edge, together with NCompartment and ECompartment that correspond to text fields placed in nodes and attached to edges, respectively. The location attributes in Node and Edge classes encode the Fig. 1. The structure of GrTP placement of corresponding nodes and edges in the diagram, and they are to be understood only by the The work of GrTP Engine on a concrete DMM is powered Presentation Engine; they are not meant for use by model by model transformations connecting DMM and IMM. To transformations. enable writing of these transformations, scaffolding The IMM includes GraphDiagrType class for different between DMM and IMM that contains interconnection graph diagram types (e.g., class diagrams, or activity links of concrete DM and IM elements is used. The diagrams) together with NodeType and EdgeType classes transformations can be written in any universal model for types of nodes and edges that are allowed in diagrams transformation language (e.g., QVT [12], MOLA [13]) that of respective type. The type information for node or edge has an efficient implementation. They are called by GrTP contains style information of respective element, as well as Engine at runtime. compartment type information (NCompartmentType and The GrTP platform itself consists of a core part that is the ECompartmentType classes). In this simplified IMM we presentation engine, the implementation of the repository show only shape information for nodes and both edge ends and the IMM, and the specialization part that allows in their types (nodeShape, startShape and endShape tailoring GrTP to the needs of serving concrete DMM. attributes for simplicity are treated here as integers). The More precisely, specialization of GrTP to serve concrete compartment type information associated with node and DMM (that is, building of particular tool on the basis of edge types list names of compartments that are in elements GrTP) consists of the following: (nodes or edges) of corresponding types. The ordering of 1. providing the domain meta-model itself; node compartments is given by the values of nr attribute. For edge compartments the position attribute denotes the 2. defining types of visual presentation elements placement of corresponding compartment (e.g. at the (nodes and edges), as well as symbol palette beginning or end of the edge). The instances of elements (these are defined in IM as instances of GraphDiagrType, NodeType, EdgeType, respective IMM classes); NCompartmentType and ECompartmentType classes, as 3. defining scaffolding between the elements well as instances of Palette and PaletteElement classes are (classes) of DMM and IMM; created at initialization time of concrete specialized tool. 4. creating the transformation library (one can think These instances determine, to a large extent, the of it as of Transformation Engine (TE)) and functionality of the concrete tool that is available to the end user. For instance, the collection Command ErrorMessage of compartment types for a node OkMessage Refresh attribute: String Close Open or edge type determines the properties of compartment CurrentDiagrPointer 0..1 GraphDiagr 0..1 PaletteElement * 1 Palette 1 Diagram 0..1 name: String structure (e.g. compartment count 1 1 * name: String picture: String 1 nr: Integer and their placement) for nodes or * * edges associated with this type. Node 1 eedge Edge 1 Line 1 location: String end * location: String 1 Box 1..* The class Event ( ) and its 1 sedge * 1 GraphDiagrType subclasses correspond to the start * 1 typeName: String * 1 0..1 0..1 0..1 1 1 actions that the end user may ECompartment perform on a concrete diagram value: String 1 * 1 * 1 NodeType * sedge EdgeType and that are understood by PE. * * nodeTypeName: String start * edgeTypeName: String 1 nodeShape: Integer The instances of these classes 0..1 1 1 1 0..1 0..1 * eedge startShape: Integer end start end * endShape: Integer (called events) are created by PE 1 0..1 0..1 1 upon detection of corresponding * * 1 * end user action. NCompartment * NCompartmentType ECompartmentType value: String 1 EditEdge name: String name: String The Transformation Engine, upon enew snew nr: Integer position: Integer DeleteEdge receiving control from PE, DeleteNode NewEdge Row 1 InputField analyzes the type (class) of the EditNode NewNode 0..1 0..1 0..1 0..1 1 value: String SessionEnd PropertyDiagr 1 available event, and invokes Event Ok 0..1 1..* 1 NameField appropriate transformation, which SessionStart attribute: String Cancel 0..1 1 name: String can access the context of the event via the association links Fig. 2. Simplified interface meta-model created by PE. The Transformation Engine may, manipulation, however, this kind of decision will restrict upon transferring the control back to PE, create commands the possibility to adjust the behavior of the engine to the ( , instances of Command class) to be executed by PE. If needs of a concrete specialization. For instance, in GrTP a a command is of Refresh class, it requires the PE to update design decision has been made to leave all work of the visual presentation in accordance to changes that have positioning elements in the diagram to the hard-coded part. occurred in the interface model. This type of command is Another decision has been to allow the engine itself to typically used after node or edge addition or deletion in the produce the events like “New node” and “New edge”. visual presentation (interface). The full interface meta-model in addition to the simplified If, for instance, a NewNode event is created in a simple version considered here contains: child-parent association flowchart diagram editor, the transformation finds the type between nodes for representing node inclusion into other of the node to be created via the link to a Box nodes, subType-baseType association between element type (PaletteElement) and then via the link to NodeType. If, for classes for implementation of stereotype-like mechanism, instance, the node type has nodeTypeName = “StartNode”, additional graphical element Port that is attached to the the transformation may check, if there is already an node and can be used as Pin representation in activity instance of class StartNode in the flowchart diagram, and if diagram. The meta-model also contains additional interface there is not, the transformation may insert a Node instance constructs along with corresponding events and commands, in IM and a StartNode instance in DM, and construct a e.g., Toolbar, PopUpDiagram as well as transformation- scaffolding link between these instances. Then a command driven menu for property diagram. of Refresh type is created and control is returned to PE. If the transformation is not successful, an ErrorMessage 4.IMPLEMENTATION AND FIRST command is created, what PE uses further to display a EXPERIENCE corresponding error message to the user. The The visual presentation part of GrTP is developed on the transformations can also instruct PE to open property basis of graphical engines that are developed for GRADE diagram, e.g. for input of the node attribute values. tools family [6] and offer advanced graph drawing An important design issue concerning IMM is that of the capabilities [4, 10], e.g., advanced services for automatic event and command granularity: what kind of user actions diagram element positioning according to different layouts, are served just by GrTP engine (is hard-coded into it), and basic graph diagram editing services (e.g. Zoom, Print, what kind of work is delegated to transformations. The Scroll, etc.). hard-coded part of functionality allows for transformations To ensure the efficiency of GrTP, a novel model not to be overwhelmed by low level user interface transformation language L0 has been implemented [12] with a highly efficient compiler; also an efficient in- 6.REFERENCES memory repository for holding domain and interface meta- [1] S. Cook, G. Jones, S. Kent and A. C. Wills, “Domain- models and their instances has been developed. Specific Development with Visual Studio DSL Tools,” Addison-Wesley, 2007. The first experiments with GrTP have been performed in parallel with tuning up the platform itself. As a first [2] DiaGen Overview, implementation on the basis of GrTP, a class diagram http://www2.cs.unibw.de/tools/DiaGen/doc/Overview.pdf, editor for MOF-type meta-model building was created. As 2000. an example, the meta-models in this article have been [3] DiaGen, The Tree Tutorial, constructed and printed using this meta-model editor. The http://www2.cs.unibw.de/tools/DiaGen/doc/Tutorial.pdf, time for transformation writing for this editor can be 2003. estimated in 3 person-months; that is several times less than [4] K. Freivalds and P. Kikusts, “Optimum Layout Adjustment creating a corresponding tool from scratch. Supporting Ordering Constraints in Graph-Like Diagram Drawing,” Proc. The Latvian Academy of Sciences, Section On the basis of our platform we have also developed an B, Vol. 55, No. 1, pp. 43–51, 2001. UML activity diagram editor covering nearly all their [5] The Generic Modeling Environment, GME User's Manual features, including elements like Pin, Interrupt region, etc., http://www.isis.vanderbilt.edu/Projects/gme/GMEUMan.pdf, that are rather complicated from diagram editing viewpoint. 2005. This editor also has achieved a completely satisfactory [6] GRADE tools, http://www.gradetools.com/, 2007. performance level. The time for transformation writing for this editor can be estimated in 2 person-months. We expect [7] Graphical Modeling Framework (GMF, Eclipse Modeling that use of higher level model transformation languages subproject), http://www.eclipse.org/gmf/, 2007. could reduce the transformation writing time for new [8] J. Grundy, J. Hosking, N. Zhu1 and N. Liu1, “Generating specializations of GrTP approximately by the factor of 2. Domain-Specific Visual Language Editors from High-level Tool Specifications,” 21st IEEE International Conference on 5.CONCLUSIONS AND FUTURE WORK Automated Software Engineering (ASE'06), pp. 25-36, 2006. Our basic conclusion is that such tool building platform is [9] A. Kalnins, J. Barzdins and E. Celms, “Model sufficiently effective from practical point of view, both Transformation Language MOLA,” Proc. MDAFA 2004, from perspective of efforts involved in specialization of Vol. 3599, Springer LNCS, pp. 62-76, 2005. GrTP into concrete tools (by means of transformation [10] P. Kikusts and P. Rucevskis, “Layout Algorithms of Graph- writing), and the performance of obtained concrete tools. Like Diagrams for GRADE Windows Graphic Editors,” We have considered in this paper only interface meta- Proc. Graph Drawing ’95, Lecture Notes in Computer Science, vol. 1027, pp. 361–364, 1996. model for graph diagrams (together with some auxiliary diagrams), thus describing a graph diagram engine. We [11] A. Ledeczi, M. Maroti, A. Bakay, G. Karsai, J. Garrett, C. have under development also a tree diagram engine that is Thomason IV, G. Nordstrom, J. Sprinkle and P. Volgyesi, relatively simpler and can easily be integrated into the “The Generic Modeling Environment,” Workshop on Intelligent Signal Processing, pp. 6, 2001. current architecture. The architecture admits also further inclusion of engines for other diagram types that use the [12] Lx Transformation Language Set, http://Lx.mii.lu.lv/, 2007. event/command communication pattern with the [13] MetaEdit+ Method Workbench User’s Guide, Version 4.0, transformation engine. http://www.metacase.com/support/40/manuals/mwb40sr2a4. pdf, 2005. Our current plans include further development of graph diagram engine to enable it to serve animation of diagrams. [14] MetaEdit+ User’s Guide, Version 4.0, http://www.metacase.com/support/40/manuals/mep40sr2a4.p We see one of further target application areas for GrTP df, 2005. platform also in the context of Semantic Web. GrTP seems [15] MOF QVT specification, very suitable for building graphical editors for Ontology http://www.omg.org/docs/ptc/05-11-01.pdf, 2005. languages (RDF, OWL), and graphical Semantic Web [16] Sesame, http://www.openrdf.org, 2007. browsers. One of the strengths of GrTP that can be exploited here is its ability to process large diagrams, both [17] A. Shatalin and A. Tikhomirov, “Graphical Modeling in the sense of performance, and in the sense of automated Framework Architecture Overview,” Eclipse Modeling graph drawing facilities that are built into the engine. In this Symposium, 2006. context it is important to stress the possibility to connect [18] N. Zhu1, J. Grundy and J. Hosking, “Pounamu: a meta-tool GrTP to other in-memory data stores (for instance Sesame for multi-view visual language environment construction,” [16]), which are more popular in Semantic Web world. Proc. IEEE Symposium on Visual Languages and Human Centric Computing (VLHCC’04), pp. 254-256, 2004.