传统的软件开发方法

结构化程序设计SP

SP的思想最早是由著名计算机科学家E.W.Dijkstra提 出的。 1966年Bohm和Jacopin证明了只用三种基本结构就能 实现任何一个入口，一个出口的程序； 1977年IBM公司的Mills又进一步提出：“程序应该只 有一个入口和一个出口。

在长期程序设计的实践中，SP方法不断得以 完善，使之成为开发传统应用领域应用系统 的主要方法之一。

软件需求定义的特点


它是软件生存周期中最容易出错的一个阶段， 也是软件工程中最困难的一个阶段。困难在于： – 不能准确地理解和清楚地描述 – 软件系统非常复杂，以致用户和软件人员 都不能完整、精确地理解它或不能清楚地 表达出来；软件人员和用户缺乏共同语言。 – 用户熟悉业务，但不了解计算机；而软件 人员则相反；这种隔阂使双方不能进行交 流。 这一阶段与其它阶段很不相同，它是其它阶段 的基础，十分重要。一旦需求定义出现错误， 将导致整个软件开发的失败。而这一阶段是面 向用户问题的，而不是面向软件求解的。
交换意见 作出贡献
有补充修改
分析追踪 数据流图
无补充 修改
用户复查
细化数据 不要分解 流图
沿数据流回溯



通常从数据流图的输出端着手分析，要搞清楚： – 数据元素从哪儿来？ – 每个输出数据元素又是从哪儿来的？ 有时对用户具体的数据元素还搞不清楚，则需 要和用户探讨、商量解决。 通常把分析过程中得到的有关部门数据元素信 息记录到数据字典DD中。把对算法的简明描 述记录在IPO（输入|处理|输出图）图中。 通过分析而补充的数据流、数据存储和处理， 应该添加到DFD的适当位置上。


一致性、无冗余 与DFD相互引用 DD的建立和维护是件细致而又复杂的工作。 大的数据处理系统在DD上投入的工作量是相 当大的。一般采用计算机进行DD的自动管理， 包括：建立新的条目定义、修改、查询操作 等。 DD中收集的信息不容许有多重定义的现象 （即最小冗余度）。

软件需求定义的工作流程
用户要求
系统定义
软件功能
软件计划
范围
软件定义
功能说 明书
软件功能
费用、资源进度
2、需求分析过程


基本过程示意图 沿数据流回溯 用户复查 细化数据流图 修改开发计划 书写文档资料 审查和复审
需求分析的基本过程
用户
分析员
程序员 软件需求说明书
需要分解
软件开发计划
顶层图
宾馆 管理
DFD/L0
第2层图
A
D
B E
C
DFD/L1
第3层图
A1 A2 A3
DFD/L2.1
E1 E2
DFD/L2.2
数据字典DD（Data Directory）



DD对数据流程图中出现的所有元素给出逻辑定义;即给 出DFD中的数据流、加工和文件、及及数据项等的详 细解释。 数据字典的条目解释通常采用规范的定义形式：
传统的软件开发方法
教学目标

了解传统程序设计方法: –基本概念 –方法及特点 –步骤及准则
本单元涉及内容

第十章 传统的软件开发方法 –10.1 结构化开发方法概述 –10.2 系统分析与定义 –10.3 系统设计 –10.4 系统编程 –10.5 系统测试 –10.6 系统维护 P273~P333
举例——宾馆管理系统
客人信息库 可售房库 售出房库
预订 客人 登录
房管
公安
预付 款
财务
IDD
客帐库
数据流图的结构

一个实际问题的数据加工流程是非 常复杂的。如果绘制在一个平面图 上就显的太乱了。因此，通常采用 分层次结构。把一个复杂的问题， 分解为一些相互独立的子问题，再 绘出分层DFD。
结构图分层举例
确定对系统的综合要求
系统功能要求 找出系统必须完成的所有功能。 系统性能要求 例如，联机系统的响应时间，系统需要的存储容量 以及后援存储，重新启动和安全性等问题。 运行要求 对系统运行环境的要求。例如，什么样的硬件环境？ 采用哪种DBMS？OS平台是什么？需要什么样的 外存储器和数据通信接口等。 将来可能提出的要求 为系统将来可能的扩充和修改预做准备。
数据流图DFD

数据流图（DFD——Data Flow Diagram ） 以图形的方式表达数据处理系统中信息的变 换和传递过程。它有四种基本符号：
S
P
X
数据源及数据终点 加工 对数据进行的加工或变换，指向加工的数据流 是输入数据；离开的是输出数据。 数据流 具有名字且有流向的数据 文件 存放数据的场所

结构化编码风格

尽量使用标准库函数 程序讲究清晰，避免过于精 巧 对重复使用的表达式尽量调 用公共函数代替 使用括号，以避免二义性 用逻辑表达式代替分支嵌套 使用缩排格式 避免使用IF THEN 和空ELSE 注意计算机运算特点，如 10.0乘0.1很少等于1.0
使用有意义的变量名 对输入进行错误判别 注释勿用太滥 模块化功能专一,模块 间偶合清晰 递归定义的DS尽量采 用递归过程访问 把大程序分成小块去 编写和测试 勿追求不必要的效率, 尽量采用基本控制结 构 避免循环多个出口
用户复查
经分析将在数据流图回溯过程中找出的 数据元素，并由此定义的DD和算法是否 正确？这只能由最有发言权的用户来复 查。 在复查过程中反映出新的问题，应及时 修改、补充DFD、DD和IPO图，并将对 系统的新认识及时记录下来。实际上， 追踪DFD和复查系统的逻辑模型这两个 步骤是交替进行的循环过程。
审查和复审

分析阶段最后一步是按结束标准对 该阶段的工作成果进行正式的技术 审查和管理审查。
3、需求分析的原则
1．能够表达和理解问题的信息域 信息域反映的是用 户业务系统中数据的流向和对数据进行加工的处理过 程，因此信息域是解决“做什么？”的关键因素。 2．要建立描述系统信息、功能和行为的模型 建立模型的 过程是“由粗到精”的分析综合的过程。 3．能够对所建模型按一定形式进行分解 分解是为了降低 问题的复杂性，增加问题的可解性和可描述性。 4．分清系统的逻辑视图和物理视图
说明


需求说明书主要内容： – 概述 开发系统的意义、目的、背景及技术术语； – 现性系统的概况 业务流程、范围、存在的问题等； – 需求说明 • 功能描述 • 信息描述：DFD、DD、DS、IPO、接口等 • 性能描述 – 运行环境 – 系统限制 用户系统描述 – 系统功能和性能的描述 – 使用系统的主要步骤和方法 – 系统用户的责任等
Hale Waihona Puke Baidu
模块化处理
模块化就是把程序划分为若干个模块， 而每个模块完成一个子功能，把这些模 块汇总起来构成一个有机整体，即可完 成指定的功能。 模块化的目的是为了降低软件复杂度， 使软件设计，调试和维护等操作变得简 易。

结构化编码
SP编码的方法强调清晰简洁，它是一种构 造程序的技术，有利于提高软件生产率及 降低软件维护代价。 1966年Bohm和Jacopin就证明了只要用三 中基本结构，就足以表示所有形式的程序 控制结构。 1978年Kernihan和Plauger对一些编码风 格进行归纳，提出了16种具体方法。
结构化设计SD
SD方法是由IBM公司的Constentine等人花了十 几年时间研究出来的一种程序设计方法，发表 于1974年。 SD是一种用于概要设计的方法，与SA方法配合 使用。 其目标：建立一个结构良好的软件系统。 SD方法的基础是数据流程图，因此也称为面向 数据流的设计方法。

二、软件需求定义
软件需求分析 就是明确软件系统将来达到的目标。 换句话说，它的基本任务是准确地回 答系统“做什么？”这个问题。 目标 它要规定项目必须满足的总目标； 确定项目的可行性；拟定完成项目各 个目标的策略，制定项目资源成本和 进度。

1、软件需求定义的任务
理解和表达用户要求，制定软件开 发计划，编写要求说明书。 收集、理解、明确用户的要求，明 确系统做什么？建立系统的逻辑模 型，写出开发计划和需求分析报告。

主程序员组织
主程序员 组织负责人,全权负责,包括解决技术难题, 有时一些关键性技术问题,主程序员应亲自动手遍程去 解决；他必须是技术高手，是程序生产过程中的总体设 计师。 程序员 按任务书要求编程；是程序生产线上的“工 人”。 测试工程师 具有较高遍程水准和经验，负责系统测 试；是程序生产过程中的检验员。 文档人员 自始至终参加程序生产活动，负责编写一切 有关文档资料。

– 软件需求的逻辑视图描述的是系统要达到的功能和要处理的 信息之间的关系，这与实现细节无关； – 而物理视图描述的是处理功能和信息结构的实际表现形式， 这与实现细节是有关的 – 需求分析只研究软件系统“做什么？”，而不考虑“怎样 做？”。
4、需求分析的图形工具

图形工具在描述复杂关系时比文字叙述 要优越。在系统需求分析过程中为了准 确描述需求，常采用一些简单的描述工 具，例如数据流程图（DFD）、数据字 典（DD）、结构化语言、判定表和判定 树等。
关于SP的定义


北大王选院士认为： –没有GOTO语句 –一个入口、一个出口 –自顶向下，逐步求精的分解 –主程序员组 潭浩强认为： –自顶向下 –逐步求精 –模块化设计 –结构化编码
关于SP的定义（续）

另一种说法： –自顶向下，逐步求精 –程序结构按功能划分为模块 –模块功能单一、简单 –模块由三种基本结构组成 –程序由函数、子程序来实现

一 、结构化开发方法


结构化开发方法是传统的软件系统开发方法。 基本要点是： –自顶向下 –逐步求精 –模块化设计 –结构化编码 –主程序员组织 –结构化设计SD SP的基本思想： 把一个复杂问题的求解过程分阶段进行，每个阶 段处理的问题都控制在人们容易理解和处理的范 围内。
“自顶向下”
客帐=帐号+房租+IDD费+餐饮费+洗衣费+娱乐费+日期+经办人
内容

数据流：编号、名称、简述、别名、构成、来源、去向、流量 数据项目：编号、名称、简述、别名、类型、长度、位数 数据文件：编号、名称、简述、别名、构成、关键字、存取要求 处理 编号、名称、简述、别名、处理条件、I/O内容、处理逻辑
编写DD的要求

结构化方法的体系结构

结构化方法的体系结构是: –结构化分析（SA—Structure Analysis） –结构化设计（SD—Structure Design） –结构化程序设计（SP—Structure Programing）
结构化分析SA

SA方法是建立在自顶向下、逐步求精思想基础 上的分析方法，它的要点是分解和抽象： –把复杂问题自顶向下逐层分解，再从分解 出的对象中抽象出相对简单的子问题。 –经过一系列分解和抽象，到最底层的问题 已经是很容易求解的了。

细化数据流图

在反复循环的分析过程中，不断细 化DFD（即把数据流图扩展到更低 的层次）。通过功能分解可以完成 DFD的细化，即将一些处理比较复 杂的功能再划分为若干个子功能。
修改开发计划

在分析过程中可能会不断地修改原 拟定的开发计划，这是正常的。
书写文档资料

在软件生命周期的各个阶段，作为阶段成 果的组成部分——文档资料，其作用如何 强调都不过份。本阶段应完成4份文档资料： – 系统规格说明 描述目标系统的概貌、 功能要求、性能、运行及将来可能提出 的要求。 – 用户系统描述 从用户角度描述系统， 类似一份用户手册初稿。 – 数据要求 包括DD、数据结构的层次框 图等。 – 修改的开发计划 包括成本估计、进度
是将复杂的大问题，分解为小问题，找 出问题的关键、重点所在，同时找出技 术难点来。然后用精确的思维定性、定 量地描述问题。 问题的核心是”分解“。如何划分？准 则是什么？ 实现的手段是”子程序“、”函数“， 即模块化。

“逐步求精”
将现实世界的问题经抽象转化为逻辑空间 或求解空间的问题。复杂问题经抽象化处 理变为相对较简单的问题。经几次抽象 （精化）处理，最后到求解域中只是非常 简单的编程问题。求解（抽象）过程可以 划分为若干个阶段，在不同阶段用不同工 具来描述。实现细则在前期阶段可以不去 管它。在每个阶段有不同的规划和标准， 产生出不同阶段的文档资料。 求解问题不是一下子就用计算机语言却描 述问题，而是分阶段；先用自然语言、DFD （数据流程图）等工具一步步地去抽象、 描述，最后用计算机语言却实现。