数据库设计数据流图补充.pptVIP

数据流图 补充 1. 数据流图 系统分析阶段： 使用数据流图DFD来建立系统需求的过程模型。（结构化系统分析的方法） 系统分析采用ER图来建立系统的数据模型。 结构化分析的思想 数据流图DFD采用一系列分层次的数据流图来描述系统。 DFD的每一个层次都代表了系统的一个抽象水平。高层次DFD中的处理可以进一步分解成低层次、更详细的DFD。 分层的数据流图 纵观 1.1 数据流图的基本成分 数据流图用来记录系统中的数据和数据在特定的过程中的流动，即数据如何被采集、处理、保存和使用的（围绕信息系统的功能） 事件和DFD 事件列表中的每一个事件都可以画出一个DFD图（需要额外添加数据存储元素） 事件列表可以作为画数据流图的一个基础和检验列表 事件对应DFD模型的中间层 事件可以继续分解绘制其具体的处理过程（向下细化） 系统中事件较多时，应进行分组（向上抽象） 完整的数据流图 根据事件表重新组织，绘制完整的DFD模型： 按照事件表，对每一个事件建立一个DFD片段图。 把所有的DFD片段进行分组，归纳为大的处理逻辑，形成上一层DFD（复杂系统层次更多）。 将属于一组内的DFD片段放在一张图上，形成事件层的DFD图。 对每个事件的数据处理进一步分解为下一层DFD （复杂系统层次更多）。 完整的数据流图 真正进行结构化系统建模过程中，应该采用自顶向下的分解方法，事件表只是寻找需求的辅助工具（启发） 建模是一个从具体到抽象，又从抽象到具体的过程，需要反复多次 1.2 数据流图的画法 下面我们以高等学校学籍管理系统为例说明画数据流图的方法 如果不能直接建模，可以考虑以下事件： 新生登记 登记期末成绩 期末成绩分析 登记补考成绩 补考后成绩分析 评定奖学金 处理退学、留级、修学、复学 发成绩单…… 顶层 1.3 画数据流图的注意事项 要注意以下几点： 关于层次的划分 语法的正确性 可读性 确定系统边界 1.4 数据流图的常见错误分析 一般有三类错误情况： 语法错误（可采用软件工具辅助绘图消除） 逻辑错误 词不达意，二义性 错误情况举例1 错误情况举例2 错误情况举例3 错误情况举例4 错误情况举例5 错误情况举例6 错误情况举例7 1.5 绘图工具软件Visio介绍 Microsoft Visio可用于绘制计算机系统中需要的各种模型图 绘制DFD： DFD的四种元素 数据流两端元素的关联性 语法检查 上下层分解关系，子图自动继承父图有关的数据流 以树状目录列出全部处理 没有标准答案 数据流图的分解每个人可能有所不同，画出的数据流图也会因人而异，并一定谁画的对，谁画的错。 数据流图的优缺点 图形元素少，易学易读，容易与用户沟通 有层次性，允许系统分析员由上至下逐步分析系统，不会受困于太多复杂的细节 不能描述系统的控制流 潜在的非语法错误不易发现，复核困难，需要有一定的分析设计经验 2.系统说明书 系统说明书是系统分析阶段的成果 该文档描述了系统的需求，也称《需求规格说明书》 系统说明书参考模板 1. 引言 （1）摘要：名称、目标和功能 （2）背景：承担者、用户、与其他 系统和机构的关系 （3）参考和引用资料 （4）专门术语定义 2. 项目概述 （1）项目的主要工作内容 （2）系统功能说明（功能模型） （3）系统数据说明（数据模型） （4）系统其他需求说明 （性能/安全/故障处理/环境等） 系统说明书的品质要求 正确性 相对于用户的需求而言 待开发的系统与用户的期望相吻合 完整性 包含了软件要做的全部事情 指明系统对有效和无效输入的反应 所有条目都有标识（页、图、表、参考资料） 不要遗留任何有待解决的问题，无法避免时应进行标明，并注明谁和什么时候去解决 系统说明书的品质要求（续） 一致性 各个需求的描述不相矛盾 冲突术语、冲突特性、定时关系 无二义性 对每一项需求有且只有一种解释 可修改性 书写结构和风格易于后续的修改 可跟踪性 需求与来源、设计、源代码和测试用例可以对应 可验证性 可以运用一些可行的手段进行验证和确认 学生 成绩单 客户 订单 订单 源数据是如何进入到信息系统中的呢？ 外部实体如何从系统中获取有关的数据呢？ 难道是心灵感应？ 不论是手工系统还是计算机系统，数据不会无缘无故保存或流动，和外部的交换一定和某个加工相连。 客户 业务员 订单 外部实体到外部实体，全都是外部的。 和信息系统有关系吗？为什么要管呢？带来数据的变化了吗？ DFD考虑数据是从那个地方开始进入系统。 读者 图书 管理员 借书单 订单 入库单 数据不通过任何手续就能在数据存储之间流动？ 怪了，表格中的数据长腿了吗？要不硬盘智能化了，不需要任何外部力量，磁道上的数据会自己移动？ 读者信息 逾期历史 xx xx 仅有流入的数据流， 数据还有