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 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.

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 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.