第9章 · 播客 第11集
软件架构设计 · 架构设计与文档化：ADD与七条规则
🎙️ 本集播客：第11集：架构模式与战术的关系收口、演变交付生命周期、ADD 属性驱动设计法的输入与三步、按架构组织团队与骨架系统；架构文档化的使用者、七条编档规则、视图编档七部分与跨视图文档，以及架构重构四活动。 语音由微软 Edge 神经网络语音预生成（女声·晓伊，男声·云希）。点击下方任意对话可直接从该句开始播，当前句朗读时下一句已预先加载，无缝衔接。
明
阿明
师姐，前面说过「战术是砖、风格是墙」，9.6 节是不是把这话坐实了？
雅
小雅
对，原文原话：战术可以看做设计的基本「构建块」，通过这些构建块就可以精心设计系统的软件架构了。架构模式也称为架构风格，它是适当地选取战术的结果，这些固定的结果即模式在高层抽象层次上具有普遍实用性和复用性。通过架构模式，架构设计师可以借鉴和复用他人的经验，但不要把模式看成是一个硬性的解决方法，它只是一种解决问题的思路。原文还引了 Martin Fowler 的话：「模式和业务构件的区别就在于模式会引发你的思考。」这句引言本身就能出判断题。
雅
小雅
先讲演变交付生命周期。业界已开发出各种软件生命周期模型，其中把架构放在一个适当位置的典型模型是演变交付生命周期模型。在其中，架构设计就是从初步的需求分析开始逐步进行循环迭代——一方面在了解系统需求前不能开始设计架构，另一方面刚开始设计架构时并不需要等到全部需求都收集到。架构是由「架构驱动」因素「塑造」的，架构驱动因素是指少数关键的、优先级别最高的业务目标质量需求；架构由少数关键需求决定并在循环迭代中处于基本稳定状态，它作为演变的基础设施。
明
阿明
「不需要等全部需求收集到就可以开始设计架构」，这句跟瀑布式直觉相反，得专门记。
雅
小雅
然后是本节核心方法：属性驱动设计法 ADD，Attribute-Driven Design，是一种定义软件架构的方法，该方法将分解过程建立在软件必须满足的质量属性之上。ADD 的输入为：功能需求，一般表示为用例；限制条件；质量需求，一组特定于系统的质量场景。三个输入缺一不可。
雅
小雅
ADD 的步骤三步。第一步，选择要分解的模块，通常是整个系统，要求输入都是可获得的；从系统开始，然后分解为子系统，进一步将子系统分解为子模块。第二步，根据如下步骤对模块进行求精：从具体的质量场景和功能需求集合中选择架构驱动因素——并不是同等看待所有需求，而是在满足了最重要的需求的条件下才满足不太重要的需求，即针对架构需求有优先级；选择满足架构驱动因素的架构模式，根据前面的战术创建或选择模式，目标是建立一个由模块类型组成的总体架构模式；实例化模块并根据用例分配功能，使用多个视图进行表示；定义子模块的接口；验证用例和质量场景并对其进行求精，使它们成为子模式的限制。第三步，对需要进一步分解的每个模块重复上述步骤。
明
阿明
ADD 三步：选模块、求精、重复。求精里面那五个小步是「选驱动因素、选模式、实例化并分配功能、定义接口、验证求精」。
雅
小雅
背下了。9.6 剩下三点快速过。按架构组织开发团队：在架构的模块分解结构的最初几个层次相对稳定之后，就可以把这些模块分配给开发小组，其结果就是工作视图；像软件系统一样，开发小组也应该努力做到松耦合、高内聚；项目计划在架构确定之后可以结合分工进一步明细化，特别要规划好接口提供的时间点。开发骨架系统：演变交付生命周期模型中有两个循环，第一个循环通过迭代开发出软件架构，第二个循环在架构基础上通过迭代开发出交付的最终版本；
雅
小雅
开发骨架系统就是第二个循环的第一步，即以架构为指导开发一个可运行的原型即骨架系统，过程中要注意对接口进行充分协商，避免先开发的部分强制随后部分满足其不合理的接口要求。利用商用构件进行开发：针对需求的特点选用相应的模式来设计架构，并利用对应于该模式的商用构件进行软件开发，例如使用 J2EE/EJB 开发面向对象的分布式系统。
雅
小雅
接着 9.7 软件架构文档化。记录软件架构的活动就是架构编档过程，也就是架构的文档化，它包含两个方面：一是过程，编档过程能促使架构设计师进一步思考，使得架构更加完善；二是结果，描述架构的文档将作为架构开发的成果供项目关系人使用。架构文档的使用者是架构的项目关系人；编写技术文档最基本的原则之一是从读者的角度来编写，易于编写但很难阅读的文档是不受欢迎的。
明
阿明
不同关系人要的信息还不一样吧？
雅
小雅
原文各给了一句：系统实现人员希望文档提供关于开发活动的不能违反的限制及可利用的自由；测试人员和集成人员希望能从文档中得到必须组合在一起的各部分，并以此得到一个正确的测试黑箱；项目经理希望根据所确定的工作任务组建开发小组，规划和分配项目资源。这三句是案例分析题的素材。
雅
小雅
任何软件编档包括软件架构编档的规则归纳为 7 条，顺序背：从读者的角度编写文档；避免出现不必要的重复；避免歧义；使用标准结构；记录基本原理；使文档保持更新，但更新频率不要过高；针对目标的适宜性对文档进行评审。第七条容易被漏，「保持更新但不要过频」这种限定语也是判断题点。
雅
小雅
视图编档：视图是最重要的软件架构编档概念，架构文档化就是将相关视图编成文档，并补充多个视图的关联关系。研究者 Bachmann 等人提出的文档组织结构包含 7 个部分：视图概述，对系统进行概括性描述，包含视图的主要元素和元素间的关系，主要表示可用图形、表格、文本，通常用图形形式，使用 UML 语言来描述；元素目录，对主要表示中所描述的元素及其关系进行详细描述，包括元素及其属性、关系及其属性、元素接口、元素行为，这部分是文档的主要组成部分；
雅
小雅
上下文图，用图形展示系统如何与其环境相关；可变性指南，描述架构的可变化点，如产品线架构通过变化适用于多个系统时各系统要做出选择的选项、做出选择的时间；架构背景，为架构的合理性提供足够的、令人信服的论据，包括基本原理、分析结果及设计中所反映的假定；术语表，对文档中每个术语进行简要说明；其他信息，描述不属于架构方面的必要信息，如管理信息。
雅
小雅
跨视图文档是对多个视图文档做整体的「打包」，包括：文档有哪些内容、如何组织，即视图目录与视图模板；架构概述，描述系统的目的、视图之间的关联、元素表及索引、项目词汇；为什么架构是这样的即基本原理，解释做出决策的原因、方案的限制、改变决策时的影响及意义。UML 已成为对软件架构进行文档化的事实上的标准表示法，主要用于表示元素或元素组的行为。
雅
小雅
最后是软件架构重构。系统已存在但不知其架构，即文档缺失或失效，如何维护这样的系统并管理其演变？关键是找到软件架构，软件架构重构就是研究解决这一问题的方法，它是反向工程之一。架构重构需要工具支持，但任何一个工具或工具集都不够：工具往往面向特定语言，数据提取工具经常返回不完整或错误的结果，应在多个工具提供的结果间补充、验证和判断；重构的目的即文档的用途不同决定了需要提取什么数据，这反过来影响工具的选择——以此为原则的是架构重构的工作台方法，如 SEI 开发的 Dali，这个名字要记。
明
阿明
Dali，SEI 的工作台。重构的活动有几步？
雅
小雅
四个活动，以迭代方式进行：信息提取 View Extraction，可使用解析器、语法分析器等工具，利用 build 和 makefile 文件中关于模块的依赖关系，从源代码、编译时制品和设计制品中提取静态信息，使用分析工具提取动态信息；数据库构造 Database Construction，将提取的信息转化为标准的形式并置于数据库中；
雅
小雅
视图融合 View Fusion，将数据库中的信息组合在一起，生成该架构的一个内聚的视图；重构 Reconstruction，构建数据抽象和各种表示以生成架构表示，主要由可视化和交互、模式定义和识别两个活动组成，最后生成需要的架构文档。还有一句：必须让熟悉系统的人参与，包括过去参与开发的人员或现在正在维护的人员。
明
阿明
本集必背：架构模式即架构风格是适当选取战术的结果，模式不是硬性解决方法；演变交付生命周期里架构由架构驱动因素塑造，即少数关键优先级最高的业务目标质量需求；ADD 输入是用例形式的功能需求、限制条件、质量场景，三步是选择要分解的模块、对模块求精（选驱动因素、选模式、实例化分配功能、定义接口、验证求精）、对需进一步分解的模块重复；开发团队要松耦合高内聚；骨架系统是第二个循环第一步；编档七规则从读者角度起、针对适宜性评审收；视图编档七部分——视图概述、元素目录、上下文图、可变性指南、架构背景、术语表、其他信息；架构重构是反向工程之一，工作台方法如 SEI 的 Dali，四活动是信息提取、数据库构造、视图融合、重构。
雅
小雅
齐了。下一集是压轴双响：架构评估三方式、ATAM 九步与效用树、CBAM 八步，然后构件与商用标准、产品线、DSSA、架构演化七步、三种视图类型——练习题第十、十四、十五题全部在那里，全章必背清单也压轴奉上。