你的系统是做什么的—用例图

按照个人的习惯，这篇文章似乎来得有些晚了，通常了解一件事情时，我总是喜欢从整体到细节。而关于UML的学习，却先学习了结构型建模（《业务概念—类图》），然后是行为型建模（《流程分析—活动图、状态机图、顺序图》）才到了今天的“描述你的系统是做什么的”，不是我想换个方式来认识UML，而是书本上是这么安排的，我只是一个被动接收知识的学徒而已，别想对我有太高的要求
对一般的程序员来说，《业务概念—类图》、《流程分析—活动图、状态机图、顺序图》已经足够应付程序员生涯了（这里仅仅指那些吃青春饭的程序员），听起来有点可悲，但事实就是这样，不容得我们去争辩，因为还有更可悲的，过完了一辈子，只用到了小学六年里学到的东西大有人在
到了这里，至少说明你对软件开发是充满热情的，你愿意花这么多时间来看一篇又一篇或许有用或许没用的技术博客，我相信你一定不甘于做一个码农，如果不幸被我说中，那你应该有想过做一个自己的系统，不为工资，不看别人脸色，仅仅是因为自己喜欢。想要做一个自己的系统，要弄清楚的第一件事：什么人用你的系统做什么事情，来吧，UML中的用例图就是做这个事情的

基本语法

用例图的语法是到目前为止，我所接触过的UML图中最简单的一个，没有分支，没有循环，也没有泳道

• 执行者（Actor），一般用一个小人表示（），一个执行者是一个角色的代表，小人下方的名字表明角色，一般是名词。一个系统中有多个执行者，具体到某一个人时可能有多个角色，也就是一个人可能有多种身份来使用一个系统
• 用例（Use Case），一般用一个椭圆表示（），椭圆里的文字一般是【动词+名词】动宾结构的语句，表明执行者做什么事情，类似于活动图中的活动（但没有主语，用例的主语就是指向他的执行者）
• 关联（Association），一般用直线表示（），直线的一端连接执行者，另一端连接用例，表明执行者通过系统做什么事情（这里的做什么事情就是用例）。直接关联（Directed Association），是比关联更精确的表示，一般用带箭头的直线来表示，箭头可以理解成数据的流向或者谁启动（触发）谁，数据由不带箭头的一端流向箭头一端，或者不带箭头的一端启动（触发）箭头的一端。一般情况下，只需要画出关联即可
• 系统边界（在StarUML中用UseCaseSubject表示），一般用矩形
  
  来表示，矩形上方的文字是该系统的名称，矩形内部一般放多个用例

进阶语法

一般情况下，基本语法已经足够描述一个系统能够做什么事情了，但这还不能够满足比较复杂的系统，为了描述一个较复杂的系统能够做什么，我们还需要学习进阶语法

• 继承（Generalization），面向对象中非常重要的概念，执行者可以继承于执行者，用例也可以从其他用例继承过来，看例子：
  
  
  • 执行者的继承，图书管理员继承于借阅者，可以执行借阅者的全部用例，除此之外，图书管理员还可以执行管理图书的用例，执行者的继承可以简单化（同时美化）用例图，如果没有继承，要表达上图的意思，则画出的用例图会是这样的
    
    利用继承是不是更加形象美观呢？
  • 用例的继承，查询类似于虚基类，并不代表具体的用例。查询还书日期，查询可借阅图书两个用例均继承于查询这个用例
    执行者的继承可能会用到，但用例的继承比较少用
• 用例的扩展（Extend），一般用带箭头的虚线，虚线上带《extend》
  
  来表示。表达的意思是导出报表需要在查看报表的基础上才能执行
• 用例的包含（Include），一般用带箭头的虚线，虚线上带《include》
  
  来表示。表达的意思是管理员工信息包括增、删、改、查四个用例

其他

用例图是用图形的方式来描述什么人通过系统能够做什么，这里的用例一般仅使用【动词+名词】形式的语句来表示，表达内容相当有限，如果某些用例比较复杂，可以考虑使用用例表来描述用例，用例表参考：

需要注意的是，不管是用例图还是用例表，仅仅是描述系统行为的一种方法，任何可以达到目的的方法都是可以接受的，最主要的还是表达清楚系统能够做什么，不要拘泥于形式