The implementation style maps modules of a module viewtype to a development infrastructure. Implementing a module always results in many separate files, such as those that contain the source code, files that have to be included and usually contain definitions, files that describe how to build an executable, and files that are the result of translating, or compiling, the module. Those files need to be organized so as not to lose control and integrity of the system. Configuration management techniques usually do this job: in the simplest case, a hierarchy of directories in a file system.
A view in the implementation style can also be much more elaborate, perhaps showing special configuration items for various kinds of modules, such as those items that need a specific test procedure. This usually requires a more sophisticated configuration management system that allows the definition of new configuration items and complex processes necessary to create new items in the structure.
5.4.2 Elements, Relations, and Properties
Table 5.3 summarizes the discussion of characteristics of the implementation style. Environmental elements in the implementation style are configuration items: files in a file system or primitives managed by the configuration management system. In the simplest case, those configuration items are directories for organizational purposes and files as containers for the information. The software elements are modules of any style of module viewtype, such as functions or classes.
Two relations in the implementation style are
|Properties of elements||
|Properties of relations||None|
|Topology||Hierarchical configuration items: is-contained-in|
As with the deployment style, the important properties of the software and enviromental elements of the implementation style are those that affect the allocation of the software to configuration items. For example, how a configuration management system deals with histories and branches is a configuration item property; a specific version of a Java compiler to use might be a property of a software module. A dependency that requires one module to be compiled before another is a property of a software module.
5.4.3 What the Implementation Style Is For and What It's Not For
The implementation style is used during development and at build time to manage and to maintain the files that correspond to software elements. Developers use this style to identify files that they can check for updating, testing, or system building; and to check back in new releases.
The implementation style can be used to specify the version differences of a particular system. This style can also be used to highlight those elements that are used for special purposes, such as testing, or to analyze the configuration management for a system.
5.4.4 Notation for the Implementation Style
Any notation for the implementation style must have modules, the configuration items, and the mapping between them. Ideally, icons are used to distinguish the configuration items from the modules. The decomposition of the configuration items should also be shown. Figure 5.5 shows an example of a small implementation view, rendered in an informal notation specialized to the style.
Figure 5.5. Implementation view in an informal notation. The configuration items are directories and files. The lines show containment. The allocation relation is shown as a name convention, not as an explicit line. Allocations as a name convention are frequently used and usually indicate missing tool support.
5.4.5 Relation to Other Styles
The implementation style is naturally most strongly related to the module styles that provide the software elements for the allocation.
5.4.6 Example of the Implementation Style
An implementation style is included in the NASA ECS example in Appendix A.
Software Architectures and Documentation
Part I. Software Architecture Viewtypes and Styles
The Module Viewtype
Styles of the Module Viewtype
The Component-and-Connector Viewtype
Styles of the Component-and-Connector Viewtype
The Allocation Viewtype and Styles
Part II. Software Architecture Documentation in Practice
Documenting Software Interfaces
Choosing the Views
Building the Documentation Package
Other Views and Beyond
Rationale, Background, and Design Constraints