Browse Prior Art Database

Program Design Validation System

IP.com Disclosure Number: IPCOM000087751D
Original Publication Date: 1977-Mar-01
Included in the Prior Art Database: 2005-Mar-03
Document File: 2 page(s) / 14K

Publishing Venue

IBM

Related People

Meyers, GJ: AUTHOR

Abstract

A program design validation system is described which provides a software designer with an automated vehicle to detect certain categories of design errors before his program is coded. In general, the later that errors are detected in a software development project, the higher the cost of correcting the error and the higher the probability of doing it incorrectly.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 2

Program Design Validation System

A program design validation system is described which provides a software designer with an automated vehicle to detect certain categories of design errors before his program is coded. In general, the later that errors are detected in a software development project, the higher the cost of correcting the error and the higher the probability of doing it incorrectly.

The system first prompts the designer to enter a description of his program, and this information is stored in a data base. The designer describes each module interface. An interface description consists of the names of the calling and called modules, the input arguments, the output arguments, and the degree of coupling between the two modules. (See G. J. Myers, Reliable Software Through Composite Design, New York: Petrocelli/Charter, 1975 for a definition of module coupling.) The arguments may be described in abstract terms. For instance, the user might define the inputs for a particular module as "region code, list of customer names."

Once this data base is constructed, the designer can request the system to validate the design. The four types of validation performed are: 1. It searches the data base for modules that have no calling modules and prints a list of any encountered. 2. It searches the data base for modules that have more than one calling module. When such a module is encountered, the system checks the module's interfaces for consistency. That is, it determines if each interface to the module has the same number of input arguments and the same number of output arguments. Any inconsistencies are reported to the user. 3. For modules with multiple calling modules, the system checks their couplings for consistency. For instance, if modules A and B call module C, but A and C have one type of coupling and B and C have a different type of coupling, the discrepancy is reported to the user. 4. The system attempts to locate incomplete interfaces. It does this by examining each module and its surrounding interfaces. A list of the module's total input space is formed from the input arguments from its calling modules and the output arguments returned from the modules it calls. A list of the module's total output space is formed from the output arguments returned to its calling modules and the input arguments passed to the modules it calls. The system then attempts to determine if each data item leaving the module (each item in the total output space) can be derived from the data entering the module (data in the total input space). For instance, if an output space item is "region co...