软件自动化概述在线视频

嗨，大家好

今天我们来讨论软件自动化的话题

首先，我们一起来看两个有关自动化编程方面的
传说

第一个是来自芝加哥的报道

据说有一家名为Care Technologies的软件公司

最近向外界公布了他们最新的研究成果，有一款叫
OlivaNova的软件

据说这款软件可以把应用程序的开发速度提高47
倍

还可以减少编程错误

这个软件编写出来的代码，它的错误只有手工编程的7%

据说OlivaNova支持的开发平台有Windows

和几乎所有的Unix/Linux

并可自动生成VB 6、JAVA/EJB、JSP、

.NET等等

还可以用来开发Web、C/S、Web Service等等各
种各样的程序

第二个传说叫Genux，它将整个软件开发过程

通过自己的平台重新定义为

需求捕获、建模、自动化实现和部署这样几个阶段

据说一个复杂的ERP系统，不懂编程语言的两个
业务专家

只干了2到3个月就完成了

演示的时候，报道者要求当场增加几个数据库字
段

在非常复杂的界面之上再调整出几个更复杂的界
面

本来想难为难为他们

但是没成想几分钟之后，修改就完成了！

真是不可思议呀

这些报道估计有夸张的成分

但可以看的出来，人们对自动编程的追求是永无
止境的

从自动化编程所需要的技术来看

只有当形式化研究和人工智能在取得长足发展的
情况下

各种软件模型都能够由计算机直接生成

这个时候自动化编程才能真正大范围的应用起来

我们之前在讨论软件工程自动化的时候

举过一个例子

在我们的技术水平达到高级自动化的时候

软件开发公司就彻底消失了

如果客户需要一个软件

他只需要对着计算机说出想要软件的功能

话音刚落，计算机就会自动生成一套完美的软件
系统

就如同科幻电影当中所揭示的那样

当计算机有了人工智能，可以自我进化的时候

是不是代表着人类统治的终结呢？

经过一番神游之后，我们还是回到现实中来吧

大家知道，软件工程的发展方向，从大的方面来
说有两个

一个是形式化，一个是工程化

形式化从数学方面来关注软件开发技术基础

研究如何表达“做什么”

工程化主要关注的是“怎么做”

从个人到团队，从设计到实施

在软件开发中，形式化方法一直受到多方争议

拥护者认为形式化方法会引起软件的革命

反对者则认为形式化方法中所包含的数学理论

限制了大多数程序设计人员的学习和使用

并且目前缺乏对软件生命周期各个阶段

能够提供全面支持的形式化方法和工具

最终可能会延误项目开发周期，增加开发费用等
等

形式化方法本身的知识比较高深

我们这里只是简单的了解一下什么是形式化

它研究什么内容，现阶段我们软件开发人员能不
能用它

从广义上来说，形式化方法就是借助数学的方法

来解决软件工程领域的问题

主要包括建立精确的数学模型以及对模型的分析
活动

狭义来说，就是指运用形式化的语言

进行形式化的规格描述、模型推理以及验证的方
法

也就是说，我们通过很精确的

无歧义的规格描述语言把来自应用领域的需求

翻译成计算机能够识别的描述

很明显，机器是没有办法来理解和执行我们的自
然语言

因为无论是英语还是汉语，都是不精确的，都有
歧义

而计算机执行的命令必须是明确的，无歧义的

形式化方法的出发点是数学逻辑方法

它的目标是开发出可靠的软件产品

这和工程化的目标是一致的

因此，我们可以从现有的方法出发

来研究如何将这些方法形式化，使软件系统的描
述更精确

以减少可能的误解所带来的问题

或者以目前的软件开发过程为出发点

研究怎样在软件开发过程中增加一些形式化方法
的应用

以提高软件的可靠性

形式化的软件开发，就是用形式化的语言

来描述软件需求和特征

并且通过推理验证来保证最终的软件产品

能够满足这些需求和具备这些特征

这样的验证当然需要建立在严格的语法和语义的
基础之上

在实际应用中，这是不容易做到的

形式化方法研究的目的就是希望能够提供

更好的理论、方法和工具

扩大形式化方法的应用范围和使用价值

实际上，如果我们仔细观察

可以发现形式化方法在软件开发过程当中

能够起到的作用是多方面的

比如我们用UML用例分析技术对软件的需求进行
描述

用类图对设计进行描述

将类图直接生成软件代码等等，还有软件的自动
化测试

形式化方法的研究目前主要分布在三个方面

第一个方面就是继续加强对基础概念的研究

包括在软件开发中具有基础地位的

复合、抽象、复用模型、数学理论组合

数据结构及算法等等

第二个方面是形式化方法与面向对象方法的结合

这方面的研究又体现在两个方面

一是利用面向对象结构来提高形式符号的表达能
力

二是利用形式化方法来分析面向对象的语义

或者提高这些标记符号的表达对象概念的能力

第三个方面是形式化工具的开发

用户界面良好、易于学习，操作简单的

这种形式化方法支撑工具的开发

对于形式化方法的推广具有很重要的意义

追求通用的，完善的形式化方法和对应的支撑工
具是不现实的

侧重于某一个或某几个方面准则的特色方法和特
色工具是未来研究的重点

比如，我们应该首先开发和推出那些收效快的

开发人员用了马上就能看到效果的

学习成本低的，易上手的

输入输出简单，易懂易读的

还有那些可以用在软件开发各个阶段的形式化工
具

好了，形式化方法我们还是浅尝辄止吧

大多数开发人员自己虽然对形式化方法充满了敬
畏

但是却对自动化工具充满了憧憬和期待

我们来看一下业界在软件自动化方面做出了哪些
努力

首先应该关注OMG推出的MDA

MDA是在UML2的基础之上的一个框架

它支持软件设计和模型的可视化、存储和交换技
术

它的最终目标是实现从UML企业化模型到

最终代码的自动化生成

MDA推出之后，相继有很多业界大公司宣布支持
MDA

它们努力的开发出了一些激动人心的软件开发工
具

比如XDE和Together

有人预言，未来一旦MDA大量应用

软件自动化程度大大提高

大量低创造性的工作岗位，如软件蓝领，就会失
业

但无论如何，要在未来的软件开发活动中立足

我们永远都不能放弃创造性思维的培养

下面来具体的看一下MDA模型

这个模型是典型的分层架构，上层的PIM是抽象程
度最高的

它只与业务有关，独立于任何实际的实现技术

因此这个模型只随业务变化

在未来可以由更高的技术来实现

第二层就是PSM模型

这个模型是与具体的实现技术相关的

也就是对系统的设计

代码呢，就是对PSM的直接翻译

在目前的技术水平下，这是最有可能实现自动化
的部分

大家需要注意是，PIM文档和需求分析文档是不
同的

PIM文档是给类似编译器的自动工具阅读用的

所以应该是形式化的

变换工具在MDA中的地位举足轻重

它扮演了传统编译器的角色

编译器则退居到了目前汇编器的地位

其他的各层工具依次后退

调试器也将逐渐进化，就像从机器码级的调试向
源码级的调试过渡那样

慢慢过渡到模型级调试

同样的，IDE编辑窗口显示的不再是代码，而是
图形模型

开发者谈论设计模式就像我们现在谈论API函数
一样

而代码模式将完全由变换工具自动生成

不再是大家关心的内容

MDA的这三层架构，也可以视为一种开发模式

金蝶公司在国内的软件市场具有较高的知名度

它在93年推出基于DOS的财务软件

96年推出了基于WINDOWS的财务软件

98年又推出基于三层架构的管理软件

在这期间，随着WINDOWS操作系统和数据库系
统

一次又一次的升级，金蝶被迫做出了很多次的产
品升级

这种管理软件对技术平台的依赖不仅大大加重了
软件厂商的更新成本

也对用户造成了很大的影响，增加了系统的维护
成本

金蝶的EAS从4.0开始就按照MDA的模型进行开
发

它首先建立元模型，将管理软件的所有应用原子
化

为业务语言开发打下了基础

然后在元模型的基础上，运用建模工具建立业务
模型

然后在元模型的基础上，运用建模工具建立业务
模型

包括组织模型、功能模型、信息模型、流程模型
等

这些模型属于平台无关的模型

最后，根据不同的平台对业务模型进行模型编译

生成对应平台的实现模型

这种开发方法，将传统的业务模型和平台相关的
实现进行了分离

摆脱了管理软件对技术基础平台的依赖

同时，从业务模型到不同平台的实现都保留了一
致性

同一套业务模型，既可以在J2EE平台上实现

也可以在.net平台上实现

下面我们对比一下传统开发环境和MDA环境的差
异

首先来看传统的开发环境

我们先看人员分工和自动生成的部分

UML模型是设计师或架构师完成的

然后有一小部分的框架可以自动生成

比如类的声明，属性和方法的声明等等

编程人员完成了MVC结构的几乎所有内容

包括用户界面，业务逻辑和数据访问等等

我们再来看一下MDA环境

首先是UML模型跨越了建模工具和开发工具

架构师和设计师的创造性工作得以扩展

这对软件产品质量的提高具有重要的意义

其次是从UML模型自动生成涵盖了数据访问部分

尤其是随着ORM工具的日益成熟

极大的降低了开发者的劳动强度

MDA模型呢，根据之前的形式化描述

可以完成大部分的业务逻辑自动化生成

开发者只需要编写部分核心的复杂逻辑

如果对系统自动生成的这种千篇一律的界面感到
不满意

可以对界面进行手工的个性化的调整

可以对界面进行手工的个性化的调整

好，今天就讨论到这里，谢谢大家