2.3_数据字典+软件开发计划.pptVIP

* * * * * 数据源条目的描述内容 名称：数据源的名(外部实体名) 别名：同数据流条目 简要描述：对数据源的简要描述(包括指明该外部实体在DFD中是用作“源”，还是“宿”，还是“既是源又是宿”) 输入数据流：描述源向系统提供哪些输入数据流 输出数据流：描述系统向宿提供哪些输出数据流 注解：对数据源的其它补充说明 数据字典的实现 提倡采用专用的软件工具或者常用的实用程序(如正文编辑程序、电子表格)来建立数据字典的电子文档，其好处是便于字典条目的检索，字典的管理和维护 如果数据字典由辅助绘制DFD的工具自动产生的话，那么可以利用数据字典来检查DFD的一致性和完整性，并保持数据字典与DFD的一致 如果数据字典是由人工制作的，可以为每个字典条目制作一张卡片，所有卡片按字典条目的种类(数据流、文件、加工等)分类成册，每类卡片按某种约定排序 例子：编写学籍管理的DD 例子：编写学籍管理的DD 2.4 加工逻辑描述 加工逻辑描述是基本加工的规约说明，应精确地描述用户要求一个加工“做什么” 包括加工的激发条件、加工逻辑、优先级、执行频率、出错处理等 最基本的部分是加工逻辑，即该加工的输出数据流与输入数据流之间的逻辑关系 加工逻辑不是对加工的设计，不涉及数据结构、算法实现、编程语言等与设计和实现有关的细节 加工逻辑的描述方法 结构化语言：介于自然语言和形式语言之间的一种半形式语言 判定表：适用于加工逻辑包含多个条件，而不同的条件组合需做不同的动作 判定树：判定表的变种，它本质上与判定表是相同的，只是表示形式不同 结构化语言 没有严格的语法 加工规约分为若干个段落，每个段落可分为内外两层： 外层有严格的语法来描述它的控制结构 如结构化英语中可使用if_then_else、while_do、repeat_until、for_do、case等结构 内层可以用自然语言来描述 允许使用嵌套结构 “计算信用度”的结构化英语描述 Case 1 (No Bounced－Checks in Customer Record)： Write Exemplary－Customer―Citation to Annual―Summary. Case 2 (One Bounced－check)： If Yearly―Average―Balance exceeds $ 1000. Remove Bounced―Check from Customer―Record. Otherwise. Recuce Credit―Limit by 10%. Case 3 (Multiple Bounced－Checks)： For each Bounced―Check. Recuce Credit―Limit by 15%. Set Credit―Rating to Deadbeat. Write Scathing―Comment to Annual―Summary. Write Customer―Name―and―Address to IRS―Enemies―List. 结构化语言书写加工规约注意事项 语句力求精炼 语句必须易读、易理解、无二义 主要使用祈使句，祈使句中的动词要明确表达要执行的动作 所有名字必须是数据字典中有定义的名字 不使用形容词、副词等修饰语 不使用含义相同的动词，如“修改”、“修正”等 可以使用常用的算术和关系运算符 总之要尽可能精确、无二义、简明扼要、易理解 判定表 判定表的组成元素 条件框：列出各种条件的对象，如发货单金额，赊欠天数等，每行写一个条件对象 条件条目：列出各条件对象的取值，条件条目的每一列表示了一个可能的条件组合 动作框：列出所有可能采取的动作，如发出发货单等，每行写一个动作 动作条目：列出各种条件组合下应采取的动作 条件框 条件条目 动作框 动作条目 构造判定表的步骤 提取问题中的条件 标出条件的取值 计算所有条件的组合数N 提取可能采取的动作和措施 制作判定表 完善判定表 发货单金额 ＞500 ≤500 － 赊欠天数 ＞60 ＞60 ≤60 发不批准通知 √ 发出批准书 √ √ 发出发货单 √ √ 发出赊欠报告 √ “审批发货单”加工的简化判定表 “审批发货单”加工的判定表 发货单金额 ＞500 ＞500 ≤500 ≤500 赊欠天数 ＞60 ≤60 ＞60 ≤60 发不批准通知 √ 发出批准书 √ √ √ 发出发货单 √ √ √ 发出赊欠报告 √ 判定表的其它形式 发货单金额≤500 0