原文分析法(Textual Analysis),是在用例说明与流程分析的基础上进行的业务领域分析,是一项在需求研讨会后整理和分析需求的工作。当我们完成了用例图的绘制,为每个用例编写出用例说明以后,原文分析的工作就可以开始了。要讲解原文分析,我们还是用一个实例更简单明了:
这是一个实际项目的用例说明。在进行原文分析的时候,我们首先要做的事情就是对用例说明中事件流部分的文字描述,提取其中的名词。在这个实例中都有些什么名词呢?这些名词我在用例中用蓝色标注了出来,经过整理就是这些:触发器、考核指标(简称指标)、执法行为、指标定义、过错标准(过错判断标准)、过错行为、考核结果、年度、月份、机关、分子数、分母数、过错数、正确率。
领域模型中的实体,往往就在我们通过原文分析提取出来的这些名词中,但需要我们进行进一步分析。并不是所有名词都可以成为实体,那么哪些可以呢,而哪些又不能呢?首先,系统外的参与者不能。系统外的参与者是触发本系统某个事件的人或者物,但它本身存在于系统之外,比如用户使用鼠标点击了一个按钮,而领域模型是描述系统之内的事物,因此系统外的参与者应当被排除。本例中的触发器就是系统外的参与者(参见《功能角色分析与用例图》),它应当被排除。
其次,系统之内的事物转化到领域模型中,可能会变成两种东西:实体与实体中的属性。什么变成实体而什么变成实体中的属性呢?自身有自己的属性,可以成为系统中行为的执行者或施与者的,才是实体。比如考核指标就是实体,因为它有它的考核标准、过错行为、分子数、分母数、过错数、正确率等属性,它在系统中会去执行考核,所以是实体;分子数是不是实体呢?它仅仅是一个数据,没有自己的属性和方法。另一个判断是实体还是属性的方法就是判断它将如何持久化。如果一个事物被持久化到数据库中时是一个表,则是一个实体;如果仅仅是表中的一个字段,则是一个属性。
然而,是实体还是属性并不是那么绝对,关键看系统对这个事物进行怎样的处理。比如过错标准是一个实体还是一个属性呢?如果我们在系统中仅仅是一个文字描述则是考核指标中的一个属性,如果需要对它进行分解,有它的判断公式,需要让它去执行判断,则应当是一个实体。在需求分析的初期,可以先将其设计成一个属性,待日后的细化阶段再进行调整。
另外一个非常重要、值得我们着重关注的地方是名词的多义性。在本例中,我们考察一下“过错行为”这个名词。“一种过错行为”与“一个过错行为”显然不是一个概念。“一种过错行为”代表的是一种类型,有它的过错定义与判断标准;“一个过错行为”则代表的是一个实例,一个执法行为中的某个错误的行为。正因为它们概念上的差异,我们在领域模型中将其分为“过错类型”与“过错行为”。
经过一番分析,我们绘制出了一个基本的领域模型。毫无疑问,这个领域模型使用的是一个类图,实体在图中就是一个个的类。同时,我们将各个类之间的关系标注出来:一对一、一对多、多对多、聚集、组合、继承,等等。为了提高模型的可读性,我们在必要时可以标注关系的名称。如考核指标与执法行为之间是类型与实例的关系,等等。
现在,让我们重新回到原文分析。这次要分析的不是用例说明中的名词,而是动词,在本例中我用红色标注出来。最后,我们整理出这些动词:触发、执行考核、预警、采集、判断、是过错、是正确、打分、统计。
对用例说明中的动词分析,是为了定义各个实体之间的各种行为。同样,并不是所有动词都是实体的行为。参与者的行为显然不是实体的行为,应该被排除掉,如:实例中的“触发”。还有一些动词是某个行为的一个细节,如:“是过错”、“是正确”,被合并到“过错判断”中。最后,将行为添加到行为的执行者中。最后绘制出这样一个领域模型:
领域模型有别于后期的分析模型,其中最关键的就是目的,它的目的仅仅是分析需求,因此在很多地方会比较模糊而不考虑技术实现,比如本例中的“指标定义”、“过错标准”。另外一个比较关键的地方就是,系统中的行为到底由谁来执行,这个标准常常是说起来容易做起来难。我给大家的建议是参考GRASP中的“信息专家”模式。
GRASP是一种职责驱动设计的系统分析方法,它的“信息专家”模式是这样描述的:应当将系统中的行为交给信息专家去执行,而信息专家就是掌握着执行该行为所需数据的实体。在本例中,由于考核指标掌握着指标的定义,还有那些执法行为,所以它可以执行考核,而过错类型则掌握着过错标准,因此可以执行过错的判断。注意,这里的“执行”什么行为,是软件意义上的概念,即一个类可以拥有什么行为,而非现实世界的概念。要知道现实世界中的事物是不可能有主动执行什么操作的能力的。
过去我们拿到需求不知道该怎样去业务领域分析。有了原文分析方法,给了我们一个简单可行、易于操作的方法,让我们准确而高效地完成业务领域分析。
这是一个实际项目的用例说明。在进行原文分析的时候,我们首先要做的事情就是对用例说明中事件流部分的文字描述,提取其中的名词。在这个实例中都有些什么名词呢?这些名词我在用例中用蓝色标注了出来,经过整理就是这些:触发器、考核指标(简称指标)、执法行为、指标定义、过错标准(过错判断标准)、过错行为、考核结果、年度、月份、机关、分子数、分母数、过错数、正确率。
领域模型中的实体,往往就在我们通过原文分析提取出来的这些名词中,但需要我们进行进一步分析。并不是所有名词都可以成为实体,那么哪些可以呢,而哪些又不能呢?首先,系统外的参与者不能。系统外的参与者是触发本系统某个事件的人或者物,但它本身存在于系统之外,比如用户使用鼠标点击了一个按钮,而领域模型是描述系统之内的事物,因此系统外的参与者应当被排除。本例中的触发器就是系统外的参与者(参见《功能角色分析与用例图》),它应当被排除。
其次,系统之内的事物转化到领域模型中,可能会变成两种东西:实体与实体中的属性。什么变成实体而什么变成实体中的属性呢?自身有自己的属性,可以成为系统中行为的执行者或施与者的,才是实体。比如考核指标就是实体,因为它有它的考核标准、过错行为、分子数、分母数、过错数、正确率等属性,它在系统中会去执行考核,所以是实体;分子数是不是实体呢?它仅仅是一个数据,没有自己的属性和方法。另一个判断是实体还是属性的方法就是判断它将如何持久化。如果一个事物被持久化到数据库中时是一个表,则是一个实体;如果仅仅是表中的一个字段,则是一个属性。
然而,是实体还是属性并不是那么绝对,关键看系统对这个事物进行怎样的处理。比如过错标准是一个实体还是一个属性呢?如果我们在系统中仅仅是一个文字描述则是考核指标中的一个属性,如果需要对它进行分解,有它的判断公式,需要让它去执行判断,则应当是一个实体。在需求分析的初期,可以先将其设计成一个属性,待日后的细化阶段再进行调整。
另外一个非常重要、值得我们着重关注的地方是名词的多义性。在本例中,我们考察一下“过错行为”这个名词。“一种过错行为”与“一个过错行为”显然不是一个概念。“一种过错行为”代表的是一种类型,有它的过错定义与判断标准;“一个过错行为”则代表的是一个实例,一个执法行为中的某个错误的行为。正因为它们概念上的差异,我们在领域模型中将其分为“过错类型”与“过错行为”。
经过一番分析,我们绘制出了一个基本的领域模型。毫无疑问,这个领域模型使用的是一个类图,实体在图中就是一个个的类。同时,我们将各个类之间的关系标注出来:一对一、一对多、多对多、聚集、组合、继承,等等。为了提高模型的可读性,我们在必要时可以标注关系的名称。如考核指标与执法行为之间是类型与实例的关系,等等。
现在,让我们重新回到原文分析。这次要分析的不是用例说明中的名词,而是动词,在本例中我用红色标注出来。最后,我们整理出这些动词:触发、执行考核、预警、采集、判断、是过错、是正确、打分、统计。
对用例说明中的动词分析,是为了定义各个实体之间的各种行为。同样,并不是所有动词都是实体的行为。参与者的行为显然不是实体的行为,应该被排除掉,如:实例中的“触发”。还有一些动词是某个行为的一个细节,如:“是过错”、“是正确”,被合并到“过错判断”中。最后,将行为添加到行为的执行者中。最后绘制出这样一个领域模型:
领域模型有别于后期的分析模型,其中最关键的就是目的,它的目的仅仅是分析需求,因此在很多地方会比较模糊而不考虑技术实现,比如本例中的“指标定义”、“过错标准”。另外一个比较关键的地方就是,系统中的行为到底由谁来执行,这个标准常常是说起来容易做起来难。我给大家的建议是参考GRASP中的“信息专家”模式。
GRASP是一种职责驱动设计的系统分析方法,它的“信息专家”模式是这样描述的:应当将系统中的行为交给信息专家去执行,而信息专家就是掌握着执行该行为所需数据的实体。在本例中,由于考核指标掌握着指标的定义,还有那些执法行为,所以它可以执行考核,而过错类型则掌握着过错标准,因此可以执行过错的判断。注意,这里的“执行”什么行为,是软件意义上的概念,即一个类可以拥有什么行为,而非现实世界的概念。要知道现实世界中的事物是不可能有主动执行什么操作的能力的。
过去我们拿到需求不知道该怎样去业务领域分析。有了原文分析方法,给了我们一个简单可行、易于操作的方法,让我们准确而高效地完成业务领域分析。