designing a component-based framework
DESCRIPTION
Designing a Component-Based Framework for A Domain Independent Visualization ToolTRANSCRIPT
Designing a Component-Based Framework for A Domain Independent Visualization Tool
by
Casey Best B.Sc., University of Victoria, 2000
A Thesis Submitted in Partial Fulfillment of the Requirements for the Degree of
MASTER OF SCIENCE
in the Department of Computer Science
We accept this thesis as conforming to the requested standard
Dr. Margaret-Anne Storey, Supervisor (Department of Computer Science) Dr. Jens Jahnke, Department Member (Department of Computer Science) Dr. Issa Traoré, Outside Member (Department of Electrical and Computer Engineering) Dr. Kin Li, External Examiner (Department of Electrical and Computer Engineering)
© Casey Best, 2002 University of Victoria
All rights reserved. This work may not be reproduced in whole or in part,
by photocopy or other means, without the permission of the author.
ii
Supervisor: Dr. Margaret-Anne Storey ABSTRACT
Often programmers must use several tools to support a software development
process. Each tool may assist the developer by automating one or more tasks in the
process. Unfortunately these tools often lack the ability to be integrated with other tools,
and thus become obsolete before they should. Also tool designers have to make many
decisions that ultimately decide the fate of their tool. For example, most tools are
designed for a specific task in a specific domain. If the designer does not create an
architecture that is extensible, opportunities to use the tool in other domains can be
missed. Unfortunately, many software engineering tools lack the ability to be integrated
with other tools. This is particularly true of research tools as they tend to be developed in
an ad hoc way. One such research tool, called SHriMP (Simple Hierarchical Multiple
Perspective) Views, also suffered from these problems. In this thesis, we examine how
we reengineered the SHriMP software visualization tool into a component-based domain
independent visualization framework. Before this reengineering effort, we were unable
to integrate SHriMP with other software engineering tools or use its visualizations for
other purposes. This limited our ability to evaluate SHriMP’s effectiveness when used
as part of a larger process. We show through two case studies how the resulting
framework enabled SHriMP to be easily integrated with other tools and furthermore how
it could be customized to provide visualization features for other domains. Lessons learnt
through this reengineering case study should also be of value to other tool designers.
iii
Examiners: Dr. Margaret-Anne Storey, Supervisor (Department of Computer Science)
Dr. Jens Jahnke, Department Member (Department of Computer Science)
Dr. Issa Traoré, Outside Member (Department of Electric and Computer Engineering)
Dr. Kin Li, External Examiner (Department of Electrical and Computer Engineering)
iv
Table of Contents
ABSTRACT ...................................................................................................................... II TABLE OF CONTENTS................................................................................................IV LIST OF TABLES ..........................................................................................................VI LIST OF FIGURES ...................................................................................................... VII ACKNOWLEDGEMENTS........................................................................................ VIII DEDICATION.................................................................................................................IX INTRODUCTION............................................................................................................. 1 BACKGROUND................................................................................................................ 4
2.1 SOFTWARE REENGINEERING ...................................................................................... 4 2.2 BACKGROUND ON TOOL INTEROPERABILITY.............................................................. 5
2.2.1 Data Integration................................................................................................. 6 2.2.2 Control Integration ............................................................................................ 6 2.2.3 Presentation Integration .................................................................................... 6 2.2.4 Process Integration ............................................................................................ 8
2.3 COMPONENT-BASED FRAMEWORKS........................................................................... 9 2.4 JAVA BEANS............................................................................................................. 12 2.3 SUMMARY ................................................................................................................ 14
SHRIMP VIEWS ............................................................................................................ 16 3.1 GRAPH VISUALIZATION............................................................................................ 16 3.2 SHRIMP................................................................................................................... 17 3.3 OLD ARCHITECTURE ................................................................................................ 22 3.4 REQUIREMENTS FOR THE NEW ARCHITECTURE........................................................ 26 3.5 SUMMARY ................................................................................................................ 28
REENGINEERING CASE STUDY: SHRIMP............................................................ 29 4.1 REENGINEERING PROCESS........................................................................................ 29
4.1.1 Reengineering Limitations and Solutions ........................................................ 29 4.1.2 Design and Development Process.................................................................... 31
4.2 THE NEW ARCHITECTURE ........................................................................................ 38 4.2.1 Data Bean......................................................................................................... 39 4.2.2 Persistent Storage Bean ................................................................................... 39 4.2.3 Display Bean .................................................................................................... 40 4.2.4 Selector Bean.................................................................................................... 40 4.2.5 Filter Bean........................................................................................................ 41
v
4.2.6 History Bean..................................................................................................... 41 4.2.7 Search Bean...................................................................................................... 42 4.2.8 HotBox Bean .................................................................................................... 42 4.2.9 Adapters ........................................................................................................... 43
4.3 SUMMARY ................................................................................................................ 44 EVALUATING THE FRAMEWORK: CASE STUDIES .......................................... 45
5.1 JAMBALAYA (SHRIMP AND PROTÉGÉ INTEGRATION).............................................. 45 5.1.1 The Protégé Management Tool ........................................................................ 46 5.1.2 Integration of Protégé and SHriMP................................................................. 48 5.1.3 Jambalaya Integration – Some Technical Details ........................................... 49
5.2 INTEGRATING SHRIMP WITH ECLIPSE ..................................................................... 52 5.2.1 Eclipse .............................................................................................................. 52 5.2.2 Integration of Eclipse and SHriMP.................................................................. 54 5.2.3 Eclipse Integration - Some Technical Details.................................................. 55
5.3 SUMMARY ................................................................................................................ 58 LESSONS LEARNT ....................................................................................................... 59
6.1 EXPERIENCES WITH JAVA BEANS ............................................................................. 59 6.1.1 Java Beans........................................................................................................ 60 6.1.2 Design and Implementation Lessons................................................................ 62
6.2 EXPERIENCES WITH TOOL INTEGRATIONS ................................................................ 67 6.2.1 Data Integration............................................................................................... 67 6.2.2 Control Integration .......................................................................................... 69 6.2.3 Presentation Integration .................................................................................. 70 6.2.4 Process Integration .......................................................................................... 71
6.3 SUMMARY ................................................................................................................ 73 CONTRIBUTIONS, RELATED WORK, AND FUTURE WORK ........................... 74
7.1 CONTRIBUTIONS....................................................................................................... 74 7.1.1 Reengineering Approach.................................................................................. 75 7.1.2 Component-Based Frameworks ....................................................................... 76 7.1.3 An Implementation of a Visualization Framework .......................................... 76 7.1.4 Strategies for Tool Integrations ....................................................................... 76
7.2 RELATED WORK....................................................................................................... 77 7.2.1 Field ................................................................................................................. 77 7.2.2 GSEE .................................................................................................................. 78
7.3 FUTURE WORK......................................................................................................... 79 7.3.1 Plug-in Extension for the SHriMP Framework................................................ 79 7.3.2 Future Projects................................................................................................. 80
7.4 CONCLUSION............................................................................................................ 82 BIBLIOGRAPHY ........................................................................................................... 85 APPENDIX A – HOW TO INTEGRATE WITH SHRIMP....................................... 91 APPENDIX B – COLLABORATION DIAGRAMS ................................................... 94
vi
List of Tables TABLE 1: THE CORE USE CASES USED TO DESIGN THE NEW ARCHITECTURE........................ 34
vii
List of Figures FIGURE 1: THE BEAN BOX, A VISUAL BUILDER USED TO CREATE APPLICATIONS FROM JAVA
BEANS. ....................................................................................................................... 14 FIGURE 2: THE HANGMAN PROGRAM VISUALIZED BY SHRIMP. ......................................... 18 FIGURE 3: SHRIMP USES SHADES OF COLOUR TO INDICATE THE NODE IS OPENED/CLOSED.19 FIGURE 4: AN EXAMPLE OF MAGNIFY ZOOMING (A), FISHEYE ZOOMING (B), AND SIMPLE
ZOOMING (C) ON/TOWARDS THE CONTROL NODE....................................................... 21 FIGURE 5: THE HOTBOX IS USED TO PROVIDE QUICK ACCESS TO COMMON COMMANDS...... 22 FIGURE 6: THE OLD ARCHITECTURE HAD INFORMATION ABOUT A SINGLE NODE IN 2 DATA
STRUCTURES AND 12 CLASSES.................................................................................... 24 FIGURE 7: THE COLLABORATION DIAGRAM FOR THE USE CASE OF MAGNIFYING ON A NODE.
................................................................................................................................... 36 FIGURE 8: THE NEW ARCHITECTURE CONTAINS COMPONENTS (BOXES) AND ADAPTERS
(ARROWS)................................................................................................................... 38 FIGURE 9: THE HOTBOX IS OPENED OVER THE NODE “FRED SCHMIT”. THE DISPLAY
BUTTON HAS A SUB-MENU TO DISPLAY CONTEXT SENSITIVE OPTIONS FOR THIS NODE.42 FIGURE 10: THIS VIEW SHOWS THE HIERARCHICAL VIEW (LEFT SIDE) WITH PROTÉGÉ........ 43 FIGURE 11: THIS VIEW SHOWS THE ONTOLOGY EDITING ENVIRONMENT IN PROTÉGÉ. ....... 46 FIGURE 12: A SAMPLE PROJECT IN PROTÉGÉ...................................................................... 47 FIGURE 13: TWO INTEGRATION METHODS OF PROTÉGÉ. (LEFT) THE EXTERNAL PROGRAM
IS EMBEDDED IN PROTÉGÉ. (RIGHT) THE EXTERNAL PROGRAM VISUALIZES PROTÉGÉ’S DATA WITHOUT THE PROTÉGÉ USER INTERFACE. .................................... 48
FIGURE 14 AN EXAMPLE OF A WORK FLOW DIAGRAM IN WSMQI. WSMQI USES TERMINALS ON NODES TO REPRESENT INPUT/OUTPUT LINKS TO THE REST OF THE SYSTEM. ..................................................................................................................... 53
FIGURE 15: THE STRUCTURE OF SYSTEM RESULTING FROM THE ECLIPSE/SHRIMP INTEGRATION. ............................................................................................................ 55
FIGURE 16: (LEFT) THE HIERARCHY USING CONTAINS AS THE CHILD-PARENT RELATIONSHIP.................................................................................................................................... 63
FIGURE 17: ILLUSTRATES HOW THE DEFAULTDATABEAN INTERACTS WITH THE SYSTEM.. 64 FIGURE 18: THE 3 LEVELS OF DATA INTEGRATION DEVELOPERS CAN USE TO INTEGRATE
APPLICATIONS WITH SHRIMP. ................................................................................... 68
viii
Acknowledgements
This research was supported in part by CSER, NSERC, IBM, Stanford University, the
University of Victoria, the University of Texas at Austin and the Space and Naval
Warfare Systems Center San Diego. The content of the information does not necessarily
reflect the position or the policy of any of the universities nor the US or Canadian and no
official endorsement should be inferred. Special thanks to all the development teams
involved with the third party integrations (especially Derek Rayside), and to the SHriMP
development team (especially Jeff Michaud, Rob Lintern, Polly Allen, Yiling Lu, Jingwei
Wu, and Anton An). I would also like to thank Xiaomin Wu, David Perrin, Dr. Jens
Jahnke, and Dr. Issa Traoré for providing edits and feedback. Furthermore I would like
to thank my parents, Deb and Eric Best, for 6 years of support and encouragement, and
my wife, Alex Best, for her undying love and patience. Last (but definitely not least), a
special thanks to my supervisor, Dr. Margaret-Anne Storey, for her endless hours of help
and support.
ix
Dedication
To Alex.
Chapter 1
Introduction
Often programmers must use several tools to complete a software development
process. Each tool assists the developer by automating one or more tasks in the process.
Unfortunately these tools often use incompatible data formats and have different user
interfaces. Developers can manually transfer data across tools, write scripts to automate
the process, or put pressure on the tool designers to use a common data format. More
often than not, developers choose to use other tools that have better support for tool
interoperability, forcing tools that may have great potential to become obsolete.
A tool designer has to make many decisions that ultimately decide the fate of their
tool. For example, most tools are designed for a specific task in a specific domain. If the
designer does not create an architecture that lends to extensibility, opportunities to use the
tool in other domains can be missed. In this thesis we examine one such visualization
tool, called SHriMP (Simple Hierarchical Multiple Perspective) Views [59, 51, 54].
SHriMP is a visualization tool, originally designed for visualizing software. Over
the past few years we have been evaluating SHriMP as a software visualization tool
through several user studies [58]. The feedback and initial results from these studies
2
have been positive, but a clear result from these observations is that SHriMP needs to be
integrated as part of a software development environment if it is to be truly useful.
Also, many third parties have inquired about using SHriMP as part of their tool.
Unfortunately, SHriMP’s original architecture was not flexible enough to allow us to
easily integrate SHriMP with these other tools. We could rapidly do proof-of-concept
integrations but further changes and customizations were difficult to do and the resulting
customized systems were hard to maintain. Consequently we needed to redesign SHriMP
so that it could be easily integrated with other tools and customized for new domains
reusing as much code as possible.
This problem is not unique to our project. Most software engineering tools lack
the ability to integrate with other tools. In this thesis we examine how we reengineered a
software visualization tool so that it can be easily integrated with other tools and
furthermore can be customized to provide visualization features for other domains.
The main contributions from this thesis are:
- A description of the process we followed to reengineer a legacy visualization tool
into a component-based architecture.
- The visualization framework that resulted from our reengineering process and
validated by several case studies, which is available for developers to benefit
from.
- A detailed description of the resulting architecture, which should be of benefit to
other tool designers for other classes of tools.
- A description of two case studies that validate how this new architecture supports
tool interoperability and customizability.
3
The rest of the thesis is organized as follows. Chapter 2 provides background on
reengineering, tool integration approaches and software frameworks. Chapter 3 describes
the SHriMP visualization tool. Chapter 4 describes the reengineering process we used to
reengineer SHriMP, and the framework resulting from this process. Chapter 5 evaluates
the SHriMP framework by examining the integration of SHriMP with two third party
tools. Chapter 6 discusses lessons learnt during the reengineering process and tool
integrations. Chapter 7 concludes the thesis with a summary of the contributions from
this thesis, comparisons to related work, and suggested future work.
4
Chapter 2
Background
In this chapter we describe the technical background on the reengineering process
followed to reengineer SHriMP, as well as provide details on tool integration strategies
and component-based frameworks.
2.1 Software Reengineering Reengineering describes a process, which includes phases of reverse engineering,
redesigning, and forward engineering.
Reverse engineering involves recovering and documenting a system in order for
developers to understand how the system works [65]. These abstractions can be
discovered by referring to system experts, system documentation, or the source code. In
legacy systems the original system experts are often no longer available and system
documentation quickly becomes out of date. In many cases, the only way for a developer
to reverse engineer a system is to extract the information from the code. Traditionally the
extraction is done manually by reading the system’s code and running the program. To
assist the developer in creating the abstraction many different tools have been created to
5
automate different degrees of the reverse engineering progress [36]. Unfortunately the
process is still time consuming for the developer.
Software engineers often approach the redesign and forward engineering phases
of reengineering concurrently. Redesigning is the process of changing the system
abstraction to accommodate the system’s present and future requirements. Forward
engineering is the process of implementing the new abstraction. There are a number of
different development processes that can guide a developer through these two stages
(Example: UML Development Process [26]). There are also a number of tools the
developer can use to assist in a development process (Example: Rational Rose, a UML
editor [45]).
In our reengineering effort we followed an approach by Larson [26], which is
described in detail in section 4.1. As mentioned in the introduction, the new architecture
for SHriMP required that it would interoperate with other tools and support a component-
based design to enable customization for diverse domains. The next two sections provide
background on tool interoperability and component-based frameworks.
2.2 Background on Tool Interoperability Tools can interoperate in many different ways using a variety of integration
techniques [39]. In this thesis we consider four types of tool integration: data
integration, control integration, process integration, and presentation integration [64].
6
2.2.1 Data Integration
Data integration describes how two or more programs can share data using a
common data source, such as a file or database. For example, the Extensible Markup
Language (XML) has become a standard interchange format, used in many different
domains to provide data integration [15]. It provides a flexible, easy to understand
format. To support data integration, languages such as Java, have libraries for parsing
and creating XML [21]. A more complex example would involve the sharing of data via
an inter-process communication. Data integration can be bi-directional or unidirectional.
2.2.2 Control Integration
Control integration occurs when one program controls another, such as when one
program (the controller) directly invokes another program (a slave). Control integration
can also be unidirectional or bi-directional. In bi-directional control integration, a tool
may be both a slave and a controller. A slave is called an embedded tool if it provides a
Graphical User Interface (GUI) for use within the controller’s GUI. Note that control
integration requires some level of data integration, as the controller has to pass
commands to the slave.
2.2.3 Presentation Integration
Presentation integration describes the use of a common “look and feel” between
applications, with the purpose of reducing the learning curve users face when using a new
application. We divide presentation integration into two types: Standards-Based
Presentation Integration and Tool Assisted Presentation Integration. We define
7
standards-based presentation integration as any type of presentation integration that has
become accepted by industry and is common practice in applications. For example, when
users of the Windows operating system want to quit an application, they often look under
the file menu and select exit. However, Windows application developers are not forced to
place exit under the file menu nor are they required to include a file menu. Developers
choose to include items like these because they have become standards that users are
familiar with. In this example, the file menu and the exit menu item are considered forms
of presentation integration.
There are many items in applications that can be considered forms of standards-
based presentation integration, such as borders around a window, titles at the top of the
window, using “x” in the top-right corner to exit the application, placing the help menu
on the right side of the menubar, etc.
We define tool assisted presentation integration as any type of presentation
integration assisted by another tool through either control or data integration. For
example, applications in Microsoft Office use the office assistant (the paper clip) to
provide help to their users. Developers of third party tools can also integrate with
Microsoft Office and use the office assistants [32]. Although the use of the office
assistant is not standard in every Windows application, users of Microsoft Office will
quickly recognize it and understand how to use it if seen in another context.
Due to the number of items in an application that adhere to standards-based
presentation integration, and because the items associated with that type of integration are
already accepted as standard items in an application, we chose to only focus on tool
assisted presentation integration.
8
2.2.4 Process Integration
Process integration describes the integration of two or more tools for the purpose
of reducing the number of applications a person is required to use to complete an entire
process (for example, the software development process). Within a process, a tool is
either a horizontal or vertical tool [64]. Vertical tools are used at a particular step in the
process. For example, a traditional Unified Modelling Language (UML [6]) Modeler (a
program used only to model UML) is used during the design phase of the development
cycle. Horizontal tools are used throughout the entire process. For example, email
clients can be considered horizontal tools, helping developers during each step of the
development cycle. To simplify the discussion in this thesis we only consider process
integration that combines vertical tools to support a process. One example of process
integration of vertical tools is the combination of a compiler and a text editor.
Process integration is one of the main reasons developers integrate tools. For
software engineering development, Integrated Development Environments (IDEs) are
created to encapsulate a number of tools that developers may need to develop
applications. These tools include version managers, compilers, debuggers, editors, etc.
Historically the developers of IDEs built tools from scratch rather than integrating
existing tools that were already proven successful (for example, text editors were often
unique to the IDE instead of the IDE interoperating with existing editors). More recently
IDEs now have the ability to integrate with external tools via control integration (for
example, Visual Source Safe [33] is a version control manager that has been integrated
with IDEs such as CodeWarrior [8] and Visual Studio[34]).
9
In an ideal situation, the IDE would incorporate the best tool for each part of the
software development process in order to provide the developer with the best
environment to develop software. However, what constitutes the “best” tool for any
developer will vary. Therefore a more flexible IDE should have the ability to switch one
tool for another.
Standardized interchange formats have been created to ease the work involved
with integrating tools via process integration. For example, the XMI interchange format
can be used as a common medium between tools used to develop object-oriented
applications [41]. XMI is an interchange format for describing object models, and is
often used to describe UML models [41]. A developer can develop a design in a UML
Modeler and transfer the design to an IDE using an XMI file.
2.3 Component-Based Frameworks Booch describes a framework as “an architectural pattern that provides an
extensible template for applications within a domain.” [6, page 383] Wasserman
suggests that integrating tools will enhance tool performance [64] and Wang points out
integration is a standard practice in the other disciplines of engineering [62]. But
integrating tools can be time consuming and tedious, especially if their architectures do
not easily support integration with other tools. Although frameworks are generally
believed to be useful, very few industrial frameworks have been released. Some
exceptions include Eclipse [14], which we discuss in Chapter 5.
Component-based frameworks are particularly powerful as they enable a high
degree of flexibility and customization. A component-based framework describes an
10
architecture based on components. A component is a “unit of composition with
contractually specified interfaces and explicit context dependencies only. A software
component can be deployed individually and is subject to composition by third parties.”
[61, page 34] Components range in size and complexity but it is believed a good
component encompasses a single purpose in a system. An example of a small component
is any GUI widget such as a dialog box. An example of a larger component is a graphical
user interface for an application.
Wang examines the history of software development, and concludes there is still a
way to go before we can call it software engineering [62]. The main issue he raises is
that engineers build products from standard, quality components, but software developers
still build applications line by line. Wang points out that there is an absence of quality
software components. The next step in the evolution of software development, therefore,
is to provide high-quality component-based frameworks that can be easily used to create
larger, more reliable products.
There are many types of component-based architectures. The four most
commonly used in Java applications are CORBA [9], COM/DCOM [31], EJB [12], and
Java Beans [17]. Since the old system was written in Java, and we wanted to use as
much of the old system’s code as possible, we chose to use Java for the new system as
well.
The Common Object Request Broken Architecture (CORBA), the Distributed
Common Object Model (COM/DCOM), and the Enterprise Java Beans (EJB) are
platform independent, and designed to assist developers in creating distributed
applications [9, 11, 12]. As such, their main features assist developers with resolving
11
common distribution problems such as seamless component distribution, bottlenecks and
security. CORBA and COM/DCOM are language independent, whereas EJB uses Java.
All three types of architectures have a server that provides two basic services: (1)
registration of components and (2) provision of remote application access to components
upon request. Since the reengineering case study we focus on in this thesis does not
require a distributed architecture, we did not choose one of these types of architectures.
Instead we focus on Java Beans, which were used to create the new architecture in our
case study. More details are provided in the next section.
We could have used another type of frameworks, such as a module-based
framework. We chose to use a component-based framework for the flexibility,
extensibility, and maintainability that components provide. Modules, for example, are
less structured. One common problem with modules is they often become dumping
grounds for functions without a home. Since one of our main concerns was
maintainability, we chose not to use a module-based framework.
Szyperski notes modules can be used as components, but typically they are
thought of as libraries for a specific area, such as a math library [61]. Components are
typically thought of as entities and are instantiated and connected to form a system. The
main difference between modules and components is how they are structured. Modules
are customized and built using a particular company’s or developer’s guidelines.
Components, such as Java Beans, follow a set of globally accepted guidelines. The
guidelines provide a common ground between developers, easing the transition of a
component from one application to the next. Since one of our main goals was to ease the
integration of SHriMP with other tools, we chose to use the component-based approach.
12
2.4 Java Beans A Java Bean is defined as “a reusable software component that can be
manipulated visually in a builder tool” [17, page 9]. It has three characteristics:
properties, exposed methods, and events. Properties are attributes that users can set when
customizing a bean in a visual builder, and are specified by set and get methods (for
example, a bean with the methods getColour and setColour has the property colour).
Exposed methods are the methods that can be called from outside the bean to perform
some action. Events are used to notify interested clients that something interesting has
happened within the bean.
A Java Bean has the following features:
• Customization: The ability to customize the properties in a visual building tool.
• Events: Using events to communicate with the outside world.
• Properties: Attributes of the bean defined by set/get methods.
• Persistence: The ability to save/load a bean’s state to/from a persistent storage.
In a Java Bean architecture, adapters are used to connect the beans. Adapters are
simple classes used to catch an event (a notification an action has happened) from one
bean and call one or more actions in the appropriate beans. For simplicity a single action
(for example, a mouse click) is often mapped to a single adapter.
Adapters allow developers to componentize their algorithms, making them
simpler and easier to maintain. For example, with the scenario of a user clicking and
moving a graphical object in a drawing program, three different adapters could be used.
The first catches the mouse button pressed event and selects the object clicked on. The
13
second adapter catches mouse move events and moves the selected object appropriately.
The last adapter catches the mouse button released event and deselects the object.
In the above example the first adapter catches a mouse button pressed event and
selects the appropriate graphical object. This adapter can be used in many other
algorithms: deleting the object, highlighting the object, resizing the object, etc. By
decomposing the algorithms, code can more easily be reused.
Java Beans are usually assembled using a visual builder such as the Bean Box that
comes with the Bean Development Kit (BDK) [13]. In the Bean Box (Figure 1) there are
four windows. The main window shows the application under construction. The window
in the top left corner contains all of the available Java Beans. The top right window
shows the selected bean’s properties. The bottom left window summarizes the adapters
created between the beans. The developer can create an adapter by selecting an event to
catch from one bean (the command is under the menus) and choosing a target method to
call in another bean (by clicking on the target bean and selecting one of its methods).
14
Figure 1: The Bean Box, a visual builder used to create applications from Java Beans.
Although there are other visual builders, such as Forte for Java [60], most of them
are much more complicated than the Bean Box. Also, from personal experience we
found these other tools had usability issues that made them difficult and more time
consuming to learn and to use. Since the general goal of a visual builder is to simplify
and speed development, we will not discuss these tools any further and instead refer to
the Bean Box when we discuss the use of a visual builder.
2.3 Summary In this chapter we examined the generic reengineering process (reverse
engineering, redesign, and forward engineering), as well as provided details on the
different types of integration (Data, Control, Presentation, and Process). Finally we
described component-based frameworks. In the next chapter we describe how we
15
reengineered the SHriMP visualization tool into a component-based framework using
Java Beans for the purpose of tool interoperability and extensibility.
16
Chapter 3
SHriMP Views
This chapter describes the SHriMP visualization tool, its old architecture, and the
reasons it needed to be reengineered. It contains four sections. The first gives a brief
overview of graph visualization, as graphs are used by SHriMP to visually present
software. The second section describes SHriMP Views, focusing on its features and why
we think it is useful. The third section describes SHriMP’s old architecture and discusses
why the architecture was inadequate for the integration with Protégé and software
development environments. The last section discusses the requirements for the new
architecture.
3.1 Graph Visualization This section introduces the basic concepts needed to understand graphs for the
purpose of graph visualization. A graph is comprised of a set of vertices and a set of
edges. Each edge connects two vertices, and can be either directed (that is the pair of
vertices is ordered) or undirected. A directed graph contains directed edges. A nested
graph has vertices that represent subgraphs [53]. We refer to these vertices as subgraph
vertices.
17
In graph visualization, vertices are represented by nodes, and edges are
represented by arcs. In nested graphs, composite arcs between subgraph vertices
represent a visual abstraction for lower-level arcs between vertices within the associated
subgraphs [53].
Graphs can be visualized using a number of techniques. For example, TEELex
[42], a graph visualization tool created at the National Institute of Multimedia Education
in Japan, uses a 3D virtual space and represents nodes as spheres and arcs as vectors.
Another example, Rigi [49], a software reverse engineering tool created by the University
of Victoria, uses a 2D space and represents nodes as squares and arcs as lines. The
SHriMP visualization tool uses the latter approach.
3.2 SHriMP This section describes the SHriMP visualization tool, including its basic features
and how to use them.
Basic Features
Originally SHriMP was created as a software visualization tool [59]. The largest
node represents the software system being visualized. Opening this node reveals the
main subsystems in the program. Opening one of these embedded subsystem nodes
reveals more nodes, representing sub-components of the larger component. This
continues until the lowest artifacts extracted by the parser, such as methods or variables,
are displayed. Figure 2 shows how a small C program that implements a hangman game
may look. Note the hangman program could be structured in many different ways. The
18
types of nodes and arcs, and the actual structure of the graph is determined by how the
software is parsed and represented as an RSF file. The Rigi Standard Format (RSF) is a
format used to describe a graph of arcs and nodes [37, 49]. For example, Michaud’s Java
parser [35] extracts Packages, Classes, Methods, and Variables from a Java program.
The structure of the graph is determined in this case by the implementation architecture
that shows that packages contain classes and so on. Alternatively, other parsers may
impose no structure, allowing the reverse engineer to build one using semi-automatic
reverse engineering as described in the Rigi tool [30]. The structure for the Hangman
example was created using Rigi.
Figure 2: The hangman program visualized by SHriMP.
In the Hangman example (Figure 2 and Figure 3), the root node represents the
entire program and is labelled HangmanProgram. The node labelled Control is a child of
the HangmanProgram node (the smaller box in the top-left corner of HangmanProgram)
19
where Control is one of the main subsystems in the Hangman program. Nodes have two
main states: opened and closed. If a node is closed, the node will be a dark colour and
will not display any information. In Figure 3, all the nodes are closed except
HangmanProgram and Control. If a node is open, its colour becomes slightly lighter and
it displays information about itself, such as its children. When a node is opened, either its
children or the code associated with the node can be displayed.
Figure 3: SHriMP uses shades of colour to indicate the node is opened/closed.
Arcs represent relationships between nodes (Figure 2 and Figure 3). These
relationships can be any dependency between two entities (represented by nodes)
extracted from the code. The arcs are created when the code is parsed and the
dependencies between artifacts are extracted and stored in the RSF file. The types of
relationships available are dependent on the parser used to extract the arcs and nodes.
20
For example, a method may be called by another method in a C program. A C parser
would infer a relationship between the two method nodes to represent this call.
Navigation
There are two types of navigation. The first we refer to as the standard method of
navigation, where the user clicks on an object to navigate to/from the object. The second
we refer to as assisted navigation, where the user uses tools or optional mechanisms to
assist with navigation.
There are three techniques of standard navigation in SHriMP available to the user
[59]. The first is called magnifying [59, 67, 68]. To use this technique the user presses
the right mouse button on the desired node. The display is magnified and repositioned so
the node fills the entire display area (Figure 4). If the user presses the middle mouse
button, the screen is magnified and repositioned until the parent node fills the entire
display.
The second technique is called fisheye zooming [59, 67, 68]. In this method the
desired node is enlarged, while its siblings are reduced in size. This zooming method
allows users to see the contents of a node without loosing the context of the rest of the
view (Figure 4).
The third technique is called a simple zoom [59, 67, 68]. In this method of
zooming there is not a targeted node. When the user presses the right mouse button, the
view is smoothly scaled around the pixel under the mouse cursor. Unlike magnify, this
method of zooming continues until the user releases the mouse button. Similarly,
21
pressing the middle mouse button shrinks the view around the pixel under the mouse
cursor (Figure 4).
A B C Figure 4: An example of magnify zooming (A), fisheye zooming (B), and simple zooming (C)
on/towards the Control node.
There are two main methods of assisted navigation. The first method is
accomplished through the use of hyperlinks [59, 67]. Hyperlinks may be embedded
within a code view or documentation view of a node. When a link is clicked on, SHriMP
zooms to the node pointed to by the hyperlink. For example, this technique can be used
by the user to quickly browse control flow and data flow links in the program [59, 67] or
to read hyperlinked documentation such as Javadocs.
The second main method of assisted navigation is provided through a hotbox [67].
The hotbox is a pop-up menu that provides fast access to commands that are also in the
menu bar (Figure 5). If the user always had to switch their focus to the menu bar, they
could lose their orientation and quickly forget which node is the currently selected node.
The user presses and holds down the Ctrl key to invoke the hotbox. The hotbox will
appear above the position of the mouse and will implicitly cause the node or arc under the
mouse to be selected. As shown in Figure 5, the user can select navigation options from
the hotbox, such as “Home” which will zoom the view so all of the higher-level contents
are visible, or back or forward with respect to navigation.
22
Figure 5: The hotbox is used to provide quick access to common commands.
Cognitive Support
When visualizing large software systems, large amounts of information can be
overwhelming and confusing. There are many features in SHriMP to help organize the
information including node layouts, grouping of common nodes, node/arc filtering, and a
side-slice (top-down as opposed to nested) view of the hierarchy. Other features assist
with navigation, such as visual cues (node/arc colouring), and the search window [59,
67].
3.3 Old Architecture In this section we describe the old architecture of SHriMP and give a few reasons
for why it was inadequate for integrating with Protégé and other software development
environments such as Eclipse.
Description
Since the original architect of SHriMP was no longer available, the following
description of the old architecture was assembled from personal observation and
discussions with previous members of the SHriMP development team. Unfortunately, it
23
is believed that many concepts behind the architecture were lost during the many
upgrades and extensions. Consequently, the structure of SHriMP became unclear and
hard to maintain. The visual data and domain data were implemented as a single concept,
and yet the code was spread across twelve different classes. An overuse of inheritance
caused castings throughout the entire system. The display engine was complicated and
related code was found in every part of the system. The data hierarchy was split into two
separate structures and required constant synchronization. Any changes to the system
required in depth knowledge of the internal system structure and often required changes
in more than one place.
Before examining the architecture, it is important to understand Jazz [5], the
graphical engine behind SHriMP. SHriMP was originally built using Jazz’s predecessor,
Pad++ [4]. Jazz provides SHriMP with the ability to zoom and pan. We extended this
display by adding a number of algorithms to simplify the display’s interface for the needs
of SHriMP. An example of such an algorithm could be magnifying to a node. The right
click of the mouse is captured and Jazz is instructed to animate to coordinates slightly
larger than the node, giving the effect of magnifying on the node. Jazz provides a
number of features not required by SHriMP, such as multiple cameras, fading, cropping,
SVG drawing controls, and drawing objects other than JPanels (used to represent our
nodes) and ZLines (used to represent our arcs). These excess features were found to
complicate the Jazz API for our purposes. In order for a developer to maintain areas of
SHriMP using the Jazz API, the developer requires a good knowledge of the Jazz
structure before even minor changes can be attempted.
24
The data read from the RSF file was stored in two structures (Figure 6). The two
data structures held similar data but required manual synchronization. However, it is
preferred to have one structure hold the domain information and the other hold the
display information. In this case both structures held display and domain information,
forcing developers to understand the details of both before performing any modifications.
Node
Graph Node
Directed Graph Node
Picture Node
RSF Node
ZSwing
ZShrimpVisualComponent VisualPane
ZShrimpVisualNode ZShrimpPane
ZVisualGroup
ZShrimpNode
RSF Data Structure
GUI Data Structure
Figure 6: The old architecture had information about a single node in 2 data structures and 12 classes.
The first data structure is called the RSF data structure. It contained a hierarchy
of five classes. The top class (Node) represented a node in an abstract form without any
implementation. The bottom class (RSF Node) represented a node fully implemented
and able to read RSF files. The classes in-between represented different degrees of
abstractions.
The second data structure within SHriMP is called the GUI data structure. It was
used to interact with Jazz [22, 5]. The data structure was created by extending classes in
Jazz with information from SHriMP. For more information about Jazz, see [22, 5].
25
Inadequacies
The RSF data structure was meant to help maintain a generic system by allowing
developers to use the most abstract class possible. Node objects were passed through the
system at the most abstract level (the Node class). Although this should have allowed for
much flexibility, the majority of the algorithms in SHriMP required the RSF node, which
resulted in forced castings in almost every algorithm. Similar problems were also
encountered with other structures in the system, causing higher maintenance costs.
The GUI data structure was based on Jazz. Although very powerful, Jazz is
considered to be complicated to learn and use. Unfortunately many of the algorithms in
SHriMP are graphically oriented (i.e. laying out nodes, opening a node and displaying
children, hyperlinking from one node to another, etc.) and used the GUI data structure
instead of using the RSF data structure. The result was that details about the Jazz
hierarchy were propagated throughout the entire system.
The original Java architecture was structured in modules, much like a traditional
C program. The implementation of this structure caused parts of the program to be
extremely coupled, making it difficult for developers to determine where to make a
specific change. For example, a SHriMP view is the visual display representing the
internal graph, represented by the Picture class. The Picture class represented a single
SHriMP View (i.e. what the user sees), and store global information and connections to
the rest of the system. Each class in SHriMP had a reference to, and was referenced by,
the Picture it was a part of. Consequently, the Picture class allowed any part of the
system to access any other part. Although this allowed a lot of flexibility, many
algorithms abused this access resulting in a highly coupled system. The Jazz objects, for
26
example, could be accessed from any part of the system, allowing every part of the
system to modify and manipulate them. This removed the advantage of having a
structure around Jazz and significantly increased the cost of maintenance.
SHriMP needs to have a simple but powerful interface in order for third party
applications, such as Protégé, to be integrated with SHriMP. Each new domain will have
different requirements for integrating new data structures. Visualizing a software project
is different from visualizing a medical knowledge base. Therefore, the information on
each node should be unique to the domain. In the old architecture, a node was hard
coded to only display code or child nodes. Although each node could be hard coded to
display new types of information, it required constant maintenance that could be
prevented by dynamically loading the available types of displays for each node. These
different types of information are known as the panel modes for the node. The old
architecture could have been adapted to use dynamic panel modes, but the high coupling
of the system would have required tedious changes. Also a lack of simple interfaces
could cause integrators to access the wrong parts of the system, creating unpredictable
results.
3.4 Requirements for the New Architecture Several key requirements were desirable for the new architecture for SHriMP.
The first was to allow SHriMP to be integrated with and extended for use with third party
tools. The integrating tool would use SHriMP to visualize, explore and manipulate its
data. A primary goal of the component-based framework therefore is to support tool
27
interoperability via data integration, control integration and presentation integration.
These different types of integration were described in detail in Chapter 2.
In addition to extending SHriMP for integration with other tools, we also have to
support customization for different domains of knowledge and for individual users. Each
domain will have different visualization requirements and interaction techniques. For
individuals browsing and manipulating information spaces in a visual manner, there are
different preferences and styles in how they do these tasks (for example, it is generally
accepted that some people are visual learners while others are not). Consequently we
need to allow users to personalize how the information is presented and customize how
the space can be navigated.
As SHriMP is being designed to be able to view large, complex data repositories
and software programs, scalability is an important issue. When loading large
repositories, we need to use an incremental approach in loading data as all of the data
cannot be stored in memory. In addition to memory problems, scalability of the
graphical operations is also a key aspect. Currently SHriMP uses the Jazz [22] graphical
library for zooming operations. This library has more features than we need or desire. At
some point we may need to replace this library with a more efficient or lean approach.
The new design should allow us to do that if required.
Another requirement we had to consider was that of maintainability. SHriMP is a
research tool developed as part of an academic research program at the University of
Victoria. Many students come and go in our project. A design that is easy to maintain
and to comprehend is very important as new people join the project. Maintaining the
architecture will be easier if it is well documented and constructed. Furthermore, we
28
have several collaborations where other researchers would like to extend our tool or use
just some of the features in our approach. A framework is only reusable if it is
“approachable, predictable and easy to understand” [27, page 40].
3.5 Summary In this chapter we described the SHriMP visualization tool, its software
architecture, and the inadequacies with that architecture. We concluded the chapter with
requirements for the new architecture. In the next chapter we describe how we
reengineered this tool and describe the new architecture we designed.
29
Chapter 4
Reengineering Case Study: SHriMP
In the previous chapter we identified a set of requirements for the new
architecture. Here we describe the reengineering process we followed to design a new
architecture, followed by a detailed description of the new architecture.
4.1 Reengineering Process This section describes the process we followed to reengineer SHriMP. The
process was driven by our design requirements, team experience, available resources, and
tight deadlines. First we discuss the limitations and decisions we had to consider before
we began the reengineering process. Then we discuss the design and development
process we used to design and implement the new architecture.
4.1.1 Reengineering Limitations and Solutions
This subsection examines the limitations we faced and decisions we made before
we began the reengineering process.
The reengineering team consisted of four people. Two were experienced SHriMP
programmers and understood the details of the system. Neither person had much training
30
in design. The third was an undergraduate co-op student who had just recently joined the
team but had a good grasp of design concepts and programming in Java. The last
member (myself) was the team leader and design specialist.
SHriMP is a research project, and is demonstrated on a regular basis, often
without much warning. Therefore it is important that the down time for SHriMP be
minimized during the reengineering process. In order to fulfill this requirement, we
decided to use a “chicken little” approach [7] by wrapping the old system’s code within
the new system’s structures in order to implement the new system as quickly as possible.
The wrapped old code was then slowly updated to fulfill the requirements of the new
system.
To fulfill the requirements for the new architecture, we needed a model that
would provide flexibility, modularity, abstraction, and simplicity. Historically, there
were problems with parts of the system (for example, the graphical engine was too tightly
coupled with the rest of the system). We concluded that replacing these parts could
easily require as much (if not more) work as reengineering the entire system. In order to
prevent future difficulties, it was important that the new system would incorporate
replaceable parts. Although other architectural models might fulfill these requirements,
we chose to use a component-based architecture. Other projects have used component-
based architectures for similar reasons [16, 63, 20].
The old version of SHriMP was written in Java. In order to reuse as much old
code as possible we chose to implement the new system in Java as well. The four most
well-known component-based architectures for Java are COM/DCOM [31], CORBA [9],
EJB [12], and Java Beans [17]. Since there were no plans to create a distributed system,
31
it was believed COM/DCOM, CORBA, and EJB had too much overhead and were more
complicated than we wanted. Java Beans are simple, yet have a great deal of flexibility.
For these reasons, we chose to base the new architecture on Java Beans.
It is well accepted that designing a system in detail before beginning the
implementation stage will reduce structural problems and considerably speed up
implementation. The coop student and I were familiar with and had had successful
experiences using UML and so we chose to use UML to design the new architecture. To
support the “chicken little” approach, we only used UML on a macro scale to illustrate
how the components would interact with each other. Each developer was to design the
internal structure of one or more components (with the assistance of the rest of the team).
We used a formal UML development process by Larman [26], which is explained in
detail in the next section. We also discuss how we used Java Beans for creating the
components in the architecture.
4.1.2 Design and Development Process
The development team followed the UML development process described by
Larman [26]. While other development processes could have been used, two of the four
team members had previously used Larman’s process and had successful experiences.
According to Larman, the process of UML development can be broken down into 4 main
phases: plan and elaborate, analyze, design, and construct. Since the approach was meant
for developing software from scratch, we made some minor adjustments.
Many development processes are not used in industry due to the time required to
properly use them. Indeed, due to our time constraints we did not follow Larman’s
32
process completely. Instead of creating all the diagrams suggested for each phase, we
only created the collaboration diagrams and the class diagrams. We believed the most
useful steps were in determining the use cases, drawing the corresponding collaboration
diagrams, and constructing the class diagrams. Use cases are “narrative descriptions of
domain processes” [26, page 47]. Although we could have created other diagrams, we
believed the extra time spent on these additional diagrams would not lead to efficient
benefits. For example, use cases are well defined in their text-based descriptions. The
steps of the use cases were visualized in the collaboration diagrams. It should be noted
that upon completion of the reengineering process, we still believe the choice to use only
part of Larman’s process was the correct choice.
In order to fulfil the requirements set out in section 3.4, the development team
decided to use certain structures. To provide easy tool interoperability, a single class
(ShrimpView) was used to encompass a single SHriMP system, providing a framework
for third parties to use. To provide customization, structures to provide different views of
the same data, and thus the artifact and relationship structures (discussed in section 4.2)
were created. To handle scalability the implementation of the data storage had to be
hidden. In order to provide lower maintenance costs the system needed separate, easy to
upgrade subsystems. The last two requirements evolved into the use of the eight
components discussed in section 4.2.
Plan and Elaborate
This phase consists of understanding the system requirements and creating use
cases. “Requirements are a description of needs and desires for a product” [26, page 41].
33
By determining the requirements for the system, the designers can create a larger picture
and can accommodate for all the necessary actions. The sooner the requirements are
determined, the better the chance will be that the developers will not need to redesign and
rebuild the system again.
In the reengineering process the majority of the requirements can either be
determined from developers’ experience with the system, or by extracting them during
the reverse engineering stage. Some requirements, such as future goals for the project or
new business logic may still need to be determined through customers, project
supervisors, or other external sources. For our project, the majority of the reverse
engineering was already completed as we had in-depth knowledge of the old system. We
also examined Jazz in order to properly extract it from the old system and integrate it
with our new system. Also, we analyzed the old system in order to learn from the
difficulties it caused (section 3.3 describes our analysis). From this analysis we were able
to determine the core use cases for the new system.
Larman’s final step in this phase is to rank the use cases based on importance.
These rankings are used to determine which iteration of the development cycle the use
case will be part of. Instead of following this approach, it was decided a set of core use
cases should be chosen from the system requirements to form the base of the system’s
architecture (See Table 1). A core use case is considered any use case that is required for
the system to function, or any use case that is considered as a large factor in the design of
the system. The former may include use cases such as loading a project or moving a
node with the mouse, where the latter may include undoing an action or applying a layout
to the children of a node.
34
Mouse Actions Keyboard Actions Hotbox Actions Utility Actions Magnify on node or
parent of node Open Hotbox Change the layout of a node’s children Add a node/arc
Zoom in/out Close Hotbox Change a node’s panel mode Remove a node/arc
Fisheye in/out Change the mode of zooming
Search for a node/arc
Magnify in/out Undo/redo an action Save data/view
Open/close node
Open composite arc
Move a node
Select a node
Table 1: The core use cases used to design the new architecture.
Analyze
In this phase of development Larman suggests starting a development cycle
focusing on a select number of use cases. These use cases are used to define a conceptual
model, a diagram lays out the concepts of the system and draws how they will interact
with each other. For our design, we considered all of the core use cases to determine a
macro conceptual model for SHriMP (Figure 8). Components are determined and given
specific responsibilities. More information on the new components developed for
SHriMP’s new architecture can be found in Section 4.2.
Design
35
In this phase the conceptual model is used in conjunction with the use cases to
produce collaboration and class diagrams. Collaboration diagrams are a form of
interaction diagram, illustrating the sequence of events between components in a system.
Each collaboration diagram is based on one use case in order to prevent clutter and
confusion. Figure 7 is an example of a collaboration diagram based on the use case for
magnifying on a node. A complete set of collaboration diagrams can be found in
Appendix B.
36 Figure 7: The collaboration diagram for the use case of magnifying on a node.
4.11 [mode = “magnify”]addUndoAction(undoMagnify)
FilterEvent (d)MouseEvent(m)
1. obj := getObjectClickedOn():Object2. [obj ia a Node] n := (Node)obj3. [obj ia a Node] art := getArtifact(n) : Artifact4. [obj ia a Node] fireMouseEvent(art, this)
4.8.2 focus on targets4.8.3 [arts has only one item]
filter = new Vector(); notFiltered = new Vector()4.8.4 [arts has only one item]
fireFilterEvent (children, filtered, notFiltered)4.8.5 [arts has only one item]
display children
4.2 display := getDisplay() : Object4.3 .object: getObject(): Object
:DisplayBean :MouseAdapter
m: ShrimpMouseEvent
mousePressed()
4.7 coords := getScreenCoordinates(): Vector4.8 focusOn (arts)4.9 endCoordinates := getScreenCoordinates(): Vector
4.8.4.4 filter (objects, filtered, notFiltered)
:FilterAdapterFilterBean
d: FilterEvent
4.8.4.1 objects := getObjects(): Vector4.8.4.2 filtered := getFilteredVector() : Vector4.8.4.3 notFiltered := getNotFilteredVector() : Vector
4.8.1 [arts has only one item] children :=getChildren() : Vector
arts: Artifact
4.10 [mode = “magnify”]undoMagnify = new UndoAction(display, coords, endCoordinates){
public UndoMagnify (display, voords) {this.display = display;this.coords = coords;this.endCoordinates = endCoordinates
}public void undo() {
display.focusScreenOnCoords(coords);}public void redo() {
disply.focusScreenOnCoords(endCoordinates)}
}
:UndoBean
:Selector
4.1 mode := getSelected (“ZoomMode” ) : Object4.4 [shift held down] clearSelected (“artifacts”)4.5 addObjectToSelected (“artifacts”, object)4.6 arts := getSelected (“artifacts”): Vector
37
A class diagram is a diagram showing the conceptual entities in the system, their
details, and the relationships between the entities. The details (methods and attributes) of
each entity are retrieved from the collaboration diagrams. For example, from the
collaboration diagram in Figure 7, we know the display bean must have a method called
getScreenCoordinates. Instead of taking the time to do detailed class diagrams, it was
believed creating java interfaces from the collaboration diagrams would be as effective,
given the nature of our project. The information for the class diagrams can also be used
to create the initial java interfaces we used during the construction phase.
Construct
In this phase the design is mapped to code. We began by implementing several
components at once. Each member of the team was assigned a bean. All of the service
beans were quickly implemented. The data bean was written from scratch and did not
take long. The display bean took the most time. After all the other beans were written,
three members of the team focused on wrapping the old code behind the display bean
interface.
The development team (two full time and two part time) completed the first three
phases of the development process in two months, producing a fairly detailed design.
The final phase also took two months to create a working model with the old
implementation wrapped in the new architecture. To remove the wrapped code took an
addition four months. The entire reengineering process took eight months, but in the last
four months the team was split in two, where half the team removed the wrapped code
and the other half added many new features.
38
4.2 The New Architecture The new architecture is comprised of 8 Java Bean components: Data, Display,
Selector, Filter, History, Persistent Storage, Search, and Hotbox. Each is responsible for
a specific part of the system. Figure 8 illustrates the interaction between the beans. This
section describes each component of the system and the mechanisms used to connect
them.
Figure 8: The new architecture contains components (boxes) and adapters (arrows).
The first two beans (Data and Display) are wrapper beans. Each bean wraps an
outside resource for use in the internal system. The other beans are support beans and
provide certain services to the first two. All of the beans use two common structures:
artifact and relationship. An artifact represents the data used to create a node, where a
node is the visual box displayed on the screen. Likewise, a relationship is the data used
to create an arc that is visually displayed on the screen as a line connecting two nodes.
These two data structures provided a common medium for communication. Each data
domain can implement the artifact and relationship structures, allowing the domain’s
information to be processed in any manner. The artifact and relationship interfaces allow
39
the remainder of the system to function without knowledge of the domain being
visualized.
All of the beans are entirely independent and have no knowledge of each other.
The only common elements between the beans are the artifacts and relationships. The
beans are tied together by adapters, discussed in Section 4.2.9.
4.2.1 Data Bean
The Data Bean is the largest bean, and contains all of the hierarchical data for the
domain. Through its interface, the data hierarchy can be traversed and manipulated. The
internal structure of the Data Bean will be very different for each domain. The first Data
Bean we created was based on the Rigi Standard Format (RSF) file [37, 49]. This Data
Bean was created to enable integration with the Rigi tool. The RSF file is read by the
Persistent Storage Bean (see below) and parsed into appropriate artifacts and
relationships, which are added to the Data Bean. Consequently all of the information
from the RSF file needs to be stored using an internal memory model. The second data
bean we created (for Protégé) loads data incrementally from Protégé. When requests are
made to the Data Bean, information from Protégé is pulled and wrapped in appropriate
artifacts and relationships.
4.2.2 Persistent Storage Bean
Each Persistent Storage Bean handles all of the input and output of
artifacts/relationships to a specific file format. When loading a file, a Persistent Storage
Bean parses the file and creates the appropriate artifacts/relationships that are added to
40
the Data Bean. When saving the data, the Persistent Storage Bean takes artifacts and
relationships and stores them using a specific file format. The idea behind this bean is to
separate the artifacts and relationships from how they are stored. One benefit is that it
allows us to load artifacts and relationships with one Persistent Storage Bean (for
example, GXL [18]) and save it with another (for example, RSF), converting the file
format.
4.2.3 Display Bean
The Display Bean is the second largest bean as it holds all of the display related
information. We predicted that many people would write their own Data Beans to
support their specific domain, but not many would need to change the Display Bean.
Based on this assumption, it was important to make the interface to the Display Bean
simple, yet flexible enough to cover a wide range of domains. As mentioned in the
requirements section, we needed to wrap all of the Jazz zooming operations in this
implementation so that it could be easily replaced if required. The replacement Display
Bean could still use the same Display Bean interface, allowing the remainder of the
system to be unchanged.
4.2.4 Selector Bean
The Selector Bean holds a list of the currently selected artifacts. Although this
information could be maintained by explicitly flagging artifacts and relationships, we
maintain a global list for efficiency reasons.
41
4.2.5 Filter Bean
The Filter Bean is responsible for managing the filters for the system. The Filter
Bean provides a service to determine whether an artifact or relationship should be
filtered. This does not enforce filtering items within the display. Instead it allows access
by anyone to see if an artifact/relationship should be filtered. It leaves open many
possibilities such as filtering artifacts/relationships when saving to a file or applying a
layout. Moreover, we use a hierarchical view to show which nodes have been filtered by
drawing them differently. This allows the user to select individual filtered nodes and
unfilter them. The filter bean keeps track when nodes and arcs of certain types are
filtered (for example, in the Java domain, the user can choose to filter nodes denoting
methods), as well as keeping track of individual nodes and arcs that are explicitly filtered
by the user.
4.2.6 History Bean
The History Bean provides an undo/redo service. The interface needed to be
simple and general enough so that any action that needs to be “undoable” could also be
added to this bean. When SHriMP is prompted to perform an action, it passes undo and
redo information to the History Bean. We will use two instances of the History Bean:
one for storing navigation actions and one for storing all other actions. These actions are
treated separately and independently.
42
4.2.7 Search Bean
The Search Bean is required to provide a simple but powerful interface for
searching through the artifacts and relationships for information. Although the interface
was believed to be flexible, we found that introducing new domains required a fair bit of
work to provide effective searching. We are currently investigating more effective search
techniques that can be applied generally. However, we expect that each domain may
need to provide specialized search functionality, along with a default search strategy for
searching generically through artifacts and relationships.
Figure 9: The Hotbox is opened over the node “Fred Schmit”. The Display button has a sub-menu to display context sensitive options for this node.
4.2.8 HotBox Bean
The Hotbox Bean is based on the Hotbox menu widget, developed by Kurtenback
et al. [25]. The hotbox provides rapid access to commands through a popup menu
(Figure 9). To provide customized commands for different data domains, the hotbox was
designed with the assumption that almost everything in the hotbox could be changed.
The only exceptions to this were the history buttons (navigate back/forward) and the
modes of zooming (Zoom, Magnify, and Fisheye). The Hotbox Bean interface allows
each button to be renamed and given a specific functionality. Each button can also have
43
a sub-menu to provide more functionality. The hotbox is context sensitive. Opening the
hotbox over an arc will bring up different actions than opening it over a node.
Figure 10: This view shows the hierarchical view (left side) with Protégé.
4.2.9 Adapters
By using adapters we provide flexibility and customization in the system. When
integrating with other tools, some of the functionality may not be desired or may need to
be tweaked. To disable functionality requires removing the appropriate adapter. To
change functionality requires modifying or extending the appropriate adapter. An
example of this can be seen in the Hierarchy View. The Hierarchy View is a 2D slice
view of the hierarchy that is shown in the main SHriMP view (Figure 10). It uses a Data
Bean to reorganize the data and a Display Bean to display data. It limits the functionality
by including only a select number of adapters. The primary functionality of the
hierarchical view is to provide orientation cues and navigation assistance. It is also used
to highlight filtered nodes, and nodes that were found using a search query. Not all of the
operations are available in this secondary view, hence those adapters have been removed
or replaced with other actions.
44
4.3 Summary In this chapter we discussed the reengineering process followed for designing a
new architecture for SHriMP. In particular we examined the limitations of the
development team and research projects, and chose to use a formal UML development
process by Larman to reengineer SHriMP into a Java Bean architecture. We described
the four phases of Larman’s process: Plan and elaborate, analyze, design, and construct.
The last part of the chapter described the resulting architecture, based on adapters and the
following eight components: Data, Display, Selector, Filter, History, Persistent Storage,
Search, and Hotbox. In the next chapter we evaluate the SHriMP framework, and
demonstrate the requirements were fulfilled, by examining two use cases of integrating
the SHriMP framework with third party tools.
45
Chapter 5
Evaluating the Framework: Case Studies
In this chapter we validate the new architecture by applying it to two case studies.
First we describe how the architecture supported customization for new domains in
knowledge management through the integration with the Protégé tool. This first case
study was conducted by the SHriMP team. This is followed by a second case study
where we demonstrate how the framework supports tool interoperability with the Eclipse
software engineering framework from IBM. This second case study was done by a third
party developer at IBM.
5.1 Jambalaya (SHriMP and Protégé Integration) We use the term Jambalaya to refer to the integration of Protégé with SHriMP.
This section proceeds as follows. First we describe Protégé and general concepts about
knowledge management. Next we discuss how we integrated SHriMP with Protégé.
Last we discuss some technical aspects of this integration.
46
5.1.1 The Protégé Management Tool
The Protégé tool is a knowledge management tool [44, 38, 40, 57]. It allows
domain experts to build knowledge-based systems by creating and modifying reusable
ontologies and problem-solving methods, and to construct knowledge bases by
instantiating ontologies. Protégé supports the modeling of ontologies and use of
ontologies to guide acquisition of content knowledge from subject-matter experts.
Moreover it allows developers to easily “plug-in” components to add new functionalities
to the Protégé tool. Protégé is being actively used by hundreds of users world-wide in
many knowledge domains. Figure 11 shows the ontology editing environment in
Protégé.
Figure 11: This view shows the Ontology editing environment in Protégé.
Knowledge modeling and acquisition can be a cognitively challenging task. Most
current knowledge modeling tools make limited use of visualization. Our hypothesis is
that the visualizations provided in SHriMP could provide cognitive support for both
knowledge engineers constructing ontologies and for end users browsing and populating
a knowledge base. Protégé supports a frame-based system [56]. Concepts in Protégé are
47
called Classes, Instances, Slots, and Facets [56]. Classes represent the types of entities
the user will find in the ontology. Classes can be subclasses of other classes and thus
form a hierarchy of types. Ontological subclasses are similar to programmatic subclasses
in that the characteristics of the Class are inherited by the subclass. A Slot represents an
attribute of a Class. A Facet is a restriction on a Slot. Classes are templates for
Instances. Instances are the entities in the ontology.
The example in Figure 12 demonstrates a simple ontology in Protégé. At the top
of every ontology is the class Thing. Person subclasses Thing and Barber subclasses
Person. George is an instance of Barber. Chair subclasses Thing. ChairA is an instance
of a Chair. StationedAt is a slot added to Barber, and can be given any instance of a
Chair as a value. The value of StationedAt for George is ChairA. Salary is another slot
added to Barber, and allows a double as a value.
Person
Thing
BarberStationedAt
Salary
GeorgeStationedAt
Salary
ChairA
Chair
Class
Slot
Instance
Legend
Contains Value
Possible Value
Subclass
Figure 12: A sample project in Protégé.
48
5.1.2 Integration of Protégé and SHriMP
Protégé provides tool integration in two ways (Figure 13). The first method
allows an external program to instantiate a Protégé project, pulling information from the
project’s knowledge base (data and control integration), and displaying the information as
desired (presentation integration). This allows the external program to display
information without using the Protégé user interface or environment. In the second
method, an external program can be integrated within Protégé as a plug-in (data, control,
and presentation integration). The plug-in is loaded by Protégé and displayed as a tabbed
pane within the main window. We refer to the plug-in with the embedded SHriMP view
as the JambalayaTab.
UserUser
Protégé UI
InteractsW
ith
IndirectlyInteraction
SHriMP In Tab
Updates
AccessesData
Protégé Project
SHriMP UI
Updates
AccessesData
Protégé Project
InteractsW
ith
Figure 13: Two integration methods of Protégé. (Left) The external program is embedded in Protégé. (Right) The external program visualizes Protégé’s data without the Protégé User Interface.
As with the development of the new architecture, it was important to integrate
SHriMP and Protégé incrementally. The integration was planned in two phases. First
Protégé was integrated within SHriMP. Since both methods of integration require the
ability to access a Protégé project, the first phase focused on creating a new Data Bean to
49
read in Protégé projects. This phase also included the creation of new controls to interact
with the Protégé data, and algorithms to keep Protégé and SHriMP in sync (i.e. if the data
in one tool changed, the other tool was updated). In the second phase a SHriMP view
was embedded within Protégé using the Protégé tab mechanism [44]. In order to be
consistent with the SHriMP UI, this phase also included customizing the Protégé
interface to provide appropriate controls for SHriMP.
5.1.3 Jambalaya Integration – Some Technical Details
In this subsection we look at the successes and problems we encountered during
the integration. We also look at some of the technical modifications we had to make to
SHriMP in order to resolve some of these problems.
With the old architecture this integration would have been time consuming and
tedious. Since the Jazz graphical library had been integrated with entire system, each
developer would have required in depth knowledge of Jazz even though the only part of
the system being replaced was the data component. Also, SHriMP’s data structure was
complex and would have required endless hours of testing and debugging. Most likely,
the developers proceeding with the integration would have altered SHriMP’s architecture
in order to deal with some of these difficulties.
The largest success in this integration was that the adapters and beans functioned
under the new system without architectural changes. It is believed this is due to the
ShrimpView class which acts as a wrapper for a single SHriMP display. The
ShrimpView class was instantiated and added to the Protégé Tab in the same way as any
other component in the Java Swing library. The only bean that was replaced was the
50
Data Bean, which is created and passed to the ShrimpView class. The ShrimpView class
uses the Data Bean interface but not the implementation, allowing any type of Data Bean
to be passed without implementation changes to ShrimpView.
One of the most valued enhancements to SHriMP during the Jambalaya project
was the ability to nest on any relationship. When constructing the Protégé Data Bean, it
was determined the bean should be able to handle nesting using any Protégé slot. It is
believed users will find this ability extremely useful when looking at a large knowledge
base with the desire to quickly find a small set of information. For example, in a
newspaper ontology there are editors, salespeople, authors, newspapers, buildings,
publishing deadlines, etc. A Jambalaya user may be interested in who is responsible for
whom. By nesting on the relationship responsible-for, the roots nodes are the highest
level of management. The children nodes are the people they are responsible for. It is
important to note only the instances and classes with the responsible-for slot will be
included in this graph, automatically filtering irrelevant information. To enhance this
idea further, we allow the nesting relationship to be changed on the fly.
Another change required was multiple parents. The only domain SHriMP had
previously used was Rigi Standard Format (RSF). The projects we had used in RSF only
used a single parent hierarchy whereas Protégé supports multiple inheritance. In order to
accommodate this requirement, the interface for the Data Bean was changed to require a
key parent and a unique ID to identify an artifact. If an artifact has multiple parents, the
artifact is duplicated for each parent. Each duplicate receives the same ID and one of the
parents as its key parent. The key parent is the parent the duplicate will be seen under
when added to the Display Bean. Note each of these duplicates is identical in every way
51
except for the key parent it is under. Since they all represent a single data entity in
Protégé, it is important all of the duplicates are kept in sync.
It is believed the concepts of nesting on any relationship and using multiple parent
can greatly enhance SHriMP’s usefulness in future projects. To help new projects use
this ability without months of work, a Default Data Bean has been created. This Data
Bean contains default implementations for handling multiple parents, nesting of any
relationship, convenience methods (such as getChildren or getParents), common methods
(such as findCommonAncestor between two nodes) and composite relationship handling.
One issue that still needs to be addressed is cycles in hierarchies. By allowing multiple
parents it is possible to have two tree branches in the hierarchy, the bottom of each
linking to the top of the other branch. By allowing nesting of any relationship, some
relationships may be bi-directional, allowing two classes to be the child and the parent of
each other. There have been some ideas to resolve this problem but nothing conclusive at
this time.
From all of the changes that were necessary to integrate with Protégé, only the
Data Bean interface and adapters were modified. In a perfect integration the changes
would only be made to the adapters. There is a clear difference between implementing a
new Data Bean, which is acceptable, and changing the interface for the Data Bean, which
is not. Roberts and Johnson believe it takes three applications to make a good framework
[50]. Jambalaya was the second application. Although the interface for the Data Bean
changed, the only change was the addition of the key parent. We learnt a lot from the
integration and were able to make the modification without damaging the architecture.
Overall we believe this integration was very successful.
52
5.2 Integrating SHriMP with Eclipse The SHriMP framework was evaluated via the integration with Eclipse. Unlike
Protégé, Eclipse was introduced after the reengineering of SHriMP was complete,
allowing us to witness the usability of the SHriMP framework without the bias of
planning for what it could be used for. The programmer at IBM (Derek Rayside) who
conducted the integration with Eclipse did not have prior knowledge of how SHriMP was
implemented. This integration is unique in that it was performed to evaluate both the
Eclipse framework and the SHriMP framework [46]. Further details of the SHriMP and
Eclipse integration can be found in [46].
This section describes Rayside’s experiences while integrating Eclipse with the
SHriMP framework. It is divided into the following subsections. The first subsection
describes Eclipse and its terminology. The second subsection describes the integration of
SHriMP and Eclipse. The third subsection is a discussion and summary of the technical
details of the integration.
5.2.1 Eclipse
In 2001 IBM released Eclipse, a framework for software engineering [46].
Eclipse provides an API developers can use to integrate tools with the framework in a
plug-in fashion. Once integrated with the framework, tools can be designed to interact
individually or with other tools.
Eclipse can be used by programmers to create software engineering environments
(or otherwise known as IDEs) [14]. Eclipse contains a set of basic tools (workspace
53
manager, text editor, etc.) that can be extended/replaced for specific needs. Tools can be
added to the framework by wrapping them in plug-ins. The main purpose of Eclipse is
“to provide tool providers with mechanisms to use, and rules to follow, that lead to
seamlessly-integrated tools” [14, page 3].
Initially the integration was performed between SHriMP and IBM’s WSMQI
(Web Sphere MQ Integrator) editor [66] using the Eclipse framework as the intermediate
medium. WSMQI was formerly known as IBM’s MSQI (MQSeries Integrator) editor.
The WSMQI editor describes work flows (also known as business processes) as nodes,
arcs, and terminals. Nodes and arcs are the same as in SHriMP. A terminal is an input or
output to/from a node for a specific purpose. For example, a mathematical division node
may have terminals for inputting a numerator and a denominator, and outputting the
answer, remainder, and any errors (Figure 14).
A node in one work flow can represent a second work flow. In this manner, work
flows can be nested as an element in other work flows. The purpose of the integration
between SHriMP and Eclipse was to visualize these nested work flows using SHriMP.
DivisionNode
Rest ofAlgorithm
Answer
Input
Numerator
Denominator Remainder
Error
Figure 14 An example of a work flow diagram in WSMQI. WSMQI uses terminals on nodes to represent input/output links to the rest of the system.
54
5.2.2 Integration of Eclipse and SHriMP
Eclipse allows integration via plug-ins (data, control, and presentation integration)
[1]. Each plug-in is described using XML [15]. Other plug-ins can hook into this plug-in
using extension points. Each plug-in defines their extension points in the XML
description.
There are two main methods used in plug-ins [46]: Invoke as a new process or as
part of Eclipse. If the plug-in is invoked as a new process, almost any program can
become a plug-in. In order to invoke an Eclipse plug-in, there are still serious limitations.
Eclipse only supports plug-ins that use SWT, an alternative widget set to the Java Swing
widget set. Since SHriMP uses the Java Swing widget set, the integration team was
forced to use the experimental approach of placing Swing widgets within SWT widgets,
which was not officially supported [46].
As mentioned previously, the integration of Eclipse and SHriMP was performed
by a third party developer at IBM. Since this project was a prototype, the integration
team chose to implement a PersistentStorageBean called OCFPersistentStorageBean to
read the flow diagram files [46]. The RigiDataBean was used to store the in-memory
model. Figure 15 illustrates how the system was connected. The remainder of the
system was left domain independent, although some additional features were added.
These features are discussed in the next section.
55
Eclipse
OCFPersistentStorageBeanSHriMP XMI plugin file
Flow Diagram Filedefines
describes SHriMP plugin
loads
embedded within
Figure 15: The structure of system resulting from the Eclipse/SHriMP integration.
5.2.3 Eclipse Integration - Some Technical Details
In this subsection we describe some improvements made to SHriMP, some
obstacles encountered during the integration, and a short summary of the integration with
Eclipse.
Improvements
In WSMQI the connectors between flow diagram elements are organized in such
a way that the crossing of arcs is minimized. The SHriMP/Eclipse integration team
updated SHriMP to also use this algorithm to update arcs as nodes are moved.
In order to provide presentation integration between SHriMP and WSMQI (i.e. to
give SHriMP some familiar characteristics from WSMQI), the ability to place images on
nodes was required. As a flexible solution, a new method was placed in the artifact
interface called getCustomizedImage. The only parameter is the mode the corresponding
node must be in for the image to be seen. For example, in WSMQI the image is only
shown if the node is closed. If the node is in the children mode, the image is not
displayed. Adding the ability to use images is believed to have increased SHriMP
potential significantly. For example, through the use of images with transparent
56
backgrounds, nodes can be given different shapes. If an image of a circle with a
transparent background were used, the node would appear as a circle and not a square.
The end points of the arcs attached to the node would be repositioned to intersect the
node’s apparent border.
In the old architecture applying pictures to nodes would have been difficult. Each
mode was hard coded in several places throughout the system. In order to add a new
mode required modifying each place to ensure the system’s stability. From experience,
even a developer familiar with the system often missed one or two places, causing
obscure errors that were often difficult to debug. All of the modes we added in the old
architecture changed only the contents of the JPanel used to represent the node. Adding
or modifying a mode to display an image instead of the JPanel would have been far more
difficult.
Obstacles During Integration
There were two main obstacles during the integration of SHriMP and Eclipse.
First, in order to provide appropriate presentation integration, we needed to support
terminals in our flow diagrams. Second, we needed to resolve the conflict between
IBM’s SWT widget set and the standard Java Swing widget set.
For representing terminals in SHriMP, four strategies were considered [46]. The
two viable options were to make the terminals first-class objects in the SHriMP model, or
to make them second-class objects as part of nodes. We decided that making terminals
second-class objects would be easier to implement since most domains we have dealt
with do not require or have an obvious need for terminals. As terminals are part of nodes
57
as second-class objects, the performance of the system did not noticeably diminish. If the
terminals were made first-class objects, it is believed the overhead would be large enough
to see a significant decrease in performance.
A third solution not covered in [46] would be to ignore the concept of terminals.
Instead we could allow the integrator to set points on each node for arcs to connect to.
Arcs can be assigned positions when created. Images can already be placed on nodes.
Pictures can be added to the node at these connection points to give the illusion of
terminals. This solution allows multiple arcs to connect to each connection point, which
the current implementation of terminals as second-class objects does not allow. It also
offers a more generic solution for domains desiring a similar effect, but not exactly the
same. For example it may be desirable to have all outgoing connections on the right and
all incoming connections on the left. Another example is grouping arcs coming/going
from the node by type. One concern with this solution is the lack of dynamic positioning,
resulting in a more cluttered diagram [46]. It is believed an event could be thrown from
each node when it moves.
The second obstacle was overcoming the use of two different widget sets in
SHriMP and Eclipse. SHriMP uses the Java Swing widget set and Eclipse uses the SWT
widget set [46]. The Eclipse/SHriMP integration team was able to work closely with the
Eclipse implementation team using experimental integration mechanisms to embed our
Swing widgets within the SWT widgets of Eclipse. The integration team experienced
three main problems: keyboard events were not functional for all widgets, screen
refreshing was unreliable, and the interaction between Swing and SWT events had issues.
Some of these issues were resolved (for example, some events were mapped from SWT
58
to Swing), while others still exist (for example, keyboard events still could not be
captured). More details on these issues can be found in [46].
With the success of the integration between SHriMP and WSMQI, a second
project is in progress to integrate SHriMP as a view in Eclipse. SHriMP will be used as
an alternative method to open and view java files. In particular it will be used to
visualize the hierarchy of the Java application. Eclipse already supplies a java parser that
can be used to create and transfer the hierarchical data structure to SHriMP for
visualization. One possible goal is to enhance this idea by allowing users to edit code
directly on each node.
IBM states in an Eclipse white paper, “The quality of the user experience depends
significantly on how well the tools integrate with the Platform and how well the various
tools work with each other.” [14, page 2] Although our main purpose was to evaluate
SHriMP, we hope the integration of SHriMP and WSMQI has illustrated the power and
ease of integrations using Eclipse and SHriMP.
5.3 Summary In this chapter we examined two case studies to evaluate the effectiveness of the
SHriMP framework. Both studies were successful and demonstrated positive features
with the framework, but at the same time indicated the framework is still evolving. In the
next chapter we discuss some lessons we learnt during the reengineering of SHriMP and
these two case studies.
59
Chapter 6
Lessons Learnt
This chapter describes some of the lessons learnt during the reengineering process
and tool integrations. First we describe our experiences using Java Beans, including
lessons learnt during the design and implementation of each bean in the new architecture.
Then we describe our experiences with tool integrations, examining specific details to
fulfill the different types of integration introduced in Chapter 2, as well as some issues we
observed during the tool integrations described in Chapter 5.
6.1 Experiences with Java Beans In this section we discuss our experiences using Java Beans. First we look at the
overall generic lessons we learnt from using Java Beans. Then we describe some of our
experiences designing and implementing specific beans.
60
6.1.1 Java Beans
A Java Bean is defined as “a reusable software component that can be
manipulated visually in a builder tool” [17, page 9]. There are two issues with using a
visual builder, such as the Bean Box, to build an application:
(1) There is no formal method of providing event-handling details. For example,
the following scenario illustrates how the Bean Box does not support the
integration of two simple beans (a button and a text field). The desired result
from the interaction between the two beans is to have the button’s name placed
in the text field each time the button is pressed by the user. In the Bean Box, an
adapter is made between an event being thrown and the desired method that
should be called. The adapter can only call a single method. In our example
there are two methods required: getName on the button and setText on the text
field.
(2) Only methods with no parameters can be used. The Bean Box would not allow
an adapter to target a method with parameters. Using the above example again,
the setText method would be considered invalid. It is believed this restriction
with the BeanBox is there to simplify its use. Allowing parameters would
require a more complicated visual builder. The builder would require ways to
specify where and what the value will be, how to determine if the value is valid,
and where to limit values (i.e. can an object be created and passed as a
parameter?).
A way around this problem is to mutate the parameters into bean properties. By
using the set/get methods, the parameters for each method can be set before
61
calling the method. Although this is plausible, it lends to other problems such
as race conditions and class congestion (ie. too many methods).
Sun is creating a new tool called the Bean Builder for use with the Java Development Kit
(JDK) version 4, which claims to be addressing these issues [3, 10]. Unfortunately this
tool was not available during our design phase, forcing us to find alternative solutions.
In order to solve these problems we had to steer away from the traditional Java
Bean approach. Instead of connecting our beans using a visual tool, we connected them
manually by writing the adapters. Although creating the adapters in this manner took
longer, adapters are short classes meant only to connect beans together. Even manually
these adapters were created fairly quickly.
Java Beans have features to support customization, events, properties, and
persistence (Described in Chapter 2). Our beans fully support the first three features.
The customization abilities of the Bean Box were not complete enough to use with our
beans. From the description of Sun’s new Bean Builder our beans could be considered
next generation Java Beans as they meet the specs of this new visual builder.
The only feature we did not fully support was persistence. Java Beans use
serialization and externalization to make a Java Bean persistent. Our beans only partially
support these mechanisms, and therefore can not be stored separately. Instead, an entire
project within SHriMP can be saved/loaded to disk, allowing the project as a whole to be
persistent. One of the main uses for serialization and externalization is to save the state
of a bean from within a visual builder. Since our beans could not be connected via a
62
visual builder, we did not do this. If the Bean Builder supports our beans as is hoped, we
will probably reconsider and fully support serialization and externalization in the future.
6.1.2 Design and Implementation Lessons
Below we describe specific lessons learnt during the design and implementation
of some of the Java Beans created for the new architecture.
Data Bean
The Data Bean is the largest bean, and contains all of the hierarchical data.
Through its interface, the domain data can be traversed and manipulated. Since it is hard
to guess all the different types of domains that might be associated with SHriMP, we tried
to keep the Data Bean interface as flexible as possible. For example, we added a property
called the Child-Parent Relationship. This relationship is used to form a hierarchy within
the data, which is used to create a nested graph. The nested graph is fed to the Display
Bean to visualize the graph. If the Child-Parent Relationship was contains, the hierarchy
would be formed based on this package contains these classes or this class contains these
methods (Figure 16). Likewise, if the Child-Parent relationship was responsible-for, the
hierarchy would be based on this entity is responsible for that entity (Figure 16).
63
Figure 16: (left) The hierarchy using contains as the child-parent relationship. (right) The hierarchy using responsible-for as the child-parent relationship.
The internal structure of the Data Bean is very different for each domain. The
SHriMP team has created two. The first is based on an internal memory model, which is
populated by a Rigi Standard Format file [37, 49]. The file is read by the Persistent
Storage Bean and parsed into appropriate artifacts and relationships, which are added to
the Data Bean. Integration with Protégé required a non-persistent data bean. When
requests are made to the Protégé Data Bean in SHriMP, it pulls information from Protégé
and wraps the information in appropriate artifacts and relationships. To integrate a new
and different data domain into SHriMP, the Data Bean is the only bean that must be
implemented. The remainder of the system is data independent and makes calls to the
Data Bean’s interfaces.
Many architecture evaluations show inheritance to be a key characteristic of a
good framework. Due to the overuse of inheritance in the old architecture, we tended
towards as little inheritance as possible in the new design. Unfortunately we have found
under-use of inheritance as inconvenient as over-use. For example, the DataBean
interface required many identical methods in each implementation. To address this
64
problem, a DefaultDataBean was created to add a layer between the domain specific
implementation (the domain specific Data Bean) and the rest of the system. Figure 17
illustrates how the Jambalaya system was modified to use the DefaultDataBean. The
purpose of the DefaultDataBean is to ease the process of integrating a new Data Bean.
The DefaultDataBean supplies default implementations of common methods. It also
abstracts the Data Bean interface from the integrator, providing abstract methods with
simple and clear descriptions of what the developer must implement and what is optional.
The DefaultDataBean requires the implementation of 13 methods, where the Data Bean
interface required 56 methods.
DefaultDataBean
Rest of System
ProtegeDataBean
Figure 17: Illustrates how the DefaultDataBean interacts with the system. Persistent Storage Bean
The Persistent Storage Bean can be used to integrate new data domains instead of
creating a new Data Bean. The new Persistent Storage Bean would read/write the
domain’s file format and store the data in a generic Data Bean. Implementing a
Persistent Storage Beans is much less work than implementing a Data Bean, but comes
with restrictions. Protégé, for example, has large data repositories that can not be loaded
65
directly into memory and require an incremental approach to extracting the data. In this
case, a Data Bean integration would be required. A more detailed discussion on data
integration is provided in section 6.2.1.
Display Bean
Integrating with a new data domain will not affect the Display Bean. If the
developer desires, new links between the Data Bean and the Display Bean can be created,
providing new functionality (for example, different control mappings). As we integrated
SHriMP with more applications from various domains, we found the Display Bean was
missing certain desired functions such as placing images on nodes. Although slight
changes were required, so far the integrations have supported our end goal to produce a
Display Bean that should cover all of the developer’s needs and the majority (if not all) of
the developer’s wants.
Not all of our design decisions were good. When originally creating the Display
Bean’s interface we attempted to generalize as much as possible. Any time coordinates
were passed to or from the Display Bean, they were passed in a Vector. We believed that
if the 2D Jazz Display Bean was ever replaced with a 3D model, we did not want to
rewrite all the supporting code. By masking the coordinates in a Vector we believe the
dimensions could be hidden. This assumption turned out to be incorrect. All of the
supporting code required knowledge of the coordinate dimensions, and therefore would
need rewriting in the event a 3D model was introduced. Instead this generalization
became cumbersome, requiring all coordinates to be wrapped and unwrapped in Vectors
without any benefits of doing so. One possible solution is to modify the Display Bean
66
interface to provide a set of methods for each of the different dimensions of coordinates
(i.e. one set of methods for 2D coordinates, another set for 3D coordinates).
Search Bean
The Search Bean was required to provide a simple but powerful interface for
searching through the artifacts and relationships for information. Although the interface
was believed to be flexible, we found that introducing new domains required a fair bit of
work to provide effective searching. We are currently investigating more effective search
techniques.
Protégé has a number of available plug-ins that developers can use. One such
plug-in is the QueryTab, which can be used to search the current ontology. The results of
the search are displayed in a list within a simple panel. The search is simple, yet still
flexible and powerful. In order to provide a better method of searching within Protégé,
we created a prototype of the QueryTab called JambalayaQueryTab using SHriMP to
display the search results. The next step in this project is to embed the QueryTab into a
dialog, for use within the JambalayaTab. The results could be displayed in the SHriMP
view associated with the JambalayaTab, eliminating the need for a separate tab for
searching. Eventually we hope to include the QueryTab as a tool within the SHriMP
framework, allowing future integrations to benefit from its usefulness.
Hotbox Bean
After the original design, it was desired to make the Hotbox context sensitive.
Opening the hotbox over an arc should display different types of actions to opening the
67
hotbox over a node. Due to the flexibility of the design, only a few modifications were
required.
The Hotbox's interface contains two methods for customization. The first
(setButtonName) sets the label of the button associated with the given position. An
action listener can be added via addActionListener, passing in the desired button name to
add the action listener to. Using these two methods, any domain can modify the hotbox
to perform specific actions. For example, if a math domain is being visualized, the
layouts button could be replaced with an algorithms button.
6.2 Experiences with Tool Integrations In this section we describe our experiences with tool integrations, examining
specifically the lessons learnt with respect to the different types of integration.
In Chapter 2 we looked at different types of integration techniques. In this section
we analyze SHriMP and examine how the new architecture satisfies the various types of
integration. For clarity we refer to the application being integrated with SHriMP as a
3PABIS (3rd Party Application Being Integrated with SHriMP). It is important to
remember the different types of integration techniques overlap and are not separate (i.e.
control integration requires some sort of data integration).
6.2.1 Data Integration
Data integration is the passing of information from one program to another
through the use of a common data source, such as a file or database. SHriMP supports
68
data integration at different levels. The different levels provide developers with a scale
of implementation complexity versus control over SHriMP (Figure 18).
Easiest Most Control
Convert Datato RSF File
Create Persistent Storage Bean
Create Data Bean
Figure 18: The 3 levels of Data Integration developers can use to integrate applications with SHriMP.
At the first and simplest level, SHriMP reads RSF files. Developers can integrate
their applications with SHriMP via data integration by converting the 3PABIS’s domain
data into an RSF file. The conversion can take place internal to the 3PABIS (saving the
data in RSF format) or external to the 3PABIS (using a file format converter). The RSF
file can then be read into SHriMP for visualization.
At the second level, a developer can integrate their application with SHriMP by
creating a new Persistent Storage Bean. It is believed new and possibly better file
formats will always emerge (for example, GXL is one of the newest file formats in the
domain of software graphs [18]). Also, developers may wish to integrate applications
with SHriMP that use file formats not supported by SHriMP. Aside from implementing a
new data bean, there should be a quick and easy method of importing the 3PABIS’s data
into SHriMP. The Persistent Storage Bean provides an interface for reading a given file
format and converting the file’s data into Artifacts and Relationships. Each Persistent
Storage Bean is responsible for a specific file format (for example, the RSF Persistent
Storage Bean is responsible for reading/writing RSF files). The effort to create a
69
Persistent Storage Bean is considerably less than the effort required to create a Data
Bean.
At the third level of data integration, developers can implement a special purpose,
domain specific Data Bean. The first two levels indirectly used the host program’s data
through the use of files. In this level the Data Bean connects to the 3PABIS and pulls
data directly from its data source. The technique used to connect the Data Bean to the
3PABIS is based on the methods provided by the 3PABIS. For example, the Protégé
Data Bean connects to Protégé by accessing Protégé’s interface. Another method of
connection could be inter-application sockets [28]. As long as the developer follows the
specifications of the Data Bean interface when implementing the new Data Bean, the
3PABIS can be connected in any manner desired.
6.2.2 Control Integration
Control integration occurs when one program controls another program. The
SHriMP framework allows control integration via the Java Bean architecture by exposing
interfaces and events for use by the outside world. With a 3PABIS, developers can
instantiate any of SHriMP’s beans and make calls to the beans to request specific actions.
The events notify the 3PABIS about the state of the SHriMP system when it has changed,
allowing the 3PABIS to initiate a series of commands to handle the state change. The
Data Bean also makes direct requests to the 3PABIS’s data structure, controlling the
external program.
Due to the new architecture, the above technique of control integration was
extended to allow hyperlinking between nodes viewing Javadocs [35]. The technique has
70
been extended even further by hyperlinking between nodes displaying Protégé frames.
All of these hyperlinks are established using adapters between beans. When a hyperlink
is clicked on, an event is fired, the hyperlink adapter catches this event, and the path
between the artifact and the destination artifact is established. The Display Bean is then
instructed to move along the path. The ability to use this technique of hyperlinking
demonstrates the new architecture supports both control and presentation integration.
6.2.3 Presentation Integration
Presentation integration is the use of a common look and feel in applications, with
the purpose of reducing the learning curve users feel when using a new application.
SHriMP provides tool assisted presentation integration by allowing developers to
customize SHriMP’s interface to meet the demands of the 3PABIS. For example, the
Java interface for the hotbox bean supports dynamic changes to the hotbox to modify the
default buttons. When the target of the hotbox (i.e. the object the mouse is pointing at
when the hotbox is opened) is a node, the hotbox displays a button called “Panel” with a
submenu populated with the panel modes for that node. If the target is not a node the
button can be modified for another use. Customizations that are not currently used but
are supported include replacing a button in the hotbox with a more important one for the
3PABIS. A mathematical 3PABIS may not be as interested in layouts as running
algorithms on its nodes. In this case the layout button can be replaced with an algorithms
button. By allowing the customization of the hotbox, the person integrating with SHriMP
can easily provide the required commands. Users familiar with the SHriMP interface can
use the hotbox to determine the available commands for the project being visualized.
71
Developers integrating programs with SHriMP often desire SHriMP as a feature
or a view, but not as the main interface. Presentation integration is important in order to
provide the users unfamiliar to the SHriMP interface with familiarities from the host
program. Since the data being visualized in SHriMP is based on the host program, it
would also make sense to visualize the data in a manner consistent with the host program.
Often domain data is placed directly on nodes. Although the data could be placed in a
simple text area, SHriMP allows customized panels on each node. It is recommended
that the panels are the same panels as those used in the host program to provide a familiar
interface. Using the Protégé/SHriMP integration as an example, the panels used on the
nodes in SHriMP are exactly the same forms used to represent the data within Protégé.
6.2.4 Process Integration
Process integration involves the integration of several tools to support a process.
One example of such a process is the software reengineering process (reverse
engineering, redesigning, and implementing). With respect to tool support for the
reengineering process, we could use SHriMP as a software visualization tool as an aid
during the reverse engineering of a program. A design tool such as Rational Rose [45]
could then be used to help redesign the system. Lastly, an IDE could be used to
implement the new design. By integrating either the first two, last two, or all three tools
(i.e. to support the first two steps, last two steps, or all three steps in the process), we can
successfully accomplish process integration through tool integration. In section 7.3.2 we
describe how we are working towards process integration through the integration of
SHriMP with the Eclipse framework (an IDE).
72
Since SHriMP provides a generic visualization framework, it can be integrated
with many other tools to support a variety of processes. Another example (apart from
software engineering) involves a knowledge engineering process. Knowledge
engineering often involves the following steps: the design and creation of an ontology,
followed by the addition of instances to the ontology (to form a knowledge base). Once
the initial knowledge base is created, it will continue to be maintained and will evolve
over time as more knowledge is acquired. Protégé is an example of a knowledge
management tool. SHriMP can be used to visualize the ontology in order to support the
creation and maintenance of the information in the knowledge base. Consequently,
integrating SHriMP with Protégé (as discussed in section 5.1) provides another example
of process integration.
Designing a tool to support process integration is not trivial, as it is difficult to
predict all the types of processes a tool may be used to support. A partial solution to
providing process integration may be to wrap all of the core system parts within
components. From personal experiences, we noticed that developers tend to design
higher quality and more generic interfaces when dealing with components (as apposed to
a non-component system). We believe that this is due to the fact that it is expected that
other developers may examine and try to use the components.
Data, control and presentation integration are often needed to support process
integration. If a tool is easy to integrate with, it is more likely to be integrated with
another tool to support a process. A framework design for a software system will enable
all of the previous three types of integration. For example, integrating SHriMP with both
Eclipse and Protégé was easier after SHriMP became a framework.
73
6.3 Summary In this chapter we discussed the lessons learnt throughout the reengineering
process and during the tool integrations described in Chapter 5. In the next chapter we
discuss our contributions, related work, and future work.
74
Chapter 7
Contributions, Related Work, and Future Work
In this chapter we summarize our contributions, compare our approach to related
approaches and outline future work. Finally, we summarize and conclude the thesis.
7.1 Contributions The main contributions from this thesis are:
• A description of the approach we used to reengineer a legacy visualization system
into a component-based framework.
• We provide the detailed architectural design of a component-based domain
independent visualization framework.
• An implementation of a visualization framework (i.e. SHriMP).
• A detailed description of the two case studies validating our framework.
This thesis has filled some of the gaps in the research relating to reengineering,
component-based architectures, and frameworks. Many researchers have deemed
reengineering as an important discipline but the majority of the research in reengineering
focuses on the reverse engineering phase of the reengineering process [2, 36]. We
75
described the entire reengineering process we used to create a component-based
framework, providing others with a practical example.
Research in component-based architectures is still fairly new. Lorenz and
Vlissides point out that although the research involving a single component has evolved,
the area of designing a component-based system is still weak [29]. Along with the
reengineering process, we also describe the resulting component-based design (Section
4.2), which can also be used as a practical example.
Frameworks have been used for some time, yet there seems to be a lack of
research on the benefits of using a component-based design for building frameworks.
Johnson points out that most of the projects to build frameworks have failed [23]. In this
thesis we have evaluated the benefits of using a component-based framework through the
integration of SHriMP with Eclipse and Protégé. The integrations also verified the
success of our reengineering process, the component-based design, and resulting
framework.
7.1.1 Reengineering Approach
We describe an approach to reengineer a legacy system into a component-based
framework using Java Beans. The reengineering process involved reverse engineering
the existing system, designing the new architecture, and implementing the new system.
We used Larman’s UML Development process to design and implement the new system
[26]. In order to make the new system flexible, extensible, and more maintainable we
used Java Beans to form a component-based framework. We describe the reengineering
process to provide an example for other reengineers in future reengineering endeavours.
76
7.1.2 Detailed Architectural Design
We describe the details of the architecture we created for SHriMP. In addition we
also describe some of the problems and successes we encountered during the creation and
use of this architecture. Our hope is that this description will help future developers
avoid some of the mistakes we made, and benefit from some of the successes we had.
We also hope the architecture can be used as an example for developers learning to
design component-based systems.
7.1.3 An Implementation of a Visualization Framework
As part of the research for this thesis, we implemented the SHriMP visualization
framework. The framework has significantly reduced the maintenance costs of its
predecessor and has far greater flexibility for future extensions. Third party developers
can integrate the SHriMP framework with other tools to visualize nested graphs. The
visualization techniques used in SHriMP may enhance the effectiveness of these tools.
The framework can also be used as a sample for future framework development. In
particular, developers working on a future component-based framework can learn from
our experiences by examining the components we designed and the lessons learnt from
those decisions.
7.1.4 Validation of Framework
Often research ventures, such as this reengineering endeavour, have merit but are
rarely validated beyond a theoretical or prototyped project. Along with our
77
implementation of the new framework, we have also described two case studies in which
we integrated SHriMP with another tool. These case studies illustrated how the
mechanisms we designed were successful. We hope future developers can examine our
case studies to improve their own projects.
7.2 Related Work This section provides details on some related tools and compares our approach to
their approaches.
7.2.1 Field
In the late 1980s the FIELD software engineering framework was created at
Brown University [48, 47]. FIELD was one of the first software engineering
environments in which developers could integrate existing tools. The developers of
FIELD provided a control integration mechanism through the use of messages. A
message can be sent from a tool to the FIELD framework requesting a service. If another
tool was registered with the FIELD framework to provide the requested service, the
framework will invoke the second tool. Although FIELD had potential and is still around
today, it was never widely adopted by industry.
Since FIELD was one of the first software engineering frameworks, the
developers had to build everything from scratch, including the mechanisms used to
integrate with third party tools. Although FIELD provided similar mechanisms to the
SHriMP framework, tool integrators had to modify their tools to use FIELD’s customized
mechanisms in order to integrate with FIELD. In our approach we used predefined
78
integration mechanisms that have been accepted by industry, such as Java Beans and the
Swing graphical library. Tools written in Java can be integrated with the SHriMP
framework without modification or with only minor modifications.
7.2.2 GSEE
Although not known at the time, a similar project to build a flexible visualization
tool (GSEE) was being led by Favre in France [16]. The requirements for SHriMP were
similar to the requirements for GSEE. Favre describes three categories of requirements:
Multi-source exploration, multi-visualization exploration, and customizable exploration.
Upon examination, we found these three categories to be very similar to our
requirements.
Multi-source exploration is the separation of the data from the environment used
to explore the data, with the main purpose of being able to quickly replace one data
source with another. Since all the parts of a system will eventually become outdated and
need to be replaced, we extend Favre’s requirement to include the ability to quickly
replace any core part of the system (see Tool Interoperability and Maintainability in
Section 3.4).
Multi-visualization exploration is the ability to represent the same data in many
different ways in an easy to change manner. We too believe that different users will use
SHriMP in different ways on the same data. For example, a Java programmer may want
to explore a system by looking at the code of classes and methods. A supervisor
exploring the same system may only be interested in the documentation, and may want to
79
only browse the Javadocs for packages and classes. We agree with Favre and have
included this as part of our requirements (see Customization in Section 3.4).
Customizable exploration is the existence of advanced and simple tools to cover a
wide range of users. It is also the existence of a method to create specific tools for
specific tasks. We believe an environment should have a base set of commands and tools
for advanced and novice users (see Customization in Section 3.4). But Favre’s third
requirement differs slightly from ours. While Favre required mechanisms for creating
tools, we required mechanisms to integrate existing tools with SHriMP. Having learnt
from Favre’s system, we hope to extend SHriMP in the future to also fulfil his
requirements.
7.3 Future Work In this section we describe some of the future work that could take advantage of
the research in this thesis. First we describe an extension that would improve the
SHriMP framework. Second we describe some of the future projects that are possible
due to the SHriMP framework.
7.3.1 Plug-in Extension for the SHriMP Framework
From our experiences working with Protégé and Eclipse, it appears that many
tools and frameworks support integration using a plug-in mechanism as the main method
of integration [44, 14]. The SHriMP framework also supports this mechanism by
allowing developers to create new Data Beans, which can be plugged into the SHriMP
framework. The remainder of the system will function properly as long as the new Data
80
Bean follows the rules of behaviour outlined in the Data Bean interface. The next step
would be to provide faster methods of plug-in integration, such as placing the jar file in a
plug-ins directory [44].
7.3.2 Future Projects
As a result of reengineering SHriMP as a framework, many future projects have
been proposed and are now possible. We summarize two of them here. The first
involves the visualization of version control information using SHriMP. The second
involves using SHriMP as part of an IDE, which has been one of the desired projects
from early user studies.
Version Control Visualizations
Xiaomin Wu, a graduate student at the University of Victoria, has been working
on using SHriMP to visualize various aspects of version control management (VCM).
Her main focus is to provide the ability to search through the comments and code of
different versions of a project within a CVS repository. The results will be visualized in
SHriMP, using highlighting or colour coding mechanisms (for example, light colours for
no matches in a node and dark colours for lots of matches in a node).
There are many other possible projects associated with VCM systems. For
example, SHriMP could be used to visualize the stability of a class or method using
colour gradients. The darkest colours could indicate a class has changes numerous times
since a given date, while the light colours could indicate a class has not changed at all.
81
Due to the SHriMP framework, Wu will be able to use SHriMP to visualize these
projects quickly and with little effort. In the above example (visualizing the stability of
classes and methods), Wu needs to implement a new Data Bean to access the VCM
system data, and organize it into artifacts and relationships. In order to support the
gradient of colours assigned to show the relevant stability of a class, she can create a set
number of artifact types. Each type is given a colour slightly darker than the last. When
the CVS system data is organized into artifacts, each artifact can be assigned the type that
appropriately represents the amount of change to the corresponding CVS data.
Using the old architecture, such a project would not have been feasible. If the old
architecture were still in use, Wu would have had to learn the details of Jazz (note in the
new architecture she does not need to know about Jazz or how the internals of the
Display Bean work). In addition, to provide data integration she would have had to
externally convert the CVS data into an RSF file. Although it was possible to directly
interact with the internal data structures, this approach would most likely never be
considered since the data structures were manipulated throughout the entire system,
making stability very difficult to achieve.
SHriMP As an Interface For an IDE
During various conferences I have attended in the past couple of years, one of the
most frequent questions is “Do you have plans to make SHriMP as an editor for source
code?” Rob Lintern, a full time employee of the University of Victoria, has been
working on the project described in section 5.2.3 to use SHriMP as an alternative method
of viewing and editing a Java project within Eclipse. Although still experimental, there is
82
a possibility of embedding the SWT widgets onto SHriMP nodes. The project could be
recompiled to update the SHriMP display. By using the SWT widgets, we would gain
the benefit of a professional editor without having to maintain it.
We have considered creating our own editor, but there were several issues we had
to consider. First of all, users have very particular preferences for editors and want to use
their preferred set of features and tools. Secondly, since editors are one of the oldest
software engineering tools, they are very mature and well designed. Therefore, building
an editor from scratch would be a case of “reinventing the wheel”. Therefore, it makes
more sense to focus on embedding an existing editor within the SHriMP nodes instead of
creating our own.
The SHriMP framework has made it plausible to proceed with this feature. The
old architecture lacked the flexibility and structure we needed to quickly embed new
types of panels on SHriMP nodes. As in the CVS project above, the new framework has
provided the mechanism we require to quickly integrate external IDEs. For example,
Lintern has chosen to use the Default Data Bean, which provides incremental loading of
the data. There has been initial success with this project, and projects within Eclipse can
now be visualized. The next step is to explore if SHriMP can provide an alternative
interface as part of an IDE.
7.4 Conclusion Often programmers must use several tools to complete a software development
process. Each tool assists the developer by automating one or more tasks in the process.
Unfortunately these tools often lack the ability to be integrated with other tools, and thus
83
become obsolete before they should. Also tool designers have to make many decisions
that ultimately decide the fate of their tool. For example, most tools are designed for a
specific task in a specific domain. If the designer does not create an architecture that
lends to extensibility, opportunities to use the tool in other domains can be missed.
SHriMP was an example of such a tool, but this problem is not unique to SHriMP. Many
software engineering tools lack the ability to integrate with other tools. In this thesis we
examined how we reengineered SHriMP so that it can be easily integrated with other
tools and furthermore can be customized to provide visualization features for other
domains.
We began with a description of the technical background on the reengineering
process we used to reengineer SHriMP, as well as details on tool integration strategies
and component-based frameworks (Chapter 2). We described the SHriMP visualization
tool, its old architecture, and the reasons it needed to be reengineered (Chapter 3). Then
we described the process we followed to reengineer SHriMP, and gave an overview of
the new architecture (Chapter 4). We validated the new architecture by applying it to two
case studies (Chapter 5). Next we described some of the lessons learnt during the
reengineering process and tool integrations (Chapter 6). Last we summarized our
contributions, compared our approach to related approaches, and outlined future work.
New projects (such as those mentioned in section 7.3) are possible because of the
new framework we designed for SHriMP. The ability to quickly integrate a new data
domain into SHriMP has opened many doors. Being able to customize SHriMP has
allowed developers to use SHriMP without making large compromises. For the
development of SHriMP, creating a framework that is simple and flexible should reduce
84
the maintenance costs significantly, and will hopefully increase the length of the life span
of SHriMP. Designing and implementing the SHriMP framework is our contribution to
research in the hopes that future (and present) projects can use and benefit from SHriMP
for some time to come.
85
Bibliography [1] J. Amsden. Your First Plug-in. An Eclipse Corner Article. November 14, 2001.
Found at http://www.eclipse.org/articles/Your First Plug-in.html (found on February 6, 2002).
[2] L. Baniassad, and G. Murphy. Conceptual Model Querying for Software
Reengineering. Published in the Proceedings of the 20th International Conference on Software Engineering (ICSE 1998), Kyoto, Japan, pages 64 – 72, April 1998.
[3] The Bean Builder. Part of The Source For Java Technology. Sun Microsystems Inc.
Found at http://java.sun.com/products/javabeans/beanbuilder (found on February 24, 2002).
[4] B. Bederson, and J. Hollan. Pad++: A Zooming Graphical Interface for Exploring
Alternate Interface Physics. Published in the Proceedings of the 7th Annual ACM Symposium on User Interface Software and Technology (UIST ’94), Marina del Rey, California, United States, pages 17 – 26, November 1994.
[5] B. Bederson, J. Meyer, and L. Good. Jazz: An Extensible Zoomable User Interface
Graphics Toolkit in Java. Published in the Proceedings of the 13th Annual ACM Symposium on User Interface Software and Technology (UIST ’00), San Diego, California, United States, pages 171 – 180, November 2000.
[6] G. Booch, J. Rumbaugh, and I. Jacobson. The Unified Modeling Language User
Guide. Addison-Wesley, 1998. [7] M. Brodie, and M. Stonebraker. Migrating Legacy Systems: Gateways, Interfaces and
the Incremental Approach, Morgan Kaufmann Publishers, 1995. [8] CodeWarrior Development Tools. Metrowerks, Found at
http://www.metrowerks.com (found on May 9, 2002). [9] The Common Object Request Broker: Architecture and Specification. Object
Management Group. Found at ftp://ftp.omg.org/pub/docs/formal/99-10-07.pdf (found on Jan 21, 2002).
[10] M. Davidson. The Bean Builder Tutorial. Sun Microsystems Inc. Found at
http://java.sun.com/products/javabeans/beanbuilder/1.0/docs/guide/tutorial.html (found on February 24, 2002).
[11] DCOM Technical Overview. Microsoft Corporation. Found at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndcom/html/msdn_dcomtec.asp (found on May 21, 2002).
86
[12] L. DeMichiel, L. Yalcinalp, and S. Krishnan. Enterprise JavaBeans Specification Version 2.0. Sun Microsystems Inc. Found at http://java.sun.com/products/ejb/docs.html#specs (found on May 21, 2002).
[13] Downloading the BDK 1.1. Sun Microsystems Inc. Found at
http://java.sun.com/products/javabeans/software/bdk_download.html (found on May 6, 2002).
[14] Eclipse Platform Technical Overview. Object Technology International, Inc. July
2001. Found at http://www.eclipse.org/whitepapers/eclipse-overview.pdf (found on March 22, 2002).
[15] Extensible Markup Language (XML). W3C Architecture Domain. Found at
http://www.w3.org/XML, (found on May 28, 2002). [16] J. Favre. GSEE: A Generic Software Exploration Environment. Published in the
Proceeding for the International Workshop on Program Comprehension (IWPC 2001), Toronto, Ontario, pages 233 – 244, May 2001.
[17] G. Hamilton (Editor). Sun Microsystem JavaBeans. Sun Microsystems Inc. 1997.
Found at http://java.sun.com/products/javabeans/docs/beans.101.pdf. (found on February 24, 2002).
[18] R. Holt, A. Winter, and A. Schürr. GXL: Toward a Standard Exchange Format,
Published in the Proceedings of the Seventh Working Conference on Reverse Engineering (WCRE ’00), Brisbane, Australia, pages 162 – 171, 2000.
[19] J. Iivari. Why are CASE Tools Not Used? Published in the Communication of the
ACM, Volume 39, Issue 10, pages 94 – 130, October 1996. [20] I. Jacobson. Re-engineering of old systems to an object-oriented architecture.
Published in the Proceedings of the Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA ’91), Phoenix, Arizona, United States, pages 340-350, October 1991.
[21] Java Technology and XML. Sun Microsystems Inc. Found at
http://java.sun.com/xml/javaxmlpack.html (found on May 28, 2002). [22] Jazz Project. Part of the Human-Computer Interaction Lab. University of Maryland.
Found at http://www.cs.umd.edu/hcil/jazz (found in 2000). [23] R. Johnson. Components, Frameworks, Patterns. Published in the Proceedings of
the Symposium on Software Reuse, Boston, Massachusetts, United States, pages 10 – 17, February 1997.
[24] C. Kobryn, Modeling components and frameworks with UML, Published in the
Communications of the ACM, Volume 43, Issue 10, pages 31 – 38, October 2000.
87
[25] G. Kurtenbach, G. Fitzmaurice, R. Owen, and T. Baudel. The Hotbox: Efficient
Access to a Large Number of Menu-Items, Published in the Proceedings of the CHI ’99 Conference on Human Factors and Computing Systems, Pittsburgh, Pennsylvania, United States, pages 231 – 237, May 1999.
[26] C. Larman. Applying UML And Patterns: An Introduction to Object-Oriented
Analysis and Design. Prentice Hall PTR, Upper Saddle River, New Jersey, 1998.
[27] G. Larsen. Designing Component-Based Frameworks Using Patterns in the UML.
Published in the Communications of the ACM, Volume 42, Issue 10, pages 38 – 45, 1999.
[28] Lesson: All About Sockets. Part of the Java Tutorial. Found at
http://java.sun.com/docs/books/tutorial/networking/sockets/index.html (found on May 6, 2002).
[29] D. Lorenz, and J. Vlissides. Designing Components vs Objects: A Transformational
Approach. Published in the Proceedings of the 23rd International Conference of Software Engineering (ICSE 2001), Toronto, Ontario, pages 253 – 262, May 2001.
[30] J. Martin, K. Wong, B. Winter, and H. Müller. Analyzing xfig Using the Rigi Tool
Suite. Published in the Proceedings of the Seventh Working Conference on Reverse Engineering (WCRE 2000), Brisbane, Queensland, Australia, pages 207 – 209, November 2000.
[31] Microsoft COM/DCOM. Microsoft Corporation, Found at
http://www.microsoft.com/com/tech/DCOM.asp (found on Feb 26, 2002). [32] Microsoft Office XP Developer: Programming the Office Assistant. Microsoft
Corporation, Found at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/modcore/html/deovrProgrammingOfficeAssistant.asp (found on Feb 26, 2002).
[33] Microsoft Visual SourceSafe. Microsoft Corporation, Found at
http://msdn.microsoft.com/ssafe/default.asp (found on May 9, 2002). [34] Microsoft Visual Studio. Microsoft Corporation, Found at
http://msdn.microsoft.com/vstudio (found on May 9, 2002). [35] J. Michaud, M. Storey, and H. Müller. Integrating Information Sources for
Visualizing Java Programs. Published in the Proceedings of the International Conference of Software Maintenance (ICSM'2002), Florence, Italy, November 2001.
88
[36] H. Müller H, J. Jahnke, D. Smith, M. Storey, S. Tilley, and K. Wong. Reverse
Engineering: A Roadmap. Published in the Proceedings on the Conference on the Future of Software Engineering 2000, Limerick, Ireland, pages 47 – 60, 2000.
[37] H. Müller, and K. Klashinsky. Rigi – A system for programming-in-the-large.
Published in the Proceedings of the 10th International Conference on Software Engineering (ICSE 1988), Raffles City, Singapore, pages 80-86, April 1988.
[38] M. Musen, R. Fergerson, W. Grosso, N. Noy, M. Crubézy, and J. Gennari.
Component-based support for building knowledge-acquisition systems. Published in the Proceedings of the Conference on Intelligent Information Processing (IIP 2000) of the International Federation for Information Processing Sixteenth World Computer Congress (WCC 2000), Beijing, China, pages 18 – 22, August 2000.
[39] J. Nielsen, R. Mack, K. Bergendorff, and N. Grischkowsky, Integration Software
Usage in the Professional Work Environment: Evidence from Questionnaires and Interviews, Published in the Proceedings of the CHI ’86 Conference on Human Factors and Computing Systems Proceedings, Boston, Massachusetts, United States, pages 162 – 167, 1986.
[40] N. Noy, M. Sintek, S. Decker, M. Crubézy, R. Fergerson, and M. Musen. Creating
Semantic Web contents with Protégé-2000. Published in IEEE Intelligent Systems, Volume 16, Issue 2, pages 60–71, 2001.
[41] OMG XML Metadata Interchange (XMI) Specifications. Object Management
Group Inc. Found at http://cgi.omg.org/docs/formal/02-01-01.pdf (found on May 21, 2002).
[42] N. Osawa, K. Asai, and Y. Sugimoto. Immersive Graph Navigation Using Direct
Manipulation and Gestures. Published in the Proceedings of the ACM Symposium on Virtual Reality Software and Technology, Seoul, Korea, pages 147 – 152, October 2000.
[43] Protégé-2000 1.7 API, Stanford University, Found at
http://protege.stanford.edu/doc/pdk/api/index.html (found on May 9, 2002). [44] Protégé Project, Stanford University, Found at http://protege.stanford.edu (found in
August 2000). [45] Rational Rose, Rational: The Software Development Company, Found at
http://www.rational.com/products/rose/index.jsp (found on February 27, 2001). [46] D. Rayside, M. Litoiu, M. Storey, and C. Best. Integrating SHriMP with the IBM
Websphere Studio Workbench, Published in the Proceedings of CASCON'2001, Toronto, Canada, November 2001.
89
[47] S. Reiss, The Desert Environment, Published in the ACM Transactions on Software
Engineering and Methodology (TOSEM), Volume 8, Issue 4, pages 297 – 342, Oct 1999.
[48] S. Reiss. The Field Programming Environment: A Friendly Integrated Environment
for Learning and Developing, Kluwer Academic Publishers, 1995. [49] Rigi, University of Victoria, Found at http://rigi.uvic.ca (found on May 6, 2002). [50] D. Roberts, and R. Johnson. Evolving Frameworks: A Pattern-Language for
Developing Object-Oriented Frameworks, Published in the Pattern Languages of Program Design 3, Edited by J. Vlissides, J. Coplein, and N. Kerth. Addison-Wesley, 1997.
[51] Shrimp Views, University of Victoria, Found at http://www.shrimpviews.com
(found on May 9, 2002). [52] P. Stevens, and R. Pooley. Systems Reengineering Patterns, Published in the
Proceedings of the ACM SIGSOFT Sixth International Symposium on Foundations of Software Engineering, Lake Buena Vista, Florida, United States, pages 17 – 23, November 1998.
[53] M. Storey, A Cognitive Framework For Describing and Evaluating Software
Exploration Tools, PhD Thesis, Technical Report, School of Computer Science, Simon Fraser University, December 1998.
[54] M. Storey, and H. Müller. Manipulating and Documenting Software Structures
using SHriMP Views. Published in the Proceedings of the 1995 International Conference on Software Maintenance (ICSM ’95), Opio (Nice), France, pages 275-284, October 1995.
[55] M. Storey, and H. Müller. Manipulating and Documenting Software Structures using
SHriMP Views. Series on Software Engineering and Knowledge Engineering, Series Editor-in-Chief S. Chang, Vol. 7 Software Visualization, edited by P. Eades and K. Zhang, World Scientific Publishing Co., pages 244-263, November 1996.
[56] M. Storey, M. Musen, N. Noy, C. Best, R. Fergerson, and J. Silva, On the Use of
Visualization for Ontology Authoring and Knowledge Acquisition, To be Published in the Proceedings of IEEE Symposium on Information Visualization 2002 (InfoVis 2002), October 2002.
[57] M. Storey, M. Musen, J. Silva, C. Best, N. Ernst, R. Fergerson, and N. Noy.
Jambalaya: Interactive visualization to enhance ontology authoring and knowledge acquisition in Protégé, Appeared in the Workshop on Interactive
90
Tools for Knowledge Capture (K-CAP-2001), Victoria, B.C. Canada, October 2001.
[58] M. Storey, K. Wong, P. Fong, D. Hooper, K. Hopkins, and H. Müller. On Designing
an Experiment to Evaluate a Reverse Engineering Tool, Published in the Proceedings Of the 3rd Working Conference on Reverse Engineering (WCRE '96), Monterey, California, United States, pages 31-40, November 1996.
[59] M. Storey, K. Wong, F. Fracchia, and H. Müller. On Integrating Visualization
Techniques for Effective Software Exploration, Published in the IEEE Symposium on Information Visualization, Phoenix, Arizona, United States, pages 33-45, October 1997.
[60] Sun ONE Studio 3.0 (Formerly Forte for Java). Sun Microsystems. Found at
http://wwws.sun.com/software/Developer-products/ffj (found on May 27, 2002). [61] C. Szyperski. Component Software – Beyond Object-Oriented Programming.
Addison-Wesley, 1998. [62] J. Wang. Towards Component-Based Software Engineering, Published in The
Journal of Computing in Small Colleges, Volume 16, Issue 1, Orem, Utah, United States, October 2000.
[63] J. Wang, and Y. Wang. Teaching software reuse with JavaBeans. Published in the
Proceedings of the Frontiers in Education Conference (FIE 2000), Kansas City, Missouri, United States, pages T2C-7 to T2C-8, October 2000.
[64] A. Wasserman. Tool Integration in Software Engineering Environments, Published
in the Proceedings of the International Workshop on Environments, Chinon, France, pages 137 – 149, 1989.
[65] R. Waters, and E. Chikofsky. Reverse Engineering: Progress Along Many
Dimensions. Published in the Communication of the ACM, Volume 37, Issue 5, pages 22 – 25, 1994.
[66] WebSphere MQ Integrator. Part of the WebSphere MQ family. IBM. Found at
http://www-4.ibm.com/software/ts/mqseries/integrator (found on May 6, 2002). [67] J. Wu. Integrating Techniques to Support Program Comprehension, Master Thesis,
School of Computer Science, University of Victoria, 2000. [68] J. Wu, and M. Storey. A Multi-Perspective Software Visualization Environment.
Published in the Proceeding of the Centre for Advanced Studies Conference (CASCON’2000), November 2000.
91
Appendix A – How to Integrate With SHriMP The following appendix gives a short detailed overview of the different
techniques used to integrate with SHriMP. As mentioned in Section 6.2, there are three
main ways to integrate SHriMP with another tool: (1) Convert the tool’s data into RSF
format, (2) Create a Persistent Storage Bean to read the tool’s data format, or (3) Create a
new Data Bean to exchange data directly with the tool. Note that although the last choice
provides the greatest flexibility, it also requires the most work. Once one of these three
methods has been implemented, integrators can modify the adapters to customize the
control and interface of SHriMP for a specific purpose.
To understand the last two options, a brief overview of SHriMP’s internal
structure is needed. The ShrimpView class is a container for a single SHriMP system. A
SHriMP system is composed of an instance of each bean (except the Persistent Storage
Bean) described in Section 4.2 and the required adapters to connect them. Since
SHriMPView is a type of JPanel, an instance of a ShrimpView can be used as any other
Swing widget, providing an easy mechanism for developers to use to incorporate SHriMP
into another tool’s interface. For example, the integrator can add an instance of
ShrimpView to the content pane of a JDialogBox to provide the user with a dialog box
that contains SHriMP.
The stand-alone SHriMP tool is contained within the ShrimpFrame class, which
extends a JFrame. The ShrimpFrame is responsible for keeping track of the open
SHriMP systems, as well as creating new SHriMP systems. It is in ShrimpFrame that all
the Persistent Storage Beans are created and used. In order to simplify the ShrimpView
class, Data Beans are created and populated (either through a Persistent Storage Bean or
92
from a third party tool) in ShrimpFrame and passed into the ShrimpView as a constructor
argument.
If a third party wished to use SHriMP as a plug-in, it is recommended they follow
the steps we have used in the ShrimpFrame class to initiate a SHriMP system. For the
Jambalaya integration, the JambalayaTab class contains the code to initiate the system.
We also added to the JambalayaTab class code to customizing SHriMP’s controls to take
advantage of Protégé UI mechanisms.
Converting to RSF Format
The RSF format contains a description of arcs, nodes, and properties of arcs and
nodes. Data can be converted to this format by modifying the third party tool to write its
data into RSF format. Another possibility is to create a converter that take the tool’s data
as input and outputs the data in an RSF file.
Create a Persistent Storage Bean
In order to create a new Persistent Storage Bean, the developer needs to
implement the Persistent Storage Bean interface and connect the new Persistent Storage
Bean to the rest of the system. This connection is made by adding the new bean and the
appropriate adapters to the ShrimpFrame class. More than one Persistent Storage Bean
can exist at the same time by associating a particular file extension with each persistent
storage bean.
Create a Data Bean
93
The difference between creating a Persistent Storage Bean and creating a Data
Bean is the amount of complexity involved. A Persistent Storage Bean parses a file into
artifacts and relationships, which are used to populate an In-Memory Data Bean (possibly
the Rigi Data Bean). Once the Data Bean is populated, the Persistent Storage Bean is
forgotten and the In-Memory Data Bean interacts with the rest of the SHriMP system.
There are several situations in which the In-Memory Data Bean is not sufficient for the
needs of the integrator (for example, if there is a large amount of data, the data may need
to be loaded incrementally to resolve scalability issues). For these situations, the
integrator can implement a new Data Bean.
The integrator can implement the Data Bean interface or can extend a Default
Data Bean. The Default Data Bean handles all of the domain independent algorithms
such as finding a common parent between two nodes. Although the preferred method is
to extend the Default Data Bean, the developer may wish to implement a new Data Bean
to take advantage of domain dependent algorithms that are more efficient than the
domain independent algorithms in the Default Data Bean. In the stand-alone SHriMP the
new Data Bean and associated adapters are added to the ShrimpFrame. If desired, a file
extension can be associated with the Data Bean as well.
94
Appendix B – Collaboration Diagrams The following appendix contains the collaboration diagrams created for each key
use case during the reengineering of SHriMP. The labels on each diagram refer to the
key use case associated with it.
95Magnifying on a node
4.11 [mode = “magnify”]addUndoAction(undoMagnify)
FilterEvent (d)MouseEvent(m)
1. obj := getObjectClickedOn():Object2. [obj ia a Node] n := (Node)obj3. [obj ia a Node] art := getArtifact(n) : Artifact4. [obj ia a Node] fireMouseEvent(art, this)
4.8.2 focus on targets4.8.3 [arts has only one item]
filter = new Vector(); notFiltered = new Vector()4.8.4 [arts has only one item]
fireFilterEvent (children, filtered, notFiltered)4.8.5 [arts has only one item]
display children
4.2 display := getDisplay() : Object4.3 .object: getObject(): Object
:DisplayBean :MouseAdapter
m: ShrimpMouseEvent
mousePressed()
4.7 coords := getScreenCoordinates(): Vector4.8 focusOn (arts)4.9 endCoordinates := getScreenCoordinates(): Vector
4.8.4.4 filter (objects, filtered, notFiltered)
:FilterAdapterFilterBean
d: FilterEvent
4.8.4.1 objects := getObjects(): Vector4.8.4.2 filtered := getFilteredVector() : Vector4.8.4.3 notFiltered := getNotFilteredVector() : Vector
4.8.1 [arts has only one item] children :=getChildren() : Vector
arts: Artifact
4.10 [mode = “magnify”]undoMagnify = new UndoAction(display, coords, endCoordinates){
public UndoMagnify (display, voords) {this.display = display;this.coords = coords;this.endCoordinates = endCoordinates
}public void undo() {
display.focusScreenOnCoords(coords);}public void redo() {
disply.focusScreenOnCoords(endCoordinates)}
}
:UndoBean
:Selector
4.1 mode := getSelected (“ZoomMode” ) : Object4.4 [shift held down] clearSelected (“artifacts”)4.5 addObjectToSelected (“artifacts”, object)4.6 arts := getSelected (“artifacts”): Vector
96Magnify on the parent of a node
4.11 [mode = “magnify”]addUndoAction(undoMagnify)
MouseEvent(m)
1. obj := getObjectClickedOn():Object2. [obj ia a Node] n := (Node)obj3. [obj ia a Node] art := getArtifact(n) : Artifact4. [obj ia a Node] fireMouseEvent(art, this)
4.8.2 focus on targets
4.2 display := getDisplay() : Object4.3 .object: getObject(): Object
:DisplayBean :MouseAdapter m: ShrimpMouseEvent
mousePressed()
4.7 coords := getScreenCoordinates(): Vector4.8 focusOn (arts)4.9 endCoordinates := getScreenCoordinates(): Vector
4.10 [mode = “magnify”]undoMagnify = new UndoAction(display, coords, endCoordinates){
public UndoMagnify (display, voords) {this.display = display;this.coords = coords;this.endCoordinates = endCoordinates
}public void undo() {
display.focusScreenOnCoords(coords);}public void redo() {
disply.focusScreenOnCoords(endCoordinates)}
}
:UndoBean
:Selector
4.1 mode := getSelected (“ZoomMode” ) : Object4.4 [shift held down] clearSelected (“artifacts”)4.5 addObjectToSelected (“artifacts”, object)4.6 arts := getSelected (“artifacts”): Vector
4.6.2 [foreach artifact in arts] parents += getParents() : Vector
artifact: Artifact
97
4.4 [mode = “zoom”] undoZoom = new UndoAction(coords, display){
public void undo(){display.focusOnCoordinates (coords);
}public void redo() {
display.focusOnCoordinates (endCoordinates);}
public void setEndCoordinates (vector) {endCoordinates = vector
}}
4.3 [mode = “zoom”] coords = getScreenCoordinates(): Vector4.6 [mode = “zoom”] startZooming()
4.5 [mode = “zoom”] addUndoAction (undoZoom)
MouseEvent(m)
1. obj := getObjectClickedOn():Object2. [obj ia a Node] n := (Node)obj3. [obj ia a Node] art := getArtifact(n) : Artifact4. [obj ia a Node] fireMouseEvent(art)
4.2 display = getDisplay(): Display
:DisplayBean :MouseAdapter
m: ShrimpMouseEvent
mouseDown():UndoBean
:Selector
4.1. mode := getSelected (“zoomMode”): Object
Start Zooming
98Stop zooming
4.6 setEndCoordinates (coords)
MouseEvent(m)
1. obj := getObjectClickedOn():Object2. [obj ia a Node] n := (Node)obj3. [obj ia a Node] art := getArtifact(n) : Artifact4. [obj ia a Node] fireMouseEvent(art, this)
4.3 [mode = “zoom”] stopZooming()4.4 [mode = “zoom”] coords := getScreenCoordinates() : Vector
4.1 display = getDisplay(): Display
display: DisplayBean :MouseAdapter
m: ShrimpMouseEvent
mouseUp()
:Selector
4.2. mode := getSelected (“zoomMode”): Object
4.5 action := getLastAction() : Action
:UndoBeanaction :Action
99Start zooming out
4.4 [mode = “zoom”] undoZoom = new UndoAction(coords, display){
public void undo(){display.focusOnCoordinates (coords);
}public void redo() {
display.focusOnCoordinates (endCoordinates);}
public void setEndCoordinates (vector) {endCoordinates = vector
}}
4.3 [mode = “zoom”] coords = getScreenCoordinates(): Vector4.6 [mode = “zoom”] startZoomingOut()
4.5 [mode = “zoom”] addUndoAction (undoZoom)
MouseEvent(m)
1. obj := getObjectClickedOn():Object2. [obj ia a Node] n := (Node)obj3. [obj ia a Node] art := getArtifact(n) : Artifact4. [obj ia a Node] fireMouseEvent(art)
4.2 display = getDisplay(): Display
:DisplayBean :MouseAdapter
m: ShrimpMouseEvent
mouseDown():UndoBean
:Selector
4.1. mode := getSelected (“zoomMode”): Object
100
4.5 setEndCoordinates (coords)
MouseEvent(m)
1. obj := getObjectClickedOn():Object2. [obj ia a Node] n := (Node)obj3. [obj ia a Node] art := getArtifact(n) : Artifact4. [obj ia a Node] fireMouseEvent(art, this)
4.3 [mode = “zoom”] stopZoomingOut()4.4 [mode = “zoom”] coords := getScreenCoordinates() : Vector
4.1 display = getDisplay(): Display
display: DisplayBean :MouseAdapter
m: ShrimpMouseEvent
mouseUp()
:Selector
4.2. mode := getSelected (“zoomMode”): Object
4.5 action := getLastAction() : Action
:UndoBeanaction :Action
Stop zooming out
101
4.8 undoFisheyeOut =new UndoAction(display, artifacts, coords){
public void undo(){display.fisheyeToCoords (objects, coords);
}public void redo() {
display. fisheyeToCoords (objects, endCoordinates);}public void setEndCoordinates (vector) {
endCoordinates = vector}
}
4.9 addUndoAction(undoFisheyeOut)4.7 [artifact in arts] coords += getCoordinatesOf (artifact): Vector4.10 startFisheyeing (objects)
MouseEvent(m)
1. obj := getObjectClickedOn():Object2. [obj ia a Node] n := (Node)obj3. [obj ia a Node] art := getArtifact(n) : Artifact4. [obj ia a Node] fireMouseEvent(art, this)
4.10.2 [foreach object in objects] filter = new Vector(); notFiltered = new Vector()
4.10.3 [foreach object in objects]fireFilterEvent (siblings, filtered, notFiltered)
4.10.4 [foreach object in objects]start fisheyeing on object
4.2 display := getDisplay() : Object4.3.object:= getObject(): Object
:DisplayBean :Mouse_Adapter
m: ShrimpMouseEvent
mouseDown()
FilterEvent (d)
4.10.3.4 filter (objects, filtered, notFiltered)
:FilterAdapter
FilterBean
d: FilterEvent
4.10.3.1 objects := getObjects(): Vector4.10.3.2 filtered := getFilteredVector() : Vector4.10.3.3 notFiltered := getNotFilteredVector() : Vector
4.10.1 [foreach object in objects] siblings := getSiblings() : Vector
target: Artifact
:UndoBean
:Selector
4.1 zoomMode := getSelected (“ZoomMode” ) : Object4.4 [shift not held down] clearSelected (“artifacts”)4.5 addObjectToSelected (“artifacts”, object)4.6 arts := getSelected (“artifacts”): Vector
Start fisheyeing
102
4.5 [mode = “fisheye”] action := getLastAction() : Action4.3 [mode = “fisheye”] stopFisheyeing ()4.4 [mode = “fisheye”]
[foreach artifact in arts]coords += getCoordinatesOf(artifact) : Vector
MouseEvent(m)
1. obj := getObjectClickedOn():Object2. [obj ia a Node] n := (Node)obj3. [obj ia a Node] art := getArtifact(n) : Artifact4. [obj ia a Node] fireMouseEvent(art, this)
4.2 display := getDisplay() : Object:DisplayBean :Mouse_Adapter
m: ShrimpMouseEvent
mouseUp()
:UndoBean
:Selector
4.1 mode := getSelected (“ZoomMode” ) : Object
4.6 [mode = “fisheye”] arts := getArtifacts() : Vector4.7 [mode = “fisheye”] setEndCoordinates (coords)
action :Action
Stop fisheyeing
103
4.8 undoFisheyeOut =new UndoAction(display, artifacts, coords){
public void undo(){display.fisheyeToCoords (objects, coords);
}public void redo() {
display. fisheyeToCoords (objects, endCoordinates);}public void setEndCoordinates (vector) {
endCoordinates = vector}
}
4.9 addUndoAction(undoFisheyeOut)4.7 [artifact in arts] coords += getCoordinatesOf (artifact): Vector4.10 startFisheyeingOut (objects)
MouseEvent(m)
1. obj := getObjectClickedOn():Object2. [obj ia a Node] n := (Node)obj3. [obj ia a Node] art := getArtifact(n) : Artifact4. [obj ia a Node] fireMouseEvent(art, this)
4.10.2 [foreach object in objects] filter = new Vector(); notFiltered = new Vector()
4.10.3 [foreach object in objects]fireFilterEvent (siblings, filtered, notFiltered)
4.10.4 [foreach object in objects]start fisheyeing out on object
4.2 display := getDisplay() : Object4.3.object:= getObject(): Object
:DisplayBean :Mouse_Adapter
m: ShrimpMouseEvent
mouseDown()
FilterEvent (d)
4.10.3.4 filter (objects, filtered, notFiltered)
:FilterAdapter
FilterBean
d: FilterEvent
4.10.3.1 objects := getObjects(): Vector4.10.3.2 filtered := getFilteredVector() : Vector4.10.3.3 notFiltered := getNotFilteredVector() : Vector
4.10.1 [foreach object in objects] siblings := getSiblings() : Vector
target: Artifact
:UndoBean
:Selector
4.1 zoomMode := getSelected (“ZoomMode” ) : Object4.4 [shift not held down] clearSelected (“artifacts”)4.5 addObjectToSelected (“artifacts”, object)4.6 arts := getSelected (“artifacts”): Vector
Start fisheyeing out
104
4.5 [mode = “fisheye”] action := getLastAction() : Action4.3 [mode = “fisheye”] stopFisheyeingOut ()4.4 [mode = “fisheye”]
[foreach artifact in arts]coords += getCoordinatesOf(artifact) : Vector
MouseEvent(m)
1. obj := getObjectClickedOn():Object2. [obj ia a Node] n := (Node)obj3. [obj ia a Node] art := getArtifact(n) : Artifact4. [obj ia a Node] fireMouseEvent(art, this)
4.2 display := getDisplay() : Object:DisplayBean :Mouse_Adapter
m: ShrimpMouseEvent
mouseUp()
:UndoBean
:Selector
4.1 mode := getSelected (“ZoomMode” ) : Object
4.6 [mode = “fisheye”] arts := getArtifacts() : Vector4.7 [mode = “fisheye”] setEndCoordinates (coords)
action :Action
Stop fisheyeing out
105
4.5 [foreach child in children] childVisible := isVisible (child)4.9 [foreach child in children] setVisible (children, !open)
4.8 [mode = “magnify”]addUndoAction(undoMagnify)
MouseEvent(m)
1. obj := getObjectClickedOn():Object2. [obj ia a Node] n := (Node)obj3. [obj ia a Node] art := getArtifact(n) : Artifact4. [obj ia a Node] fireMouseEvent(art, this)
4.1 display := getDisplay() : Object4.2 .object: getObject(): Object
:DisplayBean :MouseAdapter
m: ShrimpMouseEvent
mousePressed()
4.4 open := false4.6 [foreach child in children]
[childVisible] open := true4.7 undoOpen = new UndoAction(display, children, open){
public void undo() {display.setVisible (children, open);
}public void redo() {
disply.setVisible(children, !open)}
}
:UndoBean
4.3 [object is an artifact]children := getChildren() : Vector
object: Artifact
Open/Close node
106
4.5 [foreach child in children] childVisible := isVisible (child)4.9 [foreach child in children] setVisible (children, !open)
4.8 [mode = “magnify”]addUndoAction(undoMagnify)
MouseEvent(m)
1. obj := getObjectClickedOn():Object2. [obj ia a Arc] arc := (Arc)obj3. [obj ia a Arc] relationship := getRelationship (arc) : Relationship4. [obj ia a Arc] fireMouseEvent(rel, this)
4.1 display := getDisplay() : Object4.2 .object: getObject(): Object
:DisplayBean :MouseAdapter
m: ShrimpMouseEvent
mousePressed()
4.4 open := false4.6 [foreach child in children]
[childVisible] open := true4.7 undoOpen = new UndoAction(display, children, open){
public void undo() {display.setVisible (children, open);
}public void redo() {
display.setVisible(children, !open)}
}
:UndoBean
4.3 [object is a relationship]children:= getChildren() : Vector
object: Relationship
Open/Close an arc
107
1. obj := getObjectClickedOn():Object2. [obj ia a Node] n := (Node)obj3. [obj ia a Node] art := getArtifact(n) : Artifact4. [obj ia a Node] fireMouseEvent(art, this)
4.7 undoMove = new UndoAction(display, coords){
public void undo(){displ;ay.moveArtifactsTo (artifacts, coords);
}public void redo() {
display.moveArtifactsTo (artifacts, endCoordinates)}public void setEndCoordinates (vector) {
endCoordinates = vector;}
}
4.8 addUndoAction(undoMove)4.6 [foreach artifact in artifacts]coords += getCoordinatesOf(artifact) : Vector
4.9 startMoving(artifacts)
MouseEvent(m)
4.1 display := getDisplay() : Object4.2.object:= getObject(): Object
:DisplayBean :Mouse_Adapter
m: ShrimpMouseEvent
mouseDown() :UndoBean
:Selector
4.3 [shift not held down] clearSelected (“artifacts”)4.4 addObjectToSelected (“artifacts”, object)4.5 arts := getSelected (“artifacts”): Vector
Start moving node
108
4.5 setEndCoordinates (coords)
MouseEvent(m)
4.2 stopMoving()4.3 coords := getScreenCoordinates() : Vector
4.4 [mode = “fisheye”] action := getLastAction() : Action
1. obj := getObjectClickedOn():Object2. [obj ia a Node] n := (Node)obj3. [obj ia a Node] art := getArtifact(n) : Artifact4. [obj ia a Node] fireMouseEvent(art, this)
4.1 display := getDisplay() : Object
:DisplayBean :Mouse_Adapter
m: ShrimpMouseEvent
mouseUp() :UndoBean
action :Action
Stop moving node
109
4.4 children := getChildren() : Vector
4.8.2 filtered := new Vector()4.8.3 notFiltered := new Vector()4.8.4.fireFilterEvent (children, filtered, notFiltered, display)4.8.5 change the layout and display
4.5 [child in children] coords += getCoordinatesOf (child): Vector
4.8 setLayoutMode (target, newMode)
:LayoutModeChangeAdapter l: LayoutModeChangeEvent
ZoomHotBoxButtonPressed()
1. newMode := getNewMode() : String2. display := getDisplay() : Object3. target := getTarget() : Object4. fireLayoutModeChangeEvent (target, newMode, display)
LayoutModeChangeEvent(l):HotboxBean
4.1 newMode := getNewLayoutMode() : String4.2 display := getDisplay() : Object4.3 target := getTarget() : Object
4.8.4.3 filter (objects)
FilterEvent(d):Filter_Adapter
FilterBean
d: FilterEventfilters out the artifacts and relationships
4.8.4.1 parent : = getParent() : Artifact4.8.4.2 objects := getObjects() : Vector
display:DisplayBean4.8.1 children := getChildren() : Vector
4.6 undoLayoutMode = new UndoAction(){public void undo() {
display.moveArtifactsTo (children, coords);}
public void redo() {display.setLayoutMode (target, newMode);
}}
4.7 addUndoAction (undoLayoutMode):UndoBean
target: Artifact
Change layout mode
110
3.6 addUndoAction (undoPanelMode)
:PanelModeChangeAdapter
p: PanelModeChangeEvent
ZoomHotBoxButtonPressed()
0. newLayout := getNewLayout() : String1. display := getDisplay() : Object2. target := getTarget() : Object3. firePanelModeChangeEvent(target, newLayout, display)
PanelModeChangeEvent(p):HotboxBean3.1 newMode := getNewPanelMode() : String3.2 display := getDisplay() : Object3.3 target := getTarget() : Object
3.4 oldMode = getPanelMode(target); 3.7 setPanelMode (target, newMode)
:DisplayBean
3.7.3.2 filter (objects, filtered, notfiltered)
FilterEvent(d)
:Filter_Adapter
FilterBean
d: FilterEvent
filters out the artifacts and relationships
3.7.3.1 objects := getObjects() : Vector
3.7.1 [newMode = “children”] children := getChildren():Vector
target: Artifact
3.7.2 filter = new Vector(); notFiltered = new Vector()3.7.3 [newMode = “children”]
fireFilterEvent (children, filtered, notFiltered, display)3.7.4 [newMode = “children”]
display (notFiltered)
:UndoBean
3.5 undoPanelMode = new UndoAction(){public void undo() {
display.setPanelMode (target, oldMode);}public void redo() {
display.setPanelMode (target, newMode);}
}
Change panel mode
111
:ZoomModeChangeAdapter
z: ZoomModeChangeEvent:SelectorBean
ZoomHotBoxButtonPressed()
1. fireZoomModeChangeEvent()
ZoomModeChangeEvent(z):HotboxBean
1.1 newMode := getNewZoomMode() : String
1.2 changeSelected (“zoom mode”, newMode)
Change zoom mode
112
:UndoActionAdapter
:UndoBean
BackButtonPressed()
1. fireUndoActionEvent()
UndoActionEvent(z):HotboxBean
1.1 undoLastAction ()
1.1.1 action = historyStack.pop()1.1.2 futureStack.push (action)1.1.3 action.undo()
Undo an action
113
:RedoActionAdapter
:UndoBean
ForwardButtonPressed()
1. fireRedoActionEvent()
RedoActionEvent(z):HotboxBean
1.1 redoLastAction ()
1.1.1 action = futureStack.pop()1.1.2 historyStack.push (action)1.1.3 action.undo()
Redo an action
114
:DisplayBean :KeyboardHotboxAdapter k: ShrimpKeyboardEvent
:OpenHotBoxAdapter
:OpenHotBoxEvent ohb
1. obj := getObjectUnderMouse():Object2. [obj ia a Node] n := (Node)obj3. [obj ia a Node] art := getArtifact(n) : Artifact4. [obj ia a Node] fireKeyboardEvent(art)
ShrimpKeyboardEvent(k)
:HotboxBean
4.1 objT: getObjectType(): String4.2 key := getKeyPressed() : char4.3a [objT = “artifact”] art :=getArtifact():Artifact
4.4a [objT =“artifact”] [key = Ctrl] setTargetArtifact(art)4.5a [objT =“artifact”] [key = Ctrl] setVisible (true)
4.4a.1 artifact := art4.5a.1 hotbox := getHotBoxPane() : Jpanel4.5a.2 fireOpenHotBoxEvent (hotbox, artifact)
OpenHotBoxEvent(ohb)
keyPressed(Ctrl)
4.5a.2.1 hotbox := getHotBoxPane() : JPanel4.5a.2.2 artifact := getArtifact() : Artifact
4.5a.2.2.1 moveHotBoxToArtifact (hotbox, artifact)4.5a.2.2.1 setHotBoxVisible (hotbox, true)
Open hotbox
115
:DisplayBean :KeyboardHotboxAdapter k: ShrimpKeyboardEvent
:OpenHotBoxAdapter
:CloseHotBoxEvent chb
1. obj := getObjectUnderMouse():Object2. [obj ia a Node] n := (Node)obj3. [obj ia a Node] art := getArtifact(n) : Artifact4. [obj ia a Node] fireKeyboardEvent(art)
ShrimpKeyboardEvent(k)
:HotboxBean
4.1 key := getKeyReleased() : char
4.2 [key = Ctrl] setVisible (false)
4.2.1 hotbox := getHotBoxPane() : Jpanel4.2.2 fireCloseHotBoxEvent (hotbox)
CloseHotBoxEvent(chb)
keyReleased(Ctrl)
4.2.2.1 hotbox := getHotBoxPane() : JPanel
4.2.2.1.1 setHotBox Visible (hotbox, false)
Close hotbox
116
5.3.1.3 display (disObj)5.3.1.4 stopDisplaying (stopDisObj)
5.3.1.1 disObj := getObjectsToDisplay(): Vector5.3.1.2 stopDisObj := getObjectsToStopDisplaying(): Vector
DataChangedEvent d
AddArtifactEvent(a)
0. obj := getObjectClickedOn():Object1.[obj is AddNodeButton] n := getSelectedNode() : Node2.[obj is AddNodeButton] parent := getArtifact(n) : Artifact3.[obj is AddNodeButton] artifactInfo := getNewArtifactInfo(): Vector4.[obj is AddNodeButton] newArt := new Artifact (artifactInfo) : Artifact5.[obj is AddNodeButton] fireAddArtifactEvent(parent, newArt)
5.1 parent := getParentArtifact(): Artifact5.2 newChild := getNewChild(): Artifact
:DisplayBean :AddArtifactAdapter A: AddArtifactEvent
mouseUp()
:DataBean
5.3 addArtifact (child, parent)
5.3.1 fireDataChangedEvent (child, null)
:DataChangedAdapter d:DataChangedEvent
Add a node
117
5.3.1.1 disObj := getObjectsToDisplay(): Vector5.3.1.2 stopDisObj := getObjectsToStopDisplaying(): Vector
DataChangedEvent d
5.3.1.3 display (disObj)5.3.1.4 stopDisplaying (stopDisObj)
RemoveArtifactEvent(a)
1. obj := getObjectClickedOn():Object2.[obj is AddNodeButton] n := getSelectedNode() : Node3.[obj is AddNodeButton] target := getArtifact(n) : Artifact4.[obj is AddNodeButton] fireRemoveArtifactEvent (target)
5.1 target := getTarget(): Artifact:DisplayBean :RemoveArtifactAdapter A: AddArtifactEvent
mouseUp()
:DataBean
5.3 [foreach relationship in relationships] removeRelationship (relationship)5.4 removeArtifact (target)
5.3.1 fireDataChangedEvent (null, relationship)5.4.1 fireDataChangedEvent (null, artifact)
:DataChangedAdapter d:DataChangedEvent
target: Artifact
5.2 relationships := getRelationships(): Vector
Remove a node
118
0. dataVector = new Vector()1. Start search thread2a. fireGeneralSearchEvent(dataVector , category )2b. Every 10 seconds update the
display with the informationin the dataVector
:GeneralSearchAdapter s: StartGeneralSearchEvent
:DataBean
SearchButton actionPerformed(e)
StartGeneralSearchEvent(s)
:SearchBean
2a.1 c:= getSearchCategory(): String2a.2 d := getStorageVector (): Vector
2a.3 beginArtifactSearch (c, d)
1.2.1 arts := findNextSetOfArtifacts(): Artifacts[]1.2.2 d.addElements (arts)
StopButton actionPerformed(e)
1. Kill search thread()
:SearchBean
Search
119
:Menu_Command
:SaveDataAdapter
SaveDataEvent sd
2.1 saveData()
1. cmd = getCmd(): String()2. [cmd = “save”]
fireSaveDataEvent()
:PersistantStorageBean
:DataBean
:RequestDataEventAdapterRequestDataEvent rd
2.1.1data := new Vector()2.1.2 fireRequestDataEvent( data)2.1.3 createPersistantStorage(data)
RequestDataEvent rd
2.1.2.1 data := getData() : Vector
2.1.2.2 data.addElements (getAllData())
Save data
120
:Menu_Command
:SaveDataAdapter
SaveViewEvent sv3.2 saveView(display)
1. cmd = getCmd(): String()2. [cmd = “saveView”]
display := getSelectedDisplay(): Object3. [cmd = “saveView”]
fireSaveViewEvent( display)
:PersistantStorageBean
:DataBean
:RequestDataEventAdapterRequestDataEvent rd
2.1.1data := new Vector()2.1.2 viewData = new Vector()2.1.2 fireRequestDataEvent( data)2.1.3 fireRequestViewEvent (viewData)2.1.4 createPersistantView (data, viewData)
RequestDataEvent rd
2.1.2.1 data := getData() : Vector2.1.2.2 data.addElements (getAllData())
SaveViewEvent sv
3.1 display = getDisplay(): Object
RequestViewEventAdapter
RequestViewEvent rv
:DisplayBeanRequestViewEvent rv
2.1.3.1 viewData := getViewData(): Vector
2.1.3.2viewData.addElements(getAllData())
Save view
Vita Surname: Best Given Names: Casey Alexander Place of Birth: Kingston, Jamaica Educational Institutions Attended:
University of Victoria 1997 to 2002 Brock University 1996 to 1997 Degrees Awarded:
B.Sc. University of Victoria 2000 Honours and Awards:
ASI Exchange Communications Award 2001 Deans Honour List 1996 Publications:
C. Best, M. Storey, and J. Michaud. Designing a Component-Based Framework for Visualization in Software Engineering and Knowledge Engineering. Published in the Proceedings for the Conference on Software Engineering and Knowledge Engineering (SEKE 2002), Iscia, Italy, July 2002. M. Storey, C. Best, J. Michaud, D. Rayside, M. Litoiu, and M. Musen. SHriMP Views: An Interactive Environment for Information Visualization and Navigation. Published in the Proceedings for CHI 2002, Minneapolis, Minnesota, April 2002. M. Storey, C. Best, N. Noy, R. Fergerson, M. Musen, and N. Ernst. Jambalaya: An Interactive Environment for Exploring Ontologies. Published in the Proceeding for International Conference on Intelligent User Interfaces (IUI 2002), San Francisco, California, United States, January 2002. M. Storey, C. Best, and J. Michaud. SHriMP Views: An Interactive Environment for Exploring Java Programs. Published in the Proceeding for the International Workshop on Program Comprehension (IWPC 2001), Toronto, Ontario, May 2001. D. Rayside, M. Litoiu, M. Storey and C. Best. Integrating SHriMP with the IBM WebSphere Studio Workbench. Published in the Proceedings for CASCON 2001, Toronto, Ontario, November 2001. M. Storey, M. Musen, J. Silva, C. Best, N. Ernst, R. Fergerson, and N. Noy. Jambalaya: Interactive visualization to enhance ontology authoring and knowledge acquisition in Protégé. Appeared in "Workshop on Interactive Tools for Knowledge Capture", K-CAP-2001.
UNIVERSITY OF VICTORIA PARTIAL COPYRIGHT LICENSE
I hereby grant the right to lend my thesis (or dissertation) to users of the University of Victoria Library, and to make single copies only for such users or in response to a request from the Library of any other university, or similar institution, on its behalf or for one of its users. I further agree that permission for extensive copying of this thesis for scholarly purposes may be granted by me or a member of the University designated by me. It is understood that copying or publication of this thesis for financial gain by the University of Victoria shall not be allowed without my written permission. Title of Thesis/Dissertation: Designing a Component-Based Framework for A Domain Independent Visualization Tool Author ____________________
Casey Best July 12, 2002