Integrating Hypertext and CASE:
The Emerging Technology

Jacob L. Cybulski and Karl Reed

Amdahl Australian Intelligent Tools Programme
Department of Computer Science and Computer Engineering
La Trobe University, Bundoora, Vic. 3083, Australia


This paper describes HyperCASE, an architectural framework for integrating the collection of tools being produced as part of the Amdahl Australian Intelligent Tools Program (AAITP). The system provides a visual, integrated and customizable Software Engineering environment, supporting software developers in the areas of project management, system analysis, design and coding via a suite of loosely-coupled tools supporting both textual and diagrammatic presentation techniques.

Tool integration is achieved by combining a hypertext-based user interface with a common knowledge-based document repository in a manner which facilitates integrity and completeness checking, component and design re-use, configuration management, etc.

HyperCASE also includes extensive natural language capabilities tailored to the CASE domain. These are used in the user interface to the software repository, providing an alternative to hypertext information management and inter-document navigation. English input during system description is also available, allowing a significant degree of automation in design and concept re-use at the earliest stages of software development.

1 Introduction

The past few years (1985-1990) witnessed the growing popularity of the fundamental belief that development practices based on Software Engineering may resolve the software crisis resulting from the massive expansion of computer usage as equipment costs continue to decline. The trend resulted in increased pressure on software manufacturers to use specific methodologies in the software development process. Special emphasis was put on strict adherence to approved software life-cycle models, the types of deliverable documents, software project organisation and control, inter-personal communication channels, etc.8 At the same time, there has been a growing realisation that software production must be automated in much the same way that engineering design has, by applying computer and software technology to the task at hand, if real reductions in the cost of software development are to be achieved. This has lead to the development of CASE, which is the subject of this special issue of IEEE Software.

As early as the 1970's, software researchers attempted to improve development efficiency through the automation and integration of selected aspects of the software development process.7 The initial CASE effort focussed upon source code formating, support for structured programming and test case generation. Later work was directed at program development environments supporting flexible or customizable process models, based on tools aiding interactive construction of system descriptions dependent on standard diagraming techniques and allowing code generation. The integration of a set of such software document production tools into a uniform CASE is not possible unless the following conditions are met :-

  1. diverse classes of documents could be used at various phases of a project development;
  2. the documents produced by a given tool can be used by other tools further down the development cycle;
  3. a software developer can traverse (navigate) between various documents describing the system and its components in an efficient and convenient manner;
  4. coherence and consistency between produced documents can be assured throughout the entire software life-cycle.

Figure 1 - Software document navigation

For example, a developer may, when viewing a process symbol in a data flow diagram, wish to display the code associated with the process, its representation in a state transition diagram, to inspect the relevant section of a (standard) Systems Requirement Specification document, or the corresponding paragraph in the feasibility description. All documents need then be stored and accessible simultaneously in a common document repository, thus forming a browsable network of software documents (Figure 1).

Considerations of these kind suggest that the mechanisms for constructing software documents, for creating navigable linkages between them, and for navigating amongst the components of a document repository should be a major feature of a CASE system. If this is true, then one should expect to make significant gains by integrating the CASE system with an appropriate system providing such facilities.

Hypertext CASE
document authoring diagram editors
text-oriented tools
browsing & navigation over program slices
through refinement levels
across semantic terms
document aggregation module libraries
data structure groups
virtual structures code generation
dynamic computation run-time results
revision management software configuration management
collaborative work project team development
extensibility & tailorability multiple methodologies
concept annotation recording design decisions
consistency checking validation
completeness assessment project plan tracking

Figure 2 - Hypertext applications to CASE

In our case, we decided to integrate our CASE tools under an extended hypertext system, an information management concept that evolved quite independently of CASE, and which may be characterised as programs allowing grouping and linking of information fragments (in various media forms), so that they could be searched and browsed in a non-sequential manner, by means of visual interaction with the users (Figure 2).3 Until recently, the prospect of using hypertext (or hypermedia) as a basis for CASE systems has been largely ignored. There are, as far as the authors are aware, very few significant projects of this type, e.g. the Neptune project at Tektronix1 and the DIF system, part of Software Factory Project at USC9.

2 Architecture

As described in the previous section, the design objective of CASE tools in general is the provision of software development teams with a powerful, user-friendly and integrated software development platform capable of significantly raising the software engineers' productivity. The HyperCASE framework (Figure 3) aims to provide its users with such an environment.

Figure 3 - HyperCASE architecture

It consists of three sub-systems :- HyperEDIT, HyperBASE and HyperDICT, being the HyperCASE graphical user interface, its knowledge base and the data dictionary respectively.

HyperEDIT integrates a number of window-based, customizable graphic or text editors and browsers used in the creation, modification and presentation of software documents (ISDUIMS, SAT). All user actions performed within the HyperEDIT environment are reflected (via the EventTALK protocol) in HyperBASE representing and organising all of the software documents into a general purpose, intelligent hyper-media repository. The repository allows the document indexing and navigation (DOCMAN), their configuration management (CONFMAN), project planning and tracking (PROTRACK), recording design decisions (DETRACK), analysis of English texts (LAPSE), etc. Additionally, HyperBASE adds the sophistication of tools specific to the software engineering domain, thus, providing integrity and completeness checking of software documents (SODA), reuse of design components (CODREM), executable software specifications (EXDDESS and ANIMAL), etc. To add efficiency and storage capabilities, the document components are stored by HyperBASE in a high capacity data base, HyperDICT, accessible via an embedded query language.

It should be kept in mind that it is intended that as many tools as possible should be able to function in a stand-alone mode with minimal support from proprietary systems, even though the HyperCASE collection constitutes an integrated system. This design goal also maximises the opportunity for independent tool development.

3 HyperEDIT: The Presentation Manager

During the process of software development a number of documents are usually produced, i.e. requirement statements, data flow diagrams, entity-relationship diagrams, structure charts, state transition diagrams, Petri nets, flow charts or Nassi-Shneiderman diagrams, program source code, test cases, etc. All such documents can be constructed, edited or displayed with the aid of the HyperCASE authoring system, HyperEDIT. HyperEDIT's main responsibility is the presentation and manipulation of a document visual form, i.e. text and graphics (e.g. DFD's composition of a collection of circles, polygons, rectangles and arrows). Its other role is to assemble graphical and textual elements into hypertext buttons capable of trapping the mouse and keyboard events applied to them (e.g. dragging, clicking, or text entry). The representation of document contents in terms of design elements and their mutual relationships (e.g. interpretation of DFD components into processes, entities, data stores and flows) takes place in the HyperBASE knowledge base accessible from HyperEDIT via EventTALK communication protocol (Cf. Figure 4).

Figure 4 - Document processing

Authoring Tools. HyperCASE users are equipped with a number of standard text and diagram editors to support major software development methodologies. Each of the editors is simply an instantiation of the HyperEDIT graphic environment tailored to manipulate specific classes of objects having variety of attributes and behaviours. Such a customization may be performed by authorized users who would enter into a visual interaction with the HyperEDIT meta-editor aiming at describing new object types, their sub-component shapes, sizes, colours, fonts, and styles, they may also specify the object behaviours and the constraints governing them, finally they can define the appearance and the functions of the new editor.

The authoring process involved in a diagram or text construction consists in composing software documents of the editor-specific objects (e.g. DFD processes, stores and entities), linking them into object sets (e.g. with data flows or into domains), specifying their logical (e.g. names) and visual attributes (e.g. colour, size and position), etc. Authoring capabilities may have to be restricted for certain type of users, e.g. technical writers who would alter the documents visual attributes only without affecting their contents, or programmers confined to viewing existing software design documents with no capability to alter any of their aspects.

Software designers will rely on HyperEDIT browsing and navigational mechanisms, i.e.

Event Manager. Throughout the process of graphical interaction with the user, the HyperCASE system maintains all the necessary data describing the currently developed diagram structures. Their presentation records are kept in the HyperEDIT repository and their contents in the HyperBASE database (or in fact any other software supporting the protocol). Although the two manifestations of diagrammatical representation are quite distinct, certain aspects will necessarily overlap (e.g. a graphics field denoting an E-R entity name, and its actual name stored in the contents database), hence, leading to a fully distributed database with information replicated across the repositories of all currently opened HyperEDIT sessions and the central HyperBASE database. A special communication protocol, EventTALK, was devised to maintain the conceptual integrity and completeness of HyperEDIT multiple diagram images.

The main objective of EventTALK is to advise HyperBASE of all user-instigated changes to the document contents associated with the creation, deletion and editing of its components (e.g. creation or deletion of entities, relationships and attributes in E-R diagrams), so that HyperBASE could perform validation of user actions. After the HyperBASE data base update is completed (e.g. deletion of E-R entity), additional changes to the document may be triggered by the KBMS rules (e.g. deletion of all connected relationships and attributes), and the reverse flow of EventTALK commands will reflect the visual representation of the document. Changes to the document presentation which do not have any impact on the document contents (e.g. re-positioning or re-sizing of graphical objects) are not immediately communicated to HyperBASE.

EventTALK is also responsible for advising HyperBASE of all user actions which cannot be interpreted within the context of the currently displayed document. The class of such events includes browsing and navigation events (clicking on a diagram component, e.g. a DFD process), which require access to the HyperBASE database storing inter-document linking information and of course the details of documents which are destinations for such navigating actions (e.g. links leading from the selected DFD process to the set of its refinement diagrams).

EventTALK is also used to give HyperEDIT an object-oriented view of the HyperBASE database (even though a relational schema may be in use), it provides mechanisms for transaction roll-backs in the long transaction model which organises the "undo" facility but which also aids document versioning. The EvenTALK logs are also useful in the implementation of a software project tracking system to assist in project and configuration management.

Interface Manager. The core of HyperEDIT presentation layer consists of a number of text and graphic primitives. The primitives are of sufficiently high level to facilitate functional expression, ease of use, and flexibility in the creation of windows, dialogue boxes, menus, palettes, buttons, text and graphics, all to be mouse and keyboard controlled.

4 HyperBASE: BASE Tools

The ultimate aim of the HyperCASE system is to incorporate hypermedia principles into the software development process. To this end, HyperCASE provides the full functionality of a generic (i.e. software unspecific) hypertext system, including a number of document production and presentation tools (through HyperEDIT), a data dictionary based document repository (through HyperDICT), document indexing and navigation, document versioning, development planning and tracking, and automatic text analysis (all via HyperBASE, and its BASE Tools).

Document Manager. Software documents produced by HyperEDIT become an integral part of a HyperCASE hypertext system. Thus, their graphical and text attributes are analysed, indexed, aggregated and stored by the document manager in a HyperDICT data dictionary to enable the subsequent inter-document linking and navigation over program slices, refinement levels, or across semantic terms.

Configuration Manager. The configuration manager controls the current state of the knowledge base and determines semantic and temporal dependencies in the project structure. Configuration manager's role is to apply a number of heuristics to ensure that the necessary consistency exists between the system descriptions, their versions and the products they define.

With a few notable exceptions (e.g. Neptune1 and DIF4), the majority of commercial hypertext systems seriously neglect the need for elaborate version management. The simple revision models that may be applied to ordinary documents are quite inadequate for the complexity of maintaining software documentation, where consideration must be given to a number of additional constraints, e.g. compositional and referential dependencies (as through the make files), document generation (e.g. executable programs), document verification (e.g. via parsing and compilation), delivery sets (baselines), development distribution (collaborative development), private workspace and prototyping, etc. It is our belief that expanding the traditional hypertext model by the elements of software configuration management will have a positive impact on the hypertext mechanisms themselves, thus, leading to the provision of a comprehensive set of customizable revision-control hypertext tools in HyperCASE.

Project Tracker. Hypertext's ability to organize software into a complex structure of internal and external documentation opens new opportunities for the software development planning and the subsequent activity tracking. The project tracker provides a suite of project-management diagram editors in which a project manager defines the tasks, required resources, milestones, adopted standards and project deliverables. The relationships and dependencies recovered from such a project plan are then used to determine the structure of deliverable documentation. The project development stage may then be determined by tracking system activity, including tool usage, monitoring resources allocated to a given task, and by checking the status of individual documents and their components.

Design Tracker. A major reason for high maintenance effort in document systems is the absence of design tracking. In particular, completed software and engineering systems and their documentation usually omit design documentation. The design tracking system forces designers to document design decisions and reasons for modifying documentation. An integral part of the HyperCASE navigation system, the design tracker will allow maintainers and managers to follow the reasoning used to make implementation choices in either chronological or logical order.

Since the design tracker, project tracker and the configuration manager allow for precise recording of a developer's actual patterns of work, HyperCASE may be used as a software process research environment in which it will be possible to identify discrepancies between a developer's explicit design reasoning, and the development plan implied by tool usage.

Text Analyser. Having a sophisticated knowledge base of document components and their definitions may be enhanced with the use of a restricted form of natural language (such as English). Unconstrained user queries will give an alternative way to access software documents across navigational organisation of the HyperCASE database, although powerful, the database is highly structured and thus inflexible. Text analysis will also facilitate the recognition of references to re-usable concepts in requirement statements, provide mechanisms for automatic requirement classification, indexing and linking of text for the purpose of hyper-navigation, etc.

5 HyperBASE: CASE Tools

The range and variety of software documents kept in the HyperCASE repository calls upon the utilisation of tools for continuous monitoring of document consistency, integrity and completeness. Due to the nature of software development process, the assessment of a software project state and condition must take into consideration vast volumes of incomplete, and in some case incorrect, information; i.e. partial specifications, unfinished designs, error-ridden code, patchy documentation, out of date schedules and plans. In such cases, the use of heuristic rules and the sophisticated document representation becomes indispensable, to this end HyperBASE provides a necessary knowledge base framework.2,5,6

Re-use Manager. Throughout the evolution of a project life-cycle, each software entity is necessarily described from several different vantage points, e.g. relationships in ER diagrams may be defined as files or records in a data dictionary but used as data flows or stores in DFD diagrams, processes initially shown in HIPO charts could be refined with Decision Tables or State Transition Diagrams, used in DFD diagrams and finally laid down as Activity Charts or program code, etc. Having a uniform declarative representation for software document components will aid the description of modules and data, will facilitate the component multiple views, and finally will enable reasoning about the software and design re-usability, the fundamental aspect of the software process.

Integrity and Completeness Manager. It can be easily seen that handling multiple software descriptions necessitates analysis of document semantics, correlation of document contents, checking design integrity, and definitional completeness. Such tasks are usually laborious and difficult, frequently requiring the use of complex logic and heuristics. The integrity manager provides the inference framework for devising rules assuring software semantic integrity and completeness. It analyses the syntactic and semantic contents of documents produced over entire software life-cycle including the highest possible levels of the design process.

Design Animator. As the HyperCASE-based system development progresses, the animator monitors the sequence of systematic module and data structure refinements, resulting in a complete system of functional and structural mappings leading from the requirement specification, through the design of program logic, flow and control, data structure definition, to the source and binary program modules. Once the programs are compiled and linked, it is then possible to exercise the code via a standard Unix symbolic debugger and to visually trace the progress of program execution across all system diagrammatical descriptions.

Executable Diagrammatic Descriptions of Systems. The goal of this activity is to produce a diagraming system which has properties similar to those of the electronic circuit diagram produced using standard module families. These display parallelism, sequencing and are "executable" in the sense that no further logical or functional design is needed to implement them.

6 HyperDICT: The Data Dictionary

All of the HyperCASE documents can be considered to be stored in HyperDICT, a common data dictionary. Data dictionary updates are triggered by EventTALK transactions, channelled through the HyperBASE knowledge base, and finally translated into the statements of an embedded high-level query language primitives (e.g. E-SQL, Figure 3). This approach guarantees the invocation of the HyperBASE rules checking integrity constraints where necessary, thus, keeping the data base in logical consistency. Several types of data base operations do not alter the database contents, and may be performed freely without any fear of constraint violation, e.g. reporting, querying, backup or recovery.

7 Current Status

A number of early HyperCASE prototypes were developed on a variety of platforms to include Sun with Unix/X, Macintosh with HyperCard, Macs and IBM ATs in C and Prolog. Currently, HyperCASE development takes place on IBM AT 386 with Open Desktop, with HyperEDIT being implemented under X Window System using OSF/Motif toolkit, HyperBASE utilising Prolog, and HyperDICT designed as a Prolog data store in Ingress. The final system is expected to be implemented on Amdahl/UTS system.

8 Conclusions

The AAITP HyperCASE project is an attempt to integrate a collection of disparate applications, in this case a CASE tool set, under a more general information management and presentation paradigm, Hypertext. The authors argue that this constitutes a very high level of concept re-use, simplifying both the implementation of the CASE system and providing increased power to its users.

Our choice of tools has, in our view, been vindicated by exercises such as the Fourth International Workshop on Software Engineering at which users and implementors catalogued problems, current status and desirable features of CASE systems. Our proposed tools-set formed a reasonable sub-set of the attendees list of desired and missing features! The initial project goals have been to focus on those front-end issues which, in our view, while critically important, were not receiving significant attention from existing research teams. We have not, therefore, proposed the development of code-generators or support for specific methodologies.

We expect that the HyperCASE concept will significantly improve the effectiveness of maintenance activity as well as simplifying the task of coping with the large collections of documents that can be expected to be generated during software development. We also expect that the combination of natural language processing, design reasoning recording and project tracking capabilities will have a substantial impact on both economy of software development and maintenance due to the provision of powerful tools for design re-use and project control.

The project team anticipates a number of opportunities for future development, providing direct support for the software tools being marketed by both Amdahl and Prometheus. This will take the form of tailored diagraming and design capture capabilities, reflecting the needs of the individual development systems.

9 Acknowledgements

The authors wish to acknowledge the direct financial support of Amdahl Australia and of both La Trobe University and Prometheus Software Developments. Assistance has also been received from the Victorian State Government. The moral support and encouragement of Prof. Tharam S. Dillon and the members of the AAITP team (Kevin Alldritt, David Cleary, Mel Hatzis, Daniel Jitnah, Austin McClaughlin, Jane Philcox, Arhur Proestakis, Bev Teague and Chris Wignall ) are also gratefully acknowledged.


  1. Bigelow, J. Hypertext and CASE. IEEE Software (March 1988), pp. 23-27.
  2. Carando, P. Shadow Fusing Hypertext with AI. IEEE Expert 4, 4 (Winter 1989), pp. 65-78.
  3. Conklin, J. Hypertext: An Introduction and Survey. IEEE Computer (September 1987), pp. 17-40.
  4. Garg, P. Abstraction Mechanisms in Hypertext. Communications of the ACM 31, 7 (July 1988), pp. 862-870.
  5. Garg, P.K. and Scacchi, W. Ishys: Designing an Intelligent Software Hypertext System. IEEE Expert (Fall 1989), pp. 52-63.
  6. Puncello, P.P., Torrigiani, P., Pietri, F., Burlon, R., Cardile, B., and Conti, M. ASPIS : A Knowledge-Based CASE Environment. IEEE Software (March 1988), 58-65.
  7. Rock-Evans, R. CASE Analyst Workbenches: A Detailed Product Evaluation, Ovum Ltd., London, England (1989).
  8. Rock-Evans, R. and Engelien, B. Analysis Techniques for CASE: A Detailed Evaluation, Ovum Ltd., London, England (1989).
  9. Scacchi, W. The USC System Factory Project. Proc. Software Symposium '88, Software Engineers Association, Tokyo, Japan, ACM SEM (January 1989), pp. 9-41.