《标题部件是否就是业务构件》由会员分享，可在线阅读，更多相关《标题部件是否就是业务构件（7页珍藏版）》请在金锄头文库上搜索。
1、标题：部件是否就是业务构件?发表评论人：游客zhh2007-6-29 0:53:36有一本书：构件中国-面向构件的方法与实践中提出企业目前的需要已经从面向构件到面向业务构件；认为企业目前需要的已经不是细粒度的技术构件，而是粗粒度的业务构件。指出构件业务化是面向构件技术发展的必然。这些观点似乎和这篇文章相似，文中的部件是否就是业务构件?如果是有必要专门提出吗？标题：关于部件是否就是业务构件?的回答发表评论人：游客求新2007-6-30 10:41:15谢谢zhh，我们欢迎对文章进行讨论，将有利于澄清观点，为我们的进一步研究提供指导。构件中国-面向构件的方法与实践一书中主要观点和我们是一致的，例如
2、前言中说“大家都在尝试更大粒度的软件编写，更自动化的软件生成，以及更松散的软件组合”。书中第4页提出了软件的4个发展阶段：面向机器阶段、面向过程阶段、面向对象阶段、面向构件阶段。第10页提出“构件业务化趋势”，目前迫切需要的“不再是细粒度的技术构件，而是粗粒度的业务构件。以业务构件为中心的面向构件的开发才能真正提升开发的速度、降低开发成本，并改善软件质量”。但是我们提出的通用软部件（以下简称部件）和书中“业务构件”存在不同。我们认为，我们要讨论的“构件”、“部件”都是特指的，都应当是软件复用件。也就是说其产品不应当只用于一个系统，而还需要用到其他系统中，否则就不是我们这儿要讨论、要研究的内容了
3、。而作为复用产品，应当说清楚可以复用在那些系统中，以及在不同系统中怎样实施复用。书中21页举例一个“客户查询”构件，关于接口的例子是“设定某人的地址，查询这个人在此地址已经住了多少年，以及查询某年这前这个人居住过的地址等”。我不知道该例子的语义描述是什么。想知道的是，如果我在调用该构件之前都要按该问题回答，然后再使用该构件，那么该构件复用范围有多大呢？可以用到那些系统、那些应用中呢？书中102页举例说明“业务构件”例如：销售线索管理、销售机会管理、销售计划管理，但在112页的表3.8中说明它们都是“无复用资产”。可是在101页又以销售线索管理说它可供客户咨询、统计分析等系统调用，这我们就不知道
4、这些调用的接口是什么，那些可以复用，在复时除了给一些变量赋值外还需不需要提供别的什么接口，以及要不要对程序也做一点修改，做那些修改，怎样修改？后面说明了销售线索管理包括录入销售线索、修改销售线索、查询销售线索状态、取消销售线索、关闭销售线索、分配销售线索等内容。实际上这些工作除“分配销售线索”外对于我们而言都可以选择数据维护类部件构建，而“分配销售线索”可以由导出类部件选择合适的充当。我们认为部件是系统中可以复用的顶级模块，再往上是子系统或系统控制模块，也可以设计相应的部件，但一般可以不做封装，因为封装将使系统的适应性、扩展性受到影响。子系统或系统控制部件管理与控制一般部件，可以使系统具有较高
5、灵活性，提高部件复用性能。提供“销售线索管理”的部件应当相当于子系统控制模块。书中提出“业务构件”由“服务构件”构成，“服务构件”包括展现构件、逻辑构件、运算构件、扩展构件等四类，我们不知道这些构件的具体标准与划分依据，那些“业务构件”需要那些“服务构件”，它们的关系以及它们如何组合到“业务构件”中我们都不清楚。我们提出的部件也是由不同构件组合而成的，但类型要多得多，而组成部件的构件很少需要扩展类构件。在145页给出了“服务构件”一例，其功能包括“响应用户界面客户接触记录查询的请求，调用查询客户接触的业务逻辑，定位客户接触记录查询结果用户界面，并将业务逻辑返回的数据返回给用户界面的服务构件”。
6、那么该“服务构件”将来可以在那些地方复用，又怎样复用呢？“部件”是基于事务的，但是是基于站在数据库的角度去处理的事务，从我们的文章中可以看到不外乎是各类数据维护、查询、导入或下载，至于在具体系统中用于什么样的业务工作，那就由使用者自己决定了。不知道通过上面讨论是否说清楚了书中的“业务构件”和“部件”的最大的不同点？欢迎继续提出问题。标题：可否在因特网上实现软部件信息系统发表评论人：游客bruce 2007-6-29 23:02:20当前对软部件技术的研究多数侧重于软部件的制作、存储、检索、裁剪和组装等问题,且往往过分强调了以上问题而忽略了另一个非常重要的方面,即部件的生产者与部件的使用者之间、
7、生产者与生产者之间、使用者与使用者之间的充分的信息交流和有效协作问题,所以可否在因特网上实现软部件信息系统?标题：关于“可否在因特网上实现软部件信息系统”的回答发表评论人：游客求新2007-6-30 10:52:12关于如何发布部件的问题确实是一个重要的问题，目前实际进行我们所定义或我们所认为的“通用软部件”的单位与个人还不多，实现的部件数量也很少，因此我们还没有关注这个问题，谢谢bruce的提醒。另外，在文章中我们已经说明了，我们的部件在因特网上只是部分功能移植成功，关于自适应性、自动进行数据完整性的保护等内容尚未实现，这与网络上开发语言的局限性有关，目前我们只能通过设计程序框架来解决，这是
8、有待进一步研究之处。标题：询问发表评论人：游客xiongwei2007-7-1 9:09:02在您的文章中说,部件采用从上而下的设计方法,您能否进一步说明一下?标题：部件与构件设计思想与设计方法之不同。发表评论人：游客求新2007-7-1 10:59:09部件采用从上而下的设计方法，同时又考虑实际应用系统的设计实例，二者相结合组织设计。实际业务工作是举不胜举，千变万化的，但是任何程序都是基于某一个语言编写出来的。语言中的语句是有限的，围绕应用的变化也是有限的。例如，涉及数据库的SQL语言的语句关键的只有9句，其变化也就很有限了；各种面向对象的语言，关键控件并不多，其使用中起重要作用的属性类型也
9、各有限，虽然方法的设计千变万化，但是相对应用而言也有眉目可寻。因此可以针对一个抽象的、非特定的管理信息系统基于某种语言去组织设计，例如分析一般管理信息系统的程序界面是由那些控件组成的，有一些什么样的功能，实现这些功能的语句情况是怎样的，再考虑性能与界面各种需求，要特别考虑所选中的具体语言所可能提供的操作、所能提供的控件与构件，经排列组合，分析需求，再进行设计。为更清楚地说明这个问题，我们还以构件中国-面向构件的方法与实践一书中关于构件的设计过程为例。书中以“神州电信”系统建设为例，首先确定服务构件的需求，例如“客户接触记录查询”构件，其功能特性包括“响应用户界面客户接触记录查询的请求，调用查询
10、客户接触的业务逻辑，定位客户接触记录查询结果用户界面，并将业务逻辑返回的数据返回给用户界面的服务构件”。非功能特性为“只能提供给有权限的登录用户使用”，部署要求为“作为业务构件CustTouchMgr的内容部署”。再进行架构平台设计或选择、用例分析、数据模型设计、用户交互设计、“客户接触记录查询”协作图、确定对外接口、美工设计，进入开发人员具体开发工作。再进行“可复用资产分析”，如果在构件库中没有该构件，就将它加入进去。从上面可以看出，这类设计首先是按照普通管理信息系统模块的设计方法与设计步骤设计了一个系统模块，没有考虑复用的问题，最后也只当构件库中没有该构件时，将它加入构件库。至于以后还有没
11、有别的系统需要该构件，就留待下一个类似系统设计人员来考虑了。事实上该书也没有谈及该构件将来在那些地方用了、可以在那些地方用、在其他地方是怎样用的等等问题。还有一些专家在提到构件时是这样提出的，构件是以复用为目的设计的经封装的实现一定功能的程序模块。这一表述强调了复用性，但一般设计也都是基于一个具体应用系统开发，再考虑在同样领域中复用的需求，修改设计并定义接口使能满足同一领域其他应用的需要。例如，财务凭证录入构件的设计是：先设计好某一财务系统的凭证录入程序，定义为构件，再考虑当某些名称改变后用到其他财务系统的凭证录入的可能性。这就与部件设计不相同，关于凭证录入部件的设计首先考虑的是这是一个数据维
12、护程序，其内容涉及一个表或一对多表的数据内容，即使一个表，其中字段也涉及层次性，例如一级科目与二级科目，会计与出纳等。从界面来看一般有表头、表格与表尾三部分，表格又有横向统计与纵向统计的内容。然后考虑采用类似界面的其他应用的类似需求，如果能让表头与表尾内容随接口变量数据的改变自动排版与定义、如果让表格的横向分为2、3或4个部分（根据接口参数值自动变化）、各部分的列的个数几表的行的个数也可以根据接口参数值自动改变，保持横向统计与纵向统计的功能，那么就成为一个通用与各类管理信息系统的通用软部件，将具有良好自适应性、可扩展性与复用性。通过上面设计过程不难看出，部件与构件是完全不相同的两类复用软件，设
13、计思想、设计方法、设计过程、乃至将来的使用方法都不相同，具有的作用与意义也不相同。按照前述构件的设计方法，一般设计的最大粒度的将只是“领域构件”，因为考虑的始终离不开某具体系统，当考虑复用时又往往只在同样系统或同一领域系统或类似领域系统中研究。在接口与内部设计中始终脱不开领域，因此一般标签内容的变化、排版问题都未加考虑，程序随数据属性的自动变化也未加考虑，其复用性能也就十分有限了。我认为这也是目前构件技术没有实现“软件工业化生产的目标”、其影响不如人们所期待的那样理想的一个重要原因。目前一般公司在开发系统时实际上都已经离不开构件了，将目前的时代定义为构件与框架的时代并不为过。但由于世上公司繁多
14、，一般大一点实力强一点的公司都有自己的特色、自己的方向，通常涉及有限几个领域，各自开发自己的构件、使用自己的构件，全球难有统一的标准，一个公司不用也很难用其他公司的构件。一方面使构件难以发展，另外软件工业化生产也就谈不上了。我们相信通用软部件技术将改变这一情况，具有特殊重要的意义。标题：对粗粒度业务的一些想法发表评论人：游客xxj2007-7-1 14:16:50求新的发言我仔细的读了后，觉得其中有一句说的很实在“部件”是基于事务的，但是是基于站在数据库的角度去处理的事务，从我们的文章中可以看到不外乎是各类数据维护、查询、导入或下载，至于在具体系统中用于什么样的业务工作，那就由使用者自己决定了
15、,在工作中做过比较多的是系统，就是俗称项目的一些东西，比如说智能卡系统，管理系统，基本上是基于j2ee，感觉业务的需求是千变万化的，客户提出一点点改变，可能就和以前的有很大的改变，因为一个业务就牵扯到很多其他的业务。所以目前迫切需要的“不再是细粒度的技术构件，而是粗粒度的业务构件。以业务构件为中心的面向构件的开发才能真正提升开发的速度、降低开发成本，并改善软件质量”那么也要从最基本的业务需求拼装到复合的业务构件。然而个人认为，基本的业务需求，也就是对数据的维护，数据的通讯，数据的共享。并且在soa非常流行的今天，个人认为其基础还是数据的交互共享和一个个模块的通用。所以，任何所谓的粗粒度的业务构
16、件，都必须是由极其基础的事务处理构成的。 标题：部件是大势所趋发表评论人：游客chyi2007-7-1 16:15:31我在看完加强对软部件技术的研究，促软件工业化生产时代到来和构件中国-面向构件的方法与实践之后,结合自己的软件开发经验,对构件和部件的有如下看法.欢迎大家指点.软件开发模式一般存在3种方式,编程模式,行业套件拼凑模式和构件搭建模式.编程模式的开发效率最低,它是从零开始编写代码,其中可以采用代码复用,框架复用,但是不能灵活应对业务需求的变化,一旦需求有所变动,又必须编写新的代码.行业套件拼凑模式在中大型软件公司采用得比较多,尤其是主要做应用系统集成的公司,这种方式是采用自下而上的方式搭建系统,先将现有的行业套件与软件需求对比,如果符合软件需求就直接套用这些套件,
