当前位置：首页 > news >正文

软考高级-系统架构设计师历年案例专题一：软件架构设计

news 2025/10/22 9:21:51

架构风格背诵

批处理序列架构风格:构件为一系列固定顺序的计算单元，构件之间只能通过数据交互传递，数据必须是完整的，以整体的方式传递。

管道-过滤器架构风格:每个构件都有一组输入和输出。构件读取输入的数据流经过处理后产生输出数据流，前一个构件输出作为后一个构件输入，过滤器就是构件，连接件就是管道。

主程序/子程序架构风格：以主程序为核心，主程序控制整体流程并发起调用，子程序负责执行具体功能，完成后向主程序返回结果，按“主调-子执行”逻辑协作。

面向对象架构风格：以封装数据（属性）和行为（方法）的“对象”为核心，以“类”为对象模板，根据继承、多态实现逻辑复用，组件间的交互通过消息传递。

层次结构架构风格：按功能划分为独立层次（如表现层、业务层），上层依赖下层提供服务、下层不依赖上层，同层无交互，实现逻辑解耦与易维护的架构模式。

隐式调用架构风格：以“事件”为核心，组件预先注册感兴趣的事件，当事件触发时系统自动调用对应组件，组件间无显式调用、靠事件关联的架构模式。

解释器架构风格：以“解释器”为核心，先将动态规则转化为抽象语法树或指令集，再由解释器逐步解析、执行这些指令，从而灵活处理可变需求。

仓库架构风格：以中央仓库为核心，各组件不直接交互，均通过仓库存取、处理数据，实现数据集中管理与组件松耦合。

黑板架构由黑板、知识源、控制器三部分构成，各部分分工明确：

黑板=中央数据结构：存

知识源：算，算完写回黑板（牛逼的学生）

控制器：调度知识源，监控黑板状态（老师叫牛逼学生上黑板答题）

黑板是共享的中央数据结构（类似“公共画板”），主要作用是：

存储问题的初始数据、中间结果和最终结果；
作为知识源之间的“交互媒介”（知识源从黑板读数据，处理后写回黑板）。

但黑板本身不执行任何“数据处理或计算”操作，仅承担“数据存储与共享”的角色。

知识源是具备特定领域知识的独立模块（比如“图像识别知识源”“语法分析知识源”等），核心职责是：

当黑板上的数据状态满足“触发条件”时，被激活；
对黑板中的数据进行处理、计算或推理（利用自身领域知识，把原始/中间数据转化为更接近目标的结果）；
将处理后的新结果写回黑板，供其他知识源后续使用。

因此，知识源是执行“数据处理和计算”的核心构件。

控制器的职责是：

监控黑板的状态变化（如出现新数据、中间结果满足特定条件等）；
根据黑板状态，调度（激活）合适的知识源去处理数据。

它是“调度者”，不直接参与数据的计算或处理。

“中央数据结构”是黑板的本质属性（黑板本身就是用于共享数据的“中央结构”），但它是“数据容器”，而非“处理构件”，因此不负责数据处理和计算。

综上，黑板架构中用于进行数据处理和计算的构件是“知识源”，答案为B。

为提升可读性，按“基础运行特性”和“维护管控特性”拆分为两个表格，仍以“优（★★★）、中（★★）、差（★）”分级，关键原因保持精准提炼：

性能灵活性可扩展性可修改性安全性

表1：架构风格基础运行特性对比（性能+灵活性）

架构风格	性能（效率/资源/实时性）	灵活性（流程/需求适配）
批处理序列	★★（批量处理高效、但实时性差）	★（流程固定，改规则/加步骤需调整整体计划，适配难）
管道-过滤器	★★（支持并行处理、组件轻量）	★★（加过滤器/管道易，但强依赖流转顺序，非线性需求难适配）
主程序/子程序	★★（资源按需调用，但同步链长易瓶颈，高并发响应慢）	★（流程由主程序控制，修改逻辑需动核心，可变需求适配难）
面向对象	★★（对象封装高效，但多对象交互有开销，复杂继承可能拖慢性能）	★★★（多态支持“同一接口不同实现”，需求变只需新增/改对象）
层次结构	★★（分层职责清晰，资源聚焦，但跨层调用有开销，多层嵌套耗时）	★★（层内调整易，但跨层需求难适配，层间依赖固定）
隐式调用	★★（事件触发响应快，但并发事件易资源竞争，广播有延迟）	★★★（组件独立注册事件，需求变只需加“事件+组件”，无侵入）
解释器	★（动态解析指令耗时，实时处理弱，复杂规则易卡顿）	★★★（规则可动态修改，无需改架构，适配可变需求极灵活）
仓库	★★（集中存储访问高效，但单点易成瓶颈，高并发易过载）	★★（组件扩展易，但仓库数据结构改会影响所有组件，格式变更适配难）

表2：架构风格维护管控特性对比（可扩展性+可修改性+安全性）

架构风格	可扩展性（新增功能）	可修改性（组件/逻辑调整）	安全性（数据管控/风险）
批处理序列	★（新增功能需嵌入固定序列，易破坏原流程，成本高）	★（组件耦合紧，改一个环节可能影响全流程，故障追溯难）	★★（集中处理易管控，但批量故障会导致“整批数据风险”）
管道-过滤器	★★★（新增组件只需接管道，不修改现有过滤器，扩展灵活）	★★★（组件解耦，改单个过滤器不影响其他，故障仅阻断局部）	★★（组件独立易管控，但数据在管道暴露，需额外加密）
主程序/子程序	★（新增子程序需主程序调整调用逻辑，扩展需动核心）	★（子程序接口变则主程序必改，耦合紧，修改影响范围大）	★★（主程序统一管控，但接口暴露多，需加强权限校验）
面向对象	★★★（新增功能可通过“继承扩展类”或“加对象”实现，不破坏原有逻辑）	★★★（封装隔离内部逻辑，改对象内部不影响外部调用，范围小）	★★★（私有属性控访问，权限可按方法粒度实现，泄露风险低）
层次结构	★★★（新增功能在对应层加组件，不影响其他层，扩展隔离性好）	★★★（层间靠接口交互，改下层（不换接口）不影响上层，修改隔离）	★★★（敏感层可单独隔离，分层权限管控，风险可控）
隐式调用	★★★（新增组件只需注册事件，不侵入原有系统，扩展无感知）	★★★（组件无显式依赖，改组件逻辑不影响其他注册者，隔离性好）	★（事件广播易泄露数据，故障组件会通过事件传播风险，权限难精准控）
解释器	★★（新增简单规则易，但扩展解释器核心能力（如支持新语法）难，需改底层）	★★（规则独立修改易，但解释器核心逻辑改会影响所有规则，风险高）	★（动态规则易注入恶意代码（如脚本注入），防护成本高）
仓库	★★（新增组件只需对接仓库，扩展易，但仓库本身扩容（如分库）复杂）	★★（组件改易，但仓库逻辑（如存储结构）改影响所有组件，范围大）	★★★（集中仓库统一加密+权限+审计，数据管控强，泄露风险低）

系统架构设计师考试：核心架构风格概念详解

作为系统架构设计师考试的重点内容，架构风格是必考知识点。下面我将用简洁、清晰的概念解释，帮助你掌握这些核心架构风格，无需代码，专注于概念理解。

1. 批处理序列架构风格

核心概念：一系列固定顺序的计算单元，数据必须是完整的整体传递。

关键特点：

严格顺序执行，前一阶段必须完成才能进入下一阶段
数据以完整批次形式传递，而非流式处理
适合不需要实时响应的批量处理场景

典型应用场景：银行夜间批量结算、报表生成系统

考试重点：与管道-过滤器架构的区别（批处理是"整体处理"，管道-过滤器是"流式处理"）

2. 管道-过滤器架构风格

核心概念：每个构件（过滤器）有输入和输出，数据流经过滤器链，前一过滤器的输出作为后一过滤器的输入。

关键特点：

数据流式处理，可边处理边输出
过滤器之间松耦合，可独立开发和测试
适合数据转换和处理流程

典型应用场景：编译器工作流程、日志处理系统

考试重点：过滤器（构件）与管道（连接件）的区分

3. 主程序/子程序架构风格

核心概念：以主程序为核心，主程序控制整体流程并发起调用，子程序负责执行具体功能。

关键特点：

"主调-子执行"逻辑，主程序控制流程
结构清晰，易于理解
适合简单线性流程

典型应用场景：文件处理程序、简单命令行工具

考试重点：与面向对象架构的区别（主程序/子程序是"控制驱动"，面向对象是"对象驱动"）

4. 面向对象架构风格

核心概念：以封装数据（属性）和行为（方法）的"对象"为核心，以"类"为对象模板。

关键特点：

高内聚、低耦合
通过继承、多态实现逻辑复用
组件间交互通过消息传递

典型应用场景：电商平台、企业级应用系统

考试重点：封装、继承、多态三大特性与应用场景

5. 层次结构架构风格

核心概念：按功能划分为独立层次，上层依赖下层提供服务，下层不依赖上层。

关键特点：

严格分层，上层调用下层
逻辑解耦，易于维护
同层无交互

典型应用场景：Web应用三层架构（表现层、业务层、数据层）

考试重点：层次间依赖关系与分层原则（如高内聚、低耦合）

6. 隐式调用架构风格

核心概念：以"事件"为核心，组件预先注册感兴趣的事件，当事件触发时系统自动调用对应组件。

关键特点：

组件间无显式调用，靠事件关联
低耦合，易于扩展
适合事件驱动型系统

典型应用场景：GUI界面事件处理、消息队列系统

考试重点：与显式调用架构的区别，事件注册与触发机制

7. 解释器架构风格

核心概念：以"解释器"为核心，先将动态规则转化为抽象语法树，再由解释器逐步解析、执行指令。

关键特点：

动态规则处理
规则可配置、可修改
适合需要灵活处理可变需求的场景

典型应用场景：规则引擎、低代码平台

考试重点：抽象语法树(AST)的构建与解释过程

8. 仓库架构风格

核心概念：以中央仓库为核心，各组件不直接交互，均通过仓库存取、处理数据。

关键特点：

组件间高度解耦
数据集中管理
适合需要数据共享的系统

典型应用场景：数据库系统、黑板系统（如语音识别系统）

考试重点：与仓库模式的区别（仓库架构是"数据集中"，而黑板系统是"数据共享"）

09年下案例一

题干

某软件开发公司欲为某电子商务企业开发一个在线交易平台，支持客户完成网上购物活动中的在线交易。在系统开发之初，企业对该平台提出了如下要求：

(1) 在线交易平台必须在1s内完成客户的交易请求。

(2) 该平台必须保证客户个人信息和交易信息的安全。

(3) 当发生故障时，该平台的平均故障恢复时间必须小于10s。

(4) 由于企业业务发展较快，需要经常为该平台添加新功能或进行硬件升级。添加新功能或进行硬件升级必须在6小时内完成。

针对这些要求，该软件开发公司决定采用基于架构的软件开发方法，以架构为核心进行在线交易平台的设计与实现。

【问题：1.1】软件质量属性是影响软件架构设计的重要因素。请用200字以内的文字列举六种不同的软件质量属性名称并解释其含义。

性能：体现系统处理任务的速度，如响应时间（对请求的反馈速度）、吞吐量（单位时间处理的任务量）等。
安全性：系统向合法用户提供服务并阻止非授权用户使用服务的能力。
可用性：系统在一段时间内正常运行的时间占比。
可修改性：系统易于被修改（如新增功能、调整结构）的程度。
可靠性：软件系统在一定的时间内持续无故障运行的能力。
可测试性：系统便于设计、执行测试用例，验证功能是否符合预期的程度。

【问题：1.2】请对该在线交易平台的4个要求进行分析，用300字以内的文字指出每个要求对应何种软件质量属性；并针对每种软件质量属性，各给出2种实现该质量属性的架构设计策略。

1：性能：资源调度，并发控制。

①引入缓存机制，减少数据库访问时间；②使用负载均衡，分散请求压力，提高处理效率。

2：安全性：入侵检测，用户认证

①数据加密，对存储和传输的信息进行加密；②访问控制，实施身份认证和授权机制，限制未授权访问。

3：可用性：主动冗余，心跳机制

4，可修改性：接口-实现分类，信息隐藏

10年下

【说明】

某公司欲针对Linux操作系统开发一个KWIC (KeyWord in Context)检索系统。该系统接收用户输入的查询关键字，依据字母顺序给出相关帮助文档并根据帮助内容进行循环滚动阅读。在对KWIC系统进行需求分析时，公司的业务专家发现用户后续还有可能采用其他方式展示帮助内容（功能扩展）。根据目前需求，公司的技术人员决定通过重复剪切帮助文档中的第一个单词并将其插入到行尾的方式实现帮助文档内容的循环滚动，后续还将采用其他的方法实现这一功能。（算法变更）

在对KWIC系统的架构进行设计时，公司的架构师王工提出采用共享数据的主程序-子程序的架构风格，而李工则主张采用管道-过滤器的架构风格。在架构评估会议上，大家从系统的算法变更、功能变更、数据表示变更和性能等方面对这两种方案进行评价，最终采用了李工的方案。

该系统更适用于管道过滤器的架构风格，

【问题：1.1】在实际的软件项目开发中，采用恰当的架构风格是项目成功的保证。请用200字以内的文字说明什么是软件架构风格，并对主程序-子程序和管道-过滤器这两种架构风格的特点进行描述。

软件架构风格：指描述特定软件系统组织方式的惯用模式。组织方式描述了系统的组成构件和这些构件的组织方式，惯用模式则反映众多系统共有的结构和语义。

主程序子程序：单线程控制，把问题划分为若干个处理步骤，构件即为主程序和子程序。显式调用，主程序直接调用子程序。

管道过滤器：每个构件都有一组输入输出，构件读取输入的数据流，前一个构件的输出作为后一个构件的输入，性能较高，交互性差。

【问题：1.2】请完成表1-1中的空白部分(用+表示优、—表示差)，对王工和李工提出的架构风格进行评价，并指出采用李工方案的原因。

总结与对比（回应图片中的表格）

表格还在加载中，请等待加载完成后再尝试复制

【问题：1.3】：

11年下

【说明】

某网上购物电子商务公司拟升级正在使用的在线交易系统，以提高用户网上购物在线支付环节的效率和安全性。在系统的需求分析与架构设计阶段，公司提出的需求和关键质量属性场景如下：

(a) 正常负载情况下，系统必须在0.5秒内对用户的交易请求进行响应；xn

(b) 信用卡支付必须保证99.999%的安全性；aq

(d) 网络失效后，系统需要在1.5分钟内发现错误并启用备用系统；ky

(e) 需要在20人月内为系统添加一个新的CORBA中间件；kxg

(f) 交易过程中涉及到的产品介绍视频传输必须保证画面具有600*480的分辨率，20帧/秒的速率；xn

(g) 更改加密的级别将对安全性和性能产生影响；

(h) 主站点断电后，需要在3秒内将访问请求重定向到备用站点；ky

(i) 假设每秒中用户交易请求的数量是10个，处理请求的时间为30毫秒，则“在1秒内完成用户的交易请求”这一要求是可以实现的；

(j) 用户信息数据库授权必须保证99.999%可用；aq

(k) 目前对系统信用卡支付业务逻辑的描述尚未达成共识，这可能导致部分业务功能模块的重复，影响系统的可修改性；

(l) 更改Web界面接口必须在4人周内完成；kxg

(m) 系统需要提供远程调试接口，并支持系统的远程调试。

在对系统需求和质量属性场景进行分析的基础上．系统的架构师给出了三个候选的架构设计方案。公司目前正在组织系统开发的相关人员对系统架构进行评估。

【问题：1.1】在架构评估过程中，质量属性效用树(utility tree)是对系统质量属性进行识别和优先级排序的重要工具。请给出合适的质量属性，填入图1-1中(1)、(2)空白处；并选择题干描述的(a)~(m)，填入(3)~(6)空白处，完成该系统的效用树。ez容易

性能，安全性，可用性，可修改性

【问题：1.2】在架构评估过程中，需要正确识别系统的架构风险、敏感点和权衡点，并进行合理的架构决策。请用300字以内的文字给出系统架构风险、敏感点和权衡点的定义，并从题干(a)~(m)中各选出1个对系统架构风险、敏感点和权衡点最为恰当的描述。

架构风险：指架构设计中潜在的，存在问题的架构决策所带来的隐患。目前对系统信用卡支付业务逻辑的描述尚未达成共识，这可能导致部分业务功能模块的重复，影响系统的可修改性；

敏感点：指为了实现某种特定的质量属性，一个或者多个构件所具有的特性。对交易请求处理时间的要求将影响系统的数据传输协议和处理过程的设计

权衡点：是影响多个质量属性的特性，是多个质量属性的敏感点。(g) 更改加密的级别将对安全性和性能产生影响；

09-11 小总结

(1) 性能是指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理事件的个数。

(2) 可用性是系统能够正常运行的时间比例。

(3) 可靠性是指软件系统在应用或错误面前，在意外或错误使用的情况下维持软件系统功能特性的基本能力。

(4) 健壮性是指在处理或环境中，系统能够承受压力或变更的能力。

(5) 安全性是指系统向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。

(6) 可修改性是指能够快速地以较高的性价比对系统进行变更的能力。

(7) 可变性是指体系结构经扩充或变更成为新体系结构的能力。

(8) 易用性是衡量用户使用一个软件产品完成指定任务的难易程度。

(9) 可测试性是指软件发现故障并隔离、定位其故障的能力特性，以及在一定的时间和成本前提下，进行测试设计、测试执行的能力。

(10) 功能性是系统所能完成所期望工作的能力。

(11) 互操作性是指系统与外界或系统与系统之间的相互作用能力。

管道-过滤器架构风格的核心是“独立组件（过滤器）+ 数据流（管道）”，各质量属性的表现（高/中/低）及核心原因如下，均基于其原生架构特性（不依赖额外增强措施）：

质量属性	等级	核心原因
可修改性	高	过滤器功能独立，修改单个过滤器（如调整处理逻辑）仅需保证输入/输出接口不变，不影响其他组件。
可测试性	高	过滤器可单独测试（给定输入验证输出），无需依赖整个管道，单元测试成本低、效率高。
性能	中	支持并行处理（多个过滤器可同时处理不同数据段），但易受“瓶颈过滤器”影响（某过滤器慢则整体慢）。
可用性	中	单个过滤器故障可能中断管道，但故障过滤器可快速替换恢复；无原生冗余机制，中断期间系统不可用。
互操作性	中	若采用标准数据格式（如JSON、XML），不同系统的过滤器可集成；但原生无强制标准，依赖接口设计。
可靠性	中	管道多为线性流，单个过滤器故障可能导致数据处理失败（故障易传播），无原生容错能力。
安全性	低	管道传递数据时无原生加密/权限控制，易被拦截或篡改；过滤器权限分散，难统一管控访问安全。

解释器风格架构的核心是定义特定领域语言（DSL）+ 构建解释器，用于解析并执行DSL描述的规则/逻辑（如SQL解释器、正则表达式引擎）。其各关键质量属性的表现（高/中/低）及核心原因如下：

质量属性	等级	核心原因
可扩展性	高	扩展领域能力仅需修改DSL语法定义或新增对应解释逻辑（如给SQL加新函数），无需重构整体架构，对原有功能影响小。
可理解性	高	DSL为特定领域设计，领域专家（如财务、运维人员）无需懂底层代码，可直接用DSL编写/维护规则，降低认知成本。
可测试性	中	单个DSL规则或解释模块（如词法解析器）可单独测试，但整体需覆盖大量语法组合、执行场景，测试用例复杂度高。
性能	低	需额外经历“DSL解析（词法/语法分析生成语法树）→ 解释执行”流程，比编译型直接执行多一层开销，复杂逻辑效率更低。
可靠性	中	单个DSL规则或解释逻辑的错误仅影响该规则（如某条SQL解析失败），但核心解释器（如语法分析器）故障会导致所有DSL失效。
安全性	低	原生无强安全管控，若解释器缺乏输入验证，恶意DSL可能引发注入攻击（如SQL注入），且解释器漏洞易被利用。
可用性	中	合规DSL可稳定执行，但DSL语法复杂或解释器bug会导致规则执行失败，需额外调试；无原生冗余机制，故障后需修复解释器本身。

架构风险：指架构设计中潜在的，存在问题的架构决策所带来的隐患。 目前对系统信用卡支付业务逻辑的描述尚未达成共识，这可能导致部分业务功能模块的重复，影响系统的可修改性；

敏感点：指为了实现某种特定的质量属性，一个或者多个构件所具有的特性。对交易请求处理时间的要求将影响系统的数据传输协议和处理过程的设计

权衡点：是影响多个质量属性的特性，是多个质量属性的敏感点。(g) 更改加密的级别将对安全性和性能产生影响；

12年

案例题

【说明】

某软件公司为其新推出的字处理软件设计了一种脚本语言，专门用于开发该字处理软件的附加功能插件。为了提高该语言的编程效率，公司组织软件工具开发部门为脚本语言研制一套集成开发环境。软件工具开发部门根据字处理软件的特点，对集成开发环境进行了需求分析，总结出以下3项核心需求：

(1) 集成开发环境需要提供对脚本语言的编辑、语法检查、解释、执行和调试等功能的支持，并要实现各种功能的灵活组合、配置与替换。

(2) 集成开发环境需要提供一组可视化的编程界面，用户通过对界面元素拖曳和代码填充的方式就可以完成功能插件核心业务流程的编写与组织。

(3) 在代码调试功能方面，集成开发环境需要实现在脚本语言编辑界面中的代码自动定位功能。具体来说，在调试过程中，编辑界面需要响应调试断点命中事件，并自动跳转到当前断点处所对应的代码。

针对上述需求，软件工具开发部门对集成开发环境的架构进行分析与设计，王工认为该集成开发环境应该采用管道-过滤器的架构风格实现，李工则认为该集成开发环境应该采用以数据存储为中心的架构风格来实现。公司组织专家对王工和李工的方案进行了评审，最终采用了李工的方案。

【问题: 1.1】请用200字以内的文字解释什么是软件架构风格，并从集成开发环境与用户的交互方式、集成开发环境的扩展性、集成开发环境的数据管理三个方面说明为什么最终采用了李工的设计方案。

软件架构风格是指描述特定软件系统组织方式的惯用模式，组织方式描述了系统的组成构件和这些构件的组织方式，惯用模式则反映众多系统共有的结构和语义。

集成开发环境与用户的交互方式：针对该需求特性，以数据存储为中心的架构风格交互性更好，可以更好的实现一组可视化编程的页面，而管道-过滤器的架构风格主要采用独立组件＋数据流的形式，交互性较差。

集成开发环境的扩展性：针对该需求特性，上述两个架构风格扩展性都表现良好，以数据存储为中心的架构风格扩展性更好一些。

集成开发环境的数据管理：针对该需求特性，以数据存储为中心的架构风格可以更好的进行数据管理，进行语法检查、解释、执行和调试等功能，管道过滤器架构风格在数据格式转换方面灵活性较差。

【问题: 1.2】在对软件系统架构进行设计时，要对架构需求进行分析，针对特定需求选择最为合适的架构风格，因此实际的软件系统通常会混合多种软件架构风格。请对核心需求进行分析，说明为了满足需求(2)和(3)，分别应采用何种架构风格，并概要说明采用相应架构风格后的架构设计过程。

针对需求二：应采用解释器架构风格，解释器系统核心是虚拟机，可以采用多种操作来解释一个句子，灵活应对自定义场景。

针对需求三：应采用事件驱动架构风格，基于事件的隐式调用风格的思想是构件不直接调用一个过程，而是触发或广播一个或多个事件，系统中的其他构件中的过程在一个或多个事件中注册，当一个事件被触发，系统自动调用在这个事件中注册的所有过程，这样，一个事件的触发就导致了另一模块中的过程的调用。首先将断点命中作为事件注册，当其被触发时，编辑界面需要响应并自动跳转到当前断点处所对应的代码作为过程被调用。

试题解析

软件架构风格是指描述特定软件系统组织方式的惯用模式。组织方式描述了系统的组成构件和这些构件的组织方式，惯用模式则反映众多系统共有的结构和语义。

从集成开发环境与用户的交互方式看，用户通常采用交互式的方式对脚本语言进行编辑、解释执行与调试。在这种情况下，采用以数据存储为中心的架构风格能够很好地支持交互式数据处理，而管道 - 过滤器架构风格则对用户的交互式数据处理支持有限。（其实没讲原因，直接结合题目进行说明）

从集成开发环境的扩展性来看，系统核心需求要求实现各种编辑、语法检查、解释执行等多种功能的灵活组织、配置与替换。在这种情况下，采用以数据存储为中心的架构风格，以数据格式解耦各种功能之间的依赖关系，并可以灵活定义功能之间的逻辑顺序。管道 - 过滤器架构风格同样以数据格式解耦数据处理过程之间的依赖关系，但其在数据处理逻辑关系的灵活定义方面较差。（先解释这种需求从题目中哪些具体的行为体现出，然后再结合题干以及储备知识区回答）

从集成开发环境的数据管理来看，集成开发环境需要支持脚本语言、语法树（用于检查语法错误）、可视化模型、调试信息等多种数据类型，并需要支持数据格式的转换。以数据存储为中心的架构将数据存储在统一的中心存储器中，中心存储器能够表示多种数据格式，并能够为数据格式转换提供各种支持。管道 - 过滤器架构风格通常只能支持有限度的数据格式，并且在数据格式转换方面的灵活性较差。

为了满足需求(2)，应该采用解释器架构风格。具体来说，需要：①为可视化编程元素及其拖拽关系定义某种语言，并描述其语法与语义；②编写解释器对该语言进行解释；③生成对应的脚本语言程序。

为了满足需求(3)，应该采用隐式调用架构风格。具体来说，首先需要定义“断点在调试过程中命中”这一事件，并实现当断点命中后的屏幕定位函数。集成开发环境维护一个事件注册表结构，将该事件与屏幕定位函数关联起来形成注册表中的一个记录项。在调试过程中，集成开发环境负责监听各种事件，当“断点在调试过程中命中”这一事件发生时，集成开发环境查找...

13年

没什么价值，主要是理解题干。考到了ESB，背住即拿分！！：

ESB:是SOA的一种实现方式，简单来讲是一根管道，用来链接各个服务节点。ESB的存在是为了集成基于不同协议的不同服务，ESB做了消息的转换，解释以及路由的工作，以此来让不同的服务互联互通。

ESB的特点：

1.ESB在面向服务的架构中起到的是总线的作用，将各种服务进行连接和整合。

2.描述服务的元数据和服务注册管理。

3.在服务的请求者和提供者之间传递服务，并有转换数据的能力。

4:发现，路由，匹配和选择的能力，解耦服务请求者和服务提供者。

ESB的主要功能：

1.服务位置透明性

2.传输协议转换。

3.消息格式转换

4.消息路由

5.消息增强

6.安全性，监控与管理

14年必做

试题一

【说明】

某软件公司欲开发一个网络设备管理系统，对管理区域内的网络设备（如路由器和交换机等）进行远程监视和控制。公司的系统分析师首先对系统进行了需求分析，识别出如下3项核心需求：

（a）目前需要管理的网络设备确定为10类20种，未来还将有新类别的网络设备纳入到该设备管理系统中；

（b）不同类别的网络设备，监视和控制的内容差异较大；同一类网络设备，监视和控制的内容相似，但不同厂商的实现方式（包括控制接口格式、编程语言等）差异较大；

（c）网络管理员能够在一个统一的终端之上实现对这些网络设备的可视化呈现和管理操作。

针对上述需求，公司研发部门的架构师对网络设备管理系统的架构进行了分析与设计，架构师王工认为该系统可以采用MVC架构风格实现，即对每种网络设备设计一个监控组件，组件通过调用网络设备厂商内置的编程接口对监控指令进行接收和处理（监控组件对...进行接受和处理，一看到处理就是处理数据逻辑，故是模型）；系统管理员通过 管理模块 向监控组件（已经确认为模型）发送监控指令（谁和模型交互，向模型输送内容，一看就是控制器），对网络设备进行远程管理；网络状态、监控结果等信息会在控制终端上进行展示。针对不同网络设备的差异，王工认为可以对当前的20种网络设备接口进行调研与梳理，然后通过定义统一操作接口屏蔽设备差异。李工同意王工提出的MVC架构风格和定义统一操作接口的思路，但考虑到未来还会有新类别的网络设备接入，认为还需要采用扩展接口的方式支持系统开发人员扩展或修改现有操作接口。公司组织专家进行架构评审，最终同意了王工的方案和李工的改进意见。

【问题1】

请用300字以内的文字解释什么是MVC架构风格以及其中的组件交互关系，并根据题干描述，指出该系统中的M、V、C分别对应什么。

MVC架构风格指的是：将一个应用的输入，处理，输出流程按照视图，控制，模型的方式进行分离，形成三个核心模块：控制器，模型，视图。

其中控制器处理用户交互的部分，模型处理应用程序数据逻辑的部分，视图处理数据显示的部分。

在本系统中，模型（M)代表监控组件、视图（V)代表控制终端、控制器（C)代表管理模块。

14年选做

全对！！！！

质量效应树＋基本理论：

架构风险：指架构设计中潜在的，存在问题的架构决策所带来的隐患。

敏感点：是指为了实现某种特定的质量属性，一个或多个构件所具有的特性。

权衡点：是影响多个质量属性的特性，是多个质量属性的敏感点。

15年

基本全对

和14年考的一模一样！！

16年:做的巨烂

17年必选：纯送分

17年选做一

试题二

阅读以下关于软件系统设计的叙述，在答题纸上回答问题1至问题3.

【说明】

某软件企业受该省教育部门委托建设高校数字化教育教学资源共享平台，实现以众筹众创的方式组织省内普通高校联合开展教育教学资源内容建设，实现全省优质教学资源整合和共享。该资源共享平台的主要功能模块包括：

(1)统一身份认证模块：提供统一的认证入口，为平台其他核心业务模块提供用户管理、身份认证、权限分级和单点登录等功能；

(2) 共享资源管理模块：提供教学资源申报流程服务，包括了资源申报、分类定制、资料上传、资源审核和资源发布等功能；

(3)共享资源展示模块：提供教育教学共享资源的展示服务，包括资源导航、视频点播、资源检索、分类展示、资源评价和推荐等功能；

(4) 资源元模型管理模块：依据资源类型提供共享资源的描述属性、内容属性和展示属性，包括共享资源统一标准和规范、资源加工和在线编辑工具、数字水印和模板定制等功能；

(5) 系统综合管理模块：提供系统管理和维护服务，包括系统配置、数据备份恢复、资源导入导出和统计分析等功能。

项目组经过分析和讨论，决定采用基于Java EE的MVC 模式设计资源共享平台的软件架构，如图2-1所示。

【问题1】(9 分)

MVC架构中包含哪三种元素，它们的作用分别是什么?请根据图 2-1 所示架构将JavaEE 中 JSP、Servlet、Service、JavaBean、DAO 五种构件分别填入空 (1)~（5）所示位置。

MVC架构包含：视图、控制器、模型

视图（View）：视图是用户看到并与之交互的界面。视图向用户显示相关的数据，并能接收用户的输入数据，但是它并不进行任何实际的业务处理。

控制器（Controller）：控制器是应用程序中处理用户交互的部分，通常控制器负责从视图读取数据，控制用户输入，并向模型发送数据。

模型（Model）：模型是应用程序的主体部分。模型表示业务数据和业务逻辑。一个模型能为多个视图提供数据。

（1）JSP （2）Servlet （3）Service （4）JavaBean （5）DAO

JavaEE Web应用的分层架构

各构件的职责与位置填充

根据JavaEE Web应用的典型流程（请求接收→业务处理→数据访问→数据库交互），各位置应填入的构件为：

(1) JSP
(2) Servlet
(3) Service
(4) JavaBean
(5) DAO

详细讲解（分层逻辑与交互流程）

JavaEE Web应用通常遵循MVC（模型-视图-控制器）或类似的分层设计，各构件分工明确，协作完成“请求处理→业务逻辑→数据持久化”的流程：

JSP（位置(1)）：视图（View）层

JSP（JavaServer Pages）负责生成动态网页内容，是直接面向用户的“视图”。它可以嵌入Java代码，从“模型”（如JavaBean）中获取数据，并渲染为HTML、CSS等格式，最终展示给客户端浏览器。

Servlet（位置(2)）：控制器（Controller）层

Servlet是服务器端的Java程序，负责接收客户端的HTTP请求（如表单提交、页面跳转请求等），解析请求参数（如表单数据、URL参数），然后根据请求的业务意图，调用业务逻辑层（Service）进行处理。它是“请求进入服务器后的第一个业务入口”，起到“请求分发、流程控制”的作用。

Service（位置(3)）：业务逻辑层

Service层封装了应用的核心业务逻辑（如用户注册的规则校验、订单生成的流程控制等）。它接收来自Servlet的请求，处理复杂的业务规则（如数据验证、事务管理、业务流程编排），然后调用数据访问层（DAO）完成数据的持久化操作。Service层是业务逻辑的“大脑”，保证业务规则的一致性和可维护性。

JavaBean（位置(4)）：模型（Model）层（数据封装）

JavaBean是普通的Java类（遵循“私有属性+公共get/set方法”的规范），主要用于数据封装：

可作为实体类（对应数据库中的表结构，存储单条记录的数据）；
也可作为数据传输对象（DTO），在Servlet、Service、DAO各层之间传递数据，屏蔽各层的实现细节。

DAO（位置(5)：Data Access Object，数据访问对象）

DAO层负责直接操作数据库（如执行CRUD：创建、读取、更新、删除）。它屏蔽了底层数据存储的细节（如使用JDBC、MyBatis、Hibernate等技术操作数据库），为Service层提供“数据读写”的统一接口。当Service需要操作数据库时，只需调用DAO的方法，无需关心数据库的具体实现。

整体交互流程

客户端浏览器 → HTTP请求 → Servlet（接收并解析请求）→ Service（处理业务逻辑）→ 借助JavaBean传递数据 → DAO（操作数据库）→ 数据库（持久化数据）→ 结果通过DAO→Service→Servlet返回 → JSP（渲染为页面）→ 客户端浏览器展示。

这种分层架构的优势的是职责分离：视图（JSP）专注展示，控制器（Servlet）专注请求分发，业务层（Service）专注业务规则，数据层（DAO）专注数据访问，JavaBean专注数据封装。各层独立开发、测试和维护，大幅提升了代码的可扩展性与可维护性。

【问题2】(6 分)

项目组架构师王工提出在图2-1所示架构设计中加入EJB构件，采用企业级JavaEE架构开发资源共享平台。请说明EJB构件中的Bean (构件)分为哪三种类型，每种类型Bean的职责是什么。

EJB中的Bean分三种类型：Session Bean、Entity Beans 和 Message-Driven Bean。

Session Bean的职责是：维护一个短暂的会话

Entity Beans 的职责是：维护一行持久稳固的数据

Message-Driven Bean的职责是：异步接收消息

会话，实体，消息驱动

【问题3】 (10分)

如果采用王工提出的企业 JavaEE架构，请说明下列(a)-(e) 所给出的业务功能构件中，有状态和无状态构件分别包括哪些。

（a）Identification Bean (身份认证构件)

（b）ResPublish Bean(资源发布构件)

（c）ResRetrieval Bean(资源检索构件)

（d）OnlineEdit Bean(在线编辑构件)

（e）Statistics Bean(统计分析构件)

Bce

17年选做

试题五

阅读以下关于Web系统架构设计的叙述，在答题纸上回答问题1至问题3.

【说明】

某电子商务企业因发展良好，客户量逐步增大，企业业务不断扩充，导致其原有的B2C商品交易平台己不能满足现有业务需求。因此，该企业委托某软件公司重新开发一套商品交易平台。该企业要求新平台应可适应客户从手机、平板设备、电脑等不同终端设备访问系统，同时满足电商定期开展"秒杀"、"限时促销"等活动的系统高并发访问量的需求。面对系统需求，软件公司召开项目组讨论会议，制定系统设计方案。讨论会议上，王工提出可以应用响应式Web设计满足客户从不同设备正确访问系统的需求。同时，采用增加镜像站点、CDN 内容分发等方式解决高并发访问量带来的问题。李工在王工的提议上补充，仅仅依靠上述外网加速技术不能完全解决高用户并发访问问题，如果访问量持续增加，系统仍存在崩溃可能。李工提出应同时结合负载均衡、缓存服务器、Web应用服务器、分布式文件系统、分布式数据库等方法设计系统架构。经过项目组讨论，最终决定综合王王和李工的思路，完成新系统的架构设计。

【问题1】(5分)

请用200字以内的文字描述什么是"响应式 Web 设计"，并列举2个响应式Web设计的实现方式。

响应式web设计是指我们设计与开发的页面可以根据用户的行为和不同的设备环境做出相应的响应来调整页面的布局，以提供用户可感知的、流畅的阅读和操作体验。

实现方式：

（1）流式布局

（2）弹性布局加媒体查询

【问题2】(16 分)

综合王工和李工的提议，项目组完成了新商品交易平台的系统架构设计方案。新系统架构图如图5-1所示。请从选项 (a) - (j) 中为架构图中(1) - (8) 处空白选择相应的内容，补充支持高并发的Web应用系统架构设计图。

(a) Web 应用层 4

(b) 界面层

(d) CDN 内容分发 1

(e) 主数据库 5

(f) 缓存服务器集群 3

(g) 从数据库 7

(h) 写操作 6

(i) 读操作 8

(j) 文件服务器集群

【问题3】(4 分)

根据李工的提议，新的B2C商品交易平台引入了主从复制机制。请针对B2C商品交易平台的特点，简要叙述引入该机制的好处。

1、提升性能

交易平台要求高并发，主从复制方式一主多从，不同的用户请求可以从不同的从数据库读取数据，提高并发度。

2、可扩展性更优

如果采用单台数据库服务器，则访问量持续增加时，数据库瓶颈暴露，且无法迅速解决问题。而主从结构可以快速增加从服务器数量，以满足需求。

3、提升可用性

一主多从，一台从服务器出现故障不影响整个系统正常工作。

4、相当于负载均衡

一主多从分担任务，相当于负载均衡

5、提升数据安全性

系统中的数据冗余存放多份，不会因为某台机器硬件故障而导致数据丢失。

18年必做

试题一

阅读以下关于软件系统设计的叙述，在答题纸上回答问题 1 至问题 3。

【说明】

某文化产业集团委托软件公司开发一套文化用品商城系统，业务涉及文化用品销售、定制、

竞拍和点评等板块，以提升商城的信息化建设水平。该软件公司组织项目组完成了需求调研，

现已进入到系统架构设计阶段。考虑到系统需求对架构设计决策的影响，项目组先列出了可能

影响系统架构设计的部分需求如下：

（a）用户界面支持用户的个性化定制； 1

（b）系统需要支持当前主流的标准和服务，特别是通信协议和平台接口； 1

（c）用户操作的响应时间应不大于 3 秒，竞拍板块不大于 1 秒； 2

（d）系统具有故障诊断和快速恢复能力；2

（e）用户密码需要加密传输； 3

（f）系统需要支持不低于 2G 的数据缓存； 2

（g）用户操作停滞时间超过一定时限需要重新登录验证； 3

（h）系统支持用户选择汉语、英语或法语三种语言之一进行操作。 4

项目组提出了两种系统架构设计方案：瘦客户端 C/S 架构和胖客户端 C/S 架构，经过对上述

需求逐条分析和讨论，最终决定采用瘦客户端 C/S 架构进行设计。

【问题 1】（8 分）

在系统架构设计中，决定系统架构设计的非功能性需求主要有四类：操作性需求、性能需求、安全性需求和文化需求。请简要说明四类需求的含义。

系统性能需求（Performance Requirements）：指响应时间、吞吐量、准确性、有效性、资源利用率等与系统完成任务效率相关的指标。可靠性、可用性等指标归为此类。

安全性需求（Security Requirements）：系统向合法用户提供服务并阻止非授权用户使用服务方面的系统需求。

操作性需求（Operational Requirements）:与用户操作使用系统相关的一些需求。

文化需求（Cultural Requirements）：带有文化背景因素的系统需求。

【问题 2】（8 分）

根据表 1-1 的分类，将题干所给出的系统需求（a）~（h）分别填入（1） ~ （4）。

表 1-1 需求分类

（1）（a）（b）

（2）（c）（d）（f）

（3）（e）（g）

（4）（h）

【问题 3】（9 分）

请说明瘦客户端 C/S 架构能够满足题干中给出的哪些系统需求（只需要回答出三个系统需求）。

瘦客户端C/S架构是指客户端功能极简，页面简单清晰，绝大部分业务逻辑由服务器完成。

可满足以下三个系统需求。

瘦客户端C/S架构能够满足的三个系统需求如下：

1. 需求（a）用户界面支持用户的个性化定制 瘦客户端的界面渲染和逻辑主要由服务器端处理，用户的个性化配置（如界面布局、功能偏好等）可集中存储在服务器。当用户访问时，服务器根据其个性化设置动态生成对应界面并发送给客户端，无需修改客户端程序即可实现定制，适配瘦客户端“功能集中在服务器”的特点。

2. 需求（b）系统需要支持当前主流的标准和服务，特别是通信协议和平台接口 瘦客户端的通信逻辑、协议解析等核心功能由服务器统一实现和维护。当需要支持新的通信协议或平台接口时，只需更新服务器端程序，所有客户端即可自动适配，无需逐个升级客户端，符合瘦客户端“集中管理和更新”的优势。

3. 需求（d）系统具有故障诊断和快速恢复能力 瘦客户端的核心业务逻辑和数据处理均在服务器端，可通过服务器集群、监控系统等技术实现故障诊断（如检测服务器节点异常）。当某一服务器节点故障时，可快速切换到备用节点，客户端仅需重新连接即可恢复服务，而客户端本身功能简单、故障点少，进一步提升了整体恢复效率。

19年必做

试题一（共25分）

阅读以下关于软件架构设计与评估的叙述，在答题纸上回答问题1和问题2。

【说明】

某电子商务公司为了更好地管理用户，提升企业销售业绩，拟开发一套用户管理系统。该系统的基本功能是根据用户的消费级别、消费历史、信用情况等指标将用户划分为不同的等级，并针对不同等级的用户提供相应的折扣方案。在需求分析与架构设计阶段，电子商务公司提出的需求、质量属性描述和架构特性如下：

（a）用户目前分为普通用户、银卡用户、金卡用户和白金用户四个等级，后续需要能够根据消费情况进行动态调整；

（b）系统应该具备完善的安全防护措施，能够对黑客的攻击行为进行检测与防御；安全性

（c）在正常负载情况下，系统应在0.5秒内对用户的商品查询请求进行响应；

（d）在各种节假日或公司活动中，针对所有级别用户，系统均能够根据用户实时的消费情况动态调整折扣力度；

（e）系统主站点断电后，应在5秒内将请求重定向到备用站点；可用性

（f）系统支持中文昵称，但用户名要求必须以字母开头，长度不少于8个字符；

（g）当系统发生网络失效后，需要在15秒内发现错误并启用备用网络；

（h）系统在展示商品的实时视频时，需要保证视频画面具有1024×768像素的分辨率，40帧/秒的速率；性能

（i）系统要扩容时，应保证在10人·月内完成所有的部署与测试工作；

（j）系统应对用户信息数据库的所有操作都进行完整记录；安全性

（k）更改系统的Web界面接口必须在4人·周内完成；可修改性

（l）系统必须提供远程调试接口，并支持远程调试。

在对系统需求、质量属性描述和架构特性进行分析的基础上，该系统架构师给出了两种候选的架构设计方案，公司目前正在组织相关专家对系统架构进行评估。

【问题1】（13分）

针对用户级别与折扣规则管理功能的架构设计问题，李工建议采用面向对象的架构风格，而王工则建议采用基于规则的架构风格。请指出该系统更适合采用哪种架构风格，并从用户级别、折扣规则定义的灵活性、可扩展性和性能三个方面对这两种架构风格进行比较与分析，填写表1-1中的（1）～（3）空白处。

表1-1 两种架构风格的比较与分析

架构风格名称

灵活性

可扩展性

性能

面向对象

将用户级别、折扣规则等封装为对象，在系统启动时加载

（2）加入新的用户级别和折扣规则时需要增加相应的类来扩展，，扩展性较差

（3）可根据类型判断或策略模式直接获得用户级别对应的折扣规则对象实时计算，性能很好

基于规则

（1）根据用户级别建立用户级别 - 折扣规则矩阵，在系统启动时加载并支持运行过程中动态更新，灵活性好；

加入新的用户级别和折扣规则时只需要定义新的规则，解释规则即可进行扩展

需要对用户级别与折扣规则进行实时解释、性能较差

【问题2】（12分）

在架构评估过程中，质量属性效用树（UtilityTree）是对系统质量属性进行识别和优先级排序的重要工具。请将合适的质量属性名称填入图1-1中（1）、（2）空白处，并选择题干描述的（a）～（l）填入（3）～（6）空白处，完成该系统的效用树。

1 安全性 2可修改性

图1-1 会员管理系统效用树

暂时无法在飞书文档外展示此内容

注意：从试题二至试题五中，选择两题解答。

20年

试题一（共25分）20分应该可以

阅读以下关于软件架构设计与评估的叙述，在答题纸上回答问题1和问题2。

【说明】

某公司拟开发一套在线软件开发系统，支持用户通过浏览器在线进行软件开发活动。该系统的主要功能包括代码编辑、语法高亮显示、代码编译、系统调试、代码仓库管理等。在需求分析与架构设计阶段，公司提出的需求和质量属性描述如下：

（a）根据用户的付费情况对用户进行分类，并根据类别提供相应的开发功能；

（b）在正常负载情况下，系统应在0.2秒内对用户的界面操作请求进行响应；

（c）系统应该具备完善的安全防护措施，能够对黑客的攻击行为进行检测与防御；安全性

（d）系统主站点断电后，应在3秒内将请求重定向到备用站点；

（e）系统支持中文昵称，但用户名必须以字母开头，长度不少于8个字符；

（f）系统宕机后，需要在15秒内发现错误并启用备用系统；可用性

（g）在正常负载情况下，用户的代码提交请求应该在0.5秒内完成；性能

（h）系统支持硬件设备灵活扩容，应保证在2人·天内完成所有的部署与测试工作；可修改性

（i）系统需要为针对代码仓库的所有操作情况进行详细记录，便于后期查阅与审计；安全性

（j）更改系统的web界面风格需要在4人·天内完成；可修改性

（k）系统本身需要提供远程调试接口，支持开发团队进行远程排错。

在对系统需求、质量属性和架构特性进行分析的基础上，该公司的系统架构师给出了两种候选的架构设计方案，公司目前正在组织相关专家对候选系统架构进行评估。

【问题1】（13分）

针对该系统的功能，李工建议采用管道-过滤器（pipeandfilter）的架构风格，而王工则建议采用仓库（repository）架构风格。请指出该系统更适合采用哪种架构风格，并针对系统的主要功能，从数据处理方式、系统的可扩展性和处理性能三个方面对这两种架构风格进行比较与分析，填写表1-1中的（1）～（4）空白处。

表1-1 两种架构风格的比较与分析

架构风格名称

数据处理方式

系统可扩展性

处理性能

管道-过滤器

数据驱动机制，处理流程事先确定，交互性差

（2）扩展功能时只需增加额外的构件与连接件，扩展性较好

劣势：需要数据格式转换，性能降低

优势：支持过滤器并发调用，性能提高

架构风格名称

数据处理方式

系统可扩展性

处理性能

仓库

（1）数据共享风格，以数据为中心，交互性较好

数据与处理解耦合，可动态添加和删除处理组件

劣势：（3）仓库中调用复杂，性能降低

优势：（4）可以处理较为复杂的问题，性能提高

【问题2】（12分）

在架构评估过程中，质量属性效用树（utility tree）是对系统质量属性进行识别和优先级排序的重要工具。请将合适的质量属性名称填入图1-1中（1）、（2）空白处，并选择题干描述的（a）～（k）填入（3）～（6）空白处，完成该系统的效用树。

21年必做

试题一（25 分）

阅读以下关于软件架构设计与评估的叙述，在答题纸上回答问题 1 和问题 2。

【说明】

某公司拟开发一套机器学习应用开发平台，支持用户使用浏览器在线进行基于机器学习的智能应用开发活动。该平台的核心应用场景是用户通过拖拽算法组件灵活定义机器学习流程，采用自助方式进行智能应用设计、实现与部署，并可以开发新算法组件加入平台中。在需求分析与架构设计阶段，公司提出的需求和质量属性描述如下：

（a）平台用户分为算法工程师、软件工程师和管理员等三种角色，不同角色的功能界面有所不同；

（b）平台应该具备数据库保护措施，能够预防核心数据库被非授权用户访问；

（c）平台支持分布式部署，当主站点断电后，应在 20 秒内将请求重定向到备用站点；

（d）平台支持初学者和高级用户两种界面操作模式，用户可以根据自己的情况灵活选择合适的模式；

（e）平台主站点宕机后，需要在 15 秒内发现错误并启用备用系统；可用

（f）在正常负载情况下，机器学习流程从提交到开始执行，时间间隔不大于 5 秒；

（g）平台支持硬件扩容与升级，能够在 3 人天内完成所有部署与测试工作；

（h）平台需要对用户的所有操作过程进行详细记录，便于审计工作；安全

（i）平台部署后，针对界面风格的修改需要在 3 人天内完成；可修改性

（j）在正常负载情况下，平台应在 0.5 秒内对用户的界面操作请求进行响应；性能

（k）平台应该与目前国内外主流的机器学习应用开发平台的界面风格保持一致；

（l）平台提供机器学习算法的远程调试功能，支持算法工程师进行远程调试。

在对平台需求、质量属性描述和架构特性进行分析的基础上，公司的架构师给出了三种候选的架构设计方案，公司目前正在组织相关专家对平台架构进行评估。

【问题 1】（9 分）纯送

在架构评估过程中，质量属性效用树（utility tree）是对系统质量属性进行识别和优先级排序的重要工具。请将合适的质量属性名称填入图 1 - 1 中（1）、（2）空白处，并从题干中的（a）-（l）中选择合适的质量属性描述，填入（3）-（6）空白处，完成该平台的效用树。

1性能 2可修改性

【问题 2】（16 分）

针对该系统的功能，赵工建议采用解释器（interpreter）架构风格，李工建议采用管道 - 过滤器（pipe - and - filter）的架构风格，王工则建议采用隐式调用（implicit invocation）架构风格。请针对平台的核心应用场景，从机器学习流程定义的灵活性和学习算法的可扩展性两个方面对三种架构风格进行对比与分析，并指出该平台更适合采用哪种架构风格。

解释器（interpreter）架构风格：解释器架构风格是通过定义特定领域语言的语法规则，构建解释器来解释执行该语言的语句或表达式，从而实现对特定逻辑解释性执行的架构模式。可以更好的实现拖拽算法组件灵活定义机器学习流程，灵活性较好，同时新加入的算法可作为新的语法规则即可，可扩展性较好。

管道 - 过滤器架构风格：是由多个“过滤器”组件通过“管道”连接，数据以流的形式在管道中传递，各过滤器独立对输入数据处理后输出给后续过滤器的架构模式。由于以流式结构顺序执行，灵活性较差。同时新加入的算法可作为新的过滤器即可，可扩展性较好。

隐式调用（implicit invocation）架构风格：是指组件不直接调用，而是通过发布事件，触发所有注册该事件的组件隐式执行相应操作，从而实现间接交互的架构模式。灵活性和可扩展性较差，不易实现自定义机器学习流程及加入新的学习算法。

综上所述，该平台采用解释器架构风格更合适。

标准答案：

【问题 2】

答案/答案解析：管道-过滤器风格具备高内聚低耦合、支持软件重用、扩展性好、支持并发等优点，但它有编写复杂、不适合处理交互应用等缺点；

隐式调用基于事件触发思想，具备支持软件重用、改进系统方便等优点，但它有构件放弃了对系统计算的控制、事件传递中的数据交换存在问题、语义依赖于被触发事件的上下文约束等缺点。

解释器通常包括解释引擎、代码存储区、记录解释引擎当前工作状态的数据结构、记录源代码被解释执行进度的数据结构。它含有一个虚拟机，可以仿真硬件的执行过程和一些关键应用，其缺点是执行效率比较低。优点：语法由很多类（每个规则对应一个类）表示，容易改变及扩展；缺点：如果语法规则数量太多，会增加系统复杂度，性能下降。

本题中，由于需要交互操作，显然管道-过滤器风格不合适；基于事件触发的隐式调用风格也不合适；只有解释器风格通过灵活自定义规则，具备较强的灵活性和可扩展性，适合本题中的机器学习应用。

22年

试题一(共25分)

阅读以下关于软件架构设计与评估的叙述，在答题纸上回答问题1和问题2。

【说明】

某电子商务公司拟升级其会员与促销管理系统，向用户提供个性化服务，提高用户的粘性。

在项目立项之初，公司领导层一致认为本次升级的主要目标是提升会员管理方式的灵活性，由于当前用户规模不大，业务也相对简单，系统性能方面不做过多考虑，新系统除了保持现有的四级固定会员制度外，还需要根据用户的消费金额、偏好、重复性等相关特征动态调整商品的折扣力度，并支持在特定的活动周期内主动筛选与活动主题高度相关的用户集合，提供个性化的打折促销活动。

在需求分析与架构设计阶段，公司提出的需求和质量属性描述如下：

(a)管理员能够在页面上灵活设置折扣力度规则和促销活动逻辑，设置后即可生效；

(b)系统应该具备完整的安全防护措施，支持对恶意攻击行为进行检测与报警；

(c)在正常负载情况下，系统应在0.3秒内对用户的界面操作请求进行响应；

(d)用户名是系统唯一标识，要求以字母开头，由数字和字母组合而成，长度不少于6个字符。

(e)在正常负载情况下，用户支付商品费用后在3秒内确认订单支付信息；

(f)系统主站点电力中断后，应在5秒内将请求重定向到备用站点；

(g)系统支持横向存储扩展，要求在2人天内完成所有的扩展与测试工作；

(h)系统宕机后，需要在10秒内感知错误，并自动启动热备份系统；

(i)系统需要内置接口函数，支持开发团队进行功能调试与系统诊断；

(j)系统需要为所有的用户操作行为进行详细记录，便于后期查阅与审计；

(k)支持对系统的外观进行调整和配置，调整工作需要在4人天内完成。

在对系统需求、质量属性描述和架构特性进行分析的基础上，系统架构师给出了两种候选的架构设计方案，公司目前正在组织相关专家对系统架构进行评估。

【问题1】(12分)

在架构评估过程中，质量属性效用树(utility tree)是对系统质量属性进行识别和优先级排序的重要工具。请将合适的质量属性名称填入图1-1中(1)、(2)空白处，并选择题干描述的(a)-(k)填入(3)-(6)空白处，完成该系统的效用树。

【问题 2】(13 分)

针对该系统的功能，李工建议采用面向对象的架构风格，将折扣力度计算和用户筛选分别封装为独立对象，通过对象调用实现对应的功能：王工则建议采用解释器(interpreters) 架构风格，将折扣力度计算和用户筛选条件封装为独立的规则，通过解释规则实现对应的功能。请针对系统的主要功能，从折扣规则的可扩展性、个性化折扣定义灵活性和系统性能三个方面对这两种架构风格进行比较与分析，并指出该系统更适合采用哪种架构风格。

折扣规则的可扩展性：若新增折扣规则，解释器架构风格可将新增的规则作为独立规则，通过解释规则从而实现，可扩展性较好，面向对象的架构风格，若新增折扣规则，可能子类和父类都需要进行改动，可扩展性较差。

个性化折扣定义灵活性：解释器架构风格灵活性较好，可自定义规则以及自定义解释器，面向对象的架构风格可自定义调用，但灵活性不如解释器架构风格。

性能：面向对象的架构风格属于调用-返回型，性能较好，解释器架构风格需要对自定义的规则进行解释，性能较差。

综上所示，由于系统的核心功能为动态调整商品的折扣力度，提供个性化的打折促销活动等，对自定义的要求较高，且对系统性能不做过多考虑，故该系统更适合采用解释器架构风格，

23年必做

试题一

某网作为某电视台在互联网上的大型门户入口，某一年成为某奥运会中国大陆地区的特权转播商，独家全程直播了某奥运会全部的赛事，积累了庞大稳定的用户群，这些用户在使用各类服务过程中产生了大量数据，对这些海量数据进行分析与挖掘，将会对节目的传播及商业模式变现起到重要的作用。

该奥运期间需要对增量数据在当日概览和赛事回顾两个层面上进行分析。

其中，当日概览模块需要秒级刷新直播在线人数、网站的综合浏览量、页面停留时间、视频的播放次数和平均播放时间等千万级数据量的实时信息，而传统的分布式架构采用重新计算的方式分析实时数据，在不扩充以往集群规模的情况下，无法在几秒内分析出重要的信息。

赛事回顾模块需要展现自定义时间段内的历史最高在线人数、逐日播放走势、直播最高在线人数和点播视频排行等海量数据的统计信息，由于该奥运期间产生的数据通常不需要被经常索引、更新，因此要求采用不可变方式存储所有的历史数据，以保证历史数据的准确性。

【问题1】(8分)

请根据 Lambda 架构和 Kappa 架构特点，填写以下表格。

1：两 2：一 3：高 4：低 5：计算开销小 6：无法满足实时性 7：大 8：弱

对比内容	Lambda 架构	Kappa 架构
复杂度与开发、维护成本	需要维护(1)套系统(引擎),复杂度(3),开发、维护成本(3)	只需要维护(2)套系统(引擎),复杂度(4),开发、维护成本(4)
计算开销	需要一直运行批处理和实时计算，计算开销大	(5)
实时性	满足实时性	(6)
历史数据处理能力	批式全量处理，吞吐量(7),历史数据处理能力强	流式全量处理，吞吐量相对较低，历史数据处理能力(8)