Browse Prior Art Database

Logically Deleted Parts

IP.com Disclosure Number: IPCOM000035971D
Original Publication Date: 1989-Aug-01
Included in the Prior Art Database: 2005-Jan-28
Document File: 7 page(s) / 84K

Publishing Venue

IBM

Related People

Chance, RM: AUTHOR [+7]

Abstract

The cost of software maintenance is rising, and the volume of maintenance necessary can often prevent new applications from being written. These facts increase the value of full-featured library control systems. Such systems can help reduce the cost of maintaining and enhancing software systems.

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 27% of the total text.

Page 1 of 7

Logically Deleted Parts

The cost of software maintenance is rising, and the volume of maintenance necessary can often prevent new applications from being written. These facts increase the value of full-featured library control systems. Such systems can help reduce the cost of maintaining and enhancing software systems.

Parts are any file that make up a piece of a total software package. This can include source code, macros, includes, documentation, and test cases.

The concept of deleted parts involves retention of data on parts that previously existed in the library control system. Library blocking allows "viewability" of parts in a library system to be controlled on a part-by-part basis. These features are the subject of this article.

(Image Omitted)

A library system is a repository for related groups of common code. These code groups are divided into categories. A library system should have the following categories: Product--All parts belonging to a particular

programming project.

Version--Any parts belonging to a specific release

within a particular programming project. Several

releases of a product may exist in product development

library system at one time; each release is called a

version.

Level--Within a version, there are several stages

through which a part must pass. Parts may be under

development, being tested, or ready for shipment. Each

stage is called a level; each library system may have

different levels. A common set of the following is

usually needed:

User level: A private repository where the

developer's code may reside. No one other than the

developer has access to his/ her own user level.

Collector level: Developer's public copy of code

resides here.

Capture level: Developer's tested copy of code

which is ready for integration.

Integration level: Copy of the code controlled by

authorized personnel.

(Image Omitted)

The level structure within a version is shown in Fig. 1.

Note that the user and collector levels represent the developer's domain where code may be changed, processed, tested, deleted, and captured. All levels above the collector level are the domain of specially authorized personnel

1

Page 2 of 7

for performing integration, driver builds, and mass recompilations. A part can exist at more than one level within a version.

Versions within a product are usually related to each other. Parts developed for the first release of a product are contained in a "base" version. Follow-on releases of the product are developed in "delta" versions. Delta versions contain new and changed parts.

In the example shown in Fig. 2, REL1 is the base version. REL2 and REL3 are follow-on or delta versions. When Release 3 of the product is built, parts can be pulled from REL3, REL2, and REL1 (usually in that order). To do this, product-building processes (compilers, for example) rely on search paths defined by an administrator.

A search path is a list of library levels that link versions together. Processes and commands that use...