第9章 · 播客 第2集
软件架构设计 · 架构的重要性、六子过程与五种模型
🎙️ 本集播客：第2集：软件架构重要性的四大技术表现逐一拆开——交流平台、早期设计决策的五个体现、复用与指导意义，加上传统模型与基于架构开发模型的定位辨析，末尾背下六个子过程的完整名单。 语音由微软 Edge 神经网络语音预生成（女声·晓伊，男声·云希）。点击下方任意对话可直接从该句开始播，当前句朗读时下一句已预先加载，无缝衔接。
明
阿明
师姐，上一集讲完架构的定义，我有个疑问：都说架构重要，它到底重要在哪？考试会怎么问？
雅
小雅
原文就是按问题给答案的。从技术角度看，软件架构的重要性表现为四个方面，我先报题目：项目关系人之间交流的平台；早期设计决策；在较高层面上实现软件复用；架构对开发的指导与规范意义。逐个拆。第一，项目关系人之间交流的平台：软件系统的项目关系人分别关注系统的不同特性，而这些特性都由架构所决定，因此架构提供了一个共同语言，原文叫公共的参考点，项目关系人以此作为彼此理解、协商、达成共识或相互沟通的基础。架构分析既依赖于又促进了这个层次上的交流。
明
阿明
所以架构是「共同语言」，这个表述直接可以进选项。
雅
小雅
对。第二个方面分量最重：早期设计决策。从软件生命周期来看，软件架构是所开发系统的最早设计决策的体现，主要表现为五条。第一条，架构明确了对系统实现的约束条件：架构是架构设计师对系统实现的各方面进行权衡的结果，是总体设计的体现，因此在具体实现时必须按架构的设计进行。
雅
小雅
第二条，架构影响着系统的质量属性：要保证系统的高质量，具有完美的架构是必要的，虽然不充分——注意这个括号，判断题就出在这，「有了完美架构就一定有高质量系统」这种说法是错的，必要不充分。架构可以用来预测系统的质量，例如可以根据经验对该架构的质量如性能作定性的判断。
明
阿明
必要但不充分，这种半句话最容易被选项偷换。
雅
小雅
第三条，架构为维护的决策提供根据：在架构层次上能为日后的更改决策提供推理、判断的依据，一个富有生命力的架构，应该是在最有可能更改的地方有所考虑，原文称之为架构的柔性，使其在此点最容易进行更改。第四条，架构有助于原型开发：可以按架构构造一个骨架系统，也就是原型，例如在早期实现一个可执行的特例，确定潜在的性能问题。第五条，借助于架构进行成本与进度的估计。
明
阿明
五条我记住了：约束、质量、维护、原型、成本进度。
雅
小雅
第三个方面，在较高层面上实现软件复用。软件架构作为系统的抽象模型，可以在多个系统间传递复用，特别是比较容易地应用到具有相似质量属性和功能需求的系统中。这里有个专属名词：产品线通常共享一个架构，产品线的架构是开发组织的核心资产之一，利用架构及其范例进行多系统的开发，在开发时间、成本、生产率和产品质量方面具有极大的回报。基于架构的开发强调对各元素的组合或装配，系统开发还可以使用其他组织开发的元素，例如购买商业构件。
明
阿明
「产品线共享一个架构」，这句是复用那块的题眼。
雅
小雅
第四个方面，架构对开发的指导与规范意义不容忽略：架构作为系统的总体设计，它指导后续的详细设计和编码；架构使基于模板的开发成为可能，有利于开发的规范化和一致性，减少开发与维护成本；架构还可以作为培训的基础，有利于培养开发团队和培训相关人员。
雅
小雅
讲完四个方面，还有一段位置关系必考。从软件开发过程来看，如果采用传统的软件开发模型也就是生命周期模型，则软件架构的建立应位于概要设计之前，需求分析之后。这三站顺序：需求分析、软件架构、概要设计。
明
阿明
等等，我原以为架构是概要设计的一部分，位置在它后面？
雅
小雅
原文明确写「概要设计之前，需求分析之后」，这是这道题的唯一口径，别拿工作印象来抬杠。而基于架构的软件开发模型则明确地把整个软件过程划分为架构需求、设计、文档化、评审（评估）、实现、演化等 6 个子过程。本章各节就是分别对这些子过程进行讨论的。这六个名字，按顺序背：需求、设计、文档化、评审、实现、演化。
明
阿明
为什么「文档化」和「评审」要单独占两个过程？设计完了不就写文档么？
雅
小雅
因为这套模型把文档和评估当成独立的一等公民，而不是设计的附属品——后面 9.7 节专讲文档化，9.8 节专讲评估，分量重到值得单独立过程。考试问「基于架构的软件开发模型将软件过程划分为哪几个子过程」，选项里常混进「需求分析」「概要设计」「测试」这类传统过程的词，记住这套名单里没有测试，评审对评估，这个对应别错。
明
阿明
六个子过程我默一遍：架构需求、架构设计、架构文档化、架构评审、架构实现、架构演化。
雅
小雅
顺序对。顺手把这几个子过程和本章结构的对应关系说一下，方便你回原文定位：架构需求对应 9.2 节的质量属性与战术，架构设计对应 9.3 到 9.6 节的风格与设计方法，文档化对应 9.7 节，评审对应 9.8 节的架构评估，演化散在构件复用、产品线和 9.10.5 的演化步骤里。你按这个地图去翻原文，不会迷路。
明
阿明
这个地图有用，等于把整章目录串起来了。
雅
小雅
最后再补一个容易漏的细节：架构需求这个子过程，原文在 9.2 节开头交代了它的核心——架构的基本需求主要是在满足功能属性的前提下，关注软件质量属性，架构设计则是为满足架构需求寻找适当的「战术」。这句话先留个钩子，「战术」这个词下一部分要大讲特讲，它就是练习题里的高频词。
明
阿明
本集必背，我自己来总结：架构重要性四方面——项目关系人交流的平台、早期设计决策、较高层面实现复用、对开发的指导与规范；早期决策五个体现——约束条件、质量属性、维护根据、原型开发、成本进度估计；完美架构是高质量的必要条件但不充分；产品线通常共享一个架构；传统模型里架构位于需求分析之后、概要设计之前；基于架构的开发模型六个子过程——需求、设计、文档化、评审、实现、演化，名单里没有测试。
雅
小雅
全对，看来你开始入门了。下一集讲架构的五种模型和著名的「4+1」视图模型——那一集是考试的重中之重，逻辑视图、开发视图、进程视图、物理视图、场景各自关心什么、谁描述静态结构谁描述动态结构，练习题第一题和第二题就埋在那里。
明
阿明
师姐，上集结尾你说的 4+1 视图，是不是就是练考第一题考的那个？
雅
小雅
对，练习题前两题都埋在这里，先把地基打好。软件架构作为一个有机的整体，可以分解成多个侧面来认识，每个侧面强调它不同方面的特征，使架构设计师能整体把握重点。原文归纳成 5 种模型：结构模型、框架模型、动态模型、过程模型和功能模型，最常用的是结构模型和动态模型。这句「最常用」本身就能出题。
雅
小雅
逐个过。结构模型：这是一个最直观、最普遍的建模方法，以架构的构件、连接件和其他概念来刻画结构，力图通过结构来反映系统的重要语义内容，包括系统的配置、约束、隐含的假设条件、风格、性质。研究结构模型的核心是架构描述语言。框架模型：与结构模型类似，但它不太侧重描述结构的细节而更侧重于整体的结构，主要以一些特殊的问题为目标建立只针对和适应该问题的结构。
雅
小雅
动态模型：是对结构或框架模型的补充，研究系统「大颗粒」的行为性质，例如描述系统的重新配置或演化。过程模型：研究构造系统的步骤和过程，结构是遵循某些过程脚本的结果。功能模型：认为架构由一组功能构件按层次组成，且下层向上层提供服务，它可以看作是一种特殊的框架模型。
明
阿明
我辨一下易混的：结构模型的核心是架构描述语言，动态模型研究大颗粒行为，功能模型是特殊的框架模型。
雅
小雅
三个抓手都对。接着上重头戏。原文说这 5 种模型各有所长，也许将 5 种模型有机地统一在一起更合适，例如 Kruchten 在 1995 年提出了一个「4+1」的视图模型。人物年份先记死：Kruchten，1995 年。4+1 视图模型从 5 个不同的视角描述软件架构：逻辑视图、进程视图、物理视图、开发视图和场景视图。每一个视图只关心系统的一个侧面，5 个视图结合在一起才能反映系统的软件架构的全部内容。
明
阿明
「4+1」是哪四个加哪一个？
雅
小雅
四个正式视图是逻辑、开发、进程、物理，加的那一个「1」是场景。练习题第一题问「不属于该模型的视图是」，给的干扰项是数据视图——4+1 里没有数据视图这个名目，选项里出现它直接选。这个坑年年有人踩，因为很多人凭直觉觉得「数据这么重要，总该有个数据视图吧」，恰恰没有。
明
阿明
逻辑、开发、进程、物理加场景，没有数据。那五个视图各自管什么？
雅
小雅
逐个说，每个视图我给你三样东西：关心什么、怎么描述、注意什么。第一，逻辑视图：主要支持系统的功能需求，即系统提供给最终用户的服务。在逻辑视图中，系统分解成一系列的功能抽象，这些抽象主要来自问题领域。在面向对象技术中，可以用对象模型来代表逻辑视图，用类图来描述逻辑视图。逻辑视图中使用的风格为面向对象的风格，设计时要注意的主要问题是保持一个单一的、内聚的对象模型贯穿整个系统。
雅
小雅
第二，开发视图：也称为模块视图，这个别称必考。它主要侧重于软件模块的组织和管理，软件可通过程序库或子系统进行组织。开发视图要考虑软件内部的需求，如软件开发的容易性、软件的重用和软件的通用性，还要充分考虑由于具体开发工具的不同而带来的局限性。开发视图通过系统输入输出关系的模型图和子系统图来描述。
明
阿明
逻辑视图管功能、开发视图管模块组织——这两个听起来都偏「静态」。
雅
小雅
你摸到题眼了，稍后收网。第三，进程视图：侧重于系统的运行特性，主要关注一些非功能性的需求，例如系统的性能和可用性。进程视图强调并发性、分布性、系统集成性和容错能力，以及逻辑视图中的主要抽象的进程结构。它也定义逻辑视图中的各个类的操作具体是在哪一个线程中被执行的。进程视图可以描述成多层抽象，每个级别分别关注不同的方面。
雅
小雅
第四，物理视图：主要考虑如何把软件映射到硬件上，通常要考虑解决系统拓扑结构、系统安装、通信等问题。当软件运行于不同的节点上时，各视图中的构件都直接或间接地对应于系统的不同节点上，因此从软件到节点的映射要有较高的灵活性，当环境改变时，对系统其他视图的影响最小。
雅
小雅
第五，场景：可以看作是那些重要系统活动的抽象，它使四个视图有机地联系起来，从某种意义上说，场景是最重要的需求抽象。在开发架构时，它可以帮助设计者找到架构的构件和它们之间的作用关系，也可以用场景来分析一个特定的视图，或描述不同视图构件间是如何相互作用的。场景可以用文本表示，也可以用图形表示。
明
阿明
所以场景是那个「1」，作用是把另外四个视图串起来。现在收网吧，你刚才让我憋的那句「静态」「动态」怎么分组？
雅
小雅
这就是练习题第二题的答案。希赛教育专家提示的原话：逻辑视图和开发视图描述系统的静态结构，而进程视图和物理视图描述系统的动态结构。选项会把「进程视图和物理视图」跟「场景视图」搭配来骗你，记住场景不在静态动态任何一组里，它是联系的纽带。
雅
小雅
原文还补了应用侧重点：对于不同的软件系统来说，侧重的角度也有所不同。例如，对于管理信息系统来说，比较侧重于从逻辑视图和开发视图来描述系统；而对于实时控制系统来说，则比较注重于从进程视图和物理视图来描述系统。管理信息系统配静态、实时控制系统配动态，这个配对也能出题。
明
阿明
管理信息系统重逻辑开发、实时控制系统重进程物理。这组配对我记下。
雅
小雅
再给你几条视图的描述方式速记，都是选项级细节：逻辑视图用对象模型代表、类图描述、面向对象的风格；开发视图别称模块视图、用系统输入输出关系的模型图和子系统图描述；进程视图关注并发、分布、集成、容错，定义类操作在哪个线程执行；物理视图解决拓扑、安装、通信，做软件到节点的映射；场景是需求抽象，文本图形都行。
明
阿明
本集必背我来：五种模型——结构、框架、动态、过程、功能，最常用的是结构模型和动态模型，结构模型核心是架构描述语言，功能模型是特殊的框架模型；4+1 是 Kruchten 1995 年提出，逻辑、开发、进程、物理四个视图加场景，没有数据视图；逻辑加开发是静态结构，进程加物理是动态结构，场景是纽带；管理信息系统侧重逻辑开发视图，实时控制系统侧重进程物理视图。
雅
小雅
背得干净。下一集进入 9.2 节，软件质量属性——GB/T16260 的六大特性带全套子特性、运行期和开发期属性清单，还有「战术」的定义。质量属性那块子特性特别密，你要打起精神，那都是选择题的选项池。