Integration model layer. Basic classes. Integration model classes. Data model layer. Basic classes. Data model classes. Hypermedia Framework

Transcription

1 HyperDisco: An Object-Oriented Hypermedia Framework for Flexible Software System Integration Ue Kock Wiil Dept. of Computer Science, Aalborg University Fr. Bajers Vej 7E, 9220 Aalborg, Denmark Abstract Software development environments are examples of complex computer applications characterized by heterogeneity; they are composed of diverse information repositories, user interfaces, services and tools. This paper presents an approach for providing hypermedia linking services as a means for integration in these heterogeneous settings. The overall goal of the Hyper- Disco project is to provide a hypermedia framework for exible software system integration. The basic idea in this approach is to allow dierent tools to be integrated in the hypermedia framework at dierent tooldependent levels. Instead of providing a single model of integration that all tools must adhere to, we allow each tool to have its own specialized model of integration and its own specialized protocol for accessing the hypermedia services. This paper describes the approach (focusing on integration and modeling aspects) and presents a prototype which supports it. Preliminary experience with the HyperDisco prototype and its relationship to other systems is described. Keywords: Hypermedia framework, linking services, software development environments, software system integration, modeling, openness, extensibility, rapid prototyping. 1 Introduction Software development environments (SDEs) are examples of complex software systems that are used to develop, maintain and display a diverse collection of highly interrelated artifacts [1, 13]. Artifacts in a SDE may, for example, include multiple versions of requirements specications, designs, prototypes, code, test information, scripts, documentation, etc. The connections between these software artifacts are many and complex. Establishing and exploring these connections are major tasks of development, program understanding and maintenance. It has been suggested and demonstrated that hypermedia [4] is an excellent technology for capturing, sharing, visualizing and navigating relations in complex software systems [2, 3, 5, 7, 8]. Providing hypermedia facilities in a SDE allows a software engineer to freely associate artifacts without regard to the type of those artifacts or where they are stored. These relationships can then be accessed at a later time through a convenient user interface which allows the software engineer to easily navigate them. While some excellent work has taken place in this area [10, 17, 18, 21], no single system to date has eectively addressed all the technical challenges posed by these heterogeneous settings. We believe that the following characteristics are among the most important for a hypermedia framework for exible software system integration [1, 14, 15, 16, 25]. Multiuser, scalability, distribution and heterogeneity. Complex software systems are characterized by many users and tools distributed across dierent machines connected through a computer network. Therefore, the hypermedia framework should be able to effectively handle: (1) a large number of simultaneous users and tools, (2) a large amount of storage in terms of bytes and artifacts, (3) users, tools and processes distributed across machines in a network, and (4) heterogeneity in terms of multiple hardware platforms, programming languages, networking protocols, data models and information repositories. Openness and extensibility. Complex software systems contain a wide variety of tools. Dierent kinds of editors and viewers are used for dierent types of artifacts. It is unlikely that users will give up their favorite tools in exchange for hypermedia functionality [1, 6, 9, 16]. Therefore, the hypermedia framework should be open (based on published, well-dened interfaces and protocols) to allow both new and existing tools to be integrated. The capabilities of a software system must constantly grow and expand. It should be possible to extend the software system (and the hypermedia framework) to absorb new tools and ideas as the technology improves, for example, to handle a new type of artifact in the system. Interoperability and collaboration. The tools and capabilities of a software system cannot stand in parallel isolation and ignorance of each other. Rather, they must be able to readily share data and results with each other. Their progress must aect, and be aected by, each other's activities. Some software systems support collaboration among a group of users working on a common task. The hypermedia framework should support both interoperability among tools and collaboration among users. Ideally all editors and viewers in a software system should be able to use hypermedia services and respond to hypermedia events. Performance and eciency. As with all computer

2 systems, performance is of great importance in complex software systems. Users will expect rapid response to requests for services that they regard as straightforward, and can be expected to be impatient for response, even to requests for services that they know toentail considerable processing. Thus, the hypermedia framework should not add considerable processing overhead to operations of the software system and should make eective use of hardware resources such as disk space, CPU time and network capacity. Easy to use. If a hypermedia framework is to support users, then it most not itself become an obstacle. Users must nd it easy to understand what capabilities the framework oers, and how to use them eectively. Atypical user of the hypermedia framework is a software engineer or some other highly skilled computer literate. The above description of overall characteristics outlines a set of more specic technical requirements for ahypermedia framework for exible software system integration. This paper describes a set of concepts which satisfy the set of requirements, and a prototype which implements the described concepts. We focus on integration and modeling aspects of the hypermedia framework. Other important facilities such as support for collaborative work groups and multiple versions of shared artifacts will not be presented in this paper. Instead, we refer to [23] for details on how HyperDisco can be used to address these issues. The remainder of the paper is organized as follows. The next three sections present the concepts, a prototype implementation of the concepts in an object-oriented hypermedia framework, and preliminary experiences with the prototype. We then conclude and describe our future plans. 2 Concepts The overall goal of the HyperDisco project is to provide a hypermedia framework for exible software system integration. Given the overall goal of the eort, we believe that the following concepts can help achieve the goal. 2.1 Layered Hypermedia Framework The hypermedia framework consists of two distinct layers as depicted in Figure 1. The data model (storage) layer provides tool independent services. The integration model (runtime) layer provides tool dependent services. By separating tool independent services from tool dependent services, we allow dierent integration models to share the same basic data model. Both the integration model and the data model layer provides a set of general-purpose built-in services (a library of reusable object-oriented software routines). In the data model layer, the built-in classes provide tool independent hypermedia storage services such as storage and retrieval of hypermedia objects (e.g., nodes, links and anchors). In the integration model layer, the built-in classes provide a basic hypermedia integration model including a exible communication protocol. These classes can be extended and tailored using multiple inheritance to provide specialized integration and storage support for individual tools. Integration model layer Basic classes Integration model classes Data model layer Basic classes Data model classes Hypermedia Framework Figure 1: The layered hypermedia framework. Integration support for participating tools is provided in the integration model layer and storage support is provided in the data model layer inheriting from the basic classes. 2.2 Data Model Layer The hypermedia framework provides an extensible object-oriented data model with a set of general hypermedia object types: Anchor, Node, Link and Composite (Figure 2). New (sub)types can be added to match specic storage requirements of participating tools. In this way, participating tools can extend and tailor the data model by adding new messages and specializing existing messages. All instances of the data model (anchors, links, nodes and composites) have a unique object identi- er (OID). Anchors (inspired by Dexter [9, 11, 14]) simply contain a value that species some location, region, item, or substructure within a component. If the anchor value is empty, the anchor refers to an entire component. The smallest sharable unit in the model is an attribute. Components are collections of attributes. Some attributes are always present in components and additional attributes can be attached dynamically. Default component attributes are a list of anchor OIDs and additional information such as owner, time created and last updated. Components and anchors can have attached scripts. Scripts are a way of extending the behavior of instances [20]. The data model supports a node subtype for each media type (text, graphics, video, voice, etc.) supported by the framework. For instance, the text node subtype provides specic operations to deal with textual artifacts. Adding a new media type to the platform involves the creation of a node subtype and specication of at least one editor / viewer tool that can display the media type. To allow integration of monolithic tools, nodes can be used as data wrappers [9] or

3 Basic classes Object Basic classes Object Concurrency Control Notification Control Version Control Access Control Query & Search Integration model classes Anchor Link Data model classes Component Anchor Figure 3: Built-in integration model classes. The integration model layer provides an extensible minimal integration model consisting of anchors and links. Node Composite Link Figure 2: Built-in data model classes. The Component class inherits facilities from ve basic classes: Concurrency Control, Notication Control, Version Control, Access Control and Query & Search. The Anchor class is a subclass of Query & Search class. proxhy objects [12]. Instead of storing the contents, a data wrapper node stores a reference to the actual location of the contents. This allows links to be anchored to les in the Unix le system. The Link class supports a very general multiheaded (n-n) link. Links have a direction, but can be traversed in both directions. Links maintain two lists of endpoints (to and from). A link endpoint can be one of three types: static, dynamic (computed) or dangling. A static endpoint contains an anchor / component OID pair, a dynamic endpoint contains a script evaluating to an anchor / component OID pair, and a dangling endpoint is simply empty. The Composite class supports a general aggregation mechanism. Composites are unstructured collections (sets) of other components referenced by their OID. Composites are either static or dynamic (computed). A static composite contains a list of component OIDs, while a dynamic composite contains a script (query) evaluating to a list of component OIDs. 2.3 Integration Model Layer The basic built-in integration model supports two types of hypermedia objects, Anchor and Link (Figure 3). The Anchor class provides operations to create, update and delete endpoints in artifacts. The Link class provides operations to create, update, delete and follow links. Participating tools can extend and tailor the integration model and communication protocol by adding new (sub)types and new messages and specializing existing messages in the Anchor and Link class. This means that tools can agree on their own models for increased (or decreased) integration and participation in hypermedia services. Communication between participating tools and the hypermedia framework is based on a generic object-oriented message passing mechanism: (send object message. arguments) Thus, the integration model layer provides a exible communication protocol supporting an extensible set of hypermedia services, rather than a xed set of services. 2.4 Levels of Integration The hypermedia framework should be able to provide hypermedia linking services for both tools that have been created to be used with the framework and, more interestingly, tools that have been created independently of the framework. This requires that dierent tools can be integrated to participate in the hypermedia services at dierent levels. To illustrate this, we describe three levels of integration: full, partial and no integration. Full integration At this level of integration, tools use the hypermedia framework to store all its artifacts in dierent node types. Artifacts managed by the tools can serve as endpoints of references (links). Anchors allow pieces of data within artifacts to serve as endpoints for links. When navigating a reference to an artifact, the hypermedia framework launches the appropriate tool displaying the artifact. If an anchor connects the link to a particular piece of information in the artifact, this piece of information is highlighted in the tool. Partial integration Like full integration, except that at this level of integration, tools use the hypermedia framework to provide anchors and links to connect (pieces of) artifacts which are stored elsewhere in the computing environment, e.g., in the le system. The fact that anchors and links are stored separately and superimposed on the artifacts by the tools, makes it possible to link into artifacts stored on read-only media such as CD-ROM. No integration At this level of integration, tools store its artifacts elsewhere. Artifacts managed by non-integrated tools can only have incoming links; it is not possible to follow links from these artifacts. Anchors, if provided, can only refer to an artifact as a whole, not to a particular piece of data within the artifact. When navigating a reference to an artifact managed by a non-integrated tool, the hypermedia framework launches the tool displaying the artifact. No hypermedia services are available when working with this tool.

4 The hypermedia framework must support all levels of integration ranging from full over partial to no integration to allow all manner of existing and future tools to be integrated. Depending on the level of integration, the hypermedia framework places certain requirements on tools to be able to use the hypermedia services. Requirements on tools ranges from no requirements (no integration), over the ability to communicate with the hypermedia framework (e.g, using sockets) and exchange anchor identiers 1 (partial integration) to the situation where the tool relies 100% on the services of the hypermedia framework (full integration). A fully integrated tool must be able to communicate storage requests to the hypermedia framework and respond to hypermedia events. 2.5 Integration Method Integration of tools in the hypermedia framework will generally require the followings steps: analyzing the tool to determine the degree of openness in the tool, determining an appropriate level and model of integration for the tool, and specializing the built-in functionality of the hypermedia framework to support the chosen level and model of integration. The latter task is divided into two subtasks: specializing the integration model and specializing the data model of the hypermedia framework to provide the necessary services. 3 Hyperdisco Prototype In this section, we present a brief overview of HyperDisco, a prototype implementation of an objectoriented hypermedia framework based on the described concepts. A more detailed technical description of the HyperDisco prototype is provided in [23]. We will briey describe the system architecture and the individual architectural components providing the data model and integration model layers. HyperDisco is implemented using the Hyperform hypermedia system development environment [24, 26]. The HyperDisco system architecture is composed of a distributed hypermedia database (hyperbase) management system, tool integrators and participating tools as depicted in Figure 4. The tool integrator implements the integration model layer (Figure 3) and the hypermedia database implements the data model layer (Figure 2) of the hypermedia framework. The architecture can be scaled from a single tool integrator / hyperbase pair to multiple, distributed tool integrators and hyperbases. The tool integrator is the central component of the architecture supporting multiple integration models allowing distributed heterogeneous tools to participate in hypermedia services. The tool integrator controls access and operation of a multi-hyperbase management system and implements all the necessary runtime support for participating tools such as distribution of 1 What exactly is exchanged depends on the chosen model of integration. The model must specify a way to uniquely identify the appropriate link in a follow-link request. Depending on the model, the tool could, for instance, communicate an OID of the selected anchor or an anchor value / le name pair to allow the hypermedia framework to determine what link to follow. integrator Hypermedia database Hypermedia database integrator Hypermedia database Figure 4: The HyperDisco system architecture. integrators provide the integration model layer and hypermedia databases provide the data model layer of the hypermedia framework. events from the hyperbases and storage, manipulation and retrieval of linking and anchoring information from the hyperbases. integrators also allow participating tools (connected to the same tool integrator) to share hypermedia structures and to communicate using an event-based mechanism. Both the tool integrator and the hypermedia database component is based on an internal computational engine that provides an object-oriented extension language which allows the built-in services to be extended and tailored dynamically at runtime. New (versions of) classes are created by composing and sending a message to the component containing a description of the class. Thus, the integration model and data model can be customized at runtime allowing tools to be integrated on the y in a rapid prototyping manner. 4 Experiences and Related Work This section presents two tests that have been performed with the HyperDisco prototype as a proof of concept. Two existing tools were integrated in the hypermedia framework to test dierent specializations of the integration model and dierent levels of integration. Based on the tests, preliminary experiences with the HyperDisco framework are presented. We then compare HyperDisco to related work. 4.1 Test 1: Anchor Link Integration Model This test uses an integration model composed by anchor and link abstractions as depicted in Figure 5. We have integrated the GNU Emacs text editor [22] and Idraw drawing tool at dierent levels of integration. Emacs is partially integrated and Idraw provides no integration with the HyperDisco framework. Anchors are made responsible for maintaining information on where the artifact is stored, what application can display the artifact, and what particular piece of data within the artifact (if any) is used as endpoint for the hypermedia link. Links in the model are simply used to connect anchors. The following example illustrates the communication (message passing) necessary to follow a link from Emacs to Idraw.

5 Buffers File Edit Help InterViews drawing editor sketch.ps test.txt This is an example of a text file which have a hypermedia link to an Idraw sketch. The user can follow the link by selecting the marked word. sketch.ps Emacs: test.txt (Text) application: emacs value: hypermedia link file: ~/HyperDisco/test.txt from: 431 to: 142 application: idraw value: file: ~/HyperDisco/sketch.ps anchor #431 link component #1608 anchor #142 Figure 5: Principles and abstractions in the Anchor Link integration model. Example: Follow a link from Emacs to Idraw By selecting the anchor value "hypermedia link", the user indicates that she wishes to follow the link associated with the anchor. Emacs looks up the anchor value in an internal anchor table and gets hold of the belonging anchor OID (#431). Emacs sends a follow-link message to the link class in the tool integrator component with the anchor OID as argument: (send integration-model-link-class follow-link 431). The follow-link method sends a message to the hypermedia database requesting the anchor associated with anchor #431: (send data-model-link-class get-anchor 431). The get-anchor method locates the link associated with anchor #431 (by querying the database), which turns out to be link #1608. Then the get-anchor method reads the associated anchor OID (#142) and reads and returns the entire anchor object (#142) to the calling method (follow-link). Based on the attribute values of the anchor object (#142), the follow-link method can start the Idraw application displaying the relevant le. The followlink operation is now completed. Implementation of the Anchor Link integration model in the HyperDisco framework involved specialization of the built-in Anchor and Link class at the integration model layer and the built-in Anchor and Link class at the data model layer to provide the necessary services (attributes and methods). It was, for instance, necessary to extend the data model Link class with a get-anchor method and the data model Anchor class with additional attributes (application and le). This integration model requires that Emacs as a partially integrated tool is capable of managing an anchor table data structure and communicating with the HyperDisco framework via sockets. The contents of the anchor table is retrieved from the hypermedia framework when a le is loaded. The model places no requirements on Idraw as a non-integrated tool. 4.2 Test 2: Data Wrapper Node Integration Model The second test uses a more complicated integration model with node, link and anchor abstractions (Figure 6). Again, we have integrated the Emacs editor and Idraw drawing tool at dierent levels of integration. Like before, Emacs is partially integrated and Idraw provides no integration with the Hyper- Disco framework. Anchors simply hold information on what particular piece of data in the artifact (in any) is used as link endpoint. Nodes are now made responsible for maintaining information on where the artifact is stored, what application can display the artifact, and which anchors are associated with the artifact. Links are used to connect node / anchor pairs. The following example illustrates a follow-link operation from Emacs to Idraw. Example: Follow a link from Emacs to Idraw By selecting the anchor value "hypermedia link", the user indicates that she wishes to follow the link associated with the anchor. Emacs sends a follow-link message to the link class in the tool integrator component with the application name, le name and anchor value as arguments: (send integration-model-link-class follow-link "emacs" "/user/kock/hyperdisco/test.txt" "hypermedia link"). The follow-link method sends a message to the hypermedia database requesting the node associated with the selected anchor value: (send data-model-link-class get-node "emacs" "/user/kock/hyperdisco/test.txt" "hypermedia link"). The get-node method locates the node

6 Buffers File Edit Help InterViews drawing editor sketch.ps test.txt This is an example of a text file which have a hypermedia link to an Idraw sketch. The user can follow the link by selecting the marked word. sketch.ps Emacs: test.txt (Text) value: hypermedia link anchor #349 application: emacs file: ~/HyperDisco/test.txt anchors: 349 application: idraw file: ~/HyperDisco/sketch.ps anchors: 417 value: anchor #417 node component #1287 node component #542 from: (1287,349) to: (542,417) link component #1077 Figure 6: Principles and abstractions in the Data Wrapper Node integration model. (#1287) and anchor (#349) of the selected anchor value by querying the database. Based on the anchor and node OID's, the get-node method locates the link (#1077) by query. Finally, the get-node method reads the node OID (#542) in the link and, reads and returns the entire node object to the followlink method. Based on attribute values, the followlink method starts the Idraw application displaying the le. Implementation of the Data Wrapper Node integration model in the HyperDisco framework involved adding a Node class and specialization of the built-in Anchor and Link class (integration model layer) and specialization of the built-in Node, Anchor and Link classes (data model layer). For instance, a text node subclass was created to support textual artifacts (in this case text les in Emacs). This integration model places fewer requirements on Emacs as a partially integrated tool. Emacs must simply be able to communicate with the HyperDisco framework via a socket protocol. Like before, no requirements are placed on Idraw as a non-integrated tool. 4.3 Experiences Experiences achieved in the described two and other tests with the HyperDisco framework fall into several categories. Due to the overall focus of this paper, we will only present experiences that relate to integration and modeling aspects. Existing versus new tools. In the two tests, we have only dealt with integration of existing tools, since this is the most dicult type of integration, and probably also the most realistic, based on the assumption that users will not give uptheir favorite tools in exchange for hypermedia functionality. Developing new tools with hypermedia functionality is a matter of including support for this functionality in the design and development process, for example, by including a dedicated library in the tool making use of the hypermedia framework services. Integration models. The HyperDisco prototype supports dierent models of integration. We have showed how Emacs can be partially integrated in two dierent ways to use hypermedia services. The presented models dier in the way basic hypermedia abstractions are composed to support hypermedia linking and in the way tools communicate with the framework. Both models allow participating tools to store artifacts elsewhere in the computing environment. Artifacts are not altered by the operations of the hypermedia framework, since anchors and links are superimposed on artifacts at runtime. Both models therefore allow references into read-only media. Integration models are developed by specializing the built-in classes in the integration model layer and data model layer of the framework. The HyperDisco prototype allows new integration models to be shaped and new tools to be integrated at runtime, thus supporting a rapid prototyping approach totoolintegra- tion. This feature makes it is easy to experiment

7 with alternating integration models and communication protocols to determine the best way tointegrate individual tools or a set of coherent tools in the framework. Levels of integration. The HyperDisco prototype allows tools to be integrated at dierent levels of integration depending on the nature of the tool. Tests have dealt with integration of three types of existing tools: extensible, semi-extensible and closed. Fully extensible tools (such as Emacs) can be integrated with the hypermedia framework at any level of integration. Semi-extensible tools (e.g. tools providing a limited macro denition capability) can in many cases be partially integrated. It is dicult (but not impossible) to integrate closed tools (such as Idraw) in the hypermedia framework. No matter how closed a tool is, it will always be possible to follow links to artifacts managed by the tool. The problems arise when we wish to follow links from artifacts managed by closed tools. Dierent levels of integration in the hypermedia framework places dierent requirements on the tool. As a minimum, atoolmust be able to communicate with the hypermedia framework to make use of the hypermedia linking capabilities. Depending on the level and model of integration, tools must meet additional requirements such as the ability to maintain an internal anchor table, to receive and respond to hypermedia events and to store its artifacts in the hypermedia database. In addition to these requirements, tools supporting hypermedia linking must in some way make these facilities available to the user through a user-friendly interface. The user should be able to locate anchors and follow links to related artifacts and to create, share and delete relations in a natural way. The tests showed that dierent integration models place dierent requirements on tools in order to be partially integrated in the hypermedia framework. Results indicate that models that place more requirements on the tools rely less on queries in the hypermedia database, for example, the fact that Emacs in the rst test is able to communicate the anchor OID to the integration link class saves two complex queries in the hypermedia database (in a follow-link operation) compared to how things are done in the second test. 4.4 Related Work An increasing number of hypermedia systems and frameworks are designed as open systems allowing existing and future tools to be integrated to make use of the hypermedia linking services. The most prominent open hypermedia systems and frameworks include Texas A&M University's Proxhy [12] and SP3 [14], Sun's Link Service [19], Euroclid's Multicard [20], University of Southampton's Microcosm [6], Aarhus University's DeVise Hypermedia (DHM) [9] and University of California, Irvine's Chimera [1]. Existing open hypermedia systems and frameworks can be divided into two categories. The rst category (DHM and SP3) includes a hypermedia database supporting a full hypermedia data model capable of providing storage of all artifacts as well as providing storage of hypermedia linking information for participating tools. The latter category (Microcosm, Proxhy, Multicard, Chimera and Link Service) makes the assumption that participating tools use other information repositories to store their artifacts and only use the hypermedia database to store hypermedia linking information. HyperDisco belongs to the rst category. HyperDisco provides a full hypermedia data model and allows tools to participate in the hypermedia services at various levels depending on the tool. Most other open hypermedia frameworks share the basic assumption made in the HyperDisco project, that providing support for integration of existing tools is the appropriate approach, rather than to develop a new set of tools providing hypermedia services. The work on Microcosm and DHM has shown that many closed tools can be integrated with an open hypermedia framework and provide links both to and, more interestingly, from artifacts managed by the tools. The work has also shown that is it not possible to integrate closed tools in a general way. Each tool must be carefully analyzed and, depending on its nature, integrated in its own special way. HyperDisco diers from other open hypermedia frameworks by allowing the integration model to be specialized dynamically. Participating tools can dynamically extend and tailor the integration model and communication protocol by adding new messages and specializing existing messages and integration model objects. This means that tools can agree on their own models for increased (or decreased) integration and participation in the hypermedia services. Other systems provide a single integration model and communication protocol. s are integrated at dierent levels in these systems by using more or less of the xed set of operations in the communication protocol. 5 Conclusions The overall goal of the HyperDisco project is to provide a hypermedia framework for exible software system integration. HyperDisco takes a particular approach in attaining its goal, namely to provide an extensible application independent hypermedia service within an open, distributed architectural setting. The basic concept is that extensibility at both the data model and integration model levels combined with carefully designed broadly applicable generality at both levels can facilitate exibility and tailorability system wide. We believe that this notion is a reasonable and workable foundation for a hypermedia framework. The HyperDisco prototype provide us with a testbed allowing us to examine the validity of the proposed concepts. Preliminary experiences indicate that HyperDisco provides a useful framework for exible software system integration. Future tests and experiments will further assess the integration capabilities and try to locate potential problems and bottlenecks in the HyperDisco prototype. 5.1 Current Status and Future Plans The HyperDisco prototype operates in Unix environments and is presently hosted on Sun Sparcstations. Currently, we have integrated a small (but steadily growing) set of tools and data formats to assess the integration capabilities of the framework. We

8 have found the prototype suitable to conduct various tests and experiments addressing the many important characteristics of hypermedia frameworks discussed in the Introduction. This paper has focused on openness, extensibility, integration and modeling capabilities of the prototype. Other tests have focused on multiuser, distribution, interoperability and collaboration aspects as well [23]. Future tests and experiments will address the important issues of scalability, heterogeneity, performance and eciency. References [1] K. M. Anderson, R. N. Taylor, and E. J. Whitehead. Chimera: Hypertext for heterogeneous software environments. In Proceedings of ECHT '94, pages 94{107, Edinburgh, Scotland, Sept ACM. [2] J. Bigelow. Hypertext and CASE. IEEE Software, 5(2):23{27, Mar [3] J. Bigelow and V. Riley. Manipulating source code in Dynamic Design. In Proceedings of Hypertext '87, pages 397{408, Chapel Hill, NC, Nov ACM. [4] J. Conklin. Hypertext: An introduction and survey. IEEE Computer, 20(9):17{41, Sept [5] M. L. Creech, D. F. Freeze, and M. L. Griss. Using hypertext in selecting reusable software components. In Proceedings of Hypertext '91, pages 25{38, San Antonio, TX, Dec ACM. [6] H. Davis, W. Hall, I. Heath, G. Hill, and R. Wilkins. Towards an integrated information environment with open hypermedia systems. In Proceedings of ECHT '92, pages 181{190, Milan, Italy, Dec ACM. [7] N. M. Delisle and M. D. Schwartz. Neptune: A hypertext system for CAD applications. In Proceedings of SIGMOD '86, pages 132{143, Washington, D.C., May ACM. [8] P. K. Garg and W. Scacchi. A hypertext system for software life cycle documents. IEEE Software, 7(3):90{99, May [9] K. Grnbk and R. H. Trigg. Design issues for a Dexter-based hypermedia system. Communications of the ACM, 37(2):40{49, Feb [10] F. G. Halasz. Reections on NoteCards: Seven issues for the next generation of hypermedia systems. Communications of the ACM, 31(7):836{852, July [11] F. G. Halasz and M. D. Schwartz. The Dexter hypertext reference model. Communications of the ACM, 37(2):30{39, Feb [12] C. J. Kacmar and J. J. Leggett. Proxhy: A processoriented extensible hypertext architecture. ACM Transactions on Information Systems, 9(4):399{419, Oct [13] R. Kadia. Issues in building a exible software development environment: Lessons learned from the Arcadia project. In Proceedings of SIGSOFT '92, Washington, D.C., Dec ACM. [14] J. J. Leggett and J. L. Schnase. Viewing Dexter with open eyes. Communications of the ACM, 37(2):76{86, Feb [15] J. J. Leggett, J. L. Schnase, J. B. Smith, and E. A. Fox, editors. Final report of the NSF workshop on hyperbase systems, Washington, D.C., October 15-16, Department of Computer Science Technical Report TAMU-HRL , Texas A&M University, June [16] K. C. Malcolm, S. E. Poltrock, and D. Schuler. Industrial strength hypermedia: Requirements for a large engineering enterprise. In Proceedings of Hypertext '91, pages 13{24, San Antonio, TX, Dec ACM. [17] N. Meyrowitz. The missing link: Why we're all doing hypertext wrong. In E. Barrett, editor, The Society of Text: Hypertext, Hypermedia, and the Social Construction of Information, pages 107{114, The MIT Press. [18] J. Noll and W. Scacchi. Integrating diverse information repositories: A distributed hypertext approach. IEEE Computer, 24(12):38{45, Dec [19] A. Pearl. Sun's link service: A protocol for open linking. In Proceedings of Hypertext '89, pages 137{146, Pittsburgh, PA, Nov ACM. [20] A. Rizk and L. Sauter. Multicard: An open hypermedia system. In Proceedings of ECHT '92, pages 4{10, Milan, Italy, Dec ACM. [21] J. B. Smith and F. D. Smith. ABC: Ahypermedia system for artifact-based collaboration. In Proceedings of Hypertext '91, pages 179{192, San Antonio, TX, Dec ACM. [22] R. M. Stallman. Emacs: The extensible, customizable, self-documenting display editor. In D. R. Barstow, H. E. Shrobe, and E. Sandewall, editors, Interactive Programming Environments, pages 300{325, McGraw-Hill. [23] U. K. Wiil and J. J. Leggett. The HyperDisco approach to open hypermedia systems and seamless integration of information. Submitted to Hypertext '96, Available through the rst author. [24] U. K. Wiil and J. J. Leggett. Hyperform: A hypermedia system development environment. Submitted to ACM Transaction on Information Systems, Available through the rst author. [25] U. K. Wiil and J. J. Leggett. Concurrency control in collaborative hypertext systems. In Proceedings of Hypertext '93, pages 14{24, Seattle, WA, Nov ACM. [26] U. K. Wiil and J. J. Leggett. Hyperform: Using extensibility to develop dynamic, open and distributed hypertext systems. In Proceedings of ECHT '92, pages 251{261, Milan, Italy, Dec ACM.