（2）用例之间的关系及其UML的图示
用例除了与参与者有联系外，各个用例之间也可能会存在一定的联系。这些联系包括：泛化关联、包含关联、扩展关联等。
- 泛化关联：它代表一般与特殊的关系，它充分体现了面向对象的继承性：子类具有父类的所有属性，还可以拥有自己的属性特点及行为。在UML中泛化关联用空心三角箭头的实线表示：其方向从特殊指向一般。
- 包含关联：它指一个基本用例的行为包含了另一个用例的行为，这种关联是一种依赖关系，被包含的用例不能独立存在，只能作为包含它的用例的一部分。在UML中其表示方法为用一条虚箭线从基本用例指向被包含的用例，并标有构造型<
>（在Visio中为< >）。
- 扩展关联：其基本含义与泛化关联类似，但是对于扩展用例有更多的规则，即基本的用例必须声明若干新的规则，扩展用例只能在这些基本的用例上进行扩展以增加新的行为。
例如，保存图书信息用例可以是图书信息修改和图书信息录入用例的扩展，它们之间存在着扩展关系。在UML中，其图形表示方法为在用例图上用一条从基本用例指向扩展用例的虚箭线表示，并在线上标注购造型<>。
七、UML用例图在本项目中的具体应用
（1）确定本项目系统中的角色（参与者）的种类
在本项目的设计中主要是要考虑有多少种不同类型的用户？都是哪几种类型的用户，用户的角色如何定义；用户的访问权限如何分配等。
- 在网上书店应用中
根据应用的要求，可能会有图书信息的浏览者(Visitor，没有进行购买行为的用户)、图书的购买者（Reader）、图书信息的发布者(Publisher)、管理员(Manager如财务人员)以及超级管理员(Administrator，系统管理员)。 - 在网上银行应用中
根据应用的要求，可能会有个人用户和企业用户、管理员(Manager如财务人员)以及超级管理员(Administrator，系统管理员)。 - 确定角色的权限
在设计的时候我们也已经把这些角色与相应的一些操作绑定在一起。如：
Publisher 拥有 Publish_Operation + Modify_Operation +Delete Operation
Visitor 拥有 Visit_Operation,
Reader拥有 Visit_Operation + change ,
Manager 拥有 Visit Money Operation +Sum Money Operation
Administrator 负责 Create_User_Operation+ Delete_User_Operation+ Assign_Permission_Operation+ Deassign_Permission_Operation +Assign_Role_Operation+Deassign_Role_Operation
（2）设计出本电子商务项目系统中的各个模块的用例（UseCase）
- 确定系统边界线
- 通过使用系统边界线矩形框来框定系统中的各个用例同时也通过它能够很清楚地划定内外部事物，因为在系统中所有的用例都应该放在矩形的内部，而在外部是所有该系统的活动者，并且它们被线连到用例。
- 在系统边界线内的每一件事物都是系统的一部分，而在系统边界线外的每一件事物都是系统的外部。
- 用例图的主要作用
在需求分析阶段,可以利用用例图来捕获用户需求。通过用例建模，描述对系统感兴趣的外部角色及其对系统(用例)的功能要求。
本系统中的网上书店的主要用例如下:
- 本系统中的网上银行的主要用例如下
客户主要进行银行帐户的查询、存钱和取钱、转帐交易，也可以修改密码等功能。其用例图如下所示：
