首页 > 代码库 > UML---用例图
UML---用例图
用例图（Use case)用于描述用户需求，从使用者角度展现系统的功能。多用于软件开发需求分析阶段的分析工作和软件测试阶段提供测试依据。
基本组成元素
| 图符 | 名称 | 英文 | 简述 |
 | 参与者 | Actor | 与系统进行交互的人或者物， 位于系统外部，如：管理员 |
 | 用例 | Use case | 具体实现的功能与需求的集合 |
 | 关联关系 | Unidirection Association | 一个物体的存在知道另一个物体 |
 | 包含关系 | Dependency or instantiates | 用例之间功能的包含，一个用例 可能包含多个用例（必填） |
 | 扩展关系 | Dependency or instantiates | 某个用例的扩展（功能的扩展） |
 | 泛化关系 | Generalization | 继承关系（功能的继承与扩展） |
 | 注释体 | Note | 描述性字体 |
 | 注释连接 | Anchor note to item | 连接注释 |
 | 边界 | Border | 划分系统范围，系统拥有明确界限 十分重要 |
作图步骤：
1.明确边界。一个庞大的系统必定设计的元素是多方面的，只有明确了边界，才能展开用例分析。具体边界找寻我们可以参考这篇博客：http://blog.csdn.net/beijiguangyong/article/details/6226242
2.确定参与者。参与者在系统外围，只有明确参与则，才能对系统用户需求和系统功能展开设计。
3.用例设计。用例设计要始终站在使用者的角度思考用户需求，包括用例的名字都要体现在使用者的角度。用例描述的是需求或者功能，一般采用动宾短语。
4.确定关系。在其中较难区分的是扩展与包含关系。包含是一种从属关系，必然会发生的事，命名规则及其相近。而扩展则强调功能的补充，不一定要发生。例如：
对于看病用例，一般情况下都是会吃药的，只有病情严重的情况下才输液，这样吃药是属于包含关系，输液属于扩展关系；基本查询功能中，必须要进行账户输入，而不一定要进行Excel打印，因此，账户输入是包含关系，而excel打印属于扩展关系。
5.用例描述与用例说明。用例图为系统设计人员与用户之间提供了良好的沟通桥梁，必要的描述必不可少。
6.界面美化问题。一个好的工程师一定会将图做的清晰可见，这样才能更好的表达自己的意图。
动手操作
总结
UML作图包含了大量的逻辑思考与规范说明，希望在日后一点点的学习中不断总结不断深入了！
UML---用例图
声明：以上内容来自用户投稿及互联网公开渠道收集整理发布，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任，若内容有误或涉及侵权可进行投诉： 投诉/举报 工作人员会在5个工作日内联系你，一经查实，本站将立刻删除涉嫌侵权内容。