Browse Prior Art Database

Method for Automated Assembly of Software Versions

IP.com Disclosure Number: IPCOM000040293D
Original Publication Date: 1987-Oct-01
Included in the Prior Art Database: 2005-Feb-02
Document File: 3 page(s) / 38K

Publishing Venue

IBM

Related People

Rhyne, JR: AUTHOR

Abstract

A new version, or configuration, of a software system is automatically derived from a predecessor configuration as constituent modules of the predecessor are updated. The structure of a software system may be represented as a directed, acyclic graph with a single root node. The graph provides directions for the assembly of the system. Assembly begins at leaf nodes and proceeds toward the root node. An example of such a graph is shown in the accompanying figure. In the figure, a plurality of system modules are shown. The solid lines extending therebetween correspond to structural links which indicate the structural dependency of modules. In particular, the system module A(A) is derived from two text modules B(A) and C(A). Module B(A) is derived from a source code module D(A) and an interface module E(A).

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 55% of the total text.

Page 1 of 3

Method for Automated Assembly of Software Versions

A new version, or configuration, of a software system is automatically derived from a predecessor configuration as constituent modules of the predecessor are updated. The structure of a software system may be represented as a directed, acyclic graph with a single root node. The graph provides directions for the assembly of the system. Assembly begins at leaf nodes and proceeds toward the root node. An example of such a graph is shown in the accompanying figure. In the figure, a plurality of system modules are shown. The solid lines extending therebetween correspond to structural links which indicate the structural dependency of modules. In particular, the system module A(A) is derived from two text modules B(A) and C(A). Module B(A) is derived from a source code module D(A) and an interface module E(A). Module C(A) is derived from modules E(A) and F(A). If a module is altered, the modules dependent thereon are automatically changed to account for the updating. This is illustrated in the figure where a change in the interface module E(A) is depicted and represented (and renamed) as module E(A'). Because module E(A) was used in generating modules B(A) and C(A) which, in turn, were used in deriving system module A(A), these modules are automatically replaced by updated (renamed) modules B(A'), C(A'), and A(A'), respectively. The replacement aspect is suggested by the dashed line representation. The figure thereby depicts the result on the system of modifying module E(A). To aid in determining when a new version of a module must be created, each module is tagged with the module id of the root node in the graph in which the module was originally created. For example, B(A) indicates that module B was originally created in the system whose root node is A. A general procedure for creating a new version of a module is set forth below in two phases: 1. An upward scan is made in the system structure graph of all nodes

dependent on the affected node, and a work list is

created consisting of nodes whose tags are not the same

as the identifier of the system structure graph. This

list must be ordered by the maximum distance of the

nodes from the affected node for the next phase to work

properly. The affected node must be the first node on

this list, as its distance is zero. The nodes on this

list will have been inherited from a predecessor system

version, and will be affected either directly by the

modification, or indirectly by being constructed

differently (having different dependents). New nodes

must be created in the current system version graph for

each node on the...