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

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、J几条法则日勺应用？

差异问题协调法则：

不一样的业务层面（有时虽然是相似业务层面）的顾客对同样的概念或者流程

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

标识出来，并展示给顾客高层管理人员，由他们来确定然样消除这些差异，

并将这些状况记录。

消除变更问题协调法则：

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

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

应当从开发角度考虑怎样消除这些差异，并提供应高层管理人员。要有积极性

需求协商时机法则：

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

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

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

实例：

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

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

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

7需求获取的重要措施

顾客访谈

顾客调查

文档分析

原型法（情节串联板）

模型驱动的措施

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

开放式话题

长处：

-让被会见者感到自在；

会见者可以搜集被会见者使用的词汇，这能反应他的教育、价值原则、态度

和信念；

-提供丰富的细节；

-对没采用的深入的提问有启迪作用；

-让被会见者更感爱好；

-容许更多的自发性；

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

缺陷：

一提此类问题也许会产生太多不相干的细节；

-面谈也许失控；

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

-也许会使会见者看上去没有准备

封闭式话题

。长处：

-节省时间；

-切中要点；

-保持对面淡的控制；

-迅速探讨大范围问题；

-得到贴切的数据

缺陷:

使得被会见者厌烦;

-得不到丰富的细节；

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

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

9顾客访谈时问题组织的三种方式及特点?

金字塔构造

❖假如会见者认为被会见者需要对话题进行预热，可以采用金字塔构造，通过逐渐的

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

♦：♦假如会见者发现自己事先对事实确实认存在较大偏差或者被会见者看上去不情愿

讨论这个话题，也可以采用金字塔构造。

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

漏斗构造

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

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

型提问次序。

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

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

问题和调查问题。

菱形构造

♦：♦使用菱形构造的重要长处是通过多种各样的问题保持被会见者的爱好和注意力。一

旦掌握了怎样在对的的时间问对的的问题，就可以多样地选择问题的次序。

10市场调查和需求获取在访谈与调查次序上有何不一样？原因何在?

一般来说，在开展市场调查时，由于很难深入接触到潜在的顾客。因此

总是先调查，后访谈。而在需求获取时，一般采用的方略是先访谈，后调查。

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

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

决的问题。

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

有效的调查问卷。

11采用原型措施的三个日的J?

明确并完善需求

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

统。

研究设计选择方案

原型作为一种设计工具，涉众可以用它研究不一样的顾客交互技术，优化系统易用性,

并评估也许的技术方案。

发展为最终产品

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

12用例描述措还

13需求关豕的主线任务是什么？

需求分析是软件需求中最关键的工作，需求建模是需求分析

的重要手段。

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

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

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

工作，也就是对目的系统提出完整、精确、清晰、详细的规定。

需求分析主线任务：建立分析模型，创立处理方案。

14需求分析任务中分解方略重要包括那几种？每种方略分别适合应

用于那些系统的开发

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

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

“业务”的角度考虑分解措施。此措施尤其适合联机事务处理系

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

目的系统-》主题域的分解根据是“目的决定范围”；

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

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

业务活动-》业务环节所做的是细化和确认工作。

2）程序构造为主线的分解方略；

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

构，割裂了与问题域之间的联络，从而轻易导致对问题域研究的

局限性，减少了需求的质量。目前认为此种措施仅适合于问题域比

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

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

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

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

总结成一系列的关注点或者功能域，向下可以分解成详细的环节

或者操作任务。

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

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

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

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

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

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

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

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

分解是一种自顶向下的措施，当按照任何一种线索进行分解时。就会破坏其他线索的完整

性。例如，假如以“业务”为线索，就会发现数据需求分解后会出现互相交叠的状况，也

就是在多种业务事件中都波及相似的类。

此种状况出现时，也许会影响需求分析人员建立全面的理解，因此需要采用自

底向上的措施进行提炼。例如将每个业务事件中的类进行提炼，抽取出共性的部分，建立

针对整个系统的全局领域模型。

16构建分析模型n勺6的？

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

2和顾客达到对信息内容的共同理解

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

物的信息

17分析模型的建模措施？

模型

-“模型是对事物的抽象，协助人们在创立一种事物之前可以有更好的理解”

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

-“它是对系统进行思索和推理的一种方式。建模的目的是建立系统的一种表

达，这个表达以精确一致的方式描述系统，使得系统的使用愈加轻易力

-建模措施

•抽象

•分解

•投影

♦：♦抽象（Abstraction）

-首先规定人们只关重视要的信息，忽视次要的内容

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

-另首先也规定人们将认知保留在合适的层次，屏蔽更深层次的细节

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

处理方案

♦：♦分解(Decomposition/Partitioning)

-“分而治之”

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

掌握各子问题之间的联络

-分解的方案往往还能提供问题的处理思绪

♦：♦投影(Projection)

-多视点措施

18实际日勺建模过程中要遵照出J建模原则？

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

手也可以有效地运用设计的方案。用可视化的模型体现现实世界，有助于理解变化所代表

的含义。

在实际的建模过程中要遵照如下建模原则：

•模型是用来沟通的；

•选择创立什么模型对怎样处理问题和怎样形成处理方案具有深远的影响。

•每种模型可以在不一样的精度级别上表达；

•最佳的模型是与现实相联络的模型；

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

19需求建模的流程？

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

然后分析顾客需求，对模型进行调整，得到一种中间形式的模型形式。

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

的处理方案模型。

20常见日勺需求分折技术?

❖构造化技术

-数据建模

实体关系图EntityRelationshipDiagram

过程建模

•数据流图DataFlowDiagram

上下文图ContextDiagram

微规格阐明Mini-Specification

•数据字典DataDictionary

-行为建模

,状态(转换)图/矩阵State(Transition)Diagram/Matrix

-过程/数据关系要模

,功能实体矩阵Function/EntityMatrix

-信息工程措施

功能分解图FunctionDecompositionDiagram

过程依赖图ProcessDependencyDiagram

♦：♦面向对象技术

-UML

,用例图Use-CaseDiagram

,类图ClassDiagram

,交互图(次序图/通信图)Interaction(Sequence/Communication)

Diagram

•活动图ActivityDiagram

,对象约束语言ObjectConstraintLanguage

,状杰图StateChartDiagram

21对欧)认识UML12)(3J(4)

(2)UML的精确理解

UML是一种语言(Language)

实际上UML就是一种表达措施，它不是措施论。

UML是一种建模语言(ModelingLanguage)

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

模等多种领域。

UML是统一建模语言(UnifiedModelingLanguage)

它是一种原则化的、统一的建模语言，OMG承认的工业原则，也是如IBM、SUN等大型企

业承认的事实原则。

(3)为何要使用UML

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

的语言，使开发人员可以基于共的模型来理解业务、需求，理解软件及其架构怎样构造

叽

(4)怎样使用UML

UML2.0原则中，共定义了13种不一样的图，这些图的功能以及与UML1.0之间的关系如

下表

图名功能备注

类图描述类、类特性及类间关系UML1.0原有

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

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

构件图描述构件的构造和连接UML1.0原有

布署图描述在各个节点上的布署UML1.0原有

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

用例图描述顾客与系统怎样交互UML1.0原有

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

状态图描述事件怎样变化对象生命周期UMLLO原有

次序图描述对象之间的交互、重点在于强调次序UMLLO原有

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

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

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

怎样使用UML-需求阶段一般常采用的图

使用频率图名功能

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

活动图阐明业务流程，以及业务活动的环节

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

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

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

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

22构造化分析遵照的三条原则？

构造化分析遵照的三条基本原则：

分解

抽象

映射

23构造化分析模型口勺构成元素？

数据字典(DD)

-模型关键，包括了所有数据对象的描述的中心库。

。E—R图(ERD)

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

♦：♦数据流图(DFD)

-指明数据在系统中移动时怎样被变换；

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

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

-用于功能建模。

状态变迁图(STD)

-指明作为外部事件的成果，系统将怎样动作。用于行为建模。

24构造化建模示例•建立计算机售书条统的透转模型

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

(2)去掉详细模型中的非本质原因:

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

••一•★的弃做“力X49««

(3)分析目前系统与目的系统的差异，建立目的系统的逻辑模型。

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

(5)需求分析的验证

学

生

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

。数据流图(DFD：DataFlowDiagram)就是组织中信息运动的抽象，是信息逻辑系

统模型的重要形式。这个模型不波及硬件、软件、数据构造与文献组织，它与对系

统的物理描述无关，只是用一种图形及与此有关的注释来表达系统的逻辑功能，即

所开发的系统在信息处理方面要做什么。

❖由于图形描述简要、清晰，不波及到技术细节，所描述的内容是面向顾客的，因此

虽然完全不懂信息技术的顾客单位的人员也轻易理解。因此数据流图是系统分析人

员与顾客之间进行交流的有效手段，也是系统设计(即建立所开发的系统的物理模

型)的重要根据之一。

。数据流图脱离系统中的物理原因(如计算机等)，体现出系统对信息的加工状况。DFD

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

。DFD是SA的重要工具，它简朴、直观，用图形、文字描述系统。它便于使用、便于

交流、便于讨论、便于形成共识，是计算机专业人员和顾客单位业务人员的共同语

言。

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

匚

外品项（§）.（P）数据存W!（D）数据海（F）

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

（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)数据流是必须和过程产生关联的，它要么是过程的数据输入，要么是过程的数

据输出。

□O兽髀正确的

叫了数据流数据流x

II_CJIH----<□

O~4JZ

11nz：_Hzu

J

匚一---------HZ1Z

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

-过程使用动词

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

数据流图绘制过程

f

绘制数据流图的重要原则

(1)明确系统边界。

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

❖(3)合理布局。

(4)数据流图绘制过程，就是系统的逻辑模型的形成过程，必须一直与

顾客亲密接触，详细讨论，不停修改，也要和其他系统建设者共同商讨

一求一致意见。

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

简朴银行取款应用描述

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

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

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

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

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

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

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

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

目录对订单进行检查并对合格订单进行处理，处理过程中根据顾客状况和订单数目将订单

分为优先订单与正常订单两种，随时处理优先订单，定期处理正常订单。最终系统根据所

处理的订单汇总，并按出版社规定发给出版社。

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

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

、…Li-i»'I-1由

1JPH”总.]1

ffl图嗔”美联HH

♦第二步，逐层分解加工，画出下层DFD0注意到根据题意，当绘出系统顶层图后并

不能将所有加工分解成基本加工，还要进行二层图分解。并在分解加工过程中逐渐

充实进数据存储。见图。

向书预I丁系网一房图

数据流图的作用

前面说过，系统分析的重要任务是建立新系统的逻辑模型。详细地讲重要是画出新

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

❖建立新系统的DFD是一项十分重要的工作。由于建立的DFD是系统开发乃至系统维

护的根据，是系统的重要文档之一。系统分析员要在详细调查中，在与顾客的反复

交流中修改DFD,力争新建DFD是对的的、精确的。

DFD的层级构造

❖根据所含过程的不一样抽象程度，DFD可以在不一样的抽象层次_L进行系统的描

述

。一种比较抽象的过程可以被展开为一种子过程愈加详细的DFD图

♦：♦DFD的层次构造

上下文图

0层图

-N层图（N>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描述，它是为系统中发生的重要事件

创立的。

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

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

产生。层图

♦：♦往往需要多次调整DFD片段的整合成果才能得日

。对DFD图（尤其是0层图）质量的鉴定有下面几种准则：

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

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

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

流是在充足运用输入数据的基础上产生的，不存在输入数据的挥霍。

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

的过程数量最佳控制在5〜9（人脑的最佳信息处理量）个。并且图中的数

据流数量越少越好，越简洁越好（接口最小化）。

功能分解产生N层图

。功能分解是一种拆分功能的描述，将单个复杂的过程变为多种愈加详细、愈加精确

和愈加细节的过程。

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

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

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

续的功能分解活切：

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

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

-顾客已经不关怀比子图更为细节的内容，或者子图的描述已经详细的足以支持

后续的开发活动;

-每一种数据流都巳经不需要进行更详细的切分，以展示对不一样数据的不一样

处理方式；

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

业务报表都已经被表达为一种单独的数据流；

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

层次构造的建立一示例

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

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

的作用下在甬道内做上下运动。甬道内安装有多种传感器，一般每个电梯停靠

点一种，用来感应电梯的实时位置。电梯内部和建筑的每个电梯停靠层都设置

有指示器，月来告知顾客的电梯实时位置和运动状况。电梯内和建筑的每个电

梯停靠层都设有按钮，顾客可以通过这些按钮提出服务申请并进出电梯。控制

系统调度顾客的申请，让电梯以最有效的方式满足顾客的服务规定。

业务需求实现业务需求需要的原登特11局部解决方案的可外交互

SF1.1:能钱获知电梯位置客应，并转交怜指外部轮入：感应省感知信号

示胃外部轴出：指示器餐求信号

SF1.2:能够控制卷扬电机.实现服务请求的内部枪入：潮度睫求

BR1:让电梯运转起来

电梯运动外部袍出：卷扬电机控制信号

SFI.3:用户可以利用按钮发出限务请求外部输入：按包信号

内部输出：服芬请求

BR2:实现电林的有效通SF2.1:系统从服务请求从列中建立高效率的内部他入：服芬请求

度.最大FR度的反芬用户n内部枪出：诏度要求

BR3:保证安全，尤其是用SP3.1:系统要根，电梯的叁动状况和服务申内司输入：服务请求.电桃状况

户出入电柿的安全请控制电棒门的开关外部输出：门控命令

图12-25、电梯控制系统的上下文图

层次构造的建立一-建立DFD片断

事件系统的响应

系统ft•先要记录请求.以备调度.如果请求叶电梯处于运动状态.

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

则系统需粤重新执行请求调皮.并在需要的情况下更改运动目标.

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

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

控命令,否则不予处理.

感应JS信号发生变化系统费根据新的信号更新电.M状态,并通如指示器改变显示.

电梯开始运动,即门已关闭.开始运票统费改变电棒状态为运动状态,然后根据等待的服务请求谓度确

动定电梯的运动因标，结合也懂目前位置，控制粗插电机开始工作.

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

电梯停止.即电棒已经列达目标位亶

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

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

层次构造的建立-一

建立。层图

图12-27、电梯控制系统的初始（I层图

E12-28,电梯控制系统的最终。层图

DFD验证

♦：・验证DFD的语法

保证DFD中不会发生语法错误

♦：♦验证DFD的构造

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

验证DFD层次构造阐明的完备性

。验证DFD的语义

-保证DFD所阐明内容的对的性和精确性

26数据字典

数据字典的提出背景：

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

流图中的许多构成元素，如数据流、数据存储、加工，仅依托名称并不能反应其本质含义，

因此必须对这些构成元素进行严格的定义。作为对数据流图的补充，数据字典(DD,Data

Dictionary)可以精确地定义数据流图中各构成成分的详细含义，两者共同构成了系统的逻

辑模型。

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

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

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

素的

-名称

-别名

-使用地点

使用措施

使用范围

描述

单位/格式

名称数据元素的原始名称

别名数据元素的其他名称

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

使用措施该数据元素饰演的角色（输入流、输出流或者数据存储等）

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

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

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

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

*又现91

W我孝宜为用于。・全通的&0选行一切的*义

双东“关，、f戏不、'欢K帕・

111我不或义泰X-|a|l»|hX-f«.b|WVt•衾小、由・*b51«<

1.1

(>我军/、-13我不■，以在、咿出国,也可口不出

II次不■量大M号中的内，・震，次

・11・*亭■电次■的■■・霞明次・•少,次.■各■次

..■”中5内，晶小本色・无拿.卒那。分

HC-L1［或小中的住,值

••内克力n”他，

符号含义示例

=包括，由…构成

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;

的"人7%灰

数据流名：发票

阐明：用作学生已付书款的根据

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

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

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

数据流词条的描述示例2：

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

数据流名称：出勤表

数据流别名：无

阐明：由人事部门每月月底上报的职工考勤记录数字

数据流来源：人事部门

数据流流向：加工1.1.1(记录出勤、请假及旷工时数)

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

数据流量：1份/月

(2)数据项条目

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

不可再分。数据字典的数据项条目中应包括的重要内容有：数据项名称、数据项别名、阐

明、类型、长度、取值范围及含义等。

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

数据项名称：职工号

数据项别名：employee」。

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

类型：字符串

长度：6

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

(3)数据文献条目

数据文献是数据流图中数据构造的载体。数据字典的数据文献条目中应包括的重要内

容有：数据文献名称、阐明、数据文献构成、组织方式、存取方式、存取频率等。

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

数据文献名称：工资档案

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

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

其他补助

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

存取方式：次序

存取频率：1次/月

(4)数据加工条目

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

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

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

例如：工资系统中的计算应发工资这个加工在数据字典干的条目描逑为

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

加工编号：L2

27ERD也模示例

简朴状况下ERD建模

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

-可以重点关注描述信息中的名词，看系统与否需要搜集其有关的特性

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

♦：♦(3)建立实体间关系

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

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

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

简朴状况下ERD建模-示例|

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

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

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

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

与某个研讨班。

-所有的学生必须旦只能参与一种研讨班的学习。

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

姓名)。

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

习心得。

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

报。

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

复杂状况下ERD建模

1.发现系统的概念域

-指那些在系统业务中非常重要的概念，假如没有这个概念，组织就也许不会存在或

者业务发生重大变化

-不能遗漏那些对业务有重大影响的概念，同步概念域的发现也不要太细节

-每一种概念域都会以星型发散的方式扩展为多种逻辑实体

2.建立对概念域的描述

3.展开概念域

-简朴状况下的ERD建模

-或者深入细分子域

4.合并概念域的局部数据模型

-消除冗余和冲突

28构造化范型与面向对象范型的区别？

构造化范型(StructuredParadigm)基于如下的思想进行开发活动：一种系统应当被

划分为两个部分：数据（使用数据/持久化模型建模）和功能（使

用过程模型建模）。简言之，构造化措施，数据将和设计模型中以及系统实现

中（也就是程序中）的行为分离。

范型（Paradigm）：做事情的整体方略或观点，是一套特定的思想集合。

面向对象范型（Object-orientedParadigm）不是将系统定义为两个分离的部分（数

据和功能），而是需要把系统定义为一组正在交互的对象。对象可以完毕某些事情（对象具

有功能），对象也懂得某些事情（对象有数据）。

*

婚物化上用

29抽象类与详细类在表达上有何区另，」？

dL<I弟当体公0・

A，e是一个“niu

Pro(t5«i»r4*RcwarrlirrA是人

rmfcMwrKr^canrhrr

引入抽象类是为了实现类的公共行为。

抽象类与详细类的区别在于：可以从详细类中实例化（创立）对象，但不

能从抽象类中实例化对象。意味着软件需要实例化专家或者研究员对象，但不

需要创立教师对象。当创立一种类实现多种类的共同特性时.就可以建立抽象

类。

30UML多重指示器口勺含义？

指示器含义

0..1零或1个

1仅1个

0..*零或多种

1..*