Page 115 - DCAP305_PRINCIPLES_OF_SOFTWARE_ENGINEERING
P. 115
Unit 5: Software Project Planning
Unlike derived objects, which can be deleted to make room, source objects are “sacred”, Notes
because deleting them may cause irreparable damage or at least significant delay until they
are reconstructed. However, derived objects may also become “sacred”, i.e., they must not be
deleted merely to make room, if it is impossible or time consuming to reproduce them. For
instance, derived objects that are imported from other sites, especially vendor supplied programs,
must not be deleted, even though they are derived in most cases. Another example are derived
objects for which the original derivers have stopped working (if they have not been ported to
new hardware, say), or if the corresponding input objects have been lost.
A special case is derived objects that are modified manually. Examples are automatically
generated program skeletons and templates that are fleshed out by hand, or object code that is
patched manually. In principle, these manual modifications produce new source objects. However,
the SCM system should store a traceability link that records the dependency between the two
objects. This link can be used for generating a reminder to update the source object if the derived
object changes. Traceability links should also be recorded among dependent source objects, for
example between a specification and its implementation, or a program and its documentation.
In fact, most source objects in an SCM system depend on one or more other objects except
perhaps the initial requirements specification. Traceability information is extremely valuable
for automatically producing update reminders, for reviewing completeness of changes, and
for informing maintainers what information they need to consider when preparing a change.
5.7.3 Structure of Software Objects
The body of a software object is either atomic or structured. An atomic object, or atom, has a
body that is not decomposable for SCM; its body is an opaque data structure with a set of generic
operations such as copying, deletion, renaming, and editing. An atomic object may consist of a
program written in some language, a syntax tree produced by a structure editor, a data structure
generated by a WYSIWYG word processor, or an object code module produced by a compiler.
A configuration has a body that consists of sub-objects, which may themselves have sub objects,
and so on. Configurations have two subclasses: composites and sequences. A composite object, or
simply composite, is a record structure comprised of fields. Each field consists of a field identifier
and s field value. A field value is either an object identifier or a version group identifier. An
example of a composite object is a software package consisting of a program, a user’s manual,
and an installation procedure. Another example is a regression test object, consisting of a test
program, input data, expected output data, and a comparator for comparing expected and actual
output. Thus, fields may contain data as well as operations.
A sequence is a list of object and version group identifiers. Sequences represent ordered multisite
of objects. They are used for combining sub-objects that are of the same class, or when the
number of sub-objects is indeterminate. In contrast to composites, the individual elements of a
sequence fulfil identical roles and are treated in the same way for SCM purposes, such as the
list of object code modules constituting a library.
Because of the need to distinguish between “precise” and “loose” configurations, we introduce the
following terms. A generic composite is a composite with at least one field value that is either a
version group identifier or a generic configuration (i.e., a generic composite or a generic sequence).
The opposite of a generic composite is a baseline composite, which is a composite whose field
values are atomic objects, baseline composites, or baseline sequences. The subclasses generic
sequences and baseline sequence are defined analogously. Finally, a generic configuration, also
called a system model, is a generic composite or a generic sequence. A baseline configuration,
or simply baseline, is a baseline composite or baseline sequence.
In both composites and sequences, source and derived objects may be freely intermixed.
However, including derived objects presents a problem: Since the derived objects may not yet
LOVELY PROFESSIONAL UNIVERSITY 109