简介UML软件建模复习题以PDF形式整理了软件建模课程的核心考点适合高校软件工程、计算机相关专业学生及备考人员使用。内容覆盖UML基本概念围绕用例图、类图、状态机、活动图、构件图和部署图等主要图型展开包含单项选择题、填空题、名词解释与简答题并附参考答案便于自测与查漏补缺。资源为单个PDF文档大小2.79MB共1个文件携带方便可直接打印或电子阅读。目前已有118人学习下载适合考前集中复习与日常巩固。相较零散笔记这份复习题结构完整、目录清晰覆盖概念、关系建模、交互图、状态图、活动图、构件与部署等模块能帮助读者快速建立UML知识框架掌握常见题型与答题思路。对有UML软件建模考试需求或希望强化面向对象建模理解的学习者来说是一份实用且高效的复习资料。1. 拿到《UML软件建模复习题.pdf》先别急着背概念一份UML软件建模复习题PDF拿到手里最吃亏的做法是从第一页的概念填空开始背。刷过几套题的人会发现真正的分水岭不是“用例图有几个要素”而是给一段图书管理或在线购物的需求限时画出类图、包图、顺序图。很多开发经验超过三年的人写代码没问题却在关联和聚合的箭头上跑分。原因不是不懂UML而是缺少一套“读题、找边界、画图、验证”的建模流程。这篇文章就按这个流程来拆先看清UML图的分类和你应该在哪类题上花时间再落到EA或Visio这类建模软件里把图导成PDF最后用一个图书管理案例完整走一遍并给出交卷前的自检指标。适合准备软考、期末考以及需要补软件建模短板的工程师。2. UML图分类与高频考点类图、用例图、包图的判定边界2.1 结构图与行为图先判断题型再落笔复习题里最不值钱的丢分是“把活动图画成流程图把类图画成E-R图”。要避免这个第一件事是建立分类感。UML 2.x 一共定义了14种图主流教材把它分成两大阵营结构图描述系统的静态组成包括类图、对象图、包图、组件图、部署图和复合结构图行为图描述系统在时间维度的动作与状态包括用例图、活动图、状态机图、顺序图、通信图、时序图、交互概览图。做题时的判断依据是题干里的词汇密度。名词密度高比如“读者、图书、借阅记录”优先考虑类图和包图动词密度高比如“借书、还书、罚款”优先考虑用例图、活动图和顺序图出现了“状态”“事件”“转移”这类词那基本是在考状态机图。这个判断要在读题后30秒内完成否则画得越细偏离越远。复习题PDF里通常把类图、用例图、顺序图、活动图列为必考包图和状态图容易当成小知识点。但近年考卷里包图出现频率明显上升因为它能考察模块划分能力。这也是“uml包图”被单独检索的原因很多复习资料里只给它两页题目却要求按层次分包。2.2 类图关系中的高频易错点类图是建模题的核心而类图的高频失分点集中在六种关系的符号和语义上。我把它们整理成一张对照表复习时直接看表格记忆符号和判断依据。关系图形符号语义复习题示例关联实线箭头或无箭头类之间有实例级连接Reader — BorrowRecord聚合空心菱形在整体侧整体-部分部分可脱离整体Library o— Book组合实心菱形在整体侧整体-部分部分随整体生命周期Order *— OrderItem依赖虚线箭头一个类的方法参数或返回值用到另一个类BorrowRecord .. Book泛化实线空心三角形指向父类继承关系Student —实现虚线空心三角形指向接口类实现接口Book ..注意聚合和组合的判断不要只看“包含”二字。一个有效的经验法是删除整体后部分如果还有独立存在意义就是聚合如果随整体一起消亡就是组合。订单删除后订单明细没有意义所以用组合图书馆删掉后馆藏图书仍然存在所以用聚合。复习题里经常把这两个关系互换来挖坑画之前先在草稿上写一句“整体没了部分还在不在”。光看符号还不够需要能自己写出来。我一般会先用PlantUML把答案快速落成文本因为文本比鼠标拖拽容易反复修改语法也能检查箭头方向。下面这个示例覆盖了聚合、关联和依赖startuml class Library class Book class Reader class BorrowRecord Library 1 o-- 0..* Book : 馆藏 Reader 1 -- 0..* BorrowRecord : 创建 Book 1 -- 1..* BorrowRecord : 对应 BorrowRecord .. Book : 引用 enduml这段代码里o--是聚合--是关联..是依赖引号内的多重性对应线的两端。Library 1 o-- 0..* Book表示一个图书馆可以聚合零到多本图书Reader 1 -- 0..* BorrowRecord表示一个读者可以关联多条借阅记录关联方向是Reader到BorrowRecord。多重性是阅卷老师重点看的内容漏掉一个数字关联的语义就变了。建议在复习阶段用PlantUML多画几遍再与标准答案对照修改比直接上Visio找形状更高效。2.3 用例图的关键要素include、extend与泛化用例图在复习题里的地位有时比类图还高因为它是唯一从用户视角描述行为的图。一张完整用例图由参与者、用例、系统边界和关系组成。参与者是系统外部的角色可以是人或外部系统“系统边界”是一个矩形框把用例框在中间参与者放在外面。关系里有三个考点关联、include、extend。关联是最基础的参与者直接发起用例时用实线。include表示基本用例总是包含一个公共子用例方向是从基本用例指向子用例用一根带箭头的虚线箭头上写include。extend表示在特定条件下才执行的扩展用例方向是从扩展用例指向基本用例写extend。举个例子“查询图书”是“借书”的include因为借书前必然要查询图书“计算超期罚款”是“还书”的extend因为只有超期才执行未超期就不执行。这个区分是标准考点。还有一个容易漏的泛化关系如果两个参与者只有一个角色不同可以把共同信息抽成父参与者。比如“学生”和“教师”都是“读者”学生和教师都继承“读者”参与者的借书权限这里就能画出参与者之间的泛化。复习时对比着include和extend多练几组比记忆定义有用。2.4 包图模块划分与依赖方向包图在UML里被称为“组织模型的模型”它本身不表达类的内部结构而是把相关元素放进一个命名空间并在包之间画出依赖关系。复习题里典型的包图考点是把系统划分成若干包然后判断包之间的依赖方向是否合理。常见分层是表现层、业务层、数据访问层依赖方向只能是上层依赖下层不能反向。包图的关键参数有两个包内元素可见性以及包的依赖。画包图时最容易犯的错是把依赖画成双向箭头。一旦两个包互相依赖就说明模块边界没划好要么合并包要么把公共部分抽到第三方包中。复习题里包图占的分值不高但图元少踩一个点就扣一份性价比很高。包图不需要画得多复杂只要把划分逻辑说清楚阅卷老师通常都会给分。3. 用EA和Visio把复习题答案画成图建模软件的选型与参数配置3.1 EA建模软件离线安装包与Visio谁更合适建模软件是复习工具里最容易让人纠结的一环。EAEnterprise Architect是专业建模工具对UML图的覆盖最完整包图、状态图、组件图都有原生模板并且支持从类图生成Java、C#代码适合系统化复习Visio是微软出品的通用绘图工具画类图足够但UML形状库依赖自带的“软件”模板不同版本入口名称有差异。热词里出现“ea建模软件离线安装包”说明很多人希望在无网环境下装好工具。常见做法是下载离线安装包后先解压再运行安装程序安装时要注意两点安装目录不要带中文或空格许可证文件放到指定目录后再启动。如果只是应付复习题画图Visio更轻量如果后面还要做课程设计或真实项目建模EA更值得花时间。两者并不冲突我推荐用EA建模型用Visio补图形排版。对比项EAVisioUML支持完整度原生支持全部14种图依赖模板部分图需自定义包图支持支持包图和包依赖关系可用容器模拟但不做语义校验类图代码生成内置代码生成无离线安装提供离线安装包需许可证依赖Office安装介质导出PDF直接导出或打印另存为PDF3.2 在EA中创建类图的3个参数可见性、多重性、关联类型在EA里画类图的路径很固定左侧Project Browser选中一个包右键选择Add Diagram在UML类别下选Class Diagram。随后从工具栏拖入Class元素双击类形状进入属性窗口。这里要设置的第一个参数叫可见性UML用字符前缀表示表示public-表示private#表示protected。一个类的属性是private还是public在复习题里不是随便写的这关系到封装性阅卷标准通常要求属性私有、方法公有。第二个参数是多重性也就是线上写1、0..*、1..*的位置。在EA中双击关联线在Source和Target的Cardinality栏中填数字。注意多重性写在靠近目标类的一端读法是“源端的一个实例对应多少个目标实例”。比如从Reader到BorrowRecord的关联线上源端是Reader目标端是BorrowRecord目标端要填0..*。第三个参数是关联类型。EA中双击关联线后在Connector类型里可以切换为聚合、组合、依赖等。这一步最常见的失误是把关联线拉完就忘了改类型线的两端变成无方向实线。建议画完每一条线后双击检查一遍线型和方向。EA里聚合是空心菱形组合是实心菱形依赖是带箭头的虚线这三种线混在一起时放大后很容易被阅卷判错。3.3 用Visio画UML类图模板、形状与形状显示选项用Visio画UML类图首先要找对模板。打开Visio后选择“软件和数据库”类别里面有“UML类图”模板如果你的版本没有这一项也可以用“数据库模型图”反向编辑但格式需要调整。进入画布后左侧模具里会有Class、Interface、Association等形状。拖入Class形状后右键点击形状选择“形状显示选项”勾选Attributes和Operations并把可见性显示为-或。这里要说明Visio的默认形状可能不显示属性类型你需要在形状上双击进入文本编辑按- name: string的格式逐行输入。关联线在Visio模具里叫“二元关联”把它拖到两个类形状之间连接好端点后右键打开“属性”对话框在“多重性”标签里设置源端和目标端的基数。很多人反映用Visio画类图最烦的是线会歪这时可以同时选中多条线使用“形状”菜单里的“对齐”和“分布”功能把它们排整齐。Visio没有自动的依赖校验所以画的线方向错了也不会提示需要你自己对照标准答案逐一核对。提示每画完一条线就把线的两个端点和关系类型在草稿上写一遍最后核对时只看草稿不需要反复在图形上找元素。3.4 用VBA宏把Visio图导出为PDF方便与复习题对照复习题是PDF你的作答最好也导出成PDF这样在平板上可以并排批注。Visio自带“另存为PDF”但如果题量大可以写一个VBA宏批量导出当前页。在Visio中按AltF11进入VBA编辑器插入模块后粘贴下面的代码Sub ExportCurrentDiagramToPDF() Dim vsoPage As Visio.Page Set vsoPage ActivePage Dim filePath As String filePath C:\UMLReview\ vsoPage.Name .pdf vsoPage.ExportAsFixedFormat visFixedFormatPDF, filePath MsgBox 已导出: filePath End Sub这段代码把当前页按页面名称保存为PDF。参数visFixedFormatPDF表示输出格式为PDF第二个参数是完整路径。注意保存目录必须提前建好否则会报错页面名称如果包含“/”或“:”Windows文件名会非法可以在导出前用Replace函数替换掉。如果你使用的是EA则不需要脚本EA在“文件”菜单里直接选“导出为PDF”即可。这些步骤不是每次考试都必需但操作熟练后能省出大量对答案的时间。4. 一道图书管理复习题的完整建模路径用例、包图、类图到顺序图4.1 读题圈出参与者、用例和名词下面我用复习题里出现频率较高的一道题做例子某图书馆需要开发一个图书管理系统管理员负责录入图书和办理读者注册读者可以查询图书、自助借书和还书每次借阅产生一条借阅记录系统根据借阅天数自动计算超期罚款。请画出该系统的用例图、包图和类图并给出借书用例的顺序图。拿到这道题先不要急着打开任何工具。我一般用三个符号做标记下划线画名词圆圈画动词方框画系统外部的角色。名词里“图书”“读者”“借阅记录”是明显的候选类“管理员”和“读者”同时也是参与者因为它们在系统外部与系统交互。动词“录入”“查询”“借书”“还书”是候选用例。容易被忽略的是“超期罚款”它既可以作为借书用例的扩展也可以单独成为用例这取决于题目对精度的要求。在复习题答案里通常把“计算罚款”作为“还书”的扩展用extend关系表示。4.2 先画包图划分模块边界用例图画完之后不要直接画类图我建议先画包图。原因是类图一旦实体多布局就乱包图能帮你建立“哪些类归到哪个包”的全局感。图书管理系统的常见分包是按功能领域拆读者管理包、图书管理包、借阅管理包再加一个公共工具包。在PlantUML里可以用package表示包startuml package 读者管理 { class Reader } package 图书管理 { class Book } package 借阅管理 { class BorrowRecord class FineCalculator } package 公共工具 { class DateUtil } 借阅管理 .. 公共工具 : 依赖 图书管理 .. 读者管理 : 依赖 enduml这里..是包之间的依赖箭头表示一个包中的类会使用另一个包中的类。注意依赖方向借阅管理依赖公共工具是因为计算罚款要用日期工具类图书管理依赖读者管理是因为Book类里会引用Reader对象。如果你发现包之间有双向依赖就说明分包没做好需要把共同依赖的类提到底层包去。包图画好以后类图只需要在对应包内部继续深化思路就顺了。4.3 细化类图把包图中的类抽出设置属性和方法类图是这道题的得分大头。参照包图我们把四个核心类填上属性和方法。Reader类有readerId、name、contactBook类有bookId、title、author、isOnLoanBorrowRecord类有recordId、borrowDate、returnDate、fineAmountFineCalculator作为工具类提供一个静态方法calculateFine。关系方面Reader与BorrowRecord之间是一对多关联Book与BorrowRecord之间也是一对多关联Book与Reader之间不要画直接连线因为借阅记录是中介直接连反而会多出额外的多对多关联。用PlantUML来表达startuml class Reader { - readerId : String - name : String - contact : String createBorrowRecord() : BorrowRecord } class Book { - bookId : String - title : String - author : String - isOnLoan : Boolean loan() : Boolean } class BorrowRecord { - recordId : String - borrowDate : Date - returnDate : Date - fineAmount : Double calculateFine() : Double } Reader 1 -- 0..* BorrowRecord Book 1 -- 1..* BorrowRecord BorrowRecord .. Book : 引用 enduml代码里的可见性前缀要规范字段为-方法为。多重性写在线的两端Reader 1 -- 0..* BorrowRecord表示一个读者对应多条借阅记录Book 1 -- 1..* BorrowRecord表示一本书至少被借过一次记录中必须引用一条。方法名createBorrowRecord放在Reader类里意味着借书操作由读者触发如果你觉得操作应该放在一个Controller类中也可以但顺序图里的调用者必须和类图里的方法所在类对齐。阅卷老师不会限制唯一样式但会检查逻辑闭环顺序图里调用谁类图里谁就必须有对应方法。4.4 用顺序图查漏一个“借书”用例的时序类图画完不要直接交卷建议把一道用例的时序走一遍。顺序图是验证类图的最好工具因为画的过程会逼你对每个类的方法签名命名。借书用例的参与者是Reader参与对象是界面类、实体类以及记录类。下面给出一个简化版顺序图startuml actor Reader participant BookUI as UI participant Book as Book participant BorrowRecord as Record Reader - UI: 输入图书ID UI - Book: findByID(bookId) Book -- UI: Book UI - Book: loan() Book -- UI: success UI - Record: create(readerId, bookId) Record -- UI: BorrowRecord UI -- Reader: 借书成功 enduml顺序图的阅读顺序是自上而下每一根消息箭头的方向必须从调用者指向被调用者。注意Book -- UI是返回消息用虚线箭头表示被调用方的返回值。很多人把返回消息画成实线这会被扣图元分。顺序图里尽量不要出现类图中没有的方法比如这里的findByID应该存在于Book类的静态方法中如果没有就回去补类图。做到这一步你的答案在结构上已经自洽了。5. 交卷前的自检多重性与依赖方向如何判错改错5.1 一个快速自检的清单画完之后我习惯按固定顺序做一次“模拟阅卷”先数类名是否正确再看每条关联线端点的多重性接着看依赖箭头方向最后看包图里是否有循环依赖。这个顺序不能乱。多重性是阅卷老师最常标准化判分的位置漏写多重性关联表达力减半写错方向整条线语义颠倒。我评测过不少互交作业超过一半的类图错误不是关系类型错而是多重性位置写反了。5.2 多重性怎么检查一眼看出合理性有一种常见做法叫“站在一边读另一边”。如果要检查Reader到BorrowRecord的多重性就站在Reader这一端问一个Reader会对应多少个BorrowRecord答案是多个所以在BorrowRecord那一端写0..*然后站在BorrowRecord这一端问一条BorrowRecord会对应几个Reader答案是一个所以在Reader那一端写1。注意我们计算的是“同一条记录不能被两个读者拥有”所以是1而不是0..1。对于订单和订单明细站在Order端问是“一个Order有多少条明细”多条所以明细端写1..*站在明细端问是“一条明细属于几个Order”一个所以Order端写1。这个口诀适用于所有类图每换一道复习题就套一次。5.3 依赖方向避免循环依赖依赖方向在包图上最明显。表现层依赖业务层业务层依赖数据访问层如果出现由下向上的箭头说明业务逻辑泄漏到了界面层或者数据访问层反过来调用了业务规则。更隐蔽的错误是包A依赖包B包B依赖包C包C又依赖包A构成三包循环。遇到这种情况最简单的修法是新建公共类型包把三者共同依赖的类下沉进去。在EA里可以打开“依赖矩阵”专门查包间关系在Visio里没有自动检测但用文本列一遍包依赖也能很快找到环。检查依赖方向时多问一句这个类是作为参数被传入还是作为返回值被传出如果是参数通常定义依赖如果只是局部创建属于更弱的临时依赖不一定非画在类图上。用这个标准去筛线类图就不会被脏线堆满。本文还有配套的精品资源点击获取