系统必然是复杂的，如何清晰准备的描述一个系统，是架构工作的困难之处。有两个架构观点，虽然各有侧重，但是殊途同归，都是软件架构的基本方法。需要注意的是，这两个架构观点对视图的定义和理解略有不同，视点应该就是视图。

“4+1”视图模型

面对复杂和不确定的业务需求，为了避免盲人摸象的局面，使用视图和视点的方法是比较有效的。Philippe Kruchten在他的文章《Architectural Blueprints—The “4+1” ViewModel of Software Architecture》详细介绍“4+1”视图模型。在这个模型中，视图是指从不同的利益相关者的角度来描述系统，利益相关者可以是最终用户，开发者，也可以是项目经理。由此，4个视图就分别是逻辑视图，开发视图，进程视图和物理视图。另外“+1”的视图是选择一些用例和场景来描述架构。

4+1视图模型

开发视图：开发视图是从程序员，以及软件管理的角度来描述系统。这个视图也被称为实现视图，往往使用UML组件图来描述系统构成。

逻辑视图：逻辑视图主要描述系统为最终用户提供的功能。一般对应于UML工具的类图，状态图等。

物理视图：物理视图是从一个系统工程师的角度来描述系统。这个视图关切软件组件在物理层拓扑结构以及组件之间的物理连接，通常也被称为部署视图。UML工具中称为部署图。

进程视图：进程视图处理系统的动态方面，比如系统的进程之间如何通信以及运行时的行为，比如并发，分布式，集成，性能，扩展性等。UML工具用活动图来表示。

场景视图：场景视图使用一些用例或者场景来描述进程和对象之间的交互，并且用来验证架构设计，也是架构原型的测试起点。

使用视点和视角与利益相关者合作

使用视点和视角与利益相关者合作的观点是由NickRozanski和Eoin Woods在《软件系统架构:使用视点和视角与利益相关者合作(原书第2版)》一书中阐述的。如果说有哪本书可以作为软件架构的教科书的话，那么非此书莫属。什么是架构？为什么架构在工作中至关重要？如何确定架构的利益相关者以及他们的关切？如何在实现和需求之间寻找平衡？如何和利益相关者沟通你的架构并且展示你的架构满足了他们需求？如何集中精力在架构关键点上而不牺牲性能和可靠性？作为架构师你最重要的活动是什么？这些问题，都会在书中获得答案。

全书的三个重要概念分别是视图，视点和利益相关者。利益相关者是构建系统的所有人，而这些人的需求是复杂多样，相互重叠甚至是相互冲突的。架构师的主要工作就是要知道如何与利益相关者一切工作，并且创造一个满足所有人需求的架构。视点（视角）是基于利益相关者的关切，结构化的描述架构和定义架构的方法。视图是视点的补充，主要作用是分割关切点，但主要关注跨结构的质量属性而不是结构本身。

利益相关者

架构的利益相关者不仅仅只是那些使用软件的人，包括构建，测试，运维等所有对软件系统有兴趣的人。

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

根据角色列出利益相关者和他们关切如下：

Acquirers

Oversee the  procurement of the system or product

Assessors

Oversee the  system’s conformance to standards and legal regulation

Communicators

Explain the  system to other stakeholders via its documentation and training materials

Developers

Construct and  deploy the system from specifications (or lead the teams that do this)

Maintainers

Manage the  evolution of the system once it is operational

Production  Engineers

Design,  deploy, and manage the hardware and software environments in which the system  will be built, tested, and run

Suppliers

Build and/or  supply the hardware, software, or infrastructure on which the system will run

Support Staff

Provide  support to users for the product or system when it is running

System  Administrators

Run the system  once it has been deployed

Testers

Test the  system to ensure that it is suitable for use

Users

Define the  system’s functionality and ultimately make use of it

视点

在系统设计过程中，有一些问题是绕不开的：

架构的主要功能组件是什么？

系统内组件之间是如何交互的？组件与外部如何交互？

系统的信息如何管理，存储和表示？

为了支持系统的这些功能，需要什么样的硬件和软件组件？

需要提供什么的运维功能？

需要提供哪些开发，测试，支持，培训环境？

这么多问题，如何理出头绪？单一视角很难描述一个复杂系统架构。

和“4+1”视图模型一样，视点就是用结构化的多视点方式来解决上面一连串问题。

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.

下面是一些视点及其定义，供参考。

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.

视图

视点的方式本质是做减法，分割关注点，单点突破，而视图是用来做加法的，并且达到一加一大于二的效果。这就是架构的质量属性！由于用户对质量属性的漠视，架构往往成为项目管理铁三角中用来牺牲和放弃的对象。在软件实现过程中，质量属性也往往被作为非功能需求而放弃。而这往往是架构失败的根源。

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.

因此，视图期望提供一个质量属性框架，促使架构师重新审视架构中各个视点的设计和实现。也就是在视点中应用视图。

视图

一些视图及其定义，供参考：

Accessibility

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

Development Resource

The  ability of the system to be designed, built, deployed, and operated within  known constraints around people, budget, time, and materials

Evolution

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

Internationalization

The  ability of the system to be independent from any particular language,  country, or cultural group

Location

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

Regulation

The  ability of the system to conform to local and international laws, quasi-legal  regulations, company policies, and other rules and standards

Security

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

Usability

The  ease with which people who interact with the system can work effectively