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
   110   111   112   113   114   115   116   117   118   119   120