大牛：“上节课我们了解了事件及其事件类型，可以帮助我们在定义系统需求时找出影响系统的事件。不过，在实际系统分析中，要找出影响系统的事件并不容易，本节课介绍一些方法可以帮助我们有效地识别影响系统的事件”。

『大牛在黑板上写下了本节课的学习内容』

● 如何区别事件以及引起事件发生的条件？

● 如何区别事件以及系统系统响应？

● 如何跟踪事件的处理过程？

● 在需求分析阶段可以忽略掉的事件。

『大牛将一张图片投影到屏幕上』

图 2-6  一系列导致用户拨打电话的行为

大牛：“这张图给出了顾客拨打电话定餐前的一系列行为，第一个行为可能是顾客想到定餐，接着顾客拿出电话准备拨打电话，然后开始拨打电话订餐”。

大牛：“小白，你说说这三个行为那个直接影响到系统？”

小白：“开始拨打电话这个行为，因为拨打电话系统才开始受到影响”。

大牛：“正确，那你再说说发生拨打电话的条件是什么？”。

小白：“顾客想到订餐和准备拨打电话这两个行为是拨打电话的条件”。

大牛：“对，顾客想到订餐和准备拨打电话这两个行为是拨打电话这个事件发生的条件。因此，在识别系统事件时，要识别出事件发生的条件和事件自身”。

大牛：“再来看看电话订餐系统的顾客取餐过程”。

『大牛将一张图片投影到屏幕上』

图 2-7 顾客取餐过程发生的一系列行为

大牛：“这张图给出了顾客取订餐过程发生的一系列行为，可以看出顾客进入店中、顾客排队是顾客取餐发生的条件，顾客要求取餐才开始影响到系统”。

大牛：“小白，你说顾客付款是条件还是事件？”。

小白：“应该是条件，因为付完款才能取餐啊”。

大牛：“可以这样考虑，顾客要求取餐，系统开始响应，系统获取顾客订餐的费用，并要求顾客付款，此时的顾客付款是顾客同系统的交互行为，这个交互行为隶属于顾客取餐事件”。

小白：“这么说，顾客取餐事件包含顾客付款这个行为”。

大牛：“是的，顾客付款是顾客取餐事件中发生的顾客与系统的一部分交互行为，因此不属于事件”。

小白：“哪如何判断系统响应是事件还是事件中的交互行为呢？”

大牛：“要确定一个系统响应是事件还是随事件而发生的一部分交互行为，采用的方法就是看二者之间是否有较长的停顿或间隔，也就是说系统能否毫无中断地完成事务处理？或者系统能否暂停下来等待下一次的事务处理？”。

大牛：“在顾客取餐过程中，一旦顾客提出取餐，查询顾客订餐内容、顾客付款、变更系统顾客订餐状态等过程会一直持续下去，直到取餐过程结束，整个过程没有明显的停顿。一旦取餐过程结束，系统就暂时中止，等待下一次取餐过程的开始”。

小白：“哦，有点明白了”。

大牛：“判断一个系统响应是事件还是事件的交互行为，主要是看两个系统响应之间是否存在较长的时间停顿或间隔，如果是连续的系统响应并对应一个事务处理，这些系统响应可以归纳为一个事件的处理过程”。

小白：“是否可以这样理解，与取餐相关的所有系统响应都属于取餐事件的交互行为？”

大牛：“可以这么理解，但要注意在事件处理过程中，如果系统中断处理等待一些条件的发生时，此时应考虑定义一个新的事件”。

小白：“哦，明白”。

大牛：“另外，在识别事件时，跟踪针对某一外部实体或参与者而发生的一系列事件通常是很有用的”。

『大牛将一张图片投影到屏幕上』

图 2-8 电话订餐系统顾客的一系列事务处理

大牛：“在电话订餐系统的例子中，需要考虑顾客订餐后所引发的可能处理。首先，顾客想要看到订餐目录或者咨询订餐情况，接着顾客拨打电话定餐，定餐后也许想要变更定餐内容或者取消定餐。再下来，可能是取餐或者提出送餐”。

大牛：“总之，仔细研究针对某一外部实体或参与者而发生的一系列事件，对定义系统需求是非常重要的”。

小白：“牛老师，这叫顺藤摸瓜，顺着一条线索往下找”。

大牛哈哈笑了：“比喻的很贴切”。

大牛：“还有一些事件，在定义系统需求时可以忽略，但是在设计阶段这些事件却很重要。小白，你能想到是那些事件吗？”。

小白：“既然说了设计阶段很重要，是不是与编写程序有关系啊”。

大牛：“设计阶段与编写程序关系不是很大，设计阶段主要关注技术架构、交互界面、物理部署、网络结构等内容”。

小白：“哦，那是不是与系统部署有关的事件呢？”

大牛：“基本接近了”。

大牛：“在设计阶段考虑系统的防范、安全等控制非常重要。例如，为了实现系统安全控制，需要安全登录、数据备份、SQL注入过滤等机制。这些机制触发的事件对系统来说是非常重要的，所以在设计阶段需要加入到系统中，但在分析阶段无需把精力和时间花费在这些控制上，只需要将精力和时间放在功能需求上”。

小白：“不是很明白，牛老师，能不能列举几个例子说明一下呢？”。

大牛：“例如，设计阶段需要考虑数据库的备份事件、系统发生崩溃时，需要恢复数据库的事件、用户登录系统的事件、用户改变系统配置的事件等等”。

大牛：“可以这么说，为保证系统完整性而加入的防范和安全所触发的事件都可以在定义系统需求阶段忽略掉，这些事件一般在设计阶段考虑进去”。

小白：“怎么判断事件是属于系统完整性事件呢？”。

大牛：“在定义系统需求时，一般假定技术是理性的，理想的技术是指系统运行的设备不会损坏、处理和存储能力没有限制、网络带宽通畅、用户完全遵照系统要求且没有误操作等”。

大牛：“通过假定技术是理想的，在需求分析阶段就能排除诸如数据库备份、用户操作失误等事件，因为假定磁盘永远不损坏、用户永远不会有误操作。之后在设计阶段，可以把这些控制加进来”。

小白：“明白了，在定义系统需求阶段，我们只需关注与系统需求有关的事件，并且假定技术是理想的，这样就可以忽略系统安全等方面的事件了”。

大牛：“本节课主要讲了在定义系统需求阶段如何有效地识别事件。通过跟踪外部实体参与事物处理的全过程，可以识别出与外部实体相关的一系列事件，同时在假定技术是理想的情况下，可以忽略掉与系统安全控制相关的事件。下节课，我们将通过练习来回顾和复习前面学过的知识”。