【软件架构设计-综合题（4）】软件架构设计知识点

软件架构设计这一章表面上看知识点很多风格、视图、评估、复用、SOA、REST、DSSA、MVP、XML、WSDL好像东一块西一块。其实把这些题目放在一起看这一章真正想考的是一件事面对复杂软件系统架构师如何从整体层面组织系统、表达系统、复用经验并验证这个系统是否真的能支撑目标。顺着这个主线去学第四章就不会碎。它大致可以分成五层先理解软件架构到底是什么再理解常见架构风格和中间件接着看架构如何被描述、开发和评估然后看架构复用与特定领域架构最后补上面向服务、Web 服务和一些典型架构模式。下面按这个逻辑整理。一、先把软件架构的底层认识立住架构是系统级决策不是局部设计软件架构最核心的含义不是“画一张大图”而是对系统进行高层组织。它描述系统由哪些主要部分构成、这些部分之间如何协作、受什么约束以及这些决策为什么成立。它关心的是整体不是单个类或单个函数。所以题目里常出现两个容易混淆的点。第一软件架构很重要但它不是必须机械套用某种固定风格。架构风格是经验不是枷锁。真正正确的理解是架构设计要根据业务目标、质量目标和现实约束去选结构而不是先选风格再硬往里塞。第二体系结构风格描述的是某一类系统反复出现的组织模式。它定义了一个系统家族的词汇表和一组约束并反映这个领域中很多系统共有的结构和语义特征。这里“词汇表”讲的是有哪些构件和连接件“约束”讲的是这些构件和连接件该怎么组合。再进一步软件架构需求也不是简单等于“功能需求”。体系结构需求一般来自三个方面系统的质量目标、系统的商业目标、系统开发人员的商业目标。这里很容易误选成“功能需求 质量目标 商业目标”但出题人想强调的是架构首先响应的是系统层面的质量与商业诉求比如性能、可扩展性、成本、交付效率、团队协作而不是把功能清单直接搬成架构。因此这一层要记住两句话架构关注整体组织方式架构需求首先由质量目标和商业目标驱动。二、架构风格与构件中间件系统究竟按什么方式组织和协作理解了架构是什么下一步就要看“系统通常怎么组织”。这就是架构风格。风格本质上是成熟系统反复验证过的组织经验不同风格适合不同问题场景。1. 常见架构风格重点不在背名字而在抓住“组织方式”批处理风格的特点是系统由多个顺序处理步骤组成每个步骤通常是独立程序前一步完成后后一步才能开始数据在步骤之间以整体方式传递。它适合一次性、大批量、流程稳定的处理任务。这里最容易错的地方是把它理解成边处理边传输的数据流那已经不是批处理强调的重点了。基于规则的系统则是另一种思路。它的核心不在“顺序执行”而在“条件满足时触发规则”。典型组成包括规则集、规则解释器、规则/数据选择器和工作内存。做题时只要看到“规则集、解释器、工作内存”这一套基本就能判断是在考规则系统。事件驱动架构 EDA 强调事件在独立、非耦合模块之间传递。发布方不需要知道订阅方是谁只负责发布事件订阅方按需响应。这种结构的重点是松耦合、异步和可扩展。与它相近的隐式调用风格也是通过间接机制实现协作。比如用户在图形编辑界面点一个动作底层处理逻辑会被自动触发但界面本身并不需要显式知道全部调用链。它的关键是“通过中介机制间接协作”而不是组件直接点对点调用。后半部分又补进来两个高频考点。一个是REST 架构风格。REST 的核心是资源每个资源通过 URI 唯一标识资源通过 HTTP 标准方法如 GET、POST、PUT、DELETE 进行操作。REST 中状态通常分为应用状态和资源状态。题目里最容易错的是“RESTful API 必须使用 JSON 交换数据”这是错的。REST 强调的是资源和统一接口不强制规定一定是 JSONXML、HTML 或其他表示形式都可以。另一个是微服务与 SOA 的管理方式。微服务架构通常采用去中心化管理每个服务独立部署、独立运行、独立管理、常常也有自己的数据存储而面向服务架构 SOA 更偏整体协调和统一治理通常体现为集中式管理。这组题目就是在考二者的边界不是说它们都“服务化”就完全一样。2. 调用返回风格中的 MVP别把 View 和 Model 直接绑在一起调用返回风格下面题目还考到了 MVPModel-View-Presenter。这个模式里Model 负责数据View 负责显示Presenter 负责业务逻辑和交互协调。它的价值在于把界面和业务逻辑拆开使逻辑更容易复用和测试。最容易错的是“View 可以直接从 Model 中读取数据”。在 MVP 中View 通常不应该直接依赖 Model而是通过 Presenter 与 Model 交互这样才能降低耦合。也正因为如此一个 Presenter 可以服务多个 ViewMVP 也常用于移动端开发场景。3. 构件与中间件中间件不替代业务它负责连接和集成构件与中间件技术是软件架构落地的重要支撑。中间件最本质的角色是连接不同的软件组件或系统提供通信和集成服务。它不是直接去处理最终业务也不是去管理 CPU 和内存那类硬件资源而是处在操作系统和应用软件之间负责把原本分散的部分接起来。CORBA 是这一类题的典型代表。其中一个高频点是对象适配器Object Adapter它负责屏蔽 ORB 内核实现细节并给服务器对象实现者提供抽象接口。简单说就是把底层中间件的复杂性包起来让上层对象更稳定地接入。这一整层的学习重点可以压成一句话架构风格解决“系统怎么组织”中间件解决“这些部分怎么接起来”。三、架构如何被表达、开发和评估真正的架构能力不只会设计还要会说明和验证很多同学学到这里会卡住因为这部分既有视图、又有 ADL、又有 ABSDM、又有 SAAM/ATAM。其实它们都在回答同一个问题架构设计出来以后怎么表达、怎么推进开发、怎么判断它靠不靠谱。1. 架构描述视图、视角和 ADL 都是在回答“怎么把系统说清楚”基于架构的软件开发 ABSD 强调由商业需求、质量需求和功能需求共同驱动架构设计。它强调采用视角与视图来描述软件架构采用用例和质量场景来描述质量需求。这里很容易误选成“构件和类图”或“类图和序列图”但 ABSD 真正强调的是多视图表达和场景化需求。ADL架构描述语言则是更正式的表达手段。它是一种基于模型的描述语言主要用于描述软件系统的构件、连接件和架构配置。因此题目里“ADL 三要素不包括什么”时中间件不属于这三要素。要把 ADL 和 ABSD 区分开ADL 是“描述架构的语言”ABSD 是“基于架构的软件开发方法”前者是表达工具后者是开发方法。2. 多视图模型不是记名字而是理解每个视图各管什么Kruchten 的41 视图模型是第四章最稳定的高频考点。它包括逻辑视图、进程视图、开发视图、物理视图再加上统一的场景。逻辑视图主要面向功能需求关注系统提供什么服务开发视图关注模块的组织与管理也常被理解成模块视图或实现视图物理视图关注如何把软件映射到硬件和网络节点上所以题目里“主要考虑如何把软件映射到硬件上”的就是物理视图进程视图则侧重系统的运行特性关注并发、性能、可用性等运行期问题所以“侧重系统运行特性”的是进程视图而“1”中的场景是把前面四个视图串起来的统一入口。你后面给的题里还出现了 Hofmeister 的4 视图模型。它由概念视图、模块视图、执行视图和代码视图组成。这里最容易和 Kruchten 混淆。Hofmeister 模型里没有场景也没有物理视图重点是从概念、模块、执行和代码四个层面去说明系统。所以多视图题的记忆方法最好不是死背而是按职责记逻辑/概念系统做什么开发/模块模块怎么组织进程/执行系统怎么运行物理/部署系统落在哪些节点场景用具体使用情境把视图串起来3. 架构评估场景是入口ATAM 和 SAAM 是方法架构评估方法里SAAM 和 ATAM 都属于基于场景的方法。也就是说它们不是抽象地谈“好不好”而是分析软件架构对特定场景的支持程度再判断它对这类质量需求的满足程度。ATAM 是在 SAAM 基础上发展起来的更强调质量属性之间的权衡分析。一个高频点是 ATAM 的四个主要活动领域场景和需求收集、架构视图和场景实现、属性模型构造和分析、折中。这几步你不用死背成术语串理解成“先收场景再看架构怎么支持这些场景再分析质量属性模型最后做权衡”就行。前半部分我们已经整理过场景、效用树、增长场景、非风险点这些内容。这里把逻辑再收紧一下场景是评估的入口效用树是场景排序工具ATAM 是做权衡分析的方法最后产出会落到风险点、敏感点、权衡点和非风险点这些判断上。4. ABSDM架构驱动开发需求不只是功能需求基于架构的软件开发方法 ABSDM 强调架构不是画完就结束而是贯穿需求、设计、文档化、复审、实现和演化全过程。前半部分已经提到它的六个主要活动以及设计、文档化、复审是迭代过程。后半部分又补了两点很重要的认识。第一ABSD 采用视图/视角描述架构用用例和质量场景描述质量需求这说明它天然适合处理“功能 质量”一起驱动的复杂系统。第二体系结构需求的来源不是简单功能罗列而是质量目标、商业目标和开发相关目标的组合。所以 ABSD 的难点不在于画图而在于把这些目标转化为真正能支撑开发和演化的架构。这一层总结一下架构描述是在说清楚架构评估是在证明靠谱ABSDM 是让架构真正驱动开发。四、架构复用与特定领域架构成熟架构不是每次重来而是不断沉淀和复用第四章另一条很强的主线就是复用。架构的价值不只是做成一个系统更重要的是形成一套可以反复利用的经验、资产和模式。1. 架构复用复用不是复制粘贴而是系统化利用成熟资产前半部分已经讲过机会复用、系统复用以及获取、管理、使用可复用资产三个阶段。后半部分又补上了几个很容易考错的边界。首先横向重用指重用不同应用领域中的软件元素比如数据结构、分类算法、人机界面构件等纵向重用则更多发生在同类或相近业务领域中。题目里只要出现“不同应用领域中的共性软件元素”答案一般就是横向重用。其次好的复用实践不是复制现有代码而是利用已经验证的开源类库或框架来开发新系统。复制粘贴虽然表面也叫“复用”但那是一种低水平复用会造成冗余和维护困难真正高质量的复用是复用经过验证、可管理、可维护的模块和框架。所以复用题的关键边界是复用强调资产化和可持续不强调临时复制。2. DSSA把复用从“构件级”推到“领域级”如果说一般架构复用还是在系统之间借鉴构件和模式那么 DSSA特定领域软件架构就是把复用再往上提一层直接面向一个领域建立可重复使用的架构方案。DSSA 的基本活动可以理解为三步领域分析、领域设计、领域实现。领域分析阶段的主要目标是获得领域模型也就是把该领域里一类系统的共性需求抽出来领域设计阶段则基于领域模型形成 DSSA领域实现阶段再依据领域模型和 DSSA 去组织可复用信息和可复用构件。围绕 DSSA题目还经常考四类角色领域专家提供领域中的需求、规则和实现知识领域分析人员负责控制整个领域分析过程做知识获取并把知识组织到领域模型中领域设计人员负责控制整个软件设计过程根据领域模型和现有系统开发出 DSSA并验证 DSSA 的准确性和一致性领域实现人员负责根据领域模型和 DSSA 提取、开发和验证可复用构件这里尤其容易错的是领域分析人员和领域设计人员。前者的关键词是“分析过程、知识获取、形成领域模型”后者的关键词是“设计过程、形成 DSSA、建立领域模型和 DSSA 的联系”。这一层学明白之后你会发现 DSSA 本质上就是一句话把一个领域里反复出现的系统经验上升为可复用的领域模型和领域架构。五、SOA、Web 服务与相关技术服务化架构的考点重在边界和配套语言第四章后半部分有一块内容会让人觉得像“杂项”SOA、WSDL、XML、REST、微服务。其实这些都属于服务化架构及其相关技术只是考法比较碎。把它们放在一起看逻辑就清楚了。1. SOA、微服务与 Web 服务它们有关联但不是一个层次SOA 是一种以服务为中心的整体架构思想强调服务封装、复用、组合与统一治理微服务则更强调服务拆分后的独立部署、独立运维和去中心化管理。二者都是服务化思路但粒度、治理方式和组织方式并不完全一样。Web 服务则更像 SOA 的一种实现形式或技术载体它关注的是服务如何被描述、发现和调用。前半部分我们已经整理过 UDDI 和 WSDL 的作用UDDI解决“服务在哪儿找”WSDL解决“服务能做什么、怎么访问、地址在哪儿”。2. WSDL重点记住三件事而不是记一堆 XML 标签WSDL 描述 Web 服务的三个基本属性服务做什么服务提供哪些操作如何访问服务交互的数据格式和协议是什么服务位于何处服务地址在哪里题目里最常见的错误干扰项是把“谁要访问服务”塞进来。WSDL 关心的是服务能力、访问方式和访问地址不负责规定“谁来访问”。3. XML它负责描述和交换数据不负责决定怎么显示与 Web 服务配套的另一个常考点是 XML。XML 的几个稳定认识是结构与内容分离可以通过命名空间解决多义性和名字冲突XML Schema 是 XML 的一种具体应用用来定义合法结构和约束。最容易错的是“XML 允许各种各样的文档显示类型”。这是错的因为 XML 本身是数据描述格式关注的是数据及其结构不负责展示控制。显示通常要靠 CSS、XSLT、前端程序等其他机制完成。4. REST要抓资源、URI、统一接口不要把它误缩成 JSONREST 作为一种架构风格核心就是资源、URI 和统一接口。它充分利用 HTTP 协议已有能力通过标准方法和状态码来操作资源。很多同学会把 REST 和 JSON 绑死这是高频误区。JSON 很常见但 REST 不以 JSON 为必要条件这一点要牢牢记住。这一大块如果压缩记忆可以抓住这样一条链SOA/微服务是架构思想Web 服务是服务交互方式WSDL 是服务说明书XML/JSON 是可能的数据表示形式REST 是另一种以资源为中心的架构风格。最后把这一章压缩成一条适合考前复习的主线可以这样理解软件架构先回答“系统整体怎么组织”所以会考架构概念、体系结构风格、构件和中间件然后回答“架构怎么表达和验证”所以会考视图、ADL、ABSDM、场景、ATAM 和 41 视图接着回答“架构经验怎么沉淀和复用”所以会考机会复用、系统复用、横向重用、DSSA 和领域角色最后回答“服务化系统怎么落地”所以会考 SOA、微服务、WSDL、XML 和 REST。考前速记如果考前速记这一章最值得抓住的是这些点体系结构风格定义系统家族的词汇表和约束架构需求主要来自质量目标、商业目标和开发相关目标批处理的数据按整体传递规则系统包括规则集、解释器和工作内存EDA 强调事件在独立非耦合模块间传递微服务偏去中心化管理SOA 偏集中式治理中间件的作用是连接不同软件组件或系统提供通信与集成服务MVP 中 View 不应直接依赖 ModelPresenter 负责逻辑ADL 三要素是构件、连接件和架构配置ABSD 采用视图和视角描述架构采用用例和质量场景描述需求ATAM 和 SAAM 都是基于场景的评估方法ATAM 包括场景收集、视图与场景实现、属性分析和折中41 视图中物理视图考虑软件到硬件的映射进程视图侧重运行特性Hofmeister 四视图包括概念、模块、执行和代码横向重用面向不同应用领域中的通用元素好的复用实践是使用成熟类库和框架不是复制粘贴DSSA 的领域分析阶段产出领域模型领域分析人员管分析过程领域设计人员管 DSSA 设计WSDL 说明服务做什么、如何访问、位于何处XML 负责描述数据结构不负责显示REST 的核心是资源和 URI不强制要求 JSON。