顶层数据流图案例实例
数据流图案例
病员极限
生理信号
病员
病员数据
极限值
3
报警 护士
病症报告
中央监视
格式化 病员数据
2
生成报告 日志数据 护士 要求报告 日志数据
4
更新日志
病员日志
医院病房监护系统二层DFD图
第二层：加工“中央监视”分解
3.1 开解信号
病员数据
病员极限
脉搏 生理信号 极限值
血压
体温
3.2
超过极限值
计算超过 极限值否
血压、体温 脉搏 3.4 日期
2.3.2 快速原型开发模型
细化的原型化模型
快速分析，确定初步规格说明 构造原型
运行/评价原型
修 正 改 进 原 型 N 原型完成否 Y 要细部说明否 Y 严格说明细部 N 效果满意否 Y 整理原型提供文档 N
快速建立系统原型进行系统的 分析和构造有如下优点：
1、增进软件开发人员和用户 对系统需求的理解。便于将用户 模糊的功能需求明确化。 2 、为用户提供了一种强有力 的学习手段。
一、 结构化语言
结构化语言是介于自然语言和形式语言之间的一种半形 式语言，它是自然语言的一个受限制的子集。一般分为两层 结构：外层语法较具体，为控制结构（顺序、选择、循环）, 内层较灵活，表达“做什么”。
例如：外层可为以下结构：
1、顺序结构 2、选择结构 IF–THEN-ELSE; CASE-OF-ENDCASE； 3、循环结构 WHILE-DO; REPEAT-UNTIL
超过极限值 日期 时钟 时间 3.4
2 护士 生成报告 日志数据
3.3 产生 报警信息
病员日志
报警
格式化 病员数据
格式化 病员数据
需求分析例题-考务处理系统的分层数据流图如图所示
例：考务处理系统的分层数据流图如图所示。
该考务处理系统有如下功能：1.对考生送来的报名表进行检查。
2.对合格的报名表编好准考证号码后将准考证送给考生，并将汇总后的考生名单送给阅卷站。
3.对阅卷站送来的成绩表进行检查，并根据考试中心指定的合格标准审定合格者。
4.填写考生通知单（内容包含考试成绩和合格/不合格标志），送给考生。
5.按地区、年龄、文化程度、职业、考试级别等进行成绩分类统计和试题难度分析，产生统计分析表。
P73，习题33.银行计算机储蓄系统的工作过程大致如下：储户填写的存款单或取款单由业务员输入系统，如果是存款则系统记录存款人姓名、住址（或电话号码）、身份证号码、存款类型、存款日期、到期日期、利率及密码（可选）等信息，并印出存单给储户；如果是取款而且存款时留有密码，则系统首先核对储户密码，若密码正确或存款时未留密码，则系统计算利息并印出利息清单给储户。
用数据流图描绘本系统的功能，并用实体-联系图描绘系统中的数据对象。
4.目前住院病人主要由护士护理，这样做不仅需要大量护士，而且由于不能随时观察危重病人的病情变化，还可能会延误抢救时机。
某医院打算开发一个以计算机为中心的患者监护系统，试写出问题定义，并且分析开发这个系统的可行性。
医院对患者监护系统的基本要求是随时接收每个病人的生理信号（脉搏、体温、血压、心电图等），定时记录病人情况以形成患者日志，当某个病人的生理信号超出医生规定的安全范围时向值班护士发出警告信息。
此外，护士在需要时还可以要求系统印出某个指定病人的病情报告。
试用实体-联系图描绘本系统中的数据对象并用数据流图描绘本系统的功能。
6.复印机的工作过程大致如下：未接到复印命令时处于闲置状态，一旦接到复印命令则进入复印状态，完成一个复印命令规定的工作后又回到闲置状态，等待下一个复印命令；如果执行复印命令时发现没纸，则进入缺纸状态，发出警告，等待装纸，装满纸后进入闲置状态，准备接收复印命令；如果复印时发生卡纸故障，则进入卡纸状态，发出警告，等待维修人员来排除故障，故障排除后回到闲置状态。
数据流图案例
IF–THEN-ELSE; CASE-OF-ENDCASE； 3、循环结构
WHILE-DO; REPEAT-UNTIL
2.3.2 快速原型开发模型
快速分析，确定初步规格说明 构造原型
பைடு நூலகம்
修N 正 改 进 原 型
N
运行/评价原型
原型完成否 Y
N 要细部说明否 Y 严格说明细部
DFD图不是流程图,不表示软件的控制流程。
2.2.6 分层DFD图的改进
DFD图必须经过反复修改，才能获得最终的目标系统的 逻辑模型（目标系统的DFD图）。可从以下方面考虑DFD图 的改进： 1、检查数据流的正确性
① 数据守恒 ② 子图、父图的平衡 ③ 文件使用是否合理。特别注意输入/出文件的数据流。 2、改进DFD图的易理解性
● 为软件设计者提供可用于转换为数据设计、体系结构 设计、界面设计和过程设计的模型；
● 提供开发人员和客户需求规格说明，用于作为评估软 件质量的依据。
需求工程小结
需求工程是系统工程和软件工程的一个交叉分支，涉及到 软件系统的目标、软件系统提供的服务、软件系统的约束和软 件系统运行的环境。它还涉及这些因素和系统的精确规格说明 以及系统进化之间的关系。它也提供现实需要和软件能力之间 的桥梁。
数据流图案例1
2.2.3 画分层DFD图的方法
“先全局后局部,先整体后细节,先抽象后具体” 通常可将这种分层的DFD图,分为顶层、中间层、底层。 具体步骤： 1。先确定系统范围，画出顶层的DFD图。 2。逐层分解顶层DFD图，获得若干中间层DFD图。 3。画出底层的DFD图。
顶层图说明了系统的边界,即系统的输入和输出数据流 ，顶层图只有一张。底层图由一些不能再分解的加工组 成，这些加工都已足够简单，称为基本加工。在顶层和 底层之间的是中间层。中间层的数据流图描述了某个加 工的分解，而它的组成部分又要进一步分解。
数据流图与数据字典的实例
系统的数据流图与数据字典实例作为示例，为简单起见,我们只考虑人机分工.此处的数据流图是计算机化的帐务处理系统中涉及到计算机部分的数据流图,人工完成的部分将不做反应。
例如：计算机没有能力审核原始凭证、填制记账凭证，这些工作必须由人来完成,因此进入系统（系统的自动化部分）的应该是记账凭证而不是原始凭证。
银行对帐单仍然是系统的输入数据流，原有的输出数据流系统也必须提供.图1 系统的顶层数据流图图2 系统的第一层分解图记账凭证进入计算机系统需要进行输入操作，而且由于记账凭证本身可能出错，或输入过程中可能发生错误，因此系统必须提供对已输入的记账凭证的修改功能和审核功能，审核通过的记账凭证才能够记账.据此，对“凭证处理"分解得到第二层分解图,该分解图由凭证输入、凭证修改和凭证审核三个处理构成.如果记账凭证是由操作人员直接根据原始凭证用计算机填制，则凭证处理还应该包含一个打印记账凭证的处理。
图3 系统第二层分解图之一（图1) 在系统中，登帐处理由计算机完成，其分解的流程图与原来一致。
图4 系统第二层分解图之二（图2）图5系统第二层分解图之三（图3）图6 系统第二层分解图之四（图4）8。
1。
3 数据字典数据字典的作用是对数据流图中的各种成分进行详细说明，作为数据流图的细节补充，和数据流图一起构成完整的系统需求模型.数据字典一般应包括对数据项,数据结构、数据存储和数据处理的说明.以下列出本系统的主要数据字典条目.1. 数据项条目数据项编号：D01-001数据项名称：凭证编号别名:凭证流水号符号名：PZBH数据类型:数值型长度：4取值范围：1~9999其余略。
2. 数据结构条目数据结构编号:DS01—003数据结构名称：会计分录别名:分录简述:记帐凭证的基本组成成分组成:科目代码+借贷方向+金额其余略。
3。
数据存储条目数据存储编号：F01数据存储名称：记账凭证来源:由凭证处理产生组成：凭证日期+凭证类别+凭证编号+附件张数+{会计分录｝+制证+主管+审核数据存储编号：F02数据存储名称：现金日记账来源：由登记现金日记账产生组成：凭证日期+凭证类别+凭证编号+摘要+借方金额+贷方金额+余额方向+余额数据存储编号：F03数据存储名称：银行日记账来源：由登记银行日记账产生组成：凭证日期+凭证类别+凭证编号+摘要+借方金额+贷方金额+余额方向+余额数据存储编号：F04数据存储名称：明细账来源:由登记明细账产生组成：科目代码+凭证日期+凭证类别+凭证编号+摘要+借方金额+贷方金额+余额方向+余额数据存储编号：F05数据存储名称：总账来源：由登记总账产生组成：{科目代码+年份+月份+期初余额方向+期初余额+本期借方发生额+ 本期贷方发生额+本期余额方向+本期余额｝其余略.4。
顶层数据流图
顶层数据流图系统操作 数据统计结果信息一层数据流图员工表 账目明细表存款记录 取款记录客户信息表 反馈 查询姓名 银行账号用户资料表 打印输出管理系统数据库用户系统储蓄员员工登录柜台系统外部系统转账转入接口报表系统管理系统 管理人员 用户二层数据流图相关信息丢弃否是身份证密码 否三层数据流图存款 存款信息填表 出错 存款 信息 存款单存款单 （存折） 设置密码 存款信息 不需要密码密码存单 存款信息用户 开户修改密码取款存款转账查询记录操作结果登折并签字询问是否继续身份验证分类销户用户储户验收存款单重填更新存款信息 设置密码 密处理存款储户打印存单错误 错误取款单密码输入密码 正确取款单利息信息取款清单 取款信息 余额信息 现金 取款信息 余额信息转账转账单错误错误本次需要转账金额 输入密码转出金额大于 结余金额则丢弃转款清单 余额信息转款信息输入转账信息储户验收取款单验证密码 密码计算利息更新余额 处理余额 打印清单 储户 储户 验收转账单 验证密码金额比较转账显示余额 打印清单储户 重填 重输重填重输重输 信息种类错误 输入密码账户信息信息清单E-R 图储户验证密码查询所需信息显示信息打印清单储户管理员姓名性别 年龄密码代码上岗时间储户姓名性别账号密码家庭住址身份证号银行地址银行名称联系方式联系方式管理办理存取款。
数据流图
E1 储户
F1存款单 F2取款单
P0储蓄系统
F3存单 F4利息清单
E1 储户
F5存款信息 F5存款信息
D1存款信息
E1 储户
F1存款单 F7密码
P1 记录存款信息
P2 打印存单 F5存款信息 F3存单 E1 储户 F4利息
F5存款信息 D1存款信息 F7密码 F2取款单
F5存款信息 P3 核算密码
分类 统计表
考生名册
数据流图分解原则
DFD可以用来表示一个系统或软件在任何层次上 的抽象。 较大型软件系统DFD分成多层(子图、 父图概念),可以表示数据流和功能的进一步的细 节。 0层数据流图应当把系统或软件作为一个单一的 功能来描述。 应当注意原始的输入和输出。 每个过程的每次细化一般控制在3－4个分过程。 所有圆圈和箭头应用有意义的名称标注。一个名 称标注在 同一个DFD中只能出现一次。 每次细化时，细化部分的输入和输出必须保持一 致，即保持信息流连续性，有时称为平衡。 一次最好只对一个圆圈细化。
顶层数据流图
不合格报名单 报名单 准考证
考 生
考务 处理系统
考 生 名 单
考 试 中 心
成 绩 清 单
阅卷站
0层数据流图
不合格 报名单
1
登记 报名单
考 生 名 单
2
统计 成绩
统计分析表
错 误 成 成 合 绩 绩 格 清 清 标 单 单
准
考生名册
1层数据流图 (a)
报名单 不合格 1.1 报名单 检查 报名单
4从房
[问题2] 房主文件 和 学生文件 [问题3] 姓名+现住址+电话号码+出生日期+性别
顶层数据流图案例实例
网上作业提交与管理系统的顶层数据流图其中：数据流A：账号和密码数据流B：作业申请数据流C1：需要完成的作业数据流C2：完成的作业数据流D：作业成绩存储E：作业成绩统计文件决策表行李重量W＞30W≤30是否国内乘客头等舱其他舱国内国外免费是否头等舱(W－30)×4(W－30)×6头等舱其他舱是否头等舱(W－30)×8(W－30)×12需求分析文档超市进货管理系统的开发主要涉及到商品信息的管理、供应商信息的管理、订单信息的管理、库存信息的管理、商品分类信息的管理五大功能的数据管理。
商品信息管理包括添加商品、删除商品、修改商品信息、浏览商品信息。
供应商信息管理包括添加供应商、删除供应商、修改供应商信息、浏览供应商信息、浏览供应商与商品间关系。
订单信息管理包括添加订单、删除订单、修改订单信息、浏览订单信息。
库存信息管理包括添加商品库存、删除商品库存、修改商品库存信息、浏览商品库存信息。
商品分类信息管理包括添加商品分类信息、删除商品分类信息、修改商品分类信息、浏览商品分类信息。
一、功能需求(1) 商品管理---对所有商品信息进行管理。
(2) 供应商管理---对购物车和订单信息的维护。
(3) 订单管理---对订单和订单中书籍打印信息的更新与管理。
(4) 库存管理---对后台用户进行管理添加、删除以及修改信息。
(5) 商品分类管理---对数据库进行备份和恢复。
二、性能需求(1) 系统中的软件不构成对人身健康的损害。
(2) 系统中的软件失效时不造成财产的损失。
(3) 系统中的软件失效时不造成环境的破坏。
(4) 系统中的软件可以每天使24小时，每年使用365天。
(5) 系统中的软件故障率小于等于5%。
(6) 用户输入错误信息时系统应提示不应崩溃。
数据流图示例
1、成绩管理模块（见图5）
F2学生各科成绩F7.1成绩通知单
F5.1.1查询条件
F5.1.2查询结果
F3学生成绩统计
图3成绩管理数据流图
2、学籍管理模块（图6）
F1.2新生名册
F5.2..2查询结果
F5.2.2查询条件
F4学生日常管理资料
F6学生基本情况表
F7.2学籍管理
通知单
F5.2.3学生名单
图4学籍管理数据流图
数据流图示例：
一、关联图（见图3）
F2学生各科成绩
F3学生成绩统计
F4日常管理资料
图1系统关联图
二、顶层图（见图4）
F7.1成绩通知单
F2学生各科成绩
F1.1新生名册
F3学生成绩统计
F5.1学生成绩信息
F1.2新生名册
F4学生ቤተ መጻሕፍቲ ባይዱ常管理资料
F6学生基本情况表F5.2学生学籍信息
F7.2学籍管理通知单
图2系统顶层数据流图
数据流图(DFD)作用描述逻辑模型的图形工具,表示数
需求分析的步骤 需求分析模型 数据建模 功能建模和信息流 行为建模
功能建模和信息流 使用工具: 数据流图 ( Data Flow Diagram， DFD)
数据字典 ( Data Dictionary， DD ) 判定树 /判定表 结构化语言
数据流图(DFD）作用： 描述逻辑模型的图形工具，
C 3.1
子图
3.2
D
实例1:配送中心管理信息系统的顶层DFD
发票
订货单
送货单 配送中心 路单
供应商
管理信息
连锁 门店
货物清单 系
统 门店销
售信息
订单
配送中心管理信息系统的零层DFD
订货单
门店
D1 订货单表
1
送货单
商品编码
D3 订货单表
库存管 出库单、入库单 2
理
财务管
理
发票
供 应
D2 缺货单表
* 数据流： 加工 加工 数据流 数据流
源
加工
潭
* 流入、流出存储文件的数据流可无名称；加工名、文
件名表达要清楚、规范。
2）数据流与加工的关系： * 数据流（一个或多个） * 加工（一个或多个）
加工 数据流
DFD的层次分解
DFD可以用来表示一个系统或软件在任何层次上的抽象。 较大型软件系统DFD图可以分成多个层(父图、子图概念),可 以表示数据流和功能的进一步的细节。
缺书
无效
学 书单 1.1 有效 1.2
1.3 领书 学
生 生 审查 购书单 有效性
购书单 开发票 发票 登记并
开领书单
单
F3 各班学生用书表
F4 售书登记表
作业-数据流图(DFD)
1/3杭州电子科技大学计算机学院 软件与智能研究所阅读以下说明和图，回答问题1至问题5，将解答填入答题纸的对应栏内。
（20分） 【说明】某高校欲开发一个成绩管理系统，记录并管理所有选修课程的学生的平时成绩和考试成绩，其主要功能描述如下：1) 每门课程都有3到6个单元构成，每个单元结束后会进行一次测试，其成绩作为这门课程的平时成绩。
课程结束后进行期末考试，其成绩作为这门课程的考试成绩。
2) 学生的平时成绩和考试成绩均由每门课程的主讲教师上传给成绩管理系统。
3) 在记录学生成绩之前，系统需要验证这些成绩是否有效。
首先，根据学生信息文件来确认该学生是否选修这门课程，若没有，那么这些成绩是无效的；如果他的确选修了这门课程，再根据课程信息文件和课程单元信息文件来验证平时成绩是否与这门课程所包含的单元相对应，如果是，那么这些成绩是有效的，否则无效。
4) 对于有效成绩，系统将其保存在课程成绩文件中。
对于无效成绩，系统会单独将其保存在无效成绩文件中，并将详细情况提交给教务处。
在教务处没有给出具体处理意见之前，系统不会处理这些成绩。
5) 若一门课程的所有有效的平时成绩和考试成绩都已经被系统记录，系统会发送课程完成通知给教务处，告知该门课程的成绩已经齐全。
教务处根据需要，请求系统生成相应的成绩列表，用来提交考试委员会审查。
6) 在生成成绩列表之前，系统会生成一份成绩报告给主讲教师，以便核对是否存在错误。
主讲教师须将核对之后的成绩报告返还系统。
7) 根据主讲教师核对后的成绩报告，系统生成相应的成绩列表，递交考试委员会进行审查。
考试委员会在审查之后，上交一份成绩审查结果给系统。
对于所有通过审查的成绩，系统将会生成最终的成绩单，并通知每个选课学生。
现采用结构化方法对这个系统进行分析与设计，得到如图2-1所示的顶层数据流图和图2-2所示的第1层数据流图。
【问题1】（4分）使用说明中的词语，给出图1-1中的外部实体E1~E4的名称。
数据流图(示例)
数据流图（示例）
系统流图虽然在一定程度上表达了信息的流动和存储情况，但要想描述出信息流和数据从输入移动到输出的过程中所经受的变换，必须把信息的流动、加工、存储等过程流抽象出来，得出组织中信息流的综合情况，描述这种情况的就是数据流图。
数据流图是组织中信息运动的抽象，是管理信息系统逻辑模型的主要形式。
数据流图（DFD）是一种图形化技术，它描绘信息流和数据从输入移动到输出的过程中所经受的变换。
在数据流图中没有任何具体的物理部件，它只是描绘数据在软件中流动和被处理的逻辑过程，具有直观、形象、易理解的优点。
数据流图有以下四种基本元素组成，它们的图形符号说明如下：
变换数据的处理数据的源点/终点
数据存储数据流
图1 数据流图的图形符号
1 系统顶层数据流图
图2 顶层数据流图
2系统0层数据流图
图3系统0层数据流图对图3中的数据流描述如下：
F1：用户信息
F2：课程相关数据
F3：测试题
F4：网络课件数据
F5：课程信息
F6：测试过程数据
F7：学生答案
F8：学生的学习及测试情况
F9：学习进度
F10：测试成绩
3 系统1层数据流图
图4系统1层数据流图（用户管理）对图4中的数据流描述如下：
F1：用户名，密码
F2：用户基本信息
F3：课程用户信息
F4：课程学生信息
F5：课程教师信息
图5系统1层数据流图（课程管理）
图6系统1层数据流图（在线测试过程控制）
图7系统1层数据流图（信息反馈）。
软件工程分层数据流图建模实例
实例我们需研制一个“教育基金会的捐助资金管理系统”的例子来说明数据流图的具体建模方法。
要求如下：⑴由捐助者向基金会提出捐助请求，经身份确认后被接受，对捐助人进行登记并授予捐助证书，捐款存入银行。
⑵由教育单位提出用款申请，在进行相应的合法性校验和核对相应的捐款储备后做出支出。
⑶每月给基金会的理事会一份财政状况报表，列出本月的收入和支出情况和资金余额。
为了搞清系统中的各种关系，用数据流图的方法进行分析和建模。
1.初步确定基本元素画数据流图的第一步是确定图中数据的源点或终点以及数据流。
首先考虑数据的源点或终点。
从以上对关系的描述可知：“捐助者向基金会提出捐助请求”，“由教育单位提出用款申请”，“每月给基金会的理事会一份财政状况报表”，所以“捐助者”和“教育单位”是数据的源点，而“理事会”是数据的终点。
然后考虑数据流。
由于系统需要把每月的财政报表提供给理事会，因此财政报表是一个数据流；同样，捐助者的捐款请求和教育单位的用款申请都是系统的数据流。
在问题的描述中，“给理事会财政状况报表”表明“财政报表”也是数据流。
这样我们得到如图1所示的顶层图。
顶层图由若干个数据的源点和终点和一个加工组成。
这个加工就代表了整个系统的功能。
图1 基金会资金管理系统的顶层数据流图2.分解接下来是对顶层数据流图进行细化，从而描述系统的主要功能。
可以采用从外向里的方法进行。
由上面的讨论可知，数据流“捐款请求”是作为基金会的收入来处理的，可以加上一个“收入处理”的加工；数据流“用款请求”是作为基金支出来处理的，应加上一个“支出处理”加工；数据流“财政报表”应由加工“产生报表”来完成。
这三个加工将代替图1中的“资金管理系统”。
此外，数据流增加了一个数据存储，因为“处理收入”、“处理支出”和“产生报表”都需要从“财政状况”数据库中取得数据。
与这个数据存储相对应的三个数据流，分别用于三个不同的加工访问数据存储中的数据。
可以注意到这三个数据流与数据存储的命名相同，因为从一个数据存储中取得的数据通常和它本来存放的数据形式一样。
关于数据流图DFD实例
主管部门批 准/不批准
主管部门
应收账款报表
生产部门
图6.19
当前价格 产品描述 已核对价 格的订单 应收账款
订单数据
顾客
1.1 核对价格
1.2 核对账目 状况
账目状况已核对的订单
批准/不批准
1.3 批准订单
主管部门 批准/不批准
核对订单数据
主管部门
关于数据流图DFD实例
关于数据流图DFD 概念：数据流图表达了数据和处理的关系。它 是将用户提供的业务流程图进一步标准化。用比 较规范DFD进行描述 设计：DFD设计过程就是将数据和处理进行逐 层分解就形成了若干层次的DFD。 数据流图DFD分为顶层图（第一层图）第二层 图、第三层图等等。 举例说明：下面通过销售系统流来说明DFD的 设计过程，其中图6.18是销售子系统第一层的数 据流图，图6.19是第二层图。
图例说明
外部实体
处理
存储18
1.0送 进订单
调整 发票 应收账款 顾客账目状况 产品描述
顾客
包装通知单
订单记录本
订单细节 未付 差额 调整 财务费 用变动 生产通知单 准备发 货细节 5.0提供应 收账款
1.0送 已批准订单 进订单
核对 订单 数据
2.0处理 订单
3.0开 发票
数据流图与数据字典的一个经典例子知识分享
系统的数据流图与数据字典实例作为示例，为简单起见，我们只考虑人机分工。
此处的数据流图是计算机化的帐务处理系统中涉及到计算机部分的数据流图，人工完成的部分将不做反应。
例如：计算机没有能力审核原始凭证、填制记账凭证，这些工作必须由人来完成，因此进入系统（系统的自动化部分）的应该是记账凭证而不是原始凭证。
银行对帐单仍然是系统的输入数据流，原有的输出数据流系统也必须提供。
图1 系统的顶层数据流图图2 系统的第一层分解图记账凭证进入计算机系统需要进行输入操作，而且由于记账凭证本身可能出错，或输入过程中可能发生错误，因此系统必须提供对已输入的记账凭证的修改功能和审核功能，审核通过的记账凭证才能够记账。
据此，对“凭证处理”分解得到第二层分解图，该分解图由凭证输入、凭证修改和凭证审核三个处理构成。
如果记账凭证是由操作人员直接根据原始凭证用计算机填制，则凭证处理还应该包含一个打印记账凭证的处理。
图3 系统第二层分解图之一（图1）在系统中，登帐处理由计算机完成，其分解的流程图与原来一致。
图4 系统第二层分解图之二（图2）图5系统第二层分解图之三（图3）图6 系统第二层分解图之四（图4）8.1.3 数据字典数据字典的作用是对数据流图中的各种成分进行详细说明，作为数据流图的细节补充，和数据流图一起构成完整的系统需求模型。
数据字典一般应包括对数据项，数据结构、数据存储和数据处理的说明。
以下列出本系统的主要数据字典条目。
1. 数据项条目数据项编号：D01-001数据项名称：凭证编号别名：凭证流水号符号名：PZBH数据类型：数值型长度：4取值范围：1~9999其余略。
2. 数据结构条目数据结构编号：DS01-003数据结构名称：会计分录别名：分录简述：记帐凭证的基本组成成分组成：科目代码+借贷方向+金额其余略。
3. 数据存储条目数据存储编号：F01数据存储名称：记账凭证来源：由凭证处理产生组成：凭证日期+凭证类别+凭证编号+附件张数+{会计分录}+制证+主管+审核数据存储编号：F02数据存储名称：现金日记账来源：由登记现金日记账产生组成：凭证日期+凭证类别+凭证编号+摘要+借方金额+贷方金额+余额方向+余额数据存储编号：F03数据存储名称：银行日记账来源：由登记银行日记账产生组成：凭证日期+凭证类别+凭证编号+摘要+借方金额+贷方金额+余额方向+余额数据存储编号：F04数据存储名称：明细账来源：由登记明细账产生组成：科目代码+凭证日期+凭证类别+凭证编号+摘要+借方金额+贷方金额+余额方向+余额数据存储编号：F05数据存储名称：总账来源：由登记总账产生组成：{科目代码+年份+月份+期初余额方向+期初余额+本期借方发生额+ 本期贷方发生额+本期余额方向+本期余额}其余略。
数据流图举例-图书管理系统
(1) 性能要求 查询服务部分：用户通过多媒体电脑，在提交查询命令到返回结 果，本地计算机不超过5秒钟。 数据管理部分：提交一次录入到结果返回不超过 5 秒钟。借阅等 对资源不能满足借阅要求时，应首先予以提示，不能出现死循环 或无限等待。 (2) 灵活性要求 各种字典数据的编码要尽可能采用行业标准，自行编码也应合乎 规范，征得相关业务部门认可；数据库的设计应考虑可扩充性， 以适应今后图书馆发展和系统升级的需要。 (3) 故障处理要求 正常使用时不应出错，若运行时遇到不可恢复的系统错误，也必 须保证数据库完好无损。在系统出错后，应能恢复回原来备份的 数据库。 (4) 其他要求
数据流图举例 图书管理系统
图6-5是图书馆信息系统的顶层数据流图
系统时钟
当前时间管理请求信息 图书源自询信息读者信息图书管理 员 图书馆信息系统 图书信息 罚款信息 读者情况 图书情况 借还书信息 图书借阅情况 读者
图6-6
第二层数据流程图
图6-9
图书借阅管理数据流程图
6. 其他用户需求
概要设计
概要设计也叫总体设计，或架构设计，它是软件开发的第二个阶 段，在完成系统需求分析的基础上确定系统“怎么做”。概要设 计注重于宏观上和框架上的设计，它是软件系统的总体结构设计、 全局数据库(包括数据结构)设计、外部接口设计、功能部件分配 设计、部件之间的接口设计。它要覆盖需求规格说明书中的功能 点列表、性能点列表、接口列表，若为 B/A/S 结构设计，则要说 明部件运行在网络中的哪一个节点上。 概要设计的任务，一是要覆盖《需求规格说明书》的全部内容， 二是要作为指导详细设计的依据。 (1) 系统模块的划分 概要设计的核心问题是确定系统总体架构和模块划分。系统功能 要层层划分，直到每一个模块可以作为一个可以执行的程序单元 为止。功能模块的划分最终的结果，是系统功能结构图，图6-10 是图书馆信息系统的功能架构图。 (2) 功能需求与程序模块的关系，如表6-4所示。 (3) 基本处理流程，如图6-11所示。
考务系统的分层数据流图实例PPT幻灯片课件
经审定的 成绩清单
2.5 分析 试题难度
难度 分析表
2.4 分析 统计成绩
分类 统计表 考生名册
2.3 考生 制作 通知单 通知单
6
统计分析表。
1
实例 考务处理系统功能
考务处理系统的分层DFD • 如下：
2
顶层数据流图
不合格报名单
考
统计分析表
试
考
报名单
生
准考证
中
考务 处理系统
合格标准 心
考生通知单
考 生 名
成 错误成 绩 绩清单 清
单
单
阅卷站
3
0层数据流图
报名单
考生通知单
不合格 报名单
准考证
1
登记 报名单
2
统计分析表 统计成绩
考务处理系统功能
(1)对考生送来的报名单进行检查; (2)对合格的报名单编好准考证号后将准考证送给考
生，并将汇总后的考生名单送给阅卷站; (3)对阅卷站送来的成绩单进行检查并根据考试中心
制定的合格标准审定合格者; (4)制作考生通知单(含成绩及合格/不合格标志)送
给考生; (5)按地区进行成绩分类统计和试题难度分析，产生
错
考 生 名 单
考生名册
合 格 标 准
成绩误成 清
绩 清
单单
4
一层数据流图 (a)
报名单
不合格 报名单
1.1
检查 报名单
合格 报名单
1.2
编准考 证号
准考证
考生名册
1.3 考生名单
登记 考生
5
一层数据流图 (b)
成绩清单
2.1 检查
正确
2.2
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
网上作业提交与管理系统的顶层数据流图
其中：
数据流A：账号和密码
数据流B：作业申请
数据流C1：需要完成的作业
数据流C2：完成的作业
数据流D：作业成绩
存储E：作业成绩统计文件
决策表
行李
重量
W＞30
W≤30是否
国内
乘客
头等舱
其他舱
国内
国外
免费
是否
头等
舱
(W－30)×4
(W－30)×6
头等舱
其他舱
是否
头等
舱
(W－30)×8
(W－30)×12
需求分析文档
超市进货管理系统的开发主要涉及到商品信息的管理、供应商信息的管理、订单信息的管理、库存信息的管理、商品分类信息的管理五大功能的数据管理。
商品信息管理包括添加商品、删除商品、修改商品信息、浏览商品信息。
供应商信息管理包括添加供应商、删除供应商、修改供应商信息、浏览供应商信息、浏览供应商与商品间关系。
订单信息管理包括添加订单、删除订单、修改订单信息、浏览订单信息。
库存信息管理包括添加商品库存、删除商品库存、修改商品库存信息、浏览商品库存信息。
商品分类信息管理包括添加商品分类信息、删除商品分类信息、修改商品分类信息、浏览商品分类信息。
一、功能需求
(1) 商品管理---对所有商品信息进行管理。
(2) 供应商管理---对购物车和订单信息的维护。
(3) 订单管理---对订单和订单中书籍打印信息的更新与管理。
(4) 库存管理---对后台用户进行管理添加、删除以及修改信息。
(5) 商品分类管理---对数据库进行备份和恢复。
二、性能需求
(1) 系统中的软件不构成对人身健康的损害。
(2) 系统中的软件失效时不造成财产的损失。
(3) 系统中的软件失效时不造成环境的破坏。
(4) 系统中的软件可以每天使24小时，每年使用365天。
(5) 系统中的软件故障率小于等于5%。
(6) 用户输入错误信息时系统应提示不应崩溃。
(7) 软件适合12-70周岁的智力、视力、体力和肢体正常且具有图书借阅相关知识的人使用。
三、运行需求
(1) 系统在常温环境下使用。
(2) 系统在洁净的室内使用。
(3) 宽带网、1M以上宽带互联网。
(4) 任何有浏览器的设备打印功能需IE浏览器。
(5) 数据库管理系统SQL Server2008及以上。