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.
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.
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. 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. 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:
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:
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.
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:
Figure 3. Hyperdocument showing the view mechanism ( full-size figure)
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.
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).
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.
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 |
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.
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.
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