Siemens Four Views
The Siemens approach uses four views to document an architecture. The four views and their associated design tasks are shown in Figure 11.1. The first task for each view is global analysis. The second and third groups of tasks are the central and final design tasks, which define the elements of the architecture view, the relationships among them, and important properties.
Figure 11.1. The Siemens Four Views approach to software architecture (Adapted from Hofmeister, Nord, and Soni 2000, p. 20)
11.4.1 Global Analysis
In global analysis, you identify the factors that influence the architecture and analyze them to derive strategies for designing the architecture. This provides supporting documentation that captures the analysis of the factors that influence the architecture and the rationale for why the design decisions reflected in the view were made.
11.4.2 Conceptual Architecture View
The conceptual architecture view explains how the system's functionality is mapped to components and connectors. This view is closest to the application domain because it is the least constrained by the software and hardware platforms. Documenting the conceptual architecture view can be done by using the C&C viewtype. There is a close correspondence between the Siemens terminology and our terminology (see Table 11.7).
| Siemens Four Views | Our Term | |
|---|---|---|
| Elements | CComponent | Component |
| CPort | Port | |
| CConnector | Connector | |
| CRole | Role | |
| Protocol | Protocol | |
| Relations | Composition | Decomposition |
| Cbinding | Binding | |
| Cconnection | Attachment | |
| Obeys, obeys congugate | Element property |
11.4.3 Module Architecture View
The module architecture view explains how the components, connectors, ports, and roles are mapped to abstract modules and their interfaces. The system is decomposed into modules and subsystems. A module can also be assigned to a layer, which then constrains its dependencies on other modules.
Documenting the module architecture view can be done by using the module viewtype. There is a close correspondence between the Siemens terminology and our terminology. To describe the relationships between elements of the conceptual view and the module view, the mapping, as discussed in Section 6.3, should be documented. See Table 11.8.
| Siemens Four Views | Our Term | |
|---|---|---|
| Elements | Module | Module |
| Interface | Interface | |
| Subsystem | Subsystem | |
| Layer | Layer | |
| Relations | Contain | Aggregation |
| Composition | Decomposition | |
| Use | Uses, allowed to use | |
| Require, provide | Element property | |
| Implement (module: conceptual element) | Cross-view mapping | |
| Assigned to (module: layer) | Property of a layer |
11.4.4 Execution Architecture View
The execution architecture view explains how the system's functionality is mapped to runtime platform elements, such as processes and shared libraries. Platform elements consume platform resources that are assigned to a hardware resource.
Documenting the execution architecture view can be done by using the communicating-processes style of the C&C viewtype and the deployment style of the allocation viewtype. To describe an execution configuration in the execution architecture view, start with the components in the communicating-processes styletask, process, threadand connectors, based on the communication connector. Add or refine existing component types for runtime entities: queue, shared memory, DLL, socket, file, and shared library. The communication connector is extended to include a use-mechanism relation to possible communication mechanisms, such as IPC, RPC, or DCOM. Use the deployment style as a guide to describe the execution configuration mapped to hardware devices. To describe the relationships between elements of the module view and the execution view, the mapping, as discussed in Section 6.3, should be documented. See Table 11.9.
| Siemens Four Views | Our Term | |
|---|---|---|
| Elements | Runtime entity | Concurrent units: task, process, thread |
| Communication path | Communication: data exchange, control | |
| Relations | Use mechanism | |
| Communicate over | Attachment relation | |
| Assigned to (module: runtime entity) | Cross-view mapping |
11.4.5 Code Architecture View
The code architecture view explains how the software implementing the system is organized into source and deployment components. Documenting the code architecture view can be done by using the implementation style of the allocation viewtype. To describe the code architecture view, start with the packaging units, such as files and directories, in the implementation style to describe the source components and their allocation in the development environment. You will need to create new styles in the module and allocation viewtypes for describing the other elements for intermediate and deployment components, their relations, and how they are organized and packaged in the development environment. To describe the relationships between elements of the execution view and the executable elements in the code view, the mapping, as discussed in Section 6.3, should be documented.
11.4.6 Summary
If you wish to use views prescribed by the Siemens Four Views approach, you can do so as shown in the following list:
| To Achieve This Siemens Four Views View | Use This Approach |
|---|---|
| Conceptual architecture | One or more styles in the C&C viewtype |
| Module architecture | One or more styles in the module viewtype |
| Execution architecture | Deployment style in the allocation viewtype; for processes, communicating-processes style in the C&C viewtype |
| Code architecture | Implementation style in the allocation viewtype |
Like RUP, the Siemens Four Views approach does not preclude additional information, and so you are free toand shouldconsider what other views may be helpful to your project. And, as with RUP, these views form the kernel of the architecture only; you should complete the package by adding the supporting documentation for each view and the documentation beyond views, as discussed in Chapter 10.