Issue: How do we combine individually unit tested modules into a complete system?
Bottom - Up
Top - Down
Throw all the modules together into a large bag
and shake vigorously ... it usually goes "bang." In
other words, integration doesn't begin until all modules are unit
tested, then all modules are integrated and tested
simultaneously. This is most common when the team has no shared
code repository, or developers are "hoarding" their work and not
Defects difficult to isolate.
Crucial design features, e.g. interfaces between modules, aren't tested till late when rework is expensive.
Makes no distinction between critical and peripheral parts of the system.
No flexibility in scheduling. Concentrated use of resources (testers).
Progress is very hard to measure. Many projects "die on the vine" because the modules won't integrate.
Requires little or no planning. Just hold a "coding party" and keep shoving pizzas under the door.
Implement the interfaces first (this was a requirement in our project; coding and compiling the module headers).
Code and unit test an individual module.
Add the module to the system.
Test and debug the system.
Repeat until the system is complete.
Defects can be isolated!
Major interfaces are tested first and most frequently.
Testing resources are evenly distributed.
Easier for management to monitor progress. Project behind schedule less likely to be axed.
Implementors see early results - motivating!
The planning process is a kind of design review.
Use the incremental approach. The order of integration proceeds from the top of the structure chart down.
May require "stubs" or "fakes" for lower level
modules yet to be coded. Fake come in several varieties:
Do nothing (stub). It compiles okay so you can do a build.
Display a trace message.
Test or display input parameters.
Return a constant value.
Accept input from a tester at the terminal.
Be a simple version of the real module.
UMBRELLA appoach is sometimes more practical than strict Top-Down.
Users can be shown a partial version early during implementation to get feedback
Easier for users to deal with overdue project if they have a partial system to work with.
Users may actually use the partial (or skeleton) versions as part of a transition from their current system.
Stubs are easier to write than drivers.
Use the incremental approach. The order of integration proceeds from the bottom of the structure chart toward the top.
Drivers are expensive to write and error prone.
No partial system implemented. (lacks control modules)
Lower level modules receive more testing (often key functionality is located here).
In crunch mode, coding can begin early (at the risk of integration failure).
Use the incremental approach. The order of integration proceeds as follows:
Determine which subset of modules (a "thread") are needed to perform each function required in the specification.
Allocate the threads to "stages," where each stage demonstrates a significant partial functioning system.
Implement in top-down order.
Requires a lot of planning.
McConnell doesn't like it because it creates partially implemented units.
Allows integrators to prioritize the system features to be integrated.
Partial system is available early.
Threads can be implemented in parallel.
Learn a simple three-step technique to create an integration schedule for the modules in a class diagram.
(Winter 2011) Discuss: What were the advantages and disadvantages that you experienced following the Crazy Eights integration schedule in lab?