<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Constructing domain-specific design tools with a visual language meta-tool</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Nianping Zhu</string-name>
          <email>nianping@cs.auckland.ac.nz</email>
          <xref ref-type="aff" rid="aff0">0</xref>
          <xref ref-type="aff" rid="aff2">2</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>John Grundy</string-name>
          <email>john@cs.auckland.ac.nz</email>
          <xref ref-type="aff" rid="aff0">0</xref>
          <xref ref-type="aff" rid="aff1">1</xref>
          <xref ref-type="aff" rid="aff2">2</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>John Hosking</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
          <xref ref-type="aff" rid="aff2">2</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Department of Computer Science</institution>
        </aff>
        <aff id="aff1">
          <label>1</label>
          <institution>University of Auckland</institution>
          ,
          <addr-line>Private Bag 92019, Auckland</addr-line>
          ,
          <country country="NZ">New Zealand</country>
        </aff>
        <aff id="aff2">
          <label>2</label>
          <institution>and Department of Electrical and Electronic Engineering</institution>
        </aff>
      </contrib-group>
      <abstract>
        <p>Collaborative, visual design tools are typically difficult to build and evolve. We describe a meta tool for specification and generation of multiple view, multiple user visual design tools. The tool permits rapid specification of visual notational elements, underlying tool information model requirements, visual editors, the relationship between notational and model elements, and behavioural components. Tools are generated on the fly and can be used for modelling immediately. Changes to the meta tool specification are immediately reflected in any tool instances.</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>Introduction</title>
      <p>
        Multi-view, multi-notational visual environments are popular tools in a wide
variety of domains. Examples include software design tools, circuit designers, visual
programming languages, user interface design tools, and children’s programming
environments. Many frameworks, meta-tool environments and toolkits have been
created to help support the development of such visual language environments. These
include MetaEdit+ [
        <xref ref-type="bibr" rid="ref6">6</xref>
        ], Meta-MOOSE [
        <xref ref-type="bibr" rid="ref2">2</xref>
        ], Escalante [
        <xref ref-type="bibr" rid="ref8">8</xref>
        ], and DiaGen [
        <xref ref-type="bibr" rid="ref9">9</xref>
        ]. We have
also had a long term interest in developing frameworks and meta tools supporting
development of such tools, including JViews [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ] and JComposer meta-tools [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ].
      </p>
      <p>
        However, current approaches to developing multiple-view visual language tools
suffer from several deficiencies. Frameworks provide low-level yet very powerful
sets of reusable facilities for building specific kinds of visual language tools or quite
general-purpose applications, depending on their degree of domain specialisation.
General purpose frameworks like MVC [
        <xref ref-type="bibr" rid="ref5">5</xref>
        ] and Unidraw [
        <xref ref-type="bibr" rid="ref11">11</xref>
        ] typically lack
abstractions specific to multi-view, visual language environments. Special purpose
frameworks like Meta-MOOSE [
        <xref ref-type="bibr" rid="ref2">2</xref>
        ], JViews [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ], and Escalante [
        <xref ref-type="bibr" rid="ref8">8</xref>
        ] offer more easily
reusable facilities for visual language environments, but require detailed programming
knowledge and a compile/edit/run cycle, limiting their ease of use and flexibility for
exploratory development. Many general-purpose toolkits that are suitable for visual
language development have been produced, including Tcl/Tk [
        <xref ref-type="bibr" rid="ref12">12</xref>
        ] and Suite [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ], but
lack high-level abstractions for visual, multi-view environments. More targeted
toolkits include DiaGen [
        <xref ref-type="bibr" rid="ref9">9</xref>
        ], JComposer [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ] and PROGRES [
        <xref ref-type="bibr" rid="ref10">10</xref>
        ]. Some use a code
generation approach from a specification, e.g DiaGen and JComposer. Others, such as
PROGRES, are based on formalisms such as graph grammars and graph rewriting
which are used for high-level syntactic and semantic specification of tools. Code
generation approaches suffer from similar problems to many toolkits: edit/
compile/run cycle needed and difficulty in integrating third party solutions. Meta-tools
provide an integrated environment for developing other tools. These include
MetaEdit+ [
        <xref ref-type="bibr" rid="ref6">6</xref>
        ], Escalante [
        <xref ref-type="bibr" rid="ref8">8</xref>
        ], JComposer [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ] and IPSEN [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ]. Typically meta-tools provide
good support for their target domain environments but they are often limited in their
flexibility and degree of integration with other tools.
      </p>
      <p>Our aim was to produce a new meta-tool, Pounamu1, that could be used to rapidly
design, prototype and evolve tools supporting a very wide range of visual notations
and environments, ameliorating these deficiencies. To achieve this we based
Pounamu’s design on two overarching requirements: Simplicity of use and Simplicity
of extension and modification.
2</p>
    </sec>
    <sec id="sec-2">
      <title>Overview of Pounamu</title>
      <p>M e t a - m o d e l</p>
      <p>D e s i g n e r
E v e n t h a n d l e r</p>
      <p>D e s i g n e r
V i e w D e s i g n e r</p>
      <p>T o o l S p e c i f c a t i o n s
– X M L d o c u m e n t s
T o o l s p e c i f i c a t i o n
p r o j e c t s ( X M L )</p>
      <p>M o d e l l i n g
p r o j e c t s ( X M L )
1 Pounamu is the Maori word for greenstone jade, used by Maori to produce tools, such as
adzes or knives, and objects of beauty, or taonga, such as jewellery.</p>
      <p>Tool projects are used to group individual tool specifications. Having specified a
tool or obtained someone else’s tool project specification, users can create multiple
project models associated with that tool. Modelling tools allow users to create
modelling projects, modelling views and edit view shapes, updating model entities. To
support our ease of use requirement, the shape, view and meta-model designers use
high-level visual programming tools with relatively simple appearance and semantics.
To ensure flexibility and openness of the tools, the event handler designer allows tool
designers to choose predefined event handlers from a library or to write and
dynamically add new ones as Java plug-in components. Pounamu uses an XML
representation of all tool specification and model data, which can be stored in files, a database
or a remote version control tool. Pounamu also provides a full web services-based
API used to integrate the tool with other tools, or to remotely drive the tool.
3</p>
    </sec>
    <sec id="sec-3">
      <title>Tool Specification and Usage with Pounamu</title>
      <p>Figure 2 (1) shows an example of the Pounamu shape designer in use. On the left a
hierarchical view provides access to tool specification components and models
instantiated for that tool. In the centre are visual editing windows for defining tool
specification components and model instances. Here, a shape is defined representing a
generic UML class icon. To the right is a property editing panel supplementing the
visual editing window. General information is provided in a panel at the bottom.
1
2
4
3</p>
      <p>The underlying tool information model is specified using the meta model designer,
as in Figure 2 (2). This uses an Extended Entity Relationship (EER) model as its
representational metaphor with extensions for specifying complex property data types
and calculated fields. In this example a meta-model contains entities representing a
UML class and UML object (squares), with properties for their names, attributes and
methods. An association (instanceOf ) links class and object entities and another
association (implements) links classes. The meta model tool supports multiple views
of the meta model, allowing complex meta models to be presented in manageable
segments.</p>
      <p>Other Pounamu specification tools include the connector designer, view type
designer and an event handler designer. The view designer is used to define a visual
editor and its mapping to the underlying information model. Each view type consists
of the shape and connector types that are allowed in that view type, together with a
mapping from each such element to corresponding meta model element types. Menus
and property sheets for the view editor and view shapes can also be customised using
this tool. Event handlers are used to add complex behaviour to a tool via an
EventCondition-Action (ECA) model. Each handler specifies the event type(s) that causes
it to be triggered (eg shape/connector addition/modification, information model
element change, or user action), any event filtering condition that needs to be fulfilled
e.g. property value, and the response to that event in the form of a piece of Java code.</p>
      <p>Figure 2 (3) shows the simple UML class diagramming tool in use. View (3)
shows a simple class diagram where the user has created the diagram view from the
available view types, added three UML class shapes and two association connectors,
and set various properties for these, including their location and size. View (4) shows
a simplified object diagram view, including an object of class Order. Changes to the
class name are automatically reflected in this view and only methods defined or
inherited by a class may be used in the message calling.
4</p>
    </sec>
    <sec id="sec-4">
      <title>Tool Modification and Extension</title>
      <p>Users can at any time modify Pounamu tool specifications. Changes made are
immediately reflected in models being edited using that tool, creating a live
environment. This provides powerful support for rapid prototyping and evolutionary tool
development. Changes to the specification may result in information creation or loss
in the open or saved modelling projects e.g. on addition or deletion of new properties
or types. Reuse is supported by allowing shapes, connectors, meta model elements,
and event handlers to be imported from other tools or libraries. Multiple tool
specification projects may be open when modelling, with specification of parts of the
modelling tool coming from different tool specification projects.</p>
      <p>Having defined a simple tool additional behaviour can be added using event
handlers to implement more complex constraints. Examples include type checking (e.g.
UML associations must be between classes); constraints (e.g. UML class attributes
must have unique names for the same class); layout constraints and behaviour (e.g.
auto-layout of a UML sequence diagram view when edited); more complex mappings
(e.g. changes to class shape method names automatically modifiying method entity
properties in the modelling tool information model); or add back end functionality
(e.g. generate C# skeleton code from model instances). Adding or modifying a
handler results in “on the fly” compilation and incorporation in any executing tools.</p>
      <p>Back end support e.g. for code generation can be implemented by event handlers.
In addition, as all tool and model components are represented in XML format, it is
straightforward to add back end support using XSLT or other XML-based
transformation tools. This approach can allow back ends to be developed independently of
the editing environment. An additional approach for back end support is via a web
services-based API. This exposes Pounamu modelling commands, menu extensions,
etc, allowing tight and dynamic integration of third party and other Pounamu tools.
5</p>
    </sec>
    <sec id="sec-5">
      <title>Web, Mobile and Groupware Support</title>
      <p>Pounamu-implemented visual design tools may need to be accessed in a variety of
deployment scenarios and by multiple users. We have developed a set of plug-in
components that utilise the web services API of Pounamu to extend any
Pounamuspecified tool with web-based diagramming using either GIF or SVG images, mobile
PDA and phone displays, collaborative editing of diagrams, asynchronous version
control and merging support for diagrams, and CVS repository management of
versions. An example of the web-based, thin-client editing interface for Pounamu tools
being used is shown in Figure 3 (1). This allows a group of users to interact with
Pounamu views via a web browser and standard web software infrastructure. SVG
image diagrams support browser-side drag and drop of diagram component using
scripting. An alternative set of software components using Nokia’s MUPE framework
allow users to view and edit diagrams on a wireless PDA or mobile phone. This uses
a similar approach, where the MUPE server components communicate with Pounamu
via its web services API and generate special MUPE XML mark-up for the view user
interfaces. Figure 3 (2) shows an example of a project management Gantt chart
diagram being browsed and manipulated on a mobile phone.</p>
      <p>We have evaluated Pounamu’s suitability for multiple-view visual language
environment development by using it to implement a wide variety of tools and evaluating
the development process against our primary requirements. These include a full UML
tool supporting all major view types; electrical circuit modeling, semantic modelling
using Traits, web services system design using Tool Abstraction, and software
process modeling, the latter integrated with a process enactment engine. In each case
Pounamu permitted rapid development of an environment for a simple version of the
supported notation, satisfying our first requirement. These tools were then iteratively
expanded in a manner matching the second of our requirements. Current work is
focusing on a visual event handler specification tool, extending the meta-model with
calculated property specification support, and extending the shape definer and editing
plug-ins.
7</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          [1]
          <string-name>
            <surname>Dewan</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          and
          <string-name>
            <surname>Choudhary</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          <year>1991</year>
          .
          <article-title>Flexible user interface coupling in collaborative systems</article-title>
          ,
          <source>Proceedings of ACM CHI'91</source>
          , ACM Press,
          <year>April 1991</year>
          , pp.
          <fpage>41</fpage>
          -
          <lpage>49</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          [2]
          <string-name>
            <surname>Ferguson</surname>
            <given-names>R</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Parrington</surname>
            <given-names>N</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Dunne</surname>
            <given-names>P</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Archibald</surname>
            <given-names>J</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Thompson</surname>
            <given-names>J</given-names>
          </string-name>
          ,
          <article-title>MetaMOOSE-an objectoriented framework for the construction of CASE tools:</article-title>
          <source>Proc Int Symp on Constructing Soft. Eng. Tools (CoSET'99) LA</source>
          , May
          <year>1999</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          [3]
          <string-name>
            <surname>Grundy</surname>
            ,
            <given-names>J.C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Mugridge</surname>
            ,
            <given-names>W.B.</given-names>
          </string-name>
          and
          <string-name>
            <surname>Hosking</surname>
            ,
            <given-names>J.G.</given-names>
          </string-name>
          <article-title>Constructing component-based software engineering environments: issues and experiences</article-title>
          ,
          <source>J. Information and Software Technology</source>
          , Vol.
          <volume>42</volume>
          , No.
          <issue>2</issue>
          , pp.
          <fpage>117</fpage>
          -
          <lpage>128</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          [4]
          <string-name>
            <surname>Grundy</surname>
            ,
            <given-names>J.C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Mugridge</surname>
            ,
            <given-names>W.B.</given-names>
          </string-name>
          and
          <string-name>
            <surname>Hosking</surname>
            ,
            <given-names>J.G.</given-names>
          </string-name>
          <article-title>Visual specification of multiple view visual environments</article-title>
          ,
          <source>In Proc IEEE VL'98</source>
          ,
          <string-name>
            <surname>Halifax</surname>
          </string-name>
          , Nova Scotia,
          <year>Sept 1998</year>
          , pp.
          <fpage>236</fpage>
          -
          <lpage>243</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          [5]
          <string-name>
            <given-names>G.E.</given-names>
            <surname>Krasner</surname>
          </string-name>
          and
          <string-name>
            <given-names>S.T.</given-names>
            <surname>Pope</surname>
          </string-name>
          ,
          <article-title>A Cookbook for Using the Model-View-Controller User Interface Paradigm in Smalltalk-80</article-title>
          ,
          <string-name>
            <given-names>Journal</given-names>
            <surname>Object-Oriented</surname>
          </string-name>
          <string-name>
            <surname>Programming</surname>
          </string-name>
          , vol.
          <volume>1</volume>
          , no.
          <issue>3</issue>
          , pp.
          <fpage>26</fpage>
          -
          <lpage>49</lpage>
          , Aug.
          <year>1988</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          [6]
          <string-name>
            <surname>Kelly</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Lyytinen</surname>
            ,
            <given-names>K.</given-names>
          </string-name>
          , and
          <string-name>
            <surname>Rossi</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Meta</surname>
            <given-names>Edit</given-names>
          </string-name>
          +
          <article-title>: A Fully configurable Multi-User and Multi-Tool CASE Environment</article-title>
          ,
          <source>in Proceedings of CAiSE'96</source>
          , LNCS 1080, SpringerVerlag, Crete, Greece, May
          <year>1996</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          [7]
          <string-name>
            <given-names>P.</given-names>
            <surname>Klein</surname>
          </string-name>
          ,
          <string-name>
            <surname>A.</surname>
          </string-name>
          <article-title>Schürr: Constructing SDEs with the IPSEN Meta Environment</article-title>
          ,
          <source>in Proc. 8th Conf. on Software Engineering Environments</source>
          , Cottbus, Germany,
          <year>April 1997</year>
          , pp.
          <fpage>2</fpage>
          -
          <lpage>10</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          [8]
          <string-name>
            <given-names>J.D.</given-names>
            <surname>McWhirter</surname>
          </string-name>
          and
          <string-name>
            <given-names>G.J.</given-names>
            <surname>Nutt</surname>
          </string-name>
          ,
          <article-title>Escalante: An Environment for the Rapid Construction of Visual Language Applications</article-title>
          ,
          <source>Proc. VL '94</source>
          , pp.
          <fpage>15</fpage>
          -
          <lpage>22</lpage>
          , Oct.
          <year>1994</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          [9]
          <string-name>
            <given-names>M.</given-names>
            <surname>Minas</surname>
          </string-name>
          and
          <string-name>
            <surname>G. Viehstaedt,</surname>
          </string-name>
          <article-title>DiaGen: A Generator for Diagram Editors Providing Direct Manipulation and Execution of Diagrams, Proc</article-title>
          . VL '
          <volume>95</volume>
          ,
          <fpage>203</fpage>
          -
          <lpage>210</lpage>
          Sept.
          <year>1995</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          [10]
          <string-name>
            <given-names>J.</given-names>
            <surname>Rekers</surname>
          </string-name>
          and
          <string-name>
            <given-names>A.</given-names>
            <surname>Schuerr</surname>
          </string-name>
          ,
          <article-title>Defining and Parsing Visual Languages with Layered Graph Grammars, JVLC</article-title>
          , vol.
          <volume>8</volume>
          , no.
          <issue>1</issue>
          , pp.
          <fpage>27</fpage>
          -
          <lpage>55</lpage>
          ,
          <year>1997</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          [11]
          <string-name>
            <surname>Vlissides</surname>
            ,
            <given-names>J.M.</given-names>
          </string-name>
          and
          <string-name>
            <surname>Linton</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Unidraw:</surname>
          </string-name>
          <article-title>A framework for building domain-specific graphical editors</article-title>
          ,
          <source>in Proc. UIST'89</source>
          , ACM Press, pp.
          <fpage>158</fpage>
          -
          <lpage>167</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          [12]
          <string-name>
            <surname>Welch</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          and
          <string-name>
            <surname>Jones</surname>
            ,
            <given-names>K.</given-names>
          </string-name>
          <article-title>Practical Programming in Tcl and Tk</article-title>
          , Prentice-Hall,
          <year>2003</year>
          .
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>