131
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.

Designing a Component-Based Framework

  • Upload
    sumeja

  • View
    9

  • Download
    2

Embed Size (px)

DESCRIPTION

Designing a Component-Based Framework for A Domain Independent Visualization Tool

Citation preview

Page 1: Designing a Component-Based Framework

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.

Page 2: Designing a Component-Based Framework

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.

Page 3: Designing a Component-Based Framework

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)

Page 4: Designing a Component-Based Framework

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

Page 5: Designing a Component-Based Framework

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

Page 6: Designing a Component-Based Framework

vi

List of Tables TABLE 1: THE CORE USE CASES USED TO DESIGN THE NEW ARCHITECTURE........................ 34

Page 7: Designing a Component-Based Framework

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

Page 8: Designing a Component-Based Framework

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.

Page 9: Designing a Component-Based Framework

ix

Dedication

To Alex.

Page 10: Designing a Component-Based Framework

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

Page 11: Designing a Component-Based Framework

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.

Page 12: Designing a Component-Based Framework

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.

Page 13: Designing a Component-Based Framework

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

Page 14: Designing a Component-Based Framework

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].

Page 15: Designing a Component-Based Framework

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

Page 16: Designing a Component-Based Framework

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.

Page 17: Designing a Component-Based Framework

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]).

Page 18: Designing a Component-Based Framework

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

Page 19: Designing a Component-Based Framework

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

Page 20: Designing a Component-Based Framework

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.

Page 21: Designing a Component-Based Framework

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

Page 22: Designing a Component-Based Framework

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).

Page 23: Designing a Component-Based Framework

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

Page 24: Designing a Component-Based Framework

15

reengineered the SHriMP visualization tool into a component-based framework using

Java Beans for the purpose of tool interoperability and extensibility.

Page 25: Designing a Component-Based Framework

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.

Page 26: Designing a Component-Based Framework

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

Page 27: Designing a Component-Based Framework

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)

Page 28: Designing a Component-Based Framework

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.

Page 29: Designing a Component-Based Framework

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,

Page 30: Designing a Component-Based Framework

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.

Page 31: Designing a Component-Based Framework

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

Page 32: Designing a Component-Based Framework

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.

Page 33: Designing a Component-Based Framework

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].

Page 34: Designing a Component-Based Framework

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

Page 35: Designing a Component-Based Framework

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

Page 36: Designing a Component-Based Framework

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

Page 37: Designing a Component-Based Framework

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.

Page 38: Designing a Component-Based Framework

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

Page 39: Designing a Component-Based Framework

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,

Page 40: Designing a Component-Based Framework

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

Page 41: Designing a Component-Based Framework

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].

Page 42: Designing a Component-Based Framework

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.

Page 43: Designing a Component-Based Framework

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

Page 44: Designing a Component-Based Framework

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.

Page 45: Designing a Component-Based Framework

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

Page 46: Designing a Component-Based Framework

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.

Page 47: Designing a Component-Based Framework

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

Page 48: Designing a Component-Based Framework

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

Page 49: Designing a Component-Based Framework

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.

Page 50: Designing a Component-Based Framework

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.

Page 51: Designing a Component-Based Framework

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

Page 52: Designing a Component-Based Framework

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.

Page 53: Designing a Component-Based Framework

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.

Page 54: Designing a Component-Based Framework

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.

Page 55: Designing a Component-Based Framework

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

Page 56: Designing a Component-Based Framework

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é.

Page 57: Designing a Component-Based Framework

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

Page 58: Designing a Component-Based Framework

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

Page 59: Designing a Component-Based Framework

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

Page 60: Designing a Component-Based Framework

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.

Page 61: Designing a Component-Based Framework

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

Page 62: Designing a Component-Based Framework

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.

Page 63: Designing a Component-Based Framework

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.

Page 64: Designing a Component-Based Framework

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

Page 65: Designing a Component-Based Framework

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

Page 66: Designing a Component-Based Framework

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

Page 67: Designing a Component-Based Framework

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.

Page 68: Designing a Component-Based Framework

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.

Page 69: Designing a Component-Based Framework

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

Page 70: Designing a Component-Based Framework

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

Page 71: Designing a Component-Based Framework

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).

Page 72: Designing a Component-Based Framework

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

Page 73: Designing a Component-Based Framework

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

Page 74: Designing a Component-Based Framework

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

Page 75: Designing a Component-Based Framework

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

Page 76: Designing a Component-Based Framework

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

Page 77: Designing a Component-Based Framework

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

Page 78: Designing a Component-Based Framework

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

Page 79: Designing a Component-Based Framework

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.

Page 80: Designing a Component-Based Framework

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).

Page 81: Designing a Component-Based Framework

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.

Page 82: Designing a Component-Based 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.

Page 83: Designing a Component-Based Framework

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

Page 84: Designing a Component-Based Framework

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.

Page 85: Designing a Component-Based Framework

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

Page 86: Designing a Component-Based Framework

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

Page 87: Designing a Component-Based Framework

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

Page 88: Designing a Component-Based Framework

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

Page 89: Designing a Component-Based Framework

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.

Page 90: Designing a Component-Based Framework

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

Page 91: Designing a Component-Based Framework

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

Page 92: Designing a Component-Based Framework

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

Page 93: Designing a Component-Based Framework

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.

Page 94: Designing a Component-Based Framework

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).

Page 95: Designing a Component-Based Framework

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.

Page 96: Designing a Component-Based Framework

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.

Page 97: Designing a Component-Based Framework

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.

Page 98: Designing a Component-Based Framework

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

Page 99: Designing a Component-Based Framework

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.

Page 100: Designing a Component-Based Framework

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

Page 101: Designing a Component-Based Framework

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

Page 102: Designing a Component-Based Framework

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.

Page 103: Designing a Component-Based Framework

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.

Page 104: Designing a Component-Based Framework

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

Page 105: Designing a Component-Based Framework

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

Page 106: Designing a Component-Based Framework

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

Page 107: Designing a Component-Based Framework

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

Page 108: Designing a Component-Based Framework

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

Page 109: Designing a Component-Based Framework

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

Page 110: Designing a Component-Based Framework

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

Page 111: Designing a Component-Based Framework

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

Page 112: Designing a Component-Based Framework

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

Page 113: Designing a Component-Based Framework

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

Page 114: Designing a Component-Based Framework

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

Page 115: Designing a Component-Based Framework

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

Page 116: Designing a Component-Based Framework

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

Page 117: Designing a Component-Based Framework

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

Page 118: Designing a Component-Based Framework

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

Page 119: Designing a Component-Based Framework

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

Page 120: Designing a Component-Based Framework

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

Page 121: Designing a Component-Based Framework

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

Page 122: Designing a Component-Based Framework

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

Page 123: Designing a Component-Based Framework

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

Page 124: Designing a Component-Based Framework

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

Page 125: Designing a Component-Based Framework

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

Page 126: Designing a Component-Based Framework

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

Page 127: Designing a Component-Based Framework

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

Page 128: Designing a Component-Based Framework

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

Page 129: Designing a Component-Based Framework

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

Page 130: Designing a Component-Based Framework

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.

Page 131: Designing a Component-Based Framework

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