第1章：软件工程学概述

第1章：软件工程学概述

1.1软件危机

60年代中期以前：通用硬件相当普遍，软件却是为某个具体的应用而编写的。

60年代中到70年代中：软件作坊。

软件危机：计算机软件的开发和维护过程中所遇到的一系列严重问题。（正常、不正常运行软件都具有这

种问题）

1.1.1软件危机的表现

1）对软件开发成本和进度的估计常常很不准确：

2）用户对完成的软件系统不满意的现象经常发生；

3）软件产品的质量往往靠不住；

软件危机的典型表现：

4）软件常常是不可维护的；

5）软件通常没有适当的文档资料；

6）软件成本在计算机系统总成本中所占的比例逐年上升；

7）软件开发生产率提高的速度跟不上计算机应用的发展趋势。

1.1.2产生软件危机的原因

1）软件本身特点造成；

2）软件开发与维护的方法不正确。

主要表现：

（a）忽视软件需求分析；

<b）认为软件开发就是写程序并使之运行；

（c）轻视软件维护；

在软件开发的不同阶段进行修改需要付出的代价很不相同：

1）推广使用在实践中总结出来的开发软件的成功技术和方法，并研究探索更有效的技术和方法；

2）开发和使用更好的软件工具；

3）良好的组织管理措施。

1.1.3解决软件危机的途径

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

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

科。

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

1.2软件工程

1.2.1软件工程的介绍

1968年NATO会议：软件工程就是为了经济地获得可靠的且能在实际机器上有效地运行的软件，而

建立和使用完善的工程原理。

1993年IEEE：软件工程是(1)把系统的、规范的、可度量的途径应用于软件开发、运行和维护过程;

(2)研究(1)中提到的途径。

软件工程的本质特性：

1.软件工程关注于大型程序的构造；

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

3.软件经常变化；

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

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

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

7.在软件工程领域中是由具有一种文化背景的人替具有另一种文化背景的人创造产品。

1.2.2软件工程的基本原理

1.用分阶段的生命周期计划严格管理；

2.坚持进行阶段评审；

3.实行严格的产品控制；

4.采用现代程序设计技术；

5.结果能清楚地审查；

6.开发小组的人员应该少而精；

7.承认不断改进软件工程实践的必要性。

1.2.3软件工程方法学

通常把在软件生命周期全过程中使用的-整套技术方法的集合称为方法学(Methodology),也称为范

型(Paradigm)(,

软件工程方法学的3要素：方法、工具和过程

1.传统方法学

也称为生命周期方法学或结构化范型。

结构化方法(StructureMethod)有：

1)结构化设计方法(SD)；

2)结构化分析方法(SA)；

3)结构化分析与设计技术(SADT)

4)JACKSON方法

5)WARNIER方法

2.面向对象方法学

把数据和对数据的操作紧密结合起来的方法，模拟人类认识世界解决问题的方法和过程。

面向对象的方法

=对象（属性与服务的封装）

+分类

+继承

+通过消息的通讯

3.其他开发方法

1）适用于实时事物处理系统的有限状态机方法（FSM）；

2）适用于并发软件系统的PETRI网方法；

3）以数学概念和理论为基础的形式化方法，如

SDC公司的形式化开发方法FDM：

（FormalDevelopmentMethodology）

IBM公司的维也纳开发方法VDM：

（ViennaDevelopmentMethod）

1.3软件生命周期

软件生命周期：指软件从提出到最终被淘汰的这个存在期O

软件生命周期组成：

1）软件定义；

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

2）软件开发；

D.总体设计E.详细设计F.编码和单元测试G综合测试

3）运行维护。

软件生命周期各个阶段：

1.问题定义；

2.可行性研究；

3.需求分析：

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

5.详细设计；

6.编码与单元测试；

7.综合测试；

8维.护。需求分析

购证

1.4软件过程规格说明

脸证

软件过程：为了获得高质量软件所需

设计

要完成的一系列任务的框架，它规定

验证

了完成各项任务的工作步骤。

软件过程（IS09000）：使用资源将输

编码

入转化为输出的活动所构成的系统。涌试

输入：如软件需求

输出：如软件产品［综合测试

维护

图1.2传统的瀑布模型

图L3实际的瀑布模型

1.4.1瀑布模型

1.阶段间具有顺序性和依赖性

2.推迟实现的观点

3.质量保证的观点

优点：采用规范的方法；严格规定每个阶段提交的文档；要求每个阶段交出的产品必须经过验证。

1.4.2快速原型模型

优点:不带反馈环，基本上是线性顺序进行。图1.4快速原型模型

1.4.3增量模型

优点:能较短时间内提交可完成部分工作的产品；可以使用户有充裕的时间学习和适应新产品。

图1.5增量模型

1.4.4螺旋模型

可把它看作在每个阶段之前都增加风险分析的快速原型模型。

风险分析风险分析

快速原改变化的需求

验证

风险分析

规格说由

风险分析

设计

验证

风险分析

一闲一

冽试

风险分析

综合测试

图1.7简化的螺旋模型

累计费用

与一'-各步骤的进度

碓定目标，

选择方案，

设定约束条件

风险分析

评估力案，

风险分析识别并排除

风险

风险分析

风险

可运行

原型I、原型2原型3的原型

需求计划一

与壬命一

软

操作概念软件件

详细

产

周期计划品

设

计

计

设

开发计划需求

一

确认_r一

单

啊

-编

集成与元

计划下•阶段设计验证/

测试计划与确认元/

集成

试J开发、验证

测试

］晚收I下一级产品

实现।丽瓜I

图1.8完整的螺旋模型

1.4.5喷泉模型

典型的面向对象软件开发过程模型之■»

1.4.6Rational统一过程

1.RUP软件开发经验

(1)迭代式开发

(2)管理需求

(3)使用基于构件的体系结构

(4)可视化建模

(5)贯穿于开发过程的软件质量验证

(6)控制软件变更

1.4.7敏捷过程与极限编程

1.敏捷过程

具有高效、快速响应变化的开发过程。

(1)个体和交互胜过过程和工具；

(2)可以工作的软件胜过面面俱到的文档；

(3)客户合作胜过合同谈判；

(4)响应变化胜过遵循计划。

2.极限编程

敏捷过程中最著名的一种，指把好的开发实践运用到极致，多应用于软件需求模糊的场合。

1.4.8微软过程

1.微软过程准则

2.微软软件生命周期

（1）规划阶段

（2）设计阶段

（3）开发阶段

（4）稳定阶段

（5）发布阶段

3.微软过程模型

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

基本的问题,如:

软件的总体目标什么？

有什么用途？

为那些用户设计？

1.5问题定义阶段

问题定义报告的内容包括：

1）软件项目标题；

2）软件目标；

3）软件用户对象；

4）软件规模。

问题定义是软件生命周期中时间最短的阶段，一般都比较简单，因此在实际开发中它是最容易被忽视的一

个阶段。

这一阶段工作主要由系统分析员来完成，系统分析员要尽可能从较高的角度概括软件所要做的工作，而

不用写明问题的实现细节。

第2章：可行性研究

可行性研究就是要回答“所定义的问题有可行的解决办法吗？

可行性研究的目的是：用最小的代价在尽可能短的时间内确定问题是否有解，以及是否值得去解。

2.1可行性研究的任务

可行性研究所需的时间取决于工程的规模，所需要的成本要占工程总成本的5%~10%。

可行性研究的内容：

1）技术可行性

技术可行性要分析各种技术因素，例如：

使用现有的技术能否实现这个系统？

是否有胜任开发该项目的熟练技术人员？

能否按期得到开发该项目所需的软件、硬件资源？

2）经济可行性

对经济合理性进行评价，所要考虑的问题是：

这个系统的经济效益能否超过它的开发成本？

这就需要对项目进行价格/利益分析，即“投入/产出”分析。

由于利益分析取决于软件系统的特点，因此在软件开发之前，很难对新系统产生的效益作出精确的定

量描述，所以往往采用•些估算方法。

3）操作可行性

操作可行性评价系统运行后会引起的各方面变化，如：对组织机构管理模式、用户工作环境等产生的

影响。

4）社会可行性

社会可行性主要讨论法律方面和使用方面的可行性。

例如，被开发软件的权利归属问题、软件所使用的技术是否会造成侵权等问题。

2.2可行性研究的步骤

1）复查系统规模和目标；

2）研究目前正在使用的系统；

3）导出新系统的高层逻辑模型（数据流图、数据字典）；

4）重新定义问题；

5）导出和评价供选择的解法（物理解决方案）；

6）推荐行动方案；

7）草拟开发计划；

8）书写文档提交审查。

2.3系统流程图（描绘物理系统的工具）

2.3

说明

处理如：程序，处理机，人工加工

口输入/输出表不输入或输出

O连接同一页上图的连接

□换页连接不同爽上图的连接

<—数据流指明数据流动方向

图2.1基本符号

存昌说明

UO穿孔卡片空在卡片输入/椅由.或穿在卡片寸件

口十档打印揄由.或打印线端蛉入和抿

Q磁带磁带输入隔山.或天示磁带十件

CT睬机在储在何种举磁毋存储.加磁母、磁骷等

0磁痛磁悬揄入/镯由.成磁母卜寸件、和抿庞

CD磁热磁热输F入/愉由・或磁第卜点件、和抿龙

GD显示显示黑制件

口人丁输入人丁输入拗r据.如埴空表格

D人丁想作人丁尧虎的々卜理

铺卧堤作神田辅时错名讲行的盹机摄作

诵信密盛诵讨沅程通信续盛传次和抿

图2.2条绣符号

报告生成程序

定货报告

图2.3库存清单系统的系统流程图

2.4数据流图（描绘数据在系统中流动的逻辑过程）

或□数据源点或终点

或Q变换数据的处理

或=数据存储

数据流

图2.4基本符号的含义

注意：

“处理”可表示：单个程序、一系列程序、程序的一个模块、人工处理过程等等;

“数据存储”可表示：一个文件、文件的一部分、数据库记录等等；

数据流图忽略出错处理、打开文件、关闭文件。

2.4.2绘制数据流图的例子

仓库定货报受

事务

管理员J采购员

〔统Jin

图2.5定货系统的基本系统模型

组成该例子的数据流图的元素

源点/终点处理

采购员产生报表

仓库管理员处理事务

数据流数据存储

订货报表订货信息

零件编号（见订货报表）

零件名称库存清单

订货数量零件编号

目前价格库存量

主要供应商库存量临界值

次要供应商

事务

零件编号

事务类型

数量

上述数据流图所描述的功能够详细了吗？

2.4.2绘制数据流图的例子

2.4.3命名

1）为数据流（或数据存储）命名

A.名字应该代表整个数据流（或数据存储）的内容；

B.不要使用空洞的、缺乏具体含义的名字（如“数据”、“输入”）；

C.如果为某个数据流（或数据存储）起名字时遇到困难，则很可能是因为对数据流图的分解不恰

当造成的，应该试试重新分解数据流图；

2）为处理命名

A.通常先为数据流命名，然后再为与之相关联的处理命名；

B.名字应该反映整个处理的功能；

C.应该尽量避免空洞笼统的动词做名字，如“处理”、“加工”；

D.通常用一个动词命名，如果必须用两个动词才能描述整个处理的功能，则可能要把这个处理分

解成两个处理更恰当；

E.如果在为某个处理命名时遇到困难，则很可能是发现了分解不当的情况，应考虑重新分解。

通常，为“数据源点/终点”命名时，采用它们在问题域中习惯使用的名字（如“仓库管理员”、“采购员

2.4.4数据流图的用途

1）利用它作为交流信息的工具；

2）作为软件分析和设计的工具。

图2.8这种自动化边界建议以联机方式更新库存清单

图2.8对应的物理实现硬件方案

2.4.2数据流图的用途

图2.9这种自动化边界暗示以批量方式更新库存清单

图2.9对应的物理实现硬件方案

2.5数据字典

数据字典：对数据流图中包含的所有元素的定义的集合；

可行性研究阶段，数据流图与数据字典共同构成系统的逻辑模型。

2.5.1数据字典的内容

数据字典应该对下列元素进行定义：

1）数据流；

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

3）数据存储；

4）处理。

2.5.2定义数据的数据元素字典定义实例：

1）数据元素字典定义

其定义的基本内容有：

A.数据元素编号、名称及其含义；

B.数据类型和长度；

C.合理取值；

D.其他内容，如它与其它数据的逻辑关系等。

2）数据流字典定义

其定义的基本内容有：

A.数据流编号及名称；

B.数据流来源；

C.数据流去处；

D.数据流的组成；

E.流通量；

F.峰值。

3）数据存储字典定义

其定义的基本内容有：

A.数据存储编号及名称；

B.数据存储的组成；

C.其它要求。

4）数据处理字典定义

其定义的基本内容有：

A.数据处理编号及名称；

B.简单描述；

C.输入/输出；

D.功能描述；

E.有关数据存储。

5）组成数据项的表示方法

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

+表示“与”

口与|表示“或”

｛）表示重复

（）表示可选项

通讯录=｛通讯地址｝

通讯地址=姓名+邮编+［省I直辖市I自治区］+［布I县］+街道+门牌号+（电话）

2.5.3数据字典的用途

1.作为分析阶段的重要工具；

2.数据元素的控制信息非常有用；

3.有助于开发数据库。

2.5.4数据字典的实现

实现数据字典：

1）程序处理；

2）卡片式人工书写；

2.6成本/效益分析

2.6.1成本估计

1）代码行技术

软件成本=每行代码的平均成本x估计的源代码总行数

2）任务分解技术

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

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

软件开发项目总成本估计=各个单独任务成本估计值之和。

常用的办法是按开发阶段划分任务，典型环境下各个开发阶段需要使用的人力百分比大致如下:

任务人力（％）

可行性研究5

需求分析10

设计25

编码与单元测试20

综合测试40

总计100

3）自动估计成本技术

采用自动估计成本的软件工具估计。

软件开发成本估算的经验模型：

1）Putnam模型

1978年Putnam提出的，一种动态多变量模型:

L是源代码行数（以LOC计）

K是软件开发与维护在内

的整个生存期所花费的工

作量（以人年计）

Ck为技术状态常数，它反映“妨碍开发进展的限制”，取值因开发环境而异，见卜表:

Ck的典型开发环开发环境举例

「值；

境

―2000—差没有系统的开发方法，缺乏文档和复审

8000好有合适的系统的开发方法，有充分的文

档和复审

11000优有自动的开发工具和技术

2）COCOMO模型（constructivecostmodel）

这是由TRW公司开发，Boehm提出的结构化成本估算模型，是一种精确的、易于使用的成本估算方

法。

基本COCOMO模型估算工作量和进度的公式如下：

工作量：MM=rX（KDSI）c（人月）

开发时间：TDKV=aX（MM）b（月）

DSI：源指令条数，不包括注释，1KDSI=1OOODSI

MM：开发工作量（以人月计），1MM=19人II=152人时=1/12人年

经验常数r,c,a,b取决于项目的总体类型

COCOMO模型中，考虑开发环境，软件开发项目的类型可以分为3种：

1）组织型（organic）

相对较小、较简单的软件项目。开发人员对开发目标理解比较充分，与软件系统相关的工作经验

丰富，对软件的使用环境很熟悉，受硬件的约束较小，程序的规模不是很大（＜50000行）

2）嵌入型（embedded）

要求在紧密联系的硬件、软件和操作的限制条件下运行，通常与某种复杂的硬件设备紧密结合在

一起。对接口，数据结构，算法的要求高。软件规模任意。

如大而复杂的事务处理系统，大型/超大型操作系统，航天用控制系统，大型指挥系统等。

3）半独立型（semidetached）

介于上述两种软件之间。规模和复杂度都属于中等或更高。最大可达30万行。

COCOMO模型按其详细程度可以分为三级：

1）基本COCOMO模型

是一个静态单变量模型，它用一个以已估算出来的原代码行数（LOC）为自变量的经验函数计

算软件开发工作量。

基本COCOMO模型

通过统计63个历史项目的历史数据，得到如下计算公式：

总体类型工作量所需开发时间

组织型MM=2.4xTDKV=2.5x

(KDSI)105(MM)0-38

半独立型MM=3.0xTDKV=2.5x

(KDSI)112(MM)035

嵌入型MM=3.0xTDKV=2.5x

(KDSI)120(MM)032

2）中级COCOMO模型

在基本COCOMO模型的基础上，再用涉及产品、硬件、人员、项目等方面的影响因素调整

工作量的估算。

3）详细COCOMO模型

包括中级COCOMO模型的所有特性，但更进一步考虑了软件工程中每一步骤（如分析、设计）

的影响。

2.6.2成本/效益

1）货币的时间价值

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

反之，如果n年后能收入F元钱，那么这些钱现在的价值是：

例：修改一个已有的库存管理系统，估计需要5000元，系统修改后使用5年，每年可节省2500元。请

进行成本/效益分析。

表1：将来的收入折算成现在值

年将来值现在值累计的现在

（左八nj,n1”（彳八宿（开八

125001.122232.142232.14

225001.251992.984225.12

\325001.401779.456004.57

425001.571588.807593.37

525001.761418.579011.94

2）投资回收期

第一、第二年回收：4225元

第三年用于回收投资要：

（5000-4225）/1779=0.44年

总的投资回收期=2.44年

3）纯收入

9011.94-5000=4011.94（

4）投资回收率

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

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

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

j是投资回收率。

上述修改系统的工程的投资回收率是41%-42%

第2章小结

◊可行性分析报告

说明该软件开发项目的实现在技术上、经济上和社会因素上的可行性，评述为了合理地达到开发目标

可供选择的各种可能实施方案，说明并论证所选定实施方案的理由。

◊项目开发计划

为软件项目实施方案制订出具体计划，应该包括各部分工作的负责人员、开发的进度、开发经费的预

算、所需的硬件及软件资源等。

第3章：需求分析

3.1需求分析的任务

3.1.1确定对系统的综合要求

1.功能需求

2.性能需求

如：相应时间（速度）、主存容量、磁盘容量、安全性、等。

3.可靠性和可用性需求

4.出错处理需求

系统发现错误时采取的行动，主要在系统关键部分设置。

5.接口需求

用户接口、硬件接口、软件接口、通信接口、等。

6.约束

精度、工具和语言、设计约束、硬件约束、标准，等。

7.逆向需求

8.将来可能提出的要求

3.1.2分析系统的数据要求

通过建立数据模型来分析，如数据字典、层次方框图、Wamier图，并将数据结构规范化。

3.1.3导出系统的逻辑模型

包括完善的数据流图、实体一联系图、状态转换图、数据字典、主要的处理算法（IPO图）等。

3.1.4修正系统开发计划

修订前期制定的开发进度计划、等。

3.2与用户沟通获取需求的方法

3.2.1访谈

正式访谈：系统分析员提出事先准备好的问题。

非正式访谈：提出一些用户可以自由回答的开放性问题，鼓励被访者说出自己的想法。

需要访问大量人员时，利用调查表访问较佳。

3.2.2面向数据流自顶向下求精

借助数据流图、数据字典、IPO图等，细化、完善详细的数据流图，等到各处理环节对应的功能。

例：

3.2.3简易的应用规格说明技术

面向团队的需求收集法：（用户与开发者配合）

1）初步访谈；

2）开发者和用户分别写出“产品需求”；

3）开会讨论，各自展示需求列表；

4）得出一致意见，为需求列表制定小型规格说明;

5）根据会议成果，起草完整的软件需求规格说明。

3.2.4快速建立软件原型

快速建立能演示目标系统主要功能的程序。

（1）第四代技术

（2）可重用的软件构件

（3）形式化规格说明和原型环境

3.3分析建模与规格说明

3.3.1分析建模

为了开发复杂的系统，应从不同角度（模型）抽象出目标系统的特性（数据模型、功能模型、行为模

型）。

1）实体联系图：建立数据模型，描述数据对象及数据对象之间的关系；

2）数据流图：建立功能模型的基础：

3）状态转换图：描绘系统的状态和状态间转换的方式。

3.3.2软件需求规格说明

3.4实体一联系图

数据对象可以是外部实体、事物、行为、事件、角色、单位、地点、结构等。

3.4.1数据对象

3.4.2属性

属性定义了数据对象的性质。

3.4.3联系

（1）一对一联系（1：1）

（2）一对多联系（1：N）

（3）多对多联系（M：N）

在ER图中，用菱形框表示联系。

联系

例子：

3.5数据规范化

通常用范式定义消除数据冗余的程度。

1）第一范式

2）第二范式

3）第三范式

3.6状态转换图

3.6.1状态

状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。

3.6.2事件

事件是某个特定时刻发生的事情，它是引起系统做动作或状态转换的控制信息。

3.6.3符号

状态1状态2

•初始-事件-状态变量1事件表达式_状态变量2结束事件

活动表1活动表2

1J

<___________/

■图3.3状态图中使用的主要符号

3.6.4例子

挂断电话挂断电话

闲置

拿起听筒

'拨号音、

timer=O超时

超时

do/响蜂鸣音

do/响拨号音

且增加timer

数字

数字存储的信息

无效号眄-

拨号

do/播放信息

有效号码

(tE¥占线接通中

信息播完

do/响忙音do/试接通

已接通

do/振玲

X,_____________z

］受话人回话

C~~通话)

受话人挂断电话

(断线>--------

图3.4电话系统的状态图

3.7其他图形工具

3.7.1层次方框图

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

3.7.2Warnier

Warnier图也用树形结构描绘信息，但是这种图形工具比层次方框图提供了更丰富的描绘手段。

3.7.3IPO

IPO图是输入/处理/输出图。

IPO表

系统：-------作---------

模块：-------日期：_________

编号，_______

被调用：调用：

输入：输出：

处理：

局部数据兀素：

冬3S改讲的IPO冬的形式

3.8验证软件需求

3.8.1验证软件需求的正确性

1）一致性

2）完整性

3）现实性

4）有效性

3.8.2验证软件需求的方法

1）验证需求的一致性

2）验证需求的现实性

3）验证需求的完整性和有效性

3.8.3用于需求分析的软件工具

用于需求分析的软件应该满足下列要求：

1）必须有形式化的语法

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

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

4）使用这个软件工具后，应该能够改进通信状况

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

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

第3章小结

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

对所开发软件的功能、性能、用户界面及运行环境等作出详细的说明。

它是在用户与开发人员双方对软件需求取得共同理解并达成协议的条件下编写的，也是实施开发工作

的基础。该说明书应给出数据逻辑和数据采集的各项要求，为生成和维护系统数据文件做好准备。

第4章：形式化说明技术

1.非形式化方法：自然语言描述

2.半形式化方法：数据流图或实体一联系图

3.形式化方法：基于数学技术描述

4.1

4.1.1非形式化方法的缺点

自然语言书写的系统规格说明书可能存在：

1）矛盾；

2）二义性；

如：“操作员标识山操作员姓名和密码组成，密码由6位数字构成，当操作员登陆系统时它被存储在

注册文件中

3）含糊性；

4）不完整性；

5）抽象层次混乱。

4.1.2形式化方法的优点

（1）数学是理想的建模工具，适合于表示系统状态和描述系统需求；

（2）用数学表达的需求可在不同开发阶段平滑过渡。

4.1.3应用形式化方法的准则

（1）选择合适的形式化方法；

（2）需要形式化，但不能过渡形式化，不能放弃传统的需求表达方法；

（3）应该有形式化方法的专家提供指导。

4.2有穷状态机法（FSM）

4.2.1概念

初始态终态

图4.1保险箱的状态转换图

锁的三个位置：1、2、3；转盘可向左（L）或右（R）；

锁密码：IL、3R、2L

表保险箱的状态转换表

前状态

保险箱锁定AB

转盘动作、、、

1LA报警报警

1R报警报警报警

2L报警报警保险箱解锁

2R报警报警报警

3L报警报警报警

3R报警B报警

一个有穷状态机包括5部分：

1）状态集J：｛保险箱锁定，A,B,保险箱解锁，报警｝

2）输入集K：｛1L,1R,2L,2R,3L,3R｝

3）转换函数T,如表4.1

4）初始状态S：保险箱锁定

5）终态集F：｛保险箱解锁，报警｝

史形式化的术语：

一个有穷状态机可表示一个为5元组（J,K,T,S,F）

状态转换形式：

当前状态【菜单】+事件【所选择的项】=>下个状态

加入谓词集P，把系统扩展成一个6元组后：

当前状态【菜单】+事件【所选择的项】+谓词=>下个状态

计算机系统中每个菜单驱动的用户界面都是一个有穷状态机的实现。

4.2.2例子:电梯的状态转换

定义状态：

(1)电梯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.4电梯的状态转换图

电梯状态转换规则：®S(U,e,f)+DC(e,f)=>M(U,e,R1);

@S(D,e,f)+DC(e,f)=>M(D,c,f-l)；③S(N,e,f)+DC(e,f)=>W(e,f)

4.2.3评价

有穷状态机描述规格说明：

当前状态+事件+谓词=>下个状态

易于书写、验证、转变成设计或程序代码。

有穷状态机方法比数据流图技术更精确，一样易于理解。但不能处理定时需求。

4.3Petri网

图4*5Petri网的组成

Petri网包含4种元素:

1)一组位置P,上例P={P1,P2,P3,P4}

2)一组转换T,上例T={tl,t2}

3)输入函数I,上例I(tl)={P2,P4}

I(t2)={P2}

4)输出函数0,上例O(tl)={P1}

O(t2)={P3,P3}

更形式化的Petri网结构，是一个4元组(P,T,I,O)

图4.6带标记的Petri网

权标向量(1,2,0,1)

图4.7图4.6的Petri网在转换

力被激发后的情况

权标向量(2,1,0,0)

图4.8图4.7的Petri网在转换

功被激发后的情况

权标向量(2,0,2,0)

更形式化地：

标记M：P—>{0,1,2,…}

Petri网成为一个5元组(P,T,I,O,M)

对Petri网的一个重要扩充是加入禁止线：

图4.9含禁止线的Petri网

4.3.2例子

图4.10Petri网表示的电梯按钮

EBf电梯中楼层f的按钮；Fg楼层g；Ff楼层fo

2.楼层按钮

图4.11Petri网表示楼层按钮

FBfu第f楼层向上按钮；FBfd第f楼层向下按钮；

小结

基于数学的形式化说明技术，目前还没有在软件产业界广泛应用;

应该把形式化方法与传统方法有机结合。

第5章：总体设计

5.1设计过程

1.设想供选择的方案

2.选择合理的方案

对每个合理的方案要提供：

A.系统流程图

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

C.成本/效益分析

D.实现这个系统的进度计划

3.推荐最佳方案

4.功能分解

5.设计软件结构

6.数据库设计

A.模式设计

B,子模式设计

C.完整性和安全性设计

D.优化

7.制定测试计划

8.书写文档

A.系统说明

B.用户手册

C.测试计划

D.详细的实现计划

E.数据库设计结果

9.审查和复审

5.2设计原理

5.2.1模块化

设函数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.1越块化与软件成太

5.2.2抽象

5.2.3逐步求精

5.2.4信息隐蔽和局部化

5.2.5模块

模块的独立性很重要，因为：