软件架构对于复杂实时系统的开发已日益变得更加重要。在这个新的系列中，了解为什么以及应该如何编写软件架构文档说明。您将了解 为任何中大型软件开发项目编写文档说明的五个不同视图或方面。这是本系列中的第一篇文章，其中将介绍软件架构和文档说明的重要性。您还将概略了解将在后续 文章中介绍的体系结构视图。
引言
软件架构是一门学科，开始于 20 世纪 70 年代。面对不断增加的复杂性和开发复杂实时系统的压力，作为主流系统工程和软件开发的基本构造，软件架构应运而生。
与任何其他久经考验的学科一样，软件架构在诞生之初也面临许多挑战。软件架构表示系统的结构和行为方面。在早期为软件架构编写文档说明时，所使用的文本和 图解表达常常不足或者不够精确。所需的是某种一致并得到充分理解的伪（或元）语言，以便将对软件架构进行表示和编写文档说明的不同方式统一起来。在学术研 究的推动下，在用于开发有效软件架构文档说明的最佳实践和指导原则方面，工程和计算机科学领域已取得了长足的发展。
在本系列中，您将了解如何编写软件架构文档说明。了解编写文档说明的不同方面：系统上下文、体系结构概述、功能体系结构、操作体系结构和体系结构决策。
在这第一篇文章中，了解软件架构是什么，以及为该学科的不同方面编写文档说明的重要性。
  |
|
软件架构
不同的研究人员已解释了软件架构是什么，并且他们对有关如何最好地表示软件系统的体系结构具有不同的观点。其中没有哪一种解释是错误的；每种解释都具有自己的价值。Bass L 等人抓住了软件架构的本质：
“程序或计算系统的软件架构是该系统的结构，包括软件组件、那些组件的外部可见的属性，以及那些组件之间的关系” 。
此定义重点关注由粗粒度的构造（软件组件）所构成的体系结构，可以将这些构造看作是体系结构的构建块。每个软件组件或体系结构构建块具有某些外部可见的属 性，这是它向其他体系结构构建块公开的属性。软件组件的内部设计和实现细节不是系统的其他部分所关心的内容，系统的其他部分只是将某个特定组件视为一个黑 盒。该黑盒具有某些所公开的属性，其他软件组件可以使用这些属性来共同实现业务或 IT 目标。软件架构在恰当的粒度级别标识体系结构构建块。软件架构还标识那些构建块如何彼此相关，并进行文档记录。
与软件工程相关的体系结构涉及到将单个系统分解或划分为一组可迭代地、渐进地和独立地构造的部分。各个部分彼此具有显式的关系。当组合在一起时，各个部分就形成了系统、企业或应用程序的体系结构。
关于体系结构与设计之间的区别，存在一些混淆。正如 Clements P 等人 所指出的，所有体系结构都是设计，但不是所有设计都是体系结构。需要绑定以使系统满足其功能性和非功能性需求和目标的设计本质上是体系结构。体系结构将体 系结构构建块视为黑盒，而设计则处理体系结构构建块的配置、自定义和内部工作。体系结构将软件组件与其外部属性绑定在一起。设计通常要比体系结构松散得 多，因为它允许以更多的方式遵守组件的外部属性。设计还考虑用于实现组件内部细节的各种方法。
软件架构可以递归地使用。请考虑一个属于某个系统的软件架构组成部分的软件组件 (C1)。软件架构师将该组件及其应该公开的属性、功能和非功能特性及其与其他软件组件的关系交给系统设计人员。设计人员在分析软件组件 C1 之后，决定将该组件分解为更细粒度的组件（C11、C12 和 C13），其中每个组件提供可重用的功能，这些功能将用于实现 C1 的要求属性。设计人员详细设计了 C11、C12、C13 及其接口。
此时，对设计人员来说，C11、C12 和 C13 是体系结构构造（或组件）；其中每个构造具有显式定义的外部接口。对设计人员来说，C11、C12 和 C13 是软件组件 C1 的体系结构，并且这些构造需要进一步的改进和设计，以处理它们的内部实现。通过将大型、复杂的系统划分为小型的构成部分并集中于每个部分，可以递归地使用 体系结构。
体系结构使用共同满足行为和质量目标的体系结构构建块将系统绑定在一起。参与者必须能够理解体系结构。因此必须为体系结构编写足够的文档说明，下一个部分将对此进行讨论。
|
|
编写体系结构文档说明的重要性
|
|
向参与者传达您正在构建的系统蓝图的关键是为系统体系结构编写文档说明。软件架构通过不同的视图进行表示——功能、操作、决策等等。没有任何单一视图能够表示整个体系结构。并非所有视图都需要表示特定企业或问题领域的系统体系结构。架构师将确定足以表示所需软件架构范畴的视图集。
通过编写不同视图的文档说明并捕获每个部分的开发，您可以向开发团队和业务及 IT 参与者传达有关该不断发展的系统的信息。软件架构具有一组其预期要满足的业务和工程目标。体系结构的文档说明可以向参与者传达这些目标将如何实现。
为体系结构的各个方面编写文档说明，有助于架构师弥补用白板描述解决方案（使用框线图方法）与以对下游设计和实现团队有意义的方式表示解决方案之间众所周知的差距。体系结构的框线图留下了大量有待解释的空间。需要揭示的细节通常隐藏并令人混淆地固守在那些框线背后。
文档说明还可以促进创建切合实际并且可以系统开发（例如遵循标准模板）的体系结构构件。作为一门学科，软件架构是非常成熟的。您可以利用最佳实践和指导原 则来为每种视图创建标准模板，以表示体系结构的某个部分或范畴。模板可以为架构师提供有关需要实际产生什么结果的训练。并且模板还可以帮助架构师执行强化 训练——超越框线图技术。模板以更具体的术语定义体系结构，因此可直接追溯到解决方案预期要满足的业务和 IT 目标。
由于复杂性，典型的系统开发活动可能要花 18 个月左右的时间。人员缩减在设计和开发团队是司空见惯的事情，从而导致疯狂寻找恰当的替换人员。新的团队成员通常阻碍进度，因为他们必须经历一个学习过程才能成为高效的参与者。具有良好文档说明构件的软件架构可以提供：
- 对新团队成员进行有关解决方案需求教育的完美平台。
- 有关解决方案如何满足业务和工程目标的说明。
- 特定于问题领域的各种解决方案体系结构视图。
- 对个人将处理的视图的重点关注。
请考虑一个名为“体系结构决策”的假想构件（后续部分还将对此进行讨论）。此构件确定要解决的问题，并评估备选机制以解决该问题。此构件对为什么选择某种备选机制而不选择其他机制提供了论证。
所 确定的问题涉及到访问大型机 IBM DB2® 表的机制。对两种备选机制进行了评估：使用 IBM MQSeries®，或者使用 NEON Shadow Direct 适配器（一种供应商适配器）。尽管 MQSeries 具备相关功能并且花费较少，但是后者要稳定得多，并且在制定决策时，后者具有一定的优势。现在设想原架构师在一年后离开了该项目，新的架构师粉墨登场。新 的架构师质问该团队为什么不使用 IBM MQSeries 来访问大型机 DB2 表。该团队很快返回到体系结构决策构件，并指出了做出该选择的原因。由于 IBM MQSeries 已在过去一年中经测试证明与另一个解决方案不相上下，并且由于其价格较低，于是对该决策进行了重新审视并做出更改以反映更新后的解决方案。
这个示例说明了为什么对系统软件架构的各个方面编写文档说明，是教育新团队成员和在最少的停机情况下帮助他们入门所必需的。
|
|
体系结构的不同视图
您已经了解到可以通过不同的视图来表示体系结构，每种视图集中于该体系结构的特定方面或范畴。正如 Bass L 等人 所指出的，视图 是由系统参与者编写和读取的体系结构元素或构造以及它们之间关系的内聚集合。
体系结构的功能 视图描述各个体系结构构建块、构建块之间的关系，以及如何将它们分配到体系结构中的不同层。操作 视图（也称为技术视图）描述各个基础结构和中间件软件组件，这些组件为将要部署的功能体系结构组件提供运行时平台。对应用程序架构师而言，功能视图具有第一位的重要性。对基础结构架构师而言，操作视图是要重点关注的视图。
这两种视图采用不同的方法解决相同的问题，两种视图都需要从概念体系结构推进到物理实现。视图用于强调特定的体系结构范畴，同时有意地抑制其他范畴。
自从 20 世纪 90 年代以来，已经存在许多不同的视图集。Perry 和 Wolf 提出，关于构建具有多种视图的体系结构（包括软件架构），存在一些非常有趣的要点。发表软件架构的 4 + 1 视图的 Kruchten 认为存在五种视图，这些视图组合起来可以表示软件架构。下面将描述前四种视图。
| 视图 | 描述 |
|---|---|
| 逻辑视图 | 处理静态设计模型 |
| 流程视图 | 处理设计的动态视图 |
| 物理视图 | 处理如何将软件组件映射到硬件基础设施 |
| 开发视图 | 表示软件组件在开发时环境中的静态组织 |
第五种视图更多的是一种 Litmus Test 视图。它采用一组在体系结构上非常重要的用例（业务场景），并说明如何将四种视图的每一种视图中的体系结构元素集与针对那些元素的体系结构约束和决策结合起来，用于实现那些用例。
由 Soni 等人 在 Applied Software Architecture 中发表的另一种视图由四种构成软件架构的主要视图组成：
| 视图 | 描述 |
|---|---|
| 概念体系结构视图 | 从主要设计元素及元素间的关系方面描述系统 |
| 模块互连体系结构视图 | 描述功能分解和如何在不同的层中安排软件模块 |
| 执行体系结构视图 | 描述系统的动态结构 |
| 代码体系结构视图 | 描述如何在开发环境中组织源代码、二进制文件和库 |
软件架构出版物中描述了许多其他视图，但是介绍所有这些视图超出了本文的范围。对软件架构的不同视图进行仔细分析后表明，不同的研究结果之间存在大量的相似性。我们拥有一个最常用于表示系统软件架构的最优视图集合。
下一个部分将提供一些构件的概述，建议将这些构件用作可在软件开发生命周期的体系结构阶段生成的体系结构文档的最小集。
|
|
文档说明对象
可以对软件架构的许多不同视图或方面做文档说明。对于任何中大型软件开发项目，建议您至少为以下体系结构构件集编写文档说明：
- 系统上下文
-
系统上下文对表示为黑盒的整个系统如何与外部实体（系统和最终用户）交互做文档说明。它还定义系统与外部实体之间的信息和控制流。
系统上下文用于对系统所在的操作环境进行澄清、确认和编写文档说明。外部系统的性质、其接口以及信息和控制流对体系结构中的技术构件的下游规范有帮助。
- 体系结构概述
-
体系结构概述通过简单的图示表示形式说明体系结构中的主要概念元素和关系。您可以产生包括企业视图和 IT 系统视图的体系结构概述关系图。概述帮助表示组织所需要的业务和 IT 功能。
体系结构概述还提供了简要图表，功能和操作体系结构中将对这些图表做进一步的详述和文档说明。并且体系结构概述还描述了企业在 IT 系统方面的战略方向。
- 功能体系结构
-
功能体系结构构件也称为组件体系结构或模型，用于说明如何将体系结构分解为提供软件组件逻辑分组的 IT 子系统。
功能体系结构从以下方面描述 IT 系统的结构：IT 系统的软件组件的职责、接口、静态关系和协作来交付组件所需功能的方式。此构件在各个细化阶段中迭代地进行开发。
- 操作体系结构
-
操作体系结构构件表示计算机系统的网络，这些系统支持解决方案的某些性能、可伸缩性和容错等需求。此构件还运行中间件、系统软件和应用程序软件组件。
此构件在各个细化阶段中迭代地进行开发。
- 体系结构决策
-
体系结构决策构件提供了对所有在体系结构上相关的决策编写文档说明的单一位置。决策通常涉及到但不限于：
- 系统的结构。
- 标识中间件组件以支持集成需求。
- 将功能分配到每个体系结构组件（体系结构构建块）。
- 将体系结构构建块分配到体系结构中的各个层。
- 遵守标准。
- 选择技术以实现特定的体系结构构建块或功能组件。
- 问题的确定。
- 各种解决方案的评估，包括优点和缺点。
- 选定的解决方案，包括足够的论证和其他将对下游设计和实现有帮助的相关详细信息。
本系列的其余部分将讨论如何对软件架构中的这五个构件编写文档说明。
|
|
结束语
软件架构已经存在 30 多年了。过去几十年已见证了软件工程方面的大量工作。软件架构师在设计满足企业的业务、工程和 IT 目标的解决方案中起着中流砥柱的作用。为软件架构编写文档说明是极其重要的。您可以使用文档说明，就某个正在发展的系统与参与者进行交流。文档说明对于使 新的团队成员迅速投入工作也是非常有用的，因为新的团队成员可以在实现解决方案时使用体系结构透视图作为上下文和边界前提。
关于什么在性质上是体系结构，什么在性质上不是体系结构，以及应该对系统的哪些方面做文档说明，一直存在大量的混淆。体系结构模板定义并标准化每种类型的构件中的内容，支持采用一致的方法来对软件架构编写文档说明。
在本文中，您了解了作为一门学科的软件架构，并了解了对体系结构的基本元素编写文档说明的重要性。您还阅读了建议作为文档说明最小集的体系结构构件的概述。请继续关注本系列的其他文章，它们将详述如何使用一组指导原则，以及如何对每个构件编写文档说明。