数据规范化

软件系统经常使用各种长期保存的信息，这些信息通常以一定方式组织并存储在数据库或文件中，为减少数据冗余，避免出现插入异常或删除异常，简化修改数据的过程,通常需要把数据结构规范化。

通常用“范式(normal forms)”定义消除数据冗余的程度。第一范式(1 NF)数据冗余程度最大,第五范式(5 NF)数据冗余程度最小。但是，第一，范式级别越高,存储同样数据就需要分解成更多张表,因此，“存储自身"的过程也就越复杂。第二，随着范式级别的提高,数据的存储结构与基于问题域的结构间的匹配程度也随之下降,因此，在需求变化时数据的稳定性较差。第三，范式级别提高则需要访问的表增多，因此性能(速度)将下降。从实用角度看来,在大多数场合选用第三范式都比较恰当。

通常按照属性间的依赖情况区分规范化的程度。属性间依赖情况满足不同程度要求的为不同范式，满足最低要求的是第一范式,在第范式中再进一 步满足一些要求的为第一范式,其余依此类推。下面给出第一、第二和第三范式的定义。
(1)第一范式每个属性值都必须是原子值，即仅仅是一个简单值而不含内部结构。（不可再分）
(2)第二范式满足第一范式条件，而且 每个非关键字属性都由整个关键字决定(而不是由关键字的一部分来决定)。
(3)第三范式符合第二范式的条件，每个非关键字属性都仅由关键字决定，而且一个非关键字属性不能仅仅是对另一个非关键字属性的进一步描述(即一个非关键字属性值不依赖于另一个非关键字属性值)。

实体-联系图

为了把用户的数据要求清楚、准确地描述出来，系统分析员通常建立一个概念性的数据模型（也称为信息模型）。概念性数据模型是一种面向问题的数据模型，是按照用户的观点对数据建立的模型。它描述了从用户角度看到的数据，它反映了用户的现实环境，而且与在软件系统中的实现方法无关。

数据模型包括三种相互关联的信息：数据对象、数据对象的属性及数据对象之间的联系。

数据对象

数据对象是对软件必须理解的复合信息的抽象

所谓复合信息是指具有一系列不同性质或属性的事物，仅有单个值的事物（例如宽度）不是数据对象。

数据对象可以是外部实体（例如产生或使用信息的任何事物）、事物（例如报表）、行为（例如打电话）、事件（例如响警报）、角色（例如教师、学生）、单位（例如会计科）、地点（例如仓库）或结构（例如文件）等。

总之，可以由一组属性来定义的实体都可以被认为是数据对象

数据对象彼此之间是有关联的，例如，教师“教”课程，学生“学”课程，教或学的关系表示教师和课程或学生之间的一种特定的连接

数据对象只封装了数据而没有对施加于数据上的操作的引用，这是数据对象与面向对象的范型中的“类”或“对象”的显著区别。

属性

属性定义了数据对象的性质

必须把一个或多个属性定义为“标识符”，也就是说，当人们希望找到数据对象的一个实例时，用标识符属性作为“关键字”（通常称为键）

应该根据对所要解决的问题的理解，来确定特定数据对象的一组合适的属性。

例如，为了开发机动车管理 系统，描述汽车的属性应该是生产厂 、品牌、型号、发动机号码、车体类型、颜色、车主姓名、住址、驾驶证号码、生产日期及购买日期等。但是,为了开发设计汽车的CAD系统，用上述这些属性描述汽车就不合适了,其中车主姓名、住址驾驶证号码、生产日期和购买日期等属性应该删去，而描述汽车技术指标的大量属性应该添加进来。

联系

客观世界中的事物彼此间往往是有联系的。例如.教师与课程间存在“教”这种联系，而学生与课程间则存在“学"这种联系。

数据对象彼此之间相互连接的方式称为联系，也称为关系。联系可分为以下3种类型。

(1) 一对一联系(1 : 1)

例如，一个部门有一一个经理，而每个经理只在一个部门任职，则部门与经理的联系是一对一的。

(2)一对多联系(1 : N)

例如,某校教师与课程之间存在对多的联系“教”，即每位教师可以教多门课程，但是每门课程只能由一位教师来教。

(3)多对多联系(M: N)

例如，下图表示学生与课程间的联系(“学”)是多对多的，即一个学生可以学多门课程,而每门课程可以有多个学生来学。

联系也可能有属性。例如，学生“学”某门课程所取得的成绩，既不是学生的属性也不是课程的属性。由于“成绩"既依赖于某名特定的学生又依赖于某门特定的课程，所以它是学生与课程之间的联系“学”的属性(见图)。

实体-联系图的符号

通常,使用实体联系图(entity relationship diagram)来建立数据模型。可以把实体-联系图简称为ER图,相应地可把用ER图描绘的数据模型称为ER模型。

ER图中包含了实体(即数据对象)、关系和属性3种基本成分.通常用矩形框代表实体,用连接相关实体的菱形框表示关系,用椭圆形或圆角矩形表示实体(或关系)的属性，并用直线把实体(或关系)与其属性连接起来。例如，上图是某学校教学管理的ER图。

人们通常就是用实体、联系和属性这3个概念来理解现实问题的，因此，ER模型比较接近人的习惯思维方式。此外，ER模型使用简单的图形符号表达系统分析员对问题域的理解,不熟悉计算机技术的用户也能理解它,因此，ER模型可以作为用户与分析员之间有效的交流工具，

状态转换图

在需求分析过程中应该建立起软件系统的行为模型。状态转換图(简称为状态图)通过描绘系统的状态及引起系统状态转换的事件,来表示系统的行为。此外,状态图还指明了作为特定事件的结果系统将做哪些动作(例如处理数据)

状态

状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。状态规定了系统对事件的响应方式。系统对事件的响应,既可以是做一个(或一系列)动作 ，也可以是仅仅改变系统本身的状态,还可以是既改变状态又做动作。在状态图中定义的状态主要有:初态(即初始状态)、终态(即最终状态)和中间状态。在张状态图中只能有一个初态 ,而终态则可以有0至多个。状态图既可以表示系统循环运行过程，也可以表示系统单程生命期。当描绘循环运行过程时，通常并不关心循环是怎样启动的。当描绘单程生命期时，需要标明初始状态(系统启动时进人初始状态)和最终状态(系统运行结束时到达最终状态)。

事件

事件是在某个特定时刻发生的事情，它是对引起系统做动作或和)从一个状态转换到另一个状态的外界事件的抽象。例如,内部时钟表明某个规定的时间段已经过去用户移动或单击鼠标等都是事件。简而言之,事件就是引起系统做动作或(和)转换状态的控制信息。

符号

在状态图中，初态用实心圆表示，终态用一对同心圆(内圆为实心四)表示。部分为状态的名称。这部分是必须有的；中间部分为状态变量名字和值,这部分是可选的；下面部分是活动表,这部分也是可选的。

活动表的语法格式如下:

事件名(参数表)/动作表达式

其中，事件名”可以是任何事件的名称。在活动表中经常使用下述3种标准事件:entry,exit 和do. entry事件指定进人该状态的动作.exit 事件指定退出该状态的动作，而do事
件则指定在该状态下的动作。需要时可以为事件指定参数表。活动表中的动作表达式描述应做的具体动作。

状态图中两个状态之间带箭头的连线称为状态转换,箭头指明了转换方向。状态变迁通常是由事件触发的，在这种情况下应在表示状态转换的箭头线上标出触发转换的事件表达式:如果在箭头线上未标明事件.则表示在源状态的内部活动执行完之后自动触发转换。

事件表达式的语法如下:

事件说明[守卫条件]/动作表达式

其中，事件说明的语法为:事件名(参数表)。守卫条件是一个布尔表达式。如果同时使用事件说明和守卫条件，则当且仅当事件发生且布尔表达式为真时,状态转换才发生。如果只有守卫条件没有事件说明，则只要守卫条件为真状态转换就发生。

动作表达式是一个过程表达式，当状态转换开始时执行该发表达式。

下图给出了状态图中使用的主要符号。

例子：

为了具体说明怎样用状态图建立系统的行为模型，我们下面举个例子，是人们非常熟悉的电话系统的状态图

图中表面，没有人打电话时电话处于闲置状态；有人拿起电话进入拨号音状态；到达这个状态后，电话的行为是响起拨号音并计时；这时如果拿起电话的人改变主意不想打了，挂断，电话重又回到闲置状态；如果拿起听筒很长时间不拨号（超时）。则进入超时状态……

层次方框图

层次方框图用树形结构的.系列多层次的矩形框描绘数据的层次结构。树形结构的顶层是一个单独的矩形框，它代表完整的数据结构，下面的各层矩形框代表这个数据的子集，最底层的各个框代表组成这个数据的实际数据元素(不能再分割的元素)。

例如，描绘 家计算机公司全 部产品的数据结构,软件产品又分为系统软件和应用软这家公司的产品由硬件软件和服务3类产品组成，件，系统软件又进一步分为操作系统编译程序和软件工具等，

随着结构的精细化层次方框图对数据结构电描绘得越来越详细,这种模式非常适合于需求分析阶段的需要。系统分析员从对顶层信息的分类开始，沿图中每条路径反复细化，直到确定了数据结构的全部细节时为止。

Warnier 图

法国计算机科学家Warrier 提出了表示信息层次结构的另外一种图形工具一Warnier图。和层次方框图类似，Warnier图也用树形结构描绘信息，但是这种图形工具比层次方框图提供了更丰富的描绘手段。用Warnier图可以表明信息的逻辑组织，也就是说，它可以指出一类信息或一个信息元素是重复出现的，也可以表示特定信息在某一类信息中是有条件地出现的。因为重复和条件约束是说明软件处理过程的基础，所以很容易把Warnier 图转变成软件设计的工具。

上图用Warnier图描绘一类软件产品的例子，它说明了这种图形工具的用法。

图中花括号用来区分数据结构的层次,在一个花括号内的所有名字都属于同一类信息:异或符号()表明一类信息或一个数据元素在一定条件下才出现，而且在这个符号上、下方的两个名字所代表的数据只能出现一一个:在 一个名字下面(或右边)的圆括号中的数字指

IPO图

IPO图是输人、处理、输出图的简称，它是由美国IBM公司发展完善起来的一种图形工具，能够方便地描绘输人数据、对数据的处理和输出数据之间的关系。

IPO图使用的基本符号既少又简单,因此很容易学会使用这种图形工具。它的基本形式是在左边的枢中列出有关的输人数据，在中间的框内列出主要的处理,在右边的框内列出产生的输出数据。处理框中列出处理的次序暗示了执行的顺序，但是用这些基本符号还不足以精确描述执行处理的详细情况。在IPO图中还用类似向量符号的粗大箭头清楚地指出数据通信的情况。

验证软件需求

从哪些方面验证软件需求的正确性

需求分析阶段的工作结果是开发软件系统的重要基础.大量统计数字表明，软件系统中15%的错误起源于错误的需求。为了提高软件质量，确保软件开发成功.降低软件开发成本，一且对目标系统提出一组要求之后，必须严格验证这些需求的正确性。一般说来，应该从下述4个方面进行验证.

(1)一致性 所有需求必须是一致的，任何一条需求不能和其他需求互相矛盾。

(2)完整性需求必须是完整的，规格说明书应该包括用户需要的每一个功能或性能。

(3)现实性指定的需求应该是用现有的硬件技术和软件技术基本上可以实现的。对硬件技术的进步可以做些预测，对软件技术的进步则根难做出预测，只能从现有技术水平出发判断需求的现实性。

(4)有效性必须证明需求是正确有效的，确实能解决用户面对的间题。

验证软件需求的方法

必须从一致性完整性、现实性和有效性这4个不同角度验证软件需求的正确性。那么.怎样验证软件需求的正确性呢?验证的角度不同，验证的方法也不同。

1.验证需求的一致性

当需求分析的结果是用自然语言书写的时候，除了靠人工技术审查验证软件系统规格说明书的正确性之外，目前还没有其他更好的“测试“方法。但是，这种非形式化的规格说明书是难于验证的，特别在目标系统规模庞大、规格说明书篇幅很长的时候，人工审查的效果是没有保证的,冗余、遗漏和不一致等问题可能没被发现而继续保留下来，以致软件开发工作不能在正确的基础上顺利进行。为了克服上述困难，人们提出了形式化的描述软件需求的方法。当软件需求规格说明书是用形式化的需求陈述语言书写的时候，可以用软件工具验证需求的致性，从面能有效地保证软件需求的致性 。

2.验证需求的现实性

为了验证需求的现实性，分析员应该参照以往开发类似系统的经验,分析用现有的软、硬件技术实现目标系统的可能性。必要的时候应该采用伤真成性能模拟技术.辅助分析软件需求规格说明书的现实性。

3.验证需求的完整性和有效性

只有目标系统的用户才真正知道软件需求规格说明书是否完整、准确地描述了他们的需求。因此检验需求的完整性，特别是证明系统确实满足用户的实际需要(即.需求的有效性)，只有在用户的密切合作下才能完成。然面许多用户并不能清楚地认识到他们的需要(特别在要开发的系统是全新的，以前没有使用类们系统的经验时，情况更是如此)，不能有效地比较陈述需求的语句和实际需要的功能。只有当他们有某种工作着的软件系统可以实际使用和评价时，才能完整碗切地提出他们的需要。理想的做法是先根据需求分析的结果开发出一个软件系统，请用户试用一段时间以便能认识到他们的实际需要是什么，在此基础上再写出正式的“正确的“规格说明书。但是。这种做法将使软件成本增加一信,因此实际上几乎不可能采用这种方法。使用原型系统是一个比较现实的替代方法.开发原型系统所需要的成本和时间可以大大少于开发实际系统所需要的。用户通过试用原型系统，也能获得许多宝贵的经验,从面可以提出更符合实际的要求。使用原型系统的目的，通常是显示目标系统的主要功能而不是性能。为了达到这个目的可以使用快速建立原型系统,并且可以适当降低对接口、可靠性和程序质量的要求，此外还可以省掉许多文档资料方面的工作，从而可以大大降低原型系统的开发成本。

用于需求分析的软件工具

为了更有效地保证软件需求的正确性.特别是为了保证需求的一致性,需要有适当的软件工具支持需求分析工作。这类软件工具应该满足下列要求。

(1)必须有形式化的语法(或表),因此可以用计算机自动处理使用这种语法说明的内容。

(2)使用这个软件工具能够导出详细的文档。

(3)必须提供分析(测试)规格说明书的不一致性和冗余性的手段.并且应该能够产生组报告 指明对完整性 分析的结果。

(4)使用这个软件工具之后，应该能够改进通信状况。作为需求工程方法学的一部分 ,RSL(需求陈述语言)于1977 年设计完成。RSL 中的语句是计算机可以处理的，处理以后把从这些语句中得到的信总集中存放在个称为 ASSM(抽象系统语义模型)的数据库中。有一组软件工具处理ASSM数据库中的信息以产生出用PASCAL语言书写的模拟程序，从而可以检验需求的一致性 完整性和现实性。

1977年美国密执安大学开发了PSL/PSA(问题陈述语言/问题陈述分析程序)系统。这个系统是CADSAT(计算机辅助设计和规格说明分析工具)的一部分,它的基本结构类PSA是处理，PSL描述的分析程序。
似于RSIL.其中PSL是用来描述系统的形式语言电立起数据库之后即可增加信息删除用PSL描述的系统属性放在一个数据库中， 一且信息或修改信息，并且保持信息的致性。PSA对数据库进行处理以产生各种报告,测试不一致性或遗漏,并且生成文档资料。

PSL/PSA系统的功能主要有下述4种。

(1)描述任何应用领域的信息系统。

(2)创建一个数据库保存对该信息系统的描述符。

(3)对描述符施加增加、删除和更改等操作。

(4)产生格式化的文档和关于规格说明书的各种分析报告。

PSL/PSA系统用描述符从系统信息流系统结构、数据结构数据导出、系统规模、系统动态、系统性质和项目管理共8个方面描述信息系统。

一旦用 PSL对系统做了完整描述，就可以调用PSA产生-组分析报告,其中包括所有修改规格说明数据库的记录,用各种形式描述数据库信息的参照报告包括图形形式的描述)，关于项目管理信息的总结报告,以及评价数据库特性的分析报告。

借助PSL/PSA系统可以边对目标系统进行自顶向下的逐层分解，边将需求分析过程中遇到的数据流、文件、处理等对象用PSL描述出来并输人到PSL/PSA系统中。PSA将对输人信息作一致性 和完整性检查,并且保存这些描述信息。

PSL/PSA系统的主要优点是它改进了文档质量，能保证文档具有完整性、致性和无二义性，从而可以减少管理和维护的费用。数据存放在数据库中，便于增加、删除和更改,这也是它的一个优点。