企业官网建设流程全解析

简介：完整Word版软件工程画图题目收录了多道典型软件工程建模题，适合正在准备期末考试、考研复试或课程设计的计算机/软件工程专业学生使用。资源覆盖患者监护系统、网上书店、学生选课系统、ATM取款流程、超市连锁收货流程、饮料自动售货机、企业管理系统等场景，涉及数据流图、实体联系图、软件结构图、状态转换图、类图、顺序图、活动图、流程图、盒图、对象图及用例图等核心题型，有助于系统训练画图能力、梳理建模思路。题目还包含GUI状态转换、汽车与自行车类图、打电话顺序图等经典示例，可帮助巩固软件工程各阶段图的绘制方法。资源包为单个Word文档，共1个文件，大小约1.56MB，内容按题目序号排列，可直接打开阅读或打印练习。目前已有135人学习下载，适合作为考前刷题与重点突破的实用参考资料。

1. 软件工程画图题目到底在考什么：先认清这 5 类必考图

软件工程画图题目这个标题，看着像一份期末复习资料，实际上它对应的是软件工程里最容易被低估的一类技能：把一段文字需求翻译成规范化图形模型。画图题从来不是考美术，而是考你对系统边界、层次关系、数据流向这三件事的判断力。见过太多同学把课本例题背得滚瓜烂熟，一换场景就翻车——题目不会让你原样复现「图书借阅」，它只换个壳变成「在线选课」，考点还是那五个：用例图、类图、时序图、数据流图、ER 图。这篇文章就把这几类题型的判分点、画法套路和常见丢分位置一次讲透，适合正在刷题备考的人，也适合想补 UML 基本功的开发者。

2. 用例图：从需求文本里挖出参与者和用例的完整套路

用例图是画图题里出场率最高的一张，也是新手最容易画「胖」的一张。一张用例图只回答三件事：谁在用系统、用系统做什么、系统的边界在哪里。很多人的问题是想太多，把系统内部的步骤、数据库、接口全画进去，结果整张图变成一张没有层次的流程图。下面按出题顺序拆解。

2.1 用例图的最小组成：参与者的三个判断标准

先定参与者。参与者不是「用户」这个词本身，而是所有与系统发生交互的外部角色。常见判断标准有三个：

• 位置在系统边界之外：参与者不能画进系统矩形内部
• 主动发起或被动接收交互：不只是「人」才是参与者，外部系统、定时任务、硬件设备都算
• 能从系统获得可观察的价值结果：比如「读者」借到书，「图书管理员」完成登记

判断标准的作用是帮你在文字需求里圈出所有参与者。比如这段题面：「读者可通过图书借阅系统查询图书、办理借书；图书管理员负责审核借书请求并处理还书。」这里参与者至少有两个：读者、图书管理员。如果题面里还提到「系统每晚自动发送催还通知」，那「定时器」或「通知服务」也是一个外部参与者，虽然它不主动被读者操作，但它主动向系统发起交互。

很多掉分点出在「把数据库当参与者」。数据库作为存储组件不在系统边界外，它不该出现在用例图里；如果题目强行规定画系统环境图，那才需要考虑。换句话说，用例图里的参与者一定是「有目标」的角色，而不是「被调用」的组件。

2.2 包含与扩展的区分：借书还书两个场景对比

用例之间的关系是这类题的核心考点，尤其是<<include>>和<<extend>>的区分。

区别就一句话：包含是「每次都必然执行」，扩展是「满足条件才执行」。一个典型题面是：「读者借书时，系统必须验证读者身份；若读者有逾期未还图书，则不允许借书；还书时，若超期则计算罚款。」

拆解下来：

• 「借书」包含「验证读者身份」，因为每次借书都必须先验证，这是必然步骤
• 「还书」扩展「计算罚款」，因为只有超期才触发，是可选分支
• 「借书」也可以扩展「拒绝借书」的提示流程，但通常把拒绝结果表达为借书用例的异常分支

如果题目给的文字里出现「必须」「首先」「每次」这类词，大概率是包含关系；出现「若」「当……时」「可选择」这类词，大概率是扩展关系。注意扩展的方向：箭头从扩展用例指向被扩展的基用例，标签写<<extend>>。

我用 PlantUML 练习这类题时，会先写出这样的骨架：

@startuml left to right direction actor 读者 as reader actor 图书管理员 as admin rectangle 图书借阅系统 { usecase "借书" as borrow usecase "还书" as return_book usecase "验证读者身份" as verify usecase "计算罚款" as fine } reader --> borrow admin --> borrow admin --> return_book borrow ..> verify : <<include>> return_book ..> fine : <<extend>> @enduml

这里几个语法点要说明：actor 读者 as reader给参与者起了别名，后面引用时直接用别名；rectangle 图书借阅系统 { ... }用来画系统边界，把用例放进矩形内部；-->画参与者与用例之间的实线关联；..>画用例之间的虚线依赖关系，后面的冒号: <<include>>是关系标签，必须原样写<<include>>或<<extend>>。画完检查一句话：每次借书都走验证，所以是 include；不是每次还书都罚款，所以是 extend。

2.3 用例图掉分重灾区：系统边界框住什么、不框什么

系统边界矩形是最容易被忽略的丢分点。边界内部只能放用例，不能放模块、类、数据库或业务流程步骤。判断题面时注意两组常见错误：

第一，把系统内部动作画成用例。比如「查询库存」「更新借阅记录」，这些是借书用例的内部步骤，不是独立用例。用例是对外可观察的目标，而不是内部操作。

第二，参与者与用例的连线方向错误。参与者指向用例表示「参与者发起用例」，箭头从参与者画向用例，方向反了会被判错。如果用例由系统主动触发（比如「发送催还通知」），箭头才从用例指向定时器参与者，这个细节很多人栽过。

还有一个粒度问题：一张用例图里，用例的粒度必须一致。要么都按「用户目标级」画，比如借书、还书、续借；要么都按「子功能级」画。最怕的是「管理图书」和「删除图书」并列出现在同一张图里，管理图书是目标级，删除图书是操作级，粒度不齐，一眼就能被看出来。

3. 类图与时序图：面向对象题目的两个得分大头

如果说用例图考的是「对外边界」，类图考的就是「对内结构」，时序图考的是「对象之间的协作顺序」。这两张图经常在一道大题里前后出现：先根据需求文字画类图，再选一个核心流程画时序图。画错关系线的代价很大，因为判卷时关系线往往按条给分。

3.1 类图四种关系线：依赖、关联、聚合、组合的区别与记忆方法

类图关系从弱到强排列：依赖、关联、聚合、组合。判卷时最容易扣分的集中在聚合与组合的区分上。

• 依赖：虚线箭头，类的一个方法参数或局部变量用到了另一个类，方法结束关系即结束
• 关联：实线，类长期持有另一个类的引用，常见于成员变量，可标注多重性 1、1..、0..
• 聚合：空心菱形实线，整体与部分的关系，但部分可以独立存在。典型例子是「班级」与「学生」，学生毕业了班级还在
• 组合：实心菱形实线，部分的生命周期由整体管理。典型例子是「订单」与「订单项」，订单删除时订单项必须一起删

记忆方法很简单：实心菱形比空心菱形多一层「同生共死」的绑定。画图时先判断删除整体后部分是否还应该存在：还在，用聚合；一起没了，用组合。

下面这张表是踩坑总结，也是考前必看清单：

判断技巧是「生命周期测试」：创建一个整体对象，删掉它，再看部分是否还应该有独立意义。能独立存在是聚合，不能独立存在是组合。

3.2 时序图画法：借书流程的生命线、激活条与消息序号

时序图题目多半给一段流程描述，让你画出对象之间的交互顺序。画图顺序建议固定为四步：

第一步，找参与交互的对象。从题面里找名词，排除掉纯数据项，只留「有行为」的对象。借书场景常见对象：读者、图书借阅系统、图书数据库。

第二步，确定第一条消息。时序图从上到下时间递增，第一条消息通常是外部发起者发出的请求。

第三步，逐条展开消息，注意同步与异步的箭头区别。同步调用用实心箭头，返回消息用虚线箭头。很多人把返回消息画成实线，这是高频翻车点。

第四步，给消息编号。简单流程可以用 1、2、3，嵌套调用的流程推荐用 1、1.1、1.2 表示层级关系。

借书核心流程的 PlantUML 骨架如下：

@startuml actor 读者 participant "图书借阅系统" as system database "图书数据库" as db 读者 -> system: 提交借书请求 system -> db: 查询读者状态 db --> system: 返回读者状态 system -> db: 查询图书库存 db --> system: 返回库存结果 system -> system: 登记借阅记录 system --> 读者: 返回借书成功 @enduml

语法上注意三点：actor 读者声明参与者，participant "图书借阅系统" as system给系统对象起别名，后续消息都用别名；database关键字把图书数据库画成数据库图标的生命线，考试手画时同样用矩形加生命线即可；->是同步消息实线箭头，-->是返回消息虚线箭头，system -> system是自消息，表示系统内部处理，不需要画别的对象参与。试卷上没要求标注消息序号时可以不标，但建议按 1、2、3 顺序标上，方便判卷老师对流程。

3.3 从用例描述反推类图：一个取款场景的逐步拆解

画图题里最难的变体是「根据一段用例描述，画出对应的类图」。核心方法是名词划类、动词划方法、生命周期判断关系。以 ATM 取款场景为例，题面是「用户插入银行卡，输入密码，系统验证密码后，用户输入取款金额，系统检查余额并扣款，最后吐钞并打印凭条」。

先圈名词：用户、银行卡、密码、账户、取款交易、凭条。其中密码通常作为账户的属性而不是独立类，凭条作为交易产生的记录也可以并入交易类。这样候选类定为：用户、银行卡、账户、取款交易。

再圈动词：验证、检查余额、扣款、打印。动词归属到行为发起者：账户负责验证密码和扣款，取款交易负责记录流水和打印凭条。

最后判断关系：用户与银行卡是关联（一个用户可绑定多张卡）；银行卡与账户是关联（一张卡对应一个账户，通常 1:1）；账户与取款交易是组合关系，因为交易的产生和销毁都依附于账户，账户注销时其交易记录不应独立存在。这样推出来的类图，关系线是有依据的，而不是凭感觉画。

4. 数据流图与 ER 图：结构化方法里出场率最高的那张图

用例图、类图、时序图属于面向对象方法，数据流图（DFD）和 ER 图则来自结构化方法。很多学校的软件工程课程把这两张图放在一张卷子里，而且 DFD 的分层平衡是每年必考。它们的共同点是：考的都不是画图技巧，而是「数据从哪来到哪去、数据之间怎么关联」。

4.1 DFD 的分层规则：顶层、0 层、1 层的平衡检查

数据流图由四类元素组成：外部实体（矩形）、加工（圆角矩形或圆圈）、数据流（箭头）、数据存储（开口矩形）。画图题一般让你从顶层图逐层分解，重点考察两个能力：分解的层次是否合理，以及父子图数据流是否平衡。

顶层图只有一个加工，代表整个系统。以图书借阅为例，顶层图画三个元素：读者（外部实体）、图书借阅系统（加工）、图书库（数据存储），数据流是「借书请求」从读者流向系统，「借书结果」从系统流向读者。

0 层图把顶层图里的一个加工分解成多个加工：验证读者信息、查询图书库存、登记借阅记录、生成借阅单。关键规则是：顶层图中流入流出系统的数据流，必须全部保留在 0 层图中，一条都不能丢。

1 层图继续分解某个加工。平衡规则依旧生效：父加工（0 层图中的「查询图书库存」）的输入输出数据流，与它的 1 层子图的输入输出数据流必须完全一致。比如父加工「查询图书库存」的输入是「图书编号」，输出是「库存状态」，那么子图里不能突然多出「读者姓名」这个输入。

检查平衡有个笨但有效的方法：把每个加工当作黑匣子，先在父图上写下它所有流入流出的数据流名称，再对照子图逐条打勾。少一条就是不平衡，多一条也算不平衡。DFD 题大部分丢分都丢在这一步，而不是画图本身。

4.2 ER 图的实体、属性与联系：一对多和多对多的画法差别

ER 图的题目通常包括三部分：找实体、分属性、定联系基数。实体用矩形，属性用椭圆，联系用菱形，这是手画时的标准图形，判卷时图形错直接扣分。

找实体看题目里的「可独立存在且有存储价值的名词」。图书、读者、借阅记录分别是一个实体。属性划分要看归属：简单属性直接挂在实体下，比如图书的「书名」「ISBN」；派生属性要注意识别，比如「读者的年龄」如果可由「出生日期」推算，严格判卷时会建议不单独画属性，或标注为派生属性。

联系基数是 ER 图最核心的判分点。三类：

一定要注意：读者和图书之间在借阅场景下应画成 M:N 直接联系，并通过「借阅记录」这个关联实体携带借阅日期、应还日期等属性。如果题目明确给出「每次借阅需记录借阅日期」，就必须把日期画成联系的属性，而不是某个实体实体的属性。这是 ER 图题目里最常见的区分点。

4.3 同一段借书需求：DFD 与 ER 图的产出对比

同一段需求文字，不同的图回答不同的问题。很多同学把两张图画串，就是在这一点上没分清。DFD 关心数据如何流动、经过哪些加工；ER 图关心数据如何存储、实体之间什么关系。

画图前的第一步应该是判断题目的要求：要求「画出系统 0 层数据流图」就按加工分解来画；要求「画出数据库 ER 图」就按实体属性来画。顺序反了，整张图白费。我一般会先在草稿纸上写下四个问题：系统边界外有谁？系统内部有哪些加工？数据存放在哪里？实体之间的关系是几对几？这四个问题回答完，再决定动笔画哪张图。

5. 软件工程画图题避坑清单：6 个高频翻车点与修正方法

画图题的判分点和代码题完全不同：代码跑不通就是错，图却是「多画一条线也扣分，少画一条线也扣分」。以下六个问题是历年题目里反复出现的翻车点，按「现象、原因、解决」写清楚。

5.1 用例图画成了流程图：把系统内部逻辑直接画进去

现象：用例图里出现「查询库存 → 登记借阅 → 返回结果」这种带箭头的步骤链，甚至把「数据库」画在系统边界内。

原因：把用例当成了流程节点。用例表达「用户的目标」，流程步骤属于活动图的表达范围，两者职责不同。

解决：用例图只保留参与者、用例、关系三类元素。内部步骤要么删掉，要么挪到活动图或时序图里表达。判断标准是：删除这个元素后，用户还能不能用一句话说清自己的目标？说不清，就不是用例。

5.2 时序图箭头方向与消息编号混乱

现象：返回消息画成实线箭头，请求消息和返回消息方向颠倒，消息编号乱跳，比如 1 之后直接跳 3。

原因：没建立「请求-响应」的成对意识。一次调用必然有请求和返回，请求用实线，返回用虚线。

解决：画完每条实线消息后，立刻补对应的虚线返回消息，再画下一条。编号建议按时间顺序递增；如果包含嵌套调用，用 1、1.1、1.2 这种父子编号，父消息的返回线放在所有子消息之后。

5.3 类图关系线乱用：依赖画成关联、聚合画成组合

现象：一个类的方法里用到另一个类，就画实线关联；窗口包含按钮就画空心菱形；订单包含订单项也画空心菱形。

原因：对四种关系的判定只看「有没有用到」，没看生命周期。

解决：坚持前面提到的生命周期测试。方法参数里用到的类是依赖，成员变量持有的是关联，整体不管理部分生命周期的是聚合，整体销毁部分跟着销毁的是组合。把这张判断顺序写在草稿纸角落，画完图后逐条关系线核对一遍。

5.4 DFD 父图子图数据流不平衡

现象：父图中某个加工的输入输出是 3 条数据流，子图里却画了 4 条，或名称对不上。

原因：分解子图时凭感觉加了数据流，把「子加工内部产生的中间数据」误当成父加工的数据流。

解决：子图只能细化加工的内部处理过程，不能增加父图没有的输入输出。中间数据（比如「验证通过标记」）只在子图内部流动，不参与平衡核对。核对时用清单法：父图加工的数据流名称列一张表，子图对应表逐条打勾。

5.5 ER 图出现冗余联系和派生属性

现象：读者与图书之间除了通过借阅记录关联，又画了一条直接联系线；或者把「年龄」作为属性画在读者实体下。

原因：看到两个实体有语义关联就画线，没有考虑这个联系是否提供额外信息。读者和图书的关联已经通过借阅记录实体完整表达，再画直接联系就是冗余。

解决：画联系前先问一句：这个联系能否由其他实体+联系推导出来？能推导就不画。属性同理，能由其他属性计算出来的，不单独画，或明确标注「派生属性」。

5.6 状态图缺初始状态、终止状态和自迁移

现象：状态图没有起始符号和终止符号，状态之间的迁移线上只写了事件名却没写条件和动作，某个状态在事件发生后「原地不动」的情况没有体现。

原因：把状态图当成了「状态之间的连线练习」，忽略了状态图的事件驱动本质。状态图里的每条迁移都是「事件[条件]/动作」结构，空箭头会被扣分。

解决：画图前先列出所有状态，然后给每个状态列出「有哪些事件能离开它」，离开不了的自迁移也要画出来。最后补上实心圆的初始状态和实心圆加外圈的终止状态。检查标准：从初始状态出发，沿着任意一条路径走，必须能到达终止状态或明确停留在某个合法状态。

6. 画图题的进阶验证方法：用最小核对清单给每张图做体检

画完图不对答案，等于白练。但「对答案」也有技巧：直接翻参考答案会让你记住答案本身，而不是记住规则。我更推荐用一套固定体检清单，每张图画完先自查，再对照答案，只记录清单没拦住的问题。

五步清单如下：

这五步走完，多数低级错误都能在交卷前拦住。我自己的习惯是：每道题画完先放下，喝口水回来再用清单走一遍，修改过的错图单独收进一个错题文件，重点标注当时漏掉的是哪一步。时间久了你会发现，翻车的往往不是某个图不会画，而是某一步检查习惯一直缺失。希望这个习惯对你有用，也希望这篇能帮你把画图题从「背题」变成「会题」。

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