在用例图中，主要包含用例、活动者、关系。
用例：指系统、子系统或类与外部的参与者交互的动作序列说明，包括各种正常序列以及出错序列；用例分析可以认为是对系统功能的分解。
怎样确定用例的粒度：
对一个系统一般无强制性的要求，只要能把功能需求说清楚就行，一般一个系统最好控制在20个用例左右；另外需要注意的是 用例是系统级的、抽象的描述，不是细化的（不具体到某个功能如何做），对于复杂的系统可以划分为若干个子系统进行处理。
怎样获取用例：
活动者希望系统执行什么任务？
活动者在系统中访问哪些信息？
需要将外界的哪些信息提供给系统？
需要将系统的哪个事件告诉活动者？
如何维护系统？
活动者（角色）：系统外部的参与者，可以是用户、外部硬件、其他系统，需要注意：活动者不一定是人，另外如果一个角色的操作由另一个角色代理完成的，请建立该角色到另外角色的依赖。
怎样识别活动者：
谁向系统提供信息？
谁从系统获取信息？
谁操作系统？
谁维护系统？
系统使用哪些外部资源？
系统是否和已存在的系统交互？
关系：关系包含关联、包含、扩展、泛化（其中，包含和扩展属于依赖关系的细化）
关联：用单箭头表示，只表示谁启动用例，不考虑信息的双向流动；每个用例都有角色启动，除非包含和扩展用例；无论用例与角色是否存在双向数据交流，关联总是由角色启动用例；
包含：由基本用例指向被包含的用例。两个以上的用例拥有同一功能，执行基用例时，每次都必须执行被包含的用例 。例如一个系统有两个用例，分别是取消定单和查询定单，执行取消定单用例时，一定要先查询定单，找出需要删除的定单，在执行删除动作，所以取消定单用例包含了查询定单用例。
另外，包含也可以用于：一个用例功能过多需分解成小用例的情况。
比如学生信息管理系统用例，包含了添加学生记录用例、删除学生记录用例、修改学生记录用例，但这种包含情况，被包含的用例不跟角色存在关系，只跟基用例存在包含关系。
扩展：一个用例扩展另一个用例的功能，构成新的用例，需要注意的是被扩展的用例不一定会执行，而且没有活动者指向它。扩展用例子只是部分片段组成，不是完整独立用例，无法单独执行。
比如，我们开发一个定单系统，有一个订购货物的用例，我们可以扩展多一个VIP打折的用例。
泛化：一个用例和其它几种情况的用例间构成泛化。比如一个转帐用例，它包含了跨行转帐以及本行转帐。
这些都是我之前学习UML的笔记，可能思路比较乱，大家凑合着看，欢迎大家提出意见进行交流，祝大家元旦快乐。上海装修公司www.zhixian.com.cn装修
