《实用软件架构：从系统环境到软件部署 》——2.4 架构视图与架构视点

2.4　架构视图与架构视点

以软件架构为论题的书籍、文章、研究项目及相关刊物，都会带有各自的观点。不同的流派对架构有不同的看法，他们会按照各自的看法来做架构，并会将各自的做法加以推广。就本书的主题来说，笔者并不打算专门用一个章节把与软件架构有关的各种观点全都讲解一遍，而是只想展示下面的这种观点，因为笔者觉得它比较务实，而且运用起来较为流畅。

视图和视点

Philippe Kruchten (1995.11)率先开始使用视图（view）与视点（viewpoint）这两个概念，来表达业界对软件架构的各种关注。Kruchten是IEEE 1471标准的一位制定者，该标准明确规定了视图的定义，也引入了视点的概念。Kruchten在论文（参见2.6节）中，是这样来描述这两个概念的：

视点—视点是“一份规范书，用来描述构建视图和使用视图时所应依循的约定。它是一种模式或一份模板，用来确立视图的目标和受众，以及创建视图与分析视图所用的技巧，使得我们可以据此创建出不同的视图。”

视图—视图是“从某个角度对整个系统所做的一种表现，该角度是由一系列彼此相联系的关注点所确立的。”

IBM (n.d.)定义了一套列架构视点，这就是IBM IT System Viewpoint Library（IBM IT系统视点库）。笔者认为这套架构视点相当完备地涵盖了系统架构的各个方面。如图2-3所示，该视点库中包含4个基本视点和6个正交（cross-cutting）视点。

IBM IT System Viewpoint Library中的四个基本视点分别是：

需求（Requirement）—与该视点有关的模型元素，用来捕捉系统中的各种需求，包括业务需求、技术需求、功能需求以及非功能型需求。对于该视点来说，最为常见的捕捉手段是用例与用例模型。

解决方案（Solution）—与该视点有关的模型元素，用来确定一套可以满足相关需求及约束的解决方案。此视点可以细分为两种：

功能视点（Functional）—此视点所关注的模型元素，从本质上来说，都是结构方面的元素，我们不仅要把元素本身实现出来，而且还要把元素之间的（静态和动态）关系建立好，以便用这些元素来构建系统。一般来说，此视点的细节，是通过功能架构来捕捉的，本书第7章将会专门讲解功能架构。

操作视点（Operational）—此视点关注的是怎样用结构元素来构建目标系统，以及怎样把功能视图部署到（由网络、硬件、计算资源、服务器等所构成的）IT环境中。我们通常使用操作模型来捕获此视点的细节，本书第8章将会专门讲解操作模型。

确认（Validation）—通过此视点所建立的模型元素，主要用来评估系统的能力，以确保该系统能够体现出预定的功能，并且能够提供质量合格的服务。我们通常会把功能和非功能方面的测试用例当作验证标准，以判断该系统是否具备预定的能力。

从图2-3中可以看出，这4个基本视点是相互关联的。功能视点与操作视点，可以合起来实现需求视点，并为其提供支持，而这两个视点，又是通过确认视点得以验收的。为了把这张图画得明确一些，笔者并没有专门标出“解决方案”视点，而是直接把构成该视点的功能视点和操作视点画在了图中。

视点库中还有6个正交视点。在图2-3中，4个基本视点周围的那6个同心正方形，就是用来表示这6个视点的。笔者之所以用这样的方式来画图，是想表达这6个正交视点对一个或多个基本视点所造成的影响。

这6个正交视点分别是：

应用（Application）—该视点专注于满足系统所宣称的业务需求。对于该视点来说，应用架构师扮演着主要角色。

技术（Technical）—该视点关注的是硬件、软件、中间件（其定义请参阅第5章）以及打包的应用程序，这些内容合起来可以实现应用程序的功能，并使得应用程序能够运作。对于该视点来说，基础设施架构师和集成架构师扮演着主要角色。

系统管理（Systems Management）—该视点关注部署之后的管理、维护，以及系统的运作。对于该视点来说，应用维护和管理团队扮演着主要角色。

可用性（Availability）—该视点关注怎样才能把系统构建起来，并令其保持可用（比如，怎样才能使系统的正常运行时间达到总运行时间的99.5%），以便满足预先达成的服务级别协议。对于该视点来说，基础设施架构师扮演着主要角色，而应用架构师与中间件架构师，则会为前者的工作提供支持。

性能（Performance）—该视点关注的问题是，怎样令系统的性能可以满足预先达成的服务级别协议（比如，从用户发出请求到系统给出应答，这之间的平均延迟时间要控制在400毫秒以内）。对于该视点来说，应用架构师扮演着主要角色，而中间件架构师和基础设施架构师，则会为前者的工作提供支持。

安全（Security）—该视点关注的是安全方面的系统需求，例如单点登入（single sign-on）、数据传输协议的安全程度，以及防止入侵等。某些安全需求（例如单点登入）主要是由应用架构师来处理的，而确认数据协议（例如HTTPS协议、安全套接字协议）的安全程度以及防止网络入侵等需求，则主要由基础设施架构师来处理。

每一个基本视点和正交视点背后，都隐藏着很多细节。这些视点均各自对应于一套元素，这些元素合起来能够描述出自身的特征及职责。如果理解了这些元素，那我们就能够深入地观察到每个视点的实现方式。尽管隐藏在每个基本视点和正交视点背后的细节有很多，然而笔者此处所要强调的内容，是大家应该意识到它们的存在，并且意识到我们必须从其中的每一个视点或绝大部分视点来对系统的架构进行观察。这种意识很重要。

笔者曾经对很多视点框架做了研究，我感觉其中的绝大多数框架，在基本形式的层面都有着一些共性。之所以会有这种共性，其原因在于：每个框架都想要确立一套相互补充的视角，并且想通过这些视角来观察系统的架构，以便全面地覆盖架构中的各个方面。

我们需要在各种视点框架之间做出选择，或者说，我们至少要从那些特别成熟、特别稳固而且特别持久的视点框架中进行选择。在选择时，大家应该根据自己的需求以及使用视点框架时的舒适程度来进行判断。