UML用例图：由参与者【Actor】、用例【Use Case】以及它们之间的关系构成的用于描述系统功能的动态视图。用例图由参与者、用例、箭头和系统边界构成。
startUML中，UseCase 栏显示如下内容：从上到下是：包、用例、参与者、关联、直联、泛化、依赖、包含、扩展、系统边界。
参与者【Actor】：是指系统以外的，在使用系统或与系统交互中所扮演的角色。
说明：
1、参与者不是指具体的人，只是与系统交互的角色。
比如：对应生产产品来说，人工组装产品，人是参与者。科技发达了，机器人可以代替人生产，机器人这时候是参与者。
2、一个事物或用户可以扮演多个角色，也就是该事物或用户对应系统的多个参与者。
比如：生产过程中，有时赶时间出货，产线上忙不过来，厂长也上产线组装机器。有一天QC请假了，没人顶班，厂长又去当QC了。厂长只有一个，但是扮演了多个角色。
3、多个事物或者用户也可以对应一个参与者。
在生产产品中，组装员工和机器人对应一个参与者。
4、参与者的主要特征是：作为外部用户与系统发生交互。
用例【Use Case】：系统外部可见的一个系统功能单元。系统的功能由系统单元所提供，并通过一系列系统单元与一个或多个参与者之间交换的消息所表达 。
如图：【该图来自：http://kb.cnblogs.com/page/129491/】
包含【include】：使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用。基用例控制与包含用例的 关系，以及被包含用例的事件流是否会插入到基用例的事件流中。基用例可以依赖包含用例 执行的结果，但是双方都不能访问对方的属性。
说明：
1、UML用例图关系中包含关系最典型的应用就是复用，也就是定义中说的情景。但是有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。
2、箭头指向的用例为被包含的用例，称为包含用例；箭头出发的用例为基用例。包含用例是必选的，如果缺少包含用例，基用例就不完整；包含用例必须被执行，不需要满足某种条件；其执行并不会改变基用例的行为。
比如：包工头要接了工程，要建房子。建房子要买材料，要绘图纸，还要砌墙等等：
扩展【extend】：将基用例中一段相对独立并且可选的动作，用扩展（Extension）用例加以封装，再让它从基用例中声明的扩展点（Extension Point）上进行扩展，从而使基用例行为更简练和目标更集中。扩展用例为基用例添加新的行为。扩展用例可以访问基用例的属性，因此它能根据基用例中扩展点的当前状态来判断是否执行自己。但是扩展用例对基用例不可见。
说明：箭头指向的用例为被扩展的用例，称为扩展用例；箭头出发的用例为基用例。扩展用例是可选的，如果缺少扩展用例，不会影响到基用例的完整性；扩展用例在一定条件下才会执行，并且其执行会改变基用例的行为。
比如：砌墙时，抽烟、喝酒由包工头自己决定是否进行。但是建房子砌墙是必须的。如果包工头不抽烟喝酒，不会影响到砌墙的完整性，但是如果喝酒多了，建房子容易出事故，也就是，执行了扩展用例改变了基用例的行为。
泛化【genneralizition】：子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。
比如建房子要搬砖，可以搬红砖，也可以搬水泥砖：
有所不足、多多指正、共同进步！
参考资料：
《StartUML详解》
原文地址：http://blog.csdn.net/androidolblog/article/details/45081205
