Chapter 29: Integration

Jacob Harper

The Integration Approach

The order of adding components to a system is crucial Benefits to careful integration

– Easier defect diagnosis– Fewer defects– Less scaffolding– Shorter time to a working project– Shorter overall development– Better customer relations– Improved morale– Improved code quality

Phased Integration

Design, code, test and debug the each class– Unit development

Combine the classes into one huge system– System integration

Test and debug the whole system– System dis-integration

Problems with Phased Integration

Problems arise when new classes are put together– Hard to find the culprit

All problems present themselves at once All this happens late in the project

– Hence, panic mode

Incremental Integration

Develop a small functional part of the system– The skeleton

Design, code, test, and debug a class Integrate the new class on the skeleton

– Thoroughly test and debug the new addition

Benefits of Incremental Integration

Errors easy to locate The system succeeds early in the project

– Improved morale Improved progress monitoring You’ll improve customer relations The units are more fully tested You can build the system in a shorter

development cycle– Certain jobs can be done in parallel

Top-Down Integration

Start with the main function Then move through each level of the program Disadvantages

– Leaves tricky system interfaces until the end of the project

– Have to make stubs to fill in the missing classes

Alternative: Vertical Slice

Bottom-Up Integration

Build all low level classes Test them with scaffolding Replace the scaffolding with real classes Disadvantages:

– Leaves integration of the whole system until last– Forces complete design of the whole system before

integration

Alternative: similar Vertical Slice method

Sandwich Integration

Start with high level business-object classes Make the device interface Finish with everything else in the middle A realistic, practical approach

Risk-Oriented Integration

“Hard part first integration” Identify level of risk with each component Code the most risky parts first

Feature-Oriented Integration

Code a skeleton first Then make each feature Three advantages

– Eliminates scaffolding– Visible evidence of progress– Works well with object design

T-Shaped Integration

One vertical slice is selected for early development

Then the overall breadth is developed Often combined with risk-oriented and feature-

oriented

Daily Build and Smoke Test

Build daily Check for broken builds Smoke test daily Keep the smoke test current Add revisions when it makes sense …but don’t wait too long Penalty for breaking builds Release builds in the morning

Chapter 32: Self-Documenting Code

Jacob Harper

Programming Style as Documentation

Use layout of code to define logical progression (indents and spaces)

Keys to Effective Comments

Don’t just repeat what the code says– Explain what it does in common English

Kinds of Comments

Repeat of the code– Restate in different words

Explanation of the code Marker in the code

– Gives notes to the programmer (ex: ***NOT DONE!) Summary of the code Description of the code’s intent Information that cannot possibly be expressed

by the code itself

Commenting Efficiently

Use a style that does not discourage modification– Boxes: too much

spacing– Lines above and below:

alright

/********************************* ** ** ** ** *********************************/

/******************************** Comments in here See, more comments Another line of comments Ok, these lines of comments are getting old*********************************/

Endline Comments

Use them to annotate data declarations Avoid using for maintenance //fixed error.. To mark end of blocks } // End of main

Commenting Control Structures

Before the control structure Put condition on ending bracket

To show nesting

// copy input field up to a commaWhile (…){ super awesome code here;}// while –- code input field

For( int i = 0, i < 10, i++){ while( condition ) {

if( something ){ ...}// if

} // while} // for