The code for every artifact exists in three forms. First is the source code, nowadays gener-ally implemented in a high-level language like C++ or Java. Next comes the object code, produced by compiling the source code. In this book, because of possible confusion of the word object , we refer to object code as compiled code . Finally, the compiled code for each artifact is combined with run-time routines to produce an executable load image. This is shown in Figure 5.12 . The programmer can use various different versions of each artifact.
The specifi c version of each artifact from which a given version of the complete product is built is called the confi guration of that version of the product.
Suppose that a programmer is given a test report from the SQA group stating that an artifact failed on a specifi c set of test data. One of the fi rst things to do is attempt to re-create the failure. But how can the programmer determine which revisions of which variations went into the version of the product that crashed? Unless a confi guration-control tool (described in the following discussion) is used, the only way to pinpoint the cause of the failure is to look at the executable load image, in octal or hexadecimal format, and com-pare it to the compiled code, also in octal or hexadecimal. Specifi cally, the various versions of the source code have to be compiled and compared to the compiled code that went into the executable load image. Although this can be done, it can take a long time, particularly if the product has dozens (if not hundreds) of code artifacts, each with multiple versions.
Therefore, two problems must be solved when dealing with multiple versions. First, we must distinguish between versions so that the correct version of each code artifact is com-piled and linked to the product. Second, there is the inverse problem: Given an executable load image, determine which version of each of its components went into it.
The fi rst item needed to solve this problem is a version-control tool. Many operating sys-tems, particularly for mainframe computers, support version control. But many do not, in
FIGURE 5.12 Components of an executable load image.
Executable load image
Compiled file 1
Compiled file 2
Compiled file 3
Compiled file n
Source file 1
Source file 2
Source file 3 Run-time
routines
Source file n
…
…
144 Part A Software Engineering Concepts
which case a separate version-control tool is needed. A common technique used in version control is for the name of each fi le to consist of two pieces, the fi le name itself and the revi-sion number. For example, an artifact that acknowledges receipt of a message has revirevi-sions acknowledgeMessage/1, acknowledgeMessage/2, and so on, as depicted in Figure 5.13 (a).
A programmer then can specify exactly which revision is needed for a given task.
With regard to multiple variations (slightly changed versions that fulfi ll the same role in different situations), one useful notation is to have a basic fi le name, followed by a variation name in parentheses [Babich, 1986]. Accordingly, two printer drivers are given the names printerDriver (inkJet) and printerDriver (laser).
Of course, there will be multiple revisions of each variation, such as printerDriver (laser)/12, printerDriver (laser)/13, and printerDriver (laser)/14. This is depicted in Figure 5.13 (b).
A version-control tool is the fi rst step toward being able to manage multiple versions.
Once it is in place, a detailed record (or derivation ) of every version of the product must be kept. The derivation contains the name of each source code element, including the varia-tion and revision, the versions of the various compilers and linkers used, the name of the person who constructed the product, and of course, the date and the time at which it was constructed.
Version control is a great help in managing multiple versions of artifacts and the product as a whole. But more than just version control is needed, because of additional problems associated with maintaining multiple variations.
Consider the two variations printerDriver (inkJet) and printerDriver (laser). Suppose that a fault is found in printerDriver (inkJet) and suppose that the fault occurs in a part of the artifact common to both variations. Then it is necessary to fi x not only printerDriver (inkJet) but also printerDriver (laser). In general, if there are v variations of an artifact, all v of them have to be fi xed. Not only that, they have to be fi xed in exactly the same way.
FIGURE 5.13 Multiple revisions and variations. (a) Four revisions of artifact acknowledgeMessage. (b) Two variations of artifact printerDriver, with three revisions of variation printerDriver (laser).
(a) acknowledgeMessageⲐ2
acknowledgeMessageⲐ3 acknowledgeMessageⲐ1
acknowledgeMessageⲐ4
(b) printerDriver (laser)/12
printerDriver (laser)/13 printerDriver (laser)/14 printerDriver (inkJet)
sch76183_ch05_124-153.indd 144
sch76183_ch05_124-153.indd 144 04/06/10 6:42 PM04/06/10 6:42 PM
One solution to this problem is to store just one variation, say, printerDriver (inkJet).
Then any other variation is stored in terms of the list of changes that have to be made to go from the original to that variation. The list of differences is termed a delta. What is stored is one variation and v – 1 deltas. Variation printerDriver (laser) is retrieved by accessing printerDriver (inkJet) and applying the delta. A change made just to printerDriver (laser) is implemented by changing the appropriate delta. However, any change made to printer-Driver (inkJet), the original variation, automatically applies to all the other variations.
A confi guration-control tool can automatically manage multiple variations. But
confi guration control goes beyond multiple variations. A confi guration-control tool can also handle problems caused by development and maintenance by teams, as described in Section 5.10.1.
5.10.1 Confi guration Control during Postdelivery Maintenance
All sorts of diffi culties can arise when more than one programmer simultaneously main-tains a product. For example, suppose each of two programmers is assigned a different fault report on a Monday morning. By coincidence, both localize the fault they are to fi x to different parts of the same artifact mDual. Each programmer makes a copy of the current version of the artifact, mDual/16, and they start to work on the faults. The fi rst program-mer fi xes the fi rst fault, has the changes approved, and replaces the artifact, now called mDual/17. A day later the second programmer fi xes the second fault, has the changes approved, and installs artifact mDual/18. Unfortunately, revision 17 contains the changes of only the fi rst programmer, whereas revision 18 contains those of only the second pro-grammer. None of the changes of the fi rst programmer are in mDual/18, because the second programmer made changes to mDual/16, instead of to mDual/17.
Although the idea of each programmer making individual copies of an artifact is far better than both working together on the same piece of software, clearly it is inadequate for maintenance by a team. What is needed is some mechanism that allows only one user at a time to change an artifact.
5.10.2 Baselines
The maintenance manager must set up a baseline , a confi guration (set of versions) of all the artifacts in the product. When trying to fi nd a fault, a maintenance programmer puts copies of any needed artifacts into his or her private workspace . In this private work-space, the programmer can change anything at all without having an impact on any other programmer in any way, because all changes are made to the programmer’s private copy;
the baseline version is left untouched.
Once it has been decided which artifact has to be changed to fi x the fault, the program-mer freezes the current version of the artifact he or she is going to alter. No other pro-grammer may make changes to any frozen version. After the maintenance propro-grammer has made changes and they have been tested, the new version of the artifact is installed, thereby modifying the baseline. The previous version, now frozen, is retained because it may be needed in the future, as explained previously, but it cannot be altered. Once a new version has been installed, any other maintenance programmer can freeze the new version and make changes to it. The resulting artifact, in turn, becomes the next baseline version. A similar procedure is followed if two or more artifacts have to be changed simultaneously.
146 Part A Software Engineering Concepts
This scheme solves the problem with artifact mDual. Both programmers make private copies of mDual/16 and use those copies to analyze the respective faults that they have been assigned to fi x. The fi rst programmer decides what changes to make, freezes mDual/16 and makes those changes to repair the fi rst fault. After the changes have been tested, the resulting revision, mDual/17, becomes the baseline version. In the meantime, the second programmer has found the second fault by experimenting with a private copy of mDual/16.
However, changes cannot now be made to mDual/16 because it was frozen by the fi rst programmer. Once mDual/17 becomes the baseline, it is frozen by the second programmer whose changes are made to mDual/17. The resulting artifact now is installed as mDual/18, a version that incorporates the changes of both programmers. Revisions mDual/16 and mDual/17 are retained for possible future reference, but they can never be altered.
5.10.3 Confi guration Control during Development
While an artifact is in the process of being coded, versions are changing too rapidly for con-fi guration control to be helpful. Once coding of the artifact has been completed, it should immediately be tested informally by its programmer, as described in Section 6.6. During this informal testing, the artifact again passes through numerous versions. When the pro-grammer is satisfi ed, the artifact is handed over to the SQA group for methodical testing.
As soon as the artifact has been passed by the SQA group, it is ready to be integrated into the product. From then on, it should be subject to the same confi guration-control proce-dures as those of postdelivery maintenance. Any change to an integrated artifact can have an impact on the product as a whole in the same way as a change made during postdeliv-ery maintenance. Therefore, confi guration control is needed not only during postdelivpostdeliv-ery maintenance but also during implementation. Furthermore, management cannot monitor the development process adequately unless every artifact is subject to confi guration control as soon as is reasonable, that is, after it has been passed by the SQA group. When confi gu-ration control is properly applied, management is aware of the status of every artifact and can take early corrective action if project deadlines seem to be slipping.
Two major UNIX version-control tools are sccs (source code control system) [Rochkind, 1975] and rcs (revision control system) [Tichy, 1985]. PVCS is a popular, commercially available confi guration-control tool. Microsoft SourceSafe is a confi guration-control tool for personal computers. CVS (concurrent versions system) [Loukides and Oram, 1997]
and Subversion are open-source confi guration management tools (open-source software is described in Section 1.11).