(Unit-4) Coding

1. (Unit-4) Coding • The goal of coding is to translate the design of the system given in design phase into the code of the programming language. • The goal is also to reduce the testing and maintenance part. This means that programs should not be written that they are easy to write but it should be easy to read and understand. 1.0Programming Practice 1.1 Top down and bottom up coding: • Once the design is already over we can implement that design in terms of coding by top-down or bottom-up approach. • Top down means we start to implement the main modules first and then start the coding of sub modules and so on. Here stubs are written for lower levels. • Bottom up means that we start from the modules at lowest level and then code for higher modules. It is used for layered systems like O.S. Here drivers are written for upper levels.

2. Coding 1.2 Structured Programming: • Generally structured programming means “ go to” less programming. • A program has static and dynamic structure. Static means line of code in which it is written. Dynamic means sequence of lines which will be executed in program when it runs. • The goal of structured programming is that static & dynamic structures are same. All the program contains the branching or repetition. So , statements should be single-entry and single exit. Examples are below: Selection : if B then S1 else S2 Iteration : While B do S or repeat S until B Sequencing :S1 ; S2 ; S3……….

3. Coding 1.3 Information Hiding: • Information hiding can reduce the coupling between modules and make the system more maintainable. With information hiding, the impact on modules using the data need to be evaluated only when the data structure or its access function are changed. Otherwise ,as other module nor directly accessing data , changes in this modules will have no effect on other modules using data. • Information hiding is also an effective tool for managing the complexity of developing s/w. When ever , problem partitioning must be used so that concerns can be separated and different parts solved separately . By using data hiding , we have separated the concern of using data to produce some desired results. Now to produce desired result , only desired operations on the data need to be performed, these by taking task of designing these modules easier. • Information hiding principle is supported by data abstraction. With support for data abstraction , a module is defined that encapsulates the data.

4. Coding 1.4 Programming Style: • There are certain general rules for good programming style. 1. Name :The three things should be avoided : giving cryptic (short) names, unrelated names and same name for multiple purpose. 2. Control Constructs: Generally single-entry-single-exit constructs are used. 3. Go To: The forward go to are more acceptable than the backward. The use of go to for exiting and error handling is also acceptable. 4. Information hiding: Data abstraction should be used if possible. 5. User Defined types: It should be used when ever required. E.g. enumerated data type. 6.Nesting: The deep nesting should be avoided . E.g. if C1 then S1 else if C2 then S2 else if C3 then S3 This statement can be converted to: if C1 then S1 if C2 then S2 if C3 then S3

5. Coding 7. Module Size: The programmer should check that the modules are not too small ( < 5 lines) or even too large ( > 100 line). This is because it has the effect of cohesion and coupling. 8. Module Interface: The module should not have complex interface. E.g. if module has more than 5 parameters it should be divided into two separate modules. 9. Program Layout: It means that program should be such that it is easy to understand. 10. Side Effect: If module is changing global variable such side effect should be documented. 11. Robustness: A program should try to handle exceptional condition ( like incorrect input, overflow etc.) In such situation program should not just “crash”; it should produce some meaningful message and exit gracefully.

6. Coding 1.5 Internal Documentation: • Internal documentation in the code can be extremely useful in enhancing the understandability of program. So proper comments should be written in the programs for better understanding. • The comment should specify what the code is doing. It is not required for comment for each line . Generally the comments for whole is enough. • The comments should contain following information. 1. Module functionality, or what module is doing 2. Parameters and their purpose 3. Assumption about the inputs , if any. 4. Global variables accessed and/ or modified in module. • In addition to above, other information can also be included , which is decided as standard for system like – author name, compilation date , modification date etc.

7. Coding 2.0 Code verification: • The goal of verification is to check that the code implemented according to the design. • Verification of program can be static or dynamic. Static involves only conceptual execution. While in dynamic method the program is executed with some test data and out of program are checked to find the errors. • Two techniques for verifications are used: 1.0 Code Reading 2.1 Code reading: • Code reading technique is used for verification , in this process the programmer reads the code and find the difference between the design specification and actual implementation. This process is best if the code is read from inside-out, i.e. we use the abstraction. It is very useful method and find the errors which are not found in the testing . This method will result into well- structured program and so it is also called desk review.

8. Testing 1.0 Testing fundamentals: There are different testing fundamentals: • Error: Error can be interpreted with two ways. It is the difference between computed value and theoretically correct value. In terms of software , it is a difference between the actual output and ideal out required. • Fault: It is condition, which makes the software to fail to perform its required function. • Failure: Failure is the inability of system or software to perform certain operation. A failure always occurs only if there is a fault in the system, but fault does not mean that system is failed. • Reliability: It is the probability that software will fail for the specified time and specified condition.

9. Testing 1.1 Levels of testing: Clients needs Acceptance testing Requirements System testing Design Integration testing Code Unit testing

10. Testing 1.2 Top- Down and Bottom-Up approaches • Stubs are written for top-down and drivers are written for bottom-up approach. 1.3 Test Oracle • For testing any program we need to have a description of expected behavior of the program , and a method of determining whether the observed behavior conforms to the expected behavior. • A test oracle is a mechanism , different from the program itself, that can be used to check the correctness of output of program for the testcases.

11. Testing 2.0 Functional Testing: It is also called “black box testing” as we know only the type of function a program performs , but not the internal logic of it. The four method used as follows: • Equivalence class Partitioning • Boundary value analysis • Cause effect graphing • Special cases • Equivalence class Partitioning: Equivalence classes are usually formed by considering each condition specified on an input as specifying a valid equivalence class and one or more invalid equivalence classes. E.g. if an input condition specifies a range values( 0 < count < Max) then form valid equivalence class and two invalid equivalence class ( count <0 ) and ( count > Max).

12. Testing 3.0 Structural testing: • It is a glass box testing , where the internal structure of program is tested. For testing the program the structure of a program , it is required to know the coverage or range of the structure. • Coverage Criteria statement coverage criteria branch coverage criteria path coverage criteria • Test case generation: • Instrumentation for structural testing • Complexity base Criteria

13. Testing 4.0 Testing Process (A)Test plan: • Unit test • Test plan: is a set of one or more modules together with associated data which are from a single computer program. It may be module, few module or complete program • Features to be tested: these may include functionality, performance , design constraints • Approach for testing: testing criteria based on structural and functional testing. • Test deliverables: it includes test case specification report, test summary , test log. • Schedule • Personal allocation (B)Test case specification ( c)Test case execution and analysis

14. Testing b) Boundary value analysis • A boundary value test case is set of input data that lies on the edge or boundary of class of input data or that generates output that lies at the boundary of class of output data. • It is useful to select boundary elements of the range , and an invalid value just beyond the range. c) Cause effect graphing • The cause is a distinct input condition and effect is distinct output condition. Each condition forms node in cause-effect graph. The conditions should be stated such that they can be set to either true or false. • The conditions are combined using Boolean operators “and “,”or” and “not”. d) Special Testing: • Here in some program , some combination require special treatment.