如何识别影响系统的事件
1921字,阅读需时7分钟
来自专栏
课程/专栏

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

我们还是以电话订餐系统为案例,先看下面的这张图。

image.png                                       

图 1 一系列导致用户拨打电话的行为

这张图给出了顾客拨打电话定餐前的一系列行为,第一个行为可能是顾客想到定餐,接着顾客拿出电话准备拨打电话,然后开始拨打电话订餐。这三个行为哪个需要系统响应呢?我们来分析一下,第一个行为顾客想到订餐,在这个行为中,顾客和系统没有交互,系统也无需响应这个行为;第二个行为是准备拨打电话,在这个行为中,顾客同样和系统没有交互,系统也不需要响应这个行为;第三个行为是开始拨打电话,在这个行为中,系统要响应顾客打来的电话,我们说顾客的第三个行为需要电话订餐系统响应,因此顾客拨打电话是一个外部事件。

我们再来看看顾客拨打电话这个事件的前置条件是什么?顾客想到订餐和准备拨打电话这两个行为是拨打电话的前置条件,只有这两个行为发生了,才有顾客拨打电话这个行为的发生。因此顾客想到订餐和准备拨打电话这两个行为是拨打电话这个事件发生的条件。我们在识别系统事件时,不仅要识别出事件本身,还要识别出事件发生的条件。

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

image.png

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

 

在顾客取餐的一系列行为中,顾客要求取餐的行为是外部事件,系统需要响应这个事件。顾客进入店中和顾客排队是取餐的前置条件,那么顾客付款这个行为是条件还是事件呢?我们可以这样考虑,顾客要求取餐,系统开始响应,系统获取顾客订餐的费用,并要求顾客付款,此时的顾客付款是顾客同系统的交互行为,这个交互行为隶属于顾客取餐事件。因此顾客付款是顾客取餐事件中发生的顾客与系统的一部分交互行为,顾客付款不属于事件。

那么,如何判断系统响应是事件还是事件中的交互行为呢?

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

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

当我们判断一个系统响应是事件还是事件的交互行为时,主要是看两个系统响应之间是否存在较长的时间停顿或间隔,如果是连续的系统响应并对应一个事务处理,这些系统响应可以归纳为一个事件的处理过程,而不是一个单独的事件。

另外,在识别事件时,跟踪针对某一外部实体或参与者而发生的一系列事件通常是很有用的,我们看下面这张图。

image.png

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

这张图给出了顾客从查看订餐目录到取餐的完整订餐过程。我们在跟踪顾客订餐的一系列行为时,需要考虑顾客订餐后所引发的各种可能处理。首先,顾客想要看到订餐目录或者咨询订餐情况,接着顾客拨打电话定餐,定餐后也许想要变更定餐内容或者取消定餐。再下来,可能是取餐或者提出送餐。利用跟踪顾客订餐的一系列行为的方法,我们就可以找出顾客拨打电话、顾客变更订餐、顾客取消订餐、顾客取餐这些外部事件。

因此,仔细研究针对某一外部实体或参与者而发生的一系列事件,对定义系统需求是非常重要的。通俗说,这个方法就是顺藤摸瓜,顺着一条线索往下找。

在需求调研阶段,我们重点是调研系统的功能需求。因此还有一些事件,在定义系统需求时可以忽略,但是在设计阶段这些事件却很重要。例如,为了实现系统安全控制,需要安全登录、数据备份、SQL注入过滤等机制。这些机制触发的事件对系统来说是非常重要的,所以在设计阶段需要加入到系统中,但在分析阶段无需把精力和时间花费在这些控制上,只需要将精力和时间放在功能需求上。

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

本节课主要讲了在调查系统需求阶段如何有效地识别事件。通过跟踪外部实体参与事物处理的全过程,可以识别出与外部实体相关的一系列事件,同时在假定技术是理想的情况下,可以忽略掉与系统安全控制相关的事件。下节课,我们将分析人脉系统V1.0的系统事件。

我要评论
全部评论