我们于2015年向当年软件工程学会年会投稿，NASAC2015组委会组织评审的二位专家的评语1：“通过自上而下设计软件资源库，可使得管理信息系统的开发过程中，具有设计快捷、高速、高效、质量优良、维保成本低廉等优点。”和评语2:“本文从采用自上而下的方法设计软件资源库，并提出一种设计管理信息系统软件生产线的方法，内容涵盖软件生产线的方方面面，内容详实”。组委会通知说：已被录用为短文并推荐至期刊《计算机科学》发表。不过，我们同时向会议原组委会型竞赛投稿，由于组委会工作方面失误未向专家提交审核，经我方要求组织了审核被拒。已在我们的博文：《难道只是失误吗？-给14届全国软件与应用学术会议代表们的公开信》（见http://blog.sciencenet.cn/blog-2551-933380.html）中详细说明。这一事件之后，组委会毁约未再向计算机科学杂志推荐我们的文章。去年，我们对文章修改后，增添了一些新研究内容。考虑到计算机科学杂志社与软件工程学会联系密切，向计算机科学杂志投稿，但被其正刊所拒，其依据是他们所聘请的三位“专家”的评语。我们向编辑部陈述了对这些评语的意见，但未收到对我们的意见的回复。

  一般“专家”要枪毙一篇文章或一个项目，杀手锏之一是宣布该文章或项目不具创新性。本来，这很容易论证，目前百度还有各种网站都提供搜索功能，网上一搜，如果没有创新性，一定可以找到数以万计的同类作品。但是，“专家”们不必担心，他们写评语时不需要用事实做后盾，只要根据掐头去尾的一个内容进行论定就可以了，没人找他们的麻烦，即使有投诉，装聋装瞎就是了。看：

 

  第一位专家说：“软部件实现和复用技术不是新鲜的话题，工业上已经有完整的体系，已经有很多成形的软件系统。”。另一位“专家”说：“论文中提到的“通用软部件”，“UML建模”概念已经是比较成熟的技术”。

 

  关于“软部件实现和复用技术不是新鲜的话题”是大实话，至于“工业上已经有完整的体系，已经有很多成形的软件系统。”还有““通用软部件” 已经是比较成熟的技术”就经不起推敲了。本文附件列出在中国学术期刊网络出版总库全部字段中搜索“软部件”一词的结果，找到相关的中文期刊 91 篇,用时 0.007 秒。其中有些附了摘要，有些没附，这些没附的是我和我的研究生的作品，可以认为是一家之言。可以发现，在学术期刊中，涉及“软部件”一词的就不多，涉及“通用软部件”的就更少，至于“工业上已经有完整的体系，已经有很多成形的软件系统。”和“是比较成熟的技术”，就是在信口开河了。

 

  文章要表达的一个思想是认为目前关于构件、组件、部件等概念界限不清，有必要加以区分，以有利于大家的研究和讨论、有利于“软部件”技术的发展。有一些文章、研究生论文、一些著作中都使用了“部件”这个词，但是多数文章中关于该词的定义和“构件”没有区别。我们文章认为在设计包括多个类的可复用代码产品时有二条路线，一是“从上而下”地设计，需要对所有应用系统的构成进行分析，取其中可以复用的部分加以整合与集成，得到软部件库。另一种是“从下而上”，从已经设计出来的某个领域中的系统模块中，补充或修改设计，使其具有可复用性，处理好接口，就可以复用，这是大多数文章称之为“构件”的设计。还有一些例如中间件，在应用系统中不是完整的模块程序，只是构成一个程序的部分，常称为“组件”。但是，多数作品不这样明确区分和定义，三个词混用，不利于研究与讨论。第一位专家大概就是这一逻辑，既然“部件”就是“构件”，“软部件实现”就是“软构件实现”吧，其研究就太多了，你们的文章也就不存在创新性了。目前，确实有不少公司或在某领域内建立了软构件库，形成了自己的软件系统，但其中构件不适用于其他领域，称为领域构件。领域构件的应用和研究确实也比较广泛，但还不能说是“成熟”。因为，还没有统一且准确的规范和标准，没成为教科书中成熟的理论，没在全软件产业里统一应用。在90年代末开始研究“构件”时，当时有关项目申报的最终目标是软件生产工业化，这些项目都通过了验收，但软件生产工业化的目标却不再被人提及了。90年代末到本世纪初，北京与上海都建立了软“构件库”，希望能为社会提供可复用软件，降低软件生产成本、提高软件质量、降低软件维保费用。它们在部分地区曾发挥了一定的作用，但是同样不算成熟。面对这些情况我们还不应当反思吗？不应当将原来的研究再向纵深推进吗？我们提出的区分部件和构件，正是希望能找出原来研究中的问题或者找到有可能突破的新的方向或方法。

 

  关于“UML建模”倒确实是成熟的。它是统一建模语言，是对象管理组织制定的标准，是一般计算机专业大专生的学习内容，是目前多数产业进行产品设计的必用工具。但是，我们文章讲的并不是“UML建模”， UML建模是面向对象的，其最基本元素是类与对象，基于类与对象的建模软件无法完成全应用系统的建模。我们讲的是应用“部件”建模，“部件”是类的集合，是完整程序，是直接构成应用系统的程序模块，面向对象的UML无法以“部件”为基本元素组织建模。事实上，目前流行的UML建模软件都无法自动生成应用系统，甚至无法自动生成程序代码。有一些研究希望完成UML所提出的正向工程，自动生成应用程序，但如同Rose这样使用特别多的成熟建模软件也只能自动生成程序框架，离自动生成应用系统还很远，甚至已经有许多人认为，正向工程是不可能实现的。

 

目前，关于自动生成程序代码、软件生产线的研究很多，有好多研究宣布实现了代码自动生成，甚至宣布建立了软件生产线、能自动生成应用系统。但是，还没有一个系统得到公认，没有一个系统被普遍推广与应用。其中，有些是某一家研制，服务于某类特定企业，实际是基于行业内领域构件实现的，不能普遍应用于一切应用。有些只是实现自动建库、建表；有些能自动建立网页。其中有一个比较受推崇的软件的2016版也只能自动建立某些应用程序的代码，该软件配备的组件极少，类型也极少，许多都要求从控件设计开始，要求使用流程图定义程序逻辑，再建立网页式的系统。其生成程序的界面不丰富，和我国应用实际需要的界面相差比较大；其建模方式与UML相差太多，许多要求绘制最原始的程序流程图，难学难用。不妨回顾一下面向对象技术发展历史：类与面向对象于上世纪50年代被提出，但到90年代才普遍被应用。能被普遍应用得益于MFC、jdk及许多面向对象语言的类库的建立于完善，这些类库中的类与应用无关，只与语言或平台有关，在不同应用系统中都可以使用，学习容易与使用简单促使其被普及。它的应用使得程序设计效率大大提高、软件质量大大提高、维护成本降低。每个类都集成了多个方法，只要选择方法、配置参数就可调用，无需修改代码，开发难度大大下降。借鉴这段历史，当前要实现软件工业化生产的目标，所需要的可复用软件也要求是能直接、不加修改被调用的代码块，只需要设置参数就能调用；其数量不能太多，应当能包含在某类平台或语言中；它应当是普适的，除和平台或语言有关外，与具体的应用系统无关，也就是说适用于一切应用系统（只要需要）。这正是软部件与部件库的设计目标。只有设计成功这样的系统模块级的部件库，才能通过系统控制程序（菜单程序）直接调用，才能设计出相应建模软件，自动生成应用系统，建立软件生产线。为方便学习、方便应用，其建模软件应当充分吸收UML的精华内容，操作和UML相似。我们的文章全面介绍其设计思想、设计方法、具体实现与应用情况，完全与之相同的设计现在还未见报道，具有显著的创新性。

 

“专家”常常拿程序说事，例如在2015年我们的作品一开始就被拒所依据的是“文章超过8兆”。其实，当时的规则是不超过8兆直接上传，否则需向主席报告。我们按照规则三次向主席报告，但组委会将这后面规定忽略，玩弄手法以规则为理由将之枪毙，之后经我们投诉，才再寻“专家”维持原判。

 

这篇文章第三位“专家”说“本篇文章是一篇讨论型论文，并不是学术型创新研究型（算法、系统等）论文，也不是专业领域某一综述研究论文，文章类型不属于《计算机科学》的收稿范围”。

 

  是否“收稿范围”本应在送审前、之多在一审中判定，可直接退稿。目前由二审专家提出本就晚了。而且，拿出一个“讨论型论文”的概念也十分模糊。本来，任何论文都是针对某种不足进行研究，给出自己的思想与设计，进行实验验证，再讨论并给出结论，都是在作“讨论”。如果只是对一些观点进行评述，不涉及自己的研究过程与研究内容，没有实验依据与结论，或许可以算是“讨论型论文”。但是，我们这篇文章针对当前软件设计现状提出软件生产线概念，从必要性，到需求分析，到详细设计、实验实现，最后讨论研究的意义与价值，是典型的科技论文结构，何来“讨论型论文”之说。

 

对一些专家的学术水平与中文能力需要打问号。第三位“专家”说“第三和第四章节重点讨论的是数据库的类和其他组件模块的设计”。

 

我们文章第三和第四章实际是讲根据第二章进行的需求分析，提出满足这样的需求的详细软部件库的设计方案、建模软件设计方案、应用这样的软部件库与建模软件自动生成应用系统的软件生产线设计方案与实现情况。具体的软部件库部件数量很多，因而分成维护类部件、查询类部件、统计类部件、导入导出类部件、打印与输出类部件分别说明。这位“专家”只看到维护类中有“类”这样一个字，就说是重点讨论的是“数据库的类”，真是贻笑大方了。无论哪种语言、那个应用系统中任何可复用的数据维护程序（或任何其他可复用模块程序）都不可能是一个类程序，它必须使用各种各样的控件类，否则无法达到可复用的目的。也就是说必须是多个类集成的程序，不可能只是一个类，不存在“维护类”这样的“数据库的类”。可见，文章第三章、第四章讲的是数据维护部件、查询部件、……等的详细设计与应用，决不是“数据库的类和其他组件模块的设计”。这位专家露馅了。

 

有一个“专家”说：“论文的内容是仅仅对一个管理信息系统软部件库以及应用软部件库设计信息系统软件生产线的需求，设计及开发进行说明。并没有从“代码复用技术”的角度进行探讨。”

 

我们文章第一部分引文讲软件复用，从子程序、类讲到构件、部件，再重点讲软构件和软部件概念的区别、讲这一区别的意义：只有从许多人讲的与构件混用的“部件”概念中将“通用软部件”分离出来，并且重点研究，才能设计出软件生产线，同一部件可在不同地方、不同应用系统中应用，其内容就是软件复用。“专家”说文章未没有从“代码复用技术”的角度进行探讨。只能说该“专家”对“软件复用”概念不清晰，文章的题目是“软件代码复用技术研究的重要问题探讨”，主题应当是一个“重要问题”，而不是“代码复用技术”。文章探讨的是：要实现软件生产现代化、要建立软件生产线，需要什么样的软件代码复用技术。文章的观点是要研究软部件技术，并列举了我们设计的管理信息系统软部件库为例，说明怎样建模、怎样建软件生产线，进而说明，设计出通用于一切应用系统的软部件就可以建立软件生产线。完全是从“代码复用技术”的角度进行的探讨。

 

“专家”们又一个套路是拿参考文献说事。第二位“专家”说：“论文所引用的文献相对较老，且没有对最新及本领域有影响力的文献进行引用”。

 

   如果是成果鉴定或水平论证，参考文献是表现应用价值与研究水平的重要依据；如果是申报项目、经费，参考文献也能表现研究的意义。但是，如果关于论文中的是评价创新性，“参考文献”情况不应当是否决条款。如果一个问题未被前人研究过，没有相关的文献，但有研究价值，有创新，其文章就不能发表了？关于软件生产工业化、软件生产线方面的研究目前还处在很初始的阶段，还没有大家公认的突破。缺少有影响力的文献进行引用不应当是论文发表中最重要的评价依据。

 

  关于软部件库的设计及软件生产线课题是目前许多人关注的重要课题，我们所谓的根据所有应用系统和应用进行需求分析并非不可能，时机已经成熟了。目前已经有许多行业有了自己的领域构件库，只需要对其进行整合，统一接口标准，将功能相近的构件集成到一起，处理好一个部件集成多种应用、多种功能及通过参数选用的问题，就有可能建立完善的软部件库，进而设计出软件生产线。将对提高软件生产效率、大幅度提高软件质量、降低成本、降低学习门槛、普及应用、减少软件维保成本产生重大价值，以适应大数据新时代的到来。

 

  目前，很多论证都依靠专家。这本来是求取公平、防止腐败的重要手段，十分必要。但是希望，1、要依靠真正学术水平高、实践经验丰富、原则性强的专家。希望能有“回头看”的机制，要跟踪评价，有必要的问责手段。2、要强调文风，专家评语应当以事实为依据，反对断章取义，反对乱扣帽子，强调独立自主公正评判。至少在收到投诉后，应当给予答复，将投诉内容与答复情况记入个人业务档案，对于明显违规者应记入个人信用档案。3、依靠专家不能成为“不作为”的挡箭牌。