需求工程-软件建模与分析

1问题分析的主要步骤(五步)?

(1)在问题定义上达成共识；

(2)理解根本原因，分析问题背后的问题；

(3)确定相关人员和用户；

(4)定义解决方案的界限；

(5)确定加在解决方案上的约束。

2鱼骨图主要用于定性分析，帕累托图主要用于定量分析。

3鱼膏图、帕累托图构爱的主要步骤？

鱼骨图

A选择问题

首先选择一个具体的问题或者结果。在选择问题时，要保

证问题是专门的、定义严谨的、范围相对较小的(对于大范围

的问题往往需要考虑将其分解成相对较小的问题)，并且保证

参与人员切实理解要分析的内容。对问题定义产生出来的问题

一般都应该进行一次独立的鱼骨图分析。

B头脑风暴

就导致问题的可能原因进行头脑风暴。将大家提出的意

见记录下来，确认后贴到鱼骨图上。

需要注意的是不要将原因和解决方案混为一谈。在确定

原因的分类前先进行头脑风暴(一个人提，大家批)，不然

思考问题的范围就会受到限制。支持者需要引导和鼓励参与

者参与其中。

C确定问题类型

对头脑风暴的结果进行整理，确定出主要的原因类型。

一般来说，划分出来的问题不要少于2类，不要超过6类

(经验数值，仅供参考)。经常使用的类型有：人、设备、

材料、环境、方法、过程等.将这些类型补充到鱼骨图上。

D分配原因

将头脑风暴中得出的潜在原因放在鱼骨图上，并且确保每

一项原因都归于适当的类别中。如果原因看起来可以放在多个

类别中，就表示是多重原因造成的问题。但如果多次出现多重

原因，可能就以为着分类存在问题。该阶段将形成最终的鱼骨图

E分析根本原因

对鱼骨图中罗列出来的所有潜在原因进行分析。分析出

造成某一结果的最根本原因是什么？找出核心所在。

方法如下：

通过参与者之间的公开讨论来分享看法和经验；

寻找重复的原因，或者与特定类有关的原因的数量；

使用检查表收集资料、制造流程图或者进行用户调查，

通过帕累托分析法测就各种原因的相对强度；

投票(真理多数情况下掌握在多数人手里)

帕累托图

在通过使用鱼骨图完成问题原因的定性描述后。仍然存在一个

问题，就是根本原因的辨识需要有经验的决策者确定，或者根

据人类固有经验（少数服从多数）确定。更好地方法是能够开

展定量分析。帕累托分析可以帮助我们做出这样的定量分析。

帕累托分析应用就是根据鱼骨图分析的结果，通过收集相关统计

资料，通过直方图的方式显示问题的相对频度或者大小高低等定

量结果。

A确定问题和相关原因

利用鱼骨图的结果。

B收集数据

有针对性第收集数据。例如上例中，我们可以抽取一些

废品，分析这些废品产生的原因

C绘制直方图

4上下文图画法步骤？

在绘制上下文关系图时应该采用以下步骤：

1、首先用一个矩形表示系统，写上系统的名称，将整个系统看做一个黑盒子；

2、然后找到该系统的所有Customer（客户），考虑这些Customer会发起什么事件，这些事件会引

发Worker（内部工作人员）的什么工作，将这些序列逐一表示出来；

3、最后在看看系统的每个Worker还有没有一些主动发起的事件。

（Customer：也就是该主题域的客户，它处于该主题域的外部.如，对于体检业务子系统而言，体检者显然就是

一类客户，除此之外，客服中心、物资部门、财务部门的工作人员也是这个主题域的Customer。

Worker：也就是该主题域的工作人员，它处于该主题域的内部。如，服务中心，体检科室，综合科的工作人员

都是其Worker。关键要点在于“针对本主题域”而言。）

5需求获取的主要活动

研究应用背景，建立初始的知识框架；

根据获取的需要，采用必要的获取方法和技巧；

先行确定获取的内容和主题，设定场景；

分析用户的高（深）层目标，理解用户的意图；

进行涉众分析，针对涉众的特点开展工作。

6需求协商的几条法则的应用？

差异问题协调法则：

不同的业务层面（有时即使是相同业务层面）的用户对同样的概念或者流程

有不同的认识和理解，会出现一些差异，在需求整理时应该将这些差异明确

标识出来，并展示给用户高层管理人员，由他们来确定如何消除这些差异，

并将这些情况记录。

消除变更问题协调法则：

上面法则提到的问题，从消除变更的角度考虑仍然存在问题。仅仅将差异标

识并展示给高层并不能消除变更的可能，应该考虑这些差异形成背后的问题，

应该从开发角度考虑如何消除这些差异，并提供给高层管理人员。要有主动性

需求协商时机法则：

不要在需求冻结前开展需求办商工作。需求协商应该在

需求获取过程中不断开展，出现就考虑消除。如果都等到冻结前，将所有矛

盾集中体现对工作是非常不利的。

实例：

W公司开发的信息系统到了需求冻结前夕，A建立拿出厚厚一本需求

协商底稿，分为重点差异协调部分，一般差异协调部分，已协调差异列表。

结果用户高层非常不满，认为这些工作需要大量时间难以短期完成。

7需求获取的主要方法

用户访谈

用户调查

文档分析

原型法（情节串联板）

模型驱动的方法

8开放式话题与封闭式话题运用

开放式话题

优点：

-让被会见者感到自在；

-会见者可以收集被会见者使用的词汇，这能反应他的教育、价值标准、杰度和信

念；

-提供丰富的细节；

-对没采用的进一步的提问有启迪作用；

-让被会见者更感兴趣；

-容许更多的自发性；

-会见者可以在没有太多准备的情况下进行面谈。

缺点：

-提此类问题可能会产生太多不相干的细节；

-面谈可能失控；

-开放式的回答会花费大量的时间才能获得有用的信息量；

-可能会使会见者看上去没有准备

封闭式话题

♦：♦优点：

-节省时间；

-切中要点；

-保持对面谈的控制；

-快速探讨大范围问题；

-得到贴切的数据

♦：♦缺点：

-使得被会见者厌烦；

-得不到丰富的细节；

-出于上述原因，失去主要思想；

-不能建立和面谈者的友好关系。

9用户访淡时问题组织的三种方式及特点？

金字塔结构

♦：♦如果会见者认为被会见者需要对话题进行预热，可以采用金字塔结构，通过逐步的引导

来使得被会见者打开话匣子。

如果会见者发现自己事先对事实的确认存在较大偏差或者被会见者看上去不情愿讨论这

个话题，也可以采用金字塔结构。

当想结束讨论这个话题的时候，使用金字塔结构的提问顺序也是有用的。

漏斗结构

。漏斗结构为开始一场面谈提供了一种容易而轻松的途径。

当被会见者对这个话题有情绪，并且需要自由表达这些情绪的时候，需要采用漏斗型提

问顺序。

或者在会见者事先对事实了解不多时，也应该采用漏斗结构的问题组织方式。

用这种方式组织面谈能得出很多的详细信息，以至于没有必要使用长序列的受限制问题

和调查问题。

菱形结构

使用菱形结构的主要优点是通过各种各样的问题保持被会见者的兴趣和注意力。一旦掌

握了如何在正确的时间问正确的问题，就可以多样地选择问题的顺序。

10市场调查和需求获取在访夜与调查顺序上有何不同？原因何在？

一般来说，在开展市场调查时，由于很难深入接触到潜在的用户。所以

总是先调查，后访谈。而在需求获取时，通常采用的策略是先访谈，后调查。

其实原因在于市场调查与需求获取有不同的应用背景C一般市场调查通常

用于验证潜在客户对产品的接受程度。而需求获取的目标是要理解客户需要解

决的问题。

也就是说需求获取时你往往还没有产品，信息不够充分，所以很难设计出

有效的调查问卷。

11采用原型方法的三个目的？

明确并完善需求

原型作为一种需求工具，它是对部分系统的初步实现，因为我们尚没有很好地了解该系统。

研究设计选择方案

原型作为一种设计工具，涉众可以用它研究不同的用户交互技术，优化系统易用性，并评估

可能的技术方案。

发展为最终产品

原型作为一种构造工具，是产品一个最初子集的完整功能实现。

12用例描述方法

13需求关系的根本任务是什么？

需求分析是软件需求中最核心的工作，需求建模是需求分析

的主要手段。

需求分析是软件定义时期的最后一个阶段，它的基本任务是

准确地回答“系统必须做什么?”这个问题。

需求分析的任务还不是确定系统怎样完成它的工作，而仅仅是确定系统必须完成哪些

工作，也就是对目标系统提出完整、准确、清晰、具体的要求。

需求分析根本任务：建立分析模型，创建解决方案。

14需求分析任务中分解策略主要包含那几种？每种策略分别迨合应用于

砰些系统的开发

1）业务流程为主线的分解策略；

业务流程为主线的分解策略是目前比较流行的方法，主要按照

“业务”的角度考虑分解方法。此方法特别适合联机事务处理系

统、管理信息系统（MIS）。

目标系统一》主题域的分解依据是“目标决定范围”；

主题域-》业务事件所做的是理清业务脉络；

业务事件-》业务活动所做的是填充细节；

业务活动-》处务步骤所做的是细化和确认工作。

2）程序结构为主线的分解策略；

方法是需求分析最常用的分解方法。当由于其过早进入程序结

构，割裂了与问题域之恒的联系，从而容易导致对问题域研究的

不足，降低了需求的质量。目前认为此种方法仅适合于问题域比

较清晰，问题不算复杂的情况,例如工具软件、嵌入式系统等。

3）基于场景的分解策略；

对于决策支持系统、面向用户的嵌入式系统等来说,决策场景、

使用场景是主要的线索。向上可以总结成一类相似的集合，再

总结成一系列的关注点或者功能域，向下可以分解成具体的步骤

或者操作任务。

4）基于数据的分解策略等。

上述分解策略都是从“业务”角度来组织。但对于类似数据仓库

之类的数据类项目,业务线索并不是十分明显，或者并不重要

这是就需要以数据为主的分解策略。其中主题域仍然与“业务

流程为主的分解策略”类似。而主题类是企业中的高层实体，

主要由一组企业的逻辑数据类来表示，而企业的逻辑数据类在

实现时又会对应于多个物理数据类。

15需求分析中分解与提炼的比较？

分解是一种自顶向下的方法，当按照任何一种线索进行分解时。就会破坏其它线索的完整性。例

如，如果以“业务”为线索，就会发现数据需求分解后会出现相互交叠的情况，也就是在多个业

务事件中都涉及相同的类。

此种情况出现时，可能会影响需求分析人员建立全面的理解，因此需要采用自底向上

的方法进行提炼。例如将每个业务事件中的类进行提炼，抽取出共性的部分，建立针对整个系统

的全局领域模型。

16构建分析横型的目的？

1将复杂的系统分解成为简单的部分以及它们之间的联系，确定本质特征

2和用户达成对信息内容的共同理解

3分析的活动主要包括识别、定义和结构化，它的目的是获取某个可以转换为知识的事物的信

息

17分析模型的建模方决？

模型

“模型是对事物的抽象，帮助人们在创建一个事物之前可以有更好的理解”

-集中关注问题的计算特性(数据、功能、规则等等)

“它是对系统进行思考和推理的一种方式。建模的目标是建立系统的一个表示，

这个表示以精确一致的方式描述系统，使得系统的使用更加容易”

-建模方法

,抽象

•分解

•投影

♦抽象(Abstraction)

-一方面要求人们只关注重要的信息，忽略次要的内容

•通过强调本质的特征，就减少了问题的复杂性(例如学生模型)

-另一方面也更求人们将认知保留在适当的层次，屏蔽更深层次的细节

•在问题的各元素之间推断出更广泛和更普遍的关系，帮助人们寻找解决方

案

♦：♦分解(Decomposition/Partitioning)

-“分而治之”

•将单个复杂和难以理解的问题分解成多个相对更容易的子问题，并掌握各

子问题之间的联系

-分解的方案往往还能提供问题的解决思路

❖投影(Projection)

-多视点方法

18实际的建模过程中要遵循的建模原则？

在建模时，要注意考虑到计划之外的变化：设计要文档化，只有这样，才能使不熟悉的新手也可

以有效地利用设计的方案。用可视化的模型表达现实世界，有助于理解变化所代表的含义。

在实际的建模过程中要遵循以下建模原则：

­模型是用来沟通的；

•选择创建什么模型对如何解决问题和如何形成解决方案具有深远的影响。

•每种模型可以在不同的精度级别上表示；

•最好的模型是与现实相联系的模型；

•单个模型往往不够充分，对每个重要的系统最好用一组几乎独立的模型去处理。

19需求建模的流程？

先依据获取的问题域信息建立初步的模型。

然后分析用户需求，对模型进行调整，得到一个中间形式的模型形式。

最后，对调整后的模型进行逻辑推理和验证，如果符合预期的期望，那么它就是最终的解决

方案模型。

20常见的需求分析技术?

结构化技术

-数据建模

实体关系图EntityRelationshipDiagram

-过程建模

数据流图DataFlowDiagram

上下文图ContextDiagram

微规格说明Mini-Specification

•数据字典DataDictionary

-行为建模

•状杰(转换)图/矩阵State(Transition)Diagram/Matrix

-过程/数据关系建模

•功能实体矩阵Functicn/Entit.yMatrix

-信息工程方法

功能分解图FunctionDecompositionDiagram

过程依赖图ProcessDependencyDiagram

♦面向对象技术

-UML

,用例图Use-CaseDiagram

•类图ClassDiagram

•交互图(顺序图/通信图)Interaction(Sequence/Communication)

Diagram

,活动图ActivityDiagram

•对象约束语言ObjectConstraintLanguage

,状杰图StateChartDiagram

21正确认识UML(2)(3)(4)

(2)UML的准确理解

UML是一种语言(Language)

实际上UML就是一种表示方法，它不是方法论。

UML是一种建模语言(ModelingLanguage)

它不是编程语言，而是建模语言。它不仅包含软件建模，而且可用于业务建模、流程建模等

多种领域。

UML是统一爱模语言(UnifiedModelingLanguage)

它是一种标准化的、统一的建模语言，0MG认可的工业标准，也是如IBM、SUN等大型公司认

可的事实标准。

(3)为什么要使用UML

UML是一种统一的、标准化的建模语言，它为参与软件设计和开发的各类人员提供统一的语言,

使开发人员能够基于共的模型来理解业务、需求，理解软件及其架构如何构造的。

(4)如何使用UML

UML2.0标准中，共定义了13种不同的图，这些图的功能以及与UMLL0之间的关系如下表

图名功能备注

类图描述类、类特性及类间关系UMLL0原有

对象图描述一个时间点上系统各个对象的一个快照UMLL0非正式图

复合结构图描述类的运行时刻的分解UML2.0新增

构件图描述构件的结构和连接UMLLO原有

部署图描述在各个节点上的部署UMLLO原有

包图描述编译时的层次结构UMLLO非正式图

用例图描述用户与系统如何交互UMLLO原有

活动图描述过程行为与并行行为UMLLO原有

状态图描述事件如何改变对象生命周期UML1.0原有

顺序图描述对象之间的交互、重点在于强调顺序UML1.0原有

通信图描述对象之间的交互、重点在于连接UML1.0中的协作图

定时图描述对象之间的交互、重点在于定时UML2.0新增

交互概观图是一种顺序图与活动图的混合UML2.0新增

如何使用UML-需求阶段一般常采用的图

使用频率图名功能

主体用例图说明角色和使用场景之间的关系

活动图说明业务流程，以及业务活动的步骤

顺序图描述对象之间的交互

类图说明业务实体之间的关系，体现结构规则

辅助构件图说明主题域划分以及他们之间的服务接口

部署图描述系统的部署环境，体现设计约束

22结构化分析遵循的三条原则？

结构化分析遵循的三条基本原则：

分解

抽象

映射

23结构化分析模型的构成元素？

♦：♦数据字典(DD)

-模型核心，包含了所有数据对象的描述的中心库。

♦：♦E-R图(ERD)

-表示数据对象以及相互的关系，用于数据建模。

♦数据流图(DFD)

指明数据在系统中移动时如何被变换；

-描述对数据流进行变换的功能；

DFD中每个功能的描述包含在加工规约(小说明)。

-用于功能建模。

♦状态变迁困(STD)

-指明作为外部事件的结果，系统将如何动作。用于行为建模。

24结构化京模示例-建立计算机售书东统的近韩模型

(1)通过对现实环境的调查，获得当前系统的物理模型。

-9堡

(2)去掉具体模型中的非本质因素：

-抽取现实系统的实质，抽象出当前系统的逻辑模型。

.…，♦・-a3♦XM・«

(3)分析当前系统与目标系统的差别,建立目标系统的逻辑模型。

(4)对目标系统的逻辑模型进行细化、改进与优化

(5)需求分析的验证

25数据流图CDFDJ第9章PPT第20-69页

♦：♦数据流图（DFD：DataFlowDiagram）就是组织中信息运动的抽象，是信息逻辑系统模

型的主要形式。这个模型不涉及硬件、软件、数据结构与文件组织，它与对系统的物理

描述无关，只是用一种图形及与此相关的注释来表示系统的逻辑功能，即所开发的系统

在信息处理方面要做什么。

由于图形描述简明、清晰，不涉及到技术细节，所描述的内容是面向用户的，所以即使

完全不懂信息技术用用户单位的人员也容易理解。因此数据流图是系统分析人员与用户

之间进行交流的有效手段，也是系统设计（即建立所开发的系统的物理模型）的主要依

据之一。

数据流图脱离系统中的物理因素（如计算机等），表达出系统对信息的加工情况。DFD可以

描述原系统/新系统/子系统。

❖DFD是SA的主要工具，它简单、直观，用图形、文字描述系统。它便于使用、便于交流、

便于讨论、便于形成共识，是计算机专业人员和用户单位业务人员的共同语言。

DFD由四种基本符号组成。如下图所示。

匚□□一

外部项（S）,也据加工（P）数娓存健（D）数据濠（F）

A•.

数据流图的构成及基本元素

（1）外部项（外部实体）

源点和终点（又称端点）是系统外的实体，称作外部项。它们存在于环境之中，与系统

有信息交流，从源点到系统的信息叫系统的输入；从系统到终点的信息称系统的输出。

同一个端点可以是人或其它系统。在DFD中引入源点和终点是为了便于理解系统，所

以不需要详细描述它们。它们可有编号，以“S”开头。

♦：♦外部实体

-外部实体是指处于待构建系统之外的人、组织、设备或者其他软件系统，

它们不受系统的控制，开发者不能以任何方式操纵它们。

-需要进行建模的外部实体是那些和待构建的软件系统之间存在着数据交

互的外部实体，它们是待构建系统的数据源或者数据目的地

-所有的外部实体联合起来构成了软件系统的外部上下文环境

引入外部项是为了划定系统的边界，不需严格定义。但也要统一编号，而且要

与数据字典中的编号相一致。源点和终点可以在多处出现，用特定符号表示重复的外

部项。

为了使DFD清楚易懂，我们对加工、数据流、文件的命名都力求简单。至于加

工的加工逻辑、数据流的数据结构等，将在数据字典中定义。数据字典和DFD一起来

描述系统。

常见的外部项（外部实体）有：

a)从待构建系统中获取数据或者为其提供数据的组织，如：供货方，销售方等。

b)需要和待构建系统交互的个人，如：顾客，办事员。

c)需要和待构建系统交换数据的其他软件系统。

(2)加工

❖加工又称处理亦称变换，它表示对数据流的操作。

加工的符号分成上、下两部分，从上到下分别是标识部分和功能描述部分。

♦标识部分用于标注加工编号，加工编号应具有唯一性，以标识加工，以“P”开头。

。功能描述部分月来写加工名。为使DFD清晰易读，加工名应简单，能概括地说明对

数据的加工行为，其详细描述在数据词典中定义。

加工要逐层分解，以求得分解后的加工功能简单、易于理解.

(3)数据流

数据流由一个或一组确定的数据项组成。

数据流名应能直观地反映数据流的含义。如产量日报表、汇款单、录取通知书、课程表

等。也可以用一组数据中的主要数据为数据流命名。例如“考生成绩单''由考生姓名、成

绩、通讯地址等数据组成，但成绩是主要的，所以可用“考生成绩”作为数据流的名字。

数据流应统一编号，编号要与数据字典一致。

数据流经过一个加工后其数据结构/数据含义/数据的顺序一定要有所变化，否则这个加

工就没有意义了。

(4)数据存储(文件)

数据存储是用来存贮数据的。在分层DFD中，数据存储一般仅属于某一层或某几层，因

此又称数据存储为局部文件。现对数据存储符号说明如下：

①数据存储名写在开口的长方框内，应概要地说明文件中的主要数据。

②数据存储上一定要有数据流。

③为便于说明和管理，数据存储亦应编号，编号写在文件符号左端小方格中，以“D”开

头。

♦④为避免DFD中出现交叉线，同一数据存储可在多处画出。

数据流图的绘制步骤

❖<1)确定所开发的系统的外部项(外部实体)，即系统的数据来源和去找。

(2)确定整个系统的输出数据流和输入数据流，把系统作为一个加工环节，画出关联图。

(3)确定系统的主要信息处理功能，按此将整个系统分解成几个加工环节(子系统)确

定每个加工的输出与输入数据流以及与这些加工有关的数据存储。

❖(4)根据自顶向下，逐层分解的原则，对上层图中全部或部分加工环节进行分解。

♦(5)重复步骤(4),直到逐层分解结束。

(6)对图进行检查和合理布局，主要检查分解是否恰当、彻底，DFD中各层是否有遗漏、

重复、冲突之处，各层DFD及同层DFD之间关系是否合理，及命名、编号是否确切、合

理等，对错误与不当之处进行修改。

(7)和用户进行交流，在用户完全理解数据图的内容的基础上征求用户的意见。

数据流图绘制规则

(1)过程是对数据的处理，必须有输入，也必须有输出，而且输入数据集和输出数据集应

该存在差异。

(2)数据流是必须和过程产生关联的，它要么是过程的数据输入，要么是过程的数据输出。

阳兽勰暹眯x

I—I~~<□HHZZI

O~~£□LZF——-EK

♦一、

II----TIII~~HI

口---dIII—

(3)DFD当中所有的对象都应该有一个可以唯一标识自己的名称。

-过程使用动词

-外部实体、数据流和数据存储使用名词

数据流图绘制过程

绘制数据流图的主要原则

❖(1)明确系统边界。

♦：♦(2)自顶向下逐层扩展。

❖(3)合理布局。

❖(4)数据流图绘制过程，就是系统的逻辑模型的形成过程，必须始终与用户

密切接触，详细讨论，不断修改，也要和其他系统建设者共同商讨一求一致意

见。

数据流图应用示例-银行取款系统

简单银行取款应用描述

(1)储户将填好的取款单、存折交银行，银行做如下处理：

①审核并查对帐目，将不合格的存折、取款单退回储户，合格的存折、取款单送取款处理。

②处理取款修改帐目，将存折、利息单、结算清单及现金交储户，同时将取款单存档。

画出银行取款处理数据流图。

第一步，画出关联数据流图.注意，现金是实物，不能作为数据流。

第二步，逐层分解加工，画出下层DFD。

ra.i**we

电数♦

,1不会格行苑J

数据流图应用示例-图书预定系统

图书预订系统：书店向顾客发放订单，顾客将所填订单交由系统处理，系统首先依据图书目录对

订单进行检查并对合格订单进行处理，处理过程中根据顾客情况和订单数目将订单分为优先订单

与正常订单两种，随时处理优先订单，定期处理正常订单。最后系统根据历处理的订单汇总，并

按出版社要求发给出版社。

画出图书预定系统的各层数据流图。

♦：♦第一步，画出关联数据流图。

nGB书项订羽统关BXflD

❖第二步，逐层分解加工，画出下层DFD。注意到根据题意，当绘出系统顶层图后并不能将

所有加工分解成基本加工，还要进行二层图分解。并在分解加工过程中逐步充实进数据

存储。见图。

*»nitmu♦

数据流图的作用

♦：♦前面说过，系统分析的主要任务是建立新系统的逻辑模型。具体地讲主要是画出新系统

的DFD,编写定义DFD的数据词典。

♦建立新系统的DFD是一项十分重要的工作。因为建立的DFD是系统开发乃至系统维护的

依据，是系统的重要文档之一。系统分析员要在详细调查中，在与用户的反复交流中修

改DFD,力求新建DFD是正确的、准确的。

DFD的层级结构

♦：♦依据所含过程的不同抽象程度，DFD可以在不同的抽象层次上进行系统的描述

一个比较抽象的过程可以被展开为一个子过程更加具体的DFD图

DFD的层次结构

-上下文图

-。层图

-N层图（N>0）

关于上下文图

-将整个系统看做是一个过程，这个过程实现系统的所有功能，是系统功能的最高抽象

•上下文图中存在且仅存在一个过程，表示整个系统。这个单一的过程通常编号为0

♦上下文图中需要表示出所有和系统交互的外部实体，并描述交互的数据流，包括系统

输入和系统输出

•上下文图中不会出现数据存储实例

-它非常适合于描述系统的应用环境、定义系统的边界

关于0层图

位于上下文图下面一层，是上下文图中单一过程的细节描述，是对该单一过程的第一次

功能分解

-是整个系统的功能概图

0层图应该被描述的简洁、清晰，需求工程师要根据系统的复杂度掌握0层图中过程的

抽象程度

关于N层图

-对。层图的过程分解产生的子图称为1层图，对N层图的过程分解后产生的子图称为N+1

层图（N>0）,过程分解是可以持续进行的，直至最终产生的子图都是原始DFD图

-原始DFD图可以进一步展开为

•微规格说明

•数据字典

-在低于0层图的子图上通常不显示外部实体

层次结构的构建

建立步骤

1.创建上下文图

2.发现并球立DFD片新

3.根据DFD片断组合产生0层图；

4.对0层图的过程进行功能分解，产生N层图

创建上下文图

在需求获取阶段获得的业务需求以及业务需求所决定的项目前景与范围可以用来帮助建立系

统的上下文图。

发现并建立DFD片段

DFD片断是系统对某个事件的响应过程的DFD描述，它是为系统中发生的重要事件创建的。

它将系统对事件的处理看做是一个单一的过程，重点描述这个单一过程与事件外界（包

括系统内其他部分和系统外的外部实体）的数据流交互。

产生0层图

往往需要多次调整DFD片段的整合结果才能得出

♦对DFD图（尤其是0层图）质量的判定有下面几个准则：

-1、没有语法错误，遵守前述的各项规则。

-2、具有良好的语义，过程的功能设置要高内聚、低耦合。

-3、保持数据一致性，过程的输入流要足以产生数据输出。同时过程的输出流是在

充分利用输入数据的基础上产生的，不存在输入数据的浪费。

-4、控制复杂度，不要一次在图中显示太多的信息。一般情况下，一个图中的过程

数量最好控制在5〜9（人脑的最佳信息处理量）个。而且图中的数据流数量越少

越好，越简洁越好（接口最小化）。

功能分解产生N层图

♦功能分解是一个拆分功能的描述，将单个复杂的过程变为多个更加具体、更加精确和更

加细节的过程。

在功能分解过程当中，最重要的是要保证分解过程的平衡性（Balance）,它要求DFD

子图的输入流、输出流必须和父过程的输入流、输出流保持一致。

在分解产生的子图为下述情景之一时，可以判定其为原始DFD图，此时应该停止持续的

功能分解活动：

-所有过程都已经被简化为一个选择、计算或者数据库操作；

-所有数据存储都仅仅表示了一个单独的数据实体；

-用户已经不关心比子图更为细节的内容，或者子图的描述已经详细的足以支持后续

的开发活动；

-每一个数据流都已经不需要进行更详细的切分，以展示对不同数据的不同处理方式；

-每一个业务表跑、事务、计算机的屏幕显示(computeron-linedisplay)和业务

报表都巳经被表示为一个单独的数据流；

-系统的每一个最低层菜单选项都能在子图中找到独立的过程。

层次结构的建立一示例

使用DFD描述常见的电梯控制系统。

-一个控制系统控制多个电梯。每个电梯被置于一个相应甬道之中，在卷扬电机的作

用下在甬道内做上下运动。甬道内安装有多个传感器，通常每个电梯停靠点一个，

用来感应电梯的实时位置。电梯内部和建筑的每个电梯停靠层都设置有指示器，用

来告知用户的电梯实时位置和运动状况。电梯内和建筑的每个电梯停靠层都设有按

包.用户可以通过这些按钮提出服务申请并进出电梯。控制系统调度用户的申请.

让电梯以最有效的方式满足用户的服务要求。

业芬需求实现业务需求需要的系统特桂局部解决方案的时外交互

SFI.1:能缈获知电梯位置感应,并科交恰指外部轮入：感应)5那知信号

示修外部榆出：指示器笺求信号

SF1.2:能够控制春扬电机，实现般务请求的内部输入：词度要求

BR1：让电梯运转起来

电樽运动外郁输出：卷用电机控制信号

SFL3:闲户可以利用按钮发出服务请求外部输入：按钮信号

内部输出：服务请求

BR2:实现电梯的疗效词SF2.1:系统从厦务请求队列中建立高效率的内都输入：服芬请求

尺.最大限度的服芬用户内部输出：诩度夏求

BR3:保证安全.尤其#•用SF3.1:系统国根据电梯的冰动软况和期务申内部检入：服务请求.电幡状况

户出入电样的安全清控制电桶门的开关外部输出：门控命令

门控信号

二4

012-25.电梯控制系统的上下文图

层次结构的建立--建立DFD片断

事件东统的响应

系统ft•先襄记录请求，以备弼度.如果请求时电梯处于运动状态，

闲户利厢按钮发出服芬请求

则系统需亶重新执行请求谓度,并在需要的情况下更改运动目标.

系统察科电梯状态,如果处于静止状态且处于目前楼层.则发出门

闲户利厢按钮发出开关门请求

控命■令,否则不予处理.

呼应JS信号发生变化系统要根据新的信号更新电怫状态，并通如指示器改变显示.

电桶开始运动，印门已关闭，开始运系统要改变电棒状态为运动状态,然后根据等待的服务请求谓度确

动定电梯的运动目标，结合电棒目的位置，控制粗场电机开始工作.

系统更新电梯状态为静止状态以停止对新增请求的处理，去除已先

电梯伸•止•印电样已绘到处日标位置

成的请求，然后控制费抵电机停止运动，并在停止后.开启业禅门

K12-8.电梯控制系统的外部事件及其响应

层次结构的建立-一

建立0层图

012-27,电梯控制系统的初始。层图

运动目标

图12・28.电梯控制系统的最终。层图

DFD验证

♦验证DFD的语法

-确保DFD中不会发生语法错误

❖睑证DFD的结构

-验证DFD层次结构之间的一致性

-验证DFD层次结构说明的完备性

♦：♦验证DFD的语义

-确保DFD所说明内容的正确性和准确性

26数据字典

数据字典的提出背景：

虽然数据流图能够形象、清晰地描述数据在系统中流动、加工、存储的情况，但数据流图中

的许多构成元素，如数据流、数据存储、加工，仅依靠名称并不能反映其本质含义，因此必须对

这些构成元素进行严格的定义。作为对数据流图的补充，数据字典(DD,DataDictionary)能够

准确地定义数据流图中各组成成分的具体含义，二者共同构成了系统的逻辑模型。

♦数据字典是一个储存库，包含软件使用和产生的所有数据对象的描述，其中也包括DFD当

中数据流和数据存储的定义。

有组织地列出DFD中的涉及的所有数据元素(数据流、数据存储)，并定义每个数据元素的

-名称

-别名

-使用地点

-使用方法

-使用范围

-描述

单位/格式

名称数据元素的原始名称

别名数据元素的其他名称

使用地点会使用该数据元素的过程

使用方法该数据元素扮演的角色（输入流、输出流或者数据存储等）

使用范围该数据元素存在的范围

描述对数据元素内容的描述

单位/格式数据元素的数据类型，可能事先设置的取值

数据字典中的基本元素和含义

*X■5

■我示比又为・于时•金通的暴日遗行的定£

■女与美・、-,mAXlhaWbMRMllft

111■帆.我水'前■或MRtft

1•1

(>•不可、ralt示•可以生、中出现.以不*现

II■用・・大彩次

■H表不爆定次效力・现■复的次・依少•考・次

■■小v

-逢・希■MM07.IZ我奉aMmf”中的保・・

••K•为”・信・

符号含义示例

=包含，由…构成

Name=first_name+last_name

+指明序列结构

0内容可选Phone_No.=(Area_No.)+Local_No.

[]内容多选一

Number=[0|l|2|3|4|5|6|7|8|9]

1分割口内部的多个选项

n{}m循环,最少n次，最多m次Area_No=3{Number)4

@数据存储的标识符(关键字)Student二@ID+Name+...

*♦注释Area_No=3{Number}4**区号为3到4位数字

数据字典中的条目及说明格式

数据字典是关于数据流图中各种成分详细定义的信息集合，可将其按照说明对象的类型划分

为四类条目，分别为数据流条目、数据项条目、数据文件条目和数据加工条目。

数据字典的任务是：对于数据流图中出现的所有被命名的图形元素在字典中作为一个词条

加以定义，使得每一个图形元素的名字都有一个确切的解释。

(1)数据流条目

数据流在数据流图中主要用于说明数据结构在系统中的作用和流动方向，因此数据流也被称

作“流动的数据结构“。数据字典中数据流条目应包括以下几项主要内容：数据流名称、数据流

别名、说明、数据流来源、数据流流向、数据流组成和数据流量等。

数据流词条的描述示例1:

数据流名：发票

说明：用作学生已付书款的依据

数据流来源：来自加工“审查并开发票”

数据流去向：流向加工“开领书单”。

数据流组成：学号+姓名+书号+单价总价+书费合计

数据

工资系统中的出勤表数据流在数据字典中的条目描述为：

数据流名称：出勤表

数据流别名：无

说明：由人事部门每月月底上报的职工考勤统计数字

数据流来源：人事部门

数据流流向：加工Li.i(统计出勤、请假及旷工时数)

数据流组成：出勤表=年份+月份+职工号+出勤时数+病假时数+事假时数+旷工时数

数据流量：1份/月

(2)数据项条目

数据流图中每个数据结构都是由若干个数据项构成的，数据项是加工中的最小单位，不可再

分。数据字典的数据项条目中应包含的主要内容有：数据项名称、数据项别名、说明、类型、长

度、取值范围及含义等。

例如：出勤表中的职工号数据项在数据字典中的条目描述为

数据项名称：职工号

数据项别名：employee_no

说明：本单位职工的惟一标识

类型：字符串

长度：6

取值范围及含义：1〜2位(00..99)为部门编号：3〜6位(XX0001..XX9999)为人员编号

(3)数据文件条目

数据文件是数据流图中数据结构的载体。数据字典的数据文件条目中应包含的主要内容有:

数据文件名称、说明、数据文件组成、组织方式、存取方式、存取频率等。

例如：工资系统中的职工工资档案文件在数据字典中的条目描述为

数据文件名称：工资档案

说明：单位职工的基本工资、各项津贴及补贴信息

数据文件组成：职工号+国家工资+国家津贴+职务津贴+职龄津贴+交通补贴+部门补贴+

其他补贴

组织方式：按职工号从小到大排列

存取方式：顺序

存取频率：1次/月

⑷数据加工条目

在数据流图中只简单给出了每个加工的名称，在数据字典中通过数据加工条目主要是要说

明每个加工是用来“做什么”的。数据字典的数据加工条目中应包含的主要内容有：

数据加工名称、加工编号、说明、输入数据流、输出数据流、加工逻辑等。

〔例如「X资系统中的讦算应发工资这个加工在数据字典中的条目描述为|

数据加工名称：计算应发工资

加工编号：1.2

27ERD也模示例

简单情况下ERD建模

(1)从描述信息中辩识实体

-可以重点关注描述信息中的名词，看系统是否需要收集其相关的特征

♦(2)确定实体的标识符

(3)建立实体间关系

-判断各个关系的建立是否会产生新的关联实体或者影响已有的实体特性

(4)添加详细的描述信息

-实体的详细属性和关系的基数

简单情况下ERD建穆示例

研讨班在每个学年开始的时候开设，然后持续一个学年。

-每个研讨班针对一个或几个研究方向。

-每个研讨班由一位或几位教师主持。

-在研讨班开设之后，学生可以根据主持教师(的姓名)和研讨班的方向来选择和参加某

个研讨班。

-所有的学生必须且只能参加一个研讨班的学习。

-研讨班时常会开展活动，由教师来决定活动的时间、地点、主题和做报告的学生(的姓

名）。

每次活动时，由一位或多位同学围绕活动主题做学习报告，交流自己对新技术的学习心

得。

-每个学生一次活动最多只能作一个报告，但每个学生至少会在一次活动中做一个报告。

-教师对每份活动中的学生报告进行一次点评和指导，提出意议和意见。

复杂情况下ERD建液

1.发现系统的概念域

-指那些在系统业务口非常重要的概念，如果没有这