Chimera: Hypertext for Heterogeneous SoftwareEnvironments

Kenneth M. Anderson, Richard N. Taylor, E. James Whitehead, Jr.*Depamrtent of Information and Computer Science

University of California, IrvineIrvine, California 92717-3425 U.S.A.

FAX +1.714-856-4056e-maik (kanderso,taylor,ejw) @its.uci.edtt

ABSTRACT

Emerging software development environments arecharacterized by heterogeneity they are composed of diverseobject stores, user interfaces, and tools. This paper presentsan approach for providing hypertext services in thisheterogeneous setting. Central notions of the approachinclude the following. Anchors are established with respectto interactive views of objects, rather than the objectsthemselves. Composable, n-ary links can be establishedbetween anchors on different views of objects stored indistinct object bases. Viewers (and objects) may beimplemented in different programming languages affordedby a client-server architecture. Multiple, concurrently activeviewers enable multimedia hypertext services. The paperdescribes the approach and presents an architecture whichsupports it. Experience with the Chimera prototype and itsrelationship to other systems is described.

Categories and Subject Descriptor:H.5. 1 [Multimedia information systems]D.2.2 [Software Engineering]: Tcmls and techniques;

1.7.2 [Document preparation] Hypertexthyperm-,General Terms Design, ExperimentationAdditional Key Words and phrases: heterogeneoushypertext, hypertext system architectures, link servers,separation of concerns, software development environments.

*This material is based upon work sponsored by the Advanced

Research Projects Agency under Grant Number MDA972-91-J-

1010. The content of the information does not necessarily

reflect the position or the policy of the Government and no

official endorsement should be inferred.

Permission to copy without fee all or part of this material is

granted provided that the copies are not made or distributed for

dwect commercial advantage, the ACM copyright notice and

the title of the publication and its date appear, and notice is

given that copyright is by permission of the Association for

Computing Machinery. To copy otherwise, or to republish,

requires a fee andJor specific permission.

631994 ACM 0-89791 -640-9/94/0009/!$3.50

1 INTRODUCTION

Software development environments (SDES) are used todevelop and maintain a diverse collection of highlyinterrelated software objects [2, 8, 20, 35]. Large softwaresystems may, for example, consist of multiple versions ofrequirements specifications, designs, prototypes, code, testinformation, scripts, documentation, and so on. Theconnections between these components are many andcomplex. Establishing and exploring these connections aremajor tasks of development, program understanding, andmaintenance. Researchers have recognized that the size,complexity, and interconnectedness of these systems place asevere cognitive load on software engineers which oftenleads to errors at high levels of system abstraction, such asrequirements and design [1, 17].

It has been suggested that the attributes of hypertext makeit art excellent technology for capturing and visualizingrelations in a SDE [7]. Providing hypertext capabilities in aSDE allows an engineer to freely associate objects withoutregard to the type of those objects or where they are stored.These relationships can then be accessed at a later time

through a convenient user interface which allows the

engineer to easily navigate them [30] 1. Yet while someexcellent work has taken place in this area [3, 4, 7, 9, 10,11, 22, 24, 29, 31], it is clear that no single system to datehas effectively addressed all the technical challenges posedby this task.

1We recognize that some in the software engineering

community would argue that more conventional object

management systems are the appropriate technology for

capturing relations and that free object association should not

be allowed. The purpose of this paper is not to argue this point.

Our perspective is that given some engineers prefer the

hypertext approach, we examine how the approach may be

supported.

ECHT ’94 Proceedings 94 September 1994

We believe that the following technical features are amongthose which need to be present in hypertext systems

intended to support SDE activities.

Heterogeneous object editor & viewer support.SDES contain a wide variety of tools for developing andmanipulating objects. Different kinds of editors are used fordifferent types of objects. SDES also increasingly includemultiple viewers of single objects, where each viewerpresents different aspects of the object, perhaps usingdifferent depiction styles. It is unlikely that softwaredevelopment teams will give up their favorite tools inexchange for hypertext functionality. Thus a monolithicapproach to providing hypertext services to a SDE would be

ineffective. Ideally all editors and viewers3 in anenvironment should be able to use hypertext services andqxmd to hypertext events.

Anchors specialized to particular views. Giventhat different viewers of a single object may presentstrikingly different depictions, or that one viewer maypresent a depiction of information synthesized from severalseparate objects, anchors seem more naturally-ornecessarily-associated with views, rather than objects.

Multiple-view, concurrent, and active displays.Since a software developer is typically engaged inexamining and changing many different related objects “atonce” it is most supportive to provide a system whichenables many views to be present simultaneously, whereseverrd views may be of the same objec~ and where actionsin views maybe autonomous and concurrent.

Links across heterogeneous object managers.SDES manage such a wide variety of objects, of differentlegacies, types, and possessing different object managementconstraints, that large scale SDES are now beginning tosupport multiple, heterogeneous object managers. It isnonetheless essential to be able to establish links betweenobjects managed by different repositories.

Action specifications on both anchors andlinks. Given that many different users, of differentabilities and training, may be collaborating on a projectusing a SDE, it seems useful to provide programmableactions on both anchors and links so that actions could, forexample, be determined as a function of who selected ananchor in a particular view, or how a particular linktraversal was requested.

2There is some overlap with our list and the fifteen

assumptions listed by Leggett and Schnaae when discussing

hypermedia-in-the-large [21 ]. Since we arrived at our list

independently, we view this as an indication our approach and

contributions have significant value outside the domain of

software development environments.3From now on we will use the term “viewer”* to denote tOOh

capable of visually depicting an object and which may include

interactive editing capabilities.

Scalable (composable) links. Hierarchy andabstraction are two key tools that engineers employ inundertaking large-scale problems. Hypertext support forSDES must similarly provide such capabilities for dealingwith large, complex, aggregations of information.

n -ary links. Software development often involvessituations where several pieces of information jointlyrepresent a single concept or are in some sense “grouped.”We claim therefore that hypertext support for SDEapplications should provide such capabilities in the form ofn-ary links.

Multiple contexts. The process of softwaredevelopment involves many stages (often including cycles)where different types of information are more importantthan others. Often software team members have manydifferent roles both between and within these differentstages. As such, hypertext support for SDES should be ableto take into account the current stage of the softwaredevelopment process and enable engineers to quickly accesscritical information.

This paper describes a set of concepts which satisfy this setof requirements, and a prototype which implements thedescribed concepts. The notion of viewers of objects is atthe heart of the conceptualization. We postulate anenvironment of many types of objec~, display or editing ofan object requires use of a viewer. Not all viewers are of thesame typty how they manage their display is their decision.We have developed a set of interfaces whereby a viewerannounces to the hypertext system the anchors it defines forits view of its object(s), These view-specific anchors canthen participate in (many) links. Links maybe consideredobjects in their own right, and may thus have viewersassociated with them which can define yet additionalanchors. These anchors can participate in other links, and inso doing provide hierarchical composition.

This approach brings along with it some limitations andrequirements. In order for our techniques and interfaces to beof value, the viewers in the SDE must be programmed toutilize the hypertext system’s application program interface(API). The viewers are also responsible for maintaining(over time) the associations they make between the anchorsthey announce to the hypertext system and the objects orprocess artifacts (e.g. a button in a window) that theydisplay in their views.

Since heterogeneous environments are most oftenmuhilingttal and distribua the generic architecture and ourimplementation is client-server based and a multilingualremote procedure call (RPC) mechanism (Q [231) is

utilized. Our prototype implementation, Chimera4, utilizesthe Pleiades object management system from the Universityof Massachusetts [32] for persistence of the server’s datastructures. To illustrate the concepts and the Chimera

4According to Merriam-Webster’s 9th Collegiate Dictionary,

“an individual, organ, or part consisting of tissues of diverse

genetic constitution... ”

ECHT ’94 Proceedings 95 September 1994

Set of Views

Set of Anchors

Set of Links

displays ~v

I I

rLE!EEJ

Object 1 ~

Viewers oChart

land2 Viewer

~ displaysw

‘“yAnchor 2

I Link 1 I

(Anchor 1, Anchor 2)

Figure 1: Chimera Concept Example. Chimera’s hypertext concepts are shown on the left. Two viewersare combined with one object to produce two distinct views. An anchor is added to each view and thencombined in one link. On the right, an example hyperweb presents a data file (stored as a file in theoperating system) being displayed by two different viewers. One viewer displays the data as aspreadsheet, creating a spreadsheet view of the data file.l%e other viewer displays the data as a chart,creating a chart view of the same data. The two distinct anchors are indicated by a black box in thespreadsheet, and a black underline in the chart. The anchors are stored in the Chimera database, not inthe data file. The two anchors are members of the link. Attribute-value pairs are not indicated to avoid

system, we discuss an application in which graphical viewsof a flight simulator’s instrument panel are hyperlinked tostatements in a requirements document maintained by

FrameMakerm5. The Chiron user interface development andmanagement system (Chiron) from the University ofCalifornia, Irvine [33, 34] is used as the graphical viewer ofthe instrument panel.

The remainder of the paper is organized as follows. Thenext four sections present the basic concepts, the conceptualarchitecture, our particular implementation, and our futureplans. We then discuss related work and conclude.

2 HYPERTEXT CONCEPTS

Chimera has a flexible set of hypertext concepts that mapwell into the domain of software developmentenvironments. Our concepts include objects, viewers,views, anchors, links, attribute-value pairs, and hyperwebs(See Figure 1). In the remainder of this section, we defineeach concept and provide an example which illustrates how

they can be applied in a sofhvare development environment.

Objects. Objects are named, persistent entities whoseinternal structure is unknown and irrelevant to Chimera.

5FrarneMaker is a registered trademark of Frame Technology

Corporation.

Viewers. Viewers are named active entities that displayobjects. The operations provided by a viewer are specflc tothe viewer and the type of objects it displays. Typicallyviewers provide browsing, creation, and editingfunctionality on objects within their domain.

Views. Views denote a pair (v,o) where v is a viewer foran object o. Note that an object maybe displayed by morethan one viewer, and thus participate in multiple views.Views contain anchors.

Anchors. Anchors are defined and managed by viewers inthe context of a view. An anchor tags some portion of aview as an item of interest. Anchors are tailored by a viewerto the particular view of the object being displayed. Unlikehypertext systems which require direct anchor to objectmappings [12], with anchors often embedded in the objectsthemselves [25], Chimera anchors may represent somepurely visual componen~ such as a button or other interfaceelement. Even when creating anchors on the view of anobject, the underlying object may be left unmodified, stillusable by tools unaware of Chimera’s existence.

Links. A link is a set of anchors. Links relate portions ofviews. Links are fwst-class objects in Chimera and a viewercan be constructed to display them. Anchors maybe createdon these link views and included in other links. In thismanner Chimera supports “links to links,” an important

ECHT ’94 Proceedings 96 September 1994

abstraction which supports construction of large, complexhyperwebs.

Attribute-Value Pairs. Each instance of a Chimerahypertext concept can have an arbitrary number of uttribute-value pairs associated with it. An attribute-value pairconsists of two associated strings where one string containsthe attribute’s name, the other its value. Attribute-valuepairs are commonly used in hypertext systems to providerun-time semantics or behavior for hypertext entities [3].Example uses of attributes include providing access to ananchor only to the user who created it, or link viewersfiltering their displays to show only certain types of links.

Hyperwebs. A collection of objects, viewers, views,

anchors, and links along with their attributes is a Chimerahyperweb. A hyperweb is similar to Leggett’s hypermedia[21] and HdlSZ’S hypertext [13].

Example. Several of the Chimera hypertext concepts aredemonstrated by a term project tlom a senior level softwareengineering project class. For this project, studentsaugmented a flight simulator program distributed withChiron so that its design and requirements documents, bothcreated with FrameMaker, are efficiently accessed via linktraversal.

At the heart of the flight simulator are abstract data types(ADTs) representing the state of the aircraft, including theaircraft’s pitch, roll, heading, altitude, and speed. Gauges inthe flight simulator’s cockpit visualize information fromthese ADTs as they are updated by the simulator’s flightequations. Chiron performs this visualization. In thisapplication the ADTs are considered Chimera objects,Chiron is considered a Chimera viewer, and the gauges thatChiron produces are Chimera views.

The flight simulator requirements and design documentswere written using FrameMaker. Both documents areconsidered Chimera objects. FrameMaker allows users toaccess and edit these documents, hence FrameMaker is a(Chimera) viewer. The display of the requirementsdocument represents a Chimera view, as does the display ofthe design document. Anchors are created on the display ofthe section titles within these documents.

Students added two buttons to each flight simulator gauge,marked “Requirements” and “Design” respectively. Thesebuttons do not visualize any portion of the ADT representedby each gauge, rather they are the visual indication of twoChimera anchors created on the gauge/view. For eachgauge, the Requirements anchor was put in a link alongwith an anchor on the top of the requirements documentsection describing that gauge. Thus, a single click of the

requirements button takes the engineer from the mnning(“flying”) simulator to the requirements for that gauge inthe requirements document. The Design anchor was

similarly linked to the design document.

The artificial horizon gauge demonstrates the value of theChimera view concept. This gauge produces a visualizationwhich is a synthesis of information from two objects, thepitch ADT and the roll ADT. This gauge represents adistinct view from the gauges/views that just show thevalues of the two ADTs separately. Students were able toadd their anchor buttons to all three views. Thus while thereis no object in the application which directly corresponds tothe artificial horizon view, the engineer is nonetheless ableto link the gauge to its appropriate requirements document.Moreover since Chimera anchors are defined on a viewrather than an object, anchors can be added to multiplesimultaneous views of the same object.

3 A CONCEPTUAL ARCHITECTURE

Section 2 outlined Chimera’s hypertext concepts and gave ashort example mapping them into a reasonably complexsoftware development project. This section sketches aconceptual architecture which supports these concepts. Thisarchitecture adopts a client-server approach to providinghypertext services. We term this the Chimera architecture(See Figure 2).

A client-server approach is adopted to help meet thechallenges of a heterogeneous SDE in which there are manyusers. A client-server approach allows multiple users ondifferent machines to access a hyperweb from a dymmicallychanging set of viewers; hypertext events originate in oneviewer and propagate to (potentially many) others via theserver. The use of a server supports a multilingual approachwhere clients can be written in different programminglanguages, each of them accessing the server through theirlanguage-specific API. The use of a server also keepsprocess and object file sizes down since code to manage ahyperweb is centralized in the server.

We now discuss the components of the Chimeraarchitecture which are the Chimera server, the Chimeraclients, the process invoker, and the external tools andsystems that populate any SDE.

3.1 Chimera Server

The primary responsibilities of the Chimera server are asfollows.

● Provide services which allow clients access to Chimera’shypertext concepts.

ECHT ’94 Proceedings 97 September 1994

f b InvokesViewer A duos,,,,, n

Viewer C

Viewer B ChimeraClient Client Viewer D

Chimera *API

~ ~ ~

: Read/Write ~ Read/Write ~ Read/Write

i i i

@ @ e

Viewer-speeitlc Chimera Internal Database Viewer-speeitlc

persistent data persistent data

Figure 2 Example instance of Chimera conceptual architecture. Chimera clients consisting of one or

more viewers access the Chimera server to provide hypertext seMces to their users. Note that there are no

restrictions on the number of clients, the number of viewers per clien~ and that the same viewer can appear

in multiple clients. The process invoker can invoke Chimem clients as directed by the Chimera server.

Chimera clients can rdso access external systems in the environment, such as a graphics server or a sound

server. All entities are separate Unix processes and can read/write information to a repository such as a fide

system or object manager.

● Martage the persistence of a hyperweb. Through the use ofan object manager, the Chimera server must map instancesof Chimera’s hypertext concepts into a persistent store. TheChimera server is not responsible for the persistent storageof client object data.

. Receive, route, and generate hypertext events6. The servermust also provide a means for clients to register interest ina subset of these events.

c Manage each connected client. For instance, the Chimeraserver should know what viewers are running, what vieweach viewer is in, and if the viewer is ready to receivehypertext events.

3.2 Process Invoker

The process invoker is responsible for spiming up Chimeraclients. This occurs when the Chimera server determines itneeds to send a hypertext event to a viewer that is notrunning. The process invoker maintains a mapping between

viewer names and executable programs7. When the Chimera

6The set of hypertext events are left undefined in the

concepturd architecture; only their existence is important at

this point.

7This map is supplied and maintained by the administrator of a

Chimera hyperweb.

server sends the process invoker a viewer name, the processinvoker invokes the executable program via operatingsystem services.

3.3 Chimera Client

A Chimera client includes one or more viewers and thelibraries needed to communicate with a Chimera server.Each viewer in a client is responsible for the following.

● definition of the concepts “object” and “view”. Eachviewer must determine the precise meaning of theseconcepts in their own context. While this is typicallystraightforwar~ ambiguity may arise especially with respectto versions of objects.

“ definition of the concept “anchor”. This includesidentifying what elements of a view can have anchorsattached to them, how these anchors are created and deleted,how the presence of an anchor is indicated, and whatattributes can be assigned to an anchor. Since each viewermay choose to implement this functionality in different

ways, a uniform interaction style cannot be guaranteed*.

8 This is potentially troublesome since the user has to

remember how this hypertext functionality is invoked for each

viewer [9]. This is a design trade-off involving ease-of-use,

open systemst Snd customized interfaces. We believe r~uiring

ECHT ’94 Proceedings 98 September 1994

This is one of many issues facing designers of openhypertext systems [4, 15, 25].

● a mapping function from an anchor identifier (receivedfrom the Chimera server at the time the anchor is created)into a specific region or object of its display.

“ an event handler which will respond to hypertext eventsfrom the Chimera server.

● communicating with the Chimera server. This includesregistering for hypertext events, indicating its current view(which may change if the viewer is asked by its user todisplay a different object), accessing the services related toChimera’s hypertext concepts, and letting the Chimeraserver know that it is ready to receive hypertext events (thisprovides time for a newly invoked client to initialize beforethe server sends it any hypertext events).

● providing a mechanism for persistent storage of object

3.4 External Systems

Viewers in a Chimera client may directly interface with theuser, may require the use of external tools, or may use auser interface management system to present their interface.Chimera does not place any restrictions on what externalsystems are accessed by its clients or how these clientscommunicate with their users.

4 AN IMPLEMENTATION ARCHITECTURE

We have constructed a prototype of Chimera to validate theconcepts presented in Section 2 and the conceptualarchitecture of Section 3. This prototype has been used tosupport the example described in Section 2 (as well asmany other applications). Our prototype was constructed onSun SPARCstations under the Unix operating systemusing the Ada and C programming languages. In thissection, we describe the design choices that we made inmapping the conceptual architecture into a workingprototype and discuss other issues concerning the prototypesuch as performance and size statistics.

4.1 Chimera Server

The Chimera server realizes and in some cases exceeds thegoals set out for it in Section 3.1. We discuss each goal inroughly the order they were presented in Section 3.1 in theparagraphs below.

At the heart of the Chimera server lies a set of Adapackages which implement Chimera’s hypertext concepts as

ADTs. The Chimera server coordinates access to this set ofADTs by responding to remote procedure calls made byChimera clients. These clients are invoked by end-users (orthe process-invoker) and typically contain one viewer(although multiple viewers per client is allowable). TheChimera server can handle multiple clients run by multipleusers at the same time.

Filtering information is maintained for each viewerconnected to the Chimera server. Anchors and links can befiltered such that different sets of these concepts can beprovided to different users for the same view. Users canselect the level of faltering nxeived if the viewer provides an

interface to do S09. The default filtering level is none, i.e.,all anchors and links for a particular view are accessible.The other filtering level is user_only, such that only thoseanchors and links created by a user on a particular view areaccessible. This functionality allows Chimera to providesupport for multiple contexts in a single hyperweb.Eventually we plan to implement a system of ownershipand permissions modeled after Unix’s file permissions.Thus, only those anchors and links which are readable by auser will be accessible for a particular view. We will thenextend Chimera’s support for multiple contexts by allowinga user to have different roles and thus gain access todifferent sets of anchors and links.

An active link is maintained for each user connected to theChimera server. An active link is a mechanism provided bythe Chimera server to allow modeless link creation. Intypical hypertext systems, link creation occurs as a mode.The user indicates that a new link is desir~ adds (typicallytwo) anchors to this link and then continues working. InChimera, a user can create several empty links, select oneof these links to be active, and then add anchors to thisactive link at any time thereafter. The user can also at anytime select another link to be the active link. Note thatviewers are not required to use the active link mechanism. Itis provided only as a convenience function in an attempt tofoster common interaction styles between Chimera viewers.A viewer can forgo the active link mechanism, register its

own links, and modify them independent of other viewers.

Hyperwebs are mapped into Unix directories where theChimera server stores temporary run-time tiles along withthe persistent state of its ADTs. The ADTs save their stateinformation with the Pleiades object management system.Users select which hyperweb they want to access through aresource file (.chimerarc) located in their home dwectorieswhich the Chimera server reads on start-up.

The Chimera server currently supports fourteen hypertextevents and clients can register or reregister interest in any of

a single, standard style to be too restrictive that would prevent

many existing viewers from participating in Chimera. On the

other hand, it is possible to provide a set of reusable

components that developers can utilize which simultaneously

simplifies the task of writing viewers and promotes uniform

authoring, display, and interaction styles.

9 Since Chimera is an open hypertext system, this

functionality can not be guaranteed across all viewers. It will

only exist if the viewer developer decides to include it in a

particular viewer.

ECHT ’94 Proceedings 99 September 1994

them 10 (See Figure 3). The events range from reportingchanges to the hyperweb, such as the addition or deletion ofhypertext concepts, to link traversal events and active linkevents.

Finally, clients provide a variety of information aboutthemselves to the server. This information includes whethereach viewer in each client is ready to receive hypertextevents, what hypertext events each viewer is interested in,and what view(s) each viewer is in. The server also knowshow each viewer would like to be invoked via an invocationpolicy attribute associated with each viewer. This policy isused when the server must send a link traversal event to aview not currently displayed by any connected viewer. Aviewer with an invocation policy of “Once_Only” is onlyinvoked once and all subsequent link traversal events aresent to it. This is for viewers which can display multipleviews, perhaps by opening a new window for each one orby closing the previous view before opening the new one.An alternative invocation policy is “EverY_Time” which

Event Name Associated Information

Server Disconnect NoneNew Viewer Viewer Identifier

Delete Viewer Viewer IdentifierNew Object Object IdentifierDelete Object Object IdentifierNew View View IdentifierDelete View View IdentifierNew Anchor Anchor IdentifierDelete Anchor Anchor IdentifierNew Link Link IdentifierDelete Link Link IdentifierModify Link Link IdentifierLink Traversal Anchor IdentifierActive Link Link Identifier

Figure 3: Chimera’s Hypertext Events

causes the server to invoke (via the process invoker) a newinstance of a viewer each time a link traversal occurs to anundisplayed view.

4.2 Process Invoker

The process invoker is an RPC server to which theChimera server sends messages when it wants a particularviewer invoked. The Chimera server sends a viewer namewhich the process invoker maps into an exeetttable programor shell script which it then invokes. This invocation iscurrently handled by having the process invoker use theUnix fork command to start a child process. This childprocess calls the Unix execvp command which replaces thechild process with the specified executable program whichthen begins to run. The map that the process invoker usesto determine which executable program to run is read in

10A client is assumed to have no interest in any event when it

fiist contacts the chimera server.

once at start-up and is stored in the hyperweb that the useris accessing. The information in the map file must beentered manually via a text editor in the currentimplementation. (The limitations implicit in this will befixed in future implementations. They can be overcome byproviding tools to manage a process invoker’s map file andaltering the process invoker to detect changes to its map fdeat run-time.)

4.3 Chimera Client

A major benefit of the client-server architecture of Chimerais that its clients may be written in more than one

language. An API to the Chimera server for a particularlanguage is required before that language can be used toconstruct Chimera clients. An advantage of the APIapproach is that low-level RPC details of passing messagesto the Chimera server are completely hidden from theclients which use the API. Instead clients invokesubprograms like register_anchor or traverse_link and theAPI converts these subprograms calls (and their parameters)into the appropriate RPC messages and ships them to theChimera server. The API also passes back any return valuesfrom the server to the calling client. This conversion isstraight forward and includes creating a new RPC buffer,marshaling the parameters into the buffer, making theactual RPC call, retrieving any return values from thebuffer, and deallocating the RPC buffer.

Chimera supports clients written in Ada and C with APIsfor both languages. Several clients have been written usingeach of these APIs. A C++ API is in the works but, as ofthis writing, is not yet complete. In addition, engineers atIBM Owego, New York, developed tcl bindings to Q withthe result being that they can send RPC messages to theChimera server. These tclbindings do not represent acomplete API to Chimera, however, since they cannot yetreceive hypertext events from the Chimera server. Work isnow in progress to develop a tclAPI which is built on topof the C API.

The Ada API creates two Ada tasks per viewer. One taskhandles sending messages to the Chimera serve~ the secondtask handles receiving hypertext events from the server.These tasks operate independently and maintain separateUnix sockets. This allows multiple connections to theChimera server within a single Unix process. The Ada APIhas proven to work successfully with other client-serversystems, the most notable being a simultaneous connectionby one viewer to a Chimera server, a Chiron server, and asound server.

The C API allows C programs to use Chimera serviceswithin a single Unix process. Two sockets are maintainedby the C API, requiring application writers to takeresponsibility for the scheduling of message transmissionand event reception. Since many programs using the C APIwill also use X Windows to produce their user interface,support was added to receive Chimera events from within anXt event loop. Chimera events are handled using a callbackmechanism. To date, four separate C programs have been

ECHT ’94 Proceedings 100 September 1994

written which are simultaneously Chimera and X clientswithin a single Unix process.

4.4 External Systems

As of this writing, seven viewers for several media typeshave been integrated with the Chimera system. Theseviewers are briefly described below.

FrameMaker The FrameMaker program was integratedinto the Chimera system without modifiing its executableimage. A wrapper program translates between Chimerahypertext concepts and FrameMaker’s built-in hypertextconcepts, Custom FrameMaker macros were written foranchor creation so link traversal messages could be receivedby the wrapper.

xvi The public-domain vi-clone ‘xvi’ was integrated withChimera by a group of senior students as a class project fora software engineering project course. All existing viediting functions work normally, with hypertextfunctionality accessed through a graphical control panelwritten using the Motif toolkit. Chimera services areaccessed through the C API. Link traversals to xvi cause adifferent buffer to be opened for each new file referenced inthe link.

Flight Simulator As described earlier, the flightsimulator is a simulation of an aircraft. Written in Adausing Chiron, the flight simulator features each gauge in aseparate thread of control. The Ada API easily allowsmultiple threads of hypertext functionality to operateindependently within a single Unix process.

m peg An ambitious term project for the softwareengineering project course, the mpeg viewer allows anchorsto be defined on mpeg movies. Anchors may be defined onsections of each ikune, and may have a duration from oneframe to the entire movie. Authoring support allowsanchors to be defined on a frame, then copied from frame toframe. Authors may then singlestep through the movie andadjust anchors on individual frames for the best fit. Anchorsmay be added to the active link from any frame, The mpegviewer was created by extending a public-domain mpegplayer using the C API.

xgif Another result of the same course, the xgif viewer

allows anchors to be defined on sectionsofaGIF11 image.A public-domain GIF viewer was augmented using the CAPI to display a hypertext control panel written using theMotif toolkit. The control panel varies depending onwhether the GIF viewer is in author mode or view mode.Link traversals to xgif cause a new xgif process to beinvoked to view the tinked-to GIF file.

Sound Piayer The sound player presents a list of soundsto which anchors are attached, Link traversals to a particular

11 The Graphics Interchange Format@ is the Copyright

property of CompuServe Incorporated. GIF@ is a Service Mark

property of CompuServe Incorporated.

anchor causes the sound player to play the associated sound.The Sound Player uses Chiron for its user interface, the AdaAPI for its hypertext functionality, and a Sun sound serverfor sound capability, making it simultaneously a client ofthree separate servers.

Button The button is a simple viewer which displays awindow containing only a button. An anchor is thenassociated with this button. This anchor may be a memberof only one link (a restriction enforced by this particularviewer), and can be used as a placeholder for a section of adocument. This viewer is noteworthy since its view is notassociated with any underlying object, yet it can participatein a Chimera hyperweb.

4.5 Metrics

The Chimera API consists of approximately 90 entrypoints. The Ada API library is 296 kilobytes (K) in size.The C API library is 62 K. The Chimera server is 2.3megabytes in size and uses approximately 5 megabytes ofmemory when executing.

Our metrics for the performance of Chimera is anecdotal.From a user’s perspective, a link traversal between tworunning viewers occurs instantaneously. If a link traversalleads to a non-running viewer, there is a noticeable delaywhile Unix spins up the new process. After the newlyinvoked viewer has initialized the completion of the linktraversal occurs quickly.

We conducted one performance experiment with theintegrated FrameMaker client. We set up a link traversalbetween two FrameMaker documents using Chimera andFrameMaker’s own internal hypertext functionality. Theuser noticed no difference between the time it took tocomplete either traversal despite the fact that the Chimeralink traversal involved the passing of RPC messages acrossfour Unix processes while the FrameMaker link traversalwas handled completely within FrameMaker.

5 FUTURE WORK

5.1 Versioning

Version control mechanisms are very important for anyhypertext system that wishes to support softwareengineering activities in a non-trivial fashion [14, 181.Chimera is no exception, and a mechanism for versioningis a research priority. A brief discussion of our preliminaryapproach is given below.

Since Chimera intentionally offers no support for storingapplication objects within its hypertext database, versioncontrol responsibility must be shared between Chimera andits client applications. As an example, Chimera willundoubtedly be used to create relations between source codefiles. Version control responsibility for the tiles alone willrest with an existing revision control system such as RCS[36]. Responsibility for versioning the relations betweenthe files will reside with Chimera.

ECHT ’94 Proceedings 101 September 1994

Each concept within Chimera shall be capable of multipleversions. This raises significant issues of consistencymaintenance when a concept instance is changed. Forexample, when an anchor is deleted, it must also beremoved from any links to which it belongs, requiring anew version of those links, Another issue is consistencymaintenance between versions maintained by an extematversioning system and versions maintained by Chimera.Resolving this issue and providing a mechanism forflexible multi-concept version naming requires a new fust-class concept in Chimera, the configuration. Aconfiguration will contain a snapshot of the currentversions of a hyperweb subset. External object versions canthen be mapped to a configuration.

It is anticipated that parallel version paths will be supportedby Chimera using the first-class configuration concept.While explicit mechanisms will need to exist to support thecreation of new branches, once a new branch has beencreated its use should be mostly transparent. Merging ofpaths will require the use of a special utility which willresolve conflicts, prompting the user for guidance, ifnecessary.

5.2 Collaborative Hyperweb Construction

Chimera does not currently support the collaborativebuilding of linked hyperwebs in red-time by multiple users

where each user is made aware of other user actions12. Thisis due to limitations in the conceptual architecture thatmust be addressed, as well as the current implementation’srestriction of one Chimera server per hypcrweb. The majorlimitation of the current conceptual architecture is that theChimera server must maintain the data stored in a hyperwebalong with managing any Chimera clients that connect toit. What is needed is a separation of concerns where a newcomponent, the hyperweb server, is added to the conceptualarchitecture. This new component relieves the Chimeraserver from its data management activities. This involvesmoving the ADTs which implement Chimera’s hypertextconcepts from the Chimera server to the hyperweb server.The Chimera server component is then free to concentrateon supporting client access to multiple hyperweb servers(and thus multiple hyperwebs). We postulate anenvironment in which there is one hyperweb server perhyperweb with multiple Chimera servers managingcollaborative user access in real-time to these hyperwebservers. The two sets of servers would need to worktogether to handle links created between hyperwebs and alsoto ensure that notification of changes made to theinformation space is propagated to all connected users. We

also anticipate that the Chimera server will support access

1*As of this writing, Chimera supports the collaborative

building, in a limited manner, of a single hyperweb, since all

the viewers participating in the collaboration can register for

the appropriate hypertext events from the Chimera server

managing that particular hyperweb. It is timited in the fact that

two or more users cannot mod@ the same link at the same time

and the notification of other user’s actions occurs after those

actions have taken place.

to distributed objects by employing a Universal ResourceLocator (URL) style object naming mechanism and anexisting transfer protocol to access remote objects.

6 RELATED WORK

There has been substantial evolution of hypertextfunctionality during the last decade and several significantefforts to apply hypertext to the software developmentproblem (or similar). The systems described below arediscussed in chronological order of appearance and werechosen either for their historical importance or because oftheir close relation to and impact upon the design ofChimera.

6.1 The Dexter Hypertext Reference Model

The Dexter Hypertext Reference Model (Dexter) is aframework for comparing hypertext systems developed asthe result of two NIST workshops in 1988 [13]. It attemptsto provide a standard hypertext terminology and alsodescribe the important abstractions found in hypertextsystems. At least one system has been developed based onDexter (DeVise [12]) and Dexter itself has also beenextended (AHM [16]).

Dexter defines three layers: the run-time layer, the storagelayer, and the within-component layer. The storage layer

sits in the middle and interfaces with the run-time layer viapresentation speciilcations, and the within-component layervia anchors. The storage layer creates a network of

components of three types: atomic, composite, and link.Atomic components contain data stored in the within-component layer and presented by tools in the run-timelayer. In addition, atomic components contain anchorswhich index directly into the data and allow the data to belinked. Composite compatents allow scalable hyperwebs tobe constructed. Link components contain specifiers whichdescribe how atomic and composite components are linkedtogether.

Chimera cannot be completely modeled in Dexter. Forinstance, Chimera can handle the presence of links withzero or one anchors (dangling links). Dexter’s intolerance

for such constntcts has been widely criticized [12, 16, 21].Also Chimera’s notion of a view cannot be adequatelymodeled by a composite component, because a Chimeraview contains information about the object being viewedand the viewer used to create the view. A compositecomponent on the other hand only contains references toatomic components which only contain data. In Dexter,anchors are created directly on the data referenced by atomiccomponents, whereas in Chimera, anchors are created onviews not on the objects (i.e. data) themselves. Thisadditional level of abstraction is not possible in Dexter. Infac~ we believe that Dexter cannot model the case where thesame object (atomic component) is displayed differently bytwo or more viewers with each viewer accessing a differentset of anchors and links. Chimera’s view concept handlesthis example easily while in Dexter there would be no wayto specify it. Finally, a viewer is free to define its anchors

ECHT ’94 Proceedings 102 September 1994

with respect to anything in its view including objectswhich exist only at run-time e.g. a graphical widget. Webelieve that Dexter would be unable to specify this type ofanchor, since a graphical widget lies in the domain ofDexter’s “presentation specifications” and anchors can notbe created in Dexter with respect to these spccitlcations.

6.2 Virtual Notebook System

The Virtual Notebook System (VNS) was built at theBaylor College of Medicine to support collaborativebiomedical research via distributed hypertext services in aheterogeneous computing environment [28]. VNS isimplemented by a set of work group servers (WGSS)distributed throughout a network. Each WGS is used tostore text, graphics, and link information. Users typicallystore all their data with the WGS on their local machine butcan also access information stored on another machine. TheVNS Gatekeeper is used to integrate external tools withVNS, whereby information from these tools is copied andstored in a WGS. One interesting aspect of VNS is thatwhile users may share data, they do not share links. Thustwo users can see the same page but view different links.Link information for each user is stored separately from thedata that makes up a page. After a page is constructeddynamically, a user’s link information for that page isretrieved and displayed. Chimera is able to provide thisfunctionality with its link filtering and can go one stepfurther with its anchor filtering which allows users to seedifferent anchors on a shared view.

VNS, in contrast to Chimera, requires that all systeminformation be stored in a database under its control.Integration in VNS is concerned with providing the abilityto copy information out of an external tool and into a VNSdatabase. At that point, the external tool is taken out of the100M VNS handles the display of the data from then on.Integration in Chimera is only concerned with getting aviewer to communicate with the Chimera server. Chimeramakes no attempt to display a viewer’s objects.

6.3 Sun’s Link Service

Sun’s Link Service (LS) was a commercial product whichdefined a protocol for an extensible and loosely coupledhypertext system [25]. An application integrates with theLS by loading in a library which implements the protocol.This library allows communication with the LS controlprocess which facilitates communication between link-aware applications. Applications provide call-backprocedures to the LS so that they can receive link-relatedmessages. Links are binary and are stored in a databasemanaged by the LS control process.

Chimera and the Link Service differ in three aspects. TheLS promotes applications creating anchors on theunderlying object via its data model. Chimera’s anchors arecreated on a view of an object, not the object itself. Thisallows a Chimera viewer to store anchor informationseparately from the object (or objects) to which it refers.Links are hidden in the LS; that is, an application cannot

retrieve links and manipulate them. This is not the casewith Chimera, where links can be retrieved by anappropriate viewer and displayed in a variety of ways. Thisenables the creation of hierarchical hyperwebs. FinallyChimera’s links are n-ary.

6.4 Hyperform

Hyperform is an approach to creating flexible hyperbasesupport based on the notion of extensibility. It is jointwork of the University of Aalborg and the HypermediaResearch Laboratory [37]. The Hyperform system is asimple framework which provides several built-in classesthat perform basic hyperbase features such as concurrencycontrol, notification control, access control, versioncontrol, and search and query. A user of Hyperform takesthis initial framework and extends the built-in classes toproduce a hyperbase system tailored for the hypermediaapplications in the user’s environment. The object-orientedlanguage used to implement the Hyperform server is thekey to its extensibility and allows for new data objects andmethods to be added at run-time which in turns produces anenvironment conducive to rapid prototyping.

The Chimera approach differs greatly from the Hyperformapproach. The authors of Hyperform assert that a fixedhypermedia model hinders the development of new tools byforcing developers to make compromises in theirapplications to match the existing model [37]. Thus, theHyperform approach has an implicit assumption thatdevelopers of hypermedia systems want to develop onesystem for a certain set of tools and another system for adifferent set of tools which require a different hypermediamodel. After several iterations of this approach a user endsup with several hypermedia systems which we believe couldbe incompatible with each other. Thus, objects managed byone of these systems cannot be linked to objects in anotherof these systems, and presumably the effort required toupdate applications which use one data model to the otherdata model is non-trivial. This implicit assumption issimply not tenable in a software development environmentwhich is already extremely heterogeneous. It seems counter-productive to introduce more diversity in such anenvironment with the addition of multiple potentiallyincompatible hypermedia systems. There is anotherassumption here that all of the objects in a hypermediasystem are stored in a single database. This assumption isnot valid in a software development environment in whichmultiple heterogeneous object management systems canexist and yet it is desirable to link objects stored in thesediverse object repositories.

Thus Chimera provides a flexible hypermedia model whichwas developed specifically for the needs of tools in asoftware development environment. This greatly reduces thechance that a specific tool cannot use the model provided byChimera and not be able to participate in a Chimerahyperweb. In fact Chimera’s hypermedia model was

designed with the assumption that Chimera would enter anenvironment with many pre-existing tools which would

ECHT ’94 Proceedings 103 September 1994

eventually be integrated with it. Thus the model had to beas flexible as possible.

6.5 Microcosm

Microcosm is art open hypertext system developed at theUniversity of Southampton [5, 6, 15]. It is a link servicethat attempts to keep all aspeets of the system such as thehypertext model, the messages passed from applications toMicrocosm, and Microcosm’s response to such messagesopen and tailorable. Microcosm-aware applications sendselections and action pairs to the Microcosm DocumentControl System (DCS). The DCS sends the messagethrough a chain of filters which act on the message byblocking it or passing it on, perhaps modifying it along theway, A speeial type of filter is a Iinkbase which uponfinding the source of a link in the message attaches thedestination of the link to the message. The messageemerges from the filter chain into the link dispatcher whichpresents to the user any actions contained in the resulting

message. Microcosm can integrate non-aware Microcosmviewers through the use of a shared clipboard. However thisis a worst-case situation that is rarely used as most

applications that users want to use with Microcosm containthe hooks needed to integrate with Microcosm. Microcosmhas been applied to situations involving several hundredmegabytes of information and can handle multiple sets oflinks over the same set of data (by swapping in or outvarious linkbases in the filter chain).

There are three distinctions between Chimera andMicrocosm.

1. Microcosm uses a message-based API while Chimerauses a multi-lingual programmer’s API, Microcosmmessages are in a tagged ASCII format. Filters act on tagsin the ASCII message that they reeognize and ignore allother tags. In addition, each filter can introduce any tag andits associated data into any message. In contrast, the detailsof Chimera’s message format are hidden from Chimeraclients by the Chimera API and the Chimera server by amessage ADT. This use of abstraction allows the Chimeradevelopers to freely change the format of the messageswithout affeeting the rest of the system. This allows themessage format to be as simple (ASCII text) or as complex(an Ada variant record) as needed to effectively support thesemantics of the Chimera API. This freedom to changemessage formats is not available in Microcosm but theirapproach can potentially integrate more tools into theirsystem since they do not have to modify each participatingtool to use a programmer’s API. Chimera’s approach tointegrating non-aware viewers is to create a wrapper orproxy program which uses both the Chimera API and

whatever mechanism the non-aware viewer has tocommunicate with external systems,

2. All Microcosm-aware applications must provide allhypertext functionality via a menu-based interface. Whilethis promotes a common interaction st#e between viewers,

it may also prevent some applications (such as those

without a graphical user interface) in participating in the

system. Chimera does not preseribe or restrict a viewer’sinterface in any way, with the idea that in a softwaredevelopment environment, developers will tolerateinconsistency in interface in return for using a powerfultool within a Chimera hyperweb.

3. Microcosm has no analogous concept for Chimera’sview concept. Each document in Microcosm has a user-defiied physical type. Each physical type is as~iated withone viewer. When a particular document is the destinationof a link traversal, Microcosm invokes the associatedviewer on the speeified document. Chimera’s view conceptis independent of where a particular data element is stored.This allows Chimera greater flexibility in handlingmultiple views of a single object, and also handles easilythe ease where a single view consists of data accessed frommultiple sounxx.

6.6 System Prototype O, 1, 2, and 3

The Hypermedia Research Laboratory (HRL) at TexasA&M University has engaged in the building of severalhypermedia systems (SP O-3) since 1991 [19, 21]. At thesame time, the HRL has also built a series of hyperbasesystems (HB O-3) to support the data storage requirementsof these hypermedia systems [26, 27]. SP3 defines aflexible hypertext model. Applications manage componentswhich have persistent selections created upon them, Thesepersistent selections are attached to anchors which are thenassociated with links. These links create association setsthat are modeled in the underlying hyperbase. This matchesChimera’s hypertext concepts fairly well, the onlydifference being that multiple persistent selections can beassociated with a single anchor. In Chimera, if the viewerwanted to associate multiple regions of its view to oneanchor it could do so, but this would necessarily make themapping function between anchors and regions of the viewmore complex. Typically Chimera viewers map one regionper anchor, which would be the equivalent of mapping onepersistent seleetion to anchor in SP3.

A distinctive feature of the HRL work is that anchors andlinks are frost-class executing programs that can provide awide range of run-time semantics. It also allows userinteraction with hypertext services to be handled by theanchor and link processes taking this burden off of theclient applications. (This is handled by virtue of the factthat anchors and links are supplied as classes which have adefault set of behaviors which applications can subclass andmodify as desired.) SP3 and HB3 provide a sophisticatedenvironment that represents a first attempt at providinghypermedia-in-the-large.

The differences between Chimera and the HRL work aremany. For instance, Chimera is not yet at a state where itcan support multi-user collaboration on a shared hyperweb.A few additional differences are outlined below.

● Chimera has taken a different approach with respect toanchors and links. They are objects managed by viewers andthe Chimera server respectively as opposed to being fwst-

ECHT ’94 Proceedings 104 September 1994

class processes. This allows for anchors to be specificallytailored to a viewer while placing a burden on viewerdevelopers to implement this functionality for each newviewer. It allows links to be handled in a consistent mannerat the price of implementing special link behaviors in theChimera server.

● SP3 requires applications to use its object manager (HB3)to store application data; this allows SP3 to supportversioning of application data and hypertext information.Chimera, in contrast, places no such restrictions on itsviewers requiring viewer cooperation to provide reliableversioning.

“ Chimera associates anchors with views, while SP3associates anchors with persistent selections which referdirectly to an application’s data. This enables Chimera,when combined with a viewer mechanism such as Chiron,to provide greater flexibility in displaying art anchor,supporting the ability of several viewers (concurrently)providing different views of the same object, where theanchors and their presentation are view-specific (and this allseparated by Chiron from any application code). This issimilar, though, to SP3’S notion of a context. In SP3,depending on the context, different sets of anchors and linkswill be made available to an application displaying theobject. Contexts are handled in Chimera through acombined use of attribute-value pairs and the filtering ofanchors and links by the Chimera server for a particularview.

● SP3 links are not “ordinary” objects and thus anchorscannot be defined upon them and thereby participate inhierarchical webs. Thus Chimera appears to have ascalability advantage.

7 CONCLUSIONS

In conclusion, Chimera makes a variety of contributions tosoftware engineering environments and to hypertexttechnology, including the simultaneous satisfaction of therequirements described in the introduction. The essence ofthe contributions are key concepts and separations ofconcerns, provision of an effective set of server capabilities,and the demonstrated ability to simultaneously satisfy awide variety of objectives in a single system.

The concepts and separations include view-spwific anchorsand separating object and anchor persistency from linkpersistency. Viewers define anchors and a hypertext serverhas responsibility for management of the links. Allowingviewers to define anchors permits a variety of types ofanchors to be defined, and they maybe implemented in non-invasive ways. Neither the database(s) of objects nor theuser interface are part of Chimera or its concepts. Theconcepts are defined in a media-independent manner and suchthat scalability is supported.

The Chimera server interface supports multiple. concurrentclients written in multiple programming languages anddemonstrates that commercial “black-box” tools can be

ECHT ’94 Proceedings 105

integrated (provided they support minimal interprocess

communication).

We have built a prototype system, Chimera, to validateboth the concepts and architecture. In addition, we believeour approach has value outside of the SDE domain and canaid such tasks as ethnographic studies and the building ofdigital libraries.

Some open, and potentially troublesome, issues with thisapproach exist. Since viewers define anchors, and viewersmay be heterogeneous, a lack of consistent user interface tothe hypertext is more likely to occur than not. Moretroublesome from the SDE point of view, however, is theobservation that the relations indicated by the hypertextlinks are in addition to whatever relations are maintained bythe environment’s object managers. This may yield anumber of problems, including maintaining consistency inthe face of change to the object stores. On the other hand itdoes not seem realistic to assume the existence of a singleobject manager which is responsible for maintaining atlrelations in an environment, whether they originate fromquick, dynamic, and user-discretionary hypertext linkcreation, or careful specification and design of a complexproject’s master database of strongly-typed artifacts. Thebroad research issue, in a heterogeneous world, isdetermining how to maintain consistency between variousrelatiotdlink managers. For a near-term partial solution, oneapproach we intend to pursue is the automatic creation (andmaintenance) of hyperlinks from object manager relation~in such a case hypertext style navigation of an OM storewould be enabled. It seems much more problematic toattempt to go the other direction, however (from hyperlinksto OM relations), because of the limitations of current OMsystems. Additional key research activities includedetermining appropriate mechanisms for supporting accesscontrols (so, e.g., a project’s on-line personnel records arenot accessible by those unauthorized), versioning, andsupport for collaborative hyperweb creation.

8 ACKNOWLEDGEMENTS

The authors would like to acknowledge Jonathan Grudin,Rebecca Grinter, Leysia Palen, and Hadar Ziv for reading anearly draft of this paper and providing comments, thereviewers for their helpful suggestions and Hugh Davis andWendy Hall for providing detailed information about theMicrocosm link service. In addition the authors’ gratitude isextended to the students in the software engineering projectcourse whose experiences fine-tuned Chimera and helpedexplore issues of integration with existing software,

REFERENCES

[1] V. R. Basili and B. T. Perricone. Software errors andcomplexity: An empirical investigation.Communications of the ACM, 27(1):42-52, January1984.

.[2] G. Boudier, F. Gallo, R. Minot, and I. Thomas. An

overview of PCTE and PCTE+. SIGSOFT SoftwareEngineering Notes, 13(5), November 1988.

September 1994

[3]

[4]

J. Conklii. Hypertex~ An Introduction and Survey.IEEE Computer, 20(9): 17-41, September 1987.

Application. IEEE Transactions on SoftwareEngineering, SE-6(1):2-13, January 1980.

M, Creech, D, Freeze, and M. Gris. Using Hypertextin Selecting Reusable Software Components. InProceedings of Hypertext’91, San AntoNo, Texas,December 1991.

[18]

[19]

D. Hicks, J, Legget& and J. Schnase. Version Controlin Hypertext Systems. Report TAMU HRL-91 -004,Texas A&M University, July 1991.

C. Kacmar and J. Leggett. PROXHY A Process-Oriented Extensible Hypertext Architecture. ACMTransactions on Information Systems, 9(4):399-419,

October 1991.

[5] H. Davis, W. Hall, I. Heath, G. Hill, and R. Wilkins.Towards an Integrated Information Environment withOpen Hypermdla Systems. Jn Proceedings of [heACM Conference on Hypertext, Milano, Italy,November 1992. [20] R. Kadia. Issues Encountered in Building a Flexible

Software Development Enviromnen~ Lessons Learnedfrom the Arcadia Project. In Proceedings of ACMSIGSOFT’92: Fifth Symposium on SoftwareDevelopment Environments, Tyson’s Corner,Virgini% December 1992.

[6] H. Davis, S. Knigh~ and W. Hall. Light HypermediaLink Services: A Study of Third Party ApplicationJ.ntegration. In Proceedings of the ACM Conferenceon Hypertext, Edinbur& Scotland, September 1994.

[7] N. Delisle and M. Schwartz. Neptune: A HypertextSystem for CAD Applications. In Proceedings of the

ACM SIGMOD’86, pages 132-142, Washington, DC,May 1986.

[21]

[22]

J. Leggett and J. Schnsae. Viewing Dexter with Open

Eyes. Communications of the ACM, 37(2):77-86,February 1994.

D. Lucarella, S. Parisotto, and A. Zanzi. MORE:Multimedia Object Retrieval Environment. InProceedings o Hypertext’93, Seattle, Washington,November 1993.

[8]

[9]

C. Femstr6m, K. Niirfelt, and L. Ohlsson. Softwarefactory principles, architecture, and experiments.IEEE Software, 9(2):36-44, March 1992.

J. Ferrans, D. HursL M. Serme& B. Covno~ W. Ji, P.Kajk~ and W. Ouyang. HyperWeb A Framework forHypermedia-Based Environments. In Proceedings ofACM SIGSOFT’92: Fifth Symposium on SoftwareDevelopment Environments, Washington D. C.,December 1992.

[23] M. Maybee, D. Heimbinger, D. Levine, and L.Osterweil. Q: A Multi-Lingual Inter-ProcessCommunications System for Software EnvironmentImplementation. Submitted for publication, 1992.

[24]

[25]

[26]

J. Nielsen. Hypertext and Hypermedia. Academic

Press, Inc., San Diego, California 1990.[10]

[11]

P. Garg and W. Scacchi, A Hypertext System toManage Software Life-Cycle Documents. IEEESoftware, 7(3):90-98, May 1990.

F. Garzotto, P, Paolini, and D, Schwabe. HDM - AModel for the Design of Hypertext Applications. InProceedings of Hypertext’89, Pittsburgh,Pennsylvania% November 1989.

A. Pearl. Sun’s Link Service: A Protocol for OpenLinking. In Proceedings of Hypertext’89, Pittsburgh,Pennsylvania, November 1989.

J. Schnase, J. Legget~ and D. Hicks. HB 1: InitialDesign and Implementation of a HyperbaseManagement System. Technical Report TAMU-HRL91-003, Hypertext Research Lab, Texas A&MUniversity, October 1991,[12]

[13]

[14]

K. GrOnbaek and R. Trigg. Design Issues for a Dexter-Based Hypermedia System. Communications of theACM, 37(2):40-49, Febmary 1994. [27] J. Schnase. HB2: A Hyperbase Management System

for Open, Distributed Hypermedia SystemArchitectures, PhD thesis, Texas A&M University,College Station, Texas, August 1992.

F. Halasz and S. Mayer. The Dexter HypertextReference Model. Communications of the ACM,37(2):30-39, February 1994.

[28] F. Shipmarm, III, R. Chancy, and G. Gerry.Distributed Hypertext for Collaborative Research TheVirtual Notebook System. In Proceedings ofHypertext’89, Pittsburgh, Pennsylvania, November1989.

F. Halasz. Reflections on Notecards: Seven Issues forthe Next Generation of Hypermedia Systems.Communications of the ACM, 31(7):836-852, July1988.

[15]

[16]

W. Hall, G. Hill, and H. Davis. The Microcosm LtiService: A Technical Briefing. In Proceedings ofHypertext’93, Seattle, Washington, November 1993.

[29]

[30]

J. Smith and F. Smith. ABC: A Hyperme&a Systemfor Artifact-Based Collaboration. In Proceedings ofHypertext’91, San Antonio, Texas, December 1991.

L. Hardman, D. Bulterman, and G. Van Rossum. TheAmsterdam Hypermedia Model: Adding Time andContext to the Dexter Model. Communications of theACM, 37(2):50-62, February 1994.

D. Steinberg and H. Zlv. Software Visualization andYosemite National Park. In Proceedings of theTwenty -Fifih Annual Hawaii International Conferenceon System Sciences, January 1992.

[17] K. Heninger. Specifying Software Requirements forComplex Systems: New Techniques and their

[31] N. Streitz, J. Haake, J. Hannemann, A. Lemke, W.Schuler, H. Schutt, and M. Thuring. SEPIA: A

ECHT ’94 Proceedings 106 September 1994

Cooperative Hypermedia Authoring Environment. InProceedings of the ACIU Conference on Hypertext,Mihtrto, Italy, November 1992.

[32] P. Tarr and L. Clarke. Pleiades: An ObjectManagement System for Software EngineeringEnvironments. In ACM SIGSOFT93: Proceedings othe Symposium on the Foundations of SoftwareEngineering, Los Angeles, California, December1993.

[33] R. Taylor and G. Johnson. Separationa of Concerns inthe Chiron- 1 User Interface Development andManagement System. In Proceedings of theCo#erence on Human Factors in Computing Systems,pages 367-374, Amsterdam, April 1993. ACM.

[34] R. Taylor, K. Nies, G. Bolter, C. MacFarhute, G.JohnsotL and K. Anderson. Separations of Concernsin the Chlron- 1 User Interface Development and

Management System. UCI-ICS Technical Report TR-

94-12, Department of Information and ComputerScience, University of California Irvine, March 1994

[35] I. Thomas. Tool Integration in the Pact Environment,In Proceedings of the Eleventh InternationalConference on Software Engineering, Pittsburgh PAMay 1989.

[36] W. Tichy. Design, Implementation, and Evaluation ofa Revision Control System. In Proceedings of theSixth International Conference on SoftwareEngineering, pages 58-67, Tokyo, Japsrt, September1982.

[37] U. Wiil and J. Leggett. Hyperform: UsingExtensibility to Develop Dynamic, Open andDistributed Hypertext Systems. In Proceedings of theACM Conference on Hypertext, pages 251-261,Milano, Italy, November 1992.

ECHT ’94 Proceedings 107 September 1994