- 用例(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