A number of viewpoint-based architectural frameworks exist and a comprehensive list is available here: http://www.iso-architecture.org/42010/afs/frameworks-table.html. For software intensive systems some of the more commonly used viewpoint sets are as follows:
Kruchten’s 4 + 1 architecture view model
This approach forms the basis of the Rational Unified Process has a small set of fixed views defined, with viewpoints implied rather than being explicitly identified
The views of the model are concerned with:
- Logical view: The logical view is concerned with the functionality that the system provides to end-users. UML Diagrams used to represent the logical view include Class diagram, Communication diagram, Sequence diagram.
- Development view: The development view illustrates a system from a programmer’s perspective and is concerned with software management. This view is also known as the implementation view. It uses the UML Component diagram to describe system components. UML Diagrams used to represent the development view include the Package diagram.
- Process view: The process view deals with the dynamic aspects of the system, explains the system processes and how they communicate, and focuses on the runtime behavior of the system. The process view addresses concurrency, distribution, integrators, performance, and scalability, etc. UML Diagrams to represent process view include the Activity diagram.
- Physical view: The physical view depicts the system from a system engineer’s point of view. It is concerned with the topology of software components on the physical layer, as well as the physical connections between these components. This view is also known as the deployment view. UML Diagrams used to represent physical view include the Deployment diagram.
- Scenarios: The description of an architecture is illustrated using a small set of use cases, or scenarios which become a fifth view. The scenarios describe sequences of interactions between objects, and between processes. They are used to identify architectural elements and to illustrate and validate the architecture design. They also serve as a starting point for tests of an architecture prototype. This view is also known as use case view.
Views and Beyond – Documenting Software Architectures
The V&B approach, from the Software Engineering Institute, promotes a stakeholder-based view selection, but extends the concept to recognize that documentation beyond views is also essential to provide holistic insight into the overall design approach embodied by the architecture and the decision made in arriving at the architecture. The V&B approach takes a software centric stance and focuses on the structure of the software, the relationships between software components, and how the software relates to the external environment, it classifies views into 3 types:
- Module views – Modules represent a code-based way of considering the system. Modules are assigned areas of functional responsibility, and are assigned to teams for implementation. There is less emphasis on how the resulting software manifests itself at runtime. Module structures allow us to answer questions such as: What is the primary functional responsibility assigned to each module? What other software elements is a module allowed to use? What other software does it actually use? What modules are related to other modules by generalization or specialization (i.e., inheritance) relationships?
- Component-and-connector views – Here, the elements are runtime components (which are principal units of computation) and connectors (which are the communication vehicles among components). Component and connector structures help answer questions such as: What are the major executing components and how do they interact? What are the major shared data stores? Which parts of the system are replicated? How does data progress through the system? What parts of the system can run in parallel? How can the system’s structure change as it executes?
- Allocation views – These views show the relationship between the software elements and elements in one or more external environments in which the software is created and executed. Allocation structures answer questions such as: What processor does each software element execute on? In what files is each element stored during development, testing, and system building? What is the assignment of the software element to development teams?
Software Systems Architecture
A fairly comprehensive set of viewpoints for information systems development is defined in the Rozanski and Woods “Software Systems Architecture” set, and includes the following viewpoint definitions:
- Context Describes the relationships, dependencies, and interactions between the system and its environment (the people, systems, and external entities with which it interacts). Many architecture descriptions focus on views that model the system’s internal structures, data elements, interactions, and operation. Architects tend to assume that the “outward-facing” information — the system’s runtime context, its scope and requirements, and so forth – is clearly and unambiguously defined elsewhere. However, you often need to include a definition of the system’s context as part of your architectural description.
- Functional Describes the system’s functional elements, their responsibilities, interfaces, and primary interactions. A Functional view is the cornerstone of most ADs and is often the first part of the description that stakeholders try to read. It drives the shape of other system structures such as the information structure, concurrency structure, deployment structure, and so on. It also has a significant impact on the system’s quality properties such as its ability to change, its ability to be secured, and its runtime performance.
- Information Describes the way that the architecture stores, manipulates, manages, and distributes information. The ultimate purpose of virtually any computer system is to manipulate information in some form, and this viewpoint develops a complete but high-level view of static data structure and information flow. The objective of this analysis is to answer the big questions around content, structure, ownership, latency, references, and data migration.
- Concurrency Describes the concurrency structure of the system and maps functional elements to concurrency units to clearly identify the parts of the system that can execute concurrently and how this is coordinated and controlled. This entails the creation of models that show the process and thread structures that the system will use and the interprocess communication mechanisms used to coordinate their operation.
- Development Describes the architecture that supports the software development process. Development views communicate the aspects of the architecture of interest to those stakeholders involved in building, testing, maintaining, and enhancing the system.
- Deployment Describes the environment into which the system will be deployed, including capturing the dependencies the system has on its runtime environment. This view captures the hardware environment that your system needs (primarily the processing nodes, network interconnections, and disk storage facilities required), the technical environment requirements for each element, and the mapping of the software elements to the runtime environment that will execute them.
- Operational Describes how the system will be operated, administered, and supported when it is running in its production environment. For all but the simplest systems, installing, managing, and operating the system is a significant task that must be considered and planned at design time. The aim of the Operational viewpoint is to identify system-wide strategies for addressing the operational concerns of the system’s stakeholders and to identify solutions that address these.
Although primarily intended for enterprise architecture, TOGAF is used by some organisations for software projects. Here the concept of “domain” is sometimes used in a similar way to “viewpoint”, although this is not the correct use of domains, as they are defined as being the commonly accepted subsets of an overall enterprise architecture. The following are defined in TOGAF:
- The Business Architecture defines the business strategy, governance, organization, and key business processes.
- The Data Architecture describes the structure of an organization’s logical and physical data assets and data management resources.
- The Application Architecture provides a blueprint for the individual applications to be deployed, their interactions, and their relationships to the core business processes of the organization.
- The Technology Architecture describes the logical software and hardware capabilities that are required to support the deployment of business, data, and application services. This includes IT infrastructure, middleware, networks, communications, processing, standards, etc.
Archimate is a modelling language developed specifically for the needs of enterprise architecture, which has evolved to support the TOGAF framework. Archimate defines 18 standard viewpoints to cover enterprise architecture work, serving the needs of a wide set of stakeholders. The approach and its viewpoints are comprehensively documented in the documentation available via the Open Group’s Archimate website.