IMPLEMENTATION ISSUES

• INTRODUCTION• The implementation phase of software

development is concerned with translating design specifications into source code.

• Source code clarity is enhanced by structured coding techniques, by good coding style, by appropriate supporting documents, by good internal comments, and by the features provided in modern programming languages.

• The implementation team should be provided with a well defined set of software requirements, an architectural design specification , and a detailed design description.

• Each member must understand the objectives of implementation.

• In a well known experiment, weinberg gave five programmers five different implementation goals for the same program

• Minimize the memory required, maximize output readability, maximize source text readability, minimize the number of source statements, and minimize development time/

• The results shown in fig 6.1• Each programmer achieved the desired

objective and ranked high on related objectives.

• The programmer who minimized memory ranked second in minimizing the number of source statements.

• The programmer who maximized output readability ranked second in source code readability.

• 6.1 structured coding techniques.• The goal of structured coding is to linearize

control flow through a computer program so that the execution sequence follows the sequence in which the code is written.

• Linear flow of control can be achieved by restricting the set of allowed program constructs to single entry, single exit constructs leads to questions concerning efficiency, questions about “ reasonable” violations of single entry, single exit, and questions about the proper role of the go to statement in structured coding.

• 6.1.1. single entry, single exit constructs• In 1966, bohm and jacopini published a paper

in which they demonstrated that sequencing, selection among alternative actions, and iteration is a sufficient set of constructs for describing the control flow of every conceivable algorithm.

• They argued that every turing machine program can be written in this manner.

• A modified version of the bohm-jacopini theorem can be states as follows.

• Any single entry, single exit program segment that has all statements on some path from the entry to exit can be specified using sequencing, selection and iteration.

• A sufficient set of single entry, single exit constructs for specifying control flow in algorithms is

• Sequencing : S1;S2;S3;• Selection: if B then S1 else S2;• Iteration : while B do S;

• The single entry, single exit nature of these constructs is in fig 6.2

• the single entry, single exit property permits nesting of constructs within one another in any desired fashion;

• Each statement Si might be an assignment statement, a procdure call, an if_then-else, or a while_do.

• Statements of the latter forms may in turn contain nested statements.

• The most important aspect of the single entry, single exit property is that linearity of control flow is retained. Even with arbitrarily deep nesting of constructs.

• Additional single entry, single exit constructs are widely used in practice.

• For eg. Pascal provides the control flow constructs is shown in fig 6.3

• each construct in fig 6.3 is expressed in terms of sequencing. If_then_else and while_eo “ if B then S else null”. “case” as a sequence of nested if_then_else and “repeat” as the sequence

• See pgm in book.

• A different sufficient set of constructs for structured coding is sequencing, the ease statement for selection, and repeat_until for iteration,

• All of the constructs in fig 6.3 expressed in terms of sequence, case and repeat constructs.

• The total set of constructs provided by Pascal and other modern programming languages offers increased notation convenience, increased readability and in some case, increased efficiency.

• Sequencing and conditional branching are the only necessary control flow mechanisms because the bohm-jacopini requirements of selection and iteration can be implemented using conditonal branching.

• 6.1.2 Efficiency considerations• a recurring criticism of adherence to single

entry, single exit constructs is that they result in inefficient use of memory space and execution time.

• The following eg illustrates the need for auxiliary variables in a search loop on a linked list.

• See the program in the book.• The purpose of the loop is to search a linked

list L for value X.

• Explanation• When p=null and x value is undefined.• Some language translators avoid this problem by

evaluating relational expressions in left-to-right fashion.

• If leftmost operand is false in AND, no need to evaluate rightmost operand .

• So it executes from left-to-right . It works correctly.• Ada programming language provides and_then and

or_else boolean operaions for these situations.• These operators are short-circuit conditions.

• Using short cut conditions, the example is rewritten as

• See book• Correct solution to the above problem is to

use a go to statement for premature loop exit and to handle alternative actions on loop exit:

• See book• Fig 6.5 shows three alternative “structured”

solutions for the search loop.• See book

• Solution 6.5 a uses an auxiliary variable Q, to record the location of X in the list.

• Solution b uses a Boolean variable to trigger loop exit when the first occurrence of X is located.

• Solution c assumes that the total number of nodes in the list, N is known and uses an integer counter I to count the number of nodes visited.

• In summary, solutions a and c find the last X in the list, and• Solution b finds the first X in the list• Solution a can be modified as indicated to find the first X

in the list.• Solution c is not desirable because it is inconvenient to

maintain the total node count X in dynamic list processing.

• Finally, the problems encountered in these examples can be avoided by a slight change in the data structure.

• Adding a header node L to the list as in fig 6.6• See book• If X is in the list, P will point to the location of

first X on loop exit• P will point to the last node on the list on loop

exit, which may or may not contain X.• This modification gives 3 points about

structured coding.

• 1.structured coding practices give no guidance in the design and method of access to data representations.

• 2. the modified eg finds the first X in the list.• 3. it may not be possible to design a data

structure that will satisfy all requirements in an optimal manner.

• Another concern is about efficiency in structured coding is calling of code repeatedly.

• Otherwise, the single entry, single exit rule is violated.

• Fig 6.7 shows 4 versions of a code segment• Version a uses 3 constructs with repeated

code segments.• Version b uses if then to reduce the number of

repeated code segments.• Version c and d use goto statements to

completely eliminate repeated code segments.

• Multiprocessors with limited memory requires version d

• 6.1.3 violations of single entry, single exit• The goal of structured coding is to improve the clarity

and readability of source programs.• It is not unusual to have several different conditions

for termination of a loop .• The best procedure for dealing with multiple loop

exits is to redesign the algorithm . So that multiple loop exits are not required.

• A reasonable solution expressed in FORTRAN IV as in fig 6.8

• Although gotos are used to achieve multiple loop exits and to isolate alternative actions on exit, the spirit of clarity and locality is maintained.

• Multiple loop exits in the ada programming language are illustrated in fig 6.9

• Algorithms often redesigned to eliminate the need for multiple exits.

• 6.1.4 Data encapsulation• Data encapsulation involves packaging of a data

structure and its access routines in a single module.• A data strucutre is defined by the operations that

can be performed on it.• Data encapsulation should not be confused with

abstract data types nor with data abstraction.• An abstract data type is a user defined template

that can be used to create numerous instances of encapsulated data objects, in the same way that the integer type can be used to create numerous instances of integer objects.

• In Fortran iv , data encapsulation can be implemented that violates single entry, single exit .

• Eg is given in fig 6.10• Subroutine INTSTK has 3 entry points, five

RETURN statements, and two go to statements.

• STACK and INDEX should be placed in a COMMON block to make them static objects.

• The FORTAN in eg 6.10 gives 5 basic features• 1. multiple entry and return points.• 2. local hidden source code and data

representations• 3. static data objects.• 4. an initialization section• 5. exception handling.

• 6.1.5 The go to statement• The go to statement provides unconditional

transfer of control and thus allows violation of the single entry, single exit condition of structured coding.

• The go to statement can be used to simulate single entry, single exit constructs in primitive programming languages.

• Fig 6.11 shows the use of the go to statement in FORTRAN IV to simulate if_then_else and while_do.

• Preprocessors and micro processors are available to automatically translate structured constructs into FORTRAN IV, COBOL and various assembly languages.

• Although the go to statement can be used with positive effect on program clarity, it is an extremely low-level construct and is easily misused.

• Code for a four-way selection might be implemented using gotos in the following manner.

• See book

• In summary, the go to statement can be a valuable mechanism when used in a disciplined and stylistic manner.

• As a general rule, forward go to exit local constructs and to transfer control to local-error handling code are acceptable.

• Go to statements that transfer control to remote regions of the code, or that jump in and out of code segments in clever ways, destroy the linearity and locality of control flow . They are to be avoided.

• 6.1.6 Recursion• A recursive subprogram is one that calls itself,

either directly or indirectly.• Recursion is a powerful and elegant

programming technique.• Recursive algorithms arise naturally in

conjunction with recursive data structures.• When the exact topology and number of

elements in the structure are not known. • And, in other situations that require

backtracking algorithms .

• For eg, an algorithm for in-order traversal of binary trees is expressed relatively as

• See book• P(T) is a procedure that is invoked to process nodes of

the tree as they are encountered in IN-ORDER fashion.• The distinguishing characteristic of recursive

subprograms is use of a system provided stack to hold values of local variables, parameters, and return points during recursive calls.

• A FORTRAN system that uses static memory allocation cannot support recursive subprograms because a stacks required to record successive return addresses on successive invocation prior to returns.

• Recursion is used in appropriately to implement algorithms that are inherently iterative.

• Such algorithms do not require a stack or any other backtracking mechanism.

• Eg of inappropriate use of recursion include routines to compute factorials and fibonacci numbers.

• See book• Straight forward iterative algorithms for

factorial and Fibonacci follow• See book

• An iterative implementations of an inherently recursive algorithm will result in a user maintained stack to simulate recursion or clever manipulation of pointers in the data structure to set up backtracking links.

• Ada language is used to improve the quality of the factorial function.

• Assumed type NATURAL is a user defined data type whose objects are the non negative integers.

• It is illegal for objects of type NATURAL to take on negative values.

• Local variables FAC is initialized to 1 in the declaration statement.

• If the value of N PASSED in is 0 or 1, control will fall through the for loop, and the proper value(1) will be associated with the funciton name via the return statement.

• If N is not 1, FAC is properly initialized for the loop.

• 6.2 coding style• Style is the consistent pattern of choices made

among alternative ways of achieving a desired effect.

• In computer programming, coding style is manifest in the patterns used by a programmer to express a desired action or outcome.

• The goal of good coding style is to provide easily understood, straightforward, elegant code.

• Use a few standard control constructs:• Nesting of statement sequences, selection

among alternatives, and a mechanism for iteration are sufficient.

• If implementation is done in FORTRAN,COBOL, BASIC, structured constructs is achieved by using conditional and unconditional branching in stylistic patterns to achieve the effects of if_then_else, while_do, repeat_until,case etc.

• Use gotos in a disciplined manner:• In primitive programming languages, the gotos

statement is used in conjunction with the if statement to achieve the format and effect of structured coding constructs.

• In all these cases, the goto is used in a stylistic, disciplined manner to achieve a desired result.

• The goto statement, coupled with the if statement, permits user definition of needed control flow mechanisms in the same way that user defined data types permit user definition of unavailable data representations.

• Introduce user defined data types to model entities in the problem domain:

• Ada and other programming languages provide user-defined data types.

• Use of distinct data types makes it possible for humans and computer systems to distinguish between entities from the problem domain.

• For eg., enumeration data types is used to enumerate the elements of an indexing sequence

• Subtypes used to place constraints on objects of a given type and

• Derived types permit segregation of objects that have similar representations.

• The enumeration type • See book• In primitive programming languages there are

a limited number of predefined data types(logical, integer, real,complex,double precision)

• And no mechanism for user-defined data types.

• Integers used for indexing.• Velocity and temperature objects map into

objects of type real.

• User-defined data types that segment the problem domain in a logical manner can greatly improve the clarity and readability of a source program

• It also provide increased data security.• Programs written in languages that do not

support user-defined data types cannot be made as clear or as secure as programs written in modern language.

• Hide data structures behind access functions. Isolate machine dependencies in a few routines:

• In a software system designed using information hiding, each module makes visible only those features required by other modules.

• All other aspects of the modules are hidden from external view.

• Hiding data structures behind access functions is the approach taken in data encapsulation, where in a data structure and its access routines are encapsulated in a single module.

• In languages having global scope, disciplined programming style can be used to ensure that major data structures are manipulated in only a few regions of the source code.

• This approach improves the modularity of a source program, and new access functions can be provided as needed.

• Changes in the details of data representation require only local changes to, and only local recompilation of, access code.

• If the specification part of an access routine is changed, all routines that call the modified access routine must be modified and recompiled.

• But the modification required is very simple.• Call statements needing modification can be

identified using a call graph listing.• Similar reposing applies to the isolation of

machine dependencies in a few separate routines.

• Provide standard documentation prologues for each subprogram and or compilation unit:

• A documentation prologue contains information about a subprogram or compilation unit that is not obvious from reading the source text of the subprogram or compilation unit.

• The exact form and content of a prologue depends on the nature of the implementation language.

• A routine in ada is more self descriptive than one written in assembly language, and will require less information in the documentation prologue.

• For instance, the prologue of an assembly language routine should describe the ways in which various machine registers and parameter areas are used by the routine.

• In ada, the use of IN,OUT and IN OUT parameter modes, when used in conjunciton with user defined data types for formal parameter specification, makes this aspect of ada routines self documenting

• See book

• Carefully examine routines having fewer than 5 or more than 25 statements:

• A subprogram consists of a specification part, a documentation prologue, declaration, executable statements and in some languages, exception handlers.

• Experience indicates that, in many situations, routines that have 5 to 25 executable statements satisfy these criteria.

• A subprogram that has more than 25 executable statements probably contains one or more well defined sub functions that can be packages as distinct subprograms and invoked when needed.

• It has been suggested that 30 executable statements is the upper limit of comprehension for a single reading of a subprogram written in a procedural programming language.

• A sub program that has fewer than five statements is usually too small to provide a well defined function.

• A routine having fewer than 5 or more than 25 executable statements should be closely examined for in line placement in the calling routines and identification of well defined sub functions that can be placed in separate routines and called as needed.

• Use indentation, parentheses, blank lines, and borders around blocks of comments to enhance readability:

• As illustrated in fig 6.12 a and b, • A pleasing format of presentation greatly

enhances the readability of a source program.• Formatting of source text can be done

manually by the programmer, or by a pretty print routine that automatically indents code to emphasize the syntactic structure of the programming language.

• A formatting routine insert blank lines and borders around comment statements.

• If formatting of source text is done by the programmers, standard conventions should be agreed to and adhered to by all programmers.

• If formatting is done by a program, all source code should be processed by the formatter before it is retained in a permanent file.

• A source text formatting program is a valuable tool see book

• Table 6.2

• Don’t be too clever.• The point is illustrated by the following segment of code

written in FORTRAN IV • See book• The code is inefficient.• The following code segment achieves the same result in an

efficient manner.• See book• The second version of this algorithm makes obvious the

initialization of matrix A using N extra assignment statements.• The first version requires an integer multiply operation, two

integer division operations, and a floating point conversion for each of the elements in the matrix

• See book

• Avoid null then statements.• A null then statement is of the form • See book• Avoid then_if statements.• A then_if statement is of the form• See book• Don’t nest too deeply• The major advantage of single entry, single

exit constructs is the ability to nest constructs within one another to any desired depth while maintaining linearity of control flow

• See book.

• As a general rule, nesting of program constructs to depths greater than 3 or 4 levels should be avoided.

• Avoid obscure side effects.• A side effect of a subprogram invocation is any

change to the computational state that occurs as a result of calling the invoked routine,

• Side effects include modification of parameters passed by reference or by value result, modification of global variables, i/o operations, and other items listed in sec 6.4.3

• Don’t sub optimize.• Sub optimization occurs when one devotes

inordinate effort to refining a situation that has little effect on the overall outcome.

• There are two aspects to sub optimization of software.

• First it is usually not possible to determine what portion of the code will occupy the majority of execution time until execution characteristics of the running program are measured.

• Second, unless one has intimate knowledge of the language translator, operating system, and hardware, it usually is not clear how various situation will be handled by the system.

• Carefully examine routines having more than five formal parameters.

• Parameters and global variables are the mechanisms used to communicate data values among routines.

• Parameters bind different arguments to a routine on different invocations of the routine, and global variables communicate arguments whose bindings do not change between calls to the routine.

• Parameters and global variables should be few in number.

• Long, involved parameter lists result in excessively complex routines that are difficult to understand and difficult to use

• They result from inadequate decomposition of a software system.

• Global variables should be shared among routines on a selective, as needed basis.

• The manner in which data are communicated among routines is a major criterion for guiding and assessing the quality of detailed design.

• Selection of the number 5 as the suggested upper bound on the number of parameters in a subprogram is not an entirely arbitrary choice.

• Fewer parameters and fewer global variables improve the clarity and simplicity of sub programs.

• Don’t use an identifier for multiple purposes.• Programmers sometimes use one identifier to

denote several different entities.• The rationale is memory efficiency.• Three variables will require 3 or more memory

cells, whereas one variable used in 3 different ways requires only one third as many memory cells.

• There are several things wrong with this practice.

• First, each identifier in a program should be given a descriptive name that suggests its purpose.

• This is not possible if the identifier is used for multiple purposes.

• Second, the use of a single identifier for multiple purposes indicates multiple regions of code that have low cohesion

• Third, using an identifier for multiple purposes is a dangerous practice because it makes the source code very sensitive to future modifications.

• Finally, use of an identifier for multiple purposes can be extremely confusing to the reader of a program

• If a system is so tightly constrained in memory space that single identifiers must be used for multiple purposes, the system should be segmented into several smaller routines with an overlay structure.

• 6.3 standards and guidelines• Coding standards are often viewed by

programmers as mechanisms to constrain and devalue the programmer's creative problem solving skills.

• This argument is advanced by programmers who do not understand the spirit or intent of good coding style.

• Creativity always occurs within a basic framework of standards

• It is desirable that all programmers on a software project adopt similar coding styles so that code of uniform quality is produced.

• The individual style of each programmer on a project is identifiable even when rigid adherence to standards of programming style is observed.

• A programming standard specify items such as• 1. goto statements will not be used.• 2. the nesting depth of program constructs will

not exceed five levels.• 3. subroutine length will not exceed 30 lines.

• A guideline phrases these specifications in the following manner

• 1. the use of goto statements should be avoided in normal circumstances.

• 2. the nesting depth of program constructs should be five or less in normal circumstances.

• 3. the number of executable statements in a subprogram should not exceed 30 in normal circumstances.

• 4. departure from normal circumstances requires approval by the project leader.

• Several conditions are necessary to obtain programming guidelines.

• 1.programmers understand the value of programming guidelines.

• 2. programmers must have the opportunity to participate in establishing the guidelines.

• 3. the guidelines must be subject to review and revision when they become burdensome.

• 4. there must be a mechanism for following violations of the guidelines in special circumstances.

• 5. automated tools must be used to check adherence to the guidelines.

• 6.4 documentation guidelines• This section describes some aspects of

supporting documents, the use of program unit notebooks, and some guidelines for internal documentation of source code.

• 6.4.1 supporting documents• Requirements specifications, design documents,

test plans, user’s manuals, installation instructions, and maintenance reports are examples of supporting documents.

• These documents are the products that result from systematic development and maintenance of computer software.

• A systematic approach to software development assures that supporting documents evolve in an orderly manner, and

• That the documents are available when needed.

• In the ad hoc approach to software developments, preparation of supporting documents is usually deferred until system implementation is completed.

• Because of time constrains and lack of motivation, documents generated in this manner are usually inadequate to support testing, training, modification and maintenance activities.

• Supporting document of substandard quality, that are not available when need, are a strong indication of problems with the processes being used to develop and maintain software.

• These documents should evolve as a natural byproduct of the development process.

• 6.4.2 program unit notebooks• A program unit is a unit of source code that is

developed and or maintained by one person.• That person is responsible for the unit.• In a well-designed system a program unit is a

subprogram or group of subprograms that provide a well- defined function or form a well defined subsystem.

• Program unit notebooks are used by individual programmers to organize their work activities, and to maintain the documentation for their program units.

• A program unit notebook consists of a cover sheet and several actions.

• The cover sheet is the table of contents and the sign-off sheet for the various milestones associated with the program unit.

• Fig 6.13 illustrates the cover sheet of a program unit notebook.

• Maintaining the notebook is the responsibility of the programmer currently assigned to the program unit.

• The notebook stays with the program unit throughout the lifetime of the unit, and passes from programmer to programmer as responsibility for the unit shifts.

• The sections in a program unit notebook correspond to the various phases of the unit’s life cycle.

• The cover sheet is used to record projected and actual milestone dates, and

• The sign-off by a reviewer indicates satisfactory completion of a life cycle phase.

• Reviewers are usually team leaders or project mangers who have responsibility for the total system or a significant subsystem.

• The collection of cover sheets for all program units in a system provides a detailed summary of the current status of the project visibility and to highlight problem areas.

• The requirements section of a program unit notebook contains only the specification that relate to that particular program unit.

• Both the initial version, as agreed to by the customer, and copies of subsequent modifications to the requirements are maintained in the notebook.

• The architectural and detailed design sections of the notebook contain working papers and the final design specifications.

• The unit test plan contains a description fo the approach to be used in unit testing, the testing configuration, the actual test cases, the expected outcomes for each test case, and the unit testing completion criteria.

• The section containing unit source code contains a listing of the current version of the unit and listings of significant previous versions.

• The test results section contains results from the test runs and an analysis of those results in terms of expected results.

• Problem reports are filed after the system comes under configuration control.

• At some point in the life cycle, a system comes under configuration control, and any subsequent changes must be reviewed and approved by a change control board.

• The problem report describe an error situation or a desired modification.

• In some case, the problem reports will reveal recurring problems in certain units or collections of units.

• It is sometimes advisable to rewrite troublesome units rather than to continue repairing them.

• 6.4.3 internal documentation• Internal documentation consists of a standard

prologue for each program unit and compilation unit,

• the self documenting aspects of the source code, and

• the internal comments embedded in the executable portion of the code.

• The syntax of the programming language used to implement the system may incorporate some of the information specified in table 6.3

• Most programming languages do not require information concerning the transmission mode of actual parameters to be provided in a calling routine.

• This information should be provided in the prologue of the calling routine, along with a description of nonobvious side effects caused by each called routine.

• More primitive implementation languages will require more extensive prologues.

• Standard prologues should be designed for each programming language and for each project in order to accommodate the implementation language and the needs of the project.

• Compilation unit will correspond to an individual subprogram.

• When a compilation unit contains several routines, it may be possible to limit the redundancy of information in prologues and placing them in the compilation unit prologue.

• Use of standard prologues, structured programming constructs, good coding style, and meaningful identifier names to denote user defined data types, variables, enumeration literals, parameters, and subprograms can vastly improve the readability of source code and minimize the need for internal components in the executable portion of a subprogram some guideline for internal commenting in table 6.4