Figure 6.1: Decomposition of a computer system
A system may be composed of hundreds or even thousands of objects and the construction process may involve several types of software tools, e.g. pre-processors, compilers.
To simplify construction, a system should be broken up into sub-systems, each of which is composed of one or more components that are made up of smaller objects, e.g. program code objects.
Build files should be created to automate the construction task by building:
• Components using the individual program code objects.
• Sub-systems using the constituent components.
• The system using its constituent sub-systems.
Figure 6.1 shows an example decomposition of a system into sub-systems, components and program code objects.
Figure 6.1: Decomposition of a computer system
The constituents of a system shall be organised into logical groups to facilitate effective management and construction. While this is being performed, the following should be given consideration:
• Groupings should follow consistent rules, the criteria for determining what objects to group together should be applied consistently to the complete system.
• Lowest level objects, i.e. program code objects, should be grouped on the basis of their usage, e.g. objects that have to be compiled together should be grouped together.
• Objects that are common across one or more sub-systems should be grouped together and independently of any of the sub-systems. Multiple copies of common objects should not be created. Given the nature of the software development process, it may not be possible to identify what objects are likely to be common at the start of a project.
Once the object groups have been identified, a directory tree should be constructed that maps to this structure.
Build Management is the process of constructing the system from its constituents. It is mandatory to use a build management tool, e.g. MAKE, if one already exists on the development system. If a suitable build tool is not available then a batch file should be created to automate the construction process.
A build file shall be created for each group. This build file shall contain the following:
• Primary target: This is the component that will be constructed using the various source files.
• Dependencies: This is the list of source files or sub-targets.
• Build instructions: This is the set of commands that are required to construct the target using the dependencies.
Figure 6.2 shows an example directory structure for a system and the necessary build files.
Figure 6.2 : Directory tree for computer system
In addition to the above, it is recommended that build files contain the following:
• A directive to copy the objects to the target directory from which they will be run and used.
• A directive to delete the contents of the target directory.
The return status of all the commands that are executed by the build file should be trapped. On the detection of a failure, an error message should be generated and all files created by the failed command deleted.
The build file for a group invariably references the build file or objects of other groups. Where this is the case, the other objects or build files should be referenced using relative rather than absolute addressing, i.e. the path specified for the other build files should be relative to the path of the group being constructed.
E.g.
Group1:
module1.c module2.c ..\common\header.h
cc -h ..\common -o module1.c
cc -h ..\common -o module2.c
cc -h ..\common -o group1 module1.o module2.o
Build File for group1
Figure 6.3: Example build file
Figure 6.3 shows how the build file for “Group1” is referencing the header file in the common directory using a relative address “..\common”, rather than an absolute address “c:\user\application\src\..\common.
The use of relative addressing improves portability of build files. You should be able to move the application source tree from one system to another without the need to modify the individual build files.
These are tools that automate the construction of applications. Build management tools perform the following:
• Enable one to document targets and their dependencies.
• Enable one to identify the construction tools to be used.
• Will recompile and link the objects that have changed since the last build.
• Will use the dependency information to force the re-build of a component if any of its constituent objects are modified. e.g. the build file shown in figure 6.3, the build tools would recompile “group1” if it detects a change in the header file.
Build tools regularly have an automatic interface with the native version control tool (refer to the Version Control Standard), e.g. SCCS. Users should be wary of this automatic interface since a build tool will automatically extract objects from the version control tool if they are newer than the variants in the working directory. This behaviour is not always desirable, e.g. when one is constructing a particular baseline that is composed of a set of objects of pre-determined variants.
Build files can be used to document baselines (refer to the Approval and Baselining Standard). This can be performed as follows:
• Identify the constituents of the baseline, e.g. file1.c, file2.c and header1.h.
• Identify the variants of the constituent objects that form the baseline, e.g. version 1.5 of module1.c, version 2.0 of module2.c and version 6.0 of header.h. You will need to refer to the relevant test packages to identify the variants of the objects that have been approved together.
• Hard code the variants in the build file such that, on execution, the required objects are retrieved from the Master Library and placed in the current group directory.
• Compile the files to produce the required baseline.
E.g.
Group1: module1.c module2.c ..\common\header.h
cc -h ..\common -o module1.c
cc -h ..\common -o module2.c
cc -h ..\common -o group1 module1.o
module2.o
Baseline: Baseline1 Group1
Baseline1:
rm .
get -r1.5 ..\...\SCCS\module1.c
get -r 2.0 ..\..\SCCS\module2.c
get -r6.o ..\..\SCCS\header.h
Build File for baseline 1 of group 1
Figure 764 : Example build file used to construct a baseline
Individual programmers shall be responsible for the creation of build files for the objects that they produce.
The Software Development Manager shall ensure that project specific procedures are produced that define the template and contents of build files to be used by the project.
A Build Manager shall be appointed with the responsibility for constructing baselines in non-development environments, e.g. production.
Build files shall be treated as objects. Approved build files shall not be modified unless authorization via change control is granted (refer to the Change Control Standard).