【转】Visual Studio 2010 架构图之用例图（UML Use Case Diagram）

这篇文章是来自园子的，我只是把自己觉得重要的地方，做了更鲜明的标记和解释。

使用Visual Studio 2010可以在项目中添加架构图，项目可以是ASP.NET、Windows Forms、...，也可以创建单独的Modeling Projects。

可以通过下图方式在项目中添加架构图（菜单栏===>Tools===>New Diagram）：

 

 在下面窗口中选择架构图的类型

 

用例图的工具说明：

 

 

1、Actor，参与者/角色，系统的理想用户，通过向系统输入或请求系统输入某些事件来触发系统的执行。包括:

（1）系统用户

（2）其它系统，如：购物网站使用支付宝在线支付，支付完成后再跳转到购物网站处理下一步。

（3）可以运行的进程，如：时间，经过一定时间触发系统某个事件执行。 

总结：可以理解成使用命令的那个角色，可以是整个处理过程的任何一个（可以是client,system,usecase等等），但是在图中更偏重于作为初始点的角色。

 

2、Use Case，用例，用户与系统的交互，外部可见的系统功能单元。比如像增、删、改、查这样的功能点。 

 

总结：可以认为，我们的用户看到的功能，反过来说就是系统对用户开放的功能。

3、Comment，注释。

4、Association，关联关系，描述参与者与用例之间的关系、通信。

 

 

  

总结：这个是种关系，用来描述参与者与用例之间的关系。注意一段为参与者，另一端是开放的功能，因为抽象抽模型的话，这些用例(usecase)就是这个操作黑盒，对于用户来说的入口，所以就用这个用例代表了黑盒的角色。

5、Dependency，依赖关系，用于链接表示不同版本或变体的子系统/用例，源模型指向目标模型。

总结：这一部分，还是从字面理解比较简单。就是Usecase2的情况，决定了useCase1的情况。就是需要先确定Usecase2，这里并不是调用什么的关系，还是种顺序或者递进的关系。这里要注意与extend的区别，extend是有条件发生，而这里是肯定发生。然后再和include对比，include的usecase不会影响到usecase，只是运作中的一部分。而这里的确是会影响到。再换种方式考虑，可以认为一个东西，通过某种处理方式（也可以不处理），转换到了另一个。读做【非箭头端】依赖【箭头端】

6、Include，包含关系，一个用例用其它更简单的用例来描述，定义行为更为明确的用例。

 

总结：是一个UseCase中必然包含的功能。有点类似，某一功能的具体流程。读作【非箭头端】包含了【箭头端】

7、Extend，扩展关系，基础用例的增量扩展，只有满足特定的条件，扩展用例才会被执行。

 

上图中，缴纳罚金只有在比如有车损、租赁超期等情况下才会发生。 

总结：要注意此处的关键语，只有满足特定的条件，扩展用例才会被执行，也就是说有条件执行的，也可以认为是中根据条件更具体的事物。读做【非箭头端】扩展了【箭头端】。

8、Generalization，泛化关系，一般化到特殊化的关系，一个用例可以被特例为一个或多个子用例，子用例表示基用例的特殊形式。

 

总结：对应编程中的继承，就是通例和个例间的关系。【非箭头端】继承了【箭头端】

9、CommentLink：注释链接。

 

MSDN中一个综合一点的例子：

 

  

 更多资料：

UML 用例图：准则 

UML 用例图：参考  

百度百科关于用例图的资料