软件工程第三章
合集下载
自考软件工程第3章知识点总结
2
第3章 软件需求分析
需求分析在软件开发中所处的地位愈加突出，从而也愈加 困难，它的难点主要体现在以下几个方面：
(1) 问题的复杂性。 (2) 交流障碍。 (3) 不完备性和不一致性。 (4) 需求易变性。
软件需求分析与说明的方法的基本原则：
(1) 必须能够表达和理解问题的数据域和功能域。 (2) 可以把一个复杂问题按功能进行分解并可逐层细化。 (3) 建模。
结构化分析（Structured Analysis，简称SA），是面向数 据流进行需求分析的方法。根据软件内部数据传递、变换的关 系，自顶向下逐层分解，描绘出满足功能要求的软件模型。
3.2.1自项向下逐层分解的分析策略
面对一个复杂的问题，采取分解的策略，把一个复杂的问
题划分成若干小问题，然后再分别解决。分解可分层进行，在
(3) 环境需求。 (4) 用户界面需求。
4
第3章 软件需求分析
2. 分析与综合， 导出软件的逻辑模型 分析人员对获取的需求，进行一致性的分析检查，在 分析、 综合中逐步细分软件功能，划分成各个子功能。 3. 编写文档 编写文档的步骤如下： (1) 编写“需求说明书。 (2) 编写初步用户使用手册。 (3) 编写确认测试计划。 (4) 修改完善项目开发计划。
3. 数据项条目 数据项条目是不可再分解的最小数据单位， 其定义格 式及举例如下： 数据项名称： 货物编号 别名： G-No， G-num, Goods-No 简述： 本公司的所有货物的编号 类型： 字符串 长度： 10
取值范围及含义： 第1位： 进口/国产
第2～4位： 类别 第5～7位： 规格
第8～10位： 品名编号
1. 数据流条目
数据流条目给出了DFD中数据流的定义，通常列出该数 据流的各组成数据项。
软件工程第3章需求工程概论
• 质量需求对软件结构的影响力更大，一项功能的
实现方式可能多种多样，但往往只有少数实现方
式才能满足特定的质量要求。
2020/8/20
国防科技大学计算机学院
9
软件需求的概念
• 在质量需求得不到满足的情况下，功能需求的实 现对用户并无价值 • 试想有多少用户愿意为查询一张课表而傻等数十 秒甚至数分钟 • 又有多少用户愿意冒数据丢失的风险而使用“功 能丰富”的信息化系统？ • 质量需求具有特殊的重要性，需求工程师必须对 其倾注更多的心力。
2020/8/20
国防科技大学计算机学院
14
（一）组成联合工作组
• 利益相关方代表和需求工程师组成联合工作组 • 在需求工程的初期，需求工程师和用户/客户相 互陌生，知识领域和工作侧重也各不相同，在他 们之间往往横亘着一条泾渭分明的疆界。 • 在疆界的两边，通过问答和文档进行沟通。 • 这种方式抑制了利益相关方在需求工程中的主动 精神，阻碍了良好的协同工作关系，容易导致误 解和遗漏。
• 本节将软件需求的质量要素组织为正确性、完全性和可行性三个方面。 • 软件需求的正确性包含真实性、一致性、精确性、无冗余四个质量指标。 • 真实性指，每个需求项能真实反映利益相关方的需求； • 一致性指，需求项内部、需求项之间没有逻辑冲突； • 精确性指，需求项的表述不至引起二义或多义理解； • 无冗余指，每项需求在软件需求模型中仅出现一次，多项需求之间不存
2020/8/20
国防科技大学计算机学院
15
组成联合工作组
• 建立由利益相关方代表和需求工程师共同组成的联合工作组 • 参加工作组的利益相关方代表也属需求工程人员 • 他们对需求工程的成功负有与软件开发方相同的责任。 • 联合工作组要制定自己的工作制度和计划，确定专门的记录员并
软件工程第三章
3.1 需求分析的任务3.1.1 需求分析的概念开发人员要准确理解用户的要求，进行细致的调查分析，将用户非形式的需求陈述转化为完整的需求定义，再由需求定义转化到相应的形式功能规约（需求规格说明）的过程。
需求分析虽处于软件开发过程的初期阶段,但它对于整个软件开发过程以及软件产品质量是至关重要的。
随着软件系统复杂性的提高及规模的扩大，需求分析在软件开发中的所处的地位愈加突出，从而也愈加困难。
1.需求分析的难点(1)问题的复杂性。
用户需求所涉及的因素很多，如系统功能和运行环境。
(2)交流障碍。
需求分析涉及人员较多，分别具备不同的背景知识，处于不同的出发点，造成了相互之间交流的困难。
(3)不完备性和不一致性。
用户对问题的陈述往往是不完备的，其各方面的需求还可能存在着矛盾，需求分析要消除其矛盾，形成完备及一致的定义。
(4)需求易变性。
用户需求的变动往往会影响到需求分析，导致系统的不一致性和不完备性。
2.需求分析的基本原则(1)必须能够表达和理解问题的数据域和功能域。
数据域包括数据流、数据内容和数据结构，而功能域反映数据域三方面的控制信息。
(2)可以把一个复杂问题按功能进行分解并可逐层细化。
(3) 建模。
建立模型可以帮助分析人员更好地理解软件系统的信息、功能、行为，这些模型也是软件设计的基础。
3.1.2 需求分析的基本任务1.问题识别(1) 功能需求：明确所开发的软件必须具备什么样的功能。
(2) 性能需求：明确待开发的软件的技术性能指标。
(3) 环境需求：明确软件运行时所需要的软、硬件的要求。
(4) 用户界面需求：明确人机交互方式、输入输出数据格式。
2. 分析与综合，导出软件的逻辑模型分析人员对获取的需求，进行一致性的分析检查，在分析、综合中逐步细化软件功能，划分成各个子功能。
用图文结合的形式，建立起新系统的逻辑模型。
3. 编写文档(1) 编写“需求规格说明书”，把双方共同的理解与分析结果用规范的方式描述出来，作为今后各项工作的基础。
《软件工程》第3章 软件需求分析
【本章重点】 本章重点】
需求分析的方法 ； 需求分析的任务和原则 ；
【教学目标】 教学目标】
掌握需求分析的基本概念； 掌握需求分析的基本概念； 掌握如何使用需求获取技术来进行数据采集； 掌握如何使用需求获取技术来进行数据采集； 掌握结构化分析的思想与过程； 掌握结构化分析的思想与过程； 掌握数据流建模技术。 掌握数据流建模技术。
3.2 面向数据流的分析方法
3.2.2 数据流图
1．数据流图中的主要图形元素
3.2 面向数据流的分析方法
2．分层的数据流图
在多层数据流图中，可以把顶层数据流图、 在多层数据流图中，可以把顶层数据流图、底层数 据流图和中间层数据流图区分开来。顶层数据流图仅 据流图和中间层数据流图区分开来。 包含一个加工，它代表被开发系统。 包含一个加工，它代表被开发系统。它的输入流是该 系统的输入数据，输出流是系统的输出数据。顶层数 系统的输入数据，输出流是系统的输出数据。 据流图的作用在于表明被开发系统的范围， 据流图的作用在于表明被开发系统的范围，以及它和 周围环境的数据交换关系。 周围环境的数据交换关系。底层数据流图是指其加工 不须再做分解的数据流图，其加工称为“原子加工” 不须再做分解的数据流图，其加工称为“原子加工”。 中间层数据流图则表示对其上层父图的细化。 中间层数据流图则表示对其上层父图的细化。它的每 一个加工可以继续细化，形成子图。 一个加工可以继续细化，形成子图。中间层次的多少 视系统的复杂程度而定。 视系统的复杂程度而定。
3.2 面向数据流的分析方法
4．数据流图的优缺点
总体概念强，每一层都明确强调“干什么” 总体概念强，每一层都明确强调“干什么”，“需要 什么” 给出什么” 什么”，“给出什么”; 可以反映出数据的流向和处理过程; 可以反映出数据的流向和处理过程; 由于自顶向下分析， 由于自顶向下分析，容易及早发现系统各部分的逻辑 错误，也容易修正; 错误，也容易修正; 容易与计算机处理相对应; 容易与计算机处理相对应; 不直观，一般都要在作业流程分析的基础上加以概括、 不直观，一般都要在作业流程分析的基础上加以概括、 抽象、 抽象、修正来得到
软件工程课件第三章
对应的关系模式如下：
商店（商店号, 商店名, 地址, 经理） 职工（职工号, 姓名,性别,商店号,来店时间） 商品（商品号, 商品名, 产地, 价格) 销售（职工号,商品号, 销售数量） 经营（商品号,商店号，月销量）
3．5 数据规范化
为减少数据冗余，避免插入异常、删除异 常，简化修改数据的过程，应该对数据进行 规范化。
优点： 改进了文档质量，保证文档具有完整性、
一致性、无二义性，从而减少管理和维护费 用。便于增、删、改。
本章小结
需求分析的根本任务是确定系统必须做什么。 具体任务：
1. 确定系统的综合要求； 2. 分析系统的数据要求； 3. 导出系统的逻辑模型； 4. 修正开发计划。
是发现、求精、建模、规格说明和复审的 过程。
表示同一 类信息
可以表明信息的逻辑组织。
操作系统（P1）
系统软件
代表每种软 件的数量
编译程序（P2）
软件产品
⊕
应用软件
软件工具
异或: 表明在一定条件下才出现，而 且上、下方不能同时出现，
编辑程序（P3） 测试程序（P4）
3．7．3 IPO图
是一种描绘输入数据、对数据的处理和 输出数据之间关系的图形工具。
Sno
Cno
Sdept Mname
Grade
关键字： (Sno, Cno) 属于第一范式
解决方法：
通过分解关系模式来消除其中不合适的数 据依赖。
即：对上述关系模式，通过投影，分解为 如下三个关系模式：
学生：S(SNO,SDEPT) SNO→SDEPT ； 选 课 ： SG(SNO,CNO,G) (SNO,CNO)→G ；
♦ 用于需求分析的软件工具
软件工具应该满足下列要求： 1．有形式化语言。 2．能导出详细的文档。 3．提供分析手段，指明分析的结果 4．能够改进通信状况。
软件工程第三章需求应用全面分析
结构化英语、判定树、判定表用于描述数据流 图中的处理逻辑说明。
• SA方法的实质*：是采用一组分层数据流图及数据
字典作为系统的模型，从总体来看，是一种依赖数
据流图的自顶向下的建模方法。
2020/11/25
5
数据流图：分层扩展的功能模
型
数据流图（DFD）是SA方法中用于建立系统逻辑模型 的一种工具，它以图形的方式描绘数据在系统中处理的流 动过程。由于它只反映系统需要完成的逻辑功能，所以它 是一种功能模型。*
配件库存
顾客
订货单 发货单
1
处理 业务Biblioteka 订货单 发货单供应 商
2020/11/25
15
数据流图： DFD绘制步骤（续）
* （2）再绘制二层DFD：是顶图的分解，表明子系统划分及其 边界。 • 系统划分几个子系统，一个子系统在二层图中只有一个处理逻辑（需
求来源是业务子系统或用例图中的用例）； • 每一子系统析取所有的外部项、输入输出数据流和主要数据存储； • 各子系统之间的依赖关系（数据流直接依赖，数据存储缓存依赖）。
软件工程 Software Engineering
第三章 需求应用全面分析
2020/11/25
1
本章主要内容
• 3.1 软件需求概念
-软件需求的问题、定义、层次、来源、依据、目标
• 3.2 需求工程过程
- 需求开发：需求获取、需求分析、规格说明、需求验证 - 需求管理：覆盖需求开发全过程
• 3.3 需求获取技术
数据存储可以是一个文件，也可以是文件的一部分或 数据库记录的一部分。数据可以存储在磁盘、磁带、存储 器等任何介质上。指向数据存储的箭头可以是单向的，也 可以是双向的。
《软件工程》第3章用例图及其应用
《软件工程建模工具，能够帮助我们更好地理解系统需求 和功能。本章介绍用例图的概念、基本元素、符号表示方法以及应用场景。
用例图的概念和作用
用例图是一种描述系统功能和用户行为的图形化工具。它帮助开发人员和利 益相关者理解系统的需求，并作为沟通和验证的工具。用例图能够直观地展 示系统功能，帮助识别系统的边界和行为。
用例图的基本元素
用例图包含参与者、用例和关系三个基本元素。参与者代表系统的外部角色， 用例代表系统的功能或服务，而关系则表示参与者和用例之间的交互和依赖 关系。
用例图的符号和表示方法
用例图使用参与者图标、椭圆形表示的用例以及连接线表示关系。参与者图标通常表示为人的图 标，用例图标则是一个椭圆形，并用文字描述用例的名称。
用例图在软件工程中的重要性
用例图在软件工程中起到了至关重要的作用。它不仅帮助开发人员了解系统 需求和功能，还能够引导需求分析和测试的工作，并作为可视化的沟通工具， 促进不同角色之间的合作交流。
结论
用例图作为软件工程中常用的建模工具，具有直观、易理解的特点。通过用例图，我们能够更好 地理解和沟通系统需求，提高系统开发的质量和效率。
用例图的绘制步骤
绘制用例图的步骤包括：确定系统的边界和参与者、识别系统的用例、绘制参与者和用例的图标、 添加关系和标注信息、进行审查和验证。
用例图的应用场景
用例图在软件工程中有广泛的应用场景，例如需求分析、系统设计、测试规 划等。通过用例图，开发人员和利益相关者能够共同理解系统功能和用户需 求，从而有效地进行软件开发。
用例图的概念和作用
用例图是一种描述系统功能和用户行为的图形化工具。它帮助开发人员和利 益相关者理解系统的需求，并作为沟通和验证的工具。用例图能够直观地展 示系统功能，帮助识别系统的边界和行为。
用例图的基本元素
用例图包含参与者、用例和关系三个基本元素。参与者代表系统的外部角色， 用例代表系统的功能或服务，而关系则表示参与者和用例之间的交互和依赖 关系。
用例图的符号和表示方法
用例图使用参与者图标、椭圆形表示的用例以及连接线表示关系。参与者图标通常表示为人的图 标，用例图标则是一个椭圆形，并用文字描述用例的名称。
用例图在软件工程中的重要性
用例图在软件工程中起到了至关重要的作用。它不仅帮助开发人员了解系统 需求和功能，还能够引导需求分析和测试的工作，并作为可视化的沟通工具， 促进不同角色之间的合作交流。
结论
用例图作为软件工程中常用的建模工具，具有直观、易理解的特点。通过用例图，我们能够更好 地理解和沟通系统需求，提高系统开发的质量和效率。
用例图的绘制步骤
绘制用例图的步骤包括：确定系统的边界和参与者、识别系统的用例、绘制参与者和用例的图标、 添加关系和标注信息、进行审查和验证。
用例图的应用场景
用例图在软件工程中有广泛的应用场景，例如需求分析、系统设计、测试规 划等。通过用例图，开发人员和利益相关者能够共同理解系统功能和用户需 求，从而有效地进行软件开发。
软件工程第三章
SIT
3）着重强调的是数据流程而不是控制流程。
数据流程图中的基本符号有： 1、数据流
数据流是有名字有流向的数据，在数据流程图中，数据 流用标有名字的箭头来表示。
3.5 需求分析方法
2、加工 加工又称处理逻辑，表示数据所进行的加工或变换，以 标有名字的圆圈代表加工。指向加工的数据流是该加工的输 入数据，离开加工的数据流是该加工的输出数据。 3、文件
SIT
3.1 概述
目标系统的逻辑模型：分析当前系统与目标系统逻辑上 的差别，明确目标系统要“做什么”的实质工作，从当前系 统的逻辑模型导出目标系统的逻辑模型。 目标系统的物理模型：确定待开发系统的系统元素，将 功能和数据结构分配到系统元素中。它的具体物理模型则是 由它的逻辑模型经实例化后，具体到某个业务领域得到的。
3.3.2用户需求
用户需求是从用户角度来描述系统功能和非功能需求， 以便让不具备专业技术方面知识的用户能看懂。这样的需求 描述只描述系统的外部行为，要尽量避免对系统设计特性的 描述。
3.3 软件需求分析类型
3.3.3系统需求
系统需求是比用户需求更详细的需求描述，是系统实现 的基本依据，因此，是一个完全的和一致的系统描述，是软 件工程人员系统设计的起点。 自然语言时常被用来书写系统需求描述，但被用来做更 详细的描述时，深层次的问题就暴露出来，主要有：
3.5 需求分析方法
3.建立行为模型 分析建模是实现真实世界模型向计算机模型转换的核心 环节，也是一种处理软件复杂性的有效手段。在需求开发阶 段，分析建模的关键是针对用户需求建立抽象的分析模型， 从而有助于开发人员理解用户需求，同时增强自然语言的需 求规格说明。分析模型往往采用一些图形化的表示方式，从 数据、功能和行为等不同角度表达用户需求。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
户也可以是开发者还可以是从外面请来的人。
· 使用一种“定义机制”(例如，工作表、图表 等)。 · 目标是标识问题、提出解决方案要素、商讨不 同的方法以及在有利于实现目标的氛围中指定初步的 需求。
3.2.3 软件原型 构建原型的要点是，它应该实现用户看得见的功
能(例如屏幕显示或打印报表)，省略目标系统的“隐
图3.3 数据流图的符号
3.5.2
例子
下面通过一个简单例子具体说明怎样画数据流图。 假设一家工厂的采购部每天需要一张定货报表， 报表按零件编号排序，表中列出所有需要再次定货的 零件。对于每个需要再次定货的零件应该列出下述数 据；零件编号、零件名称、定货数量、目前价格、主 要供应者和次要供应者。零件入库或出库称为事务， 通过放在仓库中的CRT终端把事务报告给定货系统。当 某种零件的库存数量少于库存量临界值时就应该再次 定货。 数据流图有四种成分：源点或终点、处理、数据 存储和数据流。因此，画出上述定货系统的数据流图 可采用以下步骤。
3.6 状态转换图
状态转换图(简称为状态图)通过描绘系统的状态 及引起系统状态转换的事件，来表示系统的行为。
一旦把数据流图的四种成分都分离出来以后，就 可以着手画数据流图了。任何系统的基本模型都由若
干个数据源点/终点以及一个处理组成，这个处理就代
表了系统对数据加工变换的基本功能。对于上述的定 货系统可以画出如图3.4所示的基本系统模型。 从基本系统模型这样非常高的抽象层次开始画数 据流图是一个好办法。在这个高层次的数据流图上是
模型由一组图形符号和组织这些符号的规则组成。结 构化分析就是一种建立模型的活动，通常建立数据模 型、功能模型和行为模型等三种模型。 除了用分析模型表示软件需求之外，还要写出准
确的软件需求规格说明。模型既是软件设计的基础，
也是编写软件规格说明的基础。
在分析软件需求和编写软件规格说明的过程中， 软件开发者和软件用户都起着关键的、必不可少的作
图3.4 定货系统的基本系统模型 (突出表明了数据的源点和终点)
图3.5 定货系统的功能级数据流图
图3.6 把处理事务的功能进一步分解后的数据流图
3.5.3
命名
数据流图中每个成分的命名是否恰当，直接影响 数据流图的可理解性，因此，给这些成分起名字时应 该仔细推敲。下面讲述在命名时应注意的问题。 1为数据流(或数据存储)命名 · 名字应代表整个数据流(或数据存储)的内容，
图3.1 分析模型的结构
3.3.2
软件需求规格说明
通过需求分析除了创建分析模型之外，还应该写
出软件需求规格说明，它是分析阶段的最终成果。下
面给出的简略大纲可以作为软件需求规格说明的框架。
Ⅰ.引言
A .系统参考文献 B .整体描述 C .软件项目约束
Ⅱ.信息描述 A .信息内容 B .信息流 1 .数据流 2 .控制流 Ⅲ.功能描述 A .功能分解 B .功能描述 1 .处理说明 2 .限制 3 .性能需求 4 .设计约束 5 .支撑图
3.2 与用户通信的技术
软件需求分析总是从两方或多方之间的通信开始。 用户面临的问题需要用基于计算机的方案来解决；开 发者应该对用户的需求作出反应，给用户提供帮助。 这样就产生了相互通信的需求。但是，正如前面已经 讲过的，从开始通信到真正相互理解的道路通常是充 满坎坷的。良好的通信技术有助于加快理解的过程。 3.2.1 访谈 访谈(或称为会谈)是最早开始运用的获取用户需 求的技术，也是迄今为止仍然广泛使用的主要的需求 分析技术。
系。
3.4.1数据对象 数据对象是对软件必须理解的复合信息的表示。 所谓复合信息是指具有一系列不同性质或属性的事物， 因此，仅有单个值的事物(例如宽度)不是数据对象。
3.4.2
属性
属性定义了数据对象的性质。 应该根据对所要解决的问题的理解，来确定特定
数据对象的一组合适的属性。
3.4.3 称为联系。 (1) 一对一联系(1∶1) 关系
访谈有两种基本形式，分别是正式的和非正式的 访谈。在正式的访谈中，系统分析员将提出一些事先
准备好的具体问题，例如，询问客户公司销售的商品
种类、雇用的销售人员数目以及信息反馈时间应该多
快等。在非正式的访谈中，将提出一些可以自由回答
的开放性问题，以鼓励被访问的人员表达自己的想法， 例如，询问用户为什么对目前正在使用的系统感到不 满意。
分析的第一步是尽可能准确地了解用户当前的情况和
需要解决的问题。 分析员对用户提出的初步要求应该反复求精多次 细化，才能充分理解用户的需求，得出对目标系统的 完整、准确和具体的要求。
为了更好地理解问题，人们常常采用建立模型的 方法。所谓模型，就是为了理解事物而对事物做出的
一种抽象，是对事物的一种无歧义的书面描述。通常，
当需要调查大量人员的意见时，向被调查的人员 分发调查表是一个十分有效的做法。 在对用户进行访谈的过程中使用情景分析技术往
往非常有效。所谓情景分析就是对用户运用目标系统
解决某个具体问题的方法和结果进行分析。
3.2.2 简易的应用规格说明技术
这种方法提倡用户与开发者密切合作，共同标识 问题，提出解决方案的要素，商讨不同的方法并指定 基本的需求。今天，简易的应用规格说明技术已经成 为信息系统界使用的主流技术。
图3.2 某校教学管理 ER 图
3.5 数据流图
当信息在软件中移动时，它将被一系列“变换” 所修改。数据流图(DFD)是一种图形化技术，它描绘信 息流和数据从输入移动到输出的过程中所经受的变换。
3.5.1 数据流图符号 如图3.3(a)所示，数据流图有四种基本符号：正 方形(或立方体)表示数据的源点或终点；圆角矩形(或 圆形)代表变换数据的处理；开口矩形(或两条平行横 线)代表数据存储；箭头表示数据流，即特定数据的流 动方向。注意，数据流与程序流程图中用箭头表示的 控制流有本质不同，千万不要混淆。
否列出了所有给定的数据源点/终点是一目了然的，因
此它是很有价值的通信工具。
下一步应该把基本系统模型细化，描绘系统的主
要功能。 在图3.5中给处理和数据存储都加了编号，这样做 的目的是便于引用和追踪。 接下来应该对功能级数据流图中描绘的系统主要 功能进一步细化。 当对数据流图分层细化时必须保持信息连续性， 也就是说，当把一个处理分解为一系列处理时，分解 前和分解后的输入/输出数据流必须相同。
(Structured Analysis ,SA)技术完成需求分析工作。
退出
3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8
概述 与用户通信的技术 分析建模与规格说明 实体—关系图 数据流图 状态转换图 数据字典 小结
3.1 概述
需求分析是发现、求精、建模、规格说明和复审
的过程。为了发现用户的真正需求，首先应该从宏观 角度调查、分析用户所面临的问题，也就是说，需求
C .控制描述 1 .控制规格说明 2 .设计约束〖ZK)〗 Ⅳ.行为描述 A .系统状态 B .事件和动作 Ⅴ.确认标准 A .性能范围 B .测试种类 C .预期的软件响应 D .特殊考虑 Ⅵ.参考书目 Ⅶ.附录
3.4 实体—关系图
数据模型包含三种相互关联的信息：数据对象、 描述数据对象的属性及数据对象彼此间相互连接的关
而不是仅仅反映它的某些成分。
· 不要使用空洞的、缺乏具体含义的名字(如“数 据”、“信息”、“输入”之类)。 · 如果在为某个数据流(或数据存储)起名字时遇 到了困难，则很可能是因为对数据流图分解不恰当造 成的，应该试试重新分解，看是否能克服这个困难。
2为处理命名 · 通常先为数据流命名，然后再为与之相关联的 处理命名。这样命名比较容易，而且体现了人类习惯 的“由表及里”的思考过程。 · 名字应该反映整个处理的功能，而不是它的一 部分功能。 · 名字最好由一个具体的及物动词，加上一个具 体的宾语组成。应该尽量避免使用“加工”、“处理” 等空洞笼统的动词作名字。 · 通常名字中仅包括一个动词，如果必须用两个 动词才能描述整个处理的功能，则把这个处理再分解 成两个处理可能更恰当些。 · 如果在为某个处理命名时遇到困难，则很可能 是发现了分解不当的迹象，应考虑重新分解。
· 必须理解和表示问题的信息域，根据这条准则 应该建立数据模型。 · 必须定义软件应完成的功能，这条准则要求建 立功能模型。 · 必须表示作为外部事件结果的软件行为，这条 准则要求建立行为模型。
· 必须对描述信息、功能和行为的模型进行分解， 用层次的方式展示细节。
· 分析过程应该从要素信息移向实现细节。
பைடு நூலகம்
从问题描述中提取数据流图的四种成分。 · 接下来考虑处理 · 最后，考虑数据流和数据存储
表3.1总结了上面分析的结果，其中加星号标记的
是在问题描述中隐含的成分。
表 3.1 组成数据流图的元素可以从描述问题的信息中提取 源点/终点 处理 采购员 产生报表 仓库管理员 处理事务 数据流 数据存储 定货报表 定货信息 零件编号 (见定货报表) 零件名称 库存清单 定货数量 零件编号* 目前价格 库存量 主要供应者 库存量临界值 次要供应者 事务 零件编号* 事务类型 数量*
数据对象彼此之间相互连接的方式称为关系，也
(2) 一对多联系(1∶N)
(3) 多对多联系(M∶N) 联系也可能有属性。
3.4.4 实体—关系图的符号 通常，使用实体—关系图(EntityRelationship Diagram)来建立数据模型，从而可以满足31节中讲 述的第一条分析准则。可以把实体—关系图简称为ER图， 相应地，用ER图描绘的数据模型也可以称为ER模型。 ER图中包含了实体(即数据对象)、关系和属性等 三种基本成分，通常用矩形框代表实体，用连接相关 实体的菱形框表示关系，用椭圆形或圆角矩形表示实 体(或关系)的属性，并用无向边把实体(或关系)与其 属性连接起来。例如，图3.2是某学校教学管理的ER图。