UML系统分析与设计复习：从类图到设计模式的完整考点链

简介《UML系统分析与设计复习试题详解》是一份面向软件工程、计算机及相关专业学生的UML复习资料可帮助备考者系统梳理统一建模语言在系统分析与设计中的核心考点。资源以单个doc文档整理压缩包大小约132KB轻量易用便于快速查阅与打印学习。文档从关联多重度、类关系判定、客户与订单实例分析、交互图对比等基础问题切入逐步覆盖类图、用例图、序列图、协作图的作用与区别并深入讲解高内聚度、可见性、领域模型、四种基本关系及GRASP模式等进阶知识每道试题均配有参考答案与详细解析。目前已有405人学习下载适合正在复习UML课程考试或准备相关认证的读者用作考前强化与查漏补缺材料。1. UML系统分析与设计复习全景图从类图多重度到设计模式的完整考点链UML系统分析与设计这门课看起来知识点分散有类图、用例图、顺序图、协作图、状态图、部署图还有GRASP原则和设计模式。但把历年的考试题摊开看一条清晰的主线就出来了——先用类图描述静态结构再用交互图描述动态行为用例图和领域模型负责连接需求与设计GRASP五原则和设计模式指导职责怎么分配最后用UP四阶段把整个过程串成迭代流程。关联多重度怎么读、顺序图和协作图差在哪、概念类怎么识别、哪个阶段定义大部分需求——这些几乎每次必考。这份复习笔记按模块重新组织考点适合正在备考的人拿着过一遍先建立全貌再逐模块吃透最后用易错点清单查漏补缺。2. 类图与多重度静态视图里的高频考点类图是UML考试里出现频率最高的图。围绕它展开的考题集中在三块多重度的读法、四种基本关系的辨别、概念类之间数量联系的推理。这一章按“读多重度 → 辨关系 → 推联系”的顺序把静态视图的考点捡干净。2.1 多重度先搞清楚它描述的是实例数量关联的多重度是指什么原题给过一道选择题正确答案是“一个类的实例能够与另一个类的多个实例相关联”。这道题看起来简单但它把多重度和“方法调用次数”“共享属性方法”混在一起出题专治概念不清。逐个看四个选项一个类有多个方法被另一个类调用——这说的是方法层面的调用和实例数量无关一个类的某个方法被另一个类调用的次数——调用频率同样不是多重度两个类具有相同的方法和属性——这描述的是继承或实现也不是关联多重度一个类的实例能够与另一个类的多个实例相关联——正确答案把四个选项过一遍就会发现多重度强调的是实例数量上的对应关系不是方法层面的关系。考试遇到类似表述先在草稿上圈出“实例”“关联”这两个词再判断这句话在描述哪一层的东西。结合“客户-订单”的场景再巩固一次一个客户提交0个或多个订单一个订单由一个且仅由一个客户提交。对应每个“订单”类的实例存在1个“客户”类的实例对应每个“客户”类的实例存在0个或多个“订单”类的实例。出题人特别爱在这里挖坑把两个空的位置互换答案就从“1和0..*”变成了另一组数——只要拿业务陈述逐句对照就不会被迷惑。常见多重度标注整理成一张表考前过目标注含义典型场景1恰好一个一个订单只能属于一个客户0..1零个或一个一个员工可选配一部公机0..零个或多个一个客户可提交0个或多个订单1..*一个或多个一次销售包含至少一个销售项2..42到4个固定范围的自定义约束2.2 四种基本关系与聚集/组合看符号还是看语义UML有四种基本关系——依赖、关联、泛化、实现外加一种特殊的关联“聚集”。原题第9题专门让你标注每种关系的图形符号所以画图题的符号记忆不能丢。对照关系与符号关系图形符号含义依赖虚线箭头一个类变化会引起另一个类变化关联实线对象之间存在结构连接泛化实线空心箭头继承子类复用父类实现虚线空心箭头类实现接口聚集聚合空心菱形加实线整体与部分可分离组合实心菱形加实线部分生命周期绑定整体依赖与关联的区别是考查重点依赖是“临时使用”比如方法参数里用到另一个类关联是“长期认识”比如一个类持有另一个类的属性。把这两种关系混淆的人不在少数。记忆方法依赖是虚线短箭头存在感弱关联是实线说明对象之间存在稳定的结构连接。聚集和组合的判断光靠符号还不够要靠语义。原题第2题类A由类B的一个实类和类C的1个或多个实类构成。这里的关键词是“构成”——整体由部分组成而且部分的生命周期绑定整体所以应画作组合关系实心菱形。换个场景“班级”和“学生”是普通聚集空心菱形因为学生离开班级依然存在。考试时看完题目先在草稿上写“可分离/不可分离”再落笔。顺带把“高内聚度”这个与类设计密切相关的概念放一起记高内聚度是对一个类中各个职责之间相关程度和集中程度的度量。一个具有高度相关职责的类而且工作量不是特别巨大就具有高内聚度。同时要注意不要给一个类分配太多职责不相关的职责不要分到同一个类。这个定义在原题第6题和第83题里反复出现答法就按“职责相关程度 不要过多”两点写。2.3 概念类联系从业务场景推出多重度原题第11题要求为“销售实例”的概念类添加联系参考答案是a:1、b:1..、c:1、d:1..。这道题的推理方法比答案本身更重要。先找业务关系“一次销售”和“销售项”是一对多“销售项”和“商品”从业务角度看存在多对一的指向。把业务陈述翻出来逐一确认数量关系一次销售至少要有一个销售项吗通常是的所以销售项端写1..*一个销售项对应一个商品吗是的所以商品端写1。这道题最容易翻车的点是凭感觉写数字写之前先问自己“这个业务允许零个吗如果允许就写0..或0..1如果不允许就写1或1..”。概念类识别之后还有一道概念题常混在其中什么是对象间的可见性考纲的答法是——可见性指的是一个对象能够“看到”或者引用另一个对象的能力。这实际上是类图上对象之间连接的前提没有可见性对象就无法向对方发送消息。做题时把“可见性”和“关联”区分开可见性是运行时协作的前提关联是类级结构的描述。这一章还要掌握一个整体框架UML提供的4种结构图中描述系统静态设计视图最常用的是类图描述静态实现视图选构件图描述体系结构的静态实施视图选部署图。三句话连起来就是“设计看类图、实现看构件图、部署看部署图”考前默写一遍即可。3. 交互图辨析顺序图与协作图的必考差异交互图包括顺序图和协作图这一块既是选择题的高频区也是画图题的主战场。原题反复出现“顺序图与协作图的主要差别和各自的优缺点”这道大题答案基本是固定的背熟即可。3.1 顺序图和协作图的区别先记一句话一句话先概括顺序图强调的是交互的时间顺序协作图强调的是交互的语境和参与交互的对象的整体组织。这句话是答案的起手式写在卷面上能拿到大部分分。展开说明顺序图按照时间顺序布图协作图按照空间组织布图。顺序图里消息按发生先后从上到下排列阅读时一眼就能看到时间关系协作图里对象按照空间摆放消息用编号标注时间顺序藏在编号里。各自的优缺点如下顺序图的优点清晰表示消息之间的顺序和时间关系。缺点需要较多的水平方向空间对象多时图会被拉得很宽。协作图的优点增加对象时比较容易分支也比较少。缺点消息比较多时难以显示消息之间的顺序。原题第72题还有一个角度顺序图没有明确表示对象间的关系协作图清楚表示对象间的关系但时间顺序必须从顺序号获得。所以顺序图适合表示方案协作图适合表示过程的详细设计。把这个“适用场景”补进答案简答题就完整了。再记一句话顺序图和协作图可以相互转换——同一个交互既可以用顺序图表示也可以画成协作图。交互图还可以用来描述一个用况的行为这是它在用例分析阶段的价值所在。3.2 协作图的消息编号时间顺序藏在哪里协作图的时间顺序靠消息编号表示原题第45题直接考了这句话。读协作图时先找编号是1的消息看它从哪个对象发出、到达哪个对象然后按编号递增读下去。举个多人协作的简化场景参与者发“开始销售”给收银台编号1收银台发“查找商品”给商品目录编号2商品目录返回商品信息编号3收银台再发“计算金额”给销售编号4。读图顺序严格按1→2→3→4而不是看箭头在图纸上的位置。嵌套编号要特别注意形如1.1、1.2的编号表示消息1在接收对象内部触发了一组子交互。这种编号出现时读图顺序变成先读1再读1.1等1.2读完再回到消息2。如果题目问“第几条消息发生在消息3之前”需要看的是编号数值大小不是图纸上下位置——这几乎是协作图必错题的出题点考场上见到协作图先找编号再找方向。3.3 从交互图到代码消息名与方法名的转化原题第31题说“读懂交互图并结合其他条件将设计转化为代码”。转化过程分五步逐个对象确定类每条指向该对象的消息确定一个方法消息参数变成方法参数返回消息确定返回类型对象之间的连接确定类之间的关联。以SSD场景为例收款员启动销售、输入商品、结束销售、处理支付对应到代码是这样的public class Register { public void makeNewSale() { // 创建一次新的销售会话 } public void enterItem(String itemID, int quantity) { // 根据itemID查找商品累计金额 } public void endSale() { // 结束本次销售计算并返回总计 } public void makePayment(double amount) { // 接收付款计算找零 } }这段代码里的四个方法名直接取自SSD图中的系统操作名。注意原题第51题画SSD图时系统是一个黑盒不对系统的内部结构与功能进行描述。所以SSD本身只告诉我们“外部的哪些操作要发给系统”具体方法分给Register类还是Sale类要结合控制器模式来分——通常由Register作为控制器接收系统事件再转发给Sale处理金额计算。如果是协作图转化代码方法归属的判定规则是消息箭头指向的对象就是方法的归属类。箭头从收款员指向销售消息名叫“计算总额”那么销售类里就要有一个total()方法。判断方法归属时先看消息箭头方向再看消息名不要被图中对象的摆放位置干扰。4. 用例图、领域模型与SSD需求到设计的三个桥墩这一章的单图考点集中用例图用于描述系统与外部系统及用户的交互领域模型用于表达真实世界的概念类SSD用于按时间顺序描述系统操作。三张图分别回答“系统为谁做什么”“业务里有哪些概念”“系统事件按什么顺序发生”。4.1 用例图参与者、用况和场景用例图最常考的考点是它的用途用于描述系统与外部系统及用户之间的交互。原题第38题、第54题都考了这句话答案都是A用例图。单选题里遇见“系统与外部系统及用户之间的交互”直接选用例图。画一张用例图的三个基本元素参与者Actor画成小人用况Use Case画成椭圆参与者与用况之间用实线连接。原题第12题要求画“电话用户”打电话的用例图场景里有“使用电话卡打电话”和“对方付款打电话”两个用况都是同一个参与者“电话用户”发起。画法上两个椭圆分别标注用况名称左边或上方画一个参与者小人各拉一条实线连到椭圆即可。用况的相关概念也要记住用况是一个描述性文档描述一个参与者使用系统完成某个业务过程时的事件发生顺序。它不描述系统内部如何工作而是定义系统的责任——说明系统必须做什么。用况有Brief、Casual、Fully Dressed三种描述方式简答题写出这三种类型即可。场景scenario是用况的具体执行序列活动者actor就是系统外部的参与者。用况模型是需求工作的重要制品由一组用况和用况图共同构成。顺带记一个与之相关的需求分类FURPS——功能性需求Functionality、可用性Usability、可靠性Reliability、性能Performance、可维护性Supportability。原题第30题问“需求分类主要需求FURPS的内容”答案是功能、可用性、可靠性、性能、可维护性五个词。这个考点在需求分析大题里时常作为补充问写下五个词就能拿分。4.2 领域模型寻找概念类的两种策略领域模型是一组表示真实世界概念类的模型不是软件部件的模型。原题第15题、第44题反复强调这一点。理解起来很简单领域模型描述的是业务世界的概念比如“顾客”“商品”“销售”而不是软件工程里的“界面类”“控制类”。识别概念类有两种标准方法概念类类别表把候选概念按类别分类列出。类别一般包括“人如顾客、收银员、组织如公司、门店、物品如商品、收款机、交易如销售、付款”等。把场景里的名词先归类再筛出真正需要建模的。标识名词短语在用例文本或业务陈述里找出名词和名词短语逐一判断哪些是值得建模的概念类。原题第20题给出的POS收银场景正好用于练习顾客带着购买的商品或服务来到POS收款台收款员启动一次销售收款员输入商品标识系统记录商品并且显示商品说明、价格并计算总金额。用“标识名词短语”策略过一遍候选概念类包括顾客、POS收款台、收款员、销售、商品标识、商品、商品说明。注意“启动”“输入”“记录”这些动词不建模它们对应的方法不是概念类。很多人把“商品说明”漏掉因为它藏在“显示商品说明”这个动宾结构里不是句子的主语——这一点正是名词短语识别法的考察重点动词后面的宾语也是候选概念类。领域建模的步骤原题第66题是固定的列出候选概念类画出领域模型图必要时加入概念类间的关联必要时加入概念类的属性。做题按这个顺序走先列类、再画图、后补关联与属性。如果题目只要求识别概念类而不画图画图这步可以跳过但列出候选类这一步绝不能省。另外原题第68题要背的UML五类图框架也放在这里用例图、静态图包括类图、对象图和包图、行为图状态图、活动图、交互图顺序图和协作图、实现图构件图和部署图。这个分类在考试中偶尔以填空形式出现背下“用例、静态、行为、交互、实现”五个词就能应付。4.3 SSD图与操作契约黑盒视角的系统行为SSD系统顺序图的特殊性在于系统被当作一个黑盒外部角色发出的操作消息直接进入“系统”这个大方块。原题第51题的正确答案已经说明了这一点——不对系统的内部结构与功能进行描述。画SSD时的三个要素外部参与者、系统对象通常是一个边界框、带操作名的消息。原题第21题就是要画包括四个操作的系统顺序图makeNewSale()、enterItem(itemID, quantity)、endSale()、makePayment(amount)。画图时注意操作名用英文动词短语不要写中文。SSD与操作契约的关系容易被忽略。原题第86题给出了操作契约的定义操作契约将系统看成一个提供公共接口的黑盒公共接口用来处理输入的系统事件发现系统事件、定义系统操作操作契约描述在一个系统操作执行后领域模型中对象状态的变化。翻译成大白话SSD展示了“外部发了什么事件进来”操作契约进一步规定“这个事件发生之后领域模型里哪些对象的哪些属性要变”。操作契约通常写三部分操作名、前置条件、后置条件。前置条件描述操作执行前必须满足的状态后置条件描述执行后状态的变化。例如endSale()的前置条件是“已经输入至少一个商品项”后置条件是“计算总金额并显示更新销售的总金额属性”。把SSD画完再补一段操作契约是综合题的完整答法。5. 易漏点与易错点GRASP、设计模式与UP阶段里最容易被扣分的判断前几章解决“知识在哪”这一章集中处理“错在哪”。根据原题的重复度和常见丢分情况挑出三大类易错点每条按“易漏点 → 为什么漏 → 怎么补”展开。5.1 GRASP五原则模式名和“解决什么问题”容易混易漏点GRASP五原则——信息专家、创建者、低耦合、高内聚、控制器——与各自解决的问题连不上线。为什么漏原题第24题要求写出每个GRASP模式解决的问题而“低耦合”和“高内聚”听起来像一对考场上容易互相替换“信息专家”和“控制器”又都跟职责分配相关选起来也容易犹豫。怎么补用问题句式把五个模式钉牢模式名解决什么问题一句话答案信息专家分配职责给对象的基本原则是什么谁最了解信息谁负责创建者谁负责创建某个类的新的实例谁该new这个对象低耦合如何支持低依赖关系和增加重用减少对象之间的依赖高内聚如何将复杂性保持在可控制的范围内职责集中不塞太多控制器谁来负责处理一个输入系统事件系统事件的入口对象把每对“模式问题”连起来默写一遍再写出对应的答案要点。原题第52题还提示了一个排坑点多态、纯虚构、间接者属于GRASP模式家族但GoF不是——GoF指设计模式领域经典著作的四位作者不属于GRASP模式集合。选择题见到“GoF”选项直接排除。5.2 设计模式问题和方案张冠李戴观察者还常被写成Composite易漏点单例、策略、组合、观察者、适配器这五个模式的“问题 → 解决方案”对应关系换一种表述就认不出来。为什么漏原题第35题已经出现了一处隐患——把观察者模式的模式名误标为Composite。这提醒我们题目本身的信息也可能来自教材或内部资料的笔误需要靠理解模式的结构去判断而不是机械背一个模式名。另外策略和适配器从名字上看都带“转换”色彩容易混淆。怎么补用一句话抓每个模式的特征单例Singleton一个类只能有一个实例对外提供一个静态获取方法。策略Strategy把一系列算法封装成实现同一接口的类运行时可互相替换。组合Composite组合对象和原子对象实现相同接口调用方可以一视同仁地处理单个对象和一组对象。观察者Observer状态变化时自动通知所有依赖对象并更新它们。适配器Adapter用中间适配器对象把一个组件的接口转成另一个接口。简答题答法按“问题解决方案”两段式先写“该模式解决什么问题”如“如何使一个类严格地只有一个实例”再写“解决方案是什么”如“定义一个静态的返回单例的类方法”。考场上先把问题句原样写上再补方案就能拿全分。需要注意设计模式里的组合Composite和UML类图里的组合Composition不是一回事。前者是结构型设计模式处理部分-整体的递归结构后者是UML关系表示生命周期绑定。遇到判断题先看语境在模式题里按设计模式答在类图题里按UML关系答。5.3 UP四阶段“定义大多数需求”到底在哪个阶段易漏点UP四阶段中定义大多数需求和范围的工作是在细化阶段完成的不在初始阶段。同时用况用例图属于行为建模不是静态设计视图。为什么漏字面上看“初始”像是“需求都在这”而“细化”像是“只是打磨”。实际上初始阶段只做简要的愿景文档和业务案例、确定范围、粗略评估成本细化阶段才迭代地实现核心构架、解决高风险问题、定义大多数需求。同样地UML五类图中类图是静态设计视图的主力用例图负责对系统的行为进行组织和建模这两类图的作用常被混淆。怎么补UP四阶段各自关键词串成一句口诀“初始愿景粗算钱细化需求定架构构造实现其余提交测试部署。” 见到“定义大多数需求”“核心构架”“高风险”就往细化阶段上靠。图分类记住静态设计看类图行为组织看用例图动态交互看顺序图和协作图物理部署看部署图。原题里还有一道关于增量开发的题容易和UP四阶段混在一起。增量开发包括两层意思一是对复杂用况分多次迭代一部分一部分实现二是将所有用况按优先级分别安排在不同迭代中实现。与UP阶段的关系是UP的构造阶段用增量迭代方式实现系统其余部分。答“什么是增量开发”时写这两层即可。软件开发生命期是另一个容易混淆的考点它是指软件产品从概念开始到交付使用的整个时期一般包括概念、需求、设计、实现、测试、安装、交付等阶段这些阶段可以重复执行时也可以迭代。注意区分软件生命周期是宏观概念UP是具体的迭代式开发框架。考题里如果问“UP阶段”答四阶段如果问“软件开发生命期”答七个阶段加“可重复、可迭代”。6. 复习清单与查漏补缺考前如何用这份资源自检6.1 一周复习节奏读完这份笔记接下来的动作是自检。前三天按模块扫盲后四天做真题复现和错题定位天次复习内容自检方式第1天类图、多重度、聚集/组合、概念类识别画出客户-订单类图标出两端多重度第2天顺序图与协作图、SSD、用例图默写交互图的三条区别和SSD黑盒原则第3天GRASP五原则、设计模式、UP四阶段默写“问题 → 模式”对应表和四阶段口诀第4天UML五类图、操作契约、FURPS写出五类图分类和FURPS五个词6.2 考前自检表自检时对着下面九个问题逐项划勾比反复通读教材更有效多重度能读懂“1”“0..”“1..”的差异吗四种关系能闭眼画出依赖、关联、泛化、实现的箭头吗聚集与组合一段话里出现“构成”能判断画实心还是空心菱形吗顺序图与协作图能说出三条区别和各自适用场景吗协作图读图能按编号顺序描述消息流而不被图纸位置带偏吗概念类识别能从业务文本抓名词短语不遗漏动词后面的宾语吗GRASP能把模式和“解决的问题”一一对上吗设计模式看到问题能匹配模式名和解决方案吗UP阶段记得住四阶段知道“定义大多数需求”在细化阶段吗最后一轮快速过题把系统操作名makeNewSale()、enterItem(itemID, quantity)、endSale()、makePayment(amount)再抄一遍想想它们各自对应哪一步业务。如果这一步卡壳回到第4章把SSD场景再读一遍。我以前复习时总是一上来就刷题结果多重度方向、UP阶段归属这种细节错了一次又一次。从那以后我每次复习都先画一遍这张知识地图再做真题先框架后细节先图后码先会背再会变。希望帮到你。本文还有配套的精品资源点击获取