简介本资源是面向软件工程专业学生及UML初学者的系统分析与设计复习备考资料聚焦UML核心概念辨析与典型试题精解助力快速掌握类图、交互图、关系建模等关键考点。压缩包为单个132KB的Word文档.doc内容结构清晰涵盖关联多重度判定、组合与聚合辨析、客户-订单业务建模、顺序图与协作图对比、高内聚设计原则、UML九种图的定位与选用、可见性与领域模型等12大高频知识点每题均附标准答案与原理详解。内容预览显示题目形式多样包括单选、图示绘制、填空与简答并延伸至GRASP设计模式、FURPS需求分类、统一过程阶段等拓展内容兼具基础巩固与应试提分价值。目前已有404人学习下载适合考前冲刺、课堂复习及自学查漏补缺。1. UML 不是画图软件而是系统设计的“交通指挥图”它不写代码却决定代码能不能跑通你有没有见过这样的场景一个团队花三周写完核心功能上线前一测发现订单模块根本连不上支付网关——不是代码有 bug而是当初没人说清“客户提交订单”这一步到底该由谁触发、谁校验、谁存库、谁通知大家各写各的接口对不上时序串不了最后全卡在集成环节推倒重来。UMLUnified Modeling Language统一建模语言就是为解决这种“人脑没对齐”的问题而生的。它不是编程语言也不是绘图工具它是一套标准化的视觉语法像城市里的红绿灯、斑马线和单行道标识——不造车但让所有车开发、测试、产品、客户能在同一张路网里安全、高效、无歧义地通行。它把模糊的“我觉得应该这样”变成可读、可验、可追溯的图形契约类图是建筑平面图用例图是用户动线图顺序图是快递配送时间表状态图是电梯运行逻辑图。你不需要靠嘴讲清楚“一个订单怎么从创建走到完成”只需画一张 SSD 图系统序列图所有人一眼就看出收款员发makeNewSale()系统回Sale created接着输入商品再endSale()……每一步谁发起、谁响应、数据怎么流清清楚楚。这份《UML系统分析与设计复习试题》不是考你背定义而是逼你用这套“交通语言”把真实业务逻辑翻译成机器能懂、人更懂的设计蓝图——它不直接产出代码但决定了代码写得出来、改得动、查得清、接得上。搞不懂 UML就像让一群没看过地图的司机在没有信号灯的十字路口同时起步。2. 关联多重度不是“有多少个”而是“必须有几个、最多几个”的硬约束UML 类图里最常被误解的符号就是那两个小小的数字1、0..*、1..5。它们看起来像数学题实则是系统骨架的“承重声明”。打个比方如果把类比作工厂里的工位那么关联多重度就是规定“这个工位必须配几个操作员、最多能连几台设备”的生产规程——少配不行超配违规写错直接导致系统“断链”。2.1 多重度的本质描述实例间强制存在的数量关系看这道真题“UML 中关联的多重度是指 ”选项 B 正确“一个类的实例能够与另一个类的多个实例相关联”。注意关键词是实例instance不是类、不是方法、不是属性。它回答的永远是同一个问题当我在内存里创建了一个 A 对象它 legally合乎设计规则能且只能关联几个 B 对象比如“客户”和“订单”每个订单Order 实例必须且只能属于 1 个客户Customer 实例→ 订单端标1每个客户Customer 实例可以有 0 个也可以有无数个订单 → 客户端标0..*这不是“大概率情况”而是设计契约如果你硬让一个订单指向两个客户系统在建模阶段就该报错如果你在代码里允许客户对象的订单列表为空那是符合0..*的但若你强制要求每个客户初始化时必须带至少一个订单那就违背了0..*应改为1..*。提示多重度永远成对出现写在关联线两端。它不描述“数据库里实际存了几条”而描述“模型允许的合法组合范围”。就像驾照规定“准驾车型”不是问你昨天开了几辆车。2.2 常见多重度标记及其业务含义标记含义典型业务场景代码映射示意Java1有且仅有一个订单 → 客户身份证 → 持有人private Customer customer; // 非 null0..1零个或一个用户 → 个人资料订单 → 优惠券private Profile profile; // 可为 null1..*至少一个无上限部门 → 员工文章 → 标签private ListEmployee employees; // size ≥ 10..*零个、一个或多个最常用客户 → 订单学生 → 选课private ListOrder orders; // size ≥ 02..5最少 2 个最多 5 个会议 → 必须有 2 名主持人最多 5 名private ListHost hosts; // size ∈ [2,5]注意*是通配符代表“无上限”不是“任意数”。它不等于0..*也不等于1..*单独写*是语法错误——必须带范围前缀。2.3 多重度与聚合/组合的关系别把“数量”和“归属”混为一谈很多初学者看到1..*就自动联想“这是聚合”看到1就觉得“肯定是组合”。这是典型误区。多重度只管数量不表生命周期。聚合空心菱形表示“整体-部分”关系但部分可独立存在如汽车-轮胎换胎不报废车组合实心菱形表示强归属部分生命周期由整体控制如公司-部门删公司即删所有部门两者都可以配1..*汽车有1..*个轮胎聚合订单有1..*个商品项组合。关键区别在语义不在数字。试题第 2 题说“类 A 由类 B 的一个实例和类 C 的 1 个或多个实例构成”这里“由……构成”是典型的组合语义A 挂了B/C 也该销毁所以类图中 A 到 B 画实心菱形1A 到 C 画实心菱形1..*。数字只是佐证不是判决依据。2.4 写错多重度的血泪后果从编译不报错到上线即崩你以为多重度只是画图时填个数字它直接影响代码健壮性。看一个真实翻车案例某电商系统订单类Order与物流单类Shipment关联标为0..*意思是“一个订单可有零个或多个物流单”支持分批发货。但开发时误写成1代码强制order.getShipment() ! null。结果促销期间大量订单因库存不足暂未发货getShipment()返回 nullNPE空指针异常雪崩。修复不是改一行代码而是回溯 UML 类图确认原始设计确实是0..*修改 Java 字段为可空类型Shipment shipment;所有调用处加判空if (order.getShipment() ! null) { ... }数据库外键约束从NOT NULL改为允许 null测试用例补全“无物流单”的分支。一个数字错五步返工。这就是为什么复习题反复考它——它不是知识点是设计防线的第一颗铆钉。3. 顺序图 vs 协作图时间轴上的快递单和办公室布局图的抉择UML 交互图里顺序图Sequence Diagram和协作图Collaboration Diagram新版 UML 中称“通信图”长得像双胞胎都画对象、都画消息箭头。但用错一个就像拿地铁线路图去规划办公室工位——图没错事办砸。它们根本不是“换种画法”而是为不同设计阶段、不同沟通目标量身定制的两种视角。3.1 顺序图给事件流装上秒表专治“谁先谁后没说清”顺序图的核心是生命线Lifeline 激活条Activation Bar 带序号的消息箭头。它把时间当作横坐标虽然没标刻度对象按列排开消息按垂直方向从上到下流动。看这道真题的 SSD 图系统序列图要求“1. 收款员启动一次销售makeNewSale()→ 2. 输入商品标识enterItem→ 3. 结束销售endSale→ 4. 顾客付款makePayment”。画出来就是四条竖线收款员、POS 系统、销售对象、顾客四组从上到下的箭头每步带编号1:,2:,3:,4:。你甚至能一眼看出endSale()必须等enterItem()返回后才能发makePayment()必须等endSale()完成才触发——时间依赖关系肉眼可判。[收款员] [POS系统] [销售] [顾客] | | | | |1:makeNewSale() | | |-------------------------| | | | | | | |2:enterItem(itemID,qty) | | |------------------------| | | | | | |3:endSale() | | |------------------------| | | | | | |4:makePayment(amount) | | |------------------------|注意顺序图中同步消息实线箭头表示发送方等待返回异步消息虚线箭头表示发完就走不等结果。考试常考这个细节。3.2 协作图给对象关系画张“办公室合影”专治“谁跟谁搭档没理清”协作图放弃时间轴转而把对象画成带标签的矩形[收款员:Cashier]用连线表示它们之间能通信即有关联或导航路径消息箭头直接标在连线上前面加序号1:,2.1:,2.2:。它不关心“enterItem是第几步”而强调“enterItem这个动作必须由收款员发给 POS 系统POS 系统再转发给销售对象”。还是上面的销售流程协作图画出来是收款员连 POS 系统标1:makeNewSale()POS 系统连销售对象标2:enterItem(...)销售对象连顾客标4:makePayment(...)。你会发现对象间的连接关系一目了然——哪些对象必须能互相访问哪些是中间协调者哪些是纯数据提供者这对设计“低耦合”架构至关重要。3.3 什么时候该用顺序图什么时候必须上协作图场景推荐图表原因复习题线索梳理用例主成功场景的执行步骤如“用户登录”完整流程顺序图时间顺序是核心需明确前置条件、返回值、异常分支题干含“按时间顺序”“事件发生顺序”“步骤”设计高内聚、低耦合的类职责分配如 GRASP 中的“控制器”模式协作图重点在“谁该响应哪个消息”需看清对象间协作网络题干问“谁负责处理系统事件”“如何降低依赖”评审接口契约确保前后端时序一致顺序图前端发请求、后端处理、返回结果三步缺一不可题干出现makeNewSale(),endSale()等具体方法名重构微服务间调用减少循环依赖协作图服务 A 调 BB 调 CC 又调 A连线交叉即暴露风险题干强调“对象组织结构”“消息传递路径”提示UML 规范允许两者互转但转换后信息会丢失。顺序图转协作图时间序号变成1.1,1.2等嵌套编号但“哪条消息并发执行”可能模糊协作图转顺序图必须人为指定对象排列顺序否则无法确定时序。所以先想清楚你要解决什么问题再选图——不是为了画图而画图。3.4 易混概念辨析顺序图、协作图、状态图、活动图四张图的生死边界初学者常把四种行为图搅成一锅粥。记住这张“决策树”考试不迷路问题答案关键区分点复习题陷阱“系统对外提供哪些功能”谁用做什么用例图Use Case Diagram画 Actor 和椭圆用例连线表示使用关系。不涉及内部实现题干说“描述系统与外部用户交互”必选用例图题17、38、54“某个对象一生经历哪些状态变化”如订单新建→已支付→发货中→已完成状态图State Diagram画圆角矩形状态、带事件标签的箭头转移。聚焦单个对象生命周期题干出现“状态”“生命周期”“事件触发”“一组对象协作完成一件事的步骤”多对象参与有明确起止顺序图 或 协作图两者都是交互图但视角不同见上文。必须有≥2个对象题干含“对象间交互”“消息传递”“SSD 图”“一个复杂流程的执行逻辑”含分支、循环、并行如“审核流程经理批→总监批→财务付”活动图Activity Diagram用圆角矩形活动、菱形判断、粗线分叉/汇合。本质是带条件的流程图可单对象也可多对象题干说“工作流”“并行任务”“业务流程”常见误区❌ 把状态图当顺序图用状态图里没有“消息”只有“事件”不能画customer → order: create()这种跨对象调用。❌ 在协作图里标时间协作图不承诺时序2.1:和2.2:只表示同级分支谁先谁后不确定。❌ 用活动图描述对象交互活动图的“泳道”Swimlane虽可标对象但核心是活动流不是对象间消息流。❌ 认为顺序图必须画“返回消息”UML 规范中返回消息虚线箭头是可选的只在需要强调返回值或异步回调时才画。4. 领域模型 vs 设计模型别把“现实世界”和“程序员脑内世界”画混了复习题里反复出现“领域模型”Domain Model、“概念类”Conceptual Class、“类图”Class Diagram很多同学边做题边嘀咕“不都是画类和关系吗有啥区别”——区别大了。这就像建筑师画的“小区实景效果图”和“水电管线施工图”前者让你看懂“这楼住人、那楼是超市”后者告诉你“插座离地30cm、水管走墙内”。混淆二者轻则需求理解偏差重则系统与业务脱节。4.1 领域模型照着现实世界拍的“概念快照”不许出现代码味领域模型也叫概念模型的目标只有一个忠实地捕捉业务领域的核心概念、它们的属性、以及彼此间的真实关系。它诞生于需求分析阶段使用者是业务专家、产品经理、分析师绝不是程序员。所以它有铁律✅ 只用业务语言Customer客户、Order订单、Product商品、Inventory库存❌ 禁用技术词汇DAO、Service、DTO、Controller、JDBC、Redis✅ 属性是业务属性Customer.name、Order.totalAmount、Product.price❌ 不出现技术属性Customer.idID 是数据库概念领域里叫“客户编号”或直接不用、Order.statusCode状态是业务概念应为Order.status: OrderStatus枚举✅ 关系是业务关系“客户提交订单”、“订单包含商品项”❌ 不画技术关系“OrderService 调用 OrderDAO”。看题15“领域模型是一组表示__A__在设计工作中广泛用来启发设计软件对象。”答案 A “真实世界的概念类”——点破本质。题44更直白“领域模型是一组表示真实世界的16不是17的模型。”答案16概念类17软件部件。题50直接定义“领域模型又称为C概念模型”。提示找概念类有两个野路子题18、23一是扫业务描述里的名词短语“顾客”“POS 收款台”“收款员”“销售”“商品”“商品说明”——题20答案二是查概念类类别表如人员、地点、组织、设备、事务、角色、规格、现象…。只要这个词在业务对话里真实存在、能被业务方理解它就可能是概念类。4.2 设计模型程序员脑内的“作战沙盘”必须带技术烙印设计模型以类图为代表是领域模型的“技术转译版”。它出现在系统设计阶段使用者是开发工程师。它必须回答“这些概念怎么用 Java/Python/Go 实现怎么存怎么交互怎么应对变化”所以它必然带技术味✅ 出现技术类OrderService业务逻辑层、OrderRepository数据访问层、OrderDTO传输对象✅ 属性含技术细节Order.id: Long主键类型、Order.createdAt: LocalDateTime时间格式、Order.version: Integer乐观锁✅ 关系含技术约束Order与OrderRepository是「依赖」OrderService用new OrderRepository()Order与OrderItem是「组合」Order销毁OrderItem必销毁✅ 加入设计模式OrderService实现OrderStrategy接口策略模式、OrderFactory创建Order工厂模式。题7、16、39都在考这个分层G类图是静态设计视图B用例图组织行为C序列图和E协作图是动态交互图。题39更明确“类图用于说明系统的静态设计视图构件图用于说明静态实现视图部署图用于说明体系结构的静态实施视图。”4.3 从领域模型到设计模型一次不能跳两步的“翻译工程”很多项目失败源于想一步到位——拿着用户说的“客户下单”直接画出CustomerController、OrderServiceImpl、MyBatis OrderMapper。这就像没学过拼音直接写论文。正确路径是三步走领域建模题66列出候选概念类客户、订单、商品→ 画领域模型图标属性、关联→ 必要时加属性客户有姓名、电话订单有日期、总金额识别设计元素基于领域模型思考“哪些概念需要持久化”→Entity、“哪些行为需要封装”→Service、“哪些数据要跨层传输”→DTO应用设计原则题24、GRASP用“信息专家”原则决定Order.totalAmount计算放Order类里用“控制器”原则决定makeNewSale()由SaleController处理用“高内聚”原则把订单创建、修改、取消放在OrderService不塞进CustomerService。题21的 SSD 图系统序列图就是典型桥梁它站在“系统黑盒”视角题51“不对系统内部结构与功能进行描述”只画外部参与者收款员、顾客和系统边界POS 系统消息是makeNewSale()这样的业务操作名不涉及OrderDao.save()这样的技术细节。它既不是纯领域没画内部对象也不是纯设计没画 DAO/Service而是承上启下的契约。4.4 易混概念辨析领域模型、用例模型、概念模型、设计模型谁是谁的爹概念定义产出物使用者与领域模型关系复习题锚点领域模型Domain Model描述业务领域中真实存在的概念、属性、关系的模型概念类图无技术词业务专家、分析师本体其他模型的源头题15、44、50、67用例模型Use Case Model描述系统功能需求的集合即“谁用系统做什么”用例图 用例描述文档Brief/Casual/Fully Dressed产品经理、用户驱动领域建模用例中的名词常是概念类题67“用况描述系统使用过程定义系统责任”题48、67、73概念模型Conceptual Model领域模型的同义词强调“非技术性”同领域模型同领域模型等价题50 直接说“领域模型又称为概念模型”题50设计模型Design Model将领域模型转化为可实现的技术方案的模型类图含 Service/DAO、序列图含技术对象、组件图开发工程师领域模型的后代继承概念增加技术实现细节题7、16、39、60常见误区❌ 把用例图当领域模型用例图里Actor角色不是概念类Login用例不是概念类它们是行为容器。❌ 在领域模型里画interface或stereotype领域模型不关心接口实现只关心“客户能下单”这个事实。❌ 认为设计模型必须 1:1 对应领域模型现实中一个领域概念Order可能拆成OrderEntity存库、OrderVO前端展示、OrderCommand命令三个设计类。❌ 用设计模型代替领域模型与客户沟通跟客户说“我们用 Spring Boot MyBatis 实现订单微服务”客户只会懵。要说“客户提交订单后系统实时生成单号、计算总价、扣减库存”。5. GRASP 与 GoF 设计模式不是炫技的咒语而是防翻车的检查清单复习题里“GRASP”和“GoF 设计模式”像两座大山堆满“信息专家”“创建者”“策略模式”“适配器模式”……很多同学死记硬背考完就忘。其实它们根本不是“高级技巧”而是前辈踩坑后总结的防翻车检查清单——当你写代码前对着它自问三句就能避开 80% 的烂设计。5.1 GRASP五条朴素原则专治“这个类该写在哪”的灵魂拷问GRASPGeneral Responsibility Assignment Software Patterns是职责分配的通用原则诞生于面向对象设计初期比 GoF 模式更底层、更普适。它不教你怎么写代码而是教你怎么把事情分派给对象。题24、52、83 都在考它。5.1.1 信息专家Information Expert谁有数据谁干活原则把职责分配给拥有执行该职责所需信息属性、关联的那个类。例子计算订单总价Order类有ListOrderItem和OrderItem.price那calculateTotal()方法就该在Order类里而不是让Customer类去遍历算。翻车现场把Order.totalAmount存数据库但calculateTotal()放OrderService里——OrderService没有OrderItem数据每次都要查库性能爆炸。检查清单写新方法前先问“这个方法需要哪些数据这些数据在哪个类里就放那儿。”5.1.2 创建者Creator谁用得多谁生娃原则类 A 应该创建类 B 的实例如果 A “包含”或“聚合”B或 A 记录 B 的实例或 A 拥有初始化 B 的数据。例子Order包含ListOrderItem那OrderItem的创建就该由Order类的addItem()方法负责items.add(new OrderItem(...))而不是让OrderServicenew 出来再塞进去。翻车现场OrderService.createOrder()里new OrderItem()然后order.addItem(item)——违反聚合关系Order失去对OrderItem生命周期的控制。检查清单new 一个对象前先看“这个新对象属于哪个现有对象的组成部分就让那个对象生它。”5.1.3 高内聚 低耦合一个类只干一件大事且尽量少求人高内聚题6、83一个类的职责高度相关共同服务于一个明确目的。Order类管订单数据、计算、状态流转但不管“发邮件通知客户”那是NotificationService的事。低耦合题24类之间依赖尽可能弱。OrderService不该直接 newEmailSender而应通过接口NotificationService依赖这样换微信通知也不改代码。翻车现场OrderService里既有calculateTotal()又有sendEmail()还有saveToDB()还有callPaymentAPI()——一个类干五件事改邮件逻辑就得测全部。检查清单一个类超过 7 个方法超过 3 个 public 属性赶紧拆。每次加新方法先看“这事和本类核心职责有关吗”5.1.4 控制器Controller入口请求交给最薄的那层皮原则把处理系统事件如用户点击、API 请求的职责分配给一个不代表具体业务实体的“控制器”类。它不存数据只协调。例子用户点击“提交订单”OrderController接收请求调用OrderService.createOrder()再返回结果。OrderController不做计算、不查库、不发邮件。翻车现场Order类里写public void handleCreateRequest(HttpServletRequest req)——实体类入侵了 Web 层彻底乱套。检查清单收到外部请求HTTP、MQ、定时任务第一反应不是写业务逻辑而是“该交给哪个 Controller”5.2 GoF 设计模式针对高频翻车场景的“标准维修包”GoFGang of Four模式是 GRASP 原则在具体场景下的落地模板。题35、39、79 都在考它。记住模式不是目标是解药。先有病设计痛点再开药模式。痛点你正在写的代码很痛苦解药对应模式核心思想复习题线索“这个算法经常变每次改都要动主流程”如不同会员等级用不同折扣规则策略模式Strategy定义算法族分别封装成类让它们实现同一接口主流程只依赖接口题35“适应算法或规则的频繁变更”“我需要一个全局唯一的配置管理器但怕别人 new 出一堆”单例模式Singleton私有构造 静态 getInstance() 方法保证全局唯一实例题35“如何使一个类严格地只有一个实例”“我有一堆相似对象文件、文件夹想用统一方式处理计算大小、列出内容”组合模式Composite让“叶子”文件和“容器”文件夹实现同一接口客户端无需区分题35“按处理原子对象的方式处理组合对象”“一个对象变了一堆对象要跟着刷新如股票价格变所有图表要重绘”观察者模式Observer主体Subject维护观察者Observer列表状态变时遍历通知题35“维护对象间一致性”“老系统接口太难用process(String data)新系统要调它但新接口是handle(DataObject obj)”适配器模式Adapter写个新类Adapter实现新接口内部调用老接口做数据转换题35“解决不兼容接口问题”注意题35 中把观察者模式写成 “Composite”是原文笔误正确应为 “Observer”。复习时务必核对概念别被笔误带偏。5.3 易混概念辨析GRASP、GoF、UML 图三者的协作关系工具定位何时用如何配合复习题体现GRASP 原则设计哲学职责分配的底层逻辑写任何类、任何方法前它指导你“为什么这么设计”。比如用“信息专家”原则决定calculateTotal()放Order类再用“控制器”原则决定谁调用它题24、42、52考 GRASP 本身、题60UP 阶段中“分配职责”GoF 模式解决方案模板针对特定痛点的标准写法发现重复出现的设计难题时它是 GRASP 的具象化。比如“算法易变”痛点用“信息专家”原则知道该把算法逻辑抽出去再用“策略模式”模板实现题35、39、79考模式名、问题、解法UML 图沟通载体把设计思想可视化表达需求分析、设计评审、团队对齐时它画出 GRASP 和 GoF 的结果。比如用类图画出Strategy接口和ConcreteStrategyA/B类用顺序图画出Controller → Service → Strategy的调用链题7、16、39考图的作用、题21SSD 图体现控制器职责常见误区❌ 为用模式而用模式没痛点硬套单例导致测试困难、内存泄漏。❌ 把 GRASP 当模式GRASP 是原则WhyGoF 是方案How不能说“我用了信息专家模式”。❌ 用 UML 图替代思考画了一堆类图但没想清OrderService和OrderRepository谁依赖谁图再美也是空中楼阁。❌ 认为 GRASP 过时微服务时代GRASP 的“低耦合”“高内聚”比以往更重要——服务间就是靠弱依赖活着。6. 什么时候该画 UML 图什么时候该合上本子写代码我带过不少刚学 UML 的开发者他们有个共同习惯拿到需求立刻打开绘图工具吭哧吭哧画上两小时类图、顺序图、用例图然后兴冲冲说“图全了可以开工了”结果写到一半发现订单状态流转没考虑“支付超时自动取消”图里没画客户信息修改要同步到 CRM图里没连促销期间并发下单库存扣减逻辑没在序列图里体现……最后图推倒代码重写时间全耗在返工上。UML 图不是装饰画它的价值只在精准暴露设计盲区。我的血泪经验是画图前先问自己三个问题画图后必须做一次“反向验证”。否则图画得越漂亮坑挖得越深。6.1 画图前的“三问”拒绝无效绘图问题为什么问不问的后果复习题对应点① 这个图要解决当前哪个具体困惑UML 是本文还有配套的精品资源点击获取