Architectural Viewpoint Summary
The following summarizes the architectural viewpoints described in later chapters. These viewpoints are built by applying the various UML diagram types to specific architecture development tasks. Each viewpoint has specific modeling goals and stakeholders. Additionally, we have used the IEEE 1471 framework to describe the rationale for each of the viewpoints. These descriptions should assist those attempting to apply these viewpoints. Appendix A provides a detailed summary of these viewpoints.
The viewpoints in Table 1.1 provide a set of highly abstracted software descriptions. The ContextView provides a summary of the system boundary and the external entities that interact with the system. The analysis views provide an abstract set of entities focusedonmodelingtheproblemrather than the solution.
Table 1.1 Conceptual and analysis viewpoint summary
Viewpoint UML diagram type
Analysis Focused Class Describe system entities in response to a scenario. Often
referred to as a view of participating classes or VOPC.
Analysis Interaction Interaction Interaction diagram between objects for analysis.
Analysis Overall Class Combination of all classes from all focused analysis viewpoints.
Context Use Case Show the external system actors and the system under design.
Table 1.2 describes a set of viewpoints targeted at describing the software design. The Component, Component Interaction, and Component State Views provide a mapping of the logical runtime structures, their functionality, and their intercommunications.The Subsystem Interface Dependency View provides a visualization of subsystem dependencies and interfaces. The Layered Subsystem View provides a highly abstracted view of all the subsystems. Finally, the Logical DataView provides a description of data models shared between components.
Table 1.2 Logical design viewpoints
Viewpoint UML diagram type Description
Component Component Illustrate component communications.
Interaction Interaction Interactions among components.
Component State State/Activity State transition/activity diagram for a component or for a set of components.
Layered Subsystem Package Illustrate layering and subsystems design.
Logical Data Class Show critical data views used for integration.
Dependency Class Illustrate subsystem dependencies and interfaces.
The final set of viewpoints (Table 1.3) is focused on the environment and physical aspects of the software, such as database deployment, that can impact architectural qualities of the system. The Deployment View shows the mapping of hardware and software for distributed systems. The Physical Database View illustrates the physical deployment structures of databases. The Process View shows the execution threads of the system and often the mapping to components. The Process State View shows the dynamic states for a process.
Table 1.3 Environment/Physical viewpoint summary
Viewpoint UML diagram type Description
Deployment Deployment Mapping of software to hardware for distributed systems.
Physical Data Deployment Physical view of a particular database.
Process Deployment Show the processes of a particular system instance.
Process State State Show the dynamic states of a process.
Often, overall views of large software systems become overwhelming. An overall view usually requires architecture-size paper to print, which necessarily limits distribution and use. As a result, we sometimes describe a single viewpoint that covers both a ‘focused’ and ‘overall’ variation of a view. In these cases, a series of focused views is often developed as the basis for an overall view. However, if the stakeholders and intent of the focused and overall perspectives are different a new viewpoint is created. The idea of focusing a view is critical to enabling development of large systems. In Chapter 5, in the discussion of managing model complexity, we describe the focusing principles that underlie the derivation of many of these viewpoints. Specific projects might create other viewpoints using these principles.
Frequently several views will be used together. For example, in the design of components and interfaces it is common to create a Component View, a Component Interaction View, and a Component State View. A series of interaction views is then used to elaborate the details of the Component View and validate the component structure. The state view describes the overall dynamics of a collection of components without showing the details of the sequencing of operations.