关于地铁自动售票系统的业务建模（１）

在下用UML做了一个地铁自动售票系统的business use case diagram。
总的用例描述如下：
1。自动售票系统是为T城市开发的，所以该城市的所有年纪大于12的都有一张电子卡，他们可以使用这个售票系统来充值电子卡。T城市居民的这张卡是可以重复充值的。他们可以选择天票的方式充值或则次票的方式充值或则两者

2。每一个访客（非该城市的居民）使用售票系统首先要买一张电子卡并且在买卡的同时就要给这张卡充值。访客的张卡不能重复充值并且在充值的时候要么选择天票要么选择次票。

3。 给电子卡充值的方式有两种:
3.1 天票的方式：以这种方式充值，用户必须指明起始的时间和终止时 间。（用户可以在起始时间到终止时间里，任意次数的乘坐地铁）
3.2 次票的方式：以这种方式充值，用户选择充值的次数。（用户乘坐地铁的次数）

在我的business use case里：
1。将Vistor（访客）作为Inhabitant（居民）的泛actor
2。一个 Buy card ,一个 Charge card。 两个业务用例，然后Buy card 必须要包含 Charge card 这个业务用例。

问题1 ： 大家觉得这个 包含 用的恰当么 ？ 由于用了包含，我在写Charge card 这个用例的流程的时候不是很通顺，因为T城市居民的卡可以在充值的时候选两种方式（比如，某居民在充值的时候首先选了天票，这个过程结束后，他表明想要在充值个次票，这是允许的。但是对于访客来说，他在买票的同时就必须选择是要充值天票还是次票，不能一次性充值两次）

Charge card的业务流程：
参与者：访客
正常流程：
1。访客想要充值
2。访客可以有两种方式充值：天票，次票
3。访客选择充值的方式
4。访客确认充值
5。如果访客的卡是可充值的并且访客想继续充值，那么重复2到4步
6。访客付钱

Buy card 的业务流程：
1。访客想要买卡
2。访客拿到卡
3。访客给卡充值
跳转到Charge card的业务流程

我曾想过将include(包含）的关系去掉，然后Charge card 作为只与Inhabitant(居民）有关系的一个用例；Buy card 作为只与 Visitor(访客）有关系的用例；然后在将Visitor 和 Inhabitant 间的泛化关系去掉，引入一个新的泛化 Traveler ，然后将 Visitor 和 Inhabitant作为Traveler的子类。
经过以上的变形后，我写Charge card 的流程的时候，如下：

参与者：居民

正常流程：
1。居民想要充值
2。居民可以选择充值方式：天票，次票
3。居民选择了充值方式
4。居民确认了充值
5。如何居民想要继续充值，那么重复2到4步
6。居民付钱

Buy card 的流程
参与者:访客
1。访客想要买票
2。访客那到了票
3。访客可以选择充值方式：天票，次票
4。访客选择了充值方式
5。访客确认了充值方式
6。访客付钱

个人觉得变形后的业务流程更清晰，但业务图不如前面的那个（有包含关系的）。当增加了 包含关系后表明在Buy card后必须执行Charge card。变形后的业务图不能很清楚的表明这点，只能在业务流程里看到。

但是前面那个的Charge card的业务流程的参与者比较模糊（T居民和访客），但它的优点是Charge card的这个业务流程得到了重复利用（Buy card里的充值部分其实和Charge card里的大同小异）