Integrating SHriMP with the

IBM WebSphere Studio Workbench∗

Derek Rayside and Marin LitoiuIBM Centre for Advanced Studies

IBM Toronto Laboratory{drayside, marin}@ca.ibm.com

Margaret-Anne Storey and Casey BestDepartment of Computer Science

University of Victoria{mstorey, cbest}@csr.uvic.ca

Abstract

This paper provides an experience report forresearchers who are interested in integratingtheir tools with the new IBM WebSphere Stu-dio Workbench. The Workbench (open sourceat www.eclipse.org) provides an open frame-work for building integrated development en-vironments. We report on our experienceintegrating an information visualization tool(called SHriMP Views) with the IBM Work-bench. Although SHriMP was originally de-veloped for visualizing programs, it is contentindependent. We have re-targeted SHriMP forvisualizing flow diagrams. Flow diagrams canbe hierarchically composed, thus leveraging thekey features of SHriMP that allow a user to eas-ily navigate hierarchically composed informa-tion spaces. We discuss the differences betweenprograms and flow diagrams both in terms oftheir semantics and in their visual representa-tion. Terminals, which are a first-class entitythat mediate between nodes and arcs in flowdiagrams, presented the main challenges here.We also report on the main technical challengeswe faced, due to the different widgets sets usedby SHriMP (Swing/awt) and the Workbench(swt).

Keywords: integration, software engineer-ing, software visualization, system modeling,flow diagrams, mof, xmi

∗WebSphere Studio Workbench is an IBM productbased upon technology from the Eclipse Project. Forthe purposes of this paper, the reader may considerthese terms as logically, but not legally, synonymous.

1 Introduction

Leveraging industrial tool infrastructure cansignificantly reduce the amount of effort re-quired to develop tool prototypes. At CAS-CON’99, Martin reported that it took him onlytwo weeks to build a complete C++ fact extrac-tor for Rigi [23] based on IBM’s VisualAgeC++, in contrast to the protracted effort thathad been required to build the previous factextractor [22]. Moreover, his new fact extrac-tor was more robust, easier to understand, and75% less code [22]. Leveraging industrial toolinfrastructure allows researchers to focus on re-search.

IBM’s new WebSphere Studio Workbench(based on open source technology from theEclipse Project) presents some exciting oppor-tunities for researchers who build software en-gineering tools. Eclipse is a platform of com-mon tool infrastructure, including: an xml-based plug-in architecture for interoperabil-ity; frameworks for structured text and graph-ics editing; a common debugging infrastruc-ture; and a complete Java development envi-ronment. Furthermore, because the Eclipsecore is open source, it can be modified by re-searchers and freely downloaded by researchtool users. Leveraging the Eclipse infrastruc-ture can significantly reduce the amount of ef-fort required to develop research tools.

This paper reports our experience integrat-ing a pre-release version of Eclipse with theSHriMP information visualization tool fromthe University of Victoria [26]. Specifically, wewant to use SHriMP to visualize flow diagrams.

1

Figure 1 Eclipse and SHriMP Architecture

Flow diagrams are used in an eBusinessproject to model the dynamic aspects of asystem, such as the main activities and themovement of information in a business process.The main motivation for our project is to ap-ply SHriMP’s advanced visualization featuresto flow diagrams, which may be hierarchicallycomposed.

SHriMP was originally developed for pro-gram visualization; therefore some minor mod-ifications were required to adapt it to this newdomain. One of our research objectives is totransfer knowledge from program understand-ing to flow understanding — and in the pro-cess to see if we can gain any new insights toimprove program visualization.

Figure 1 shows the architecture of ourproject and the three main foci of our integra-tion efforts. The column on the left representsSHriMP, and the column on the right repre-sents the flow diagram editor; both of thesetools are presented within the context of theEclipse infrastructure. Project application spe-cific components are shown in a darker shade ofgrey, and project independent re-usable compo-nents are shown in a lighter shade of grey. Thethree labeled, dashed lines represent the pointsof interaction between SHriMP and Eclipse:

1. represents file-based data exchange betweenthe rsf format used by SHriMP and the xml-based format used by the flow diagram tool inEclipse; 2. represents api-based data exchangebetween the flow diagram tool and SHriMP;3. represents the control and user interface in-tegration between the tools.

The mof frameworks for working with xmi-encoded data, such as flow diagrams, made themechanics of the data integration very easy.mof and xmi are described in the next sec-tion, Overview of Eclipse. Section 3 introducesflows and flow diagrams in detail. Section 4discusses the data and domain integration as-pects of rendering flow diagrams in SHriMP:these are largely connected with terminals.

We faced some interesting challenges inthe control integration because SHriMP andEclipse are based on different widget toolkits:Swing/awt and swt, respectively. swt isdescribed in more detail in the next section.We used an experimental mechanism for inte-grating tools based on these different widgettoolkits, and report our experience for the re-search community in §5 (commercial develop-ers should use the standard control integrationmechanisms, which are also described briefly).

Section 6 concludes the paper.

2

2 Overview of Eclipse

The core of IBM WebSphere Studio Workbenchis an infrastructure for building integrated de-velopment tools. The main integration mech-anism is an xml-based mechanism for defin-ing plug-ins. Plug-in’s contribute functional-ity by hooking into extension points defined byother plug-ins, and may also define new exten-sion points. The Workbench core provides allof the infrastructure necessary for the dynamicdiscovery, linking, and execution of plug-ins.

Libraries Because the Workbench is specifi-cally intended for building integrated develop-ment tools, instead of just integration in gen-eral, it also includes infrastructure for resourcemanagement, version control, and debugging.The Workbench core also includes a number ofuseful libraries:

• mof & xml Tools• sef: Source Editing Framework• gef: Graphics Editing Framework• JFace: high level user interface constructs• swt: Standard Widget Toolkit

mof and swt are discussed in more detaillater in this section. sef is a framework forbuilding editors of structured text, such as Javaprograms. gef is a framework for building ed-itors of structured graphics, such as flow dia-grams. JFace is a library of high level userinterface constructs, such as wizards, etc.

Standard Plug-ins The Workbench alsocomes with three standard sets of plug-ins:Java development tools, web developmenttools, and plug-in development tools. Each ofthese are built with the Workbench core infras-tructure, and each interoperates with the oth-ers. The Java development tools in Workbenchwill supersede the VisualAge for Java function-ality [14].

Flow Diagrams in XML Flow diagramscan be modelled with mof and serialized inxmi, as previously reported by (Litoiu, Starkey& Schmidt [19]). We intend to leverage theWorkbench infrastructure for working withmof to take advantage of Litoiu et al’s results.

2.1 Overview of MOF

mof [27] is an omg standard for describ-ing meta-models, models, and instance data.xmi [28] is an associated omg standard for se-rializing mof in xml.

Figure 2 shows the correlation between ex-pressing model information in uml, mof, andxmi. The first level of meta-modeling is m3 ormof-core. mof-core is a subset of uml andcontains definitions of Class, Attribute, Asso-ciation and so on [6, 27]. The second level ofmeta-modeling is m2 — the application domainmodel. This is the level on which most peo-ple operate when they build ordinary class di-agrams. Any m2 model is an instance of an m3

level, being constructed with instances of Class,Attribute, Association, and so on.

As an example, Author and Book may beconsidered as m2 instances of Class, and nameand title may be considered as instances of At-tribute. Author and Book are related to eachother by a relationship called Aggregation thatis an instance of m3 Association. A meta-modelfrom the m2 level can have many instances inthe m1 level. For example, Plato and Shake-speare are instances of Author; The Repub-lic and As You Like It are instances of Book.

The instance-of relation differentiates thethree levels in mof: each level instantiates thelevel above it, and conversely is instantiatedby the level below it. One of the main ad-vantages, for integration, of having an explicitmeta-model is that an api written for the meta-model can be used to work with any model thatinstantiates that meta-model and any data thatinstantiates those models.

Use of MOF in Our Project Figure 1 il-lustrates the role that mof and xmi play inour project. FlowMetaModel.xmi representsour application domain meta-model (takenfrom [19]). The Workbench infrastructure canautomatically derive a Java api for workingwith models that instantiate this meta-model.This api is named Flow Domain Model inFigure 1, and can be used to work with flowdiagrams encoded in xmi. We can use this au-tomatically generated api without knowledgeof the particular details of the xml encoding.

3

Figure 2 The relation between mof, uml, and xmi

UML MOF XMI

m3: Level 3(mof-Core)

<mof:Class ...

<mof:Attribute ...

</mof:Class ...

<mof:Association ...

m2: Level 2(ApplicationModel)

<mof:Class id="Author" ...

<Association id="publishes" ...

</mof:Class>

m1: Level 1(Application In-stance Model)

<Author name="Plato">

<Author.Publishes>

<Book title="The Republic"/>

</Author.Publishes>

</Author>

2.2 Overview of SWT

Standard Widget Toolkit (swt) is the softwarecomponent that delivers native widget func-tionality for the Eclipse platform in an operat-ing system independent manner. swt is analo-gous to Swing/awt in Java: the difference is inthe implementation strategy. swt uses nativewidgets wherever possible for three main ad-vantages: performance, look-and-feel, and de-bugging. swt-based applications always lookand perform like native applications, and anyproblems with the widgets can be directly repli-cated in C code. Another benefit of using na-tive widgets is that swt-based applications caninteract with platform specific features, such asActiveX controls in Windows.

awt follows a ‘least common denominator’strategy: it provides only those widgets thatare available on all platforms. Swing com-pensates for this by building higher-level, Javawidgets on top of awt’s least common denom-inator. So, there is only one implementation ofSwing that works across all platforms.

swt takes a different approach: it uses na-tive widgets wherever possible, and only im-plements a widget in Java if there is no na-tive version available (for example, Windowscontains a native tree widget and Motif doesnot). swt exposes the same public api to ap-plications on all platforms, but provides differ-

ent implementations for each platform. Part ofthis implementation is a shared library (e.g. adll on Windows), that exposes part of the op-erating system widget api to swt through theJava native interface (jni).

The Eclipse website contains white paperson swt [24], integrating with ActiveX andole on Windows [16], and creating new widgetswith swt [25].

Challenges for Our Project While swtprovides Eclipse with superior performanceand look-and-feel, it presents an integrationchallenge to us because SHriMP is based onSwing/awt. We describe our experience usingan experimental mechanism to integrate awt-based and swt-based applications in §6.

3 Flow Diagram Overview

There are many specific kinds of technical flowdiagrams, such as: Petri nets, data flow di-agrams [30], statecharts [12], process depen-dency diagrams [20, 21], uml activity dia-grams [6], and workflows [18, 7]. IBM pro-duces a number of middle-ware products [15]that also have specific kinds of flow diagramsassociated with them. In these products, theprogrammer, business analyst or system inte-grator, draws flow diagrams that are executed

4

Figure 3 An example flow diagram

by associated runtime environments. Theflows in these products are classified as nano-flow, micro-flow and macro-flow (also known aswork-flow) [19].

An example of micro-flow is the mqsi (Mes-sage Queue System Integrator) product, thatallows the programmer to draw message-flowdiagrams that describe the movement of databetween information systems. The associatedruntime environment executes these diagrams:i.e. combines, transforms, and delivers the mes-sages. mqsi is typically used to integrate infor-mation systems when large corporations mergewith former competitors. Much of IBM’s flowrelated middle-ware is developed in Toronto.Macro-flows use large-scale granular activitiesand are deployed by large-scale software com-ponents such as applications. Workflows prod-ucts that model and implement business pro-cesses are examples of macro-flows. Nano-flowsare flows of data and control that take placeinside an object or object method. In IBMproducts, nano-flows model and implement thewiring of Java classes into programs that ac-cess legacy applications. Nano-flow, micro-flow, and macro-flow diagrams can be modelledwith an extenstion of mof,called Flow Compo-sition Model (fcm), as was previously reportedby Litoiu et al [19]. fcm is in the process of be-coming an omg standard [11]. mof and fcmare typically serialized in the xml-based xmiformat [28]. As was discussed in the previ-

ous section, and shown in Figure 1, the Eclipseplatform provides substantial infrastructure forworking with mof models encoded in xmi.

3.1 An Example Flow Diagram

Business processes, or work-flows, are a kindof flow diagram that may be more familiarto the business analyst. Figure 3 describesa (simplified) business process for processinga credit request, involving activities such asRisk:Assess, Risk:Reassess and, eventually,Send:Money or Send:Rejection.

Figure 3c shows the main Credit Ap-proval process, which is composed of two sub-processes: Risk (Figure 3a) and Send (Fig-ure 3b). We want to use SHriMP’s advancedfeatures for visualizing these kinds of compo-sition relations. For the simplicity of the pre-sentation, the remainder of the paper will useMQSI to illustrate flow diagrams.

3.2 Flows and Programs

The relationship between flows and pro-grams has been approached from many an-gles. Researchers in program analysis, compil-ers and reverse engineering often use control-flow graphs and data-flow graphs to describecertain aspects of programs. Bohm and Ja-copini consider the relation of flow diagramsto the fundamental notion of computation in

5

their classic paper Flow Diagrams, Turing Ma-chines and Languages with only Two Forma-tion Rules [5].

Litoiu, Starkey & Schmidt consider thatthere is an analogy between flows and classes(in the object-oriented programming sense ofthe word) when modeling flows with mof [19].From their perspective, the Risk:Assess andRisk:Reassess boxes in Figure 3c representinstances of the flow Risk shown in Figure 3a.

We are interested in the relation betweenflows and programs because SHriMP was orig-inally developed for program visualization andwe are now using it for flow visualization.

3.3 Visual Presentation of Flows

One of the important characteristics of nodesin flow diagrams is that they have specific ter-minals where arcs may be attached to them.Which terminal an arc is attached to is fun-damental to the meaning of the diagram, asdiscussed below, and so these terminals mustbe explicitly represented in some fashion.

A Simple Example Figure 4 shows an ex-ample of a ‘filter’ node from the mqsi [15] floweditor with its terminals labelled. A filter nodeis a kind of primitive node that is analogousto a simple conditional test in an imperativeprogramming language.

Figure 4 A Filter Node from mqsi

Filter nodes have one input terminal and fouroutput terminals: failure, unknown, trueand false. When a message arrives at a fil-ter node, its condition is evaluated, and a mes-sage is sent from one of the output terminalsdepending on the result of the evaluation.

Other kinds of nodes may accept multipleinputs and send multiple outputs.

Terminals Have Distinct Identity Ter-minals have distinct identity: that is, they can-not be identified with arcs as arrowheads can,

nor can they be subsumed by the nodes theyare attached to. Terminals are different thanarrowheads in two ways: terminals are stillpresent on a node even if there are no arcs con-nected to them; and multiple arcs may be con-nected into a single terminal.

4 Integration with Flows

This project also involved a fair amount of dataand domain integration, as well as the controlintegration discussed in the next section. Theterminals on nodes posed the main challengefor both data and domain integration. Since itis easier to understand some of the issues byfirst seeing the ‘whole picture’, so to speak, wewill first show screen-captures of our workingprototype and then discuss the details. Butfirst, a brief background on SHriMP.

SHriMP The SHriMP (Simple HierarchicalMulti-Perspective) visualization technique wasdesigned to enhance how people browse andexplore complex information spaces. It wasoriginally designed to enhance how program-mers understand programs [31, 33]. SHriMPpresents a nested graph view of a software ar-chitecture. Program source code and docu-mentation are presented by embedding markedup text fragments within the nodes of anested graph. Finer connections among thesefragments are represented by a network thatis navigated using a hypertext link-followingmetaphor. SHriMP combines this hypertextmetaphor with animated panning and zoom-ing motions over the nested graph to providecontinuous orientation and contextual cues forthe user.

SHriMP’s advanced visualization features,namely its smooth zooming capabilities withina nested graph and advanced layout algo-rithms, provide us with an opportunity to re-examine some of the visual conventions used inthe current flow diagram browser/editor.

4.1 Rendering Flows in SHriMP

The top picture of Figure 5 showsSHriMP rendering the simple flow dia-gram multi1.messageflow inside the Eclipse

6

Workbench (multi1.messageflow is encodedin xmi using the mof frameworks discussedpreviously). The diagram has three nodes:Input (top-left), Output (top-right) andDataUpdate (bottom-centre). The Inputnode has one output terminal (green); theOutput has one input terminal (blue); theDataUpdate node has three terminals: input(blue), regular output (green), and erroroutput (red). Some of the important visualfeatures of the flow diagram rendered in thetop picture of Figure 5 are:

• nodes are represented by images

• terminals are represented by images

• terminals are colour-coded

• arcs are connected to terminals

• some terminals have no arcs attached

• some terminals have > 1 arc attached

• terminals are placed to reduce arc length

All of these visual features have had some im-pact on the data and domain integration effort.Some of these features differ from how flow di-agrams are rendered in mqsi: for example, vi-sually differentiated terminals (colour-coding)and terminals automatically placed to reducearc length.

Nested Interchangeable Views One of thekey features of SHriMP is its ability to shownested interchangeable views. This featuremeans that there are different views possible fornodes at different levels in the hierarchy. Thisfeature is illustrated in Figures 5 and 6. Fig-ure 5 simulates the user ‘opening’ up and zoom-ing in on the DataUpdate node, which showsan html table of the node’s property/valuepairs. Similarly, in Figure 6, the SubFlownode can be viewed as closed, or it can beopened so that the user can interact with andexplore the subflow. The nested interchange-able view mechanism more easily allows usersto explore information at the required levels ofdetail to suit different needs and tasks.

Hierarchical Composition Figure 6 illus-trates the main motivation for our project:to visualize hierarchically composed flow dia-grams. The main flow diagram has three nodes:

Input, Output and SubFlow. Figure 6 sim-ulates the user opening up the SubFlow nodeand zooming in to see that it is also composedof three nodes: Input, Output and Filter.

4.2 Data Integration

Our project had two data integration aspects ofnote: reading the flow diagrams from the xmi-based format and representing flow diagramswithin SHriMP’s data-model. The former taskwas fairly straightforward given the mof frame-works in WebSphere Studio Workbench; thelatter task required substantially more work.

SHriMP uses a graph-based data-model, sim-ilar to the one embodied by rsf [23] or gxl [13].This kind of data-model is not particularly wellsuited to the concept of terminals, because ter-minals are a new kind of first-class entity thatmediate between arcs and nodes.

It would be possible to create a new data-model that explicitly incorporates the notionof terminals. However, such an approach wouldhave required a substantial programming effortgiven SHriMP’s existing code-base, as we wouldhave had to completely replace its data-model.We think that this approach would be worthinvestigating if one was writing a program todeal with flow diagrams from scratch.

There are two main possibilities for rep-resenting terminals within SHriMP’s existingdata-model: as distinct nodes, or as attributeson existing nodes and arcs. We tried both ap-proaches, and our experience was that the lat-ter required less overall effort.

Representing terminals as attributes on ex-isting nodes and arcs requires adding two at-tributes to every arc (source terminal and tar-get terminal), as well as n attributes to everynode, where n is the number of terminals onthat node. The attributes on nodes are nec-essary to ensure that terminals with no arcsattached to them are represented. In practicewe used 2n attributes on every node: the sec-ond attribute indicates the image to use for theterminal.

Model-View-Controller (mvc) SHriMPmay be considered from the standpoint of thewell-known model-view-controller architecture.The discussion above describes the changes we

7

Figure 5 Screen-capture of SHriMP rendering a flow diagram inside Eclipse

8

Figure 6 SHriMP zooming in on a hierarchically composed flow diagram

made to the model. However, to render thediagram properly the view has to interpretthe attributes pertaining to terminals in aspecial fashion. Note that other attributes aresimply regarded as arbitrary strings associatedwith the nodes or arcs, and have no specialimplications for the view. While it was notdifficult to change the view to interpret theterminal-related attributes, it obviously re-quired introducing special cases, which alwayscomplicates code over the long-term. Thisis one of the reasons that designing a newdata-model to explicitly incorporate terminalsis an idea worth investigating.

Two Views Typically the view, in the mvcsense of the word, consists of the set of objectsmanipulated by the gui. SHriMP’s advancedzooming features, however, require that it havetwo views in order to render an image on thescreen: one for Swing (i.e. the ‘normal’ view),and one for the zooming library Jazz (i.e. the‘extra’ view). In other words, both Swing andJazz maintain their own set of objects repre-senting the visual elements on the screen.

The distinction between these two views isimportant for a variety of reasons; in our par-ticular context, each view deals with terminalsdifferently. In the Swing view, terminals are

first-class entities: that is, there is a Swingobject associated with every terminal. ThisSwing object is necessary to render the ter-minal. However, terminals are not representedin the Jazz view because they zoom with thenodes that they are attached to.

Terminals are the only things that aretreated differently by the Swing and Jazzviews: nodes and arcs are explicitly representedin both views. This subtle issue was one of themost important things in actually getting theterminals to display and zoom properly.

5 Integration with Eclipse

The Eclipse platform is designed to facilitatetool integration, both between a tool and theWorkbench, and between tools. The details ofintegration are specified in a plugin.xml file,which describes how one tool ‘plugs-in’ to theextension points of another tool, and what li-braries it depends on, etc. The entire Work-bench is built using this plug-in architecture.

Since this plug-in architecture is one of themain features of Eclipse, it is well documentedin the technical documentation as well as ina number of introductory articles on Eclipse,such as [2]. The focus of this paper is to report

9

aspects of our experience that are not docu-mented elsewhere. We have used an experimen-tal, undocumented mechanism for seamless in-terface integration of Swing-based tools withthe Workbench, and the majority of this sec-tion discusses our experience with this mecha-nism. First a summary of different mechanismsof integration in Eclipse is provided.

5.1 Control & UI Integration

Control and user interface integration of toolssuch as SHriMP with the Workbench can bepursued independently of other aspects of inte-gration, such as data integration. The reasonis that both SHriMP and the Workbench arefairly content independent: each tool can beused for a wide variety of data. In our project,we actually worked on the control and user in-terface integration before working on the dataintegration.

The Workbench can integrate with toolsbased on four different user interface technolo-gies [1]: swt, Swing, ole, and other (i.e.launching an external tool in a separate win-dow and process). swt is the tightest interfaceintegration and arbitrary external tool integra-tion is the loosest form of integration. Moredetails on the various integration mechanismsare given below.

SWT-Based Tools Java tools based on theswt can run in-place within the Workbench:that is, they are visually indistinguishable fromthe built in tools. These tools also run in-process: that is, within the same vm and classlibraries as the Workbench itself. These toolscan achieve seamless functional integration ifthe Workbench api’s are used.

In-place Java tools can also use ActiveXcontrols (on Windows only). Eclipse providesa mechanism for using ActiveX controls fromwithin the Java code [16].

This is the tightest and most seamless formof interface integration.

External Tools Any tool written in any lan-guage can be launched from the Workbenchwith its own separate process. These tools openas separate windows and are not visually in-tegrated with the Workbench. The platform

provides automatic launching of external edi-tors based on file type associations provided tothe Workbench or obtained from the underly-ing operating system.

This is the loosest form of integration.

OLE-based Tools On the Windows plat-form, ole-based tools can be run in-place.These tools appear to be tightly integratedwith the Workbench, but functionally they arethe same as any external-launch tool: all theydo is open on an artifact, edit it, and save it.

Swing-based Tools Swing-based tools canbe integrated with the Workbench interfacein two ways: in a separate window or withinthe Workbench. If the Swing-based tool islaunched in a separate window, it appears tothe user much the same as any external toolwould. One important technical difference isthat arbitrary external tools launch in a sep-arate process, whereas Swing-based tools canrun within the same vm and class libraries asthe Workbench.

There is an experimental mechanism for run-ning Swing-based tools in-place within theWorkbench, but its use is not officially sup-ported at this time. We have experimentedwith this mechanism and report on our expe-rience here for the research community. Com-mercial tool developers, or anyone else requir-ing officially supported functionality, shouldrun Swing-based tools in a separate window.

The main restrictions on this experimentalmechanism are [17]:

• It only works on Windows.

• The keyboard doesn’t work for all widgets.

• There may be possible deadlock problems.

• The api is internal and subject to change.

The experimental mechanism is basicallyjust the new Panel method in the class:org.eclipse.swt.internal.awt.win32.SWT AWT.The new Panel method has one parameter, answt Composite object, and it returns an awtPanel object. The awt Panel is containedwithin the swt Composite, and is constructedusing a WEmbeddedFrame (from Sun’s internalpackage sun.awt.windows).

10

5.2 Our Experience with Swing/SWT Interaction

We have experienced three main problemswith this rudimentary Swing/swt integrationmechanism: keyboard events do not work forcertain widgets, some complicated repaint op-erations do not work reliably, and there aresome issues in the interaction of the Swingand swt event queues. The keyboard prob-lem is known to the Eclipse developers, and weare currently waiting for more information fromthem.

The repaint problems that we have expe-rienced are related to SHriMP’s ‘hot-box’ or‘control-box’ feature. The control-box is a userinterface feature similar to context sensitiveright mouse-button menus. There are two dif-ferences: the control-box is a group of wid-gets that is not limited to a menu, and it isrequested by holding down the control key in-stead of pressing the right mouse button. (InSHriMP, the right mouse button is used tocontrol the animated zooming feature.) Theproblem is that the control-box is drawn overtop of the main window (rather than in it),and so sometimes one (or part of one) getspainted rather than the other. SHriMP issuesrepaint events for the control-box as long as theuser has the control key pressed, so the displaychanges with time as well as with mouse move-ment. We are investigating the Swing mecha-nism that SHriMP uses to display the control-box, and hope to find out how to work aroundthis problem.

We have successfully resolved some of theissues involved in working with two interfaceevent dispatching queues (Swing and swt).The execution of any widget toolkit is con-trolled by an event queue: the operating systemadds events to the queue as the user manipu-lates the machine (i.e. moves the mouse, pressesa key, etc); the dispatching loop pops eventsoff the front of the queue and executes them.Sometimes it is important to ensure that cer-tain events happen in a certain order, or thatsome computation is performed before or aftercertain interface events. For example, an in-cremental progress bar requires that the userinterface is periodically updated while a com-putation proceeds.

Swing provides two methods in theSwingUtilities class for the program-mer to specify such temporal ordering:invokeLater() and invokeAndWait(). Bothmethods take a parameter of type Runnablethat contains the code to be executed in theevent dispatching thread. invokeLater()places the Runnable at the end of the eventqueue and returns immediately (i.e., it makesan asynchronous request). invokeAndWait()is a synchronous request: it blocks the re-questing thread until the Runnable has beenexecuted in the event dispatching thread.swt provides two equivalent methods in theDisplay class: asyncExec() and syncExec().

The first thing that SHriMP does when itopens a graph is to focus on a specific node(usually the root). Focusing on a node entailspanning and zooming the display: i.e. program-matic manipulation of the interface. This pro-grammatic manipulation of the graph displaycannot occur until the graph is actually dis-played because all of the visual elements needto have positions and sizes before those at-tributes can be manipulated. When executingSHriMP within its own vm, the programmaticmanipulation is deferred until after the graphis displayed using the invokeLater() methodas shown by the code snippet in Figure 7.

Figure 7 Defer focus event (Swing)SwingUtilities.invokeLater(

new FocusOnRoots(_shrimpView)

);

However, when running SHriMP inside theWorkbench, the initial rendering of the graphdoes not occur until the swt Composite thatcontains SHriMP is initialized. This whole pro-cess is triggered by an SWT.Resize event thatgives the Composite its initial size; which, inturn, resizes the awt Panel it contains; thiscauses the SHriMP graph to be displayed forthe first time. So, for things to work properlythe order of events must be: SWT.Resize, ini-tial rendering of SHriMP graph, focus on initialnode (the programmatic manipulation of thegraph). Both the swt method asyncExec()and the Swing method invokeLater() mustbe used to accomplish this order, as detailed by

11

Figure 8 Defer focus event (Swing in swt)Display display = Display.getCurrent();

display.asyncExec(new Runnable() {

public void run() {

SwingUtilities.invokeLater(

new FocusOnRoots(_shrimpView));

}

});

the code snippet in Figure 8.The code in Figure 8 essentially says the

following: after all swt interface events havebeen processed (i.e. including the SWT.Resize),place a FocusOnRoots event at the end of theSwing event queue.

Blocking the SWT UI from a Swing Di-alog Box Another event queue interactionwork-around has been described on the EclipseCorner Newsgroup [32]; we report it here as itmay be of interest to the reader, although wehaven’t had to use this technique as of yet.

The objective is to launch a Swing dialogbox from within an swt based application, andto block the swt execution until the user dis-misses the Swing dialog box. The solutiongiven in [32] is to use a boolean object to com-municate between the swt application threadand the Swing dialog box thread. A code snip-pet detailing this solution is given in Figure 9.

6 Discussion

This paper documents our experience inte-grating SHriMP, an information visualizationtool, with IBM’s WebSphere Studio Work-bench, which is based on open source technol-ogy from the Eclipse Project. Our work in-volved control, data, and domain integration.

Control Integration From the control per-spective, we integrated SHriMP with Eclipseby transforming SHriMP into an Eclipse plug-in. The creation of a plugin is straight-forward:Eclipse provides full support for developing,testing and debugging.

One of the main technical challenges wasintegrating Swing/awt-based SHriMP with

Figure 9 Swing Dialog blocking swt uiimport javax.swing.JOptionPane;

import org.eclipse.swt.widgets.Display;

// flag for inter-thread communication

final boolean[] done = new boolean[1];

// create new thread for Swing dialog box

new Thread() {

public void run() {

JOptionPane.showMessageDialog(

null, "alert", "alert",

JOptionPane.ERROR_MESSAGE);

done[0] = true;

}

}.start();

// wait for the Swing thread to finish task

while (!done[0]) {

Display display = Display.getCurrent();

if (!display.readAndDispatch())

display.sleep();

}

swt-based Eclipse. We reported our experi-ence using an experimental mechanism for in-tegrating programs written in these differentgui frameworks, including some problems withrepaint events, keyboard events, and thread in-teraction. Researchers and other prototype de-velopers with existing Swing-based code maybe interested in trying this experimental mech-anism, despite its limitations. Commercial tooldevelopers should use the standard, supportedmechanisms for better performance and moreconsistent look-and-feel.

Data and Domain Integration Terminalswere the main challenge for the data anddomain integration aspects of our project.Throughout the paper we discussed terminalsin the context of mqsi-style message-flow dia-grams, but the issues generalize to other kindsof flow diagrams.

SHriMP’s data-model is very similar torsf [23] and gxl [13], all of which are based onthe idea of a graph composed of nodes and arcs.These data-models are not designed to dealwith terminals, which are another kind of first-class entity that mediates between nodes andarcs. We tried two approaches for expressingterminals within SHriMP’s data-model, andreported the implications that this had forSHriMP’s model-view-controller (mvc) archi-

12

tecture. The easiest part of the data inte-gration was reading the xmi-encoded flow di-agrams with the mof frameworks.

SHriMP’s advanced visualization featuresprompted us to render flow diagrams differentlyin SHriMP than is done mqsi. We discussedthese changes with ucd and flow compositionspecialists at IBM.

6.1 Conclusions

We have drawn three main conclusions fromour experience:

First, we confirm Martin’s findings [22] thatleveraging industrial tool infrastructure cansignificantly reduce the amount of effort re-quired to develop tool prototypes. In ourcase, the mof frameworks essentially elimi-nated most of the mechanics of the data in-tegration work, and let us focus on more inter-esting problems.

Second, tight ui integration between Swing-based tools and swt-based Eclipse seems pos-sible, but there are some important limitations.Loose ui integration with Swing-based tools isfully supported, as is tight ui integration withswt-based tools. SHriMP’s advanced visual-ization features made this part of the projectmore difficult than it might be for other tools.

Third, terminals seem to be a very useful andnatural concept, and they should be better sup-ported by exchange formats such as gxl [13].

6.2 Future Work

Our anticipated future work involves adaptingSHriMP to new data domains within Eclipse,and applying the idea of terminals to programvisualization.

New Domains The two domains that weare most interested in are mof and Java. Flowdiagrams are one example of data that may bemodeled in mof (using the fcm framework).However, mof can be used for modeling inmany other domains. We hope to generalizethe work presented in this paper to visualizeany mof-based models.

Eclipse also includes a full Java developmentenvironment, and we would like to integrateSHriMP into this environment for visualizing

Java programs. SHriMP has already been usedto visualize Java programs, but we would like tobuild a new fact extractor that performs somestatic analysis of polymorphic method invoca-tions (such as Class Hierarchy Analysis [9, 10]and Rapid Type Analysis [3, 4]). Determiningthe targets of polymorphic method invocationsis one of the most important tasks in under-standing object-oriented programs, and thereis relatively little support for it in most pro-gram understanding tools.

Using Terminals for Program Visualiza-tion We think that the idea of terminalspresents an opportunity to add extra visualsemantics to the standard box-and-arrow di-agrams used by many program visualizationtools (such as SHriMP). We are not aware ofany current program understanding tool thatuses terminals.

One simple possibility is to use terminals tocategorize arcs: e.g. there could be a terminalfor data related arcs and another for control re-lated arcs. In flow diagrams terminals have se-mantics that are independent of the kind of arcsconnected to them. One way to use terminalsand retain this independence in program visu-alization is to have terminals representing nor-mal and exceptional exit paths, as is done withfilter nodes in flow diagrams (see Figure 4).

Acknowledgements

We thank Grant Taylor, Mike Beltzner, andEvan Mamas at the IBM Toronto Laboratoryfor their time and assistance. Participantson the Eclipse Corner Newsgroup have alsobeen helpful, especially: Greg Adams, VeronikaIrvine, Jeff McAffer, David Whiteman, andMike Wilson.

About the Authors

Derek Rayside: Derek has just completedhis MASc (Master of Applied Science) in Elec-trical & Computer Engineering at the Univer-sity of Waterloo under the supervision of Pro-fessor Kostas Kontogiannis. Derek’s BASc isalso from the University of Waterloo, in Sys-tems Design Engineering. This year Derek is

13

pursuing an MA at the University of Toronto’sInstitute for the History and Philosophy of Sci-ence and Technology. He expects to earn a PhDin computer science after the MA.

Derek also intends to leverage Eclipseto build a prototype of a Java programbrowser designed for understanding polymor-phic method invocations [29].

Marin Litoiu: Marin is a Research Asso-ciate at the IBM Centre for Advanced Stud-ies in the IBM Toronto Laboratory. Marinholds two PhD degrees: Systems and Com-puter Engineering (Carleton University, 1999);and Control Systems (University Politechnicaof Bucharest, 1995). He has been with IBMsince 1997, where he held leading roles in thedesign of middleware tools for technologies suchas rmi, iiop and MQSeries. Prior to joiningIBM, he was a faculty with the Departmentof Computers and Control Systems of the upband held research visiting positions with Poly-technic of Turin, Italy and Polytechnic Univer-sity of Catalunia (Spain), European Centre forParallelism.

Margaret-Anne Storey: Dr. Margaret-Anne (Peggy) Storey is currently a visitingprofessor at the Department of Aeronauticsand Astronautics at MIT, on leave from theDepartment of Computer Science at the Uni-versity of Victoria. She is a fellow of theBritish Columbia Advanced Systems Institute(asi) and collaborates with IBM on Human-Computer Interaction and eBusiness. She isone of the investigators for cser (Centre forSoftware Engineering Research) developing andevaluating software migration technology andan adjunct research scientist at the New MediaInnovation Centre in Vancouver, BC. Her re-search interests include experimental softwareengineering, program understanding, human-computer interaction, information visualiza-tion, eCommerce and graph drawing.

Casey Best: Casey is a MSc student withProfessor Margaret-Anne Storey at the Univer-sity of Victoria. Casey is currently the chiefprogrammer on the SHriMP project.

References

[1] Greg Adams. External tool interoperabil-ity. Eclipse Corner Newsgroup, June 2001.

[2] Jim Amsden. Your First Plug-In. EclipseCorner Article, June 2001.

[3] David F. Bacon. Fast and EffectiveOptimization of Statically Typed Object-Oriented Languages. PhD thesis, Uni-versity of California at Berkeley, Decem-ber 1997. Supervised by Susan Graham.UCB/CSD-98-1017.

[4] David F. Bacon and Peter F. Sweeney.Fast static analysis of C++ virtual func-tion calls. In Coplien [8], pages 324 – 341.

[5] C. Bohm and G. Jacopini. Flow diagrams,turing machines and languages with onlytwo formation rules. CACM, 9(5):366–371,May 1966. Reprinted in [34].

[6] G. Booch, J. Rumbaugh, and I. Jacobson.The Unified Modeling Language — UserGuide. Addison-Wesley, 1999.

[7] F. Casatti, S. Ceri, B. Pernici, andG. Pozzi. Conceptual modeling of work-flows. In Advances in Object-OrientedData Modeling. MIT Press, 2000.

[8] James Coplien, editor. Proceedings ofACM/SIGPLAN Conference on Object-Oriented Systems, Languages and Appli-cations (OOPSLA), San Jose, California,October 1996.

[9] Jeffrey Dean, David Grove, and CraigChambers. Optimization of object-oriented programs using static class hi-erarchy analysis. In W. Olthoff, edi-tor, ECOOP’95, Arhus, Denmark, August1995. Springer-Verlag. LNCS 952.

[10] Amer Diwan, J. Eliot B. Moss, andKathryn S. McKinley. Simple and effectiveanalysis of statically-typed object-orientedprograms. In Coplien [8], pages 292–305.

[11] Object Managment Group. Flow composi-tion model. ftp://ftp.omg.org/pub/docs/ad/01-06-09.pdf.

14

[12] D. Harel and E. Gery. Executable objectmodeling with statecharts. IEEE Com-puter, 30(7):31–42, 1997.

[13] R. Holt, A. Winter, A. Schrr, and S. Sim.GXL: Towards a Standard Exchange For-mat. In Cristina Cifuentes, Kostas Kon-togiannis, and Francoise Balmas, editors,WCRE’00, Brisbane, Australia, November2000.

[14] IBM. FAQ about IBM’s new toolingstrategy and the future of VisualAge forJava. http://www7.software.ibm.com/vad.nsf/data/document2020.

[15] IBM. MQSI: Message Queue System Inte-grator. http://www-4.ibm.com/software/ts/mqseries/.

[16] Veronika Irvine. ActiveX Support inSWT. Eclipse Corner Article, March 2001.

[17] Veronika Irvine. Limitations ofSwing/SWT experimental integrationmechansim. Eclipse Corner Newsgroup,July 2001.

[18] F. Leyman and D. Roller. Work-flowbased applications. IBM Systems Journal,36(1):102–122, 1997.

[19] M. Litoiu, M. Starkey, and M.T. Schmidt.Flow composition modeling with mof. InProceedings of ICEIS’01, Setubal, July2001.

[20] J. Martin. Information Engineering BookIII: Design and Construction. Prentice-Hall, 1989.

[21] J. Martin and J. Odell. Object-OrientedAnalysis and Design. Prentice-Hall, 1992.

[22] Johannes Martin. Leveraging IBM Vi-sualAge for C++ for Reverse Engineer-ing Tasks. In Stephen A. MacKay andJ. Howard Johnson, editors, CASCON’99,pages 83–95, Toronto, November 1999.

[23] H.A. Muller and K. Klashinsky. Rigi — Asystem for programming-in-the-large. InICSE’88, pages 80–86, Raffles City, Singa-pore, April 1988.

[24] Steve Northover. SWT: The StandardWidget Toolkit. Eclipse Corner Article,March 2001.

[25] Steve Northover and Carolyn MacLeod.Creating Your Own Widgets using SWT.Eclipse Corner Article, March 2001.

[26] University of Victoria. Shrimp views visu-alization tool.

[27] Object Managment Group (OMG). Metaobject facility, 2000. http://www.omg.org.

[28] Object Managment Group (OMG).Xml metadata interchange (xmi), 2000.http://www.omg.org.

[29] Derek Rayside and Kostas Kontogiannis.On the Syllogistic Structure of Object-Oriented Programming. In Hausi Muller,Mary-Jean Harrold, and Willhelm Shafer,editors, ICSE’01, pages 113–122, Toronto,Canada, May 2001.

[30] D. Ross. Structured Analysis (SA): Alanguage for communicating ideas. IEEETransactions on Software Engineering,3(1):16–36, 1977.

[31] M.-A. Storey, H.A. Muller, and K. Wong.Manipulating and Documenting SoftwareStructures, pages 244–263. World Scien-tific Publishing Co., November 1996. Vol-ume 7 of the Series on Software Engineer-ing and Knowledge Engineering.

[32] Mike Wilson. Blocking SWT from a Swingdialog box. Eclipse Corner Newsgroup,July 2001.

[33] J. Wu and M.-A. Storey. A multi-perspective software visualization environ-ment. In CASCON’00, pages 41–50,Toronto, November 2000.

[34] Edward Nash Yourdon, editor. Classicsin Software Engineering. Yourdon Press,1979.

15