面对复杂和不确定的业务需求，为了避免盲人摸象的局面，使用视图和视点的方法是比较有效的。Philippe Kruchten在他的文章《Architectural Blueprints—The “4+1” ViewModel of Software Architecture》详细介绍“4+1”视图模型。在这个模型中，视图是指从不同的利益相关者的角度来描述系统，利益相关者可以是最终用户，开发者，也可以是项目经理。由此，4个视图就分别是逻辑视图，开发视图，进程视图和物理视图。另外“+1”的视图是选择一些用例和场景来描述架构。
A stakeholder inthe architecture of a system is an individual, team, organization, or classesthereof, having an interest in the realization of the system.
The architect must ensure that there isadequate stakeholder representation across the board, including nontechnologystakeholders (such as acquirers and users) and technology-focused ones (such asdevelopers, system administrators, and maintainers).
Oversee the procurement of the system or product
Oversee the system’s conformance to standards and legal regulation
Explain the system to other stakeholders via its documentation and training materials
Construct and deploy the system from specifications (or lead the teams that do this)
Manage the evolution of the system once it is operational
Design, deploy, and manage the hardware and software environments in which the system will be built, tested, and run
Build and/or supply the hardware, software, or infrastructure on which the system will run
Provide support to users for the product or system when it is running
Run the system once it has been deployed
Test the system to ensure that it is suitable for use
Define the system’s functionality and ultimately make use of it
It is not possible tocapture the functional features and quality properties of a complex system in asingle comprehensible model that is understandable by and of value to allstakeholders.
在“4+1”视图模型之后，IEEE Standard 1471更是通过标准的方式推广这种架构方法。
A viewpoint isa collection of patterns, templates, and conventions for constructing one typeof view. It defines the stakeholders whose concerns are reflected in theviewpoint and the guidelines, principles, and template models for constructingits views.
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.
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.
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.
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.
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.
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.
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.
An architectural perspective is a collection of activities,tactics, and guidelines that are used to ensure that a system exhibits aparticular set of related quality properties that require consideration acrossa number of the system’s architectural views.
The ability of the system to be used by people with disabilities
Availability and Resilience
The ability of the system to be fully or partly operational as and when required and to effectively handle failures that could affect system availability
The ability of the system to be designed, built, deployed, and operated within known constraints around people, budget, time, and materials
The ability of the system to be flexible in the face of the inevitable change that all systems experience after deployment, balanced against the costs of providing such flexibility
The ability of the system to be independent from any particular language, country, or cultural group
The ability of the system to overcome problems brought about by the absolute location of its elements and the distances between them
Performance and Scalability
The ability of the system to predictably execute within its mandated performance profile and to handle increased processing volumes
The ability of the system to conform to local and international laws, quasi-legal regulations, company policies, and other rules and standards
The ability of the system to reliably control, monitor, and audit who can perform what actions on what resources and to detect and recover from failures in security mechanisms
The ease with which people who interact with the system can work effectively