用例图——包含(include) 扩展(extend) 和 泛化(generalization）

1、包含(include)

    包含关系：使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用。

                  基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。

                  也就是说，基用例的事件流具有它下属的所有的包含用例的事件流

2、扩展(extend)

     扩展关系：将基用例中一段相对独立并且可选的动作，用扩展（Extension）用例加以封装，再让它从基用例中声明的扩展

                   点（Extension Point）上进行扩展，从而使基用例行为更简练和目标更集中。扩展用例为基用例添加新的可选

                   行为。扩展用例可以访问基用例的属性，因此它能根据基用例中扩展点的当前状态来判断是否执行自己。但是扩

                   展用例对基用例不可见。

                   也就是说，下属的扩展用例对应的事件流是基用例对应的事件流执行完毕后，可选的事件流，重点是可选。

 

3、泛化(generalization)

     泛化关系：子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用

                   父用例的一段行为，也可以重载它。

4、扩展（extend）和 泛化（generalization）的区别

     表面上看起来，好像两者没有什么分别，但是实际上他们之间的区别是非常的大的。

　　泛化：子用例一定和基用例是具有同一种操作的，或者说，子用例、子用例之间、基用例一定是同一种事件流

      扩展：下属扩展用例和基用例并不一定是同一类事件流，而且下属用例是基用例事件流执行完毕之后的一种选择

      有的时候，包含（include）和其他的两种关系也会有一定的重合，在实际操作中，应该自己判断一下，这种关

     系，更倾向于哪一种，从而做出适当的选择，毕竟我们使用用例图的目的是，更加清楚的表述系统的需求，而不

     是使系统的分析更加的复杂

5、下面附上几张图，帮助理解一下

6、下面，我们从整体上看一下，用例图都包含哪些内容

7、下面我们来说一说用例规约和活动图，这里有一个问题：像上图中的每一个用例圆圈就是一个具体的动作，怎么还会有规约和活动图呢？

     实际上，真正合理的用例图中的每个用例都是一个能够代表一个完整动作的事件流，比如：订票可以作为一个用例，而订票这个用例是由

     一些列的有序事件组合完成的—>填写省份证号码—>跳转到支付界面—>确认订票信息—>确定支付—>订票成功。所以才会说一个用例

     对应着一个事件流；也就是说，一张合理的用例图中，有的用例不能够划分的太细，否则就乱了，但是有些用例可以细一点。对于那些隐

     含有一些列的事件的用例来说，为了更加细致的描述它，就要用到用例规约和活动图了，当然如果这个用例过于复杂，那么可以使用二级

      用例图描述它

用例名称	处理销售
用例编号	POS001anquan
执行者	收银员
用例简述	该用例规定了收银员如何利用系统进行销售过程的处理。
涉众及兴趣	收银员：希望能够准确、快速的输入，而且没有支付错误，因为收银员如果少收了钱，就要从他的薪水中扣除相应的金额。 顾客：希望购买过程能够省力，并得到快速的服务，希望得到购买证明，以便退货。 公司：希望准确地记录交易，并满足顾客的要求。希望保证支付授权服务的信息被记录。希望有一定的容错性，即使某些服务暂时不可用（如远程信用卡验证）也能允许收款。希望能够自动、快速的更新帐目和库存信息。 支付授权服务：希望按照正确的格式和协议收到数字授权的请求，希望准确计算给商店的应付款。
前置条件	收银员必须已经被正确识别和授权。
后置条件	存储销售信息，更新帐目和库存信息，生成收据，记录支付授权服务的许可。
基本流程	1．顾客携带购买的商品或服务达到POS机收费口。 2．收银员开始一次新的销售。 3．收银员输入商品标识。 4．系统记录单件商品，并显示该商品的描述、价格和累加值。价格可以根据一套定价规则来计算。收银员重复3-4步，直到结束。 5．系统显示总值。 6．收银员请顾客付款。 7．顾客支付，系统处理支付。 8．系统记录完整的销售信息，并将销售和付款信息发送到外部的记帐系统（进行记帐）和库存系统（更新库存）。 9．系统打印收据。 10．顾客带着商品和收据离开。
扩展流程	1a 任何时刻，发生以下状况，系统将失败：为了支持恢复操作和正确的记帐，要保证所有交易的敏感状态和事件都能够从场景中的任何一步中完全恢复。 1．收银员重启系统，登录，请求恢复上次状态。 2．系统重建之前的状态。 2a. 系统恢复过程中检测到异常： 1．系统向收银员指示错误，记录此错误，并进入一个清空状态。 2．收银员开始一次新的销售。 3a. 非法标识： 1．  系统指示错误并拒绝输入。   4a. 系统生成的商品价格不是顾客想要的价格（顾客抱怨太贵，要求减价）： 1．收银员重写价格。 2．系统显示新的价格。  5a. 顾客声称他们符合打折条件（例如：VIP顾客）：  1．收银员发出打折请求。 2．收银员输入顾客的个人身份信息。 3．系统按照打折条款给出折扣价值。 5c. 顾客要求使用信用卡结帐：  1．收银员发出信用卡结帐的请求。  2．收银员输入顾客的个人身份信息。  3．系统从信用卡上扣除贷款。 6a. 顾客想用现金付款，但随身现金不足：  1a. 顾客使用替代的支付手段。 1b. 顾客告诉收银员，他要取消此销售，收银员在系统上取消此销售。 7a.现金支付： 1．收银员输入收取的现金数额。 2．系统给出应找的金额，并弹出现金抽屉。  3．收银员放入收取的现金，并拿出应找的余额给顾客。  4．系统记录现金支付。 7b. 信用卡支付： 1．顾客输入信用卡帐号。 2．系统向外部的信用卡授权服务系统发送支付授权请求，并请求批准此支付。
非功能需求	1、使用大型平面显示器，交易过程中的信息要能够在1米之外看清楚。 2、 90%的信用卡授权机构的响应应该在30秒内收到。 3、支持多种语言显示。 4、在步骤3和步骤7中可以插入新的业务规则。
业务规则	3a. 商品标识可以用条码扫描或键盘输入。 3b. 商品标识可以是各种不同的编码方式。 7a. 信用卡帐号信息可以使用读卡器或键盘输入。 7b. 记录在纸面收据上的信用卡支付签名。
发生频率	可能会持续发生。
设计约束	系统中断后的自动恢复问题，怎样保存先前的交易记录？