2.2_结构化分析及工具new.ppt

* * * * * * * * * * * * * * * * * * * * * * * * * * * * 结构化语言书写加工规约注意事项 语句力求精炼 语句必须易读、易理解、无二义 主要使用祈使句，祈使句中的动词要明确表达要执行的动作 所有名字必须是数据字典中有定义的名字 不使用形容词、副词等修饰语 不使用含义相同的动词，如“修改”、“修正”等 可以使用常用的算术和关系运算符 总之要尽可能精确、无二义、简明扼要、易理解 判定表 判定表的组成元素 条件框：列出各种条件的对象，如发货单金额，赊欠天数等，每行写一个条件对象 条件条目：列出各条件对象的取值，条件条目的每一列表示了一个可能的条件组合 动作框：列出所有可能采取的动作，如发出发货单等，每行写一个动作 动作条目：列出各种条件组合下应采取的动作 条件框 条件条目 动作框 动作条目 构造判定表的步骤 提取问题中的条件 标出条件的取值 计算所有条件的组合数N 提取可能采取的动作和措施 制作判定表 完善判定表 发货单金额 ＞500 ≤500 － 赊欠天数 ＞60 ＞60 ≤60 发不批准通知 √ 发出批准书 √ √ 发出发货单 √ √ 发出赊欠报告 √ “审批发货单”加工的简化判定表 “审批发货单”加工的判定表 发货单金额 ＞500 ＞500 ≤500 ≤500 赊欠天数 ＞60 ≤60 ＞60 ≤60 发不批准通知 √ 发出批准书 √ √ √ 发出发货单 √ √ √ 发出赊欠报告 √ 判定表的其它形式 发货单金额≤500 0 0 1 1 发货单金额＞500 1 1 0 0 赊欠天数≤60 0 1 0 1 赊欠天数＞60 1 0 1 0 发不批准通知 √ 发出批准单 √ √ √ 发出发货单 √ √ √ 发出赊欠报告 √ “审批发货单”加工的另一种判定表 判定树 本质上与判定表是相同的，只是表示形式不同 例如“审批发货单”加工逻辑的判定树描述入下： 2.5 软件开发计划 项目可行?制定项目开发计划 软件开发计划是软件工程中的一种管理性文档 针对开发项目的费用、时间、进度、人员组织、硬件设备配置、软件开发环境和运行环境配置等进行说明和规划 是项目管理人员对项目的费用、进度和资源进行控制和管理的依据 软件开发计划一般包括： 项目概述 项目的主要工作；软件的功能、性能；完成项目应具备的条件；用户及合同承包者承担的工作、完成期限及其他条件限制；应交付的程序名称；所使用的语言及存储形式；应交付的文档。 实施计划 任务的划分；明确任务责任人；开发进度（各阶段应完成的任务及时间）；项目预算（各阶段的费用支出预算） 人员组织及分工 说明开发该项目所需人员的类型、组成结构和数量 交付期限 说明项目最后完工交付的日期 思考题 1. 为什么要进行可行性研究？应该从哪些方面研究目标系统的可行性？ 2. 可行性研究有哪些步骤？成本-效益分析可用哪些方法进行度量？ 3. 如何导出新系统的高层逻辑模型？ 4. 项目开发计划有那些内容？ * * * * * * * * * * * * * * * * * * * * * * “试题得分清单”文件是加工2的局部文件，根据抽象原则不应该将这类表示加工细节的局部文件画在其父图(如图c)中，正确的画法是图a和b 2 1 (a) 父图 考生名册 (b) 子图 2.5 2.4 2.3 2.2 2.1 试题得分清单 考生名册 (c) 含局部文件的父图 2 1 试题得分清单 考生名册 加工的输出数据流不能与该加工的输入数据流同名 同一个加工的输出数据流和输入数据流即使组成成份相同，仍应对它们取不同的名字，以表示它们是不同数据流 例如，“报名单”和“合格报名单” 允许一个加工有二个相同的数据流分别流向二个不同的加工 分层数据流图的完整性 每个加工至少有一个输入数据流和一个输出数据流 在整套分层数据流中，每个文件应至少有一个加工读该文件，有另一个加工写该文件 分层数据流图中的每个数据流和文件都必须命名(除了流入或流出文件的数据流)，并保持与数据字典的一致 分层DFD中的每个基本加工(即不再分解子图的加工)都应有一个加工规约 其它需注意的问题-2 避免一个加工有过多的数据流 当一个加工存在许多数据流时往往意味着分解不合理 解决办法：重新分解 1)把需要重新分解的某张图(含有该复杂加工的图)的所有子图连接成一张图 2)把连接后的图重新划分成几个部分，使各部分之间的联系最小 3)重新定义父图，即第2)步中的每个部分作为父图中的一个加工 4)重新建立各子图，即第2)步中的每个部分都是一张子图 5)为所有的加工重新命名和编号 ( b ) 原加工2子图 2．2 2.1 2.3 2.4 2.5 H J I C K