🎯题库练习

{"bank":[{"analysis":"进程视图关注并发、同步、性能与吞吐（面向系统集成人员）；逻辑视图关注对象与职责，开发视图关注代码组织，物理视图关注部署拓扑。","answer":"B","chapter":"架构·基础与风格","difficulty":2,"explain":{"A":"逻辑视图描述功能与对象模型。","C":"开发视图描述模块与包的组织。","D":"物理视图描述硬件与部署拓扑。"},"id":"arch-01-001","options":["逻辑视图","进程视图","开发视图","物理视图"],"source":"chapter","stem":"4+1 视图模型中，用于描述并发、同步与性能、面向系统集成人员的视图是？","subject":"综合知识","type":"single"},{"analysis":"数据依次流经独立处理单元（过滤器）、由管道连接，是典型的管道-过滤器（数据流）风格。","answer":"B","chapter":"架构·基础与风格","difficulty":2,"explain":{"A":"调用/返回风格强调过程调用与返回（如分层、面向对象）。","C":"仓库风格以共享数据为中心（如数据库、黑板）。","D":"虚拟机风格如解释器、规则系统。"},"id":"arch-01-002","options":["调用/返回风格","数据流风格（管道-过滤器）","仓库风格","虚拟机风格"],"source":"chapter","stem":"某系统各处理环节独立完成一种数据转换，数据依次流经各环节。该架构风格属于？","subject":"综合知识","type":"single"},{"analysis":"事件驱动通过事件发布-订阅解耦组件，扩展性好；但控制流由事件触发、整体行为不易预测。","answer":"B","chapter":"架构·基础与风格","difficulty":2,"explain":{"A":"强耦合与明确调用是调用/返回风格的特征。","C":"以共享数据为中心属仓库风格。","D":"事件驱动通常为异步。"},"id":"arch-01-003","options":["组件间强耦合、调用关系明确","通过事件发布-订阅实现松耦合，但控制流不确定","以共享数据为中心协作","必须采用同步调用"],"source":"chapter","stem":"事件驱动（隐式调用）架构风格的主要特点是？","subject":"综合知识","type":"single"},{"analysis":"外观模式为复杂子系统提供统一的高层接口，简化客户端调用；适配器用于接口转换，装饰器用于动态增加职责。","answer":"B","chapter":"架构·分析与设计","difficulty":2,"explain":{"A":"适配器解决接口不兼容问题。","C":"装饰器在不改变接口的前提下增强功能。","D":"观察者用于一对多的状态通知。"},"id":"arch-02-001","options":["适配器","外观（Facade）","装饰器","观察者"],"source":"chapter","stem":"某系统需要在不修改原有子系统代码的前提下，为其提供统一、简化的高层调用入口。最合适的设计模式是？","subject":"综合知识","type":"single"},{"analysis":"策略模式把可互换算法封装为独立类并可在运行时切换；单例控制实例唯一，代理控制访问，组合表达整体-部分结构。","answer":"A","chapter":"架构·分析与设计","difficulty":2,"explain":{"B":"单例用于保证唯一实例。","C":"代理用于控制对象的访问。","D":"组合用于树形结构表达。"},"id":"arch-02-002","options":["策略（Strategy）","单例","代理","组合"],"source":"chapter","stem":"某系统支持多种计价算法并需在运行时切换。最合适的设计模式是？","subject":"综合知识","type":"single"},{"analysis":"用例图描述参与者与系统提供的功能，是需求阶段的核心视图；类图描述静态结构，时序图描述交互顺序，状态图描述状态变迁。","answer":"B","chapter":"架构·分析与设计","difficulty":2,"explain":{"A":"类图属结构图，描述类与关系。","C":"时序图属行为图，描述对象交互顺序。","D":"状态图描述对象状态变迁。"},"id":"arch-02-003","options":["类图","用例图","时序图","状态图"],"source":"chapter","stem":"UML 中用于描述参与者与系统功能、通常出现在需求阶段的图是？","subject":"综合知识","type":"single"},{"analysis":"同时影响多个质量属性（性能提升、可修改性下降）的决策点是**权衡点**；仅影响单个属性的为敏感点。","answer":"B","chapter":"架构·质量属性与评估","difficulty":3,"explain":{"A":"敏感点只对某一质量属性有显著影响。","C":"非风险点是已确认可接受的决策。","D":"该决策与质量属性直接相关。"},"id":"arch-03-001","options":["敏感点","权衡点","非风险点","无关决策"],"source":"chapter","stem":"某架构决策在提升系统性能的同时降低了可修改性。该决策点属于？","subject":"综合知识","type":"single"},{"analysis":"ATAM（架构权衡分析方法）在场景基础上系统识别敏感点、权衡点与风险点；SAAM 更早且侧重场景评估，CBAM 引入成本效益分析。","answer":"B","chapter":"架构·质量属性与评估","difficulty":2,"explain":{"A":"SAAM 是最早的场景评估方法。","C":"CBAM 在 ATAM 基础上引入经济性分析。","D":"功能点分析用于规模估算，不是架构评估方法。"},"id":"arch-03-002","options":["SAAM","ATAM","CBAM","功能点分析"],"source":"chapter","stem":"围绕质量属性场景识别敏感点、权衡点与风险点，并分析属性取舍的架构评估方法是？","subject":"综合知识","type":"single"},{"analysis":"质量属性场景需包含刺激源、刺激、环境、制品、响应与响应度量；B 给出了环境、刺激与**可度量**的响应（2 秒）。","answer":"B","chapter":"架构·质量属性与评估","difficulty":2,"explain":{"A":"「良好」「尽量」不可度量。","C":"缺少度量指标与场景要素。","D":"属易用性表述且不可度量。"},"id":"arch-03-003","options":["系统应具有良好的响应速度","在正常工作负载下，用户发起查询后系统应在 2 秒内返回结果","系统应尽量少出错","系统应易于使用"],"source":"chapter","stem":"可度量是质量属性场景的必要条件。下列最符合「性能」场景写法的是？","subject":"综合知识","type":"single"},{"analysis":"CAP 指出一致性、可用性、分区容错性不可同时完全满足；分布式系统通常必须容忍分区（P），在 C/A 间权衡；BASE 通过基本可用、软状态与最终一致性实现灵活性。","answer":"B","chapter":"架构·分布式与新技术","difficulty":2,"explain":{"A":"三者不可同时完全满足。","C":"BASE 主张最终一致而非强一致。","D":"两者是不同层面的理念。"},"id":"arch-04-001","options":["分布式系统可以同时完全满足 CAP 三者","分布式系统通常必须容忍分区，在一致性与可用性之间取舍；BASE 是弱一致性实践","BASE 强调强一致性","CAP 与 BASE 含义相同"],"source":"chapter","stem":"关于 CAP 与 BASE，下列说法正确的是？","subject":"综合知识","type":"single"},{"analysis":"RTO（Recovery Time Objective）关注「多久恢复」，RPO（Recovery Point Objective）关注「可容忍丢失多少数据」。","answer":"B","chapter":"架构·分布式与新技术","difficulty":2,"explain":{"A":"两个指标的含义被互换了。","C":"可用性百分比是 SLA 指标，不是 RTO/RPO。","D":"备份周期是实现 RPO 的手段之一。"},"id":"arch-04-002","options":["RTO 表示可容忍的数据丢失量，RPO 表示恢复所需时间","RTO 表示恢复时间目标，RPO 表示恢复点目标（可容忍的数据丢失量）","二者都表示可用性百分比","二者都表示备份周期"],"source":"chapter","stem":"在容灾指标中，RTO 与 RPO 分别表示？","subject":"综合知识","type":"single"},{"analysis":"消息中间件通过异步解耦与流量缓冲实现削峰填谷；它不替代事务，反而引入最终一致性问题。","answer":"B","chapter":"架构·分布式与新技术","difficulty":2,"explain":{"A":"持久化只是消息中间件的特性之一，不是题干强调的作用。","C":"异步化通常降低即时一致性。","D":"消息队列不能替代数据库事务。"},"id":"arch-04-003","options":["数据持久化","异步解耦与削峰填谷","提升强一致性","替代数据库事务"],"source":"chapter","stem":"某电商系统通过消息队列把下单请求异步化，避免数据库被瞬时流量击垮。这主要体现消息中间件的哪种作用？","subject":"综合知识","type":"single"},{"analysis":"可用性＝MTBF÷(MTBF＋MTTR)＝2000÷2020≈99.0%（精确约 99.01%）。","answer":"A","chapter":"架构·可靠性与性能","difficulty":3,"explain":{"B":"99.9% 需要更小的 MTTR（如 MTTR＝2 小时）。","C":"99.99% 对应 MTTR 约 0.2 小时，与题给不符。","D":"90% 远低于计算结果。"},"id":"arch-05-001","options":["99.0%","99.9%","99.99%","90.0%"],"source":"chapter","stem":"某系统 MTBF＝2000 小时、MTTR＝20 小时。其可用性约为？","subject":"综合知识","type":"single"},{"analysis":"MTTR 取决于检测与恢复速度：完善监控告警、自动化切换与回滚可显著缩短修复时间；冗余只提升 MTBF 或缩短切换时间，接口不同。","answer":"B","chapter":"架构·可靠性与性能","difficulty":2,"explain":{"A":"缺少监控则故障发现慢，MTTR 反而变长。","C":"注释率与故障恢复速度无直接关系。","D":"延长备份周期会增大 RPO，不缩短 MTTR。"},"id":"arch-05-002","options":["增加服务器数量但不做监控","建立完善的监控告警与自动故障转移/回滚机制","提高代码注释率","延长数据备份周期"],"source":"chapter","stem":"为缩短系统的 MTTR（平均修复时间），最有效的架构措施是？","subject":"综合知识","type":"single"},{"analysis":"重试、超时重发属于**时间冗余**：以额外时间换取成功率；硬件冗余如双机热备，信息冗余如校验码，软件冗余如多版本程序设计。","answer":"D","chapter":"架构·可靠性与性能","difficulty":2,"explain":{"A":"硬件冗余指设备双份（如双电源、双机）。","B":"软件冗余指软件多版本或多实例。","C":"信息冗余指校验码、纠错码等。"},"id":"arch-05-003","options":["硬件冗余","软件冗余","信息冗余","时间冗余"],"source":"chapter","stem":"下列冗余类型中，采用重试与超时重发机制属于？","subject":"综合知识","type":"single"},{"analysis":"缓存前置、池化减负、异步削峰是提升吞吐的常规手段；同时必须设计缓存失效/更新策略以避免一致性风险。","answer":"B","chapter":"架构·可靠性与性能","difficulty":2,"explain":{"A":"取消索引会显著降低查询性能。","C":"关闭监控会掩盖问题、降低可用性保障能力。","D":"同步串行会降低并发能力。"},"id":"arch-05-004","options":["直接扩容数据库主库并取消索引","引入缓存、连接池与异步处理，并设计缓存一致性策略","关闭监控以降低开销","把所有业务改为同步串行处理"],"source":"chapter","stem":"为提升系统吞吐量，下列措施中见效最直接且风险相对可控的是？","subject":"综合知识","type":"single"},{"analysis":"架构案例的核心是「决策 + 依据」：所选风格须与题干的质量属性诉求和约束对应，只给结论或罗列风格都难以得分。","answer":"B","chapter":"架构·案例与论文","difficulty":2,"explain":{"A":"缺少理由，无法体现架构决策能力。","C":"罗列风格不等于做出选择。","D":"技术栈名称不是架构风格选择。"},"id":"arch-06-001","options":["只写「采用微服务架构」","明确所选风格，并结合性能、可用性、可修改性等质量属性与项目约束说明理由","罗列所有架构风格","只写技术栈名称"],"source":"chapter","stem":"架构案例题要求「选择架构风格并说明理由」。最易得分的作答方式是？","subject":"综合知识","type":"single"},{"analysis":"架构论文强调技术方案深度：架构分层/组件划分、关键技术机制与选型理由、量化效果；项目背景仍必须具备。","answer":"B","chapter":"架构·案例与论文","difficulty":2,"explain":{"A":"字数要求相近，关键在于技术深度。","C":"项目背景是论文必备要素。","D":"只写管理过程会偏离架构主题。"},"id":"arch-06-002","options":["字数更多","体现技术选型理由与关键技术机制（技术深度）","不需要项目背景","只写管理过程即可"],"source":"chapter","stem":"与高项（信息系统项目管理师）论文相比，系统架构设计师论文最突出的要求是？","subject":"综合知识","type":"single"},{"analysis":"量化指标能证明方案效果，并与质量属性一一对应，是架构论文的核心加分项。","answer":"B","chapter":"架构·案例与论文","difficulty":2,"explain":{"A":"堆砌名词缺少论证。","C":"只写背景缺少方案与效果。","D":"照抄概念没有项目实践。"},"id":"arch-06-003","options":["大段罗列技术名词","给出量化指标（如响应时间、QPS、可用性）并与质量属性对应","只描述项目背景","照抄教材概念"],"source":"chapter","stem":"撰写架构论文时，下列做法最能提升说服力的是？","subject":"综合知识","type":"single"},{"analysis":"技术选型部分要说清「为什么选它」：结合性能、可用性、成本、可维护性等维度与项目约束给出理由。","answer":"B","chapter":"架构·案例与论文","difficulty":2,"explain":{"A":"人员分工属项目管理内容。","C":"公司沿革与论文主题无关。","D":"会议安排不是技术选型内容。"},"id":"arch-06-004","options":["开发人员的姓名与分工","所选技术与架构方案的理由（对标质量属性与约束）","公司的历史沿革","项目验收会议的时间安排"],"source":"chapter","stem":"论文写作中，「技术选型」部分通常应重点说明？","subject":"综合知识","type":"single"},{"analysis":"管道过滤器属于数据流风格：数据在管道中流动，经过一系列过滤器逐步变换，各过滤器之间相对独立、可复用、便于并行处理。","answer":"A","chapter":"架构·基础与风格","difficulty":3,"explain":{"B":"调用/返回风格包括主程序—子程序、面向对象、分层等结构。","C":"独立构件风格包括进程通信与事件驱动（隐式调用）风格。","D":"仓库风格包括数据库系统、超文本系统与黑板系统。"},"id":"arch-01-004","options":["数据流风格","调用/返回风格","独立构件风格","仓库风格"],"source":"chapter","stem":"在软件架构风格中，「管道过滤器」风格属于下列哪一类？","subject":"系统架构设计师","type":"single"},{"analysis":"黑板风格由中心共享数据结构（黑板）与多个独立知识源组成，适用于信号处理、语音识别、图像识别等缺乏确定解法、需多知识源协同求解的问题。","answer":"B","chapter":"架构·基础与风格","difficulty":3,"explain":{"A":"顺序数据变换适合管道过滤器或批处理风格。","C":"严格分层属于分层风格，强调层间单向依赖。","D":"单次请求—响应属于调用/返回类风格。"},"id":"arch-01-005","options":["需要按顺序做数据变换的批处理","没有确定性求解算法、需要多知识源协同推理的问题","严格分层的企业信息系统","只需单次请求—响应交互的服务"],"source":"chapter","stem":"「黑板」架构风格最适合下列哪类应用？","subject":"系统架构设计师","type":"single"},{"analysis":"4+1 视图包括逻辑视图（功能与对象）、进程视图（并发、同步、进程通信）、开发视图（模块组织与静态结构）、物理视图（软硬件映射与部署），外加场景（用例）视图串联验证。","answer":"B","chapter":"架构·基础与风格","difficulty":3,"explain":{"A":"逻辑视图关注系统的功能需求与关键抽象（类、对象）。","C":"开发视图关注开发期的模块划分、包与层次组织。","D":"物理视图关注软件到硬件节点的部署与网络拓扑。"},"id":"arch-01-006","options":["逻辑视图","进程视图","开发视图","物理视图"],"source":"chapter","stem":"Kruchten 提出的「4+1 视图」中，用于描述系统并发与同步、进程通信的视图是？","subject":"系统架构设计师","type":"single"},{"analysis":"依赖倒置原则要求高层模块与低层模块都依赖于抽象，抽象不依赖细节，从而降低耦合、提高可扩展性与可测试性。","answer":"B","chapter":"架构·分析与设计","difficulty":3,"explain":{"A":"单一职责原则强调一个类只承担一项职责、只有一个引起变化的原因。","C":"里氏替换原则要求子类型可替换其基类型而不破坏程序正确性。","D":"接口隔离原则要求使用多个专门的小接口而非一个臃肿的总接口。"},"id":"arch-02-004","options":["单一职责原则（SRP）","依赖倒置原则（DIP）","里氏替换原则（LSP）","接口隔离原则（ISP）"],"source":"chapter","stem":"在面向对象设计原则中，「高层模块不应依赖低层模块，二者都应依赖抽象」体现的是？","subject":"系统架构设计师","type":"single"},{"analysis":"结构型模式用于处理类或对象的组合，包括适配器、桥接、组合、装饰器、外观、享元、代理等。","answer":"C","chapter":"架构·分析与设计","difficulty":3,"explain":{"A":"工厂方法属于创建型模式。","B":"观察者属于行为型模式。","D":"策略属于行为型模式。"},"id":"arch-02-005","options":["工厂方法（Factory Method）","观察者（Observer）","适配器（Adapter）","策略（Strategy）"],"source":"chapter","stem":"下列设计模式中，属于「结构型模式」的是？","subject":"系统架构设计师","type":"single"},{"analysis":"序列图（顺序图）以时间顺序展示对象之间的消息交互，常用于表达场景的实现过程与接口调用链。","answer":"C","chapter":"架构·分析与设计","difficulty":3,"explain":{"A":"用例图描述系统与外部参与者的功能关系。","B":"类图描述类的属性、方法与类之间的关系（静态结构）。","D":"部署图描述构件在硬件节点上的部署关系。"},"id":"arch-02-006","options":["用例图","类图","序列图（顺序图）","部署图"],"source":"chapter","stem":"在 UML 图中，用于描述对象之间按时间顺序的消息交互、强调调用次序的是？","subject":"系统架构设计师","type":"single"},{"analysis":"质量属性场景由刺激源、刺激、制品（环境中的被刺激对象）、环境、响应、响应度量六要素构成，用于把模糊的质量需求转化为可验证的表述。","answer":"A","chapter":"架构·质量属性与评估","difficulty":3,"explain":{"B":"这是对处理过程的通用描述，不是质量属性场景要素。","C":"这些是系统构成的描述性名词，不构成场景六要素。","D":"这是项目管理三要素的扩展表述，与质量属性场景无关。"},"id":"arch-03-004","options":["刺激源、刺激、制品、环境、响应、响应度量","输入、处理、输出、反馈、控制、约束","用户、任务、数据、界面、接口、部署","目标、范围、进度、成本、质量、风险"],"source":"chapter","stem":"质量属性场景的六个要素是？","subject":"系统架构设计师","type":"single"},{"analysis":"敏感点是实现某一特定质量属性所必须关注的架构决策点；权衡点会影响多个质量属性并需折中；风险点是可能导致问题的决策；非风险点是可接受的安全决策。","answer":"B","chapter":"架构·质量属性与评估","difficulty":3,"explain":{"A":"这是权衡点的定义。","C":"这是风险点的定义。","D":"与质量属性无关的细节不属于敏感点。"},"id":"arch-03-005","options":["影响多个质量属性、需要折中的架构决策","为实现某特定质量属性而需要重点关注的架构决策","可能导致风险的架构决策","与质量属性无关的普通设计细节"],"source":"chapter","stem":"在体系结构评估中，「敏感点」指的是？","subject":"系统架构设计师","type":"single"},{"analysis":"ATAM 通过质量属性效用树与场景分析，让利益相关者参与，识别敏感点、权衡点、风险点与非风险点，从而在多个相互制约的质量属性之间做权衡。","answer":"B","chapter":"架构·质量属性与评估","difficulty":3,"explain":{"A":"ATAM 面向多质量属性，不只针对性能。","C":"ATAM 用于架构设计阶段的评估，不是代码审查方法。","D":"ATAM 的核心产出正是风险与权衡点的识别。"},"id":"arch-03-006","options":["只评估性能单一属性","在多个质量属性之间识别权衡点，通过场景分析与利益相关者参与揭示风险","仅用于编码阶段的代码审查","只输出架构文档，不涉及风险识别"],"source":"chapter","stem":"ATAM（体系结构权衡分析方法）的核心特点是？","subject":"系统架构设计师","type":"single"},{"analysis":"API 网关作为所有外部请求的统一入口，承担路由转发、认证鉴权、限流熔断、协议转换与响应聚合等横切功能。","answer":"B","chapter":"架构·分布式与新技术","difficulty":3,"explain":{"A":"注册中心负责服务实例的注册与发现。","C":"配置中心负责配置的集中管理与动态推送。","D":"消息中间件用于异步通信与解耦，不承担统一入口职责。"},"id":"arch-04-004","options":["注册中心","API 网关","配置中心","消息中间件"],"source":"chapter","stem":"在微服务架构中，用于统一处理认证授权、限流熔断、路由与服务聚合的组件通常是？","subject":"系统架构设计师","type":"single"},{"analysis":"CAP 定理指出一致性（C）、可用性（A）、分区容错性（P）不可同时完全满足；分布式系统必须容忍分区（P），因而需在一致性（C）与可用性（A）之间取舍。","answer":"A","chapter":"架构·分布式与新技术","difficulty":3,"explain":{"B":"可扩展性不属 CAP 三要素。","C":"安全性不属 CAP 三要素。","D":"性能与可维护性不属 CAP 三要素。"},"id":"arch-04-005","options":["一致性与可用性","可用性与可扩展性","一致性与安全性","性能与可维护性"],"source":"chapter","stem":"根据 CAP 定理，当网络分区发生时，分布式系统必须在下列哪两者之间做取舍？","subject":"系统架构设计师","type":"single"},{"analysis":"下单后需通知多个下游系统属于典型的一对多异步场景：通过消息队列解耦，可避免同步调用链路过长、下游故障导致主流程失败，并支持削峰填谷。","answer":"B","chapter":"架构·分布式与新技术","difficulty":3,"explain":{"A":"登录鉴权要求实时同步响应，通常不经消息队列。","C":"CDN 分发属于内容加速，与异步解耦无关。","D":"精确查询要求低延迟同步返回，不适合异步化。"},"id":"arch-04-006","options":["用户登录时的身份验证","下单成功后需要通知库存、积分、物流多个下游系统","静态图片的 CDN 分发","数据库单条记录的精确查询"],"source":"chapter","stem":"下列场景中，最适合采用消息队列异步解耦的是？","subject":"系统架构设计师","type":"single"},{"analysis":"可用性 = MTBF /（MTBF + MTTR）= 9900 /（9900 + 100）= 99%。","answer":"C","chapter":"架构·可靠性与性能","difficulty":3,"explain":{"A":"90% 相当于 MTTR 远大于 MTBF 的情形。","B":"95% 与计算结果不符。","D":"99.9% 要求 MTTR 约为 MTBF 的千分之一，本例 MTTR 占比 1%，故为 99%。"},"id":"arch-05-005","options":["90%","95%","99%","99.9%"],"source":"chapter","stem":"某系统平均无故障时间 MTBF 为 9900 小时，平均修复时间 MTTR 为 100 小时，其可用性约为？","subject":"系统架构设计师","type":"single"},{"analysis":"并联系统可靠度 R = 1 −（1 − R₁）（1 − R₂）= 1 − 0.1 × 0.1 = 0.99，冗余设计显著提高可靠性。","answer":"C","chapter":"架构·可靠性与性能","difficulty":3,"explain":{"A":"0.81 是串联系统的可靠度（0.9 × 0.9）。","B":"并联冗余不会等于单个部件的可靠度。","D":"可靠度小于 1，不可能等于 1。"},"id":"arch-05-006","options":["0.81","0.9","0.99","1.0"],"source":"chapter","stem":"两个可靠度均为 0.9 的部件并联构成冗余系统（假定相互独立），系统可靠度约为？","subject":"系统架构设计师","type":"single"},{"analysis":"年可用性 99.99% 对应的年停机时间约为 365 × 24 × 60 × 0.01% ≈ 52.6 分钟；99.9% 约为 8.76 小时，99.999% 约为 5.26 分钟。","answer":"B","chapter":"架构·可靠性与性能","difficulty":3,"explain":{"A":"8.76 小时对应 99.9% 的可用性。","C":"5.26 分钟对应 99.999% 的可用性。","D":"31.5 秒对应约 99.9999% 的可用性。"},"id":"arch-05-007","options":["约 8.76 小时","约 52.6 分钟","约 5.26 分钟","约 31.5 秒"],"source":"chapter","stem":"某系统要求年可用性达到 99.99%，其年累计允许停机时间约为？","subject":"系统架构设计师","type":"single"},{"analysis":"论文摘要约 300 字，应概括项目背景、本人承担的角色与工作、采用的关键技术与方法以及取得的效果，使评阅人快速把握全文要点。","answer":"B","chapter":"架构·案例与论文","difficulty":3,"explain":{"A":"过于简略，无法体现项目与工作内容，易被判为内容空洞。","C":"抄写题目属违规且无信息量。","D":"摘要应简明，篇幅过大将挤占正文并影响结构评分。"},"id":"arch-06-005","options":["只写一句「本文讨论了某系统的架构设计」","简要说明项目背景、本人角色、采用的主要技术与方法及实施效果，篇幅约 300 字","直接抄写题目原文","详细展开技术细节，篇幅 1000 字以上"],"source":"chapter","stem":"系统架构设计师论文写作中，「摘要」部分的推荐写法是？","subject":"系统架构设计师","type":"single"},{"analysis":"论文评分重视项目真实性与个人贡献，应写明项目规模与背景、选型依据、遇到的具体问题与解决过程，并给出可量化的效果或指标改善。","answer":"B","chapter":"架构·案例与论文","difficulty":3,"explain":{"A":"只引用理论定义缺少实践内容，是常见低分原因。","C":"堆砌名词而无解释与对比，难以体现分析能力。","D":"方案罗列而不做取舍，说明缺乏决策与权衡能力。"},"id":"arch-06-006","options":["大量引用教材中的理论定义","结合具体项目说明规模、技术选型理由、实施中的问题与解决措施及量化效果","只写技术名词不做解释","把可能的方案全部罗列不做取舍"],"source":"chapter","stem":"论文正文中体现「真实项目经历」，最有效的写法是？","subject":"系统架构设计师","type":"single"},{"analysis":"此类题目考查权衡能力：应依据质量属性场景建立评价维度（性能、可用性、可修改性、成本与风险等），逐项对比后给出结论与理由，并说明实施风险与应对措施。","answer":"B","chapter":"架构·案例与论文","difficulty":3,"explain":{"A":"只给结论而无论证过程，缺少对比分析得分低。","C":"只比成本忽略质量属性，评价维度不完整。","D":"回避取舍不符合「选型」的答题要求。"},"id":"arch-06-007","options":["直接给出一个方案并说明它最先进","结合质量属性场景列出评价维度，对两方案做对比分析，给出选型结论与理由及风险应对","只比较价格与开发工作量","回避取舍，回答「两者都可以」"],"source":"chapter","stem":"在架构设计案例题中，要求「对两种候选架构方案进行选型」，最佳答题思路是？","subject":"系统架构设计师","type":"single"}],"cert":"ruankao-arch","chapters":[{"name":"架构·基础与风格","title":"第 1 章 · 架构基础与架构风格","url":"/ruankao-arch/books/jingjiang/arch-01-jichu/"},{"name":"架构·分析与设计","title":"第 2 章 · 系统分析与设计（UML · 设计模式）","url":"/ruankao-arch/books/jingjiang/arch-02-fenxi/"},{"name":"架构·质量属性与评估","title":"第 3 章 · 质量属性与架构评估","url":"/ruankao-arch/books/jingjiang/arch-03-zhiliang/"},{"name":"架构·分布式与新技术","title":"第 4 章 · 分布式、云原生与新技术架构","url":"/ruankao-arch/books/jingjiang/arch-04-fenbu/"},{"name":"架构·可靠性与性能","title":"第 5 章 · 系统可靠性、性能与安全设计","url":"/ruankao-arch/books/jingjiang/arch-05-kekaoxing/"},{"name":"架构·案例与论文","title":"第 6 章 · 案例分析专项与论文写作","url":"/ruankao-arch/books/jingjiang/arch-06-anli-lunwen/"}],"practiceUrl":"/ruankao-arch/practice/"}