标题：部件是否就是业务构件?

发表评论人：[游客]zhh[2007-6-29 0:53:36]

有一本书：《构件中国-面向构件的方法与实践》中提出企业目前的需要已经从面向构件到面向业务构件；认为企业目前需要的已经不是细粒度的技术构件，而是粗粒度的业务构件。指出构件业务化是面向构件技术发展的必然。这些观点似乎和这篇文章相似，文中的部件是否就是业务构件?如果是有必要专门提出吗？

标题：关于"部件是否就是业务构件?"的回答

发表评论人：[游客]求新 [2007-6-30 10:41:15]

谢谢zhh，我们欢迎对文章进行讨论，将有利于澄清观点，为我们的进一步研究提供指导。
《构件中国-面向构件的方法与实践》一书中主要观点和我们是一致的，例如前言中说“大家都在尝试更大粒度的软件编写，更自动化的软件生成，以及更松散的软件组合”。书中第4页提出了软件的4个发展阶段：面向机器阶段、面向过程阶段、面向对象阶段、面向构件阶段。第10页提出“构件业务化趋势”，目前迫切需要的“不再是细粒度的技术构件，而是粗粒度的业务构件。以业务构件为中心的面向构件的开发才能真正提升开发的速度、降低开发成本，并改善软件质量”。
但是我们提出的通用软部件（以下简称部件）和书中“业务构件”存在不同。我们认为，我们要讨论的“构件”、“部件”都是特指的，都应当是软件复用件。也就是说其产品不应当只用于一个系统，而还需要用到其他系统中，否则就不是我们这儿要讨论、要研究的内容了。而作为复用产品，应当说清楚可以复用在那些系统中，以及在不同系统中怎样实施复用。
书中21页举例一个“客户查询”构件，关于接口的例子是“设定某人的地址，查询这个人在此地址已经住了多少年，以及查询某年这前这个人居住过的地址等”。
我不知道该例子的语义描述是什么。想知道的是，如果我在调用该构件之前都要按该问题回答，然后再使用该构件，那么该构件复用范围有多大呢？可以用到那些系统、那些应用中呢？
书中102页举例说明“业务构件”例如：销售线索管理、销售机会管理、销售计划管理……，但在112页的表3.8中说明它们都是“无复用资产”。可是在101页又以销售线索管理说它可供客户咨询、统计分析等系统调用，这我们就不知道这些调用的接口是什么，那些可以复用，在复时除了给一些变量赋值外还需不需要提供别的什么接口，以及要不要对程序也做一点修改，做那些修改，怎样修改？
后面说明了销售线索管理包括录入销售线索、修改销售线索、查询销售线索状态、取消销售线索、关闭销售线索、分配销售线索等内容。实际上这些工作除“分配销售线索”外对于我们而言都可以选择数据维护类部件构建，而“分配销售线索”可以由导出类部件选择合适的充当。我们认为部件是系统中可以复用的顶级模块，再往上是子系统或系统控制模块，也可以设计相应的部件，但一般可以不做封装，因为封装将使系统的适应性、扩展性受到影响。子系统或系统控制部件管理与控制一般部件，可以使系统具有较高灵活性，提高部件复用性能。提供“销售线索管理”的部件应当相当于子系统控制模块。
书中提出“业务构件”由“服务构件”构成，“服务构件”包括展现构件、逻辑构件、运算构件、扩展构件等四类，我们不知道这些构件的具体标准与划分依据，那些“业务构件”需要那些“服务构件”，它们的关系以及它们如何组合到“业务构件”中我们都不清楚。我们提出的部件也是由不同构件组合而成的，但类型要多得多，而组成部件的构件很少需要扩展类构件。
在145页给出了“服务构件”一例，其功能包括“响应用户界面‘客户接触记录查询’的请求，调用‘查询客户接触’的业务逻辑，定位‘客户接触记录查询结果’用户界面，并将业务逻辑返回的数据返回给用户界面的服务构件”。
那么该“服务构件”将来可以在那些地方复用，又怎样复用呢？
“部件”是基于事务的，但是是基于站在数据库的角度去处理的事务，从我们的文章中可以看到不外乎是各类数据维护、查询、导入或下载……，至于在具体系统中用于什么样的业务工作，那就由使用者自己决定了。
不知道通过上面讨论是否说清楚了书中的“业务构件”和“部件”的最大的不同点？
欢迎继续提出问题。

标题：可否在因特网上实现软部件信息系统

发表评论人：[游客]bruce  [2007-6-29 23:02:20]

当前对软部件技术的研究多数侧重于软部件的制作、存储、检索、裁剪和组装等问题,且往往过分强调了以上问题而忽略了另一个非常重要的方面,即部件的生产者与部件的使用者之间、生产者与生产者之间、使用者与使用者之间的充分的信息交流和有效协作问题,所以可否在因特网上实现软部件信息系统?

标题：关于“可否在因特网上实现软部件信息系统”的回答

发表评论人：[游客]求新[2007-6-30 10:52:12]

关于如何发布部件的问题确实是一个重要的问题，目前实际进行我们所定义或我们所认为的“通用软部件”的单位与个人还不多，实现的部件数量也很少，因此我们还没有关注这个问题，谢谢bruce的提醒。另外，在文章中我们已经说明了，我们的部件在因特网上只是部分功能移植成功，关于自适应性、自动进行数据完整性的保护等内容尚未实现，这与网络上开发语言的局限性有关，目前我们只能通过设计程序框架来解决，这是有待进一步研究之处。

标题：询问

发表评论人：[游客]xiongwei [2007-7-1 9:09:02]

在您的文章中说,部件采用从上而下的设计方法,您能否进一步说明一下?

部件采用从上而下的设计方法，同时又考虑实际应用系统的设计实例，二者相结合组织设计。实际业务工作是举不胜举，千变万化的，但是任何程序都是基于某一个语言编写出来的。语言中的语句是有限的，围绕应用的变化也是有限的。例如，涉及数据库的SQL语言的语句关键的只有9句，其变化也就很有限了；各种面向对象的语言，关键控件并不多，其使用中起重要作用的属性类型也各有限，虽然方法的设计千变万化，但是相对应用而言也有眉目可寻。因此可以针对一个抽象的、非特定的管理信息系统基于某种语言去组织设计，例如分析一般管理信息系统的程序界面是由那些控件组成的，有一些什么样的功能，实现这些功能的语句情况是怎样的，再考虑性能与界面各种需求，要特别考虑所选中的具体语言所可能提供的操作、所能提供的控件与构件，经排列组合，分析需求，再进行设计。
为更清楚地说明这个问题，我们还以《构件中国-面向构件的方法与实践》一书中关于构件的设计过程为例。书中以“神州电信”系统建设为例，首先确定服务构件的需求，例如“客户接触记录查询”构件，其功能特性包括“响应用户界面‘客户接触记录查询’的请求，调用‘查询客户接触’的业务逻辑，定位‘客户接触记录查询结果’用户界面，并将业务逻辑返回的数据返回给用户界面的服务构件”。非功能特性为“只能提供给有权限的登录用户使用”，部署要求为“作为业务构件CustTouchMgr的内容部署”。再进行架构平台设计或选择、用例分析、数据模型设计、用户交互设计、“客户接触记录查询”协作图、确定对外接口、美工设计，进入开发人员具体开发工作。再进行“可复用资产分析”，如果在构件库中没有该构件，就将它加入进去。
从上面可以看出，这类设计首先是按照普通管理信息系统模块的设计方法与设计步骤设计了一个系统模块，没有考虑复用的问题，最后也只当构件库中没有该构件时，将它加入构件库。至于以后还有没有别的系统需要该构件，就留待下一个类似系统设计人员来考虑了。事实上该书也没有谈及该构件将来在那些地方用了、可以在那些地方用、在其他地方是怎样用的等等问题。
还有一些专家在提到构件时是这样提出的，构件是以复用为目的设计的经封装的实现一定功能的程序模块。这一表述强调了复用性，但一般设计也都是基于一个具体应用系统开发，再考虑在同样领域中复用的需求，修改设计并定义接口使能满足同一领域其他应用的需要。例如，财务凭证录入构件的设计是：先设计好某一财务系统的凭证录入程序，定义为构件，再考虑当某些名称改变后用到其他财务系统的凭证录入的可能性。这就与部件设计不相同，关于凭证录入部件的设计首先考虑的是这是一个数据维护程序，其内容涉及一个表或一对多表的数据内容，即使一个表，其中字段也涉及层次性，例如一级科目与二级科目，会计与出纳等。从界面来看一般有表头、表格与表尾三部分，表格又有横向统计与纵向统计的内容。然后考虑采用类似界面的其他应用的类似需求，如果能让表头与表尾内容随接口变量数据的改变自动排版与定义、如果让表格的横向分为2、3或4个部分（根据接口参数值自动变化）、各部分的列的个数几表的行的个数也可以根据接口参数值自动改变，保持横向统计与纵向统计的功能，那么就成为一个通用与各类管理信息系统的通用软部件，将具有良好自适应性、可扩展性与复用性。
通过上面设计过程不难看出，部件与构件是完全不相同的两类复用软件，设计思想、设计方法、设计过程、乃至将来的使用方法都不相同，具有的作用与意义也不相同。
按照前述构件的设计方法，一般设计的最大粒度的将只是“领域构件”，因为考虑的始终离不开某具体系统，当考虑复用时又往往只在同样系统或同一领域系统或类似领域系统中研究。在接口与内部设计中始终脱不开领域，因此一般标签内容的变化、排版问题都未加考虑，程序随数据属性的自动变化也未加考虑，其复用性能也就十分有限了。
我认为这也是目前构件技术没有实现“软件工业化生产的目标”、其影响不如人们所期待的那样理想的一个重要原因。目前一般公司在开发系统时实际上都已经离不开构件了，将目前的时代定义为构件与框架的时代并不为过。但由于世上公司繁多，一般大一点实力强一点的公司都有自己的特色、自己的方向，通常涉及有限几个领域，各自开发自己的构件、使用自己的构件，全球难有统一的标准，一个公司不用也很难用其他公司的构件。一方面使构件难以发展，另外软件工业化生产也就谈不上了。我们相信通用软部件技术将改变这一情况，具有特殊重要的意义。

标题：对粗粒度业务的一些想法

发表评论人：[游客]xxj[2007-7-1 14:16:50]

求新的发言我仔细的读了后，觉得其中有一句说的很实在"“部件”是基于事务的，但是是基于站在数据库的角度去处理的事务，从我们的文章中可以看到不外乎是各类数据维护、查询、导入或下载……，至于在具体系统中用于什么样的业务工作，那就由使用者自己决定了",在工作中做过比较多的是系统，就是俗称项目的一些东西，比如说××智能卡系统，××管理系统，基本上是基于j2ee，感觉业务的需求是千变万化的，客户提出一点点改变，可能就和以前的有很大的改变，因为一个业务就牵扯到很多其他的业务。所以目前迫切需要的“不再是细粒度的技术构件，而是粗粒度的业务构件。以业务构件为中心的面向构件的开发才能真正提升开发的速度、降低开发成本，并改善软件质量”那么也要从最基本的业务需求拼装到复合的业务构件。然而个人认为，基本的业务需求，也就是对数据的维护，数据的通讯，数据的共享。并且在soa非常流行的今天，个人认为其基础还是数据的交互共享和一个个模块的通用。所以，任何所谓的粗粒度的业务构件，都必须是由极其基础的事务处理构成的。

标题：部件是大势所趋

发表评论人：[游客]chyi[2007-7-1 16:15:31]

我在看完《加强对软部件技术的研究，促软件工业化生产时代到来》和《构件中国-面向构件的方法与实践》之后,结合自己的软件开发经验,对构件和部件的有如下看法.欢迎大家指点.软件开发模式一般存在3种方式,编程模式,行业套件拼凑模式和构件搭建模式.编程模式的开发效率最低,它是从零开始编写代码,其中可以采用代码复用,框架复用,但是不能灵活应对业务需求的变化,一旦需求有所变动,又必须编写新的代码.行业套件拼凑模式在中大型软件公司采用得比较多,尤其是主要做应用系统集成的公司,这种方式是采用自下而上的方式搭建系统,先将现有的行业套件与软件需求对比,如果符合软件需求就直接套用这些套件,如果不能满足需求,也必须编写新的代码.采用构件搭建系统与采用行业套件的方式类似,只是构件的服用粒度更细,虽然在某种程度上提高了服用率,但是由于构件服用粒度细的自身特点,不便于较灵活地将这些构件组合在一起搭建应用系统,即使是采用BPM将构件动态地组合在一起.而部件则是自上而下,根据需求对部件进行局部裁减,通过裁减的方式就可以为需求量身定做应用系统,可以很灵活的适应需求的变化.如果在软件开发中采用这种部件裁减模式,那么就可以灵活应对需求的变化.所以部件是大势所趋.但是就目前国内或者是国外而言,还没有一套部件的行业标准,所以制定部件标准迫在眉睫.

标题：询问

发表评论人：[游客]ddl[2007-7-1 23:13:34]

我是一个学生，对这个题目很感兴趣，能否请程老师介绍一下部件特殊重要的意义？

标题：发展部件技术誓在必行，具有重大理论意义与实际意义

发表评论人：[游客]求新 [2007-7-2 8:33:11]

我们对于部件的前景的看法是乐观的，我们期盼部件技术能飞快发展。
杨芙清院士2005年3月9日讲话说：“中国软件产业路在何方？用工程化的方法来解决软件的开发，用工业化的方式来解决软件的生产，这就是软件产业。那么软件工业化，就需要有一个产业的基础，同时也就需要有一个产业的基础设施。我认为需要发展的软件产业的基础设施主要可分为四部分，分别是基础平台、构件库、标准规范和安全机制”。“构件库。其实也就是进行软件开发的资源库。构件，顾名思义，就是构成软件的零部件。有了构件库，制定统一的标准使得这些构件能够复用，是实现软件工业化的基础”。杨院士的话说明了较大粒度的复用软件具有十分重要的意义。
当面向对象初出现时，人们是指望它导致软件工程的革命的，事实上也确实使软件工程从理论到技术大大向前发展了一步，但是软件生产工业化的目标没有实现，因为其粒度太小。现在看来，基于构件的软件生产工业化进展不理想的原因也一样，构件粒度还不够大、数量太多、抽象程度不够。另外，前面我曾说过：构件是以具体应用系统设计为基础的，即使在后来考虑了向其他同领域系统移植与复用的可能，由于前期设计没有做足够充分的复用考虑，后期的修改很难脱去领域的痕迹，很难变成通用于某个大领域（例如管理信息系统领域）所有系统通用的软件，使其应用范围大大受限。也是由于这种至下而上的设计方法，使得各个公司各自开发自己业务有关领域的构件，构件成为各个公司的私有资源，各个公司无法使用或不愿使用其他公司的构件，各自为政的结果使得构件的规范化、标准化成为空谈，构件的私有性与领域性使得构件数量难以估计，这些终于使得构件产业化道路崎岖，进展缓慢。可以这样总结，构件技术虽然占了天时，也有地利，但缺少人和，终于没有见到预期的辉煌。
我们都看到了面向对象技术带来的辉煌，它简直改写了历史，导致了软件需求分析方法、建模理论与技术、软件设计理论与方法、高级语言及软件工程其他理论与技术的全面革命。其发展历程值得研究与借鉴。面向对象理论与技术不是至下而上设计出来的，它首先是基于在各类应用系统中都普遍见到的界面与程序，设法复用相应的代码，并与有关数据绑定，再在理论上升华，将客观世界中的对象的属性与方法的特征援引过来，终于发展成为一个成熟的理论与技术。再加上类的数量不多，大家很容易地就统一了规范与标准，导致了面向对象时代的到来。构件虽然也具有很大影响，目前大家的实际系统开发都离不开构件，可以将当前的时代称为构件与框架的时代。但是没有特别的轰动效应，其软件复用特性创新性不明显，没有要求软件需求分析方法、软件设计理论与方法、高级语言等产生革命性的变化。
通用软部件借鉴面向对象的成功经验，采用从上至下的设计方法，考虑全局的复用，要求通用于管理信息系统或其他较大的领域，期望其数量尽可能少，这就为其产业化创造了条件。它不专门属于任何一个单独的业务领域，不为任何一个领域公司所私有，这就为全球共享、为产生大家公认的标准与规范打下基础，必然会比构件技术导致更大的变革要求，它将要求补充新的软件需求分析方法、要求特殊的建模语言与方法、会产生新的软件设计方法、呼吁新的测试理论与方法，甚至要求新的网络语言、新的安全理论与方法，其意义难以估量！
目前SOA呼声很高，但实际上，带有通信接口、具有消息驱动的通用软部件就是最好的服务实体，在许多性能上甚至比目前一些服务软件更好，部件诞生时间还早于SOA，它其实就是中国本土的SOA。
至于部件技术的直接意义，例如提高开发效率、增加可扩展性、提高软件质量、延长软件寿命、降低软件成本尤其是降低软件维护费用，这些是大家公认的，就不必多说了。由于其粒度大、复用于高端、通用性强，上述性能都只会优于构件，而不会低于构件。由于部件在应用于具体应用系统时所实现的功能、性能与界面都是通过接口参数数据所控制的，当环境或需求改变时只要能根据以上改变自动改变接口参数的数据，就可能自动适应环境或需求的改变，可以不要求改变代码，甚至可以不要求重新编译，实现十分宝贵的“自适应性”，这是其他方法与技术都难以实现的。
终上所述，部件技术具有无比优越性，具有难以估量的美好前景，如果我国科技部门给予重视，国内各大软件公司通力合作，大力发展，必将促使民族软件业大放光彩。

标题：部件与业务构件能否共存?

发表评论人：[游客]zzr [2007-7-2 19:30:07]

看了前面的讨论,我对部件技术有了一定了解.就我个人的理解来说:部件,更多的是从一个领域所共同拥有的特征应用入手，提取出一种比较通用的模型系统，集成了一个领域通用的一些模块。它的基础其实也是构件。而，研究的初期更是集中于数据处理这一大多数软件系统的共同部分。从这点来说，部件的研究是从共性来着手的。而业务构件，其基础也是构件，不过它是针对领域中一部分独立的功能模块来开发的，其研究是从个性或特例来着手的。前者，着眼于全局；而后者着眼于局部。部件，应该是具有一定完整功能的微系统；而业务构件则不能称为系统。因此，就我的理解，部件与业务构件是在软件工业化中产生的两种不同思路。对两者进行对比来说，业务构件的功能较部件来说比较单一，自适应度和代码复用度较差，但其代码冗余度与部件相比在单一功能上来说较低，出错的风险也较低；但如果由业务构件集合来生成系统，与部件直接剪裁而生成的系统来比较，由于前者的接口更多需要再设计，因此在设计时，出错的风险和代码冗余度也将大幅增加。就发展来看，部件是一种质上更高等的软件复用模块，这就决定了部件的设计将是比基本技术构件和业务构件更困难的事，而业务构件因其技术较部件技术更简单，故，其在量上的积累更容易。而两者的共同发展，与在一定范围、一定程度上的竞争，将对两者的共同基础，即技术构件的发展起到极大的促进作用和产生不可估量的意义。 对未来的软件工业来说，部件将不仅能做减法，也应能做加法，即，既能做裁减来形成基本的系统模型，也能提供结合其他包括部件、业务构件、构件、类等软件复用单元,从而形成能满足行业需要，个性与共性相结合的实际系统。部件与业务构件既相辅相成，又有一定的竞争，而两者共同构成软件工业的基本要素，这大概是未来的发展方向吧。
以上是我的一点浅见，纸上谈兵，不对之处请大家指正！

标题：部件和领域构件需要共同发展

发表评论人：[游客]求新 [2007-7-2 23:48:14]

我同意zzr的意见,实际上部件和领域构件应当是并肩前进的,在目前阶段,领域构件还有很大发展空间.由于它是从具体系统总结再升华的,相对来说设计难度较低,应用针对性很强,许多情况下能更贴切地满足实际系统的需要,更体现系统的特色.因此对于各个业务领域软件公司来说,目前还会也需要继续研究与发展领域构件.但是,我们希望的是有更多、条件更好的大公司能重视部件的开发，希望产、学、研加强合作促使部件技术更快发展。另外，我们不喜欢业务构件这个词，杨芙清院士提过的领域构件这个词强调复用，比较符合我们的研究方向。

标题：减法与加法

发表评论人：[游客]求新 [2007-7-3 9:22:23]

我们所说的减法与加法是一个比方，指通用软部件的使用特性，如果所设计的部件在其设计的应用范围的现场可以不动封装，即不修改已封装起来的代码就直接为用户调用，用来完成某一业务工作，这才是所希望的通用软部件。在使用时如果原样使用、提供其全部功能，我们称为即插即用。在使用时如果通过对接口变量赋值使只使用其部分功能，我们称为经裁剪后再即插即用，这就是减法的意思。加法是对比一般构件的一种形象的说法，意指一般构件都不能独立地、即插即用式的用于构建系统，不能独立地完成一项业务工作，因为它们在设计时都没有考虑界面的设计，没有预先设计好的使用界面或没有界面自动生成功能，在用于现场时必须加上有关界面的代码后才能使用。领域构件应用时也构成系统的顶级模块，一般也包括界面设计，但在使用时其界面一般没有大的变化，当用于不同领域甚至同一领域的不同系统时，往往都要修改有关界面的代码、甚至要修改更多的代码后才能组装到系统中，这也就不符合我们对部件的期望了。
还以《构件中国-面向构件的方法与实践》一书中的例子为例，其中“销售线索管理”等“业务构件”是非复用件，我们不谈。书中较详细地描述了一个“客户接触记录查询控制逻辑”构件，被称为“服务构件”，其功能是“响应用户界面‘客户接触记录查询’的请求，调用‘查询客户接触记录’的业务逻辑，定位‘客户接触记录查询结果’，并将业务逻辑返回的数据返回给用户界面”。其“部署要求”是“作为业务构件CustTouchMgr的内容部署”。
这里“部署要求”已经说明了该构件不可能独立使用。即使没有写该“部署要求”，我们设想一下，该构件的名称已经决定在其程序代码中一定有涉及“客户”之类或相关的的标签或对话框，在设计中没有关于在使用时如何修改这类标签的方法，那么它的使用范围就很有限了，如果用到其他领域中，不修改程序代码恐怕是不行的。
在该书中也提到可复用的业务构件，其中个别确实是可以不动代码跨领域使用的，例如“用户管理”，如果它能考虑到如何适应不同系统安全性控制要求，在用户注册表结构改变时能自动调整界面使相适应，那就和我们的部件要求一致了，可以将它加入到部件库中了。
该问题另一方面是讲当实现部件产业化后，部件厂的设计思想是什么。减法与加法不是讨论在使用时是否可以将若干部件与构件组合后使用。例如砖块，生产时是先将泥土放到模具里压制成型，再经烧结而成。在工地使用时可以和其他砖块或其他材料通过水泥或其他粘合物粘结成柱子或其他非标准件，但通常是只使用于该工地或少数几个类似需求的工地（如果是普遍使用，就可以将其标准化并纳入部件厂去生产了）。而且决不会有那个工地将砖块重新捻成粉，再和其他材料混合后重新烧结。
同样意思，可以将若干部件组合在一起去做一件事情，有两种方法，一种是将它们逻辑上组合在一起，可以通过控制程序（例如菜单类程序）依次或按一定逻辑去调用。这一般不考虑组合件的复用问题，不是加与减的问题。另一种是物理地封装在一起，其中控制逻辑预先设计好，使用时又分两类，一类是控制逻辑不变，一般没有通用性。另一类是通过接口参数数据可以改变控制逻辑，具有通用性，它实际是一个新的部件产品。但我们建议，从管理的角度，将构成在其内的部件不叫部件，而叫构件，即在物理封装时可以将它们去掉封装后加入，这样可以减少程序复杂度，也更具有灵活性。

标题：顶一个

发表评论人：[游客]jj [2007-7-4 10:17:10]

不错不错，这个技术对于未来的软件开发产业具有巨大的推进作用，缩短了软件目前软件开发的时间。值得推广应用！

标题：

发表评论人：[游客]挂 [2007-7-4 14:55:47]

感觉分析的还是很详细的,期待更多更好的部件技术产品

标题：共同进步

发表评论人：[游客]ddl [2007-7-5 7:52:21]

这儿的讨论好极了，原来我对软件复用理解不深，也不了解部件，现在清楚多了。不过普元软件是全球领先的面向构件的中间件提供商，还希望普元软件及对构件研究比较深的专家多发表一点意见，目前我看普元软件参加的人不是很多。我曾在普元社区发了几次贴子，希望他们多派人参家讨论，但不知为什么，挂上去就被摘掉了。能不能请高手去邀请一下？

标题：顶

发表评论人：[游客]fjieo [2007-7-5 22:57:38]

顶起来，希望看到构件技术和现在最热的soa技术的相关研究

标题：是给"部件"一个准确的定义的时候了!

发表评论人：[游客]ddl [2007-7-6 20:21:27]

现在软件部件这个词很热，原来有很多使用构件这个词的现在都改为部件这个词。但将部件
这个词用滥了并非好事，到时候就不知道究竟什么是部件，我们需要达到的目标究竟是什么
，又会重韬构件复撤。我同意本文的定义：“软件部件是经封装的、面向业务工作而不是简
单单一功能的系统顶级模块；部件之间不存在直接联系、不要求彼此间的协作、包括了全局
性界面设计的内容、直接依据接口参数调用、不存在动态接口。它是采用从上而下设计方法
设计的通用于不同应用系统，能适应于不同数据库系统与不同数据表结构的规范化、标准化
的代码类复用软件。在应用于现场时可以如同硬件生产一样即插即用或经简单裁剪后插入使
用。
我看到有一篇文章说，ActiveX、DCOM都是使用部件的范例。不过按照上面这样的定义，
ActiveX、DCOM中的所谓部件是都还不够被称为部件的。