CS302: Software Engineering (2021.B.01)

The most common code management procedure is the creation of derivations. The two code management types are for versions and variations. They can all be supported in the same software library or can be in separate libraries. Each type serves a different purpose.

Derivation 

A derivation is a list that identifies the specific versions of multiple modules that were linked to create a load module or joint memory resident work unit. The purpose of a derivation is to allow tracing of errors that might be due to vendor software. All software used to create a load unit are specifically identified with vendor, version, and last installation date. The sample shown in Figure 18-13 identifies specific platform, operating system, compiler, for creation of a work unit, and the dates of the creation of each stage. If a problem were found, for example, a rounding error occurs in computing interest, the error is traced backward through the development software to find the problem. The program is checked first, then the compiler, then the operating system, and so on. Let's say, for instance, that a new version of the compiler was installed one week before this module's creation, and that, upon inspection, the rounding algorithm used only allowed four decimal places to real numbers. If more than four places are needed, a new compiler would be required.

The difference between a load module and joint memory resident work unit is in the dynamism of the processes. A load module is a compiled version of one or more source code modules that have been compiled and link-edited together, forming the load module. Compilation translates a module from source code to object (assembler) code. Linkage editing resolves references to other modules by replacing Call references with relative memory addresses, thus joining related modules for processing as a single work unit (see Figure 18-14). 

A joint memory resident work unit is a series of load modules that work together in a dynamic, real-time environment. Linkage editing creates static modules that are fixed until the next linkage edit process. In real-time application environments, one goal of the procedures is to relieve the need to freeze specific module references until they are needed in operation. This liberates programmers from the linkage editing process but can create chaos when an error occurs and must be traced. Both situations require maintenance of derivations. 

Recording of derivations requires precise identification of the software, option, code inputs, responsible person, and date that a load module was created (see Figure 18-15). The level of detail for derivations should match each process a module undergoes from source code to load unit. This means that if the translation is from source code to load unit, there are two derivations. If the translations are from source to object to load unit, there are three derivations. All software used in creating the derivation is recorded, including the compiler, linkage-editor, and so on, and their versions. Derivation maintenance provides an audit trail for software and is the only way that errors can be guaranteed to be traceable.

FIGURE 18-13 Sample Derivation

Delta Version 

Delta means difference. A delta file is a file of differences between versions of a program. Versions are multiple copies of a single program that represent incremental changes.

When a delta version is kept, the main program logic is maintained once. Then, the delta version is applied to the main logic, with specific lines of code being replaced to derive the delta (see Figure 18-16). The advantage of using a delta strategy is that changes in functionality affect only the original code. The disadvantages are that loss or corruption of the original also affects all deltas, and that delta references based on code line numbers can lead to errors when the original changes.

FIGURE 18-14 Compile and Link Edit

Many software librarians and operating system editors work on the delta version principle. For instance, the Unix editor maintains delta versions of changes to text files, which includes program code. Using line numbers as the reference point, the original is stored. As changes are made, changed lines are kept plus new line numbers are appended in a delta file. When the file is referenced, the original is loaded into memory, then the deltas are applied until the memory version reflects all changes. 

When using a delta version, then, it is important to create a new file periodically to save storage and processing time for delta overlays. This minimizes the extent to which you are making changes to changes. To create the new file, you save the old file with a new name. Renaming modules is necessary to create a permanent version of the program with deltas incorporated into the saved version. Maintaining many renamed versions can cause errors in remembering the most current version, too.

Variation Storage 

Variations are alternative, interchangeable program modules created for multiple environments or purposes. For instance, you might create an IBM PS/2 version of a program and a Novell Netware 386 version of a program. The functionality is the same, but specific modules are different to support the specific hardware/software platform. 

Variations in a COBOL environment, for instance, might have a different interface for users in the United States and users in South America. Variations in an Ada environment, as another example, might be for performing the same process using integers or using real numbers.

FIGURE 18-15 List of Requirements for Recording Derivations

Variations are named rather than numbered because there is no meaningful relationship between variations (see Figure 18-17). The name of each variation should reflect what makes it different. For instance, the names PS2S0RT (for PS/2 sort routine) and N386S0RT (for Netware 386 sort routine), would be good variation names because they identify both the platform and the function of the variation.