软件工程完整教程课件

软件工程(SoftwareEngineering)软件工程(SoftwareEngineering)1第1章：软件工程学概述1.1软件危机60年代中期以前：通用硬件相当普遍，软件却是为某个具体的应用而编写的。

60年代中到70年代中：软件作坊。第1章：软件工程学概述1.1软件危机2

软件危机：计算机软件的开发和维护过程中所遇到的一系列严重问题。（正常、不正常运行软件都具有这种问题）1.1.1软件危机的介绍软件危机：计算机软件的开发和维护过程中所遇到的一系列31）对软件开发成本和进度的估计常常很不准确；2）用户对完成的软件系统不满意的现象经常发生；3）软件产品的质量往往靠不住；软件危机的典型表现：1）对软件开发成本和进度的估计常常很不准确；软件危机的典型表44）软件常常是不可维护的；5）软件通常没有适当的文档资料；6）软件成本在计算机系统总成本中所占的比例逐年上升；7）软件开发生产率提高的速度跟不上计算机应用的发展趋势。4）软件常常是不可维护的；51.1.2产生软件危机的原因1）软件本身特点造成；2）软件开发与维护的方法不正确。主要表现：（a）忽视软件需求分析；（b）认为软件开发就是写程序并使之运行；（c）轻视软件维护；1.1.2产生软件危机的原因1）软件本身特点造成；主要表6

在软件开发的不同阶段进行修改需要付出的代价很不相同：高中低早期中期后期软件开发时期代价引入同一修改的代价随时间变化的趋势在软件开发的不同阶段进行修改需要付出的代价很不相同：71）推广使用在实践中总结出来的开发软件的成功技术和方法，并研究探索更有效的技术和方法；2）开发和使用更好的软件工具；3）良好的组织管理措施。

1.1.3解决软件危机的途径1）推广使用在实践中总结出来的开发软件的成功技术和方法，并研8

为了解决软件危机产生的问题，软件工程与方法学逐渐形成，然后出现了两个相互相承又各有侧重的学科：

1）软件工程学：主要应用工程的方法和技术研究软件开发与维护的方法、工具和管理的一门交叉学科。

2）程序设计方法学：主要应用数学的方法研究程序的性质以及程序设计的理论和方法的学科。

为了解决软件危机产生的问题，软件工程与方法学逐渐形成91.2软件工程1.2.1软件工程的介绍1968年NATO会议：软件工程就是为了经济地获得可靠的且能在实际机器上有效地运行的软件，而建立和使用完善的工程原理。1993年IEEE：软件工程是（1）把系统的、规范的、可度量的途径应用于软件开发、运行和维护过程；（2）研究（1）中提到的途径。1.2软件工程1.2.1软件工程的介绍1968年NAT101.软件工程关注于大型程序的构造；

2.软件工程的中心课题是控制复杂性；

3.软件经常变化；

4.开发软件的效率非常重要；

5.和谐地合作是软件开发的关键；

6.软件必须有效地支持它的用户；

7.在软件工程领域中是由具有一种文化背景的人替具有另一种文化背景的人创造产品。软件工程的本质特性：1.软件工程关注于大型程序的构造；软件工程的本质特性：111.2.2软件工程的基本原理1.用分阶段的生命周期计划严格管理；2.坚持进行阶段评审；3.实行严格的产品控制；4.采用现代程序设计技术；5.结果能清楚地审查；6.开发小组的人员应该少而精；7.承认不断改进软件工程实践的必要性。1.2.2软件工程的基本原理1.用分阶段的生命周期计划严121.2.3软件工程方法学

通常把在软件生命周期全过程中使用的一整套技术方法的集合称为方法学（Methodology），也称为范型（Paradigm）。软件工程方法学的3要素：方法、工具和过程1.2.3软件工程方法学131.传统方法学也称为生命周期方法学或结构化范型。结构化方法（StructureMethod）有：1）结构化设计方法（SD）；2）结构化分析方法（SA）；

3）结构化分析与设计技术（SADT）4）JACKSON方法5）WARNIER方法1.传统方法学142.面向对象方法学把数据和对数据的操作紧密结合起来的方法，模拟人类认识世界解决问题的方法和过程。

面向对象的方法=对象（属性与服务的封装）+分类+继承+通过消息的通讯2.面向对象方法学151）适用于实时事物处理系统的有限状态机方法（FSM）；2）适用于并发软件系统的PETRI网方法；3）以数学概念和理论为基础的形式化方法，如

SDC公司的形式化开发方法FDM：（FormalDevelopmentMethodology）IBM公司的维也纳开发方法VDM：

（ViennaDevelopmentMethod）

3.其他开发方法

1）适用于实时事物处理系统的有限状态机方法（FSM）；3.161.3软件生命周期软件生命周期：指软件从提出到最终被淘汰的这个存在期。1.3软件生命周期软件生命周期：17软件生命周期组成：

1）软件定义；

A.问题定义B.可行性研究C.需求分析

2）软件开发；

D.总体设计E.详细设计

F.编码和单元测试G.综合测试

3）运行维护。软件生命周期组成：181.问题定义；

2.可行性研究；

3.需求分析；

4.总体设计（概要设计）；

5.详细设计；

6.编码与单元测试；

7.综合测试；

8.维护。软件生命周期各个阶段：1.问题定义；软件生命周期各个阶段：191.4软件过程软件过程：为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。软件过程（ISO9000）：使用资源将输入转化为输出的活动所构成的系统。输入：如软件需求输出：如软件产品1.4软件过程软件过程：为了获得高质量软件所需要完成的一201.4.1瀑布模型1.阶段间具有顺序性和依赖性2.推迟实现的观点3.质量保证的观点1.4.1瀑布模型1.阶段间具有顺序性和依赖性21优点：采用规范的方法；严格规定每个阶段提交的文档；要求每个阶段交出的产品必须经过验证。优点：采用规范的方法；严格规定每个阶段提交的文档；要求每个阶221.4.2快速原型模型优点：不带反馈环，基本上是线性顺序进行。1.4.2快速原型模型231.4.3增量模型优点：能较短时间内提交可完成部分工作的产品；可以使用户有充裕的时间学习和适应新产品。1.4.3增量模型优点：能较短时间内提交可完成部分工作的产24一种风险更大的增量模型：一种风险更大的增量模型：251.4.4螺旋模型可把它看作在每个阶段之前都增加风险分析的快速原型模型。1.4.4螺旋模型26软件工程完整教程课件271.4.5喷泉模型典型的面向对象软件开发过程模型之一。1.4.5喷泉模型典型的面向对象软件开发过程模型之281.4.6Rational统一过程1.RUP软件开发经验（1）迭代式开发（2）管理需求（3）使用基于构件的体系结构（4）可视化建模（5）贯穿于开发过程的软件质量验证（6）控制软件变更1.4.6Rational统一过程1.RUP软件开发经291.4.7敏捷过程与极限编程1.敏捷过程具有高效、快速响应变化的开发过程。（1）个体和交互胜过过程和工具；（2）可以工作的软件胜过面面俱到的文档；（3）客户合作胜过合同谈判；（4）响应变化胜过遵循计划。2.极限编程敏捷过程中最著名的一种，指把好的开发实践运用到极致，多应用于软件需求模糊的场合。1.4.7敏捷过程与极限编程1.敏捷过程301.4.8微软过程1.微软过程准则2.微软软件生命周期（1）规划阶段（2）设计阶段（3）开发阶段（4）稳定阶段（5）发布阶段3.微软过程模型1.4.8微软过程1.微软过程准则31

问题定义就是要确定为用户建立什么样的软件系统，软件叫什么样的名称等等。“问题”是指软件最基本的问题，如：

软件的总体目标什么？有什么用途？

为那些用户设计？

1.5问题定义阶段问题定义就是要确定为用户建立什么样的软件系统，软件叫32问题定义报告的内容包括：

1）软件项目标题；

2）软件目标；

3）软件用户对象；

4）软件规模。问题定义报告的内容包括：33

问题定义是软件生命周期中时间最短的阶段，一般都比较简单，因此在实际开发中它是最容易被忽视的一个阶段。这一阶段工作主要由系统分析员来完成，系统分析员要尽可能从较高的角度概括软件所要做的工作，而不用写明问题的实现细节。

问题定义是软件生命周期中时间最短的阶段，一般都比较简34第2章：可行性研究

可行性研究就是要回答“所定义的问题有可行的解决办法吗？”。可行性研究的目的是：用最小的代价在尽可能短的时间内确定问题是否有解，以及是否值得去解。2.1可行性研究的任务第2章：可行性研究可行性研究就是要回答“所定义的问题35

可行性研究所需的时间取决于工程的规模，所需要的成本要占工程总成本的5%~10%。可行性研究所需的时间取决于工程的规模，所需要的成本要36可行性研究的内容：1）技术可行性技术可行性要分析各种技术因素，例如：使用现有的技术能否实现这个系统？是否有胜任开发该项目的熟练技术人员？能否按期得到开发该项目所需的软件、硬件资源？可行性研究的内容：372）经济可行性对经济合理性进行评价，所要考虑的问题是：

这个系统的经济效益能否超过它的开发成本？这就需要对项目进行价格/利益分析，即“投入/产出”分析。由于利益分析取决于软件系统的特点，因此在软件开发之前，很难对新系统产生的效益作出精确的定量描述，所以往往采用一些估算方法。2）经济可行性383）操作可行性操作可行性评价系统运行后会引起的各方面变化，如：对组织机构管理模式、用户工作环境等产生的影响。3）操作可行性394）社会可行性社会可行性主要讨论法律方面和使用方面的可行性。例如，被开发软件的权利归属问题、软件所使用的技术是否会造成侵权等问题。4）社会可行性402.2可行性研究的步骤1）复查系统规模和目标；2）研究目前正在使用的系统；3）导出新系统的高层逻辑模型（数据流图、数据字典）；4）重新定义问题；

2.2可行性研究的步骤1）复查系统规模和目标；415）导出和评价供选择的解法（物理解决方案）；6）推荐行动方案；7）草拟开发计划；8）书写文档提交审查。

2.2可行性研究的步骤5）导出和评价供选择的解法（物理解决方案）；2.2可行性422.3系统流程图（描绘物理系统的工具）2.3.1符号

符号名称说明处理如：程序，处理机，人工加工输入/输出连接换页连接数据流表示输入或输出同一页上图的连接不同页上图的连接指明数据流动方向图2.1基本符号2.3系统流程图（描绘物理系统的工具）2.3.1符号43符号名称说明穿孔卡片文档磁带联机存储磁盘磁鼓显示人工输入人工操作辅助操作通信链路穿孔卡片输入/输出，或穿孔卡片文件打印输出，或打印终端输入数据磁带输入/输出，或表示磁带文件任何种类磁盘存储，如磁盘、磁鼓等磁盘输入/输出，或磁盘上文件、数据库磁鼓输入/输出，或磁鼓上文件、数据库显示器部件人工输入数据，如填写表格人工完成的处理使用辅助设备进行的脱机操作通过远程通信线路传送数据图2.2系统符号符号名称说明穿孔卡片文档磁带联机存储磁盘磁鼓显示人工输入人工442.3.2例子

事务库存清单程序报告生成程序定货信息定货报告库存清单主文件图2.3库存清单系统的系统流程图2.3.2例子事务库存清单程序报告生成程序定货信息定货452.4数据流图（描绘数据在系统中流动的逻辑过程）2.4.1符号

或或或数据源点或终点变换数据的处理数据存储数据流图2.4基本符号的含义2.4数据流图（描绘数据在系统中流动的逻辑过程）2.4.46TABC*TABC*附加符号TABC+TABC+TABC*TABC*附加符号TABC+TABC+47注意：“处理”可表示：单个程序、一系列程序、程序的一个模块、人工处理过程等等；“数据存储”可表示：一个文件、文件的一部分、数据库记录等等；数据流图忽略出错处理、打开文件、关闭文件。注意：482.4.2绘制数据流图的例子

事务库存清单程序报告生成程序定货信息定货报告库存清单主文件图2.3库存清单系统的系统流程图2.4.2绘制数据流图的例子事务库存清单程序报告生成程序492.4.2绘制数据流图的例子

仓库管理员采购员定货系统事务定货报表图2.5定货系统的基本系统模型2.4.2绘制数据流图的例子仓库定货系统事务定货报表图2502.4.2绘制数据流图的例子库存清单仓库管理员采购员事务定货报表图2.6定货系统的功能级数据流图处理事务1产生报表2D1库存清单D2定货信息定货信息定货信息2.4.2绘制数据流图的例子库存清单仓库事务定货报表图51组成该例子的数据流图的元素源点/终点处理

采购员仓库管理员

产生报表处理事务数据流数据存储

订货报表零件编号零件名称订货数量目前价格主要供应商次要供应商事务零件编号事务类型数量

订货信息（见订货报表）库存清单零件编号库存量库存量临界值组成该例子的数据流图的元素源点/终点处理采购员产生报52

上述数据流图所描述的功能够详细了吗？上述数据流图所描述的功能够详细了吗？532.4.2绘制数据流图的例子仓库管理员采购员事务定货报表图2.7定货系统进一步分解后的数据流图更新库存清单1.2产生报表2D1库存清单D2定货信息接收事务1.1处理定货1.3库存清单定货信息定货信息2.4.2绘制数据流图的例子仓库事务定货报表图2.7定541）为数据流（或数据存储）命名A．名字应该代表整个数据流（或数据存储）的内容；B．不要使用空洞的、缺乏具体含义的名字（如“数据”、“输入”）；

2.4.3命名1）为数据流（或数据存储）命名2.4.3命名55C．如果为某个数据流（或数据存储）起名字时遇到困难，则很可能是因为对数据流图的分解不恰当造成的，应该试试重新分解数据流图；

C．如果为某个数据流（或数据存储）起名字时遇到困难，562）为处理命名A．通常先为数据流命名，然后再为与之相关联的处理命名；B．名字应该反映整个处理的功能；C．应该尽量避免空洞笼统的动词做名字，如“处理”、“加工”；

2）为处理命名57D．通常用一个动词命名，如果必须用两个动词才能描述整个处理的功能，则可能要把这个处理分解成两个处理更恰当；E．如果在为某个处理命名时遇到困难，则很可能是发现了分解不当的情况，应考虑重新分解。D．通常用一个动词命名，如果必须用两个动词才能描述整58通常，为“数据源点/终点”命名时，采用它们在问题域中习惯使用的名字（如“仓库管理员”、“采购员”）。通常，为“数据源点/终点”命名时，采用它们在问题域中591）利用它作为交流信息的工具；2）作为软件分析和设计的工具。2.4.4数据流图的用途

1）利用它作为交流信息的工具；2.4.4数据流图的用途602.4.4数据流图的用途仓库管理员采购员事务定货报表图2.8这种自动化边界建议以联机方式更新库存清单更新库存清单1.2产生报表2D1库存清单D2定货信息接收事务1.1处理定货1.3库存清单定货信息定货信息2.4.4数据流图的用途仓库事务定货报表图2.8这种61图2.8对应的物理实现硬件方案图2.8对应的物理实现硬件方案622.4.4数据流图的用途

仓库管理员采购员事务定货报表图2.9这种自动化边界暗示以批量方式更新库存清单更新库存清单1.2产生报表2D1库存清单D2定货信息接收事务1.1处理定货1.3库存清单定货信息定货信息D3事务2.4.4数据流图的用途仓库事务定货报表图2.9这63图2.9对应的物理实现硬件方案图2.9对应的物理实现硬件方案64

数据字典：对数据流图中包含的所有元素的定义的集合；可行性研究阶段，数据流图与数据字典共同构成系统的逻辑模型。2.5数据字典

数据字典：对数据流图中包含的所有元素的定义的集合；2652.5.1数据字典的内容数据字典应该对下列元素进行定义：

1）数据流；

2）数据元素（数据流分量）；

3）数据存储；

4）处理。

2.5.1数据字典的内容661）数据元素字典定义其定义的基本内容有：A．数据元素编号、名称及其含义；B．数据类型和长度；C．合理取值；D．其他内容，如它与其它数据的逻辑关系等。2.5.2定义数据的方法1）数据元素字典定义2.5.2定义数据的方法67数据元素字典定义实例：数据元素编号：DC001数据元素名称：考试成绩别名：成绩、分数简述：学生考试成绩，分五个等级类型/长度：两个字节，字符类型取值/含义：优[90-100]良[80-89]中[70-79]及格[60-69]不及格[0-59]有关数据项或结构：学生成绩档案有关处理逻辑：计算成绩

图2.10数据元素字典定义数据元素字典定义实例：数据元素编号：DC001图2.1682）数据流字典定义其定义的基本内容有：A．数据流编号及名称；B．数据流来源；C．数据流去处；D．数据流的组成；E．流通量；F．峰值。2）数据流字典定义69数据流字典定义实例：数据流编号：DF001数据流名称：订票单简述：订票时填写的订票单数据流来源：外部实体“乘客”数据流去处：处理逻辑“预订机票”数据流组成：订单编号日期乘客号航班号状态订单失效日期流通量：每天300份高峰值流通量：每天早上9：00，约160份图2.11数据流字典定义数据流字典定义实例：数据流编号：DF001图2.11数据流703）数据存储字典定义其定义的基本内容有：A．数据存储编号及名称；B．数据存储的组成；C．其它要求。3）数据存储字典定义714）数据处理字典定义其定义的基本内容有：A．数据处理编号及名称；B．简单描述；C．输入/输出；D．功能描述；E．有关数据存储。4）数据处理字典定义72数据处理字典定义实例：数据处理编号：DP001数据处理名称：编辑订票简述：接收从终端录入的订票单，检验是否正确输入：乘客订单，来源：外部实体“乘客”输出：1.合格订单，去处：处理逻辑“确定订票”2.不及格订单，去处：外部实体“乘客”功能描述：……（略）图2.12数据处理字典定义数据处理字典定义实例：数据处理编号：DP001图2.12数735）组成数据项的表示方法

=

表示“等价于”或“定义为”

+

表示“与”

[]与|

表示“或”

{}

表示重复

()

表示可选项通讯录={通讯地址}

通讯地址=姓名+邮编+[省|直辖市|自治区]+[市|县]+街道+门牌号+（电话）

5）组成数据项的表示方法741.作为分析阶段的重要工具；2.数据元素的控制信息非常有用；3.有助于开发数据库。2.5.3数据字典的用途1.作为分析阶段的重要工具；2.5.3数据字典的用途75实现数据字典：1）程序处理；2）卡片式人工书写；2.5.4数据字典的实现实现数据字典：2.5.4数据字典的实现762.6成本/效益分析1）代码行技术软件成本

=每行代码的平均成本×估计的源代码总行数

2.6.1成本估计2.6成本/效益分析1）代码行技术2.6.1成本估计772）任务分解技术

软件开发项目分解为若干个相对独立的任务，分别估计每个单独任务的成本：

单独任务成本=任务所需人力估计值×每人每月平均工资；

软件开发项目总成本估计=各个单独任务成本估计值之和。2）任务分解技术78

常用的办法是按开发阶段划分任务，典型环境下各个开发阶段需要使用的人力百分比大致如下：任务人力（％）可行性研究需求分析设计编码与单元测试综合测试总计510252040100常用的办法是按开发阶段划分任务，典型环境下各个开发阶793）自动估计成本技术采用自动估计成本的软件工具估计。

3）自动估计成本技术801）Putnam模型1978年Putnam提出的，一种动态多变量模型：软件开发成本估算的经验模型：1）Putnam模型软件开发成本估算的经验模型：81Ck为技术状态常数，它反映“妨碍开发进展的限制”，取值因开发环境而异，见下表：Ck的典型值开发环境开发环境举例2000差没有系统的开发方法，缺乏文档和复审8000好有合适的系统的开发方法，有充分的文档和复审11000优有自动的开发工具和技术Ck为技术状态常数，它反映“妨碍开发进展的限制”，取822）COCOMO模型(constructivecostmodel)

这是由TRW公司开发，Boehm提出的结构化成本估算模型，是一种精确的、易于使用的成本估算方法。基本COCOMO模型估算工作量和进度的公式如下：

工作量：

MM=r×(KDSI)c

（人月）

开发时间：

TDKV=a×(MM)b

（月）DSI：源指令条数，不包括注释，1KDSI=1000DSIMM：开发工作量（以人月计），1MM=19人日=152人时=1/12人年

经验常数r,c,a,b取决于项目的总体类型2）COCOMO模型(constructivecostm83COCOMO模型中，考虑开发环境，软件开发项目的类型可以分为3种：1）组织型(organic)相对较小、较简单的软件项目。开发人员对开发目标理解比较充分，与软件系统相关的工作经验丰富，对软件的使用环境很熟悉，受硬件的约束较小，程序的规模不是很大（<50000行）COCOMO模型中，考虑开发环境，软件开发项目的类型842）嵌入型(embedded)要求在紧密联系的硬件、软件和操作的限制条件下运行，通常与某种复杂的硬件设备紧密结合在一起。对接口，数据结构，算法的要求高。软件规模任意。如大而复杂的事务处理系统，大型/超大型操作系统，航天用控制系统，大型指挥系统等。2）嵌入型(embedded)853）半独立型（semidetached）介于上述两种软件之间。规模和复杂度都属于中等或更高。最大可达30万行。3）半独立型（semidetached）86COCOMO模型按其详细程度可以分为三级：1）基本COCOMO模型是一个静态单变量模型，它用一个以已估算出来的原代码行数(LOC)为自变量的经验函数计算软件开发工作量。COCOMO模型按其详细程度可以分为三级：87基本COCOMO模型通过统计63个历史项目的历史数据，得到如下计算公式：总体类型工作量所需开发时间组织型MM=2.4×(KDSI)1.05TDKV=2.5×(MM)0.38半独立型MM=3.0×(KDSI)1.12TDKV=2.5×(MM)0.35嵌入型MM=3.0×(KDSI)1.20TDKV=2.5×(MM)0.32基本COCOMO模型总体类型工作量所需开发时间组织型MM=882）中级COCOMO模型在基本COCOMO模型的基础上，再用涉及产品、硬件、人员、项目等方面的影响因素调整工作量的估算。3）详细COCOMO模型包括中级COCOMO模型的所有特性，但更进一步考虑了软件工程中每一步骤（如分析、设计）的影响。2）中级COCOMO模型891）货币的时间价值

假设年利率为i,如果现在存入P元钱，则n年以后可以得到的钱数为：

反之，如果n年后能收入F元钱，那么这些钱现在的价值是：2.6.2成本/效益分析1）货币的时间价值2.6.2成本/效益分析90例：修改一个已有的库存管理系统，估计需要5000元，系统修改后使用5年，每年可节省2500元。请进行成本/效益分析。例：修改一个已有的库存管理系统，估计需要5000元，91表1：将来的收入折算成现在值

年将来值（元）(1+0.12)n现在值（元）累计的现在值（元）125001.122232.142232.14225001.251992.984225.12325001.401779.456004.57425001.571588.807593.37525001.761418.579011.94表1：将来的收入折算成现在值年将来值（元）现在值（元）累计922）投资回收期第一、第二年回收：4225元

第三年用于回收投资要：(5000-4225)/1779=0.44年总的投资回收期=2.44年3）纯收入9011.94-5000=4011.94（元）2）投资回收期3）纯收入934）投资回收率

其中：P是现在的投资额；

Fi是第i年年底的效益（i=1,2,3,…,n）;

n是系统的使用寿命（一般假设n=5）；

j是投资回收率。上述修改系统的工程的投资回收率是41%-42%4）投资回收率94第2章小结

可行性分析报告说明该软件开发项目的实现在技术上、经济上和社会因素上的可行性，评述为了合理地达到开发目标可供选择的各种可能实施方案，说明并论证所选定实施方案的理由。

项目开发计划为软件项目实施方案制订出具体计划，应该包括各部分工作的负责人员、开发的进度、开发经费的预算、所需的硬件及软件资源等。第2章小结

可行性分析报告95第3章：需求分析3.1.1确定对系统的综合要求

1．功能需求

2．性能需求如：相应时间（速度）、主存容量、磁盘容量、安全性、等。3.1需求分析的任务第3章：需求分析3.1.1确定对系统的综合要求3.1963.可靠性和可用性需求4.出错处理需求系统发现错误时采取的行动，主要在系统关键部分设置。5.接口需求用户接口、硬件接口、软件接口、通信接口、等。6.约束精度、工具和语言、设计约束、硬件约束、标准，等。7.逆向需求8.将来可能提出的要求3.可靠性和可用性需求973.1.3导出系统的逻辑模型包括完善的数据流图、实体－联系图、状态转换图、数据字典、主要的处理算法（IPO图）等。3.1.2分析系统的数据要求通过建立数据模型来分析，如数据字典、层次方框图、Warnier图，并将数据结构规范化。3.1.4修正系统开发计划修订前期制定的开发进度计划、等。3.1.3导出系统的逻辑模型3.1.2分析系统的数据要求983.2与用户沟通获取需求的方法3.2.1访谈正式访谈：系统分析员提出事先准备好的问题。非正式访谈：提出一些用户可以自由回答的开放性问题，鼓励被访者说出自己的想法。需要访问大量人员时，利用调查表访问较佳。3.2与用户沟通获取需求的方法3.2.1访谈正式访993.2.2面向数据流自顶向下求精分析追踪数据流图用户复查细化数据流图有补充修正无补充修正需要分解不需分解图3.1需求分析基本过程借助数据流图、数据字典、IPO图等，细化、完善详细的数据流图，等到各处理环节对应的功能。3.2.2面向数据流自顶向下求精分析追踪数据流图用户复查100仓库管理员采购员事务定货报表定货系统数据流图更新库存清单1.2产生报表2D1库存清单D2定货信息接收事务1.1处理定货1.3库存清单定货信息定货信息例：分析销售趋势统计功能仓库事务定货报表定货系统数据流图1.22D1库存清单D2定货1013.2.3简易的应用规格说明技术面向团队的需求收集法：（用户与开发者配合）1）初步访谈；2）开发者和用户分别写出“产品需求”；3）开会讨论，各自展示需求列表；4）得出一致意见，为需求列表制定小型规格说明；5）根据会议成果，起草完整的软件需求规格说明。3.2.3简易的应用规格说明技术面向团队的需求收集法：1023.2.4快速建立软件原型

快速建立能演示目标系统主要功能的程序。（1）第四代技术（2）可重用的软件构件（3）形式化规格说明和原型环境3.2.4快速建立软件原型快速建立能演示目标系统主要功能1033.3分析建模与规格说明3.3.1分析建模为了开发复杂的系统，应从不同角度（模型）抽象出目标系统的特性（数据模型、功能模型、行为模型）。1）实体联系图：建立数据模型，描述数据对象及数据对象之间的关系；2）数据流图：建立功能模型的基础；3）状态转换图：描绘系统的状态和状态间转换的方式。3.3.2软件需求规格说明3.3分析建模与规格说明3.3.1分析建模3.3.2软1043.4实体－联系图

数据对象可以是外部实体、事物、行为、事件、角色、单位、地点、结构等。数据对象3.4.1数据对象3.4实体－联系图数据对象可以是外部实体、事物、1053.4.2属性属性定义了数据对象的性质。属性3.4.2属性属性1063.4.3联系（1）一对一联系（1：1）（2）一对多联系（1：N）（3）多对多联系（M：N）在ER图中，用菱形框表示联系。

联系3.4.3联系联系107教师学生课程学号姓名系年级职务性别职称性别姓名教工号教学成绩学分学时课名课程号图3.2某校教学管理ER图MN1N例子：教师学生课程学号姓名系年级职务性别职称性别姓名教工号教学成绩108通常用范式定义消除数据冗余的程度。

1）第一范式

2）第二范式

3）第三范式3.5数据规范化通常用范式定义消除数据冗余的程度。3.5数据规范化1093.6状态转换图3.6.1状态状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。3.6.2事件事件是某个特定时刻发生的事情，它是引起系统做动作或状态转换的控制信息。3.6状态转换图3.6.1状态1103.6.3符号3.6.3符号1113.6.4例子3.6.4例子1123.7其他图形工具

层次方框图用树形结构的一系列多层次的矩形框描绘数据的层次结构。

产品硬件软件服务处理机存储器外部设备系统软件应用软件软件服务硬件维修培训编译程序软件工具操作系统图3.5层次方框图的一个例子3.7.1层次方框图3.7其他图形工具层次方框图用树形结构的一系列多层次113Warnier图也用树形结构描绘信息，但是这种图形工具比层次方框图提供了更丰富的描绘手段。

软件产品软件工具编辑程序（P3）应用软件编译程序（P2）操作系统（P1）系统软件测试驱动程序（P4）设计辅助工具（P5）⊕图3.4Warnier图的一个例子3.7.2Warnier图Warnier图也用树形结构描绘信息，但是这种图形工114IPO图是输入/处理/输出图。旧的主文件事务文件1.校验主记录2.校验事务记录3.更新主记录有效的主记录有效的事务记录更新后的主文件输入处理输出图3.7IPO图的一个例子3.7.3IPO图IPO图是输入/处理/输出图。旧的主文件1.校验主记录有效115IPO表系统：模块：编号：作者：日期：被调用：调用：输入：输出：处理：局部数据元素：注释：图3.8改进的IPO图的形式IPO表系统：模块：编号：作者：日期：被调用：调用：输入：输1163.8验证软件需求1）一致性2）完整性3）现实性4）有效性3.8.1验证软件需求的正确性3.8验证软件需求1）一致性3.8.1验证软件需求的1171）验证需求的一致性2）验证需求的现实性3）验证需求的完整性和有效性

3.8.2验证软件需求的方法1）验证需求的一致性3.8.2验证软件需求的方法118用于需求分析的软件应该满足下列要求：

1）必须有形式化的语法

2）使用这个软件工具能够导出详细的文档

3）必须提供分析规格说明书的不一致性和冗余性的手段

4）使用这个软件工具后，应该能够改进通信状况3.8.3用于需求分析的软件工具用于需求分析的软件应该满足下列要求：3.8.3用于需求分119

RSL（需求陈述语言）：信息集ASSMPASCAL模拟程序

PSL/PSA（问题陈述语言/问题陈述分析程序）系统

RSL（需求陈述语言）：信息集ASSM120第3章小结

软件需求说明书（软件规格说明书）

对所开发软件的功能、性能、用户界面及运行环境等作出详细的说明。它是在用户与开发人员双方对软件需求取得共同理解并达成协议的条件下编写的，也是实施开发工作的基础。该说明书应给出数据逻辑和数据采集的各项要求，为生成和维护系统数据文件做好准备。第3章小结

软件需求说明书（软件规格说明书）121第4章：形式化说明技术1.非形式化方法：自然语言描述2.半形式化方法：数据流图或实体－联系图3.形式化方法：基于数学技术描述第4章：形式化说明技术1.非形式化方法：自然语言描述1224.1概述4.1.1非形式化方法的缺点自然语言书写的系统规格说明书可能存在：

1）矛盾；2）二义性；如：“操作员标识由操作员姓名和密码组成，密码由6位数字构成，当操作员登陆系统时它被存储在注册文件中。”3）含糊性；

4）不完整性；

5）抽象层次混乱。4.1概述4.1.1非形式化方法的缺点1234.1.2形式化方法的优点（1）数学是理想的建模工具，适合于表示系统状态和描述系统需求；（2）用数学表达的需求可在不同开发阶段平滑过渡。4.1.3应用形式化方法的准则（1）选择合适的形式化方法；（2）需要形式化，但不能过渡形式化，不能放弃传统的需求表达方法；（3）应该有形式化方法的专家提供指导。4.1.2形式化方法的优点4.1.3应用形式化方法的1244.2有穷状态机法（FSM）4.2.1概念锁的三个位置：1、2、3；转盘可向左（L）或右（R）；锁密码：1L、3R、2L4.2有穷状态机法（FSM）4.2.1概念锁的三个位125软件工程完整教程课件126一个有穷状态机包括5部分：

1）状态集J：{保险箱锁定，A，B，保险箱解锁，报警}2）输入集K：{1L,1R,2L,2R,3L,3R}3）转换函数T，如表4.14）初始状态S：保险箱锁定5）终态集F：{保险箱解锁，报警}更形式化的术语：一个有穷状态机可表示一个为5元组（J,K,T,S,F）一个有穷状态机包括5部分：127状态转换形式：当前状态【菜单】＋事件【所选择的项】＝>下个状态加入谓词集P，把系统扩展成一个6元组后：当前状态【菜单】＋事件【所选择的项】＋谓词＝>下个状态计算机系统中每个菜单驱动的用户界面都是一个有穷状态机的实现。状态转换形式：计算机系统中每个菜单驱动的用户界面都是128定义状态：（1）M(d,e,f)：电梯e正沿d方向移动，即将到达第f层楼。（2）S(d,e,f)：电梯e停在f层楼，将朝d方向移动（未关门）。（3）W(e,f)：电梯e在f层等待（已关门）。（4）DC(e,f)：电梯e在楼层f关上门。（5）ST(e,f)：电梯e靠近f层时触发传感器，电梯控制器决定在当前楼层是否停下。（6）RL：电梯按钮或楼层按钮被按下进入打开状态4.2.2例子:电梯的状态转换定义状态：4.2.2例子:电梯的状态转换129电梯状态转换规则：①S(U,e,f)+DC(e,f)=>M(U,e,f+1);②S(D,e,f)+DC(e,f)=>M(D,e,f-1);③S(N,e,f)+DC(e,f)=>W(e,f)电梯状态转换规则：①S(U,e,f)+DC(e,f)=>M(1304.2.3评价有穷状态机描述规格说明：

当前状态＋事件＋谓词=>下个状态易于书写、验证、转变成设计或程序代码。有穷状态机方法比数据流图技术更精确，一样易于理解。但不能处理定时需求。4.2.3评价有穷状态机方法比数据流图技术更精确，一样易1314.3Petri网4.3.1概念4.3Petri网4.3.1概念132Petri网包含4种元素：1）一组位置P，上例P＝{P1,P2,P3,P4}2）一组转换T，上例T＝{t1,t2}3）输入函数I，上例I（t1）={P2,P4}

I（t2）={P2}4）输出函数O，上例O（t1）={P1}O（t2）={P3,P3}更形式化的Petri网结构，是一个4元组（P，T，I，O）Petri网包含4种元素：133权标向量（1，2，0，1）权标向量（1，2，0，1）134权标向量（2，1，0，0）权标向量（2，1，0，0）135权标向量（2，0，2，0）权标向量（2，0，2，0）136更形式化地：标记M：P－>{0,1,2,…}Petri网成为一个5元组（P，T，I，O，M）更形式化地：137对Petri网的一个重要扩充是加入禁止线：对Petri网的一个重要扩充是加入禁止线：1384.3.2例子1.电梯按钮EBf

电梯中楼层f的按钮；Fg

楼层g；Ff

楼层f。4.3.2例子EBf电梯中楼层f的按钮；Fg楼层1392.楼层按钮FBfu

第f楼层向上按钮；FBfd

第f楼层向下按钮；2.楼层按钮FBfu第f楼层向上按钮；FBfd140小结基于数学的形式化说明技术，目前还没有在软件产业界广泛应用；应该把形式化方法与传统方法有机结合。小结141第5章：总体设计5.1设计过程

1.设想供选择的方案

2.选择合理的方案对每个合理的方案要提供：

A．系统流程图

B．组成系统的物理元素清单

C．成本/效益分析

D．实现这个系统的进度计划第5章：总体设计5.1设计过程1.设想供选择的方案1423.推荐最佳方案4.功能分解5.设计软件结构6.数据库设计A．模式设计B．子模式设计C．完整性和安全性设计D．优化3.推荐最佳方案1437.制定测试计划8.书写文档

A．系统说明

B．用户手册

C．测试计划

D．详细的实现计划

E．数据库设计结果9.审查和复审

7.制定测试计划1445.2设计原理如果一个大型程序仅由一个模块组成，很难被人理解。设函数C(x)定义问题x的复杂程度，函数E(x)定义解决问题x需要的工作量（时间）。对于两个问题P1和P2，如果：

C(P1)>C(P2)

那么E(P1)>E(P2)根据解决问题的经验，有一个规律是：

C(P1+P2)>C(P1)+C(P2)于是有E(P1+P2)>E(P1)+E(P2)

5.2.1模块化5.2设计原理如果一个大型程序仅由一个模块组成145模块数目接口成本成本/模块软件总成本M最小成本区成本图5.1模块化与软件成本模块数目接口成本成本/模块软件总成本M最小成本区成本图5.11465.2.2抽象

5.2.3逐步求精模块的独立性很重要，因为：1）有效的模块化的软件比较容易开发出来;2）独立的模块比较容易测试和维护。5.2.4信息隐蔽和局部化5.2.5模块独立5.2.2抽象5.2.3逐步求精模块的独立性很重要147一、耦合

耦合：指软件结构内不同模块彼此之间相互依赖（连接）的紧密程度。模块独立程度可以由两个定性标准度量：耦合与内聚。一、耦合耦合：指软件结构内不同模块彼此之间相互依赖148模块的偶合分四类：1）数据耦合两个模块之间只是通过参数交换信息，而且交换的信息仅仅是数据。数据耦合是最低程度的耦合。AB数据（1）数据耦合模块的偶合分四类：AB数据（1）数据耦合1492）控制耦合两个模块之间所交换的信息包含控制信息。控制耦合是中等程度的耦合。图中模块A的内部处理程序判断是执行C还是执行D，要取决于模块B传来的信息状态（Status）。BACD（2）控制耦合astatus2）控制耦合图中模块A的内部处理程序判断是执行C还是执行1503）公用耦合两个或多个模块通过一个公共区相互作用时的耦合。公共区可以是：全程数据区、共享通信区、内存公共覆盖区、任何介质上的文件、物理设备等。软件结构中存在大量的公用耦合时会给诊断错误带来困难。

3）公用耦合151图中存在公用耦合，假设模块A、C、E都存取全程数据区（如公用一个磁盘文件）中的一个数据项。如果A模块读取该项数据，然后调用C模块对该项重新计算，并进行数据更新。ABCDE全程数据区（3）公用耦合图中存在公用耦合，假设模块A、C、E都存取全程数据区（如152如果此时C模块错误地更新了该项数据，在往下的处理中模块E读该数据项时出现错误。表面上看，问题由模块E产生，实际上由模块C引起。ABCDE全程数据区（3）公用耦合如果此时C模块错误地更新了该项数据，在往下的处理中模块E1534）内容耦合

一个模块与另一个模块的内容直接发生联系。内容耦合对维护会带来严重的困难。

模块A…LAB：MOVE1…模块B…GOTOLAB…内容耦合（4）内容耦合程序中如果一个模块直接把程序转移到另一个模块中，或一个模块使用另一个模块内部的数据，都会产生内容耦合。内容耦合是最高程度的耦合，应该避免采用。4）内容耦合模块A模块B内容耦合（4）内容耦合程序中如果154

软件设计应追求尽可能松散耦合，避免强耦合，这样模块间的联系就越小，模块的独立性就越强，对模块的测试、维护就越容易。因此建议：尽量使用数据耦合，少用控制耦合，限制公用耦合，完全不用内容偶合。

软件设计应追求尽可能松散耦合，避免强耦合，这样模块间的联155二、内聚

内聚：一个模块内部各个元素彼此结合的紧密程度。它是衡量一个模块内部组成部分间整体统一性的度量。常见的内聚有七类。二、内聚内聚：一个模块内部各个元素彼此结合的紧密程1561）功能内聚（FunctionalCohesion）如果一个模块内所有处理元素完成一个，而且仅完成一个功能，则称为功能内聚。功能内聚是最高程度的内聚。但在软件结构中，并不是每个模块都能设计成一个功能内聚模块。1）功能内聚（FunctionalCohesion）1572）顺序内聚（SequentialCohesion）如果一个模块内处理元素和同一个功能密切相关，而且这些处理元素必须顺序执行，则称为顺序内聚。

2）顺序内聚（SequentialCohesion）158

如图，一个求一元二次方程根的模块由三个处理元素组成，该模块中存在顺序内聚。通常，顺序内聚中一个处理元素的输出是另一个处理元素的输入。

求一元二次方程根模块1．输入方程系数2．求解3．打印方程的解顺序内聚示例如图，一个求一元二次方程根的模块由三个处理元素组成，该模1593）通信内聚（CommunicationalCohesion）如果一个模块中所有处理元素都使用同一个输入数据和（或）产生同一个输出数据，称为通信内聚。

3）通信内聚（CommunicationalCohesio160如图，模块A的处理单元将根据同一个数据文件FILE的数据产生不同的表格，因此它存在通信内聚。通信内聚有时也称为数据内聚。A从文件FILE中读出数据1.由数据产生报表A2.由数据产生报表B通信内聚示例如图，模块A的处理单元将根据同一个数据文件FILE的1614）过程内聚（ProceduralCohesion）如果一个模块内的处理元素是相关的，而且必须以特定的次序执行，称为过程内聚。过程内聚与顺序内聚的区别是：顺序内聚中是数据流从一个处理单元流到另一个处理单元，而过程内聚是控制流从一个动作流向另一个动作。

4）过程内聚（ProceduralCohesion）1625）时间内聚（TemporalCohesion）如果一个模块包含的任务必须在同一段时间内执行，称为时间内聚。也称为瞬时内聚。5）时间内聚（TemporalCohesion）163

例如，完成各种初始化工作的模块，或者处理故障的模块都存在时间内聚。如图，在“紧急故障处理模块”中，“关闭文件”、“报警”、“保留现场”等任务都必须无中断地同时处理。紧急故障处理模块1．关闭文件2．报警3．保留现场时间内聚示例例如，完成各种初始化工作的模块，或者处理故障的模块都1646）逻辑内聚（LogicalCohesion）如果模块完成的任务在逻辑上属于相同或相似的一类，称为逻辑内聚。6）逻辑内聚（LogicalCohesion）165如图，A、B、C模块合并成ABC模块之后，ABC模块就是逻辑内聚模块。XYZABCXYZABC合并逻辑内聚示例如图，A、B、C模块合并成ABC模块之后，ABC模块就是166对逻辑内聚模块的调用，常常需要有一个功能开关，由上层调用模块向它发出一个控制信号，在多个关联性功能中选择执行某一个功能。这种内聚较差，增加了模块之间的联系，不易修改。对逻辑内聚模块的调用，常常需要有一个功能开关，由上层调用1677）偶然内聚（CoincidentalCohesion）如果一个模块由完成若干毫无关系的功能处理元素偶然组合在一起的，就叫偶然内聚。7）偶然内聚（CoincidentalCohesion）168

偶然内聚是最差的一种内聚。常犯这种错误的一种情况是：有时在写完程序后，发现一组语句在多处出现，于是为了节省空间而将这些语句作为一个模块设计，就出现偶然内聚。偶然内聚是最差的一种内聚。169如图，模块A、B、C出现公共代码段W，于是将W独立成一个模块，而W中这些语句并没有任何联系。如果在测试中发现模块A不需要做“X=Y+Z”，而应该做“X=Y*Z”，此时对W的维护就很困难了。ABCW模块X=Y+ZGETCARDIFI=5THENE=0…偶然内聚示例如图，模块A、B、C出现公共代码段W，于是将W独立成170

软件设计中应该：力求做到高内聚，尽量少用中内聚，不用低内聚。

软件设计中应该：力求做到高内聚，尽量少用中内聚，不用低内1715.3启发式规则1.改进软件结构提高模块独立性2.模块规模应该适中3.深度、宽度、扇出和扇入都应适当

深度：软件结构中控制的层数；

宽度：软件结构内同一个层次上的模块总数的最大值；

扇出：一个模块直接控制（调用）其它模块的数目；

扇入：一个模块被其它模块调用的数目。

正文加工系统输入输出编辑加标题存储检索编目录格式化添加删除插入修改合并列表5.3启发式规则1.改进软件结构提高模块独立性3.172对扇出、扇入过大的改进：

（a）对扇入过大的改进（b）对扇出过大的改进对扇出、扇入过大的改进：（a）对扇入过大的改进（b）对扇出1734.模块的作用域应该在控制域之内

MAGBCEDF图5.2模块的作用域和控制域作用域：受该模块内一个判定影响的所有模块的集合。控制域：模块本身以及所有从属于它的模块的集合。4.模块的作用域应该在控制域之内MAGBCEDF图5.2174如：QUAD-ROOT（TBL,X）求一元二次方程的根的模块，其中TBL，X都为数组，分别代表方程的系数和方程的根。应该使接口更简单，如：

QUAD-ROOT（A,B,C,ROOT1,ROOT2）

A、B、C是方程的系数，ROOT1，ROOT2是方程的根。5.力争降低模块接口的复杂度如：QUAD-ROOT（TBL,X）5.力争降低1756.设计单入口、单出口的模块7.模块功能应该可以预测6.设计单入口、单出口的模块7.模块功能应该可以预测1765.4图形工具5.4.1层次图和HIPO图

正文加工系统输入输出编辑加标题存储检索编目录格式化添加删除插入修改合并列表图5.3正文加工系统的层次图5.4图形工具正文加工系统输入输出编辑加标题存储检索编目录177正文加工系统输入1.0输出2.0编辑3.0加标题4.0存储5.0检索6.0编目录7.0格式化8.0添加3.1删除3.2插入3.3修改3.4合并3.5列表3.6图5.4带编号的层次图（H图）HIPO图是：“层次图＋输入/处理/输出图”正文加工系统输入输出编辑加标题存储检索编目录格式化添加删除插1785.4.2结构图产生最佳解得到好输入计算最佳解输出结果读输入编辑输入结果格式化显示结果图4.5结构图的例子—产生最佳解的一般结构5.4.2结构图产生最佳解得到好输入计算最佳解输出结果读179MAB图5.6判定为真时调用A，为假时调用BMABC图5.7模块M循环调用模块A、B、CMAB图5.6判定为真时调用A，为假时调用BMABC图5.1805.5面向数据流的设计方法面向数据流设计（DataFlow-OrientedDesign，DFOD）是与数据流分析（DFA）对应的结构化软件设计技术。面向数据流的设计将得到以数据流图为基础的软件模块结构图。

5.5面向数据流的设计方法面向数据流设计（Data181数据流可以分为两种类型：

1）变换型数据流

2）事务型数据流

5.5.1变换流与事务流数据流可以分为两种类型：5.5.1变换流与事务流182一、变换流

具有较明确的输入、变换（或称主加工）和输出界面的数据流图称为变换型数据流图。如图所示，该变换中心可以理解为数据的加工和处理程序。

读入原始数据校验原始数据计算最优结果编辑打印最优结果输入变换中心输出一、变换流读入原始数据校验原始数据计算最优结果编辑打印最优结183

事务型数据流图中存在一个事务中心（也就是数据处理、加工中心），它将输入分离成若干个发散的数据流，形成许多活动路径，并根据输入值选择其中一条路径。要求类别处理分房处理调房处理退房处理住房要求事务中心活动路径二、事务流事务型数据流图中存在一个事务中心（也就是数据处理、加工中184

通常，一个实际系统的数据流图是变换型和事务型两种类型的混合体。如图所示，中间的子块属事务型数据流，如果把中间子块视为一个处理整体的话，整个程序属变换型程序。

A（事务型，A为事务中心）变换中心输入输出混合型数据流图通常，一个实际系统的数据流图是变换型和事务型两种类型的混185面向数据流设计软件结构的基本步骤有七步：

1）复审并精化数据流图；

2）确定数据处理流图的类型；

3）确定变换中心或事务中心；5.5.2面向数据流设计的步骤面向数据流设计软件结构的基本步骤有七步：5.5.2面向数1864）将数据流图映射成软件模块结构图，设计出该数据流图对应的第一层模块结构；5）基于数据流图逐步分解，设计下层模块；6）运用模块设计和优化准则优化软件结构；7）描述模块的接口。4）将数据流图映射成软件模块结构图，设计出该数据流图对应的第187复查、精化数据流图类型找出事务中心找出变换中心映射成事务结构映射成变换结构优化软件模块结构导出模块结构复查不满意变换事务变换设计事务设计面向数据流的设计步骤复查、精化数据流图类型找出事务中心找出变换中心映射成事务结构188

变换设计就是从变换型数据流图映射出软件模块结构的过程，也称以变换为中心的设计。

5.5.3变换设计变换设计就是从变换型数据流图映射出软件模块结构的过程，也189变换设计的基本方法有两步：1）分解第一层模块结构

就是把整个变换分解成输入控制模块Ci、输出控制模块Co和变换中心控制模块Ct，由主控模块控制。主控模块输出控制模块Co变换中心控制模块Ct输入控制模块Ci变换设计的基本方法有两步：主控模块输出控制模块Co变换中心控1902）分别设计输入、输出和处理的下层模块结构方法是：

从变换中心边界向两侧移动，分别把输入通路和输出通路的每个处理映射成输入控制模块Ci和输出控制模块Co的下属模块。变换中心的下层模块，是把每个处理映射成变换中心控制模块Ct的一个直接下属模块。2）分别设计输入、输出和处理的下层模块结构191ABCDFEGHIJK变换中心输入输出主控模块输出控制模块Co变换中心控制模块Ct输入控制模块CiDCBAEFGIHJKABCDFEGHIJK变换中心输入输出主控模块输出控制模块C192

事务设计就是从事务型数据流图映射出软件模块结构的过程，也称为以事务为中心的设计。5.5.4事务设计事务设计就是从事务型数据流图映射出软件模块结构的过程193事务设计的基本方法有两步：

1）建立主控模块、接收输入类型分析模块和事务调度模块；主模块调度输入类型分析事务设计的基本方法有两步：主模块调度输入类型分析1942）分别设计输入类型分析模块和调度模块的下层模块结构。方法是：将输出的每条通路作为调度模块的一个判断分支，而输入类型分析模块的下层模块与变换设计类似。

2）分别设计输入类型分析模块和调度模块的下层模块结构。195I2I3I1TCA1B1C1A2B2C2事务中心主模块调度输入类型分析I1I3I2A1A2B1B2C1C2I2I3I1TCA1B1C1A2B2C2事务中心主模块调度输196第5章小结

概要设计说明书该说明书是概要实际阶段的工作成果，它应说明功能分配、模块划分、程序的总体结构、输入输出以及接口设计、运行设计、数据结构设计和出错处理设计等，为详细设计提供基础。第5章小结

概要设计说明书197第6章：详细设计目标：确定如何具体实现所要求的系统。不是具体编写程序，而是设计程序的“蓝图”。详细设计的结果决定最终程序代码的质量。第6章：详细设计目标：确定如何具体实现所要求的系统。198E.W.Dijkstra最早提出结构程序设计：程序质量与程序中包含的Goto语句的数量成反比（1965）。1966，Bohm,Jacopini，证明了只用“顺序”、“选择”、“循环”控制结构就能实现任何单入口单出口程序。6.1结构程序设计

E.W.Dijkstra最早提出结构程序199理论上，最基本的控制结构只有两种：顺序、循环结构（选择结构可由其两者构造）。

学界认识到，不是简单去掉Goto语句的问题，而是要创立一种新的程序设计方法。

——结构化程序设计（IBM率先成功运用）。理论上，最基本的控制结构只有两种：顺序、循环200结构程序设计：