摘要：软件复用是当前软件开发研究的重点，本文针对领域产品的开发过程中的复用策略与方法从系统分析设计到编码各阶段讨论了软件的领域复用与层次复用等方面的问题。

关键词：电子政务、软件复用、领域架构、层次架构、可复用组织

随着信息化技术的发展普及，电子化公文管理成为政府机关的一个战略性课题。为了进一步推动政府信息化的建设，必须进一步研究和开发适应新时代的基于Internet和Intranet的公文管理系统，以提高机关公文办理效率，提升政府绩效。正是在这一市场机遇下，我们研究开发了公文管理系统产品－DocMan公文管理系统(以下简称：DocMan)并取得了良好的市场效果。

DocMan公文管理系统是面向政府机关的公文处理系统，是电子政务的主要组成部；因此，DocMan和其他电子政务子系统一样存在跨平台、分布、异构以及对原有应用系统进行整合的问题。为了面对各类机关的应用需要，DocMan公文管理系统，采用了多层B/S架构（客户端浏览器层、Web服务器层、应用服务器层、数据库层）、并采用了J2EE及EJB技术实现系统的分布异构及跨平台。为了满足各类机关的需要，DocMan对流行操作系统（Win32系列，Unix系列，linux系列）、Web服务器（Tomcat4.0,IBM WebSphere4.0,BEA WebLogic 5.0）以及数据库管理系统(Oracle ,SQL Server , Sybase,Infomix,DB2等)都给予支持。在考虑大型机关应用时，我们选用了代理服务器、多并行Web服务器及多应用服务器技术实现系统的负载均衡和流量管理。由于当前分布式数据库的应用不够成熟，DocMan采用了集中式数据库技术实现机关数据的存储。

现就我们在开发DocMan产品时遇到的有关软件复用方面的问题、解决方法以及实现策略介绍如下。

一、需求重用

1 企业产品领域的定位

随着政府上网工程的推进，电子政府与电子政务正逐步走向成熟；并给软件行业带来了新的业务领域，而我们所开发的公文管理系统只是电子政务的一小部分；因此我们公司将业务定位于电子政务行业。电子政务需要的软件产品众多，而公文管理系统可以看作是政府办公自动化软件的一个子系统，在公文管理系统开发完成后，我们将进一步开发政府办公所需的其他软件子系统，逐步为政府行业的应用提供全套的解决方案。

2 领域工程核心的识别与抽取

在产品领域定位的指导下，我们经过深入的分析调研，发现所有的事务型系统都有一个共同的特征：工作流程。在ISO9000中也规定任何组织的事务处理必须有标准，规范的工作流程。（在ISO9000中为了实现ISO9000规定的20个质量要素，必须制定相应的体系文件。这个体系文件分为3层：第一层质量手册，制定组织的质量方针、目标；第二层工作程序，制定为了实现质量目标所定义的工作程序即工作流程；第三层表单，制定了在工作程序运行过程所用的表单。）在系统分析时，可以将这些业务工作流程抽象出来，如公文管理中的收文流程、发文流程、归档流程、稽催流程、档案管理流程等；另在非公文管理的其他的业务中也可以抽取流程如：车辆管理业务流程、会议室管理流程、请假加班流程等等。因此，我们可以建立一个工作流平台，使所有的业务流程只要在工作流平台中进行定义就可以运作。从而实现"零代码编写的理想目标"。

3 产品非业务性需求分析

一般的应用软件产品除了完成业务所需要的功能外，还必须有一些支持模块，以支持系统的正常运行。这些模块通常包括：组织管理模块和系统支持模块。组织管理是机关业务得以正常运作的基础，这对于每一个电子政务领域内的应用系统来说都是必不可少的。通常系统支持模块是为了软件系统的正常运作所提供的必不可少的功能，如系统权限管理、日志管理、数据库备份/恢复功能等都属于此类。所有的这些都可以作为我司系列软件产品的公共模块加以复用。

4 产品界面风格

对于企业来说，保持系列产品在风格上的一致性是非常重要的。它不但可以减少系列产品的广告费用，减少系列产品的维护、培训费用；而且还可以在软件开发时进行界面风格复用，减少软件开发费用。因此在企业进行系列产品的开发时保证产品在风格上的一致性、操作方式上的一致性是至关重要的。

二、设计重用

1 领域架构的设计

在产品开发之初，我们识别了所有的业务流程都可以运行于工作流平台之上。因此，我们在产品设计时，采用了以工作流平台为核心的领域软件产品设计架构。如图1所示。

该工作流平台除了向产品最终用户提供流程自定义工具，使用户无需编程就可以自定义出所需要的工作业务流程，并可对流程流转过程进行实时监控；之外，还向软件开发人员提供了快速应用开发工具以及API接口，使开发人员只要调用该工作流平台API就可以实现复杂流程业务程序。

2 层次架构的设计

在选好系统领域框架和统一开发方针后, 系统构件的开发就应充分利用已有框架所提供的服务和工具；并力求实现大粒度构件重用。通过系统构件的分层，将频繁变动得业务逻辑层分离出来，实现通用类构件的完全复用。并且在各个模块之间设计统一的接口，当某一模块业务逻辑改变时，使系统之间的影响最小，使系统实现即插即用，让系统容易升级。为此将我们将产品的系统构件模型定义为四个层次：1）系统构件层、2）通用模块构件层、3）业务构件层、4）表现层。如图2所示。

图1 领域构架

图2 层次构架

（1）系统构件层，指系统开发平台本身所提供的类库包括Java JDK类库等。

（2）通用类构件层，是我们产品复用的核心。它不但能实现产品的纵向复用，而且还可以实现系列产品的横向复用。在这一层主要包含了工作流平台核心模块、组织管理模块、系统管理模块（包括：权限管理、存取控制、日志管理、数据备份/恢复等等）、页面风格函数以及JSP的CSS、JS等、字符串处理、数据库连接、日期处理等等与业务逻辑无关的类函数。

（3）业务构件层，指为了满足各个不同业务的需要而设计的软件包，并在业务软件包中设置明确的接口，方便业务之间的交互，并可以实现系列产品之间的大粒度构件复用。

（4）表现层。主要采用JSP、Serverlet页面来展现业务流程界面。在该层JSP只调用JavaBean业务逻辑接口方法实现业务逻辑的处理，而不涉及任何业务逻辑,在系统中取到用户与系统交互的作用。

3 面向对象的设计

在系统开发时，我们采用了面向对象的技术。通过面向对象的方法、消息、类、继承、封装、多态和实例等机制构造软件系统，并为软件复用提供强有力的支持。

（1）模块化设计 在设计时我们采用了面向对象的包机制实现对业务流程的模块划分，如公文管理系统的发文流程、收文流程。在模块之间通过定义明确的消息机制与方法接口实现模块之间的交互。另外，在模块划分时，我们还注意到了底层模块的抽取，尽量将用户会话接口包与业务实体包相分离；如在工作流平台设计时我们从中抽取了与用户接口无关的工作流元模型包和工作流引擎包，他们可以向其他包提供调用接口方法，实现尽可能的大粒度重用。

（2）类设计 在类设计时，我们采用了类的封装、继承、多态等机制实现类设计复用。在类中实现了所有的处理逻辑，这些类中一般都可以提供新增、删除、修改、查询四大类操作，并尽可能的提供处理逻辑所需要的方法接口，实现一次编写处处运行的理想目标。采用继承和多态机制后子类的实现可以继承父类的各个属性与操作，从而避免了相似功能的重复编码，提高了程序的可维护性，简洁性、可读性。

三、代码重用

在采用上述可复用的分析、设计方法后，系统的实现将变得相对的容易。在各代码段的实现时，只需要调用明确的接口，就可以实现处理功能，降低了算法的复杂度，大大提高了编码的效率及程序的可维护性。在编码时，我们主要采用了JavaBean和JSP技术实现了业务实体逻辑和用户系统操作接口。在JavaBean中充分采用了Java的优秀的面向对象机制，实现了业务实体类的处理逻辑，并尽可能的达到了JavaBean方法的一次编写处处运行的目标。在编写JSP时，我们完全引用了业务逻辑层的JavaBean，从而使JSP的页面编写变得简单，并实现了业务逻辑的封闭性，提高了JSP程序代码的安全性。

另外，在编码过程中的一个重要复用是算法的复用。由于在类设计时基本上每一个类都提供了相似的功能，如新增、删除、修改、查询，而这些操作的算法基本上是一致的，差别只在于SQL语句的差别；所以在设计编码时，可以先设计一个基类提供这些功能，在其他类实现时可以继承基类并重载或应用这些方法，实现算法的重用。

四、复用的组织结构

在软件复用的过程中，仅仅有软件复用方法是不够的，还必须有复用的开发组织结构可以支持。因此，我们在产品开发过程中建立了复用的组织架构。一般的复用的组织架构主要由三组成员组成：复用构件创建组、构件应用组和协调组。复用构件创建组，主要收集归纳并创建可以复用的构件提供给构件应用组使用；构件应用组主要进行业务逻辑的设计与实现，在开发过程中使用构件创建组提供的可复用构件进行业务逻辑的快速实现，并帮助构件创建者归纳，收集可复用构件；协调组主要在构建创建组和构件复用组织间起协调的作用，起到构件的分发推广的作用，在项目较小时可以由项目经理或系统分析员充当。

其实在软件复用过程当中，不仅仅通用构件层提供的类函数可以复用，在业务层模块之间也可相互引用。但是在引用时，也应该尽量避免模块之间的交互，提高模块的内剧性、降低模块间的耦合性。在模块之间的引用协调也由协调组完成。

五、软件部件库

在软件复用过程当中，我们建立了软件部件库以进行可复用构件的推广使用。在构件创建完成后，创建者将该构件存放于产品项目工程中提供应用组使用；并用JBuilder生成JavaDoc文档存放于Visual SourceSafe部件文档库中以便应用时查询，同时通知每一个开发成员。

当应用组成员需要调用通用构件或其他模块的方法或函数时，直接应用即可；如果在软件部件库中没有他需要的方法或函数，则可询问协调者，由协调者解决该问题。协调者可以通知创建者进行创建提供或用其他方式解决。

六、结论与不足

在公文管理系统及电子政务产品开发过程中，我们主要采用了以上方法进行软件的复用开发。实现了产品领域横向的复用和产品开发过程中的纵向层次架构的复用；并在软件开发过程中采用全程（从需求分析到编码实现）复用的策略进行软件开发，从而大大提高了软件产品的可复用性，提高了软件开发的生产率，并为后继产品的开发提供了良好的可复用基础。但在开发过程中也存在一些不足，有待于我们进一步改善。如：

（1）系统分析设计的力度不够。由于在系统开发过程中系统分析设计人力不足，在项目紧任务重的情况下，没有对分析设计文档审核就开始编码实现。因此对分析设计过程中存在的错误没有进行及时改正。另外，对模块包的划分也没有仔细的考虑、验证，对某些类的设计也不够合理。

（2）开发组成员软件复用意识的不够。由于开发人员软件复用意识不够，在成员之间沟通不力的情况下自行编写底层构件，从而降低了软件的可维护性；而更有甚者在业务模块编写时，直接在JSP表现层实现对业务逻辑的处理，而没有抽象为JavaBean，虽然在表面上提升了单个模块的开发效率，但却降低了整个开发组织的效率、可重用性以及程序的安全性。

（3）开发人员面向对象知识的欠缺。在开发过程中由于开发人员面向对象知识的欠缺，在设计实现时没有采用面向对象技术，从而降低了软件的可重用性。

（4）面向对象分析设计工具的欠缺。由于在分析设计过程当中，我们没有很好的运用Rose等分析设计工具，从而加大了分析设计的难度，降低了文档的可维护性、修改性和可复用性。

在下一步的开发过程中我们将尽力的改善这些状况；以便为国家的电子政务事业提供更多更好的软件产品，为国家电子政务事业的发展作出更大的贡献。