The three principal investigators have extensive experience in building
software reverse engineering and visualization tools, including Rigi, PBS,
Over the past decade, we have directly experienced many facets of the
tool adoption problem.
There are two critical issues. First, our tools had inadequate cognitive
support to ease the complex software engineering tasks programmers
perform. This problem became evident through informal feedback, user
and structured tool demonstrations [Sim00, Storey01a].
Second, our tools cannot do everything and must leverage other tools
via interoperability mechanisms such as: data integration (so tools
can read and write common formats), control integration (so one tool
can control another), and presentation integration (so tools have the
same, familiar look-and-feel). For example, the scripting layeer in
Rigi allows it to coordinate other tools or to be controlled by other
tools. Tool builders have exploited this feature successfully to create
new tool environments.
For new tools to be successfully adopted, they must be compatible
with both existing users and other tools.
In the follwing, we describe the issues of cognitive
common office tools, and tool
interoperability, which are central to our ongoing research.
Software development tools aid software engineers by participating
in their thinking and work. The assistance can include helping them
make complicated decisions in the context of uncertainty, helping them
perform change analysis, or assisting them in understanding software
Thus, in this proposal when we use the term cognitive support, we mean
the principles and means by which cognitive software processes are
supported or aided by software engineering tools. Walenstein's PhD
thesis includes a survey of the types of phenomena that comprise cognitive
support, including external memories, various external structures,
and scaffolding. It also proposes methods for systematically enumerating
the cognitive support provided by tools. In our ACSE project, we will
specifically investigate what kind of cognitive support is needed and
suited for software engineering tools, and will examine how to leverage
the cognitive support already provided by existing office tools effectively.
Extending Common Office
Office suites are highly popular platforms that typically offer a
number of programmable core applications for document creation, drawing,
database storage, spreadsheet, and presentation. Examples of these
suites include Microsoft Office XP, Lotus SmartSuite, Sun StarOffice,
and Corel WordPerfect Office. Other popular platforms include infrastructures
such as Adobe Acrobat and Lotus Notes. A few software engineering environments
exploit the functionality of such common tools.
The Desert environment
includes a custom editor for producing source code and architectural
documentation. This editor uses the Adobe FrameMaker application extensively.
Also, the Visual
Design Editor (VDE) is a domain-specific graph editor built on
top of Microsoft's PowerPoint application using the Visual Basic scripting
A New Era in Interoperability
Interoperability among all tools in the software development life
cycle is still an elusive goal. However, a remarkable array of middleware
technology exists for tool developers, including XML standards, scripting
languages, model-driven architectures, and plug-in platforms. For example,
IBM offers Eclipse (branded
as Websphere Studio Workbench), a recent, innovative, open source,
plug-in architecture into which seemingly unrelated tools are effectively
Another important event in the tool development market is OMG'S
Model-Driven Architecture (MDA), which promises rapid development
of cross-platform interoperability solutions, ease of portability
to other middleware platforms, and improved productivity when using
multiple middleware platforms.
In our ACSE project, we also expect to exploit selected W3C standards
and recommendations. In various research projects over the past decade,
we have struggled with many tool interoperability issues involving
data, control, and presentation integration. For example, we had moderate
success in the adoption of RSF as an exchange format for graphs [Wong98].
Now, we can leverage GXL,
an XML-based graph exchange language developed by the CSER community.
Also, we have advocated making tools more flexible and extensible through
end-user programming (e.g., Rigi [Tilley94b, Tilley95])
and pervasive scripting [Wong99]
using a scripting language such as Tcl. Now, we can exploit ECMAScript,
a standard used in Web applications. In addition, we have explored
the creation of personal information spaces [Tilley94a].
Now, we can use Scalable
Vector Graphics (SVG), a W3C recommendation for data-driven, personalized,
and scalable graphics which can be embedded seamlessly on various platforms.
[Storey98b] M.-A. Storey; K. Wong;
and H. Müller. "How do program Understanding Tools Affect
how Programmers Understand Programs?" J. of Science of Computer
[Sim00] S. Sim and M.-A. Storey. "A
Structured Demonstration of Program Comprehension Tools," IEEE
7th Working Conf. on Reverse Eng. (WCRE '00), Nov. 2000.
[Storey01a] M.-A. Storey, S. Sim
and K.Wong, "A Collaborative Demonstration of Reverse Engineering
Tools: The SORTIE Project," http://www.csr.uvic.ca/chisel/collab/.
[Walenstein01] A. Walenstein. "Cognitive
Support in Software Engineering Tools: A Distributed Cognition Environment",
Ph.D. Thesis, Simon Fraser University, Oct. 2001
[Wong98] K. Wong. Rigi User's Manual,
University of Victoria, June 1998.
[Tilley94b] S. Tilley, K. Wong, M.-A.
Storey and H. Müller. "Programmable Reverse Engineering," Int.
J. of Software Eng. and Knowledge Eng., 4:4, pp. 501-520, Dec. 1994.
[Tilley95] S. Tilley. Domain-retargetable
Reverse Engineering, Ph.D. Thesis, Department of Computer Science,
University of Victoria, Jan. 1995.
[Wong99] K. Wong. Reverse Engineering
Notebook, Ph.D. Thesis, Dept. of CS, UVic, Oct. 1999.
[Tilley94a] S. Tilley. "Domain-Retargetable
Reverse Engineering II: Personalized User Interfaces," IEEE Int.
Conf. on Soft. Maint. (ICSM '94), pp. 336-342, Sep. 1994.