企业官网建设流程全解析

刚考完《UML系统分析与设计》这门课，身边不少同学都在抱怨：复习时照着教材把九种图画了一遍又一遍，考场上看到题目还是懵。这其实不是努力不够，而是复习方向跑偏了。UML这门课考的从来不是“你会不会画图”，而是“你懂不懂为什么这么画”。翻开历年真题你会发现，命题老师特别喜欢给你一段业务描述，然后让你判断该用哪种图、元素怎么摆、关系如何定，最后还要你解释建模理由。这篇纪要整理的就是这些东西——高频考点、答题套路、典型题精讲，以及那些教材里没写明但考卷上真正扣分的地方。无论你是刚接触这门课的新手，还是考前突击回炉的同学，照着这份清单过一遍，至少能少走一半弯路。

1. 这门课到底在考什么：从考题反推复习重点

1.1 别把复习做成画图练习

我见过太多人复习UML，就是从第一章开始把每种图的定义、元素、画法抄一遍，然后照着课后题临摹几遍，觉得“画得像”就等于“会了”。结果一到考场上，题目说“请为某自动售货机系统建立用例图”，你脑子里只有教材里那个“图书馆管理系统”的图样，却不知道怎么套进新场景。根本原因在于：你把UML学成了美术课，而它实际是一门建模思维课。

真正的命题逻辑是什么样的？我总结过近几届的考题，发现每道大题的题干都极短，往往只有三五句话的业务描述，真正考察的是三个环节：

• 选型：这个场景该用类图还是时序图？对象生命周期复杂用状态图，业务流程梳理用活动图，这一步错了后面全错；
• 建模：元素是否齐全？关系是否画对方向？参与者有没有写成具体人名？
• 论证：题目最后通常会跟一句“请说明你的建模理由”，这句话值5到8分，答不出来前面画得再好也拿不满。

所以复习的时候，我的建议是“以题带点”：先找两三套真题，不看答案硬做，再把自己卡住的地方对应到知识点上。你会发现，反复卡住的永远是那几个地方——用例图的include和extend、类图的关联和聚合、时序图的消息顺序、状态图的事件驱动。把这些钉子拔掉，比把教材抄十遍管用得多。

1.2 六种核心图的考频与复习优先级

UML官方标准里图的数量已经扩展到十几种，但作为一门本科课程，真正拿来出大题的通常只有六种：用例图、类图、时序图、状态图、活动图，以及偶尔出现的通信图或部署图。我用表格整理了一下考频分布，方便你按权重分配时间。

从应试角度看，用例图和类图是大题雷区，几乎每套卷子都会出现；时序图通常搭配用例图作为第二问；状态图则偏好出在“电梯”“订单”“洗衣机”这类生命周期清晰的对象上。活动图容易被忽视，但恰恰是它最好拿分，因为只要你懂流程图，活动图基本是白送，后面我会细说它的坑在哪。

2. 核心建模元素速查：每个符号背后必须能说出“为什么”

2.1 用例图：需求边界就是系统边界

用例图是需求分析阶段最常用的图，它回答的问题不是“系统内部怎么做”，而是“系统外面站着谁，他们要干什么”。很多同学画用例图时凭感觉加东西，看到“学生选课”就写“数据库”“登录模块”，这些都是典型的错误。

先记住三个基本概念：

• 参与者（Actor）：位于系统外部、与系统交互的角色。注意是“角色”而不是“具体的人”。例如“学生”是参与者，“张三”不是；“管理员”是参与者，“王老师”也不是。参与者可以是人、外部系统、硬件设备，比如“支付网关”“传感器”都可以是参与者。
• 用例（Use Case）：参与者通过系统完成的一个完整目标。命名必须是动宾短语，比如“提交订单”“查询成绩”“打印报表”，不能写“订单处理”——那是系统内部功能，不是用户视角的目标。
• 关系：包含（include）、扩展（extend）、泛化（generalization）三种，这是送分题也送命题。

关于include和extend，无数人在这里翻车。我提供一个百试百灵的判断角度：include是“每次都要做”，extend是“可选做、满足条件才做”。比如网购流程里，要下单必须先登录，所有涉及身份的操作都需要登录，那“登录”就是被包含的公共用例，用带箭头的虚线指向被包含用例，箭头上标注<<include>>；再比如“查询订单”之后用户可以下载发票，但下不下发票不影响查询这个目标完成，那“下载发票”就是扩展用例，用虚线箭头从扩展用例指向基础用例，标注<<extend>>。

区分不清的时候问自己一句话：删掉这个用例，原来的业务流程还成立吗？删掉“登录”，下单流程无法开始，所以它是include；删掉“下载发票”，“查询订单”依然完整体验，所以它是extend。

还有一个容易忽略的点：用例图不需要画系统内部功能分解。把“数据库连接”“权限校验”画进用例图，等于把需求分析图画成了系统模块图，阅卷老师看到必扣分。

2.2 类图：关联、聚合、组合的判定陷阱

类图是UML里信息量最大、也最容易画错的图。它的考点集中在类与类之间的关系上，笼统说有五种：依赖、关联、聚合、组合、继承。这五种关系里，关联、聚合、组合的辨析是历年扣分重灾区。

我自己的判断方法是分三步走：

第一步，看两者生命周期是否绑定。组合关系中，部分的生命周期和整体严格绑定：整体没了，部分也没了。比如“订单”和“订单明细”，删除订单，订单明细一同消失，这就是组合，实心菱形画在整体端。聚合关系则是“整体和部分可以分开存在”：一个班级由多个学生组成，班级解散了，学生还在，这就是聚合，空心菱形画在整体端。

第二步，看关系是长期还是临时。如果A只是偶尔用到B，比如方法的参数、返回值里出现B，那是依赖（虚线箭头），不是关联。依赖是五种关系里最弱的，考试时最容易被人忽略。判断口诀：“依赖是借用，关联是持有。”代码里临时作为局部变量使用，就是依赖；作为类成员长期持有，才是关联。

第三步，看是否构成has-a语义。关联关系描述的是“知道对方存在”，比如“教师”和“课程”：教师知道自己在教哪些课程，课程知道谁在教它，这种双向或单向的平级引用就是关联，用实线连接，可加箭头表示导航方向。

多重性（多重度）也是必考细节。一对多时记得在“多”的一端写1..*，在“一”的一端写1；可选项写0..*或0..1。漏标多重性在考试里扣分极狠，但补起来只要半分钟，属于最不划算的失分。

2.3 时序图与通信图：消息顺序才是灵魂

时序图描述的是“在某个时间段内，对象之间按什么顺序发送消息”。它和类图是一对搭档：类图负责画出有哪些类，时序图负责把类之间的动态交互演一遍。考试中时序图的大题通常给一个用例，让你画出消息序列。

四个关键元素必须熟练掌握：

• 生命线（Lifeline）：一个矩形框加一条向下的虚线，代表一个参与交互的对象或角色。生命线顶部写对象名，不要写类名，比如user: User表示名为user的User实例。
• 激活条（Execution Occurrence）：生命线上的细长矩形，表示这段时期该对象正在执行操作。消息到达时激活条开始，返回消息时激活条结束。
• 消息（Message）：生命线之间的箭头线。实心箭头是同步消息（发送方等待接收方处理完再继续），空心箭头是异步消息（发送方发完不等回应），虚线箭头是返回消息。这三者画错直接扣分。
• 交互片段（Combined Fragment）：用于表达逻辑控制，最常见的是alt（多条件分支）、loop（循环）、opt（可选片段）。有了它们时序图才真正具备表达能力。

考试中判断同步和异步有个直观方法：如果后面的动作必须依赖前面的结果，比如先查库存再提交订单，那么“查库存”就是同步消息，必须用实心箭头；如果消息发出后发送方可以继续做别的，比如用户提交订单后系统发通知邮件，通知动作可以采用异步消息。

通信图（协作图）和时序图表达的是同一件事，只是侧重点不同：时序图强调消息的时间顺序，通信图强调对象间的连接结构。考试时如果同时出现两种图让你选择，就记住一句结论：要分析“顺序和阻塞关系”选时序图，要分析“谁和谁有交互结构”选通信图。

2.4 状态图与活动图：状态是静态的，流转是动态的

状态图和活动图长得像，名字也像，但它们建模的对象完全不同。教科书上的定义比较绕，我换个说法：

• 状态图盯着“一个对象”看。描述的是某个对象从创建到消亡的过程中，经历了哪些状态，在什么事件驱动下发生状态转移。它回答的问题是：“这个对象此刻处于什么状态？状态怎么变？”
• 活动图盯着“一个流程”看。描述的是一个业务流程想完成一个目标时，要依次执行哪些动作、动作之间怎么流转、哪里可以并行。它回答的问题是：“这件事按什么流程走？”

举个例子你就彻底清楚了。假设要建模一个“快递包裹”：

如果用状态图，你会画“已下单→已揽收→运输中→派送中→已签收”，状态之间的转移由事件触发：“揽收完成事件”“到达中转站事件”“签收事件”，箭头旁标注事件名[条件] / 动作。

如果用活动图，你会画“接收订单→分拣→运输→派送”，重点关注的是步骤的先后和并行——分拣和运输之间有传递关系，可能多个包裹并行处理，用分叉和汇合表示并发。

状态图的两个必考细节：一是初始状态用实心圆，终止状态用牛眼符号，很多同学漏画；二是转移标记格式需要写成“事件[监护条件]/动作”，比如签收[金额已付清]/通知发货方，监护条件写在方括号里。活动图的坑则在泳道：泳道（Swimlane）表示动作由谁执行，一旦业务流程涉及多个角色，就必须用泳道把动作归类，漏画泳道也要扣分。

3. 从需求到代码的建模主线：一张图串联一门课

3.1 需求阶段：用例图加活动图锁定范围和流程

很多人复习UML是孤立地背每一种图，最后合上书脑海里一盘散沙。我后来才意识到，这门课按软件开发的生命周期有一条清晰的建模主线：需求阶段用什么图、设计阶段用什么图、实现阶段用什么图，其实是非常固定的。掌握了这条线，你不仅能应付考试，还真的会建模了。

需求分析阶段就两件事：锁定边界、梳理流程。

锁定边界用用例图，核心是确定“谁（参与者）会用系统做什么（用例）”。考试中常见的一个场景是“校园卡管理系统”，考生容易把“消费”“充值”“查余额”全画成一个大型用例图，显得又大又乱。正确的做法是：参与者先找齐——学生、商户、系统管理员；用例按照业务域分组——充值管理、消费管理、卡片管理，组与组之间不要连线，这张图信息已经足够。

梳理流程用活动图，尤其是那些跨部门、多步骤的业务，比如“请假审批流程”“图书借阅流程”。活动图把流程的起点、判断节点、并行分支、终点画出来，整个业务逻辑一目了然。需求阶段的用例图负责说清“做什么”，活动图负责说清“按什么顺序做”，两者互补，这就是建模主线的第一步。

3.2 分析设计阶段：类图、时序图和状态图协同细化

进入设计阶段，你要把需求翻译成技术方案。这一步通常需要三张图配合：

先画时序图，再反推类图。

很多教科书先讲类图再讲时序图，但实际建模中我的习惯是反着来：从用例描述中提取参与交互的对象，画出消息序列，消息在哪个对象上触发了哪些操作，这些操作最后就沉淀为类的方法。比如“提交订单”这个用例，时序图里订单服务、库存服务、支付服务之间来回发消息，画完时序图你自然就能列出它们各自要承担哪些职责，类图里的方法栏直接抄作业就行。

类图负责静态结构，时序图负责动态行为，状态图负责生命周期复杂的对象。

判断哪些对象值得画状态图，就一句话：这个对象有没有“多个值得关注的稳定状态”？订单有“待支付、已支付、已发货、已完成”，值得画；一个普通的“计算器”对象只有“空闲、计算中”两个状态，没必要画。考试里只要出现“控制系统”“订单系统”“ATM机”“电梯”这类词，十有八九要配套状态图。

3.3 实现与部署阶段：构件图和部署图快速认识

这两个图在整个课程里戏份不重，但不代表不考。考试多以选择题或判断题出现，偶尔在简答题里让你说出它们的作用。

构件图关注的是软件模块之间的依赖关系。比如一个分层架构里，表示层依赖业务层，业务层依赖数据层，你就用两个矩形块加一条带箭头的虚线如实表达。部署图关注的是软件跑在什么硬件节点上：一个应用服务器节点上部署了Web应用和数据库服务，用节点方块表达硬件，节点内部列出构件名。

复习建议很简单：能说出构件图和部署图各自解决什么问题，能分辨哪张图是描述模块依赖、哪张图是描述物理部署，这就够了。别花太多时间深挖——它们不是大题素材。

4. 典型习题精讲：把答题思路拆开揉碎

4.1 用例图大题：识别参与者与用例的关系

题目背景：现要开发一个在线考试系统，考生登录后可参加考试、查看成绩、下载成绩单；管理员负责管理题库、发布考试、人工复核主观题成绩。请画出该系统的用例图，并说明include和extend的使用。

把这道题做对，需要一套稳定的答题流程，我管它叫“三找一标”：

第一找参与者：通读题干，圈出所有动词的主语（谁要做事）和“与系统交互的外部角色”。本题中“考生”是核心参与者，“管理员”是另一个核心参与者。注意“数据库”不是参与者，它是系统内部部分。

第二找用例：参与者一出现，后面跟的动词短语几乎就是用例。考生这边有“参加考试”“查看成绩”“下载成绩单”；管理员这边有“管理题库”“发布考试”“复核主观题成绩”。用例与用例之间默认是独立的，不要连线和嵌套。

第三找公共用例：哪个用例是多个用例都会用到的？参加考试要登录，查看成绩也要登录，所以“登录”被“参加考试”“查看成绩”“下载成绩单”共同包含，画成include。管理员侧如果也需要登录，同样include。

第四标extend：哪个用例是可选且不影响主体功能的？“下载成绩单”是在“查看成绩”之后的一种延伸操作，不是查看成绩的必要步骤，所以从“下载成绩单”虚线指向“查看成绩”，标注<<extend>>。

完整画出来之后，阅卷老师还会看一个问题：你给每个用例命名时用的是不是动宾短语。“在线考试”就不合格，改成“参加在线考试”才算完整目标。

4.2 类图大题：关系强度的三层判断法

题目背景：图书馆管理系统需要一个借阅模块，读者可以借阅图书，一次可借多本；每本图书同时只能被一个借阅记录关联；系统还要记录每次借阅的借书日期和应还日期。请画出该模块的类图并标注关系。

这道题锻炼的是从文字中抽类的核心能力。我的拆解步骤：

第一步，圈名词，过滤掉“多余名词”。题干里出现的名词有：图书馆、读者、图书、借阅记录、日期。其中“图书馆”是边界还是核心类？本题只做借阅模块，图书馆不必建模；“日期”可以直接作为借阅记录的属性，不单独成类。于是候选类确定为：读者（Reader）、图书（Book）、借阅记录（BorrowRecord）。

第二步，确定关系类型。读者和借阅记录：一位读者有多条借阅记录，借阅记录不能脱离读者存在吗？从业务上讲，删掉读者，其历史借阅记录依然要保留在系统里做审计，所以它们是关联关系，多重性为1..*。图书和借阅记录同理，一本图书可以对应多条借阅记录（历史记录），也是关联关系1..*。这个例子里没有明显的聚合组合，但很多同学会把“读者和借阅记录”画成组合，这就错了——组合意味着两者生死绑定，而实际上借阅记录是独立的历史档案。

第三步，补全属性和方法。属性从题干描述里直接找：“学号、姓名、读者类型”通常在上下文里隐含；“ISBN、书名、馆藏数量”是图书必带；借阅记录有“借书日期、应还日期”。方法栏不要贪多，写核心业务方法就行，比如borrow(readerId, bookId)、returnBook(recordId)。

考试卷面上画类图，最大的扣分点是“菱形方向画反”。记住规则：聚合组合的空心/实心菱形一定画在“整体”那一端。读者和借阅记录若画成聚合，菱形也要画在整体端（Reader端），画到Book端就成了“图书聚合借阅记录”，语义完全反了。

4.3 时序图大题：从需求描述到消息序列

题目背景：用户通过网页提交订单，系统先检查库存，库存充足则生成订单并调用支付接口完成支付，支付成功后将订单状态改为已支付。请画出该场景的时序图。

这种题我推荐直接按“消息序列推导法”来做，核心是把题干里的动词按因果顺序排列：

1. 用户 -> 订单界面：提交订单请求
2. 订单界面 -> 订单服务：创建订单()
3. 订单服务 -> 库存服务：检查库存(商品Id)
4. 库存服务 --> 订单服务：库存结果
5. alt [库存充足]
6. 订单服务 -> 支付服务：发起支付()
7. 支付服务 --> 订单服务：支付结果
8. 订单服务 -> 订单：更新状态为已支付
9. 订单服务 --> 用户：提交成功
10. end alt

画图时有三个细节必须留意，它们都是真实的扣分点：

消息箭头类型：第3、4步是同步调用和返回，检查库存必须等结果才能继续，所以第3步是实心箭头实线，第4步是虚线箭头。支付同理。消息名后面要加括号，类似调方法。

alt条件分支：第5步到第10步整体处在alt [库存充足]片段里。很多同学不画交互片段，而是直接画一个分支箭头，这在UML里是不允许的。只有活动图才用菱形分支，时序图的分支只能用alt片段框。

激活条的位置：每个对象的生命线上都要画出激活条，激活条从消息到达开始，到返回消息结束。漏画激活条，图看起来像简笔画，也是扣分项。

4.4 状态图大题：有限状态机的建模模板

题目背景：某电梯控制系统，电梯有上行、下行、静止三种运动状态，门有开门、关门两种状态。请建立电梯的状态图，并说明每个状态转移的触发事件。

状态图大题的答题思路比其他图更固定，严格按“四步法”走：

第一步，找出对象的所有可能状态。电梯作为一个整体对象，可以区分为六个状态：静止（idle）、上行（up）、下行（down）、开门（open）、关门（closed）。通常把“开门”“关门”和运行状态分开看，但考试要求统一建模时，就列出所有的正交组合。

第二步，找到初始状态和终止状态。电梯开机后处于“关门静止”，所以初始状态画实心圆指向该状态；电梯几乎不会消亡，终态往往省略或不画。

第三步，穷举事件与转移。这是得分的主体，每写一个转移都要按“事件[条件]/动作”格式：

• 关门结束 / 门锁上：closed → idle
• 上升请求[目标楼层高于当前] / 电机启动：idle → up
• 到达目标楼层 / 制动停止：up → idle
• 开门请求 / 释放门机：idle → open
• 开门超时 / 关门：open → closed

第四步，简答建模理由。这题为什么用状态图而不是活动图？因为我们要研究的是“电梯对象在不同时刻的状态变化”，而不是“业务流程步骤的先后”，状态图天然适合表达事件驱动的状态切换，活动图适合表达动作流程。把这句话写上，简答分就到手了。

状态图最常见的低级错误是搞混事件和状态。比如有些人会写“状态：正在上升”，然后转移箭头写“检测到上升事件”——上升事件是促使电梯从静止切到上升状态的驱动条件，而不是状态本身。把“事件”当“状态”写，阅卷老师会认为你根本没理解状态机的本质。

5. 复习备考的实操工具箱：我踩过的坑和验证过的套路

5.1 以题为纲做知识复盘，而不是以章节为纲

我第一轮复习是拿期末题库直接刷，先做再对，然后回到教材定位知识点。这个方法比按教材目录一章一章过效率高一倍，因为UML的知识点环环相扣，孤立的记忆很容易忘。做完一套题你会发现错误集中在几个固定位置，比如我当初总是在include和extend上反复摇摆，后来痛定思痛，自己编了一句口诀：“包含是一定的，扩展是可选的”，再也没错过。

题库做三遍：第一遍查漏，标记不确定的题；第二遍只看错题，把原因写旁边；第三遍限时模拟，训练答题节奏。大题一定要动手画出来，不能只看答案。我之前总觉得“看懂了就等于会了”，结果考场上发现自己连箭头的方向都拿不准，这是血泪教训。

5.2 画图细节上的常见扣分点清单

以下每条都是阅卷中高频出现的扣分原因，考前对照自检一遍：

• 关系符号画错方向：泛化三角箭头指向父类，不是子类。Aggregation和Composition的菱形画在整体端，而不是部分端。
• 用例名不是动宾短语：“考试系统”“信息管理”这类名词短语不是用例，改成“参加考试”“管理信息”才合规。
• 时序图消息没有顺序标注：时序图默认按时间从上到下排列，一般不必加数字序号，但如果题目要求说明顺序，可以按1:、2:标注。
• 状态图漏画初态或终态：实心圆和牛眼符号各画一个，一秒钟的事，画出来就有分。
• 依赖和关联混淆：带箭头的虚线是依赖（临时借用），实线是关联（长期持有），画错了整个图的关系语义都跑偏。

我把这些细节做成了一张A4纸贴在书桌前，考前反复看，亲自验证过来，比刷十道题更能兜底。

5.3 考前两天的冲刺清单

最后两天不要贪多，围绕下面几项做温习就足够：

• 过一遍关系判断口诀：依赖是借用、关联是持有、聚合可分离、组合同生死、继承是泛化。每个口诀找一个题目实例对号入座。
• 亲手画一遍题库里的六道典型大题：在线考试系统用例图、图书馆类图、订单时序图、电梯状态图、选课活动图、ATM部署图。不求新题，只求熟练。
• 默写时序图画法规范和状态图转移格式：这两处是硬规则，丢分最可惜。

我自己在考前最后一晚做完了这份清单，第二天考场上拿到卷子，看到那几道大题差点笑出声——全都见过。哪怕题目换了背景故事，解题套路一模一样。

最后说点题外话。我始终觉得UML这门课最有价值的不是让你背会多少种图，而是让你养成一种习惯：动手写代码之前，先在脑子里把对象、职责、交互顺序过一遍。这套思维方式一旦形成，你后面学设计模式、学架构设计都会顺很多。复习纲要终究只是考试的手段，把建模的思路真正用起来，才是这门课的最终目的。