系统必然是复杂的，如何清晰准备的描述一个系统，是架构工作的困难之处。有两个架构观点，虽然各有侧重，但是殊途同归，都是软件架构的基本方法。需要注意的是，这两个架构观点对视图的定义和理解略有不同，视点应该就是视图。
“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).
根据角色列出利益相关者和他们关切如下：
视点
在系统设计过程中，有一些问题是绕不开的：架构的主要功能组件是什么?系统内组件之间是如何交互的?组件与外部如何交互?系统的信息如何管理，存储和表示?为了支持系统的这些功能，需要什么样的硬件和软件组件?需要提供什么的运维功能?需要提供哪些开发，测试，支持，培训环境?这么多问题，如何理出头绪?单一视角很难描述一个复杂系统架构。
和“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.
下面是一些视点及其定义，供参考。
视图
视点的方式本质是做减法，分割关注点，单点突破，而视图是用来做加法的，并且达到一加一大于二的效果。这就是架构的质量属性!由于用户对质量属性的漠视，架构往往成为项目管理铁三角中用来牺牲和放弃的对象。在软件实现过程中，质量属性也往往被作为非功能需求而放弃。而这往往是架构失败的根源。
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.
因此，视图期望提供一个质量属性框架，促使架构师重新审视架构中各个视点的设计和实现。也就是在视点中应用视图。
一些视图及其定义，供参考：
【本文是51CTO专栏作者石头的原创文章，转载请通过作者微信公众号补天遗石(butianys)获取授权】
