1、用例图的粒度：对一个系统一般无强制性的要求，只要能把功能需求说清楚就行，一般一个系统最好控制在20个用例左右；另外需要注意的是 用例是系统级的、抽象的描述，不是细化的（不具体到某个功能如何做），对于复杂的系统可以划分为若干个子系统进行处理。
今天写某个模块的需求说明书，居然把用例图画上了，真是画蛇添足，太不专业了
2、Actor与Use Case以及Use Case间的关系：关联、包含、扩展、泛化。
关联：用单箭头表示，只表示谁启动用例，不考虑信息的双向流动；每个用例都有角色启动，除非包含和扩展用例；无论用例与角色是否存在双向数据交流，关联总是由角色启动用例。
包含：由基本用例指向被包含的用例。两个以上的用例拥有同一功能，执行基用例时，每次都必须执行被包含的用例 。例如一个系统有两个用例，分别是取消定单和查询定单，执行取消定单用例时，一定要先查询定单，找出需要删除的定单，在执行删除动作，所以取消定单用例包含了查询定单用例。另外，包含也可以用于：一个用例功能过多需分解成小用例的情况。
比如学生信息管理系统用例，包含了添加学生记录用例、删除学生记录用例、修改学生记录用例，但这种包含情况，被包含的用例不跟角色存在关系，只跟基用例存在包含关系。
扩展：一个用例扩展另一个用例的功能，构成新的用例，需要注意的是被扩展的用例不一定会执行，而且没有活动者指向它。扩展用例子只是部分片段组成，不是完整独立用例，无法单独执行。
比如，我们开发一个定单系统，有一个订购货物的用例，我们可以扩展多一个VIP打折的用例。
泛化：一个用例和其它几种情况的用例间构成泛化。比如一个转帐用例，它包含了跨行转帐以及本行转帐。
包含和扩展属于依赖关系的细化。
3、网上找到的例子
http://www.imphper.cn/imphper-php-view.php?view=single&id=19
不过觉得不是很专业，也有问题存在
参考：http://www.cnblogs.com/springcsc/archive/2008/12/31/1365730.html
今天写某个模块的需求说明书，居然把用例图画上了，真是画蛇添足，太不专业了
2、Actor与Use Case以及Use Case间的关系：关联、包含、扩展、泛化。
关联：用单箭头表示，只表示谁启动用例，不考虑信息的双向流动；每个用例都有角色启动，除非包含和扩展用例；无论用例与角色是否存在双向数据交流，关联总是由角色启动用例。
包含：由基本用例指向被包含的用例。两个以上的用例拥有同一功能，执行基用例时，每次都必须执行被包含的用例 。例如一个系统有两个用例，分别是取消定单和查询定单，执行取消定单用例时，一定要先查询定单，找出需要删除的定单，在执行删除动作，所以取消定单用例包含了查询定单用例。另外，包含也可以用于：一个用例功能过多需分解成小用例的情况。
比如学生信息管理系统用例，包含了添加学生记录用例、删除学生记录用例、修改学生记录用例，但这种包含情况，被包含的用例不跟角色存在关系，只跟基用例存在包含关系。
扩展：一个用例扩展另一个用例的功能，构成新的用例，需要注意的是被扩展的用例不一定会执行，而且没有活动者指向它。扩展用例子只是部分片段组成，不是完整独立用例，无法单独执行。
比如，我们开发一个定单系统，有一个订购货物的用例，我们可以扩展多一个VIP打折的用例。
泛化：一个用例和其它几种情况的用例间构成泛化。比如一个转帐用例，它包含了跨行转帐以及本行转帐。
包含和扩展属于依赖关系的细化。
3、网上找到的例子
http://www.imphper.cn/imphper-php-view.php?view=single&id=19
不过觉得不是很专业，也有问题存在
参考：http://www.cnblogs.com/springcsc/archive/2008/12/31/1365730.html
