UML基础之用例建模

• 用例(Use Case)是一种描述系统需求的方法，使用用例的方法来描述系统需求的过程就是用例建模。
• 用例方法最早是由Iva Jackboson博士提出的，后来被综合到UML规范之中，成为一种标准化的需求表述体系。
• 用例的使用在RUP中被推崇备至，整个RUP流程都被称作是"用例驱动"(Use-Case Driven)的，各种类型的开发活动包括项目管理、分析设计、测试、实现等都是以系统用例为主要输入工件，用例模型奠定了整个系统软件开发的基础。

  

1.用例图（Use Case Diagram）

 

说明：

    用例模型在 UML 中是由用例图来描述的，并且用例模型可以被划分为多个用例图。 由模型元素和关系构成，主要包括：系统边界、参与者、用例及关系（包含、扩展、泛化三种）。

 

 

注意：

l  一个系统通常不会仅使用一个大而全的用例图来描述，而是会有很多用例图构成。（除非系统非常简单）

l  用一个系统中，可以划分出不同的业务领域，比如，销售管理中，可能会存在“库存管理”、“订单管理”等多个业务领域，而一般的做法是在每个业务领域下都创建用例图。

 

 

1.1 参与者（Actor）

 

 

 

 

定义：是与该系统打交道的人或其他系统。

 

UML图示：

l  首先，参与者也是一个类，UML中的参与者是那些带有构造型 Actor 的类， 类的名称就是参与者的名称；

l  参与者类可以既具有属性，也具有行为，同时还具有用于描述该参与者的文档特性。

 

 

 

特征：

l  参与者是一个类型（一个类），而不是一个实例；

参与者代表了一个群体，比如王二是问道游戏的玩家，参与者应该是“玩家”而不是王二。

l  参与者代表的是角色（Role） ，而不是系统的单个用户。在实践中，用户角色往往和参与者是等同的。

l  同一个人可以是系统中的不同参与者，这主要依赖此人在系统中的角色而定，就像一个人可以拥有不同的角色一样。

l  用例必须由参与者启动；

有时，一个用例是定时执行的一个程序，那么计时器就是此用例的参与者。从来不会出现自启动的用例，总要有外因触发。

l  参与者有时是一个系统

如果用例被外部的一个系统调用，则此外部系统是作为参与者存在的。

如果用例在处理过程中调用了外部系统接口，则此外部系统也是系统内的参与者。

l  参与者是由系统的边界所决定的：

n  如果我们所要定义的系统边界仅限于ATM