用例图别再乱画了：一篇讲清角色、功能和系统边界
适合场景：毕业设计、需求分析、系统功能说明、答辩材料
关键词：用例图、UML、需求分析、角色权限、毕业设计 在线体验：www.drawdoc.cn
很多同学画用例图时，第一反应是把系统功能全塞进去：登录、注册、管理、查询、审核、统计……最后图里全是椭圆，老师看完也不知道系统到底给谁用、每个角色能做什么。
其实用例图最重要的不是“功能多”，而是讲清楚三件事：
- 系统有哪些参与者；
- 每个参与者能使用哪些功能；
- 这些功能之间有没有包含、扩展或父子层级。
下面用码绘的用例图工具做一个完整拆解。
1. 用例图到底解决什么问题？
用例图不是页面原型，也不是功能菜单截图。它是需求分析阶段用来描述“系统边界”的图。
一句话理解：
用例图回答的是：谁可以使用系统，系统向这些角色提供哪些能力。
比如一个志愿服务平台，至少会有：
- 管理员：管理用户、审核活动、维护公告；
- 志愿组织：发布活动、查看报名、管理活动；
- 志愿者：浏览活动、报名活动、查看记录。
这些内容如果只写成文字，读起来很散；画成用例图后，系统边界会清楚很多。
2. 先从角色开始，不要先堆功能
画用例图时，建议先列角色，再列功能。
常见顺序是：
角色 → 功能 → 功能关系 → 导出/放论文
在码绘里，可以先选择某个角色，例如“管理员”，右侧会自动展示这个角色对应的用例图。
这样做的好处是：一开始不会被所有功能淹没。先把单个角色的职责理清，再合成系统总图，会比直接画一张大图稳得多。
3. 系统总图适合放论文，角色单图适合讲细节
如果论文只放一张图，建议放系统总图，因为它能让读者看到完整的角色和功能范围。
但答辩讲解时，不一定要从总图开始硬讲。更自然的方式是：
- 先用系统总图说明系统边界；
- 再选管理员、普通用户等角色单独展开；
- 对复杂功能再拆子用例。
这样老师追问“管理员具体能做什么”时，你可以顺着角色图继续讲，而不是在总图里到处找功能点。
4. 三级用例什么时候用？
三级用例不是越多越好。只有当某个功能本身还需要继续拆分时，才需要画到三级。
比如“活动管理”可以继续拆成：
- 发布活动；
- 编辑活动；
- 审核报名；
- 查看活动数据。
这时三级用例就很有价值。
如果只是“登录系统”“查看列表”这种很简单的功能，就没必要再硬拆。图越复杂，反而越难读。
5. 不知道怎么开始，可以先生成一版再改
如果你手里只有系统题目，还没整理好需求，可以先让工具生成一版用例文案，然后再人工修改。
这里要注意：生成结果只能作为草稿。最终放进论文前，仍然要根据自己的系统功能做删改，尤其是角色名称、权限边界和功能粒度。
6. 论文里怎么描述用例图？
可以按下面这个结构写：
本系统主要包括管理员、普通用户等参与者。
管理员负责用户管理、信息维护、数据审核等功能；
普通用户可以完成信息浏览、申请提交、个人信息维护等操作。
系统通过用例图展示不同角色与功能模块之间的关系。
系统用例图如图 X-X 所示。
不要把图里每个椭圆都念一遍。论文描述要概括角色职责，而不是复述图形。
总结
画用例图时，记住一个原则：
先画角色，再画功能；先讲边界，再讲细节。
如果你从功能列表开始，很容易堆成一张“椭圆大杂烩”。如果从角色和系统边界开始，图会清楚很多，也更适合放在毕业论文的需求分析章节。
