论软件架构（software architecture）

题目： 论软件架构（software architecture）

——软件架构建立过程分析

定义的架构

我们对于“架构”的定义没有缺陷。甚至存在支持定义集的网站。1 文中的定义来自IEEE标准 1472000，IEEE对强软件系统的架构描述的推荐实践，参见IEEE 1471。2 定义如下，其中重要部分用粗体字表示。

架构是在组件，彼此间和与环境间的关系，引导设计发展原则中体现的系统的基本结构。[IEEE 1471]

软件架构（software architecture）是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连接通常用接口(计算机科学)来实现。

软件体系结构是构建计算机软件实践的基础。与建筑师设定建筑项目的设计原则和目标，作为绘图员画图的基础一样，一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。

在“软件构架简介”中，David GArlan 和 Mary Shaw 认为软件构架是有关如下问题的设计层次：“在计算的算法和数据结构之外，设计并确定系统整体结构成为了新的问题。结构问题包括总体组织结构和全局控制结构；通信、同步和数据访问的协议；设计元素的功能分配；物理分布；设计元素的组成；定标与性能；备选设计的选择。”

但构架不仅是结构；IEEE Working Group on Architecture 把其定义为“系统在其环境中的最高层概念”。构架还包括“符合”系统完整性、经济约束条件、审美需求和样式。它并不仅注重对内部的考虑，而且还在系统的用户环境和开发环境中对系统进行整体考虑，即同时注重对外部的考虑。

架构的目标是什么

正如同软件本身有其要达到的目标一样，架构设计要达到的目标是什么呢？一般而言，软件架构设计要达到如下的目标：

• 可靠性（Reliable）。软件系统对于用户的商业经营和管理来说极为重要，因此软件系统必须非常可靠。

• 安全行（Secure）。软件系统所承担的交易的商业价值极高，系统的安全性非常重要。

• 可扩展性（SCAlable）。软件必须能够在用户的使用率、用户的数目增加很快的情况下，保持合理的性能。只有这样，才能适应用户的市场扩展得可能性。

• 可定制化（CuSTomizable）。同样的一套软件，可以根据客户群的不同和市场需求的变化进行调整。

• 可扩展性（Extensible）。在新技术出现的时候，一个软件系统应当允许导入新技术，从而对现有系统进行功能和性能的扩展

• 可维护性（MAIntainable）。软件系统的维护包括两方面，一是排除现有的错误，二是将新的软件需求反映到现有系统中去。一个易于维护的系统可以有效地降低技术支持的花费

• 客户体验（Customer Experience）。软件系统必须易于使用。

• 市场时机（Time to Market）。软件用户要面临同业竞争，软件提供商也要面临同业竞争。以最快的速度争夺市场先机非常重要。

架构的种类

根据我们关注的角度不同，可以将架构分成三种：

• 逻辑架构、软件系统中元件之间的关系，比如用户界面，数据库，外部系统接口，商业逻辑元件，等等。

逻辑架构中系统被划分成三个逻辑层次，即表象层次，商业层次和数据持久层次。每一个层次都含有多个逻辑元件。比如WEB服务器层次中有HTML服务元件、Session服务元件、安全服务元件、系统管理元件等。

• 物理架构、软件元件是怎样放到硬件上的。

描述了一个分布于北京和上海的分布式系统的物理架构，所有的元件都是物理设备，包括网络分流器、代理服务器、WEB服务器、应用服务器、报表服务器、整合服务器、存储服务器、主机等等。

• 系统架构、系统的非功能性特征，如可扩展性、可靠性、强壮性、灵活性、性能等。

系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识，这一工作无疑是架构设计工作中最为困难的工作。

此外，从每一个角度上看，都可以看到架构的两要素：元件划分和设计决定。

首先，一个软件系统中的元件首先是逻辑元件。这些逻辑元件如何放到硬件上，以及这些元件如何为整个系统的可扩展性、可靠性、强壮性、灵活性、性能等做出贡献，是非常重要的信息。

其次，进行软件设计需要做出的决定中，必然会包括逻辑结构、物理结构，以及它们如何影响到系统的所有非功能性特征。这些决定中会有很多是一旦作出，就很难更改的。

根据经验，一个基于数据库的系统架构，有多少个数据表，就会有多少页的架构设计文档。比如一个中等的数据库应用系统通常含有一百个左右的数据表，这样的一个系统设计通常需要有一百页左右的架构设计文档。

逻辑架构分析

    “三层结构”一词中的“三层”是指：“表现层”、“中间业务层”、“数据访问层”。其中：

• 表　现　层：位于最外层（最上层），离用户最近。用于显示数据和接收用户输入的数据，为用户提供一种交互式操作的界面。

• 中间业务层：负责处理用户输入的信息，或者是将这些信息发送给数据访问层进行保存，或者是调用数据访问层中的函数再次读出这些数据。中间业务层也可以包括一些对“商业逻辑”描述代码在里面。

• 数据访问层：仅实现对数据的保存和读取操作。数据访问，可以访问数据库系统、二进制文件、文本文档或是XML文档。

三层结构是一种严格分层方法，即数据访问层只能被业务逻辑层访问，业务逻辑层只能被表示层访问，用户通过表示层将请求传送给业务逻辑层，业务逻辑层完成相关业务规则和逻辑，并通过数据访问层访问数据库获得数据，然后按照相反的顺序依次返回将数据显示在表示层。有的三层结构还加了Factory、Model等其他层，实际都是在这三层基础上的一种扩展和应用。

构架描述

为了讨论和分析软件构架，必须首先定义构架表示方式，即描述构架重要方面的方式。在 Rational Unified Process 中，软件构架文档记录有这种描述。

• 构架视图

我们决定以多种构架视图来表示软件构架。每种构架视图针对于开发流程中的涉众（例如最终用户、设计人员、管理人员、系统工程师、维护人员等）所关注的特定方面。

构架视图显示了软件构架如何分解为构件，以及构件如何由连接器连接来产生有用的形式 [PW92]，由此记录主要的结构设计决策。这些设计决策必须基于需求以及功能、补充和其他方面的约束。而这些决策又会在较低层次上为需求和将来的设计决策施加进一步的约束。

• 典型的构架视图集

构架由许多不同的构架视图来表示，这些视图本质上是以图形方式来摘要说明“在构架方面具有重要意义”的模型元素。在 Rational Unified Process 中，您将从一个典型的视图集开始，该视图集称为“4+1 视图模型”[KRU95]。它包括：

用例视图：包括用例和场景，这些用例和场景包括在构架方面具有重要意义的行为、类或技术风险。它是用例模型的子集。逻辑视图：包括最重要的设计类、从这些设计类到包和子系统的组织形式，以及从这些包和子系统到层的组织形式。它还包括一些用例实现。它是设计模型的子集。实施视图：包括实施模型及其从模块到包和层的组织形式的概览。 同时还描述了将逻辑视图中的包和类向实施视图中的包和模块分配的情况。它是实施模型的子集。进程视图：包括所涉及任务（进程和线程）的描述，它们的交互和配置，以及将设计对象和类向任务的分配情况。只有在系统具有很高程度的并行时，才需要该视图。在 Rational Unified Process 中，它是设计模型的子集。配置视图：包括对最典型的平台配置的各种物理节点的描述以及将任务（来自进程视图）向物理节点分配的情况。只有在分布式系统中才需要该视图。它是部署模型的一个子集。构架视图记录在软件构架文档中。您可以构建其他视图来表达需要特别关注的不同方面：用户界面视图、安全视图、数据视图等等。对于简单系统，可以省略 4+1 视图模型中的一些视图。

一个架构可以平衡涉众需求

架构是为了实现涉众的需要而创造的。但是，一般来说不可能满足所有的需求。例如，涉众可能会问特定的时间框的功能，但是这两方面（功能和时间框）是互斥的。或者为了满足时间表而减少范围或者所有的功能可以扩展时间框实现。类似的，不同的涉众之间可能有相互冲突的需求，所以应满足适当的平衡性。所以作折中是构建进程的主要方面，且妥协是架构的重要属性。

仅仅提供一个任务的例子，考虑如下涉众群各自的所需：

• 最终用户关心直觉，正确的行为，性能，可靠性，可用性，有效性和安全性。

• 系统管理员关注直觉行为，管理和辅助监测。

• 业务人员关注有竞争力的特性，市场的时效性，对于其他产品的定位和开销。

• 客户关注开销，稳定性和计划性。

• 开发者关注清晰的需求和简单而一致的设计方法。

• 项目经理关注追踪项目，计划，资源的生产使用和预算的可预见性。

• 维护人员关注易理解性，一致性，和文档化的设计方法，与易修改性。

正如表中可看到的，对于架构师的另一个挑战是涉众群不仅仅关注系统所提供的需求功能。他们所关注的在实际中是不起作用的，因为在系统中他们不发生作用。（例如，关于成本和计划的关注）但是这些关注体现了系统质量或局限。非功能需求经常是架构师所关注的最重要的需求。

一个架构基于基本原理体现决策

一个架构的重要部分不仅仅是最终结果，架构本身，而是他为什么是如此的原因。因此，确信你已把使用这个架构和原因文档化就非常重要了。

这个信息与许多涉众都有关系，尤其是那些维护系统的人。这些信息对需要参考设计理由的架构师来说非常有价值，因为他们可以省去不必要的步骤。例如，当需要重复架构和架构师重新审视所做的决定时，这些信息非常有用。

一个架构影响团队结构

架构定义了一组连贯的相关元素。例如，顺序进程系统架构可能已定义了一组次序入口，计数管理，客户管理，实现，外部系统集成，持续性和安全性。

每一组都会要求不同的技术。因此，一旦被定义好，统一软件开发小组结构就非常有意义了。但是，情况经常是最初的小组结构影响了构架，而不是相反情况。因为结果通常都是一个不太理想的架构。“康威规律” 规定“如果你有4个编译小组，那你会有4路编译器”。 实际上，我们经常会无意识地创建架构，以反映创建架构的组织。

但是，完全从实际出发，事实上这种有点理想的观点经常是不实际的，因为当前小组结构和技术都有实际可能的限制，并且架构师必须考虑在内。

一个架构呈现在每一个系统中

每个系统都有一个架构，即使这个架构没有被文档化，或者如果系统非常简单且包含单一元素。对架构文档化很有价值。文档化的架构比没有的考虑的更周全——因此也更有效，所以根据架构的进程可以更细致的考虑。

相反地，如果架构没有文档化，那么很困难来证明满足了诸如可维护性，最佳适应性等的需求。似乎大部分现今存在的无文档的架构都有些随意性而不是目的性。

一个架构拥有一个特定的范围

有许许多多种架构，最著名的是与建筑和其他工程相关的。甚至在软件工程领域，我们经常会遇到不同形式的架构。例如，除了软件构架的概念，我们会遇到诸如企业架构，系统架构，组织架构，信息架构，硬件架构，应用架构，基础设施架构等。你会见到其他类型的，每种类型都定义了一个架构的具体范围。

不幸的是，产业界没有相互形式间的协定，所以导致了对同一形式的不同意思。但是，从图3中可以推断出这些形式的范围。当你们在考虑和讨论下面这张图的时候，你肯定会发现很多你不同意的元素或是在你们的组织中不同的使用方法。但是重要的是——这些形式的确存在，却没有一致的观点。

不同领域的范围

上图展示的元素有：

• 软件架构——这篇文章主要的关注点。

• 硬件架构——包括CPU, 内存，硬盘，周边设备例如打印机，与连接这些元素的部分。

• 组织架构——是一些关于商业进程，组织结构，规则和职责，与组织核心能力的部分。

• 信息架构——包含组织好的信息结构。

• 软件架构，硬件架构，组织架构和信息架构是全部系统架构的子结构。

• 企业架构，与系统架构很相似，包括硬件，软件，人员等。但是，企业架构与商业有很强的联系，因为它专注于商业对象的联系，专注于商业敏捷性和组织效率。企业架构可能穿插于公司间。

正像人们期盼的那样，有相应形式的架构师（例如软硬件架构师等）和架构（例如，软硬件架构等）。

现在我们已浏览过这些定义了，但还有很多未回答的问题。企业架构与系统架构间有什么不同？一个企业是一个系统？信息架构与数据集成软件应用中的数据架构是一样的？不幸的是，没有对这些问题的一致的答案。

对现在来说，你会意识到这些不同，但是产业界不存在对这些内容的一致定义。因此，对你的建议只是选择那些与你的组成相似的形式并且合适的定义他们。至少你会获得某些一致性，并减少错误传达的可能。

架构师

软体设计师中有一些技术水平较高、经验较为丰富的人，他们需要承担软件系统的架构设计，也就是需要设计系统的元件如何划分、元件之间如何发生相互作用，以及系统中逻辑的、物理的、系统的重要决定的作出。

这样的人就是所谓的架构师（Architect）。在很多公司中，架构师不是一个专门的和正式的职务。通常在一个开发小组中，最有经验的程序员会负责一些架构方面的工作。在一个部门中，最有经验的项目经理会负责一些架构方面的工作。

但是，越来越多的公司体认到架构工作的重要性，并且在不同的组织层次上设置专门的架构师位置，由他们负责不同层次上的逻辑架构、物理架构、系统架构的设计、配置、维护等工作。

总结

架构是宏观上的。定义构成一个系统的各个组成部分。比如基于J2EE的三层架构：WEB层，应用中间层及数据层，从宏观上定义系统的各个组成部分。

这篇文章关注于定义软件架构的核心特性以及软件架构建立的过程分析。

                                            NIIT印度国家信息技术学院

                                                     郭 鹏

2008-6-11