1.2 软件架构

关于什么是软件架构已经有很多论述。在这里我们采用《Software Architecture in Practice》（第3版）中软件架构的定义：

一个系统的软件架构是构成该系统所需结构的组合，它们由软件元素、元素之间的关系以及元素和关系两者的属性组成。

正如你将要看到的，我们的设计方法结合了这一定义，并帮助设计者创建出一个具有理想属性的软件架构。

1.2.1 软件架构的重要性

关于软件架构的重要性也已经有很多论述。同样，我们还是采用《Software Architecture in Practice》中的论述。我们注意到软件架构之所以重要有各种各样的原因，以及类似的多种多样的来自这些原因的各种后果：

❑ 架构会妨碍或支持系统质量属性的实现。

❑ 在架构中做出的决定允许你在系统发展的过程中分析改变的原因并管理它们。

❑ 对软件架构的分析使我们可以在系统开发的早期预测系统的质量。

❑ 书面记录的架构加强了利益相关者之间的沟通。

❑ 软件架构是最早的设计决策的载体，这些设计决策也是最基本、最难修改的。

❑ 软件架构定义了一系列的约束条件以及后续的实现。

❑ 软件架构会影响一个组织的结构，反之亦然。

❑ 软件架构能够为可改进甚至是一次性的原型设计提供基础。

❑ 软件架构是架构师和项目经理估算成本和进度的关键工件。

❑ 软件架构可以作为一个可转移、可重复使用的模型，该模型可以构成产品线的核心。

❑ 基于架构的开发专注于组件的组装，而不仅仅关注它们的创建过程。

❑ 通过限制软件架构的备选方案，架构师可以激发开发人员的创造性，减少设计和系统的复杂度。

❑ 软件架构可以为培养新的团队成员打基础。

如果一个软件架构因为以下这些原因而变得重要：它会影响组织的结构、系统的质量，以及参与它的创建者和改进者，那么一定要在设计这个关键工件时非常小心。可悲的是，大多数情况下往往不是这样的。软件架构经常“演变”或“突现”。虽然我们并不反对演变或突现，且强调不主张“大规模预先设计”，但除非是最简单的项目，不设计任何软件架构往往都是非常危险的。你愿意开车经过一座没有经过仔细设计的桥吗？或者你愿意坐在一架没有经过仔细设计的喷气式飞机上吗？当然不。但你每天使用的软件都是充满缺陷、昂贵、不安全、不可靠、容易出错和缓慢的，许多这些讨厌的特性本来都是可以避免的！

本书的核心信息是，软件架构设计不一定是困难或可怕的，它并不只是行家的专有领地。它不一定是昂贵的，不一定需要预先把所有的事情做完。我们的工作就是告诉你应该怎么做并让你相信这么做是在你的能力范围以内的。

1.2.2 生命周期活动

软件架构设计是软件架构生命周期的活动之一（图1.1）。在任何一个软件项目的生命周期中，该活动关注的都是将需求转化成设计然后再转化成实现。具体来说，软件架构师需要操心以下问题：

❑ 架构需求。在所有的需求中，有些需求在软件架构方面特别重要。这些软件架构方面的重要需求（architecturally significant requirement, ASR）不仅包含系统最重要的功能和需要考虑的约束条件，也包含了最重要的一点——质量属性，如高性能、高可用性、容易改进和铁甲一样的安全性。这些需求，以及一个明确的设计目的和其他可能永远不会被写下来或可能对外部利益相关者来说不可见的与软件架构有关的问题，将指导你对软件架构的结构和组件做出选择。我们将把这些软件架构方面的重要需求和关注点作为驱动因子，因为可以说是它们在驱动设计。

❑ 架构设计。设计是一种从需要的世界（需求）到解决方案的世界的转化。它在结构方面由代码、框架和组件组成。一个好的设计是满足了驱动因子的设计。软件架构设计是本书的关注点。

❑ 架构文档。结构的一些初步文件（或草图）应该作为软件架构设计的一部分来创建。然而，这个活动是指通过这些草图创建出一个更正式的文档。如果该项目比较小并且有一个先例，那么软件架构文档可能非常小的。与此相反，如果该项目比较大或者是需要分布式团队合作，又或者存在重大的技术挑战，那么在架构文档这个活动中的付出将会得到足够的回报。程序员经常拒绝和嘲笑编写文档，但是在其他工程领域，这是一个标准的、不容讨价还价的交付产出。如果你的系统足够大并且是任务关键的，它就应该被记录下来。在其他工程学科，一份“蓝图”——一些被记录下来的设计，是一个通往实现阶段和投入资源的绝对必要的步骤。

❑ 架构评估。与架构文档一样，如果你的项目不是一个简单的项目，那么无论是对自己还是对利益相关者，你都有义务来评估软件架构。这是为了确保做出的决策对于解决关键的需求是恰当的。你会提供代码而不测试吗？当然不会。同样地，你为什么会没有先“测试”设计就投入庞大的资源来充实你的软件架构呢？你可能需要在首次创建系统或者要对系统做一个大规模的重构时这么做。典型的架构评估是非正式和内部的，但对于真正重要的项目，最好是有一个由外部团队完成的正式的架构评估。

❑ 架构实现/一致性检查。最后，你需要实现你创建过（并且评估过的）的软件架构。作为一个软件架构师，你可能需要根据系统的发展和需求的演变来调整设计。这是正常的。除此之外，在实现过程中你的主要职责是保证代码与设计的一致性。如果开发人员没有切实地实现架构，他们可能会破坏你所设计的质量要求。让我们再一次参考一下其他工程领域是怎么做的。当我们浇筑一个新建筑物的混凝土地基时，直到地基首先被测试通过，我们才会修建地基以上的部分。这个测试通常是通过测试一个核心样本，以确保它足够强大、足够致密、没有水和燃气的泄漏以及其他问题。如果没有一致性检查，我们没有办法确保随后构建的产品的质量。

请注意，我们并没有在图1.1中提出一个特定的生命周期方法。模板<<前置的>>只是意味着一个活动一定要在之后的活动之前做。例如，如果你不了解需求，就不能进行设计活动，如果你还没有先做一些设计决策，就无法评估一个软件架构。

今天，大多数商业软件是使用某种形式的敏捷开发方法来开发的。上面提到的这些软件架构的活动都与敏捷开发实践兼容。软件架构师的问题不是“我应该使用敏捷开发还是做软件架构？”而是“有多少软件架构的工作我应该提前做好，有多少应该推迟到该项目的需求已经在一定程度上确定以后？”和“有多少软件架构需要我正式用文档记录，在什么时候记录？”在许多软件项目中敏捷开发和软件架构是一对快乐的伙伴。

我们将在第9章讨论架构设计以及各种软件生命周期的方法和过程模型，包括迭代开发之间的关系。