Assuring the correctness of configured software descriptions

In previous work, we described the design and implementation of a software hypertext environment for managing configured software descriptions [5]. That environment served as a basis for providing a facility for creating, managing, and revising the descriptions (ie, documentation) associated with the engineering of a software system’s life cycle. It described the structures we employed for organizing, linking, and visualizing software life cycle documents as configured descriptions. It further described how this visualization mechanism utilizes a module interconnection language (NuMIL) based description of a large program in order to graphically depict (sub)system configuration structures, as well as to graphically or logically browse relations between the configuration and its source code. This paper describes a new set of concepts and mechanisms which add a more rigorous, correctness-preserving foundation to the automated management of configured software life cycle descriptions. Specifically, there are two principal concepts embodied in this work, and an associated environment which supports their operationalization as well. The first involves the generalization, extension, and application of module interconnection language concepts to all software life cycle descriptions, not just to source code as used previously. This involves development of a formalism that views all objects created during a software system’s life cycle (e.g., individual requirements, design diagrams, test plans) as having an “interface” through which information resources are provided or required. Resource type and configuration relations are then associated with the interfaces, which in turn must be compatible for two or more software objects to be interconnected. As such, software life cycle objects can be composed or interconnected into life cycle stage descriptions (e.g., Requirements Analysis, Design, Testing). Further, descriptions associated with successive software life cycle descriptions, as defined by the user (e.g., design, implementation, testing), are also main-