业务逻辑流程图，业务逻辑流程图绘制指南？( 二 )

b：为什么要画用例图–用户并不关心系统的实现和内部结构，只关心产品所呈现出来的外部特征动态。而用例图恰好就是描述软件产品外部特性的视图，它从用户的角度而不是从开发者的角度来描述需求，分析产品的功能和动态行为。
c：用例图包括三方面内容：参与者（Actor）; 参与者、用例之间的关系，用例（Use Case）; 。用例图模型如下图所示，参与者用人形图标显示，用例用椭圆形表示，连线描述之间的关系。

文章插图
a：参与者：
1、参与者是系统外部的一个实体，它以某种方式参与了用例的执行过程，在UML中，通常用名字写在下面的人形图标表示。
a：真实的人，即用户
这一类是最常用的参与者，几乎在每个系统中。在命名这一类参与者时，应该按照业务而不是位置命名，因为一个人有可能有多重身份。
比如：汽车租赁公司的客户服务代表，通常情况下是客户服务代表，但在她有租赁行为时，就变成了客户。因此，按照业务而不是位置命名可以获得更加稳定的参与者。
b：其他的系统
在有的系统中，还需要建立与其他系统的接口，依然以汽车租赁系统为例，它可能要与外部应用程序建立联系，比如：说外部信用卡应用程序，这时候外部信用卡应用系统就是一个参与者。
c：可运行的进程
以时间为例，当经过一定时间触发系统中的某个时间时，时间就成了参与者。比如：在汽车租赁系统中，到了还车时间客户仍未归还，系统便会提醒客户代表致电客户。由于时间不再在人的控制内，因此它也是一个参与者。
2、参与者间的关系：
对于一些参与者来说，它既扮演者自己的角色，同时也扮演更一般的角色，在案例图中用泛化关系来描述他们（此点与上一节类图中介绍的泛化关系类似）。
b：用例：
1、概念：是对系统的用户需求（主要是功能需求）的描述，用例表达了系统的功能和所提供的服务，描述了活动者与系统交互中的对话；以汽车租赁系统为例，客户向系统发出租赁请求，并向系统中输入数据（姓名等信息），系统响应活动者的请求，进行相应的处理，并且将结果返回活动者。
2、用例与事件流—用例分析处于系统的需求分析阶段，这个阶段尽量避免考虑系统实现的细节问题。但若要建立系统还需要更加具体的细节，这些细节可以写在事件流中。
事件流描述的是一个系统做什么，而不是怎么做，举个栗子，在汽车租赁系统中用例“用户登录”可以采取一下方法：
c：参与者、用例之间的关系
1、关联关系；–这是最常使用的关系，用带箭头的实线来描述。以汽车租赁系统中的“客户”参与这以及和他交互的3个用例（预定、取车和换车）为例。
2、泛化关系–一个用例可以被列举为多个子用例，这就被成为用例泛化，这与类间的泛化关系类似。在用例泛化中，子用例表示父用例的特殊形式，可从父用例处继承行为和属性。泛化关系的图形用空心实线箭头表示，箭头指向父类。
如下图所示是汽车租赁公司用例图中的用例“预定汽车”，该用例有两个子用例“预定大巴中巴”和“预订小车” 。
3、包含关系–指的是其中一个用例（称为基础用例）的行为包含了另一个用例（称为包含用例）。
基础用例包含用例并依赖包含用例的执行结果。但是二者不能访问对方的属性。包含关系的图形为虚线箭头加>，箭头指向包含用例。
4、扩展关系–扩展用例可以被定义为：基础用例的增量扩展，它俩之间为扩展关系。