上周日，我去工商银行自助柜员机取钱的时候，发生了一起意外的事件-自己的银行卡被柜员机给吞掉了。
过程情况大概是这样的：我将卡插入柜员机后，选择取款，金额数量为3500，然后等待柜员机出钞。当我将钞票取出来之后，选择了退卡，但是当时我正忙于清点钞票，并没有留意还在插在柜员机上的银行卡。清点完钞票，当我正要取卡的时候，柜员机突然将我的卡吞掉，同时打印了一张纸质凭条，上面包括两方面信息，一个是我的银行卡号，一个是操作事件流水号，同时我的手机也收到了一条通知短信，短信告知我在5个工作日后并且30日内去与柜员机绑定的工商银行大厅带有效证件办理取卡。
其实之前我并没有这方面的经验，只能先拨通了工商银行卡的客服电话。
客服姐姐的声音还是很甜的，她向我索要了流水号，然后查询之后，反馈的信息也是短信中的内容。
经过这件事，我发现类似我这种将银行卡搁置在柜员机的行为也是银行的一项业务。
那么接下来让我们来做一些文档名词的约定：首先，我们先对即将用到的元素进行标记，我们称柜员机为“机器”，将机器的系统称为“系统”，将我称为“操作人”，将银行卡含在柜员机上没有被操作人取回这件事称为“取卡超时”，将取卡超时后系统的自动化操作称为“吞卡通知业务”，同时这里还会用到短信系统，区域网点通知系统等等（系统具体的布局和组织架构我也不清楚，只是为了方便描述作为一种假设），我对这些系统不再做标记，只会在用到这些系统时，尽量将这些系统以更加语义化的方式表达。
需求分析学中，取卡超时属于业务事件的范畴，它的目的用于触发业务用例，英文的缩写为BUC（用缩写的目的只为装个B），业务用例的解释为业务事件触发后，系统的一系列自动化的操作（切记是自动化）。
约定描述完毕后，我们将讨论系统对“取卡超时”这个事件触发的业务用例是什么：这里有一个前提，就是银行卡已经执行过一次被柜员机的吞入和吐出事件。这种前提本身也代表银行卡的一种状态，暂且称它为状态A吧。当银行卡处于状态A时，它是混沌的，也就是说它还需要一些操作才能使系统不去执行自动化的操作，混沌的状态A会有两种选择，一个是被操作人取回（很明显，我没干这件事），另一个就是当状态A持续一段时间后（我的时间为30秒），它就变成了状态B，状态B就是“取卡超时”这个事件。
补充一下事件的两种来源，一种是人为操作触发事件，一种是时间计时触发事件，时间计时触发事件包括三类，一类是时间点的触发事件，一类是时间段的触发事件，还有一类是两种事件混合的触发事件。这些事件看名字都是比较容易理解的，比如你的闹钟在早晨7点钟响了，这就是时间点的触发事件，炸弹在30分钟后爆炸，这就是时间段的触发事件。很明显“取卡超时”属于时间段的触发事件。
当取卡超时发生时，系统首先将卡吞掉，然后会至少触发四个系统，一个是短信系统（就是给我发送短息的那个系统），一个是中央储蓄卡系统（用于存储当前卡的状态），一个是区域网点通知系统（告诉银行人员，有个傻瓜忘记拿银行卡了，你们来帮他取回），还有一个就是本地系统（打印凭条就靠它了）。
业务的流程大概是：卡被吞入后，本地系统打印了凭条，同时通知三个系统，短息系统接收到通知后，向我发送了短息，网点通知系统收到通知后，向当地网点银行发送信息（可能以一种待办通知的方式），中央系统直接记录银行卡的状态信息。当然，以上三个系统也是被通知触发各自相应的用例。
我给客服小姐姐打电话，她查询我银行卡的信息就是通过中央系统。
以上就是我对这件事的分析，好歹吃一堑，长一智。这里还有一种情况没有说明，就是银行卡即将被吞入的瞬间，我强制性拔卡，那会发生什么事情呢？估计头顶突然出现两挺机关枪，然后一阵突突突突，从此我就永远的 game over 了。
