Two Approaches to Software Repositories and Hypertext Functionality: Oinas-Kukkonen and Rossi: JoDI

On Two Approaches to Software Repositories and Hypertext Functionality

Harri Oinas-Kukkonen and Gustavo Rossi*
Department of Information Processing Science, University of Oulu,
FIN-90570 Oulu, Finland
Email: Harri.Oinas-Kukkonen@oulu.fi, Harri Oinas-Kukkonen home page
*LIFIA, Departamento de Informatica, UNLP, CONICET and UNLM, Argentina
Email: gustavo@sol.info.unlp.ar, Gustavo Rossi home page

Abstract

This paper discusses the use of hypertext functionality in software engineering environments (SEEs). We discuss some of the outstanding problems in the construction and use of SEEs and software repositories, and show that by using hypertext it is possible to enhance their functionality. The integration of hypertext into this kind of software system poses several challenges in design and implementation, however. Two different approaches for implementing hypertext functionality are presented.

1 Introduction

Software Engineering Environments (SEE) appeared in the mid-1970s as an attempt to integrate software engineering techniques, methods and tools. (Jarke 1992) It is widely known that during the software development process many different kinds of documents are generated; they are usually created as part of group work and many designers share them. SEEs let system developers document and model an information system from its initial user requirements through design, implementation, testing and maintenance, letting them apply tests for consistency, completeness and conformance to standards. SEEs deal with a great variety of information from different sources: software artifacts (analysis and design documents, code, etc.), process information (activities and their pre- and post-conditions), human resources, plans, rationales, etc. Many of these information items are manipulated by different tools (graphic editors, compilers, configuration managers, etc.) and development roles (managers, programmers, etc.) and must be readily available and easily accessible.

Though software engineering environments have not provided a \0xFFFDsilver bullet\0xFFFD for software development, (Brooks 1987) they have helped to get developers to use software engineering techniques correctly and consistently. They have also provided support for the integration of tools, (Jarke 1992) the reuse of high-level software artifacts, (Potts and Bruns 1988) the use of a variety of methods, notations and platforms, the integration of formal and informal approaches to software development, (Bruel and France 1996) and the use of different representation formalisms for describing the software process and their customization according to the application domain. (Finkelstein et al. 1992)

Recently, a new generation of software engineering environments has emerged, emphasizing software repositories. (Sagawa 1990) A repository contains the collection of software artifacts managed by the SEE, making them accessible to a great variety of integrated tools. A software repository is basically a database of software artifacts; it can be used as a 'save deposit box' to check in and check out models with valid design data, as a basis for all data management services during system development, and as a common environment for group activities. Repositories should be extensible to permit their integration with management tools and with existing commercial packages (such as standard databases and workflow tools).

Current approaches for building software repositories vary from passive data dictionaries to active databases, (Ceri and Fraternali 1997) including design information and version management; support technologies vary from repositories based on standard relational database technologies to those supported by complex object stores.

While software repositories have been a step forward with respect to software engineering environments as they decouple artifacts from the tools that deal with them, we can still improve access to these artifacts by using a richer model for expressing relationships among them: the hypertext model.

This paper discusses the integration of hypertext functionality (HTF) into software engineering environments. The hypertext functionality approach (Oinas-Kukkonen 1997a, Bieber et al. 1997) focuses on incorporating hypertext features into non-hypertext systems so as to provide their users with an associative way of accessing, analysing and organizing information. HTF is a desired functionality of software systems that supports the relating of information or pieces of it to each other in an associative manner. This paper shows that hypertext functionality can play the key role of connecting different artifacts of a software repository, helping to support different process models, etc. Integrating different information structuring paradigms (hypertext with databases, for instance) as is common when using hypertext, provides a powerful framework for creating and accessing software objects. We discuss different ways in which hypertext has been used for supporting software repositories.

The paper is organized as follows. Section 2 describes the use of hypertext functionality in general terms. Sections 3 and 4 describe two different approaches to enhance software engineering environments. Section 5 compares and discusses these two approaches.

2 Hypertext functionality and software repositories

Hypertext has been used for representing software design documents, (Bigelow 1988) and hypertext-based software engineering systems and environments have been developed. (Cybulski and Reed 1992) Hypertext systems are useful for information management in large-scale software engineering environments because they can cope with the variety of data types in software artifacts and with the need to navigate through them through semantic relationships. Building a hyperdocument in which nodes represent design artifacts and links express the relationships among them is obviously appealing.

For example, while viewing an initial user requirement, we can follow a link to a module defining the static object model for that requirement (Figure 1). In the same way, we can traverse the link to the behaviour model of a particular class, or we can go from the design model to the implementation, and so on.

Figure 1

Figure 1. Hypertext network with design documents ( full-size figure)

Also, the problem of disorientation, which is common with some hypertext systems, can be partially solved by providing abstraction constructs for grouping hypertext nodes as composites (perhaps recursively). In Figure 2 each composite (or aggregated object) may represent a network on its own (obviously navigation is allowed 'crossing' the composite borders), and if some sense of locality is given (as explained below) we can provide the reader with a closed and friendly environment. Providing additional information such as presented in browsers, navigation maps, etc., will also help in navigating complex software spaces. Note that a software browser, like for example the typical class hierarchy browser of object-oriented environments, a debugger, etc., is difficult to model as a hypertext node, though it would be interesting to enhance it with navigation facilities. In this case we would have either to implement navigation on top of the browser or modify the basic hypertext data model so that we can build nodes that behave as such tools.

Figure 2

Figure 2. Abstracting nodes and relationships ( full-size figure)

The advantage of building a software repository in terms of a network of objects related by hypertext links is that different tools combining navigation with conventional queries may be constructed. For example, the object network may be searched by object-oriented queries as usual in object-oriented database management systems; e.g. queries, such as "Find all C++ methods, which invoke the method they refine", will need to follow links whose origin is in a C++ method. Being a network structure rich enough to support navigational access, the same result could also have been obtained by navigating through C++ methods using hypertext functionality. Queries and complex browsing involving analysis and design data or relating use scenarios with implementation could also be performed. However, using only the hypertext metaphor for structuring the whole environment would not necessarily be a good choice for various reasons:

  1. Hypertext was originally devised for supporting mainly unstructured data (text, and more recently other media), while software engineering documents combine unstructured documents such as text-based requirements with others that are highly structured such as design charts and object relationship models.
  2. Structuring mechanisms are not common in hypertext systems, while, for example, classifying data elements, factoring their common aspects or grouping them in aggregation hierarchies is important in software repositories.
  3. Hypertext provides a rich metaphor for navigation, but it does not necessarily support a rich behavioural model which is critical for implementing many of the features in software engineering environments For example, some of the queries mentioned before require adding some behaviour to nodes and to the composite structures.
  4. Links lack semantics in many of the current hypertext systems, while being able to define semantically rich relationships among object types is another strong requirement in software engineering environments.

While many of these problems can be solved by enriching the traditional hypertext model (e.g. the typing of nodes and links could partially solve the last problem above), it is better to decouple the basic functionality of the environment from the hypertext features as proposed by the HTF approach. In this way the best of the two worlds can be obtained: the complex behaviour of the underlying application, and the navigation facilities of the hypertext functionality.

To summarize, there are two ways of using hypertext in the context of software engineering environments and repositories:

  • Building the SEE around hypertext as has been done in systems like Neptune/HAM. (Bigelow 1988) In this case nodes and links are the main abstractions in the application. As explained above, this alternative has some limitations.
  • Using hypertext as value-added functionality to enrich the features of the environment. In this approach, nodes and/or links are plugged into the application\0xFFFDs objects to provide navigation facilities, without any conflict with the existing domain functionality that is decoupled from the hypertext component.

The advantage of the latter approach, i.e. hypertext functionality, is that one can exploit the existing SEE facilities while the associative hypertext features can be used for navigating through the information, as well as for organizing and analysing the information. Besides, if the structure of the existing environment is preserved and the HTF implementation is designed as modular, the hypertext modules will be independent of the existing software repository. We believe that the hypertext functionality approach is superior to building the full environment around hypertext. Next we describe two different approaches for implementing HTF in the context of software engineering environments.

3 Implementing hypertext functionality with an application framework

Application frameworks are an interesting and powerful approach for reusing designs using objects. The basic idea behind frameworks is to implement an abstract design for the intended domain. The design is abstract because it only implements what is common for all application in that domain. To create a new application a designer adapts the framework to the particular features of the application, either by instantiating or customizing the framework. When using objects correctly, this extension is obtained by either specializing classes in the framework or by creating framework objects and composing them with application objects. (Fayad and Schmidt 1997, Pree 1994)

OO-Navigator (Garrido and Rossi 1996, Garrido and Rossi 1998) is an object-oriented implementation of a domain-specific architecture for hypermedia. This framework comprises a set of class hierarchies representing well-known hypertext concepts: nodes, links, access structures and a collaboration model implemented in abstract classes that allows an object-oriented application to be extended with hypertext functionality. OO-Navigator views applications as having three layers: the objects layer, the hypermedia layer and the interface layer. The objects layer contains the application behaviour, while the hypermedia layer implements navigation.

Using the framework involves creating instances of framework classes (nodes and links for example) and plugging them into corresponding application classes in a similar way to the process of creating user interfaces using the Model-View-Controller application framework in Smalltalk. (ParcPlace 1996, Krasner and Pope 1988) OO-Navigator allows hypertext functionality to be implemented by assisting the designer to build hypertext structures that use the underlying objects and relationships as the source for information in nodes and links. From the point of view of a final user, what we get by using OO-Navigator is a running system that combines features of hypertext applications (such as forward and backward navigation) with more conventional application behaviour. From the point of view of a designer, using OO-Navigator implies identifying which classes will have a hypertext counterpart, creating nodes and links (from framework classes), connecting those nodes and links with objects and defining interfaces for the nodes. Once we have done this, the application 'acquires' hypertext functionality.

By making nodes and links reflect the design model of the application, the inclusion of hypertext functionality can be done smoothly. As each node is a view on an application object and each link maps a relationship among objects, the resulting hyperdocument may evolve together with the application evolution (Figure 3). A more comprehensive discussion on the structure of OO-Navigator can be found in Rossi et al. (1998). We next explain how we used OO-Navigator to add HTF to computer-aided software engineering (CASE) environments.

In the context of the discussion in section 2, our approach decouples objects and tools in the software repository from their navigational views (nodes and links); while basic repository functionality is implemented in the objects (repository) layer, nodes and links derived from repository objects are instantiated from framework classes. Nodes do not replicate data in the repository layer as they just 'view' application objects. In any case, the framework provides functionality for making navigational objects persistent.

The level of granularity of hypertext relationships in the CASE tool can be defined regardless of the level of granularity in the application layer. If, for example, we have objects representing requirements in the application layer, we will be able to define nodes viewing those objects and links departing from a requirement (or from one of its attributes such as a text item). However, if requirements are thought as aggregation of finer-level objects (their attributes), we could also define composite nodes and navigate from the lower-level ones to other nodes (e.g. to a class design document).

We will explain the process of deriving a hypermedia view of design documents by using as an example a CASE system for the object-oriented software engineering (OOSE) methodology. (Jacobson et al. 1992) We first built a design model for the CASE environment; it contains classes such as AnalysisModel, Model Object, with sub-classes such as InterfaceObject and EntityObject; we also have UseCaseModel containing UseCases. An instance of the Analysis Model contains information about the application domain and will contain (as part of its aggregate structure) instances of Interface Object, Entity Object, etc. Meanwhile, for each Analysis Model we will have a Use Case Model containing many UseCases. An instance of AnalysisDocument contains managerial information related to a particular project.

We next introduce the basic steps we followed to build a hypertext view of the CASE tool by focusing on how this extension improves the use of the system. We first analyse which classes should be extended with hypertext features; candidates were, obviously, instances of Model Object (and its sub-classes) and UseCaseModel. Then we create hypermedia components as instances of some framework classes and compose domain objects with framework objects (e.g. nodes).

To build the HTF of our CASE application, we need to create:

  • An instance of class Hypermedia. This object will contain the whole hyperdocument created from CASE components. Class Hypermedia is provided by the framework and will act as the main controller for navigation by containing navigation histories, the set of user profiles, etc. It is also useful for providing query support both at the navigation level ("what was the last node we accessed?") or at a more conceptual one ("which documents are linked to this requirement?"
  • A 'point of view' for each different user profile and the transitions that are allowed between different points of views. The definition of user profiles is based on the idea of 'actors' in the OOSE methodology. (Jacobson et al. 1992) It is widely known that CASE tools must be adapted to different kinds of users: analysts, designers, programmers, managers, etc. While all users will share the information base (a set of design artifacts) each of them will need to perceive different aspects of these artifacts and will want to navigate across different relationships. Allowing hypertext nodes to have different views (according to the user\0xFFFDs preference) and making each view 'observe' different attributes of the same object solves this problem, as we show below. The CASE tool may have a view for the client and each different developer role: analyst, designer, programmer, tester, etc. Defining transitions implies stating that a person may play more than one role (a programmer may also be an analyst) and that he/she can switch from one to the other. For each class of nodes (for example UseCase), its instances will appear as having different 'faces', one for each role. Moreover, we will define different outgoing links for each 'face'. The whole hyperdocument will look as shown in Figure 3.
  • Node classes and unclassified nodes. A 'node class' defines common properties of a group of nodes that contain the same attributes, look alike and are related to other nodes in the same way. When extending an OO application, node classes will be derived from application classes; objects belonging to an application class will usually be mapped to nodes belonging to the same node class. We will have a node class for each important design document we intend to navigate using hypertext links. Examples are UseCaseModel, AnalysisModel, etc. OO-Navigator automates the creation of new nodes; each time a UseCase object is created, a corresponding node is also instantiated and they are connected to each other. Some nodes will not be related with classes in the underlying CASE tool. For example, we may create a node that collects all UseCases for a particular actor. Node classes allow the idea of type (or class) to be extended to the hypermedia document, thus helping to structure the navigation space.
  • Indexes and other access structures. Indexes provide direct access to a group of nodes for easier navigation. For example, we can create a Project Index, a ControlObjects Index, etc. Each index 'points' to a set of nodes and will present them in the interface using some outstanding attributes (e.g. project names, etc.). Indexes may be simple or hierarchical; for example, we can build a Project Index that allows us to select first an application domain and then a project in that domain.
  • Link classes. Links represent the association between two nodes. They activate navigation through their origin anchors (in the node interfaces). Link classes (as node classes) provide a typing concept for links; for example, we can define a link class DerivedFrom connecting entity object nodes with use case nodes. When link classes reflect relationships existing in the underlying application, we give further structure to the hyperdocument. It is possible to define a link class automatically to create links departing from each node of a class. Most links in OO-Navigator are generated automatically as the framework has the knowledge about link types that allows this each time the corresponding node object is instantiated. The CASE user may create certain links by hand, however, for example to relate some artifacts opportunistically.

OO-Navigator is an extensible and flexible environment. It can be used to extend 'legacy' repositories easily. The full strength of OO-Navigator can be used when application designers are aware of the framework features. In the context of our CASE tool it is easy to define new tools and improve them with hypertext links. For example, we can build a debugger (similar to the Smalltalk debugger) and enrich its inspection functionality with links that allow navigation from the debugger window to related documents. We can also integrate this functionality with that of the environment (inspecting objects and methods, etc.). In this particular example (the Smalltalk system), seamless tool integration is easy and a good example of the way in which HTF can be used to improve CASE tools.

4 Enriching software modeling through hypertext functionality

Often, neither the support of software development methodologies nor the automatic generation of hypertext representation of design data is enough for representing semantic dependencies between design documents. In many cases users should be able to create additional semantic and/or associative connections, at will, by hand. This kind of support is achieved via such hypertext functionality, which enables use of the material already contained in a diagram as a collection of nodes between which the associative connections are represented via links. This kind of hypertext functionality provides the information readers with smooth transfer possibilities through the dependencies between design diagrams or parts of them, and the information authors with elegant tools to create and maintain the hypertext information. In this case, all software engineers can participate in the creation and maintenance of the hypertext information.

Linking Ability is the hypertext functionality behind the model editing and argumentation tools of the MetaEdit+ CASE environment. (Kelly et al. 1996) The CASE environment has been developed in the MetaPHOR research project (Metamodeling, Principles, Hypertext, Objects and Repositories), and as part of its modern tool suite it includes such basic CASE tools as Diagram Editor, Matrix Editor and Table Editor. See Oinas-Kukkonen (1997b) for a more thorough description of Linking Ability in this environment. Linking Ability does not provide a suite of features to model or represent all software engineering concepts needed, and it does not provide a foundation for building a software repository, but rather it provides the environment with hypertext features to supplement the existing software repository.

The key features of Linking Ability include hyperlinks, annotations, bookmarks and landmarks, link attributes, link attribute query, and various link lists (Figure 4).

  1. Existing documents can be linked using two kinds of hyperlink: traceability or association links. Traceability links emphasize the possibility of tracing back to the original development requirements. One of the most important benefits of document integration performed in a hypertext manner is that it is possible to show the relations between software components relatively easily. Traceability links support the representation of dependencies between system development phases, the refinement of objects over time, or other semantic traces. Association links allow the representation of associative connections between various parts of documents to be supported.
  2. An annotation is a brief, informal record of text. The addition of annotations and the representation of their connections to the original documents take place through annotation and debate links. Annotation links provide a way of supporting the refinement of concept definitions or the recording of experience over time, which is crucial for software project success. The name debate link emphasizes design rationale, which is basically a conversation among developers in which they bring their expertise and viewpoints to bear on resolving design issues. Annotations and design rationale nodes can be investigated via browsers particularly dedicated for this.
  3. In addition to hyperlinks, some 'marks' having conventional meanings and used in place of words, or to represent a complex notion, can be attached to the documents. Two kinds of mark are provided: a bookmark and a landmark. A bookmark is a marker for keeping one's place in the collection of documents; for example, it can be attached to a specific design object in a document, which might be of interest at a later date. A landmark is a conspicuous object in a document that directs the user towards a place or identifies it, e.g. an important region in the documentation.
  4. All hyperlinks can have attributes associated with them to provide more information and a way of previewing the target before activating a hyperlink. The attributes include a name for the link, creator of the link, date and time of creation, textual description, and subtype and keyword definition. As an example, if the project uses an object-oriented methodology, the traceability links might be sub-typed into \0xFFFDrequirements-OOA\0xFFFD, \0xFFFDOOA-OOD\0xFFFD and \0xFFFDOOD-code\0xFFFD.
  5. The benefit of defining attributes for hyperlinks can be seen in the link attribute query facility. A document reader (e.g. a project manager, a reviewer, another systems designer, or the original designer, who, having been involved in creating the documentation, is now reading it later) may want to find all the project\0xFFFDs traceability hyperlinks to which the keyword \0xFFFDimportant\0xFFFD is attached. When the query is executed the user receives a hit list consisting of the links that fulfill the requirements stated in the query and can backtrack or follow any of these.
  6. Effective navigation and unlimited backtracking is supported in Linking Ability by various kinds of link lists. The interaction history enables a user to view his/her own footprints during earlier reading of the hyperdocument, and is supported by a hyperlink history list which contains the links the user has activated during the current session. Like link attribute query results, the hyperlinks that target an active document or have an active document as their source are listed as incoming and outgoing link lists. Where targets have been deleted links pointing to them are listed as dangling links so that users can recognize the possible inconsistency.

5 Discussion

These examples show two different ways of utilizing hypertext functionality in the context of software engineering environments and software repositories. In both approaches hypertext features can be added without any conflict with the application structure or the underlying abstraction mechanisms (i.e. classes and objects). By decoupling hypertext functionality from the behaviour of the environment both can evolve independently. For example, new kinds of software artifacts can be added to the repository or new hypermedia features (such as orientation tools) can be implemented without any change in the overall architecture.

Although OO-Navigator and Linking Ability both address hypertext functionality they differ in many respects. At the architectural level, OO-Navigator defines nodes and links as objects in a separate layer with respect to the underlying application, and Linking Ability basically utilizes existing objects as nodes and provides a set of semantic link types for connecting these. In this sense the use of OO-Navigator is more complex as it requires instantiating the framework, while Linking Ability allows end users to manipulate information at the interface level. While nodes and links follow closely the application class model in OO-Navigator (they 'observe' objects and relationships), Linking Ability allows more dynamic linking structures that can be built 'on the fly'. Even with support for this kind of linking, the strength of OO-Navigator would be mainly in the definition of a navigational model clearly separated from the object model, as proposed in some hypermedia design methodologies like OOHDM (Schwabe et al. 96).

There are some other differences between the two HTF approaches (Table 1). Technically, OO-Navigator emphasizes automatically generated links and their hypertext representation to end users, while Linking Ability emphasizes the use of hand-made semantic links as an additional feature of software engineering environments. In software development, OO-Navigator is basically intended to support programming, while Linking Ability mainly supports functionality for analysis and design.

Table 1. Link generation and support for development phases by the systems
OO-Navigator Linking Ability
Link generation Automatic hypertext representation of concepts in software repository Additional hand-made links to denote fine-grain relationships between design components
Software development phases Programming Analysis and design




The completeness and soundness of links (
Ashman et al. 1997) can reveal some other important differences between these two hypertext functionality approaches. Completeness concerns whether all possible links have been created and whether they are up to date. Soundness is whether the created links are desirable. Table 2 summarizes and generalizes these two approaches in terms of soundness and completeness.

Table 2. The completeness and soundness of links in the systems
OO-Navigator Linking Ability
Completeness High Low
Soundness Low High

The completeness of the set of links in Linking Ability is often relatively low, because the effort required to manually create links is high. This approach utilizes hypertext functionality as additional information on top of software design data, however, which means that the set of links is not intended to include all possible links. Only those links that authors want to emphasize are created. In this approach all links that are created are also necessary, and link attributes help others to comprehend the rationale behind the link creation and provide more information. But it can take a great effort to correct hand-made links when the data they link is changed. Even if the dangling link list helps avoid inconsistencies to some extent, the maintenance of links is the greatest difficulty in Linking Ability. OO-Navigator partially addresses the problems of the effort required to create and maintain links. The most obvious purpose of automatically generated links is in situations where there are many similar links to create. The completeness of links in OO-Navigator is high, because all links in one relationship are created by an identical process. In fact, the set of links may even bring with it the danger of over-completeness, if there are more links present than the reader can comprehend.

On the other hand, links in OO-Navigator are sound only if the derivation rules accurately reflect the author\0xFFFDs intentions. When a large set of links is created at once the soundness of individual links may be low, while the soundness of hand-made links in Linking Ability always has to be considered for each link individually. Despite advances in natural language analysis and other technologies, there are many situations where it is undesirable or impossible to implement automatically generated links. Some link types may be too complex to define and create with rules or algorithms. Some features can only be computer-generated to a limited extent or not at all, such as design rationales, ad hoc annotations, or placeholders and reminders of things for later use.

Another problem with OO-Navigator is that, even when using the associated visual toolkit, obtaining a running hyperdocument is a hard task. Designers must learn how to use the framework (for example, understanding the meaning of views, node and link classes, etc.) to derive the hypertext structure associated with an application. As application frameworks provide a way to reuse domain designs we obtain great benefits at the cost of learning the design we are reusing. (Johnson and Foote 1988) In the case of software engineering environments the trade-off is clearly justified, but this may not be the case for simpler applications.

6 Conclusion

This paper has described two different approaches to utilize hypertext functionality in software engineering environments. These approaches are complementary and an ideal software engineering environment should perhaps include both. In this kind of integrated environment hand-made links could best be applied during the early phases of software development (such as analysis and design), and automatic links could best be applied during the later phases (such as programming).

Hypertext functionality can contribute to the issue of fine-grained relationships, e.g. relationships between one requirement and another, or between a requirement and a design object, which is important and remains a research issue. We recommend that the developers of software engineering environments consider providing hypertext views to design information by using the hypertext functionality approach, which enables the environment to be enhanced with desired hypertext features.

References

Ashman, H., Garrido, A. and Oinas-Kukkonen, H. (1997) "Hand-made and Computed links, Precomputed and Dynamic links". Proceedings of Hypertext \0xFFFD Information Retrieval \0xFFFD Multimedia (HIM \0xFFFD97), Dortmund, Germany, September-October

Bieber, M., Vitali, F., Ashman, H., Balasubramanian, V. and Oinas-Kukkonen, H. (1997) "Fourth Generation Hypermedia: Some Missing Links for the World Wide Web". International Journal of Human Computer Studies, Vol. 47, No. 1, 31-65

Bigelow, J. (1988) "CASE and Hypertext". IEEE Software, March, 23-27

Brooks, J. (1987) "No Silver Bullet: Essence and Accidents of Software Engineering". IEEE Computer, Vol. 20, No. 4, April

Bruel, J. and France, R. (1996) "A Formal Object-Oriented CASE tool for the Development of Complex Systems". Proceedings of the 7th Workshop on The Next Generation of CASE Tools, Heraklion, Crete, Greece, May, pp. 1-11

Ceri, S. and Fraternali, P. (1997) Designing Database Applications with Objects and Rules. The IDEA Methodology. (Addison Wesley)

Cybulski, J. and Reed, K. (1992) "A hypertext based software engineering environment". IEEE Software, March, 62-68

Fayad, M. and Schmidt, D. (1997) "Object-Oriented Application Frameworks". Communications of the ACM, Vol. 40, No. 2, 32-39

Finkelstein, A., Kramer, J., Nuseibeh, B., Finkelstein, L. and Goedicke, M. (1992) "Viewpoints: A framework for integrating multiple perspectives in system development". Int. Journal of Software Engineering and Knowledge Engineering, Vol. 2, No. 1, 21-58

Garrido, A. and Rossi, G. (1998) "Capturing hypermedia functionality in an object-oriented framework". In Object-Oriented Application Frameworks, edited by R. Johnson and M. Fayad (John Wiley and Son)s

Garrido, A. and Rossi, G. (1996) "A Framework for extending object-oriented applications with hypermedia functionality". The New Review of Hypermedia and Multimedia, Vol. 2, 25-42

Jacobson, I., Christerson, M., Jonsson, P. and Overgaard, G. (1992) Object-Oriented Software Engineering (Addison Wesley)

Jarke, M. (1992) "Strategies for integrating CASE environments". IEEE Software, Vol. 9, No. 2, 54-61

Johnson, R. and Foote, B. (1988) "Designing reusable classes". Journal of Object-Oriented Programming, Vol. 1, No. 2, 22-35

Kelly, S., Lyytinen, K. and Rossi, M. (1996) "MetaEdit+: A Fully Configurable Multiuser and Multitool CASE Environment". Seventh International Conference on Advanced Information Systems Engineering (CAiSE \0xFFFD96), Crete, Greece, May (Springer-Verlag), pp. 1-21

Krasner, G. and Pope, T. (1988) "A cookbook for using the Model-View-Controller user-interface paradigm in Smalltalk". Journal of Object-Oriented Programming, Vol. 1, No. 3, 26-49

Oinas-Kukkonen, H. (1997a) "Embedding Hypermedia into Information Systems". Proceedings of the ThirtiethHawaii International Conference on Systems Sciences (HICSS \0xFFFD97), Vol. IV, Maui, Hawaii, January (IEEE Computer Society Press), pp. 187-196

Oinas-Kukkonen, H. (1997b) "Towards Greater Flexibility in Software Design Systems through Hypermedia Functionality". Information and Software Technology, Vol. 39, No. 6, 391-397

ParcPlace (1996) The Visual Works Smalltalk Programming Environment

Potts, C. and Bruns, G. (1988) "Recording the Reason for Design Decisions". Proceedings of the 10th International Conference on Software Engineering (IEEE Press), pp. 418-427

Pree, W. (1994) Design Patterns for object-oriented software (Addison Wesley)

Rossi, G. and Schwabe, D. and Garrido, A. (1999) "Designing Computational Hypermedia Applications". Journal of Digital Information, Vol 1, issue 4, February http://hdl.handle.net/1969.2/jodi-14/

Sagawa, J. (1990) "Repository Manager Technology". IBM Systems Journal, 2

Schwabe, D., Rossi, G. and Barbosa, S. (1996) "Systematic Hypermedia Application Design with OOHDM". Proceedings of the ACM International Conference on Hypertext '96, Washington, March