Chapter 20. Development

CONTENTS
  •  Introduction
  •  Development Life Cycle
  •  SCCS - Source Code Control System
  •  SCCS Commands
  •  Manual Pages of Some Commands Used in Chapter 20

Introduction

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.

Development Life Cycle

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.

Analysis Phase

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.

Development Phase

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.

Test Phase

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.

SCCS - Source Code Control System

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.

graphics/20icon01.gif

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.

SCCS Revision Versioning

graphics/20icon02.gif

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.

Figure 20-1. Sequential Pattern of SCCS Software Revisions

graphics/20fig01.gif

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.

Figure 20-2. Branch Delta Created

graphics/20fig02.gif

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.

graphics/20icon02.gif

SCCS Commands

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.

Admin Command

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.

get Command

graphics/20icon01.gif

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]]]]] 

SCCS Command

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:

graphics/20icon02.gif

$ 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.

unget Command

This command cancels the get -e or edit command, preventing a new delta from being created and deleting any lock associated with the file.

delta Command

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.

graphics/20icon02.gif

The sccs command can be used with delta much the same as it is used with edit.

Manual Pages of Some Commands Used in Chapter 20

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

graphics/20icon02.gif

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


UNIX User's Handbook
UNIX Users Handbook (2nd Edition)
ISBN: 0130654191
EAN: 2147483647
Year: 2001
Pages: 34

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net