Activity: Structure the Implementation Model

Create the initial implementation model structure 

Start by mirroring the structure of the Design Model in the Implementation Model: Design Subsystems will have corresponding Implementation Subsystems, which will contain one or more components and all related files needed to implement the component.

Create a Component Diagram to represent the Implementation Model Structure.  A simple Component Diagram is shown below:

Example Component Diagram for a simple Automated Teller Machine

Adjust implementation subsystems

Decide whether the organization of subsystems needs to be changed, by addressing small tactical issues related to the implementation environment. Below are some examples of such tactical issues. Notice, that if you decide to change the organization of implementation subsystems you must also decide whether you should go back and update the design model, or the design model to differ from the implementation model.

• Development team organization. The subsystem structure must allow several implementers or teams of implementers to proceed in parallel without too much overlap and agitation. It is recommended that each implementation subsystem be the responsibility of one and only one team. This means that you might want to split a subsystem in two, and assign them to be implemented by two implementers or two teams of implementers. Especially if the two implementers have different release cycles.
• Declarations of types. In implementation you may realize that a subsystem needs to import component from a another subsystem, because a type is declared in that subsystem. Typically, this occurs when you use a typed programming languages, such as C++, Java and Ada. In this situation, and in general, it may be a good idea to extract type declarations, into a separate subsystem.

Example

You extract some type declarations from Subsystem D, into a new subsystem Types,to make Subsystem A independent of changes to the public (visible) components in Subsystem D.

Type declarations are extracted from Subsystem D

.

• Existing legacy code and component systems. You may need to incorporate legacy code, a library of reusable components, or off-the-shelf products. If these have not been modeled in design, then implementation subsystems must be added.
• Adjust dependencies. Assume that a subsystem A and a subsystem B have import dependencies to each other. However, you may want to make B less dependent on changes in subsystem A. Extract the components of A that B imports and put in a new implementation subsystem A1 in a lower layer.

Components are extracted from subsystem A, and placed in a new subsystem A1.

Decide placement of executables

Decide where in the implementation model to place the main executables. It is usually advantageous to place each of the main executables that comprise the system in its own subsystem. The reasons for doing this are:

• Developers may have their own copy of only a few subsystems, but also need a place to link and execute the system. If executables are embedded in other subsystems, all developers would need their own copy of each subsystem with an executable in order to create a build for testing.
• Executables are often large and separating them from the bulk of the source and object files makes it easier to manage the disk space involved.
• There is often at need to keep executables even if the source code changes and not explicitly kept. Having a separate subsystem for executables allows you to keep all the required executables without having to keep any significant amount of the source code.

Define imports for each implantation subsystem

For each subsystem, define which other subsystems it imports. This can be done for whole sets of subsystems, allowing all subsystems in one layer to import all subsystems in a lower layer. Generally, the dependencies in the Implementation Model will mirror those of the Design Model, except where the structure of the Implementation Model has been adjusted (see Adjust Subsystems).

Present the layered structure of subsystems in component diagrams.

Decide placement of test subsystems and components

Unit Tests. Each Implementation Subsystem must contain a Test Subsystem which defines how to unit test the contents of the Implementation Subsystem (i.e. components). The contents of this Test Subsystem will include test plans, test scripts, test data, and test drivers for the subsystem to be tested.

Integration Tests. Integration occurs by successively building larger parts of the system. Integration subsets can be defined at any level, but generally occur along within higher-level subsystems and layers.

System Test. System tests evaluate the entire system. At the top-level of the system, there must be a Test Subsystem which defines how the system will be tested. The contents of this Test Subsystem will include test plans, test scripts, test data, and test drivers for the subsystem to be tested.

Decide where in the implementation model to place the test subsystems and test components, such as test automation tools, test procedures, input data and output data.

Update the implementation view

The Implementation View is described in the "Implementation View" section of Software Architecture Document. This section contains component diagrams that show the layers and the allocation of implementation subsystems to layers, as well as import dependencies between subsystems.