High-level architecture of MaramaALM. 

Context in source publication

Context 1

... whether automatic layout support could be better provided. II. M OTIVATION A ND R ELATED W ORK Complex diagramming tools often need layout facilities to aid model visualization. Many use a hierarchy represented by trees e.g. a horizontal tree organising top-level business units. Some use force- directed layout for node and link diagrams e.g. a display of related document relevance for a semantic wiki. We wanted modellers of complex diagrams to be able to use automatic layout support in our Marama-generated [7] diagramming tools. However, in order to achieve a satisfactory level of aesthetic value in the visualization, manual arrangement of elements often consumes too Centre for Computing and Engineering Software Systems Swinburne University of Technology Melbourne, Australia much time and effort. Furthermore, when there is a high level of viscosity [6] in the modelling, a change of one element may require a reorganization of the layout. However, to realise such layout features usually requires considerable development effort by tool developers. Almost any non-trivial layout algorithm requires developers to write complex code. We wanted to provide Marama tool designers with meta-tool support to quickly and easily add automatic layout support to their Marama-specified diagramming tools. Our past experience indicates that the implementation process of the layout features in Marama is very time-consuming, involving low-level Java coding for each feature [8]. There are a large variety of low-level layout algorithms [5]. In the domain of tree drawing, earlier works such as [15] and [16] have contributed to the tidy renderings of “narrow” tree structures, while more recent work focuses on algorithms that minimize edge crossings. In the domain of force-directed layout drawing, one of the earlier is the spring-based force- directed layout algorithm [3], followed by a technique that uses a simluated annealing approach to determine the termination of the algorithm when the layout achieves an optimal level of aesthetics [4]. The traditional approach to provide automatic layout support is by textual specification, followed by the execution of some layout algorithm. Layout-by-Example is a notational approach suggested in [16] to specify automatic layout of diagrams using the concept of fuzzy theory. In this approach, a layout is generated based on the layout rules that are applied explicitly or extracted automatically from the stereotypes of diagram layout. These stereotypes are specified by a fuzzy visual language. Layout by interactive example is a complementary approach using interaction to specify layout constraints [2], [11], [16]. Constraint hypergraph grammars [12] are used to specify the synthetic structure and layout requirements of diagram in a consistent way. In this approach, the automatic layout support is able to accommodate user-defined adjustments. Visual specification of diagram layout has been carried out in other meta-tools, using interaction to build up layout constraint rules [10]. Kaitiaki allows tool developers to specify event handling using visual specifications [7]. These include event filtering, tool state querying and action invocation. Tool developers can compose handlers from a high-level view and incorporate them into the diagramming environment. III. T HE M ARAMA ALM A PPROACH Marama is a set of Eclipse-based meta-tools that facilitates rapid specification and construction of domain- specific visual language (DSVL) modelling tools [7]. There are two types of Marama user: specification tool and modelling tool users. Specification tool users are modelling tool designers who design and develop their software tools using facilities provided by Marama. Modelling tool users perform tasks using the Marama- generated software tools. The current Marama approach allows customisation of layout primitives using Marama event handlers i.e. plug-in Java code, the Kaitiaki visual event handler specification tool [8], or the use of textual Object Constraint Language (OCL) behaviour constraints [8]. Using these facilities to build complex diagram layout is challenging and time-consuming, even for experienced Marama specification tool users. Our primary goal was to provide an automatic layout mechanism for Marama that benefits both modelling and specification tool users. This mechanism will provide overall layout management from the viewpoint of a tool user and a tool designer. In the modelling domain, we wanted to offer better ways for Marama tool users to manage their model layouts. In the specification domain, a more accessible approach is desired for the tool designers to specify and generate layout support for their modelling tools. We have developed Marama Automatic Layout Manager (MaramaALM) to achieve this goal.MaramaALM comprises two main components: Layout Indicator and Behaviour Generator . The layout specification process begins with the Layout Indicator, followed by the Behaviour Generator. Figure 1 illustrates the addition of MaramaALM support into the Marama meta-toolset. The layout indicator augments the Marama Shape Designer allowing a specification tool user to annotate shape types that will need to have automatic layout algorithms applied to them. Currently we support the annotation of shapes to allow them to participate in force-directed layout and tree layout. The behaviour generator augments the Marama View Designer to allow specification of multiple tree or force-directed layout behaviours on elements of a diagram. It generates infrastructure for the resultant tool to realise the layouts. The Layout Indicator operates at the shape level in the Shape Designer. It allows meta-modellers to drag and drop a special notation, LayoutManager icons, onto shapes. These specify the desired layout support for these annotated shapes. Figure 2 (a) shows an example of such layoutManager annotations (green octagons) on a Marama shape designer specification. The Marama tool developer has indicated these shapes will participate in a tree layout algorithm (nodes and edges). A shape can be either a tree node or a force-directed node, determined by the node type indicated on the LayoutManager annotation. When generating the target tool, a number of necessary properties are assigned to the specified shapes in the underlying Marama tool XML representation. This ensures that their layout behaviours are reflected in the generated modelling environment. The Behaviour Generator functions in the View Designer. A special notation named ViewLayoutManager is provided to customize each desired layout mechanism. It allows the tool designer to indicate the layout support type and connectors between automatically laid out shapes to be used in the diagram type. The tool designer selects a Generate Tree Visual Handler or Generate Force-directed Visual Handler menu item, depending on the specified ViewLayoutManager, as in Figure 2 (b). MaramaALM retrieves the relevant layout specification files and Java-based event handlers to implement the layout from an existing repository and allocates them to the Marama tool specification folders. In our prototype IV. C ASE of S TUDY MaramaALM we have incorporated The Web the Evaluation choice of Planner tree or (WEP) force-directed is a Marama- layout behaviours generated tool and to functionalities assist Web developers to provide in an measuring effective the yet easy-to-use usability of layout their management Web applications. for modelling It comprises tool users. a The Process tree Scheduler layout mechanism and a Goal-Question-Metric is useful for information Builder visualisations that utilize both that the MaramaALM aim to highlight tree and a force-directed hierarchical structure. layouts to enhance It comprises modelling. layout In a support GQM model, including the automatic breakdown node of a attachments, goal into several tree questions style switching, and a collapsible refinement of or one expandable question subtrees, into several detachable metrics, subtrees form a and top-to-bottom dynamic resizing. tree Layout structure. switching Goal-Question-Metric can be activated using Builder a menu offers triggered a tree event mechanism handler. to The support descendent this nodes presentation. of a tree It are includes switched a force-directed from being aligned layout vertically to assist to outlining horizontal of the alignment entity-attribute-metric by level. Elision relationships. can be activated via The a menu tool triggered building event process handler begins . with the meta-model specification The force-directed of entities and layout associations mechanism for is WEP. useful Then to prevent WEP visual node notations overlapping, are created maintain in node the Shape proximity Designer and highlight to represent visibility the underlying of clusters entities in the and modelling associations. space. For Unlike the Process the tree Management layout, it supports view type, acyclic tree layout graphs support and any is information chosen. In order visualization to generate that the does tree not behaviours have a for strong the hierarchical target tool, structure. the modeller This mechanism drags and improves drops the the aesthetic ViewLayoutManager value of an initial notation graph into by promoting the view overall type layout specification symmetry. diagram It provides and specifies optional the automatic desired layout node attachments, and connector types layout in a optimization property sheet. through For the GQM node redistribution, view type, both an the emphasis tree and the mechanism force-directed and layout dynamic are node required. resizing. MaramaALM The behaviour generates emphasis event mechanism handlers can to be enable activated these using in the the WEP menu tool. triggered event handler when pointing Figure 3 to a target (a) shows node. the The sequence directly of connected activities nodes that are of the to be selected ...