软件架构的视点，视图及利益相关者
系统必然是复杂的，如何清晰准备的描述一个系统，是架构工作的困难之处。有两个架构观点，虽然各有侧重，但是殊途同归，都是软件架构的基本方法。
“4+1”视图模型
面对复杂和不确定的业务需求，为了避免盲人摸象的局面，使用视图和视点的方法是比较有效的。Philippe Kruchten在他的文章《Architectural Blueprints—The “4+1” ViewModel of Software Architecture》详细介绍“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 |