企业官网建设流程全解析

简介：UML系统分析与设计复习试题资料包，面向正在学习统一建模语言、备战期末考试或相关资格认证的高校学生及软件开发初学者。文档以问答形式整理近20个高频考点，覆盖关联多重度判断、类与类之间组合与聚合关系、客户与订单数量对应、顺序图与协作图优缺点对比、高内聚度含义、用例图与序列图的实际用途，以及UML四种基本关系识别等核心知识，所有选择题、简答题和场景设计题均附详细答案与解题思路，便于读者对照练习、查漏补缺。资料为1个doc文档，压缩包大小132KB，使用Word即可打开浏览。该内容出自CSDN作者hduzh整理的复习资料，已有404人学习，适合在考前集中梳理UML系统分析与设计重点、加深对抽象概念理解并提升应试能力。

1. 复习UML到底在复习什么：背图名赢不了，判关系才能拿分

UML复习最容易翻车的地方，往往不是叫不出图的名字，而是拿到一道纸条判断题时手悬在半空：“订单与订单项之间是什么关系？”选聚合还是组合，决定了你这轮复习是不是真的踩到了点子上。UML系统分析与设计考的不是背图名，而是能不能把一段普通需求文字翻译成关系正确、标注完整、阅卷人挑不出错的模型图。不管是期末突击还是面试前冲刺，最该先解决的问题是：哪些图必考、关系怎么判、动态图从哪里采分，以及用什么方法在考前快速验证自己的画图结论。下面这套复习思路就按这个顺序展开。

2. UML考察地图：先分清静态还是动态，复习才不会白搭

翻开往年试题就会发现，UML知识点并不平均分布：有的图年年出现在综合题里，有的图只在选择题里露一面。要是按教材目录从头背到尾，时间不够，效率也低。正确做法是先画一张考察地图，把图的优先级排出来，再按分值分配精力。

2.1 常考图的优先级一览：哪些图必须会画，哪些图认识就行

下面这张表按题型和出现频率整理了复习优先级，前四类建议动手画，后三类做到能认、能选、能说出用途即可。

类图和顺序图分值最高，因为综合题几乎绕不开“静态建模 + 动态建模”的组合拳；用例图和活动图是需求分析与业务流程建模的主力。对象图、组件图、部署图更多考概念辨析，比如“对象图是类图的实例化快照”这句话本身就是一个常见选择题考点。

2.2 结构图与行为图的二分法：一个分类救回五道选择题

把图分成静态和动态两大类，是复习时第一个要内化的动作。结构化建模关心系统的组成：类图、对象图、组件图、部署图、包图都归这里；行为建模关心系统的运行：用例图、活动图、状态图、顺序图、通信图都归这里。

这个二分会直接影响判断题得分。选择题里出现“类图描述系统的静态结构”“状态图描述对象的状态迁移”这类命题，基本都能靠分类直接判断。还有一个易错点：用例图虽然描述的是“功能”，建模界普遍把它归入行为图阵营，因为它刻画的是参与者与系统的交互。如果教材把它单独列为需求建模，考试时按教材口径作答。

2.3 题干信号词映射表：看到“流转”选状态图，看到“泳道”选活动图

综合题给一大段需求文字时，先划信号词再决定画什么图，比读完就动手稳得多。下表列的是选择题和画图题里出现频率最高的信号词组合。

看到“订单流转”这类词别急着画活动图，先判断主语是“单个对象的状态”还是“多个角色之间的流程”。主语是订单这一类对象，选状态图；主语是“用户、系统、仓库”多个角色来回协作，选活动图或顺序图。

3. 类图的关系判定：六类关系吃透，综合题一半的分就稳了

类图是UML静态建模的核心，也是失分重灾区。综合题里让你根据需求文字画类图，本质就是考两件事：类选得准不准，关系画得对不对。关系错了，整张图逻辑就塌了；关系对了但多重性没标，阅卷同样按“建模不完整”扣分。

3.1 六类关系的符号与一句话语义

UML类图里有六类关系，它们的符号区分度很高，但考试喜欢混在一起考，比如“聚合与组合的差别”“依赖与关联的差别”。先把符号和语义钉死，下面这张表是我复习时用得最顺的速查表。

关联和依赖最容易并列考：关联是两个类长期“互相知道”，比如老师和课程；依赖往往只在一次方法调用里出现，比如工具类作为方法参数传入，调用结束就不持有它。记住“长期持有”和“临时使用”这个分水岭，判断题基本不会翻车。

3.2 聚合还是组合？三个追问比背例子可靠

聚合与组合都表示整体-部分关系，很多复习资料靠例子区分，结果题目一换场景就懵。我的习惯是背三个追问，每个追问都能拍板：

1. 部分离开整体后，业务上的独立意义还在吗？课程从老师名下移除，课程还能存在，这是聚合；订单项从订单里拆出来就没有交易含义，这是组合。
2. 整体销毁时，部分必须一起销毁吗？订单取消后订单项不再参与交易，组合；学校撤并，老师可以转到别的学校，聚合。
3. 生命周期是否同步？同步的偏向组合，不同步的偏向聚合。

用这三个追问去套“订单与订单项”和“学校与教师”两组经典案例，比死记“订单是组合、学校是聚合”要稳得多。考试里出“图书馆与图书”“公司与部门”这类变体时，依然能套用同一个逻辑。

3.3 从题干到类图四步：再借PlantUML自检一波

拿到画类图的综合题，我一般按四步走，少一步都有可能丢分：

1. 圈名词和动词：题干里的业务名词是类的候选，动词是关系候选。
2. 筛类：把单纯描述属性的词剔掉，比如“价格”“姓名”通常是属性，不是一个独立类。
3. 先画强关系：先确定泛化、实现、组合这类语义明确的关系，再补关联和依赖。
4. 标多重性：把题干里“一个”“多个”这类数量词翻译成 1、0..、1..写在线的两端。

复习时想把关系验证对，不建议只靠眼睛看，可以用PlantUML把图写出来渲染比对。下面这段puml把六类关系全部写进去了，跑一遍就是一张速查图。

' 类图自检模板：综合题用到的六类关系浓缩成一份puml @startuml class Animal class Dog interface IFlyable class Bird class Order class OrderItem class Teacher class Course ' 泛化：Dog继承Animal，实线空心三角指向父类 Dog --|> Animal ' 实现：Bird实现IFlyable，虚线空心三角指向接口 Bird ..|> IFlyable ' 组合：Order包含OrderItem，整体端实心菱形 Order "1" *-- "1..*" OrderItem ' 聚合：Teacher聚合Course，整体端空心菱形 Teacher "1" o-- "0..*" Course @enduml

这段代码里最值得记的是符号差异：--|>是泛化，..|>是实现，*--是组合，o--是聚合。多重性写在连接线两端的引号里，比如"1"表示整体端恰好一个，"0..*"表示部分端可零到多个。渲染时常见做法是直接用java -jar plantuml.jar class_relation.puml，或者在支持PlantUML的编辑器里装插件预览。哪条线渲染出来箭头方向和预期不一样，就说明那个符号还没记牢。

4. 动态图的四个采分点：用例图方向、顺序图消息、状态图事件、活动图泳道

动态建模在考试里不止一种考法，用例图、顺序图、状态图、活动图各有各的采分点。很多复习资料把它们混在一起讲“都是行为图”，但实际做题时，每一张的坑长得完全不一样。

4.1 用例图：include与extend的方向是选择题和综合题的共同陷阱

用例图里最容易被出题人盯上的就是include和extend。include表示基础用例每次执行都必须包含的公共步骤，比如所有交易类用例都要“登录验证”；extend表示在特定条件下才触发的可选扩充，比如“会员积分抵现”。复习时只要记住两句话：每次都要做的是include，可选追加的是extend。

方向是真正的扣分点。include的箭头从基础用例指向被包含的公共用例，extend的箭头从扩展用例指向被扩展的基础用例，两者正好相反。拿“网上购物系统”举例：下单必须先登录，登录是include；会员下单可以用积分抵现，积分抵现是extend。用PlantUML写出来长这样：

' 用例图：include箭头指向被包含的登录，extend箭头从扩展用例指向下单 @startuml left to right direction actor 顾客 as user rectangle 网上购物系统 { usecase "登录" as login usecase "下单" as order usecase "积分抵现" as redeem } user --> order order ..> login : <<include>> redeem ..> order : <<extend>> @enduml

渲染后能直观看到：order指向login，表示下单包含了登录；redeem指向order，表示积分抵现扩展了下单。综合题阅卷时看到方向反了，就算用例选对了也会扣掉关系分。每次练习前先默写一遍这两条线，能少踩一半的坑。

提示：include与extend方向相反，这是选择题和画图题共同的高频失分点。

4.2 顺序图：消息顺序、返回线、生命线一个都不能少

顺序图是综合题里动态建模的主力，考的是“谁在什么时候调用谁”。一张完整的顺序图至少要包含四条信息：对象生命线、消息、返回消息、激活条。手绘时容易漏的是返回消息，很多同学把箭头画完就收笔，结果丢掉了“应答”这个环节。

画顺序图时消息编号的层次也有讲究：从1开始按时间顺序编号，嵌套调用写成1.1、1.2，而不是把每一层都从1重新编。返回消息用虚线箭头，普通同步调用用实线箭头。下面这个例子是典型的“界面层调用控制层，再调用存储层”三层结构：

@startuml actor 考生 as s participant "考试界面: ExamForm" as ui control "答题Controller: AnswerCtrl" as ctrl entity "试题库: QuestionBank" as db s -> ui: 打开试卷 ui -> ctrl: 获取试题列表 ctrl -> db: select questions db --> ctrl: 返回试题数组 ctrl --> ui: 渲染题目列表 ui --> s: 显示试卷 @enduml

participant、control、entity这几个关键字给了对象一个“类型头衔”，渲染出来生命线风格不同，阅卷时更容易看出分层职责。对象名用“对象名:类名”的格式，比如考试界面: ExamForm，比只写“考试界面”更符合建模规范。从考生到考试界面是实线，表示考生发起的同步交互；从db返回给ctrl是虚线，表示查询结果回传。把这两类线画反，整道题的采分点就丢了。

4.3 状态图：事件、守卫条件、动作三角齐了才有分

状态图描述的是单个对象的生命周期，核心考点集中在“迁移线上写什么”。一个规范的迁移写成“事件[守卫条件]/动作”，比如“提交审核[资料完整]/生成待审记录”。考试时只写目标状态不写事件，或者只写事件不写条件，都会被判为建模不完整。

经典的订单或审批状态流转经常被拿来出综合题。初始状态用实心圆[*]表示，终止状态也用[*]加外圈表示，中间每个状态用圆角矩形框起来。

@startuml [*] --> 待审核 待审核 --> 已通过 : 审核通过 待审核 --> 已驳回 : 驳回 已通过 --> 已发布 : 上线发布 已发布 --> 已下线 : 活动结束 已下线 --> [*] 待审核 --> [*] : 关闭申请 @enduml

这个代码里，冒号后面写的是触发迁移的事件，比如“审核通过”“驳回”。如果题目要求带守卫条件，就写成“审核通过[材料齐全]/归档”；没有动作时动作部分可省略。另一个常见考点是状态图和活动图的区分：状态图里的节点是一个一个“状态”，活动图里的节点是一步一步“活动”，一个强调事件驱动，一个强调流程推进。

4.4 活动图：泳道和并发横线是阅卷眼里的大缺口

活动图考业务工作流，综合题里经常遇到“按以下流程画活动图”的题目。这类题目的采分点有三块：判断节点、泳道、并发。判断节点用菱形，对应题干里的“如果……否则……”；泳道用|角色|分隔不同职责；并发对应题干里的“同时”“并行”。

@startuml start |前端界面| :提交订单; |后端服务| :校验库存; if (库存充足?) then (有) :扣减库存; :生成订单; else (无) :返回缺货提示; endif :流程结束; stop @enduml

活动图的泳道是阅卷重点，因为它在图形上直接表达了“谁负责这一步”。题干里出现“用户在界面上提交”“后端校验库存”，就分别放到前端界面泳道和后端服务泳道。并发分支在代码里对应fork和join两条粗横线，看到题干写“通知仓库的同时给用户发消息”，就要画分叉再汇合。缺了并发横线，这道题即使流程顺序正确，也会被认定为没抓住需求关键。

5. UML复习常见问题排查：五处丢分高发点与对策

下面这五个问题全部来自对错题的复盘，每条都是课本边角但在考场上被反复扣分的位置。复习时不用等考完再来对答案，训练阶段就能提前排掉。

5.1 含“由…组成”不一定选组合

现象：判定题给“计算机由CPU、内存、主板等组成”，很多人想都不想就选聚合，标准答案却是组合。原因：看到“由…组成”就套整体-部分模板，没走语义判定。解决：先问“部分离开整体后还有独立业务意义吗”。CPU离开计算机后整机无法工作，生命周期同步，这是组合；换成“学校与教师”，教师从学校离职后仍然是教师，才用聚合。把“能否独立存活”作为第一判词，比背例子可靠。

5.2 include与extend箭头方向画反

现象：手绘用例图时把登录画成“下单指向登录”，又把“积分抵现”挂在订单下面当include，两道题一起丢分。原因：把“功能之间有关系”当成“包含”，没按语义定方向。解决：include是基础用例必须包含的公共步骤，箭头从基础用例指向被包含用例；extend是可选补充扩展基础用例，箭头从扩展用例指向基础用例。平时练习多写两遍redeem ..> order : <<extend>>，方向就固定在肌肉记忆里了。

5.3 顺序图返回线画成实线，消息编号扁平

现象：画顺序图时把“返回试题列表”画成实线箭头，所有消息从上到下编成1、2、3。原因：把返回应答和发起调用当成同一种消息。解决：同步调用用实线箭头，返回/应答一律用虚线箭头；嵌套调用编号写1.1、1.2而不是另起编号。阅卷时实线返回会被当成普通消息序列接着读，语义全乱，分自然没了。

5.4 状态图漏了初始节点或迁移事件

现象：状态图从“待支付”状态直接开画，迁移线上只有目标状态名，没有触发事件。原因：把状态图当成活动图的流程图来画。解决：先固定[*]初始节点，再考虑终态；每条迁移线按“事件[守卫条件]/动作”补全。如果题干给的是一串“先做什么再做什么”的步骤，没有事件驱动特征，那不是状态图，是活动图，尽早换图型。

5.5 类图画完线不标多重性，关系对也拿不满分

现象：类图关系连线全部正确，但1、0..*一个都没写，最后被判“关系不完整”。原因：只求类之间“连得上”，没把题干的数量词转写成模型信息。解决：读到“一个老师可以带多门课程”，直接在线的两端写Teacher "1" -- "0..*" Course；读到“一个订单包含多个订单项”，写Order "1" -- "1..*" OrderItem。多重性写在连接点处，是实实在在的采分点，别省。

6. 把复习错题做成可复现的PlantUML图谱：考前二十分钟的快速回血

复习到后期，最容易出的问题不是不会画，而是画完心里没底。手绘时连线方向很容易“看顺眼”，明明符号画反了，自己还觉得挺对。我的最后一个复习技巧是：把所有综合题都写成PlantUML文件，用渲染结果当标准答案对照，这样每道题都能在考前快速复现。

我的做法是按题型给文件命名，比如case_usecase_01.puml、class_relation_02.puml、sequence_03.puml，一个文件放一道题的完整图描述。准备考试时写一个批量渲染命令，把所有图一次性输出成PNG。

mkdir -p out for f in case_*.puml; do plantuml -tpng "$f" -o "out/" done

-tpng指定输出PNG格式，-o指定输出目录，循环语句遍历所有case_开头的复习文件。本机没有plantuml命令时，把命令替换成java -jar plantuml.jar "$f"即可。全部渲染完成后，把PNG和手绘图并排对比，一行注释都不用写，符号方向对不对一目了然。

错题本也融入到文件里：在puml注释中记下当年踩坑的地方，比如' 错因：include方向画反，箭头应指向被包含用例。考前二十分钟直接搜“错因”或“翻车”，检索出来的全是自己的定向错题，比从头翻课本效率高很多。有一回我拿到“审批流程”类综合题，第一反应画出状态图，结果整道题走偏；后来记住一句话：流程步骤多且角色多，选活动图；单个对象状态切换，选状态图。养成“先判图型、再画图、最后渲染比对”的习惯之后，这类方向性翻车基本绝迹了。希望帮到你。

本文还有配套的精品资源，点击获取