信息系统分析与设计(第3版)邝孔武 王晓敏_第 6章-结构化系统分析

客户
客户或 管理部 门 发装部
更新订单
查询订单的 状态 记录订单的 执行
信用卡处理 系统 客户 发装部门 银行 修改确认 客户 订单修改细节 发装部门 交易信息 银行 订单状态的详 客户或管理 细情况 部门
客户退货
订单退货 通知
客户
建立退货记 录
退货确认 交易信息
客户 银行
网上订单系统的事件表
事件名称 触发点 未来客户需要 产品目录 目录 的查询请 求 客户更新基本 客户信息 信息 修改通知 市场部给客户 促销产品 发送促销材料 细节 调整产品目录 产品目录 更新细节 事件源 活动 未来客 提供产品目录 户 信息 客户 更新客户基本 信息 分发促销单 更新产品目录 促销单 客户和未来 客户 响应结果 产品目录 事件目的地 未来客户
• 客户
• 技术人员
系统需求的种类
系统需求是新系统必须完成的功能或其局限性。
• 系统需求一般分为两类：
–功能性需求 –技术性需求
功能性需求
• 功能需求是系统必须完成的活动或过程，也 就是系统将要涉及的商业应用。 • 功能需求是根据业务过程和业务规则确定的， 有些容易获取，有些则是隐含的，需要去发 现。
图书管理员
算机程序），通常可省略
数据流
数据流是指处理功能的输入或输出（箭头表示 数据流向） 。 •例如：数据，订单，查询要求等
合格订单 编 辑 订货单 计 算 应收款
编制 财务 报表
经理
数据存储
数据存储表示某种数据保存后的逻辑统称。不 是指保存数据的物理地点或物理介质。 •流入数据存储的数据流
• 将处理后的数据写入或修改到数据存储中
• 外部实体是数据的来源（谁提供了最初始的数据？） • 外部实体是数据的去处（数据对谁有价值？）
图书 管理员 图书 管理员
读者
馆长
读者
数据处理
处理指对数据的逻辑处理功能，也就是对数 据的变换功能。 别名：功能、处理过程，数据加工
P2.2.1 识别 读者身份 标识部分（层次化的功能编号） 功能描述部分（动宾词组） 功能执行的角色（人，部门，计
– 例如：姓名可能包含姓和名，日期包含年月日。
6.2 数据流图
系统分析阶段： • 使用数据流图DFD来建立系统需求的过程模 型。（结构化系统分析的方法）
• 系统分析采用ER图来建立系统的数据模型。
结构化分析的思想
• 数据流图DFD采用一系列分层次的数据流图 来描述系统。 • DFD的每一个层次都代表了系统的一个抽象 水平。高层次DFD中的处理可以进一步分解
–如：学生和图书，一个学生可以预约多本图书， 每本图书可能被多个学生预约。
–如：一个客户可以发出多个订单，一个订单只能 是一个客户的。
事物的属性
• 属性：有关事物的一条特征信息。
– 例如：客户的姓名、年龄、电话等。
• 标识符：能唯一区分事物的属性。
– 例如：发货单号，职工编号。
• 复合属性：指包含了许多相关属性的属性。
其他要求:系统分析员应有较强的系统观点，较好的
逻辑分析能力，能够从复杂的事物中抽象出系统模 型。他还应具备较好的口头和书面表达能力，较强 的组织能力，善于与人共事。
6.1.2 系统需求
分析的重要任务是理解和表达需求 • 需求有哪些种类？ • 如何寻找需求？ • 如何表述需求？
需求的来源—系统相关者
• 建模是一个从具体到抽象，又从抽象到具体 的过程，需要反复多次
6.2.2 数据流图的画法
• 下面我们以高等学校学籍管理系统为例说明 画数据流图的方法 • 如果不能直接建模，可以考虑以下事件：
– 新生登记 – 登记期末成绩 – 期末成绩分析 – 登记补考成绩 – 补考后成绩分析 – 评定奖学金 – 处理退学、留级、修学、复学 – 发成绩单……
技术性需求
• 技术需求也称非功能性需求，是和公司的环 境、硬件和软件有关的所有可操作目标。 • 例如：系统必须能支持100个并发用户；保存 订单的时间不能超过0.5秒等等，涉及系统性 能、可靠性、安全性等质量特性。
• 通常是一些技术目标。
如何表述需求
• 自然语言
– 不需要任何准备 – 但既要保证精确无二义性，又要保证叙述不至于 晦涩难懂，是困难的（随意性、误会）
系统的所有处理过程都是由事件驱动的， 所以将事件列表并进行分析，对于定义系 统需求是十分有意义的。
事件的类型
我们可以从以下类型来寻找事件： – 外部事件(external event) – 时间事件(temporal event) – 状态事件(state event)
外部事件
在系统之外发生，通常是由外部的人或组织 激发的事件，这些人或组织是数据的提供者 和接收者。 –比如图书馆流通系统中的读者 外部事件能够导出系统需要处理的关键事务
寻找外部事件
• 首先要确定外部实体，然后再分析。 • 外部实体需要一个事务处理
–比如读者借书
• 外部实体需要系统提供某些信息
– 比如读者查阅书目
• 某些数据改变了，系统需要更新它们
– 比如书籍的位置改变
• 管理过程需要某些信息
– 比如制订新的采购计划需要流通统计情况
时间事件
当系统时间到达某一刻时发生的事件，这些 事件通常要求系统能定时自动地完成某些输 出或处理。
识别事件的规则
• 区分事件与具体响应过程
– 事件响应中的一系列交互过程是完整具体的实现，而
不是独立的一个事件。例如：拿信用卡交费
• 跟踪关键业务的整个生命周期来发现事件
– 跟踪读者实现从图书馆借书的全部过程
• 暂时忽略技术性依赖事件和系统控制事件
– 如管理员登录系统，修改口令，每天的备份
网上订单系统的事件表
事物之间的关系
• • 事物间的很多关系对于研究系统也非常重 要。 关系：指某些事物间自然发生的联系。
– 例如：学生和图书，学生可以借阅图书。
– 例如：一个客户可以发出订单。
•
对每一个事物分析和它相关的事物，找出 关系。
事物之间关系的基数
• 关系的基数：指一个事物关联另外一个事物 的数量（一对一，一对多，多对多或者一个 具体的数量—4个）。
• • • • 活动对应于处理框 事件源和事件目标对应于外部实体 触发点和响应结果是与外部实体相连的数据流 只有数据存储在事件响应表中没有对应的描述
事件表中能找到数据流图中出现的一些元素：
事件和DFD
• 事件列表中的每一个事件都可以画出一个 DFD图（需要额外添加数据存储元素） • 事件列表可以作为画数据流图的一个基础和 检验列表
成低层次、更详细的DFD。
分层的数据流图
• 纵观
顶层
P1
P2
第一层
P3 P4
P41 P42
第二层
6.2.1 数据流图的基本成分
• 数据流图用来记录系统中的数据和数据在特 定的过程中的流动，即数据如何被采集、处 理、保存和使用的（围绕信息系统的功能）
p1
外部实体
数据处理
数据存储
数据流
外部实体
外部实体指系统以外又与系统有联系的人或事物 。它表达了该系统数据的外部来源和去处。 例如：人、组织、外部系统等等。
市场部 销售部
每日交易汇总 每天末
产生交易汇总 报告
产生订单汇总 报告
交易汇总报 财务部 告
订单汇总报 管理部门 告
每周订单汇总 每周末
2、事物与系统需求
• 事物——系统需要处理或保存的对象。
– 如客户，订单，产品等。
•
对信息系统中事物的理解和建模是定义 系统需求的另外一个重要方面。
事物的类型
事物的类型： • 实在有形：书籍、产品、文档 • 角色身份：医生、读者、顾客 • 组织单位：小组、部门 • 设备：打印机、传感器、鼠标 • 事件：借阅、订货、销售、罚款 • 场所：零售店、仓库
– 事件对应DFD模型的中间层 – 事件可以继续分解绘制其具体的处理过程（向下 细化） – 系统中事件较多时，应进行分组（向上抽象）
单个DFD的组合Βιβλιοθήκη Baidu
• 事件之间有一定的联系，一般通过数据存储 建立关联
完整的数据流图
根据事件表重新组织，绘制完整的DFD模型：
• 按照事件表，对每一个事件建立一个DFD片 段图。
•流出数据存储的数据流
• 从数据存储中查询获取数据，不改变原来的数据
D2 D5 D2
产品
销售量
职工
累计销售量单价
产品
计算 销售量
D2 产品销售帐
计算销售总额
商品编号#_
其他图形表示
数据流图中的图形元素有不同的画法，本书使 用Gane-Sarson画法
存取要求
帐目
业务 处理
储户
存折
一个事件的DFD
顶层
报表 新生名单
教委
招生办
学籍管 理系统
毕业生登记表 用人 单位
学籍表
学籍管理系统顶层DFD
第一层
第二层——“成绩管理”框的展开
第三层——“处理期末成绩”框的展开
第三层——“分析期末成绩”框的展开
第三层——“分析补考成绩”框的展开
6.2.3 画数据流图的注意事项
要注意以下几点： 1. 关于层次的划分 2. 语法的正确性 3. 可读性 4. 确定系统边界
•
模型
– 模型是人们对复杂问题的一种抽象或者对实物的 一种简单实现或规划蓝图。 – 例如：飞机模型，建筑模型，数学模型等等。
模型的作用
信息系统模型的作用：
– 建立模型的过程可以使得分析员更深入地了解 和定义信息系统的需求，并发现问题 – 对复杂问题进行简化 – 有助于回忆需求的细节 – 有助于同开发小组的其他成员交流 – 有助于同客户交流 – 为以后的维护升级提供了文档
• 把所有的DFD片段进行分组，归纳为大的处 理逻辑，形成上一层DFD（复杂系统层次更 多）。
• 将属于一组内的DFD片段放在一张图上，形 成事件层的DFD图。 • 对每个事件的数据处理进一步分解为下一层 DFD （复杂系统层次更多）。
完整的数据流图
• 真正进行结构化系统建模过程中，应该采用 自顶向下的分解方法，事件表只是寻找需求 的辅助工具（启发）
如何着手建模
构建模型首先需要识别用户的需求，识别需 求一般可以从两个方面着手：
•
识别系统中的事件(Events)建立过程模 型（数据流图，DFD）
识别系统中的事物(Things) 建立数据模 型（实体关系图，ER）
•
1、事件与系统需求
事件——在特定时间、特定地点发生的，
能够描述出来并值得保存的的事情。
第6章 结构化系统分析
本章计划学时：8学时
本章主要内容
• • • • • • 系统分析的任务 数据流图 数据字典 表达处理的工具 实体关系图 系统说明书
6.1 系统分析的任务
• 系统分析员与用户在一起充分理解用户的要 求，并把双方的理解用书面文档——系统分 析说明书表达出来。 • 分析本质上就是一个发现过程，分析期间推 动活动的关键词就是发现和理解。
系统分析的困难
• 系统分析是研制信息系统最重要的阶段，也 是最困难的阶段。 • 困难主要来自三个方面：
– 问题空间的理解 – 人与人之间的通讯 – 环境的不断变化
系统分析员要成为业务专家
• 才能与用户交流顺畅，充分理解用户的要求。 • 才能确保系统满足了业务需求，甚至用更好 的方法来解决业务需求。 • 在用户中建立可信度，用户才可能接受你的 建议。
• 系统需求的主要来源是系统的各种系统相关 者，他们是对系统成功感兴趣的所有人（与 系 统 有 关 系 的 所 有 人 ， 也 称 涉 众 stakeholder）。 • 系统分析中获得需求的首要步骤就是确定各 类系统相关者。
系统相关者
• 业务用户 • 信息用户 • 管理用户 • 主管用户
• 外部用户
信息系统的模型
在信息系统分析中有三类常用的图示化模型：
1. 功能模型
• 利用数据流图分层描述系统的功能和数据的处理流程 • 利用数据字典辅助解释数据流图中的每个元素
2. 数据模型
• 利用实体关系图描述系统中的数据实体及其关系
3. 对象模型
• 利用类图描述对象、对象之间的联系。和数据实体不 同，对象在数据之外增加了行为特性
–如：图书馆流通系统中的按月发布逾期催还 名单。 –如：每天晚上12：00定时转换归档医疗图像。
注意命名时必须包含所要完成的处理和规定 期限
状态事件
系统内部的变化触发系统对某个处理的需要， 这种情况的发生称为状态事件
–比如：销售系统中库存数一旦低于控制点就产 生订货单
状态事件一般是外部事件的结果，它的发生 是不定时的
事件名称 触发点 客户希望检查 产品的查 产品可订量 询请求 客户建立一个 新订单 订单 事件源 活动 客户 查询产品的 可用量 客户 建立新订单 响应结果 产品可用量详 细情况 实时连接 订单确认 订单细节 交易信息 事件目的地 客户
客户改变或作 修改订单 废订单 的请求
客户和管理层 订单状态 检查订单状态 的查询请 求 为订单发货 订单发货 通知