2025年《UML面向对象分析、建模与设计》试卷及答案

2025年《UML面向对象分析、建模与设计》试卷及答案一、单项选择题（每题2分，共20分）1.在UML2.5规范中，以下哪项不属于结构型图？A.类图B.包图C.组件图D.状态图答案：D2.用例图中，“<<include>>”关系表示：A.主用例必须包含被包含用例的功能B.被包含用例可以替代主用例C.主用例扩展了被包含用例的功能D.两个用例为互斥关系答案：A3.类图中，若类A的某个属性类型为类B，且类B的生命周期不依赖类A，则A与B的关系最可能是：A.泛化B.依赖C.关联D.组合答案：C4.顺序图中，“alt”交互片段表示：A.并行执行的多个分支B.至少执行一次的循环C.互斥的多个分支D.可选的执行路径答案：C5.活动图中，泳道（Swimlane）的主要作用是：A.表示活动的执行顺序B.划分活动的责任主体C.标识活动的开始与结束D.描述活动的条件分支答案：B6.状态图中，若一个状态包含子状态，且子状态需全部完成后才能退出父状态，该状态应标记为：A.简单状态B.复合状态（顺序子状态）C.并发状态D.历史状态答案：B7.包图中，若包A依赖包B的接口但不依赖其实现，应使用：A.导入（Import）关系B.访问（Access）关系C.泛化关系D.组合关系答案：B8.协作图（通信图）与顺序图的核心区别在于：A.协作图强调交互的时间顺序，顺序图强调对象间的结构关系B.协作图使用消息编号表示顺序，顺序图使用时间轴表示顺序C.协作图仅支持同步消息，顺序图支持异步消息D.协作图用于需求分析，顺序图用于详细设计答案：B9.在面向对象设计中，“依赖倒置原则”要求：A.高层模块不依赖低层模块，二者依赖抽象B.抽象不依赖细节，细节依赖抽象C.类应仅有一个修改原因D.子类可以替换父类而不影响程序正确性答案：A10.以下哪项不是UML模型的核心元素？A.事物（Things）B.关系（Relationships）C.图（Diagrams）D.模式（Patterns）答案：D二、填空题（每空1分，共15分）1.用例图的基本元素包括参与者、用例和__________。答案：关系（或关联、泛化、包含、扩展）2.类图中，关联的多重性“”表示__________，“0..1”表示__________。答案：任意多个（或零到多个）；零或一个3.顺序图的垂直轴表示__________，水平轴表示__________。答案：时间顺序；参与交互的对象4.状态图的基本元素包括状态、转移、事件和__________。答案：动作（或活动、守卫条件）5.活动图中，__________节点用于合并多个并行执行的路径，__________节点用于拆分单一流程为多个并行路径。答案：汇合；分叉6.组件图主要描述系统的__________及其之间的依赖关系，部署图描述系统的__________及其之间的连接。答案：组件（或模块）；物理节点（或硬件节点）7.面向对象分析的核心任务是__________，面向对象设计的核心任务是__________。答案：建立系统的需求模型（或识别问题域中的对象与关系）；将需求模型转化为可实现的设计模型（或确定类的职责、接口与协作）8.UML2.x中，交互概览图是__________与__________的结合，用于描述复杂交互的整体流程。答案：活动图；顺序图三、简答题（每题8分，共32分）1.简述用例图中“扩展（<<extend>>）”关系与“包含（<<include>>）”关系的区别，并举例说明。答案：区别：包含关系（<<include>>）：主用例的功能必须通过被包含用例实现，被包含用例是主用例的必要组成部分（如“登录系统”用例包含“验证身份”用例）。扩展关系（<<extend>>）：被扩展用例在特定条件下（如异常、可选流程）可添加扩展用例的功能，扩展用例是可选的（如“正常购票”用例可扩展“学生票折扣”用例，仅当用户是学生时触发）。2.类图中，聚合（Aggregation）与组合（Composition）的核心差异是什么？请用图书馆系统举例说明。答案：核心差异：组合表示强拥有关系（部分对象生命周期由整体控制），聚合表示弱拥有关系（部分对象可独立于整体存在）。示例：组合：“图书馆”类与“书架”类（书架无法脱离图书馆存在，图书馆销毁则书架销毁）。聚合：“图书馆”类与“读者”类（读者可独立于图书馆存在，图书馆关闭不影响读者）。3.顺序图中如何表示异步消息与同步消息？二者在建模中的典型应用场景是什么？答案：表示方式：同步消息：实心箭头（→），调用方等待接收方返回结果。异步消息：空心箭头（→>），调用方不等待接收方响应。应用场景：同步消息：需要立即获取结果的操作（如“查询图书库存”，调用后需等待库存数据返回）。异步消息：无需立即响应的操作（如“发送通知邮件”，调用后继续执行其他逻辑）。4.简述在面向对象设计中“单一职责原则（SRP）”的含义，并说明违反该原则可能导致的问题。答案：含义：一个类应仅有一个引起它变化的原因（即一个类只负责一项职责）。问题：若违反SRP，类会承担多个不相关职责，导致：代码耦合度高，修改一个职责可能意外影响其他职责；测试复杂度增加（需覆盖所有职责的组合场景）；可维护性降低（职责边界模糊，难以定位问题）。四、分析设计题（共33分）（一）需求分析与用例建模（12分）某智能校园图书管理系统的核心需求如下：读者可通过PC或移动终端查询图书（书名/作者/ISBN）、预约图书（到馆取书或快递配送）、续借已借图书（限3次）；图书管理员可录入新书信息（书名、作者、ISBN、出版社、库存数量）、处理预约（标记图书为“已预约”并通知读者）、处理归还（更新库存并释放预约）；系统需记录所有操作日志（读者/管理员ID、操作时间、操作类型）。要求：1.识别系统的参与者（3分）；2.绘制用例图（需包含主要用例及必要关系，7分）；3.说明“预约图书”用例与“通知读者”用例的关系（2分）。答案：1.参与者：读者（包括PC用户、移动终端用户）、图书管理员、系统（日志记录器，可选）。2.用例图关键元素：参与者：读者、图书管理员；用例：查询图书、预约图书、续借图书、录入新书、处理预约、处理归还、记录操作日志；关系：“预约图书”包含“选择配送方式”（<<include>>）；“处理预约”扩展“通知读者”（<<extend>>，当预约成功时触发）；“记录操作日志”与所有用户操作（查询、预约、续借、录入、处理预约、处理归还）为依赖（<<trace>>）关系。3.关系说明：“处理预约”用例通过<<extend>>关系扩展“通知读者”用例，仅当预约处理成功时触发通知流程。（二）类图设计（10分）基于上述图书管理系统，设计核心类图，要求包含以下类及关系：图书（Book）：属性包括书名、作者、ISBN、出版社、库存数量、当前状态（可借/已借/已预约）；读者（Reader）：属性包括读者ID、姓名、联系方式、已借图书列表、剩余续借次数；图书管理员（Librarian）：属性包括工号、姓名；预约记录（Reservation）：属性包括预约ID、图书（关联Book）、读者（关联Reader）、预约时间、配送方式；操作日志（Log）：属性包括日志ID、操作人（关联Reader或Librarian）、操作时间、操作类型。要求：1.绘制类图（需标注类属性、关联关系及多重性）；2.说明Book与Reservation的关联类型及多重性（如1对多、多对多）。答案：1.类图关键设计：Book与Reservation：一对多（1..），一本图书可被多次预约（但同一时间只能有一个有效预约）；Reader与Reservation：一对多（1..），一个读者可预约多本图书；Reader与Book：一对多（0..），一个读者可借多本图书；Log与操作人（Reader/Librarian）：多对一（..1），一条日志对应一个操作人；Librarian与Book：一对多（0..），管理员可录入多本图书。2.Book与Reservation的关联类型为关联（Association），多重性为Book:1，Reservation:0..（一本图书可被多次预约，但同一时间可能仅有一个有效预约，具体需根据业务规则调整）。（三）顺序图设计（11分）针对“读者通过移动终端续借图书”场景，设计顺序图。场景描述：读者登录系统，选择“续借”功能，输入图书ISBN；系统验证读者身份（是否有效）、图书状态（是否已借且未超续借次数）；验证通过后，更新图书的到期时间（原到期日+30天），减少读者剩余续借次数（每次续借减1）；系统提供续借成功日志，向读者发送短信通知；验证失败时，返回错误提示（如“续借次数已用尽”）。要求：1.列出参与交互的对象（3分）；2.绘制顺序图（需包含消息流、条件分支，8分）。答案：1.参与对象：移动终端（ReaderApp）、读者（Reader）、图书管理系统（System）、图书（Book）、日志记录器（Logger）、短信服务（SMS）。2.顺序图关键消息流：ReaderApp→System：发送续借请求（ISBN、读者ID）；System→Reader：验证身份（同步消息，返回是否有效）；System→Book：查询当前状态（是否已借）；System→Reader：查询剩余续借次数（是否>0）；[条件：验