2.1 结构化开发方法

2.1.1 结构化开发方法简介

结构化开发方法（Structured Method，SM），是自顶向下的结构化方法、工程化的系统开发方法和生命周期法的结合，它是迄今为止所有开发方法中应用最普遍、最成熟的一种。该方法由E.Yourdon和L.L.Constantine在1978年提出，1979年Tom DeMarco对此方法做了进一步的完善，到20世纪80年代得到最广泛的应用。

结构化开发方法主要是按照功能来划分系统的结构，它把系统看作是由功能组成的，功能是指根据给定的输入数据，进行相应的处理转换，然后输出结果，即“输入数据→处理转换→输出数据”这样的过程，如图2-1所示。结构化开发方法的核心思想是用功能及其之间的数据流动关系来解释系统的运作过程，具体来说，结构化开发方法是用系统工程的思想和工程化的方法，遵循用户至上的原则，结构化、模块化、自顶向下地对系统进行分析与设计，即首先考虑整个系统的功能，然后按照模块划分的一些基本原则对功能进行分解，把整个系统划分成多个模块，每个模块实现特定的子功能。为了提高系统的内聚性，在模块中还会把功能分解到更小的子模块中，在完成所有的模块设计后，将模块一个个拼接到一起，自底向上、逐步地构成整体系统。系统可看作是多个子系统的集合，每个子系统都具有输入输出的功能模块。

结构化开发方法主要强调自顶向下整体性的分析与设计和自底向上逐步实施的系统实施过程，即在系统分析与设计时要从全局考虑，要自顶向下地工作；而在系统实施时，则要根据设计的要求先编制一个个具体的功能模块，然后自底向上逐步实现整个系统。通过这样的模块化处理，程序被划分为若干模块，而每个模块完成一个子功能，把这些模块汇总起来就构成了一个有机整体，可以用来实现指定的功能，从而降低了软件复杂度，并使软件设计、调试和维护等操作变得更简单。

图2-1 结构化软件系统结构模型

2.1.2 结构化开发方法的开发步骤

针对信息系统生命周期各个不同的阶段，结构化开发方法将系统的开发过程分为结构化系统分析（Structured Analyze，SA）、结构化系统设计（Structured Design，SD）和结构化程序设计（Structured Program，SP）3个阶段。

（1）结构化系统分析

旧的系统（人工系统或信息系统）如果不再适应发展变化的环境，就可能提出开发新系统的要求，并做出新系统的开发规划。系统分析是系统开发工作的第一个阶段，它以系统规划中提出的目标为出发点：首先经过初步的系统调查，获取用户对新系统的基本需求，并据此确定新系统应具有的逻辑功能；然后通过详细调查掌握原系统的运作原理，得到原系统的逻辑模型，其内容主要包括两个方面——管理业务流程的调查和数据流程的调查，通常采用功能层次图、数据流程图、数据字典等工具来描述调查结果；接着综合前两步的调查结果进行系统化分析，建立新系统的逻辑模型；最后总结系统分析的结果，写出“系统分析报告”，这是系统分析阶段的文档，也是下一步开发阶段的工作基础。

（2）结构化系统设计

系统设计阶段是指在系统分析阶段提出的新系统逻辑模型的基础上设计系统的物理方案，其主要内容包括总体结构设计、系统运行平台设计、系统接口设计、系统网站设计、系统数据库设计等，系统设计阶段的成果是“系统设计说明书”。

（3）结构化程序设计

程序设计阶段的任务是按照设计阶段的成果，组织人员编写程序以实现系统，并进行人员培训、数据准备和试运行等工作。这一阶段的成果，除了最终实现的系统外，还包括有关的技术文档（如程序说明书、使用说明书等），至此，一个新的信息系统便开始了它的生命周期。

2.1.3 结构化开发方法的特点

结构化开发方法的关键思想就是通过功能分解来减少程序设计的复杂性，并且增加软件的可重用性，以减少开发和维护的费用，它具有以下优点。

1）从系统整体出发，强调在整体优化的条件下“自上而下”地分析和设计，保证了系统的整体性和目标的一致性。

2）强调功能抽象和模块化，采取分块处理问题的方法，把一个比较复杂的问题分解为若干个容易处理的部分，降低了问题处理的难度。

3）严格区分系统开发的工作阶段，每一阶段及时总结、发现、反馈和纠正，避免造成浪费和混乱，且每一阶段的工作成果是下一阶段的依据，便于系统开发的管理和控制。

4）按工程标准建立标准化的文档资料，大大简化了编程人员繁杂的工作，也便于软件在以后的维护。

结构化开发方法也存在一些不足之处。

1）系统开发周期长，难于适应环境变化。

2）对于结构化程度较低的系统，在开发初期难以锁定功能要求。

该方法适用于规模较大、结构化程度较高的系统的开发，这类系统业务处理过程规范、数据需求非常明确，在一定时期内需求变化不大。

结构化开发方法在20世纪70年代或80年代时期还可以适应，但在越来越复杂的非数值计算类型的软件系统开发中，在广泛应用图形界面的交互式应用中，在控制要求非常突出的系统中，在需求经常变动的环境下，这种方法暴露出了许多弊病。

1）功能与数据分离的系统设计结构与人类的现实世界环境很不一样，和人的自然思维也就不一致了，因此对现实世界的认识与系统编程之间存在着一道很深的理解上的鸿沟。

2）系统是围绕着如何实现一定的行为来进行的，即按照功能来划分系统，当用户需求发生变化，比如要求修改现有系统功能的实现方式或者要求追加新的功能时，修改就变得极为困难。这类系统的结构是基于上层模块必须掌握和控制下层模块工作的前提，因此在底层模块发生变化时，常常会迫使不得已去改变一系列的上层模块，新的上层模块也必须了解它的所有下层模块，编写这样的上层模块当然是极为困难的，从而导致这种结构无法适应技术的迅速发展和当代社会的进展要求。

3）在系统中模块之间的控制作用有重要影响时，也就是说，实际的控制发生的根源来自分散的各个模块时，模块间的控制作用只能通过上下之间的调用关系来进行，造成信息传递路径过长、效率低，易受干扰甚至出错。如果允许模块间为进行控制而直接通信，结果则是系统总体结构混乱，也将难于维护、难于控制，出错率高，因此这种结构是无法适应以控制关系为重要特性的系统要求的。

4）用这种方法开发出来的系统往往难以维护，主要是因为所有的函数都必须要知道数据结构，可是许多不同数据类型的数据结构只有细微的差别，这种情况的函数中常常充满了条件语句，但它们与函数的功能毫无关系，只是因为数据结构的不同而不得不使用它们，结果使程序变得非常难读。

5）自顶向下功能分解的分析设计方法极大地限制了系统的可重用性，导致大量的重复性工作，大大降低了开发人员的效率。