第3章结构化建模——2讲述.ppt

3.7 加工规格说明 决策表举例 商店业务处理系统中“检查订货单” 的决策表。 条件茬 条件项 动作茬 动作项 3.7 加工规格说明 决策表的改进 如果表中有两条或更多的处理规则具有相同的动作，并且其条件项之间存在着某种关系，就可设法将它们合并。 3.7 加工规格说明 建立决策表的步骤 (1) 列出与一个具体过程（或模块）有关的所有处理。 (2) 列出过程执行期间的所有条件（或所有判断）。 (3) 将特定条件取值组合与特定的处理相匹配，消去不可能发生的条件取值组合。 (4) 将右部每一纵列规定为一个处理规则，即对于某一条件取值组合将有什么动作。 3.7 加工规格说明 决策树 决策树（decision tree）也是用来表达加工逻辑的一种工具，有时侯它比决策表更直观。 检查订货单的决策树 3.8 需求规格说明 需求分析阶段的重要任务之一是根据分析的结果编写需求规格说明，经过严格评审并得到用户确认之后，作为这个阶段的最终成果。 按照国家标准GB/T 8567—2006《计算机软件文档编制规范》，涉及需求规格说明的文档有“软件需求规格说明（SRS）”、“数据需求说明（DRD）”等。 小结 传统软件工程方法学使用结构化分析技术完成用户需求的分析工作。需求分析是发现、求精、建模、规格说明和复审的过程。 为了更好地理解问题，人们常常采用建立模型的方法，结构化分析实质上就是一种建模活动， 在需求分析阶段通常建立数据模型、功能模型和行为模型。 * 软件需求分析是软件生存期中重要的一步，也是决定性的一步。需求分析是软件定义时期的最后一个阶段，它的基本任务是准确地回答“系统必须做什么?”这个问题。 软件需求分析阶段的主要工作产品有“需求规格说明”和“初步的用户手册”。 * S系统被分解为3个子系统1、2、3。顶层下面的第1层数据流图为DFD/L1。第2层数据流图DFD/L2.1、DFD/L2.2及DFD/L2.3分别是子系统1、2和3的细化。对任何一层数据流图来说，我们称它的上层图为父图，在它下一层的图则称为子图。 在分层的数据流图中，各层数据流图之间应保持“平衡”关系。例如，在图3-9中，DFD/L1的子系统3有两个输入数据流和一个输出数据流，那么它的子图DFD/L2.3也要有同样多的输入数据流和输出数据流，才能符合子图细化的实际情况。 * 对环境图中的银行储蓄系统进行分解，从大的方面分解为接收事务、处理存款、处理取款3部分，得到1层数据流图。 接收事务的主要功能是判断一个事务（输入数据流）的类型，其结果或者是存款业务，或者是取款业务。 存款信息需要使用外部文件或数据库的方式来存储 。 * * 表中所列出的定义方式类似于描述高级语言结构的巴科斯─瑙尔范式（Backus-Naur form，BNF），是一种严格的描述方式。 3.4 数据建模 属性 属性定义数据对象的特征，如数据对象学生的学号、姓名、性别、专业等，课程的课程编号、课程名称、学分等。 在ER图中用椭圆或圆角矩形表示属性，并用无向边将属性与相关的数据对象连接在一起。 3.4 数据建模 关系 不同数据对象的实例之间是有关联关系的，在ER图上用无向边表示。 在无向边的两端应标识出关联实例的数量，也称为关联的重数。 从关联重数的角度可以将关联分为３种。 (1) 一对一（1:1）关联 (2) 一对多（1:m）关联 (3) 多对多（m:n）关联 实例关联还有“必须”和“可选”之分。 3.4 数据建模 关联数量的表示 在ER图中用圆圈表示所关联的实例是可选的，隐含表示“0”，没有出现圆圈就意味着是必须的。出现在连线上的短竖线可以看成是“1”。 3.4 数据建模 关联关系举例 3.4 数据建模 关系的属性 关系本身也可能有属性，这在多对多的关系中尤其常见，如学生和课程之间的关系可起名为“选课”，其属性应该有学期、成绩等。 关系属性的表示：在表示关系的无向边上再加一个菱形框，并在菱形框中标明关系的名字，关系的属性同样用椭圆形或圆角矩形表示，并用无向边将关系与其属性连接起来。 3.4 数据建模 关系的属性 3.4 数据建模 银行储蓄系统的ER图 3.5 行为建模 3.5 行为建模 状态转换图（简称状态图）通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。状态图中使用的主要符号如图所示。 3.5 行为建模 状态 状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式，状态规定了系统对事件的响应方式。 状态可能有：初态（初始状态）、终态（最终状态）和中间态。 在一张状态图中只能有一个初态，而终态则可以有多个，也可以没有。 3.5 行为建模 状态的表示：初态用实心圆表示，终态用牛眼图形表示，中间态用圆角矩形表示。 3.5