Implementation Plan system integration required for each iteration

Implementation • Plan system integration required for each iteration • Distribute the system by mapping executable components onto nodes in the deployment model - based on active classes • Implement the design classes and subsystems • Unit test components and integrate them by compiling and linking them together into one or more executables

Implementation Workflow

Implementation Components • • • <<executable>> - program that may be run on a node <<file>> - file containing source code or data <<library> - a program library <<table>> - a database table <<document>> - a document

Architectural Implementation • Identifying architecturally significant components, such as executable components • Mapping components to nodes in the relevant network configurations

Integrate System • Create an integration build plan describing the builds required in an iteration and the requirements on each build • Integrate each build before it is subject to integration tests

Criteria for Planning a Build • Should add functionality to previous build by implementing complete use cases and/or scenarios of them • Should not include too many new or refined components • Should be based on previous build, and should expand upwards and to the sides in the layered subsystem hierarchy

Implementing Use Case • Identifying the design subsystems and classes that participate in the use case realization • Identify implementation subsystem and components in the implementation model tracing to those subsystems/classes • Consider impact that implementing the requirements made on these implementation subsystems and on the components on top of the current build • Results captured in the integration build plan

Integrating a Build • Collecting right version of the implementation subsystems and components • Bottom up compilation • Linking into build

Implement Subsystem

Implementing a Class • Outlining a file component that will contain the source code • Generating source code from the design class and the relationships in which it participates • Implementing the operations of the design class in terms of methods • Ensuring that the component provide the same interface as the design class

Unit Testing • Specification testing – done via unit I/O – based on concept of equivalence class – e. g. state of account resulting in 3 equivalence classes: empty, negative balance, positive balance – e. g. input arguments: 0 and positive; output: positive amount withdrawn and nothing withdrawn – Test: normal value (4, 3. 44, 5923), value on boundary (0, 0. 00001, 10000), value outside boundary, illegal value ( -144, A) – Test: withdraw $14 from account with $-234. 11, 0, 12. 123, 15

Unit Test • Structure testing – verify component works internally as intended – statement test, branch test, path test – e. g. See text, Fig. 10. 27