CONTENTS |
Whether you will be programming for yourself or for a large project, being familiar with the development processes and tools will be helpful.
Writing a program is only part of the story. Software quality and integrity needs to be addresses. Developing and working within a development life cycle will help uncover software errors and help ensure a better product.
Programmers use source code software tools to help address and keep track of various upgrades and corrections made to the software. These tools are also helpful when working on a large project with multiple programmers. They will prevent loss of changes and overwrites.
This chapter will address the various development life cycles and will cover a source code control tool, typically found on UNIX systems, called SCCS.
Understanding the development life cycle becomes a necessity when programming for a larger project with multiple developers. Using a development life cycle will allow programmers, software testers and project managers to work in harmony. Certain software expectations are set for each part of the life cycle, allowing syntax or logical errors to be uncovered and rolled back for correction.
Software projects are broken into three basic phases: Analysis phase, Development phase, and Test phase. These three phases are described in the upcoming three sections.
A program or application has a community of users. Changes in business needs or interests require either the creation of new programs or enhancements of existing ones. These requests are given to the development community. Writers and architects work to interpret the requests into a comprehensive statement of work, outlining changes needed to the application.
Designers model these changes, creating or enhancing design documents.
Programmers make changes to, or create new source code to meet the requirements outlined in the design documents.
A programmer will create or edit a source file with an editor. The source file contains source code, which is readable text instructions or commands written in a programming language.
After the source code is complete, the developer compiles the program. A compiler will check for syntax errors. Syntax errors occur if the programmer has not followed the programming language's rules (syntax) for entering text instructions. If any syntax errors occur, they must be corrected in the source code and recompiled. This process continues until a compile completes successfully and an executable is created.
Next, a programmer begins the Test phase. Unit test occurs first, allowing the programmer to test the new or enhanced programming logic. The program is executed and the output is checked to ensure that it meets the requirements outlined in the design phase.
After the programmer is satisfied, the source code is sent to integration test. This allows the programmer to integrate and test her source code with other programmers' source code. This is a particularly important phase when more than one programmer is working on the same program.
If the integration test phase is completed successfully, the source code is moved into system test. Most programming projects have either staff testers or a testing organization with the responsibility for test the whole application against the user and design requirements. If at any stage logical errors are found, they are brought to the attention of the programmer. If the errors are due to a design flaw, the process reverts to the design phase. After the fix has occurred, the cycle begins again, moving forward from that point.
The final test phase is called acceptance test. The program is tested either in the production environment or on a separate computer system emulating the production environment.
After acceptance test, the program is moved into the production environment and is available to its user community.
Different programming organizations may have a variation of this process, using different terminology, inserting more steps, or consolidating others. Regardless, organizations will feel the impact of errors in logic or design. Because an error causes a roll back to a previous process or phase, and every step after it must be repeated, there is a cost associated with it.
Errors found during the Development phase are much more expensive in both time and cost than errors found during the Analysis phase. And likewise, errors discovered late in the Test phase are very expensive. Errors found in production are the most expensive to repair.
It is important that the analysis and design of a problem is performed with due diligence. Assuming that ambiguities or design adjustments will be ironed out later in the process is not good practice. Every issue dealt with early in the development cycle will save an enormous amount of effort, cost, and time in the end.
Most programs consist of more than one file, frequently many files. Source code for a single program can be in multiple source files. The source code in these files evolve over the life of the program. It is very hard to keep track of the different versions of each file. Source and documentation files change frequently as errors are fixed, programs are enhanced, and new versions of the software are released to production. Frequently, customers are using one version while programmers are working on a new version. It is easy to lose track of the versions and accidentally lose changes that were already made.
Source files usually reside in a directory and are accessible to developers. Consider the following scenario:
Developer A needs to make a change to a source file. Developer A makes a copy of the source file from the public directory where the source files are stored. The source file is copied to Developer A's home directory. Developer A begins to make changes to the source code in the file.
Meantime, Developer B also needs to make a change to the same source file. Developer B also makes a copy from the public directory and puts the source file in his home directory. Developer B has no idea that Developer A has a copy of this file and is currently making her own changes. Developer B begins to make changes.
Developer A has now completed changes made to the source code in the source file. Developer A compiles the source code successfully and performs a unit test of the code. Developer A returns the source file to the public directory where the source files are stored. Developer A performs an integration test, which is successful.
Developer B has now completed his changes. Developer B compiles and unit tests his changes. Developer B copies the source file back to the public directory and overwrites Developer A's changes. Both Developer B and Developer A have no idea this has happened. Developer B performs integration test.
The software is moved to system test. An external organization begins testing, and notices that Developer A's changes are not there. Developer A is notified and now must redo her work.
How was this scenario avoidable? To help with these problems, UNIX provides utilities for managing and tracking changes to files called SCCS.
SCCS enables organizations and individuals to have some control over their files. SCCS can control who is allowed to update the files, thus preventing overwrites. For each update to a file, it records who made the changes and saves notes or comments regarding the reason for the changes. Because SCCS stores the original version of the file as well as any changes made to it, it is possible to regenerate previous versions of a file. SCCS will save only the changes, not a whole copy of the new version. This approach helps keep the size of an SCCS file under control. A history of changes made to files can also be requested. The history output of a file SCCS will list the version, date, time, author, and comments.
SCCS allows developers to generate a read-only copy of a version of a file. SCCS also allows a file to be "taken out for edit." This phrase means that the copy given is intended for edit, and any subsequent requests for an editable copy will be denied until the original is "returned." In other words, SCCS locks a file that is out for edit, to prevent overwrites.
When an SCCS file is taken out for edit and returned, a change is recorded. The change is referred to as a delta. Changes to the software are referred to as revisions to the software.
Each delta has an associated version number consisting of either two or four components. The first two, which are always used, are the release and level numbers. When an SCCS file is initially created, the default release number and level number are 1, which corresponds to Version 1.1 or Delta 1.1. When subsequent revisions occur, SCCS automatically assigns subsequent numbers - 1.2, 1.3, and so on. The user does have control over the version numbers and can skip level numbers or change the release number. Normally, release numbers only change when there is a major revision to the software occurs, i.e., Version 1 to Version 2.
File versions follow a sequential pattern, where each delta or revision includes all previous deltas or revisions. The last box in Figure 20-1 illustrates a change to the release number to reflect a major software revision.
However, there are cases when an intermediate version is necessary. For example, version 2.1 of the software is under development. The previous version, 1.3, is currently in production. A feature in the production version 1.3 has an error in it and an emergency fix is needed. The development version 2.1 is not ready for production; therefore, an intermediate version of the production file becomes necessary. A branch delta is created, as shown in Figure 20-2.
Any revisions made in the branch starting with version 1.3.1.1 will not be included in version 2.1 and beyond. All revisions made to the branched versions of the file will not impact the primary version flow. If the error is part of version 2.1, the fix will need to be manually entered into a new version, 2.2.
SCCS provides a number of commands to allow a user to manage software versions. All SCCS files begin with "s." followed by the name of the file to be tracked in SCCS. When an SCCS file is initially created, the "s." file is created. This file will contain all the software changes, comments, dates, times, IDs of the developers making the change, and revision information.
The admin command is one of the most important SCCS utilities. It is used to create SCCS files, control the availability of revisions to the software, and change the requirements for submitting a revision.
All SCCS files must be initialized using the admin command before any other action can be performed. These files can be initialized as empty files or with the contents of a file.
To create an SCCS file with an empty initial revision, the following command is used:
$ admin -n s.payroll.txt
where "s." is the SCCS file prefix and payroll.txt is the file to be tracked with SCCS.
To create an SCCS file with initial contents from another file, use:
$ admin -i payroll.txt s.payroll.txt
where the SCCS file, s.payroll.txt, will be initialized with the contents of payroll.txt.
A simpler method of creating SCCS files is:
$ sccs create payroll.txt
The file s.payroll.txt will automatically be created in the directory where this command is run.
The get command will allow a copy to be generated from an existing SCCS file. Any version can be retrieved either by version number or by date.
Without any options, SCCS will generate a copy of the latest version of the file with read-only permissions, because it assumes that you will not be making any changes and creating a new revision.
$ get s.payroll.txt 1.1 4 lines No id keywords
This command prompted the generation of three lines. The first line, 1.1 is the current revision number of the software, the second line is the number of lines in the file, and the third states how many keywords were expanded. The read-only file can be found in the directory where this command was executed.
If a user wishes to make changes to the file and create a new revision of the software, the following command can be used:
$ get -e s.payroll.txt 1.1 new delta 1.2 4 lines
The first line is the current revision number, the second is the new revision number, and the third line is the number of lines in the file. The -e option indicates that the most recent revision of the file payroll.txt is out for editing. The get command generates a writable copy and creates a lock file called p.payroll.txt. This lock prevents other users from retrieving the same version of the file for editing until this file is checked back in using the delta or unget commands. Read-only copies can still be generated.
The -e option allows for different versions of the same file to be out for edit at the same time. Both of these versions cannot be on the same revision path. For example, if a revision is out for edit from the primary revision path, any other revisions taken out for edit at the same time can only be from branches.
The default revision of the file generated by the get command is the most recent revision. Using the -p and -c options allow other revisions of the files to be generated. Both options can be combined with the -e option.
SCCS also allows the retrieval of the highest revision within a version of the software with the -r option:
$ get -r2 s.payroll.txt 2.3 4 lines No id keywords
In this example, revision 2.3 was the highest revision number within version 2 of the software.
To retrieve a revision by date, use the -c option:
$ get -c991129 s.payroll.txt 1.1 4 lines No id keywords
The date is specified in the following format; time is optional:
YY[MM[DD[HH[MM[SS]]]]]
The sccs command simplifies the functionality of the get command.
To retrieve a read-only copy of the latest revision:
$ sccs get payroll.txt
To retrieve a read-only copy of revision 1.4:
$ sccs get -r1.4 payroll.txt
To retrieve the most recent revision of payroll.txt for edit:
$ sccs edit payroll.txt
The sccs command accepts all the get flags. It also accepts the file name, the user does not have to specify the SCCS file with the "s." prefix. The sccs command performs the translation.
This command cancels the get -e or edit command, preventing a new delta from being created and deleting any lock associated with the file.
The delta command is used to submit files that have been edited and need to return to SCCS as a new revision. This is also called creating a deltaor submitting a file.
To submit a file, use the following command:
$ delta s.payroll.txt comments? Add fifth line No id keywords (cm7) 1.5 1 inserted 0 deleted 3 unchanged
The delta command prompts the user for comments. Once entered, the delta command lists the new revision number, how many lines were inserted, how many were deleted, and how many lines experienced no change at all.
Delta removes the writable version of the file by default. If the -n flag is used, the writable version remains. If more than one revision is out for edit, use the -r flag to specify with which revision path the file should be associated.
The sccs command can be used with delta much the same as it is used with edit.
The following is the HP-UX manual page for sccs used in this chapter. Commands often differ among UNIX variants, so you may find differences in the options or other areas for some commands; however, the following manual pages serve as an excellent reference.
sccs - Source code control system.
sccs(1) sccs(1) NAME sccs - front-end utility program for SCCS commands SYNOPSIS sccs [-r] [-d rootpath] [-p dirpath] command [options] [file ...] DESCRIPTION The sccs command is a straightforward front end to the various programs comprising the Source Code Control System. It includes the capability of running set-user-id to another user to allow shared access to the SCCS files. sccs reduces the need to explicitly reference the SCCS filenames. The SCCS filenames are generated by prepending the string SCCS/s. to the working files specified. The default SCCS subdirectory name can be overridden with the -p dirpath option. The command supplied to the sccs command can either be an SCCS program or a pseudo command. The SCCS programs that sscs handles include admin, cdc, comb, delta, get, help, prs, rmdel, sact, unget, val, what and sccsdiff. The pseudo commands are: check Prints a list of all files being edited. Returns a non-zero exit status if a file is being edited. The intent is to allow an 'install' entry in a makefile to verify that everything is included in the SCCS file before a version is installed. See the info pseudo command for a description of the -b, -u user and -U options. clean Removes all files from the current directory or the named directory that can be recreated from the SCCS files. Does not remove files that are in the process of being edited. If -b is given, branches (i.e. SID's with three or more components) are ignored in determining which files are being edited. Therefore, any edits on branches can be lost. create Creates the initial SCCS file, taking the contents from file. Any options to admin are accepted. If the files are created successfully, the original files are renamed with a , (comma) on the front. Read-only copies are retrieved with get. The renamed files should be removed after you have verified that the SCCS files have been created successfully. delget Runs delta on the named files and then get the new versions. The new versions of the files have expanded identification keywords, and cannot be edited. The [-mprsy] options are passed to delta, and the [-bceiklsx] options are passed to get. deledit Equivalent to delget, except that the get phase includes the -e option. diffs Gives a diff listing between the current version of the files being edited and the versions in SCCS format. The [-rcixt] options are passed to get. The [-lsefhb] options are passed to diff. The -C option is passed to diff as -c. edit Equivalent to get -e. enter Equivalent to create, except get is omitted. This pseudo command is useful when you want to run the edit command immediately after creating the SCCS file. fix Removes a named delta, but leaves a copy of the delta in the current directory. The -r SID option is required and must point to a leaf in the source tree. Since a record of the changes is not preserved, fix should be used carefully. info Lists all the files being edited. The -b option ignores branches in determining which files are being edited. The -u user option lists only the files being edited by user. The -U option is equivalent to -u current_user. print Prints information about named files. Equivalent to prs -a followed by get -p -m -s. tell Lists all the files being edited, with a newline after each entry. See the info section for a description of the -b, -u user and -U options. unedit Equivalent to unget. Any changes made since the last get are lost. Use with caution. Certain commands, admin, cdc, check, clean, diffs, info, rmdel, sccsdiff, and tell cannot use the set-user-id feature, as this would allow anyone to change the authorizations. These commands are always run as the real user. Options The options supplied to the SCCS commands are documented in the corresponding SCCS man pages. The options supplied to the pseudo commands are documented in the above section. All other options preceding command are documented as follows: -r Runs sccs as the real user rather than the effective user sccs is set-user-id to. -d rootpath Gives the pathname to be used as the root directory for the SCCS files. rootpath defaults to the current directory. This flag takes precedence over the PROJECTDIR environment variable. -p dirpath Specifies the pathname for the SCCS files. The default is the SCCS directory. dirpath is appended to rootpath and is inserted before the final component of the pathname. The command sccs -d /usr -p cmd get src/b converts to get /usr/src/cmd/s.b. This can be used to create aliases. For example, the command alias syssccs="sccs -p /usr/src/cmd" makes syssccs an alias that can be used in commands like syssccs get b. EXTERNAL INFLUENCES Environment Variables If the PROJECTDIR environment variable is set, its value is used to determine the -d rootpath option value for rootpath. If PROJECTDIR begins with a / (slash), the value is used directly; otherwise, the value is assume to be a login name and the home directory corresponding to login name is examined for a subdirectory named src or source. If found, this directory path is used. Otherwise, the value is used as a relative path name. LC_CTYPE determines the interpretation of text within file as single- and/or multi-byte characters. LC_MESSAGES determines the language in which messages are displayed. If LC_CTYPE or LC_MESSAGES is not specified in the environment or is set to the empty string, the value of LANG is used as a default for each unspecified or empty variable. If LANG is not specified or is set to the empty string, a default of "C" (see lang(5)) is used instead of LANG. If any internationalization variable contains an invalid setting, sccs behaves as if all internationalization variables are set to "C". See environ(5). International Code Set Support Single-byte and multi-byte character code sets are supported. EXAMPLES To create a new SCCS file: sccs create file To get a file for editing, edit it, create a new delta and get file for editing: sccs edit file.c ex file.c sccs deledit file.c To get a file from another directory (/usr/src/cmd/SCCS/s.cc.c): sccs -d /usr/src get cmd/cc.c To make a delta of a large number of files in the current directory, enter: sccs delta *.c To get a list of files being edited that are not on branches, enter: sccs info -b To get a list of files being edited by you, enter: sccs tell -u In a makefile, to get source files from an SCCS file if it does not already exist, enter: SRCS = <list of source files> $ (SRCS) : sccs get $(REL) $@ RETURN VALUE A successful completion returns 0. On error, sccs exists with a value from <sysexits.h> or the exit value from the command that was invoked. The only exception is the check pseudo command which returns a non zero exit status if a file is being edited. SEE ALSO admin(1), cdc(1), comb(1), delta(1), get(1), prs(1), rmdel(1), sact(1), sccsdiff(1), sccshelp(1), unget(1), val(1), vc(1), what(1), sccsfile(4). SCCS: Source Code Control System chapter in Programming on HP-UX. STANDARDS CONFORMANCE sccs: XPG4
CONTENTS |