1.4 软件工程方法论
1.4.1 软件工程方法论的提出
长期以来，人们将软件开发方法与软件生命周期模型，甚至软件开发方法与软件过程改进模型混为一谈，因而误认为软件生命周期模型或软件过程改进模型就是软件开发方法。例如，将迭代模型RUP（Rational Unified Process）和过程改善模型CMMI（Capability Maturity Model Integration）误认为是软件开发方法或软件工程方法论。事实上，软件开发方法与软件生命周期模型是不同的，软件开发方法与软件过程改进模型就更不相同了。软件开发方法学来自程序设计语言方法学，而软件生命周期模型或软件过程改进模型与程序设计语言方法学无关。
软件生命周期模型是指在整个软件生命周期中，软件开发过程应遵循的开发路线图。或者说，软件生命周期模型是软件开发全部过程、活动和任务的结构框架。
例如，瀑布模型、增量模型、螺旋模型、喷泉模型、XP模型、原型模型和RUP迭代模型，它们都有各自清晰的开发路线图，规定了各自的开发过程、活动和任务的结构框架。这些软件生命周期模型，将在后续的有关章节中详细论述。
软件开发方法是指在软件开发路线图中，开发人员对软件需求、设计、实现、维护所采用的开发思想、开发技术、描述方法、支持工具等。
在软件工程方法学方面，大体可分为程序设计方法学和软件开发方法学，前者是关于小规模程序的设计方法学，后者是关于大规模软件的开发方法学。
例如，在程序设计方法学中，最基本的方法有：面向过程程序设计方法，面向对象程序设计方法，面向元数据（Meta-data）程序设计方法。在软件开发方法学中，最基本的方法有：面向过程方法、面向对象方法、面向元数据方法、形式化方法。它们都是软件开发方法，都有各自的开发思想、开发技术、描述方法、支持工具等。
软件工程中软件开发方法的集合，称为软件工程方法论。
现在的问题是：到目前为止，软件工程方法论中，到底包括哪几种最基本的软件开发方法？这几种开发方法，到底存在什么关系？下面将回答这些问题。
1.4.2 面向过程的方法
面向过程的方法（Procedure-Oriented Method），来自于面向过程的程序设计语言，如汇编语言、C语言。面向过程方法包括面向过程的需求分析、设计、编程、测试、维护、管理等。
面向过程方法，习惯上称为传统软件工程开发方法，或结构化方法。它包括结构化分析、结构化设计、结构化编程、结构化测试、结构化维护。面向过程方法，有时又称面向功能的方法，即面向功能分析、设计、编程、测试、维护。由此可见，面向过程方法、面向功能方法、结构化方法，三者是同一个意思。
在软件工程发展史上，曾经出现过的面向过程方法有：
（1）面向结构化数据系统的开发方法DSSD（Data Structured Systems Development）；
（2）面向可维护性和可靠性设计的Parnas方法；
（3）面向数据结构设计的Jackson方法；
（4）面向问题设计的PAM方法；
（5）面向数据流方法。
上述5种方法的详细内容，利用百度或Google搜索引擎，都可以在网上查到。但是，不管在方法名字上如何称呼，这5 种方法在宏观上都属于面向过程方法，支持这些方法的是面向过程的结构化编程语言。
面向过程方法设计中强调模块化思想，采用“自顶向下，逐步求精”的技术对系统进行划分，分解和抽象是它的两个基本手段。面向过程方法编程时采用单入口单出口的控制结构，并且只包含顺序、选择和循环三种结构，目标之一是使程序的控制流程线性化，即程序的动态执行顺序符合静态书写结构。
在面向过程的5种具体方法中，面向数据流方法最具有代表性。
面向数据流的设计方法，把数据流图映射成软件结构，数据流图的类型决定了映射方法，数据流图DFD（Data Flow Diagram）可以分为变换型数据流图和事务型数据流图。
（1）具有明显的输入、变换（加工）和输出界面的数据流图称为变换型数据流图。
（2）数据沿输入通路到达一个处理模块，这个处理模块根据输入数据的类型在若干动作序列中选出一个来执行，这类数据流图称为事务型数据流图，并且称这个模块为事务中心。它完成如下任务：接收输入数据；分析数据并确定数据类型；根据数据类型选取一条活动通路。
面向数据流的方法，在本书的后续章节中还会有进一步的介绍。
软件的基础是程序，没有程序就没有软件，也就没有软件工程方法。对于软件行业来说，某一种软件工程方法往往来自于某一类程序设计语言。面向过程的方法，来自于20世纪60～70年代流行的面向过程的程序设计语言，如ALGOL，PASCAL，BASIC，FORTRAN，COBOL，C语言等，这些语言的特点是：用“顺序、选择（if-then-else）、循环（do-while或do-until）”三种基本结构来组织程序编制，实现设计目标。面向过程方法开始于20世纪60年代，成熟于70年代，盛行于80年代。该方法在国内曾经十分流行，大量应用，非常普及。
面向过程方法的优点是：以处理流程为基础，简单实用。其缺点是：只注重过程化信息，忽略了信息的层面关系及相互联系。它企图使用简单的时序过程方法（顺序、分支、循环三种结构），来描述关系复杂（随机）的信息世界，因而对于关系复杂的信息系统来说，其描述能力不强，最后可能导致软件设计、开发和维护陷入困难。
自从面向对象方法出现之后，在许多领域，面向过程方法逐渐被表述能力更强的面向对象方法所取代。当前，面向过程方法主要用在过程式的程序设计中，如对象方法（函数）、科学计算、实时跟踪和实时控制的实现。
【例1-4】 面向过程方法在军事领域的实时跟踪监控系统中有很好的应用。如我方侦察卫星发射后其飞行轨迹的捕获、测量、跟踪和预报，导弹防御系统中敌方导弹发射后飞行轨迹的捕获、测量、跟踪和预报，其软件系统都是采用面向过程的方法设计和实现的。使用面向过程的方法，系统的执行路径可由系统自动控制，也就是程序自动控制，这是一切自动控制与跟踪系统所必需的。
1.4.3 面向对象的方法
面向对象的方法（Object-Oriented Method），在不少教材中称为现代软件工程开发方法。该方法包括面向对象的需求分析、设计、编程、测试、维护、管理等。面向对象方法是一种运用对象、类、消息传递、继承、封装、聚合、多态性等概念来构造软件系统的软件开发方法。
面向对象方法的特点是，将现实世界的事物（问题域）直接映射到对象。分析设计时由对象抽象出类（Class），程序运行时由类还原到对象（Object）。
面向对象方法，源于20世纪80代年开始流行的面向对象的程序设计语言，如Java，C++，Delphi，Visual Basic语言等。面向对象方法的基本特点是，将对象的属性和方法（即数据和操作）封装起来，形成信息系统的基本执行单位，再利用对象的继承特征，由基本执行单位派生出其他执行单位，从而产生许多新的对象。众多的离散对象通过事件或消息连接起来，就形成了软件系统。20 世纪80 年代末，微软视窗操作系统的出现，使它产生了爆炸性的效果，大大加速了它的发展进程。90 年代中期，UML（Unified Modeling Language）和Rose（Rational object-oriented system engineering）的产生，标志着它逐步走向了成熟，并且开始普及。21世纪初，面向对象的两类开发平台是．Net平台和J2EE平台。
面向对象方法，实质上是面向功能方法在新形势下（由功能重用发展到代码重用）的回归与再现，是在一种高层次上（代码级）新的面向功能的方法论，它设计的“基本功能对象（类或构件）”，不仅包括属性（数据），而且包括与属性有关的功能（或方法，如增加、修改、移动、放大、缩小、删除、选择、计算、查找、排序、打开、关闭、存盘、显示和打印等）。它不但将属性与功能融为一体，而且对象之间可以继承、派生以及通信。因此，面向对象设计，是一种新的、复杂的、动态的、高层次的面向功能设计。它的基本单元是对象，对象封装了与其有关的数据结构及相应层的处理方法，从而实现了由问题空间到解析空间的映射。一句话，面向对象方法也是从功能入手，将功能与方法当作分析、设计、实现的出发点和最终归宿。
面向对象方法的优点是：能描述无穷的信息世界，同时易于维护。其缺点是：对于习惯于面向过程方法的人，较难掌握。
面向对象方法是当前软件界关注的重点，是软件工程方法论的主流。面向对象的概念和应用已超越了程序设计和软件开发，扩展到更宽的范围。如交互式界面、应用结构、应用平台、分布式系统、网络管理结构、CAD技术、人工智能等领域。
业界流传的面向方面的方法、面向主体的方法和面向架构的方法，都是面向对象方法的具体应用实例。
【例1-5】 互联网上各种网站的设计、实现和维护，都是面向对象方法的案例。游戏软件的设计、实现和维护，更是面向对象方法的杰作。
【例1-6】 面向对象方法在电子商务中的应用有：网站前台界面的制作，信息的发布和处理，用户在网上浏览和录入信息等应用软件都是利用面向对象的方法设计与实现的。个人网页的制作也是面向对象方法的应用例子。窗口操作系统与互联网的出现，为面向对象方法开辟了无限的前景。
1.4.4 面向元数据的方法
这里讲的面向元数据的方法（Meta-data Oriented Method），既不是传统软件工程中的“面向数据流”方法，也不是传统意义上的面向数据结构的Jackson方法，它们都是面向过程的方法，而且这两种方法都出现在关系数据库管理系统RDBMS（Relational Database Management System）成熟之前。所以这里讲的面向元数据方法，就是面向meta-data的方法，它与面向过程方法截然不同。
面向元数据方法来源于面向元数据的程序设计思想，即关系数据库语言的程序设计思想。当关系数据库管理系统和数据库服务器出现之后，面向元数据方法才被人们所发现与重视。当数据库设计的CASE工具Power Designer、Oracle Designer和ER win出现之后，面向元数据设计方法才开始流行。
元数据（Meta-Data）是关于数据的数据，组织数据的数据，管理数据的数据。
这里的元数据，泛指一切组织数据的数据，如类的名称、属性和方法，实体的名称、属性和关联，数据库中的表名、字段名、主键、外键、索引、视图，数据结构中存储数据的框架等。但是，我们研究的重点，是指数据库中的元数据。
面向元数据的方法，就是在软件需求分析、设计、实现、测试、维护过程中，均以元数据为中心的软件工程方法。
例如，数据库概念设计中的实体名和属性名，数据库物理设计中的表名和字段名，它们就是元数据。而具体的某一个特定的实例，它们不是元数据，而是对象或记录，是被元数据组织的数据。关系数据库管理系统自带的程序设计语言，提供了强大的面向关系表中数据的编程能力，典型的例子就是编写存储过程（Stored Procedure）和触发器（Trigger）。Oracle数据库管理系统自带的编程工具Developer 2000，是一个面向元数据的编程工具。Oracle Designer加上Developer 2000，构成了一个完整的面向元数据的信息系统开发环境。
面向元数据方法包括面向元数据的需求分析、设计、编程、测试、维护。
（1）面向元数据的需求分析，是在需求分析时，找出信息系统所有的元数据，使其完全满足信息系统对数据存储、处理、查询、传输、输出的要求。也就是说，有了这些元数据，信息系统中的一切原始数据不但都被组织起来，而且能完全派生出系统中的一切输出数据。
（2）面向元数据设计，是利用需求分析获得的元数据，采用面向元数据的CASE工具，设计出信息系统的概念数据模型CDM（Conceptual Data Model）和物理数据模型PDM（Physics Data Model），以及从原始数据到输出数据的所有算法与视图。
（3）面向元数据编程，是在物理数据模型PDM的基础上，根据信息系统的功能、性能、接口和业务规则，建立数据库表和视图，再利用数据库编程语言，编写出存储过程和触发器。
（4）面向元数据测试，是对数据库表初始化并加载之后，运行相关的存储过程和触发器，测试信息系统的各种功能需求与性能指标。
（5）面向元数据维护，是对数据库表中的记录进行统计、分析、审计、复制、备份、恢复，甚至对表结构及视图结构，进行必要的调整。
事实上，近20多年来，面向元数据方法已经是建设信息系统、数据库、数据仓库和业务基础平台的基本方法。概括起来，面向元数据的方法要点是：
（1）数据（Data）位于企业信息系统的中心。信息系统就是对数据的输入、处理、传输、查询和输出。
（2）只要企业的业务方向和内容不变，企业的元数据就是稳定的，由元数据构成的数据模型（Data Model）也是稳定的。
（3）对元数据的处理方法是可变的。用不变的元数据支持可变的处理方法，即以不变应万变，这是企业信息系统工程的基本原理。
（4）信息系统的核心是数据模型。数据模型包括概念数据模型CDM和物理数据模型PDM。数据模型的表示形式是E-R图，它用CASE工具设计。例如，Power Designer，Oracle Designer或ER win，它们不但具有正向设计功能，而且具有逆向分析功能，这样才能实现快速原型法。
（5）信息系统的编程方法主要是面向对象（除数据库服务器层面上），其次才是面向元数据（在数据库服务器层面上）和面向过程（在实现存储过程和对象方法中）。
（6）用户自始至终参与信息系统的分析、设计、实现与维护。
面向元数据方法的优点是：通俗易懂，特别适合信息系统中数据层（数据库服务器）上的设计与实现。其缺点是：只能实现二维表格，不能实现窗口界面。
面向元数据方法，与关系数据库管理系统紧密地捆绑在一起，只要面向对象数据库不能完全替代关系数据库，这种方法就不会终结。目前数据库管理系统的发展趋势是：在关系型数据库的基础上，将面向对象的某些特性（如继承）添加上去，称为“对象-关系型数据库”，但本质上仍然是一个关系型数据库。
【例1-7】 面向元数据的方法在电子商务中也有应用。网站后台数据库服务器上的数据处理和数据传输，其软件都是利用面向元数据的方法设计与实现的。实际上，不管网络应用系统是C/S结构还是B/S结构，在数据库服务器（S）上对数据的分析、设计和实现，都自觉或不自觉地使用了面向元数据的方法。
＊1.4.5 形式化方法
1. 什么是形式化方法？
软件工程的形式化方法（Formalized Method），是建立在严格数学基础上、以逻辑推理为出发点、并且具有精确数学语义的开发方法。
软件工程中的形式化方法是软件工程的研究领域之一，其内容包括：有限状态机、State charts、Petri网、通信顺序进程、通信系统演算、一阶逻辑、程序正确性证明、净室软件工程、时态逻辑、模型检验、Z形式规约语言、B语言和方法、VDM系统、Larch等。
作为一种以数学逻辑为基础的方法，形式化方法以其严密性越来越受到众多领域的重视，尤其是在安全性和可靠性作为关键问题的系统，如核电站、航空航天、铁路运输系统中得到了较为广泛的应用。但是对于形式化方法在工业领域的实际应用问题，在软件工程界，尤其是在系统开发人员当中，还存在着相当多的疑问。
1990年，J．A Hall回答了有关形式化方法的7个疑问，它们是：
（1）该方法可否保证软件系统的完美无缺？答：形式化方法不能保证系统的完美无缺，也并不能减少系统所需的测试。用户不能认为它是万能的。
（2）它处理的只是程序正确性的证明？答：形式化方法不仅仅局限于对程序正确性的证明。
（3）它只适用于“安全第一”的系统？答：形式化方法不仅仅局限于“安全第一”的系统。
（4）它需要专业的数学知识？答：许多复杂问题的简单形式化描述，以及若干项目的成功运作反驳了有关形式化方法需要专业的数学知识。
（5）它增加系统开发的成本？答：是的，增加了研发成本。
（6）用户无法接受它？答：最终用户以及非专业人员，在系统开发中的广泛参与，说明了用户对该方法的认可。
（7）无法应用于大型的实际系统？答：它在几个大型实际系统中成功应用，已经引起了广泛的关注，也否定了形式化方法无法应用于大型实际系统的说法。
1995年，Jonathan P Bowen进一步回答了随着计算科学的发展，有关形式化方法的其他7个新疑问。
（8）该方法延迟开发进程？答：尽管一些应用形式化方法的项目由于各种原因被延迟，但是多数都因该方法的成功应用显著地缩短了开发时间。
（9）它缺乏支持工具？答：随着形式化方法领域的不断壮大，对其支持的工具会越来越丰富。类似于CASE的集成工具也已经出现。
（10）它将代替传统的工程设计方法？答：它与结构化软件工程方法并不是相互对立，相反，二者的结合将会是有益的相互补充。
（11）只适用于软件设计？答：该方法不仅适用于软件开发，同样适用于硬件设计，而且它使软、硬件联合设计成为可能。
（12）实际上并不需要它？答：尽管关于该方法的必要性有很多争论，但不可否认的是，在一些领域中，它是必须的，而且这些领域将越来越广泛。
（13）它缺乏支持？答：它正在为越来越多的人所接受与支持。在一些国家，该方法正逐渐步入大学的课堂。
（14）该方法的热衷人员只使用形式化方法？答：必须承认，该方法并不是万能的。在一些特定领域它并不适宜，用户界面设计就是一例。
当然，上述回答是站在正方的立场上的。若站在反方的立场上，至少存在这样一个事实：在当今社会上，很难找到几个IT企业，他们在软件需求、设计、实现、验证中，系统地采用了形式化方法。
2. 形式化方法的优势
随着软件系统的功能越来越多，规模越来越大，其开发的复杂度也越来越高，这样一来，软件中出现错误的概率也随之增加，由于这些错误可能会带来时间、财产甚至是人的生命的损失，因此软件工程的一个主要目标就是希望软件的可靠性不会随着系统的复杂性增大而降低。与其他传统的软件开发方法相比，以数学为基础的形式化方法有着无法比拟的严密性，它能够帮助发现其他方法不容易发现的系统描述的不一致性、二义性或不完整性，有助于增加软件开发人员对系统的理解。
形式化方法在软件开发中能够起到的作用是多方面的。首先是对软件需求和设计的描述。系统分析人员将软件需求和设计用形式化的语言，而不是自然语言描述出来，这样做主要有两方面的好处：对于开发人员而言，由于自然语言本身的局限，传统的需求与设计描述是不规范的，可能存在歧义，容易被错误理解，一旦在这个环节出错，那么编写的代码也不可避免地会出现错误；对于系统分析人员而言，在用形式化语言描述需求设计规范之后，可以利用模型检查、定理证明等方法，来判断软件的设计是否一致、是否完整，并且预测系统是否会表现出预期的特点、做出正确的行为。这可以在早期发现软件开发过程中的错误，并获得及时改正。对于软件开发来说，错误发现得越晚，修改成本就越高，越是大型复杂的系统，越是如此。形式化方法虽然在开发早期可能成本较高，但是却可以大大降低后期的维护和验证的费用。对于编程而言，还可以考虑自动代码生成。对于一些简单的系统，形式化的描述有可能直接转换成可执行程序，这就简化了软件开发过程，节约了资源，减少了出错的可能性。形式化方法还可以用于程序验证，以保证程序的正确性。另外，对于测试来讲，形式化方法可用于测试用例的自动生成，这既节省时间，又在一定程度上保证测试用例的覆盖率。
下面通过一个简单例子来看如何使用形式化的规格说明来对系统建模，并加以分析和验证。
现考虑以下需求：一个装冷却水的水箱在低水位传感器发出警告时需要向其中加水。每次加水都向水箱加9个单位的水。注意：
● 水箱最多能装10个单位的水。
● 每次读取水位的时间间隔会用掉1个单位的水。
● 低水位传感器会在水箱剩下1个单位或不到1个单位的水时发出警报。
以上描述涉及两个关键概念：水箱中的水位和水的使用量。我们可以将其形式化地描述如下：
（1）水位用整数表示，并且取值范围为[0，10]。
（2）水的使用量用整型常数1表示。
水位描述的是在任一时间水箱内的水量，而水的使用量是每次间隔使用的水量。
基本的需求是如果水位为1个单位或者更少则向水箱加水，可以描述为：
（3）函数fill的输入/输出均为水位。如果输入为L个单位的水，fill将在L等于或小于1时返回L+9，其余情况返回L。（这里定义了fill（L）函数，用于说明水箱中的加水动作。）
根据常识，这个系统中，一个时间间隔后新的水位应该是当前水位加上加入的水量减去这个时间间隔用掉的水量。设当前水位为L，则：
（4）level = L + fill（L）- usage
我们检查这个规格描述是否与水位level的定义一致，也就是说，是否保证水位是0～10的一个整数。为了检查在第（3）条说明中定义的fill是否满足一致性，需要检查以下两条：
（5）对于所有的水位 L
（L ＜= 1）则（0 ＜= L + 9）并且（L + 9 ＜= 10）
（6）对于所有的水位 L
（0 ＜= L + fill（L）- usage）并且（L + fill（L）- usage ＜= 10）
这两个条件可以用形式化方法工具自动推理生成。其中第（5）条可以如下证明：
（5.1）因为L ＞= 0，所以L+9 ＞= 0。
（5.2）因为L ＜= 1，所以L+9 ＜= 10。
但是第（6）个条件不能保证成立，当L = 9时
L + fill（L）= L + L -1 = 9 + 9-1 = 17（不满足＜= 10）
因此，以上的某一步出现了错误。仔细检查可以发现，第（4）条中关于一个时间间隔后的水位描述有问题：（4）level = L + fill（L）- usage（错误）。
这个描述与fill的定义不一致，因为fill返回的是水箱的新水位而不仅仅是加入的水量，因此我们将第（4）条改为
（4'）level = fill（L）- usage（正确）
那么第（6）条判断就改为
（6'）对于所有的水位L
（0 ＜= fill（L）- usage）并且（fill（L）- usage ＜= 10）
这条判断留给读者自行验证。为了读者阅读方便，例中用自然语言而不是形式化语言来描述，读者可以通过相关参考书进一步研究如何用形式化语言来描述这个系统。
通过这个例子读者可以看到，如何给出形式化的规格说明，如何检查一致性，如何定义系统行为，如何进行证明。
形式化方法本身是一个很灵活的方法，决策者不需要决定是否在系统中完全采用或者完全不用这类方法，而可以根据自己的实际情况选择在开发的某些阶段，或者软件的某些模块某些功能点采用这一方法，也可以考虑将形式化方法与其他非形式化方法，如面向对象方法结合起来使用。
3. 形式化方法的局限性
首先，形式化方法可以应用于软件开发的一些领域和阶段，但是它也有自己的适用范围。它基于离散数学，最适合对离散系统建模，尤其适用于包括很多逻辑交互的系统。如果一个系统包括很多不同的状态，状态之间的转移根据布尔条件来确定，这样的系统采用形式化方法收效明显；而如果系统结构比较松散，没有太多内在的逻辑关系，就算是形式化了，也得不到太大的好处。同时形式化方法很难应用到采用数值化算法，需要大量计算的问题当中，尤其是需要浮点运算的系统。
其次，目前形式化方法还只能解决中小规模的问题，如果系统规模较大，形式化方法的工作量会很大，并且有一定的难度。逻辑推理在形式化方法中占有很重要的位置，也是一个难点。逻辑推理主要包括模型检测和定理证明。模型检测是将系统建成一个有穷模型，然后检测该模型是否具备希望的性质。简单来说，就是在模型的状态空间中进行穷举搜索，主要的困难在于，当系统非常庞大时采用何种数据结构和算法才能有效地进行搜索。
再次，形式化方法虽然比其他方法更加严密准确，能够通过数学推理对系统的特性做出证明，但是必须清醒地看到，即使一个系统完全采用了形式化方法，也不能说它就是百分之百正确的。因为在将非形式化的信息翻译成形式化表示的过程中，以及将形式化的分析结果解读成人们容易理解的信息的过程中都有可能出错，同时在逻辑推理过程中，逻辑推理软件本身也有可能出现错误。更何况由于形式化方法本身的能力以及软件开发过程中提供的信息可能不全面，要在一个系统中完全采用形式化方法几乎是不可能的事情。
4. 形式化方法的发展现状
形式化方法的发展之路并非一帆风顺，在它刚被提出的时期，由于符号系统过于艰深，工具也难于上手并且不够完善，人们只在小型实验中采用它。随着形式化方法的不断发展，出现了一些新的方法，如Z方法、VDM方法，既可以严格定义，学习起来也不太困难，并且与之相对应的软件也开发得比较全面，形式化方法才渐渐被真正的软件开发人员所接受。虽然形式化方法目前主要集中在安全性较高的一些领域，但是从实际效果来看，形式化方法确实可以改进软件质量，提高开发效率。正所谓“磨刀不误砍柴工”。虽然采用形式化方法在开发初期需要更多的时间，但是与在后期所节省的验证维护的人力和时间相比，还是值得的，并且它也确实可以降低软件的错误率，由此受到对安全性能要求高的用户的推崇。
目前已知的采用过形式化方法的软件开发领域包括：数据库、医疗、核放射监控、保安系统、通信、交通控制等，均取得了不错的效果。
5. 形式化方法小结
形式化方法包含了一组活动和一组模型，它们导致了计算机软件的数学规约。数学规约就是应用一个严格的、数学符号体系来规范、开发和验证软件系统。
形式化方法提供了一种机制，能够克服其他软件工程方法难以克服的二义性、不完整性和不一致性。
形式化方法主要是关注软件的功能和数据，而对软件的时序、控制、界面和行为难于表示。
形式化方法不是通过专门的评审与审计来验证软件的正确性，而是通过对软件的数学分析来验证。因此，它能发现和纠正其他方法发现不了的错误。
形式化方法的理论基础是离散数学中的集合运算和逻辑运算，支持形式化方法的基本概念是：
（1）数据不变式。一个在包含一组数据的系统执行过程中总保持为真的条件。
（2）状态。系统访问和修改的存储数据。
（3）操作。系统中发生的动作以及对状态数据的读/写，且一个操作是和两个条件相关联的：前置条件和后置条件。
从国外一些采用形式化方法开发的成功实例可以发现，形式化方法在严密的数学理论的支持下，确实能够解决软件工程中常见的一些问题。随着形式化方法越来越成熟，相关可视化工具也越来越多，将形式化方法引入软件开发的门槛会越来越低。虽然前进的道路很曲折，但是有着独特魅力的形式化方法终会在软件开发中得到越来越广泛的应用。
＊1.4.6 面向业务基础平台的方法
业务基础平台（Business Framework）是近几年开始使用的新名词，是IT企业开发应用软件的开发环境。近年来，许多软件企业都有自己的业务基础平台。
屏蔽操作系统平台、数据库平台的诸多技术细节，采用面向业务建模来实现软件系统的方法，叫做面向业务基础平台方法。
该方法的特点是面向业务领域的与技术无关的开发模式。
面向业务基础平台开发方法在本质上仍然是面向元数据方法与面向对象方法的综合运用实例，从软件工程方法论的角度来讲，人们并没有将它作为一种单独的基本方法。
该方法的优点：它有效弥合了开发人员和业务人员之间的沟通鸿沟，使开发人员更多地关注业务部分，开发者与用户双方集中精力弄清原始单证与输出报表之间的关系，建立好系统业务模型，而不是关注实现的技术细节，从而提升了业务基础平台中构件的复用性，避免了开发人员开发相同构件的重复劳动，最终达到提高软件开发速度与改进软件产品质量的目的。
该方法的缺点：业务基础平台是面向业务行业领域的，不同行业领域之间的通用业务平台标准尚未建立，也较难建立。因此，不同行业领域的软件开发商，可能有各自不同的业务基础平台。
【例1-8】 北京某公司在业务基础平台的开发方面，处于国内领先水平。名称为X3的业务基础平台，在许多大型企业与软件公司得到了应用，取得了良好业绩。
X3业务基础平台是从信息化的整体、全局数据库和发展的角度出发，为保障信息化成功而提供的战略支撑工具。该业务平台为信息系统的规划、设计、构建、集成、部署、运行、维护和管理等提供高可用性、高合理性的体系架构，真正实现“用户主控，随需而变，全局规划，整体集成”的信息化战略，用户可以在很短的时间内构建起大型复杂的业务系统。
（1）X3业务基础平台构建的信息系统具有如下能力和优势：
● 灵活调整和自由扩展。
● 组织机构和权限管理。
● 业务工作流。
● 表单和报表。
● 业务集成和业务门户。
● 查询、统计和决策分析。
● 快速实施和部署。
● 业务支撑架构。
● 快速构建和业务建模。
（2）X3业务基础平台基本思想，体现在图1-1中。
X3业务基础平台是业务导向和驱动的软件构架体系，现有的信息系统，可直接在技术平台上构建。而基于业务基础平台的信息系统，是在更高级的、基于业务层面的基础平台上构建管理系统，这与现有信息系统相比有着本质的区别。
图1-1 X3业务基础平台基本思想示意图
（3）X3业务基础平台实现原理与方法。
① 实现原理——应用与实现技术分离，如图1-2所示。
图1-2 X3业务基础平台实现原理示意图
它通过将业务模型资源与系统实现技术相分离，从根本上提升管理系统的技术无关性。
业务模型资源是随用户需求而变动的最频繁的部分，通过分离业务与实现部分，可以做到业务模型资源变动时，不影响底层的实现技术，无须重新配置或升级运行环境。而运行环境的独立，则可以保证应用能够跨越实现技术，运行在不同的系统之上，随时零成本迁移到新的实现技术。
② 实现方法——业务模型驱动（BMD），如图1-3所示。
图1-3 X3业务基础平台实现方法示意图
在实现方法上，X3业务基础平台采用“业务模型驱动”（BMD，Business Model Driven）的方法体系和工具集。业务模型驱动是一种全新的管理软件架构和运行模式，它的基本思想是：用业务建模工具来开发管理软件，用业务基础平台来运行管理软件。
业务模型驱动体现了“以业务模型资源为中心”的思想，它要求用业务建模的开发模式，并将建模的结果业务模型应用资源作为管理软件开发的主体产品。在BMD模式下，用户是以业务模型应用资源为主要的目标对象，进行信息系统的设计、构造、发布、集成、维护和管理。
（4）X3业务基础平台的应用体会。
某公司2006年引进X3业务基础平台后，经过简短的培训就能运用自如了。例如，要开发一个固定资产管理系统，只要将该系统的基本表、代码表、报表（又称查询统计表）的定义告诉X3，并用X3定义的业务模型将这些表安插到流程中去，固定资产管理系统就初步开发成功了。
1.4.7 软件工程方法论小结
到目前为止，软件工程方法论包涵面向过程方法、面向对象方法、面向元数据方法和形式化方法这4 种基本的软件开发方法。至于面向业务基础平台的方法，它只是面向元数据方法与面向对象方法的具体应用实例，不能单独作为一种基本方法。
在大型多层结构的信息系统建设中，这4 种方法的关系是：面向元数据方法用在数据库服务器层面的系统设计与实现上，面向对象方法用在除数据库服务器层面之外的其他层面的系统设计与实现上，面向过程方法用在其他两种方法本身内部函数的设计与实现上，形式化方法用在某些核心程序的正确性证明上。由此出发，我们得出如下的认识。
（1）所谓“面向过程方法是传统软件工程方法，面向对象方法是现代软件工程方法”的观点是肤浅的。
（2）只要将“元数据”的概念稍加扩充，即元数据是所有软件系统中组织数据的数据，那么，对于信息系统之外的其他领域，面向元数据方法也是适应的。
4种方法的比较如表1-5所示。
表1-5 4种开发方法的比较
由此可见，4种开发方法各有生存时间和空间，不是互相孤立、毫无联系、彼此对立的，而是互相补充、彼此相关的，所以它们在软件开发领域能和平共处，互相促进，共同构成了一个多极化的、丰富多彩的和谐的软件工程方法论世界。
到21世纪初，面向对象方法的开发平台分为两大类：以SUN和IBM公司为主的J2EE平台和以微软公司为主的．NET平台。这两种平台，都是为了实现多层结构中的表示层与中间层上的开发。数据层上的开发，仍旧是用面向元数据的方法。中间层与数据层之间的连接，采取数据库连结中间件ODBC或JDBC的方式实现。