谢谢王云的问题。对通用软部件（简称部件）作清晰的界定将有利于部件技术的发展。我们前面文章中说明部件是粗粒度的可复用的代码封装体。这里，粗粒度的概念是什么？我们认为可以从以下三方面说明。 1、部件是应用系统的顶级模块，是包括模块级人机交互界面、数据控制（包括数据完整性约束、安全性控制）、数据变换、通信、代码变换、简单数据处理操作等代码的封装体，它的每一次复用将建立系统的一个程序模块。有必要与面向对象技术做一个比较。对象，用一般人不容易弄明白的语言去描述，其意义是指实际存在的事物的抽象，包括数据与行为。而对程序员而言，对象是类的复用，是类的实例。类是单个数据级的人机交互界面、数据域完整性控制、简单操作控制（消息驱动）等代码的封装体，它的每一次复用将建立程序模块中一个控件。为了使类能适用于任何场所，调用（复用）时需要给出接口参数，例如名称、所代表的数据（数据源）、其原始模板（生成该控件的类的名称及相关特性）、位置与形状等几何与图形特征、域完整性约束条件、控件的操作特性等等，这些内容用“属性”来表示。它被用到不同程序中可以实现不同的功能，利用方法来实现。这些方法在复用到其他地方时，许多代码要由程序员填写，这一部分内容不能复用。尽管从类派生生成对象的过程需要人工操作，存在大量无法复用的部分，但是该技术对于提高程序设计效率与质量发挥了大家都公认的作用。对于一些最简单的程序，在一个系统建立过程中，需要程序员书写的代码可能不到系统全部有效代码的20%，我们说该系统代码复用率可以到80%以上；也有一些程序中代码复用率可能在50%以下。但是，不管怎样说，需要人工设计的代码量减少了很多。从上面比较不难看出，部件封装了更多的内容，由于它将一个模块所有控件都封装了进去，处理好了控件间，也就是数据间的相互联系；它包括了数据变换与通信接口等内容，也就处理好了模块对外的联系。我们所设计的数据维护、一般常规查询、常见导入导出与简单报表等部件中还封装了全部数据操作代码。这些内容对于程序员与用户都是一个黑盒，在设计时无须考虑其内部的实现，使设计简化，我们统一设计的接口参数变量不到20个，如果有数据完整性控制等特殊要求再另外通过常规接口参数表、数据变换接口参数表（字典表）、通信接口参数表等传递控制信息。这些将使利用部件技术构建的系统具有更高的代码复用率。目前我们研究的部件主要是管理信息系统领域的部件，对于一般管理信息系统而言，数据维护、查询、导入导出与报表模块占据模块总数的80%以上，这就使得一般管理信息系统设计复用率可以很容易地达到70%到80%，这是一个很可观的数字。在建筑行业中，大多数建筑主要是利用标准件建设，但是临场还是有许多需要现场浇注的梁、柱，有的还需要现场制造其他构件。至于全新的机器设备，则更多的部件需要当时设计与制造。即使是老的设计，也常常需要外加工的补充。可见，一个系统要求完全复用是十分困难的，一般在后台进行业务逻辑和数据处理的部分，例如复杂的查询、特殊的导出、复杂统计与报表、数据分析、编制计划或其他决策支持程序，还需要人工设计补充。 2、软件复用无止境我曾请教一位研究构件的权威教授，以后关于软件复用的研究内容会是什么？他的回答是，目前关于构件研究已经十分彻底了，软件复用方面已经不会再有什么好的课题了。我们不同意这样的观点。软件发展与软件复用研究始终紧密联系在一起。机器语言是用二进制数字描述硬件的操作；汇编与高级语言用助记符与语句代替一到多个二进制代码，使方便了程序的编写。至于伴随汇编与高级语言出现的循环、子程序、函数、过程、宏开始了代码复用的历史。软件工程诞生后，复用内容从代码扩展到文档，软件复用成为软件工程研究内容不可或缺的部分。这以后差不多过了二十年，出现了面向对象的理论与技术，代码复用率大幅上升，程序设计效率大幅提高。但是我们必须看到，面向对象设计增加了代码冗余，降低了处理速度，使得一些要求高的程序还得用面向过程的语言书写。我们可以这样认为，面向对象设计技术适用范围变小了，在这些领域，需要研究与发展如何在满足环境要求与设计要求的前提下提高软件复用率的问题。我们还应当看到，面向对象技术的出现，使得原来一些面向过程的程序设计变得十分简单，有的甚至只需要根据向导的指引，不需要编写代码就能实现。但是，人们并不感到轻松，甚至觉得程序设计难度更加大了，不仅要学原来面向过程设计的全部知识与理论，还要掌握大量的类库与可视化操作工具。这是因为，面向对象技术将计算机理论与技术向前大大推进了一步，计算机应用范围更加大了、应用更深入了。这个范围与深度的变化也要求面向对象技术与时俱进，不断发展。根据上面的分析，我们可以预计，部件技术也会遇到同样的问题。部件的代码冗余更大，处理速度会进一步受到影响，部件的适用范围会更小。但是也一定会促进计算机理论与技术的发展，会将计算机应用的范围与应用的深度再向前推进，将要求部件技术自身不断向前发展。部件技术深入研究不会让软件复用研究走到尽头，软件复用实现的难度会越来越大，但发展不会停止。在自适应工资管理系统一文中看到的设计不仅可以复用到其他行业的工资管理上，还可以用到各种单一主数据表、所有处理都以字段为基本单位的其他系统或子系统中，可以看成是系统级或子系统级的复用产品了，但它是不能被称为部件的，也不要求封装。基于以上分析，我们不妨预言，软件复用技术的发展将伴随软件发展全部历史，关于部件的研究还仅仅是开始，需要我们更多地去投入与研究。 3、在设计部件时要尽可能地将非复用部分独立出来。关于数据处理的部分变化很多，要想所有处理代码都来自复用是不现实的，只能逐步积累，慢慢提高这一部分的复用率。往往还需要以往的设计方法。但是，为了取得较强的适应性与可扩展性，提高程序设计效率，应当尽可能地将这一部分代码从部件封装体中剥离出来、形成相对独立的部分。在复杂查询程序与复杂报表设计时我们考虑了这一问题。在《单数据表查询部件设计》一文中我们就曾介绍，可以将该部件做生成器用，程序员利用该程序按查询要求操作，部件程序可以将每一步操作生成的代码记录下来，存放到数据库中，在再复用调用时从数据库中取出存放的代码并执行。也可以将手工设计与输入的特殊的数据处理代码也存放到数据库中。这样，处理有关的界面部分代码已经封装到部件中，无须程序员操心，剩下的工作就和原来面向过程的设计差不多了。在我们设计的部件库中有专门的批处理部件，其中就设计了这样的机制，允许将数据处理的过程程序存到数据库中，该部件可以直接用程序号（记录号）调用，程序设计工作量与系统设计难度都大大下降。 关于“对于数据量比较大的表，如百万级、千万级数据量的表，以及并发访问量比较大的情况下，系统性能怎么样” 这一问题，我们目前还没有实验数据。前面已经提到，我们目前设计的部件代码冗余量大，会影响降低处理速度。但是可以研究能适应大数据量的专门部件，原则上，部件主要还是解决人机交互界面设计问题，其他是高级设计内容，而人机交互界面设计对于大数据量处理影响较小，一般程序能够达到的指标，部件也应当可以达到。另外，在设计时需要考虑查询优化问题，例如在设计多表查询部件时，应当有先进行连接再查询的部件，也要有嵌套查询的部件，既是为了满足不同查询要求的需要，也有助于提高处理速度。目前我们只有部分部件实现向B/S模式的移植，而且移植生成的部件无法实现自适应及完整性控制等功能，主要受开发语言表达能力的局限，我们正在加紧研究解决部件通信问题，随着这一问题的解决，在网上部件的功能与性能才能趋于理想。

转载本文请联系原作者获取授权，同时请注明本文来自程学先科学网博客。
链接地址：https://blog.sciencenet.cn/blog-2551-4643.html

上一篇：单数据表查询部件设计
下一篇：<管理信息系统及其开发>内容简介