软件工程复习 第四章
第四章 结构化分析
需求分析
作用
为了开发出真正满足用户需要的软件产品，明确了解用户需求是关键。
需求分析就是要回答“系统必须做什么”
在需求中会存在大量的错误，这些错误若未及时发现和更正，就会造成软件开发费用增加、软件质量降低，严重时，会造成软件开发失败
需求分析是非常重要的过程，它完成的好坏直接影响后续软件开发的质量。
方面
确定系统的运行环境要求系统运行时的环境要求包括
硬件环境要求，如对计算机的CPU、内存、存储器、输入/输出方式
通信接口和外围设备等的要求
软件环境要求，如操作系统、数据库管理系统和编程语言等的要求。
确定系统的功能性需求和非功能性需求
功能需求是软件系统最基本的需求表述，包括对系统应该提供的服务，如何对输入做出反应以及系统在特定条件下的行为描述。
非功能性需求包括对系统提出的性能需求、可靠性和可用性需求、系统安全以及系统对开发过程、时间、资源等方面的约束和标准等。
进行有效的需求分析
原则
需求分析是一个过程，它应该贯穿于系统的整个生命周期中，而不是仅仅属于软件生命周期早期的一项工作。
需求分析应该是一个迭代的过程。通常情况下，需求是随着项目的深入而不断变化的。
为了方便评审和后续的设计，需求的表述应该具体、清晰，并且是可测量的、可实现的。最好能够对需求进行适当的量化
两个任务
需求分析的建模阶段，即在充分了解需求的基础上，建立起系统的分析模型。
需求分析的描述阶段，就是把需求文档化，用软件需求规格说明书的方式把需求表达出来。
软件需求规格说明书
- 软件需求规格说明书是需求分析阶段的输出，它全面、清晰地描述了用户需求，因此是开发人员进行后续软件设计的重要依据。软件需求规格说明书应该具有清晰性、无二义性、一致性和准确性等特点。同时，它还需通过严格的需求验证、反复修改的过程才能最终确定。
步骤
需求获取
观察
体验
问卷调查
访谈
单据分析
报表分析
需求调研会
分析建模
- 获取需求后，下一步就应该对开发的系统建立分析模型了。模型就是为了理解事物而对事物做出的一种抽象，通常由一组符号和组织这些符号的规则组成。对待开发系统建立各种角度的模型有助于人们更好地理解问题
需求描述
- 需求描述就是指编制需求分析阶段的文档。一般情况下，复杂的软件系统在需求阶段会产生3个文档:系统定义文档（用户需求报告）、系统需求文档（系统需求规格说明书）、软件需求文档（软件需求规格说明书）。而对简单的软件系统而言，需求阶段只需要输出软件需求文档就可以了。
需求验证
- 需求分析阶段的工作成果是后续软件开发的重要基础，为了提高软件开发的质量，降低软件开发的成本，必须对需求的正确性进行严格的验证，确保需求的一致性、完整性、现实性、有效性，确保设计与实现过程中的需求可回溯性，并进行需求变更管理
需求管理
为了更好地进行需求分析并记录需求结果，需要进行需求管理。
需求管理是一种用于查找、记录、组织和跟踪系统需求变更的系统化方法。可用于：
（1）获取、组织和记录系统需求。
（2）使客户和项目团队在系统变更需求上达成并保持一致。
有效需求管理的关键在于维护需求的阐述足够明确、每种需求类型适用的属性，以及与其他需求和其他项目工件之间的可追踪性。
需求管理实际上是项目管理的一部分，它涉及以下3个主要问题
（1）识别、分类、组织需求，并为需求建立文档。
（2）需求变化，即带有建立对需求不可避免的变化是如何提出、如何协商、如何验证以及如何形成文档的过程。
（3）需求的可跟踪性，即带有维护需求之间以及与系统的其他制品之间依赖关系的过程。
需求分析的常用方法
功能分解方法
- 功能分解方法是将一个系统看成是由若干功能模块组成的，每个功能又可分解为若干子功能及接口，子功能再继续分解，即功能、子功能和功能接口为功能分解方法的3个要素。功能分解方法采用自顶向下、逐步求精的理念。
结构化分析方法
- 结构化分析方法是一种从问题空间到某种表示的映射方法，其逻辑模型由数据流图和数据词典构成并表示。它是一种面向数据流的需求分析方法
信息建模方法
模型是用某种媒介对相同媒介或其他媒介中的一些事物进行模拟表现的形式。从一个建模角度出发，模型就是要抓住事物最重要的方面而简化或忽略其他方面。简而言之，模型就是对现实的简化。建立模型的过程称为建模。
建模可以帮助理解正在开发的系统，这是需要建模的一个基本理由，并且，人对复杂问题的理解能力是有限的。建模可以帮助开发者缩小问题的范围，每次着重研究一个方面，进而对整个系统产生更加深刻的理解。可以明确地说，越大、越复杂的系统，建模就越重要。
面向对象的分析方法
面向对象的分析方法的关键是识别问题域内的对象，分析它们之间的关系，并建立3类模型。
它们分别是
描述系统静态结构的对象模型
描述系统控制结构的动态模型
描述系统计算结构的功能模型
其中，对象模型是最基本、最核心、最重要的。面向对象主要考虑类或对象、结构与连接、继承和封装、消息通信，只表示面向对象分析中几项最重要的特征。类的对象是对问题域中事物的完整映射，包括事物的数据特征（即属性）和行为特征（即服务）
结构化分析概述
一种考虑数据和处理的需求分析方法被称为结构化分析（Structured Analysis，SA）方法，它是20世纪70年代由Yourdon Constaintine及DeMarco等人提出和发展，并得到广泛应用的。它基于“分解”和“抽象”的基本思想，逐步建立目标系统的逻辑模型，进而描绘出满足用户要求的软件系统。
结构化分析的具体步骤如下。
建立当前系统的“具体模型”。
抽象出当前系统的逻辑模型。
建立目标系统的逻辑模型。
为了完整地描述目标系统，还需要考虑人机界面和其他一些问题。
结构化分析方法
此模型的核心是“数据字典”，它描述软件使用或产生的所有数据对象。
围绕这个核心有3种图
“数据流图”指出当数据在软件系统中移动时怎样变换，以及描绘变换数据流的功能和子功能，用于功能建模
“实体-关系图”（E-R图）描绘数据对象之间的关系，用于数据建模
“状态转换图”指明作为外部事件结果的系统行为，用于行为建模。
结构化分析方法必须遵守下述准则。
（1）必须定义软件应完成的功能，这条准则要求建立功能模型。
（2）必须理解和表示问题的信息域，根据这条准则建立数据模型。
（3）必须表示作为外部事件结果的软件行为，这条准则要求建立行为模型。
（4）必须对描述功能、信息和行为的模型进行分解，用层次的方式展示细节。
（5）分析过程应该从要素信息移向实现细节。
不同的模型往往表述系统需求的某一方面，而模型之间又相互关联，相互补充。
功能建模
功能建模的思想就是用抽象模型的概念，按照软件内部数据传递和变换的关系，自顶向下逐层分解，直到找到满足功能要求的可实现的软件为止。功能模型用数据流图来描述。
数据流图（简称DFD图）就是采用图形方式来表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程，是结构化系统分析方法的主要表达工具及用于表示软件模型的一种图示方法。
数据流图
4种符号
（1）外部实体：表示数据的源点或终点，它是系统之外的实体，可以是人、物或者其他系统。
（2）数据流：表示数据流的流动方向。数据流可以从加工流向加工、从加工流向文件、从文件流向加工。
（3）数据变换：表示对数据进行加工或处理，比如对数据的算法分析和科学计算。
（4）数据存储：表示输入或输出文件。这些文件可以是计算机系统中的外部或者内部文件，也可以是表、账单等。
Yourdon表示法
（1）矩形表示数据的外部实体。
（2）圆形泡泡表示变换数据的处理逻辑。
（3）两条平行线表示数据的存储。
（4）箭头表示数据流。
环境图
环境图也称为系统顶层数据流图（或0层数据流图），它仅包括一个数据处理过程，也就是要开发的目标系统。
环境图的作用是确定系统在其环境中的位置，通过确定系统的输入和输出与外部实体的关系确定其边界。
根据结构化需求分析采用的“自顶向下，由外到内，逐层分解”的思想，开发人员要先画出系统顶层的数据流图，然后再逐层画出低层的数据流图。顶层的数据流图要定义系统范围，并描述系统与外界的数据联系，它是对系统架构的高度概括和抽象。底层的数据流图是对系统某个部分的精细描述。
遵守的原则
（1）第0层的数据流图应将软件描述为一个泡泡。
（2）主要的输入和输出应该仔细标记。
（3）通过分离在下一层表示的候选处理过程、数据对象和数据存储，开始求精过程。
（4）应使用有意义的名称标记所有的箭头和泡泡。
（5）当从一个层转移到另一个层时要保持信息流的连续性。
（6）一次精化一个泡泡。
数据流图的分层
对于稍微复杂一些的实际问题，在数据流图上常常出现十几个甚至几十.个加工，这样的数据流图看起来不直观，不易理解，分层的数据流图能很好地解决这一问题。
按照系统的层次结构进行逐步分解，并以分层的数据流图反映这种结构关系，能清楚地表达和容易理解整个系统。
原则
数据守恒与数据封闭原则
- 所谓数据守恒是指加工的输入输出数据流是否匹配，即每一-个加工既有输入数据流又有输出数据流。或者说一个加工至少有一 个输入数据流,一个输出数据流。
分解加工的原则
自然性:概念上合理、清晰;
均匀性:理想的分解是将一个问题分解成大小均匀的几个部分;
分解度:每个加工每次分解一般不超过7士2个子加工;分解到基本加工为止。
子图与父图的“平衡”
- 父图中某个加工的输入输出数据流应该同相应的子图的输入输出相同(或相对应)，分层数据流图的这种特点称为子图与父图“平衡”
合理使用文件
- 当文件作为某些加工之间的交界面时，文件必须画出来，一旦文件作为数据流图中的一个独立成份画出来了，那么同其他成份之间的联系也应同时表达出来。
数据建模
数据模型中包含3种相互关联的信息
数据对象
- 数据对象是对软件必须理解的复合信息的抽象。数据对象可以是外部实体、事物、行为、事件、角色、单位、地点或结构等。总之，可以由一组属性来定义的实体都可以被认为是数据对象
数据对象的属性
属性定义了数据对象的性质
必须把一个或多个属性定义为“标识符”,也就是说，当人们希望找到数据对象的一个实例时，用标识符属性作为“关键字”(通常简称为“键”)
数据对象彼此间相互连接的关系
客观世界中的事物彼此间往往是有联系的
数据对象彼此之间相互连接的方式称为联系，也称为关系
关系用菱形表示，并用无向边分别与有关实体连接起来,以此描述实体之间的关系
关联数量的表示
关系本身也可能有属性，
关系属性的表示
- 在表示关系的无向边上再加一个菱形框，并在菱形框中标明关系的名字，关系的属性同样用椭圆形或圆角矩形表示，并用无向边将关系与其属性连接起来。
行为建模
状态转化图
状态转换图是一种描述系统对内部或外部事件响应的行为模型。它描述系统状态和事件，事件引发系统在状态间的转换，而不是描述系统中数据的流动。这种模型尤其适合用来描述实时系统，因为这类系统多是由外部环境的激励而驱动的。
优点
状态之间的关系能够直观地捕捉到
由于状态转换图的单纯性，能够机械地分析许多情况，可以很容易地建立分析工具。
状态转换图能够很方便地对应状态转换表等其他描述工具
并不是所有的系统都需要画状态转换图，有时系统中的某些数据对象在不同状态下会呈现不同的行为方式，此时应分析数据对象的状态，画出状态转换图，才可正确认识数据对象的行为，并定义其行为。对这些行为规则较复杂的数据对象需要进行如下分析。
找出数据对象的所有状态
分析在不同的状态下，数据对象的行为规则是否不同，若无不同，则可将其合并成一种状态
分析从一种状态可以转换成哪几种状态，是数据对象的什么行为导致这种状态的转换。
状态
状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式
在状态转换图中定义的状态主要有
初态（即初始状态）
终态（即最终状态）
中间状态
一张状态图中只能有一个初态，而终态可以没有，也可以有多个
状态中的活动表的语法格式如下
事件名（参数表）/动作
表达式其中，“事件名”可以是任何事件的名称。
事件
事件是在某个特定时刻发生的事情，它是对引起系统做动作或（和）从一个状态转换到另一个状态的外界事件的抽象。
状态变迁通常是由事件触发的，在这种情况下，应在表示状态转换的箭头线上标出触发转换的事件表达式。
事件表达式的语法如下
事件说明［守卫条件］/动作表达式其中，事件说明的语法为：
事件名（参数表）守卫条件是一个布尔表达式。如果同时使用事件说明和守卫条件，则当且仅当事件发生且布尔表达式为真时，状态转换才发生。如果只有守卫条件没有事件说明，则只要守卫条件为真，状态转换就发生。
动作表达式是一个过程表达式，当状态转换开始时执行该表达式。
数据字典
数据字典是关于数据的信息的集合，也就是对数据流图中包含的所有元素的定义的集合。
数据字典可以把不同的需求文档和分析模型紧密结合在一-起，如果所有的开发人员在数据字典上取得一致意见， 那么就可以缓和集成性问题。为了避免冗余和不一致性，应该在项目中创建一个独立的数据字典，而并不是在每个需求出现的地方定义每一个数据项。
六类条目
数据项
数据结构
数据流
数据存储
加工逻辑
外部实体
加工规格说明
过程设计语言
- 过程设计语言（Procedure Design Language，PDL），也称为伪代码，在某些情况下，在加工规格说明中会用到。但一般说来，最好将用PDL来描述加工规格说明的工作推迟到过程设计阶段进行比较好。
判定表
- 在某些数据处理中，某个数据处理（即加工）的执行可能需要依赖于多个逻辑条件的取值，此时可用判定表。判定表能够清晰地表示复杂的条件组合与应做的动作之间的对应关系。
判定树
- 判定树是判定表的变种，也能清晰地表示复杂的条件组合与应做的动作之间的对应关系。判定树也是用来表述加工规格说明的一种工具。判定树的优点在于，它的形式简单到不需要任何说明，一眼就可以看出其含义，因此易于掌握和使用
结构化分析的图形工具
层次方框图
层次方框图由树形结构的一系列多层次的矩形组成，用来描述数据的层次结构。
方框之间的关系是组成关系，而不是调用关系。
Warnier图
与层次方框图相似，也用树形结构来描绘数据结构，但提供了更详细的描绘手段
能指出某一类数据或某一数据元素重复出现的次数，并能指明某一特定数据在某一类数据中是否是有条件地出现。
IPO图
IPO图是输入-处理-输出（Input-Process-Output）图的简称。
能够方便地描绘输入数据、对数据的处理和输出数据之间的关系。