黄振业

【摘 要】本文阐述了公共软件平台的功能及发展。分析了当前平台开发和应用中存在的不足及在实践中遇到的困难，提出了一种新的公共软件平台的构建方法，并阐明了其优点以及对其开发流程和相应的应用开发模式进行了探讨。

【关键词】公共软件平台；组件对象模型；开放源代码

1 软件平台的产生及发展

软件平台通常是指建构于硬件设备和操作系统之上的应用开发框架，它的范畴并没有一个严格的界定。通常操作系统之上与具体的应用逻辑无关的公共软件部分都可以归于软件平台，当然在具体的实现中平台和应用也经常出现在此消彼涨或相互重叠的现象。

显而易见，软件平台产生的初衷是为了在规模化的软件开发中提高应用软件开发效率，节约开发资源；由于平台完成了绝大部分公共代码，因而应用程序的开发将大为简化，同时采用一套稳定的公共平台也大大降低了测试和维护的工作量。

目前公共软件平台的实现主要包括以下几个方面：

操作系统适配层：通常是一个公共函数库，它的主要目的是封装系统调用，隔离应用程序和底层操作系统及硬件，实现代码的可移植性。

OAM框架：提供公共的操作维护机制。

应用程序框架：主要是为了进一步简化应用的实现或增强某些特性，而引入的公共的服务，如任务管理，状态机模板，以及为了适应分布式应用和负载均分，高可靠性而引入的一些公共的机制或中间件。

开发工具：为了方便应用实现而开发的一些辅助设计和实现工具，如任务编辑器，状态机编译器等。

2 传统软件平台建设中面临的困难

传统的软件平台通常是由专门的团队开发，作为独立的子系统或通过SERVICE LIBRARY的方式提供服务给应用开发人员。但是这种方法有着很多不足之处：

1）平台功能的重复开发严重。由于平台的开发往往是和应用开发同时进行，甚至落后于应用的开发，造成了大量平台功能在不同应用中重复实现和棘手的版本问题。

2）平台后期推广困难。由于市场的压力，很多软件产品的开发来不及针对软件平台做详细的全局的规划，同时由于软件巨大的代码量和复杂度，使后来的平台引入，特别是替换那些已经在应用中实现了的功能变得困难重重。对于那些模块化不好的软件，由于错综复杂的依赖关系和交叉耦合，实际上如果不重写软件，那么不可能实现平台化。

3）平台功能的扩充较慢。平台功能的升级速度很难满足各种不同应用的多方面的需求。

4）对一些复杂应用特性支持困难。采用C函数库或独立子系统的方式来提供对一些高级特性的支持，如分布性与高可靠性，容易造成平台自身结构的复杂化和灵活性的下降。

为了克服这些困难，我们有必要考虑从根本上改进平台开发模式和实现方法，以促进平台在实时开发中应用。

3 新一代软件平台

有一种形象的说法：骑自行车是不可能登上月球的。分析计算机语言的发展历程可以发现，编程语言的每一次升级都带来开发效率的提高和软件结构的变化。要实现更加复杂的功能和特性，通常必须采用更先进的开发工具和方法。

设想一下，如果我们用汇编语言来开发目前实时系统中一个简单的模块，如果消息队列或者协议栈将会是什么情况。实际上，现今的实时软件开发正处于这种困境中，现有的开发手段不足以应付开发复杂度和可靠性要求越来越高的软件系统的要求。同时我们看到，编程语言的发展趋势是随着需求的不断提高而不断引入新的特性和增强的语素-从指令，到语言，函数，对象，再到组件。正是由于C语言的基本语素——函数缺乏支持更高级需求的特征，因而造成了广泛存在的代码复用率和开发效率低下的问题。

综上所述，平台开发和应用中存在的问题主要是和软件的设计方法和开发模式有关。要解决这些问题，必须从软件工程的方向入手，对目前的开发模式进行改造。那么，实时软件开发应该采用什么样的开发工具和开发模式呢？首先，工程化意味着必须有明确的设计、生产、组装、测试的阶段和分工。其次，工程化还有一层隐含的意思，那就是必须在相当大的限度内，软件开发的效率应当与投入的人力资源成近似正比关系。在当前的模式下很难完全做到第一点，即便是做了，效果也不理想；对于第二点，则其限度——即人员的饱和点远远不能满足实际要求。

工程化是产业化的必然要求。如果我们把目光从实时软件转向桌面平台去看一看，或许能从中得到启发。微软已经成功地实现了到软件工程的转化，其根本途径是组件式开发。简单地讲，组件式开发就是像建筑业用砖、瓦、水泥板等预制件来构造一座软件大厦一样。它的根本依据是软件实现的模块化分解和建模，即任意软件可以分解为无交叉耦合的多个模块。模块的划分越细，則并发开发的人员越多，开发效率就越高；建模则是要求按上诉条件分解后的软件系统可以用完备的非代码的方法描述。即开发人员可以根据设计文档完成模块开发和组合。

如果引入了平台的概念，实时软件和桌面软件实际上已经没有本质的区别。桌面软件的开发模式和经验也同样适用于实时软件的开发。因此，组件式开发也将是实时软件开发工程化的必经之路。

4 实现方法

建设组件化的公共软件平台应采取以下几个步骤：

1）制定组件规范。必须针对实时软件的特性对微软的COM规范进行必要的扩展，包括增加支持实时应用的标准接口。

2）选取或开发OS适配库，组件支持库，开发组件编译器，测试环境。这是组件式开发的基础。

3）建立组件资源库，包括管理界面，组件上下载界面，Q/A界面。建立组件资源库的目的是固化已有的软件成果，使其可以继承和复用。显然，组件资源库将随着时间的推移而不断扩大。完善的交互界面可以提高资源库的使用效率。

4）培训开发人员。包括组件的开发和使用，组件的检索，下载和提交。

5）开放资源库，接受提交，测试并发布已提交的组件。观察当前留下的开放源代码的发展可以发现，这是一种非常有效的分布式开发模式。它的成功之处一方面在于能够汇聚零散的开发资源——由于众多的参与者的加入，每一个开放源代码软件都能够得到充分的开发、测试、使用和维护的支持。另外一个成功的原因在于，每一个项目成员的参与，通常都是基于对这个项目的强烈需求或者浓厚兴趣。虽然这种方法来开发一个完整的商用软件是不充分的，但是它却可以成为开发一个逐步积累的组件资源库的最佳途径。特别是如果对于每一个提交都有相应的激励，就能够更加有效地提高向组件式开发转化的进程。开发人员会非常乐于开发和使用组件，并且逐步对已有的软件中可以用组件实现的代码进行转换，从而扩大已有代码的组件化比率，并最终实现全面的组件式开发。

6）当设计人员，开发人员都已经习惯于组件式开发时，原有的开发队伍就会自然而然地分化为：系统设计人员、组件开发人员和使用者。很显然，他们的功能分别对应于设计、生产和组装，这正是软件工程的要求之一。

7）随着组件资源的不断积累，新的应用软件开发将变得越来越简单，效率也越来越高。

与传统平台相比，新的方案具有以下几个优点：

1）强调了平台自身的模块化，即使用者可以根据需求选取必要的功能模块，而不必依赖于庞大、复杂的平台子系统。

2）应用开发人员可以根据自己的需求对已有的平台功能进行扩展和扩充，而不会影响其它的使用者。这大大提高了平台的发展速度。

3）良好的组件规范和设计方法能够保证么一个组件都成为恒久的软件资源，使之不会随着产品的升级换代而流失。

4）统一的资源库使不同应用之间也可以实现组件共享，从而实现整个公司范围内开发资源的优化。

5）可以促使开发人员提高模块化意识，改善软件结构。

当然我们要做到这些，前提是必须制定和实施完善的组件对象模型规范。从长远的发展考虑，越早实施新的方案越有利于开发效率提高和资源的积累。

【参考文献】

[1]汪瑞嵘，等.基于SOA的软件公共服务平台设计与实现，软件产业与工程，2014.11.

[2]Samuel Qu，Using COM+&UML for Real-time Software Design，2003.endprint