11.4 Siemens Four Views

Team-Fly     Documenting Software Architectures: Views and Beyond By Paul Clements, Felix Bachmann, Len Bass, David Garlan, James Ivers, Reed Little, Robert Nord, Judith Stafford Table of Contents Chapter 11.  Other Views and Beyond 11.4 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). Table 11.7. Siemens Four Views conceptual architecture view   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. Table 11.8. Siemens Four Views module architecture view   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 style�task, process, thread�and 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. Table 11.9. Siemens Four Views execution architecture view   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 to�and should�consider 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. Team-Fly     Top