2025年系统分析与设计理论知识及技能考核考试卷及答案

2025年系统分析与设计理论知识及技能考核考试卷及答案一、单项选择题（每题2分，共20分）1.以下哪项不属于需求工程中的“非功能性需求”？A.系统响应时间≤2秒B.用户界面支持多语言切换C.订单数据存储需符合GDPR规范D.购物车模块支持同时添加100个商品2.在UML建模中，用于描述系统动态行为、展示对象间消息传递顺序的图是？A.类图B.用例图C.序列图D.状态图3.某电商系统需要支持“双11”期间百万级并发请求，其架构设计的核心目标应优先考虑？A.可维护性B.可扩展性C.性能与吞吐量D.可测试性4.设计模式中，“将抽象部分与实现部分分离，使它们可以独立变化”对应的模式是？A.适配器模式B.桥接模式C.装饰器模式D.策略模式5.在结构化分析方法（SA）中，用于分解系统功能、描述数据流动的工具是？A.数据字典B.实体关系图（ER图）C.数据流图（DFD）D.控制流图6.敏捷开发（Agile）的核心价值观不包括？A.个体与交互胜过流程与工具B.可工作的软件胜过详尽的文档C.客户协作胜过合同谈判D.严格的阶段评审胜过快速迭代7.某银行核心交易系统要求“任何操作失败后，系统需自动回滚至操作前状态”，这体现了系统设计的？A.一致性原则B.原子性原则C.隔离性原则D.持久性原则8.以下关于用例（UseCase）的描述，错误的是？A.用例必须由参与者（Actor）触发B.一个用例可以包含多个子用例C.用例的“扩展（Extend）”关系表示基础用例在特定条件下执行扩展用例D.用例图仅用于描述系统外部可见的功能，不涉及内部实现9.微服务架构与单体架构的主要区别在于？A.微服务更依赖集中式数据库B.微服务通过API网关实现服务间通信C.单体架构更易于横向扩展D.微服务的部署单元是单个应用程序10.在系统设计中，“高内聚、低耦合”原则的主要目的是？A.降低系统复杂度，提高可维护性B.提升系统运行效率C.减少开发成本D.增强系统安全性二、填空题（每题2分，共20分）1.需求分析的三个层次包括业务需求、用户需求和__________。2.UML中的“泛化（Generalization）”关系对应面向对象中的__________机制。3.软件架构设计的“4+1视图”包括逻辑视图、开发视图、物理视图、进程视图和__________。4.设计模式中的“单例模式（Singleton）”主要解决__________问题。5.数据流图（DFD）的四个基本元素是外部实体、处理过程、数据存储和__________。6.敏捷开发的典型方法包括Scrum、XP（极限编程）和__________。7.系统测试的主要类型包括功能测试、性能测试、安全性测试和__________。8.在面向对象设计中，“依赖倒置原则（DIP）”要求高层模块不依赖低层模块，二者都应依赖__________。9.微服务架构中，服务间通信的常见模式有同步（如REST）和__________（如消息队列）。10.需求验证的常用方法包括评审、原型法和__________。三、简答题（每题8分，共40分）1.简述用例图的构成要素，并举例说明“包含（Include）”关系与“扩展（Extend）”关系的区别。2.比较瀑布模型与敏捷开发的适用场景，说明在哪些情况下更适合选择敏捷开发。3.什么是MVC模式？请分别描述Model、View、Controller的职责，并举例说明其在Web系统中的应用。4.系统设计中为什么需要考虑“可扩展性”？请结合云原生架构（如容器化、K8s）说明如何实现系统的水平扩展。5.需求分析阶段可能出现的常见问题有哪些？请提出至少3种避免需求偏差的方法。四、应用题（每题10分，共20分）1.某社区团购系统需要实现“用户下单”功能，需求如下：用户需登录后才能下单；下单时需选择收货地址（可新增/修改地址）；系统需校验库存（若库存不足，提示“商品售罄”）；下单成功后，提供订单号并发送短信通知用户。请根据以上需求：（1）绘制用例图（需包含参与者、用例及必要关系）；（2）设计该功能的类图（需包含关键类及类间关系）。2.某企业现有一套单体架构的ERP系统，随着业务扩张，系统出现以下问题：单次部署耗时2小时，影响业务迭代速度；部分模块（如采购、销售）修改后需重新测试整个系统；高并发时，财务模块（核心功能）与报表模块（非核心）竞争资源，导致核心功能响应延迟。请分析问题成因，并基于微服务架构提出改进方案（需说明服务拆分策略、通信方式及部署优化措施）。答案一、单项选择题1.D2.C3.C4.B5.C6.D7.B8.D9.B10.A二、填空题1.系统需求2.继承3.用例视图4.全局唯一实例5.数据流6.看板方法（Kanban）7.可靠性测试8.抽象9.异步10.测试三、简答题1.用例图的构成要素包括：参与者（Actor，如用户、外部系统）、用例（UseCase，如“下单”“登录”）、关系（包含、扩展、泛化）。“包含（Include）”关系：基础用例必须依赖被包含用例完成功能（如“下单”包含“校验库存”）；被包含用例是基础用例的必要步骤，不可独立存在。“扩展（Extend）”关系：扩展用例在特定条件下（如异常）添加到基础用例中（如“下单”在“库存不足”时扩展“提示售罄”）；扩展用例是可选的，可独立存在。2.瀑布模型适用场景：需求明确、变更少、对质量要求高（如航天软件）；强调阶段顺序，需完成前一阶段才能进入下一阶段。敏捷开发适用场景：需求模糊或易变、需快速响应市场（如互联网产品）；核心是迭代开发、客户持续参与。选择敏捷的情况：客户需求不明确、需要快速验证原型、团队沟通效率高。3.MVC模式（模型视图控制器）是一种分层架构模式：Model（模型）：负责业务逻辑与数据管理（如订单数据的增删改查）；View（视图）：负责数据展示与用户交互（如网页前端的订单详情页面）；Controller（控制器）：接收用户请求，调用Model处理业务，将结果传递给View渲染（如用户提交订单后，控制器调用Model校验库存，返回结果给View显示成功/失败）。Web系统中，用户通过View提交表单，Controller解析请求参数，调用Model处理业务逻辑（如扣减库存），最后Model返回数据给Controller，由Controller选择View模板渲染页面。4.可扩展性是指系统能通过增加资源（如服务器、模块）应对业务增长（如用户量、功能需求）。原因：业务规模扩大时，避免系统成为瓶颈；支持新功能快速集成；降低维护成本。云原生架构实现水平扩展：容器化（Docker）：将服务封装为轻量级容器，实现环境一致性；编排工具（K8s）：自动管理容器的部署、扩容、负载均衡；无状态设计：服务不保存用户会话，通过分布式缓存（如Redis）存储状态，支持任意实例处理请求；弹性伸缩：根据CPU/内存使用率或请求量，自动增加/减少容器实例数量（如K8s的HorizontalPodAutoscaler）。5.需求分析常见问题：需求模糊（如“系统要好用”未明确标准）；客户与开发团队理解偏差（如客户认为“快速”是1秒，开发团队认为是3秒）；需求遗漏（如未考虑多语言支持）；需求变更频繁（影响开发进度）。避免方法：采用原型法（开发可交互的简易版本，让客户直观验证需求）；编写清晰的需求规格说明书（使用用例、用户故事描述，明确验收标准）；定期组织需求评审（邀请客户、开发、测试多方参与，及时澄清歧义）；建立需求变更管理流程（评估变更影响，与客户协商优先级）。四、应用题1.（1）用例图：参与者：用户（User）、短信服务（外部系统）。用例：登录、下单、新增地址、修改地址、校验库存、发送短信通知。关系：“下单”包含“校验库存”（<<include>>）；“下单”包含“发送短信通知”（<<include>>）；“选择地址”扩展“新增地址”和“修改地址”（<<extend>>，当用户无地址或需修改时触发）；“下单”依赖“登录”（<<include>>，用户需先登录才能下单）。（2）类图：关键类：User（属性：用户ID、用户名；方法：登录）、Address（属性：地址ID、用户ID、详细地址；方法：新增、修改）、Order（属性：订单ID、用户ID、商品列表、状态；方法：提供订单号）、Inventory（属性：商品ID、库存数量；方法：校验库存）、SmsService（属性：接口地址；方法：发送通知）。类间关系：User与Address：关联（1对多，一个用户有多个地址）；Order与User：关联（1对1，订单属于用户）；Order与Inventory：依赖（Order调用Inventory的校验方法）；Order与SmsService：依赖（Order调用SmsService发送通知）。2.问题成因：单体架构所有模块耦合在一个应用中，部署时需整体打包，耗时且影响迭代；模块间强依赖，修改一个模块需重新测试整个系统，测试成本高；资源竞争：单体应用运行在同一进程/服务器，非核心模块（报表）占用资源影响核心模块（财务）性能。改进方案（微服务架构）：（1）服务拆分策略：按业务功能拆分为独立服务，如采购服务、销售服务、财务服务、报表服务。拆分原则：高内聚（如财务服务专注记账、结算）、低耦合（服务间通过API通信）。（2）通信方式：核心服务（财务）与非核心服务（报表）采用异步通信（如消息队列RabbitMQ），减少实时调用延迟；服务间同步调用使用轻量级RESTAPI或gRPC（提高性能）。（3）部署优化：容器化部署