摘要：基于组件的软件工程的主要任务是从事把部件（组件）集成为系统的开发，这种开发中部件作为可重用实体，系统的维护和更新是通过定制和替换这些部件来实现的。这需要贯穿于组件和系统整个生命周期的确定的方法体系和工具的支持，包括技术、组织、市场、法律等其他方面。传统的软件工程学科需要新的方法学支持基于组件的开发。IVICA CRNKOVIC对出现的这种技术面临的挑战进行了评价，并讨论了它在软件开发过程中的应用。

　关键词：组件 软件工程 系统开发 UML

　　软件开发面临的挑战
　　我们目睹了软件在商业、工业、管理和研究领域日益膨胀的应用。软件已不再处于技术体系的边缘，已成为许多应用领域中的重要因素。软件的功能而不是其他特性的系统特征，在竞争中日渐成为市场上的决定性因素，如在汽车行业、服务行业和教育领域等。日益增长的软件用户并不都是专家，这些趋势对软件提出了新的要求。可用性、稳健性、易于安装和集成性正变为软件最为重要的特征。由于软件可用性涉及领域很广，不同领域中对集成的要求呈现增长趋势。我们把在不同管理层次的数据和过程集成方式称为垂直统一管理，把来于不同领域的相类似的数据类型和过程的集成称为横向结合。例如，在工业自动化处理中，采自管理的最低层面（田疃管理）中处理过程的数据被直接控制，然后在车间层面（加工管理）被综合，最后进行更进一步的处理。这种处理主要是分析和结合市场提供的数据进行整合，最后在 络上发布（商务管理）。

　　这一系列变动导致了软件变得越来越庞大和复杂。传统上，软件开发致力于处理日益增长的复杂性和作为一个系统对外部软件、交付期限和资金预算的依赖，往往忽略了系统进化或升级方面的要求。这已导致了一系列的问题：大多数项目不能在交付期限内完成，超出了预算，不能达到质量要求和持续增长的软件维护费用。为了应对这样的挑战，软件开发应该能够处理软件的复杂性，并能迅速的接受新的挑战。如果新的软件产品在开始开发时就是乱写（没有规划和分析），那么他们肯定达不到最后的目标。解决这类问题的关键是可重用性。从这个角度上看，基于组件的软件开发（CBD）应该是最好的解决途径。这包括对软件复杂性更有效率的管理，快速地推向市场，更高的生产力（开发效率），提高的质量，更为连贯的一致性和更为广泛的可用性。

　　但是在使用基于组件的开发中有几个危及其成功的不利因素：

　　·开发组件所需要的时间和精力。在所有阻碍可重用组件开发的因素中，比较重要的是对时间和精力增长的需求。构建一个可重用的组件需要三至五倍于开发满足特定需要组件的时间和精力。
　　·不确定和模糊的需求。通常，需求管理是开发过程中一个重要的方面。其主要目的是定义一个一致和完整的组件需求。可重用组件被定义，然后应用在项目中，其中一些应用和需求难以预见，包括功能性和非功能性的。
　　·可用性和可重用性的冲突。为了更为广泛的应用，一个组件必须足够的全面综合、可升级和易于维护，这导致了组件更为复杂（给使用也带来了一定的难度），对计算资源更多的消耗需求（使用所需要的花费也上升了）。对可重用性的需求可能导致转向其他的开发途径，如采用一个新的较为抽象的开发层次，这会减少弹性和可微调性，但更好的实现了简洁性。
　　·组件维护所需的花销。应用软件维护所需要的花费可能会很低，但组件维护所需要的花费会很高。这是因为组件必须和在不同环境下的不同应用的不同需求相一致，这包括不同的可依赖性的需求和可能需要不同级别维护支持的需求。
　　·可靠性和对挑战的灵敏性。由于组件和应用软件有独立的生命周期和不同种类的需求，所以存在组件不能完全满足应用软件需求或可能具有某些应用软件开发者也不确定的隐藏特征的风险。在介绍应用程序级别的挑战中（比如操作系统的更新，其他组件的更新，应用软件的挑战等等），以上介绍的挑战可能导致系统崩溃的风险。为了充分利用他的优点并努力避免风险和问题，我们需要一个系统化途径去实现在不同处理过程和技术层次中基于组件的软件开发。

　　基于组件的软件工程
　　通过组件开发软件的这个观念并不是新出现的。对一个复杂软件系统的传统设计总是从定义组成子系统的部件和模块等开始的，其中包括更低层次的模块，类，过程等等。软件开发中的重用机制已经被使用了很多年了。但是，最近出现的基于组件开发的新技术已进一步地增加了利用可重用组件来构建系统和应用软件的可能性。客户和供应商都对CBD（基于组件开发）开发模式有很高的期望，但他们的期望并不总是得到满足。经验证明，基于组件的软件开发需要一个系统性方法，需要致力于软件开发中的组件方面。传统的软件工程学科必须要适应这种新的方法，新的处理过程也必须得以开发。基于组件的软件工程已作为一个新的软件工程子学科受到认可。 

　　基于组件的软件工程的主要的目的是对软件开发所提供的支持，这种开发将系统作为组件集成体，将组件作为可重用实体来看待，通过定制和更换组件来实现维护和更新。系统由组件来构建和满足不同系统应用的组件开发需要成熟的方法学和处理过程，这种处理不仅与开发和维护等方面相关，而且与组件和系统的整个生命周期中包括组织、市场、法律和其他因素在内的方面相关。对应用软件来说，在基于组件的开发中除了一些具体的基于组件的软件工程目标如组件规格、综合约束和技术外，还有一些其他的软件工程学科和处理需要详细的方法和规范。其中许多方法学还没有在应用中成熟，一些甚至还没有开发出来。未来不久的软件开发过程将会更多地取决于CBSE（基于组件的软件工程）的成功确立，这已得到工业界和学术界双方的认可。现在很多涉及CBSE和CBSE实现等方面的议程软件工程会议召开的越来越频繁。引用Gartner Group的话说，就是“截至2002年，所有新应用软件的70%将会采用基于组件的开发模式来构建软件的模块。”

　　后文列出了一些CBSE学科的一般观点和未来的相应趋势和需要应当的挑战。

　　组件规范
　　为了对基于组件的开发有一个整体的理解，我们应该先弄清的一个要点究竟什么是组件而什么称不上是组件。作为一个术语，它的概念相当清晰——组件是一个系统的一个组成部件——但这个概念因为太含糊而对人理解起来没什么用处。尽管组件的定义已被广泛的讨论过，我们将采用广为人们使用的Szyperski’s的说法：软件的组件是一个综合体的一个单元，这个单元只有约定的指定接口和对外部环境的依赖。一个软件的组件可以被独立地配置，它受第三方组合的制约。

　　组件最重要的特征是具有独立于应用的接口。这种独立不同于我们常见的那些编程语言（如ADA或Modula-2）中定义和执行的独立，也不同于那些面向对象的编程语言中类的定义和类的执行相互独立。我们要确保组件被集成综合到一个应用软件与组件的开发生命周期相互独立，同时在应用软件更新一个组件时，相关组件不需要重新编译或者连接加载就可以使用。独立的另一个重要特色是组件的执行只有通过它的接口才可见，这对于由第三方发布的组件来说尤其重要。这意味着对组件具有详细完整的规范有相当的要求，这些规范包括功能性和非功能性的，用例，测试等等。尽管现在的基于组件开发技术成功了实现了对功能性接口的管理，但对组件其他方面规范的管理并没有达到另人满意的程度。
以上采用的组件定义关注组件的应用。它对组件如何定义，应用和如何规范组件涉及较少，但是我们可以参考那些关注组件其他方面的基于组件的开发。例如，OOP（面向对象编程）与组件有很强的联系。组件模型（或者称为组件规范）COM/DCOM，.NET，EJB（企业级Java Beans）和CCM（CORBA组件模型）的组件接口都与类的接口有联系。组件采用了面向对象原则的方法和数据封装的原理。Cheesman and Daniels认为一个组件在其生命周期中可以有以下几种存在方式：组件规范详述（组件的特点和方法），组件接口（规范的一个方面，是组件行为的定义），组件的执行（组件规范的实现），组件的生成（组件执行的配置实例）和组件对象（已生成对象的实例）。并不是所有的研究者都认为组件是OOP（面向对象编程）的扩展。相反，他们认为组件和对象之间的差别在于对象有声明，是实例的个体，而组件没有独立的声明，是配置个体。
在学术界和工业界，对CBD也有不同的理解。学术界的研究者把组件看为定义良好的实体（常常较小，有容易理解的功能性和非功能性的特点）；而工业界把组件视为一个系统的可重用部件，它不必定义为具有清晰的接口和与组件类型高度的一致性。一个组件可以是系统无组织的部件，但它的改动可能需要不少精力。鉴于组件越大，它们在被重用时可能表现出来的性能就越好，这样的组件（或叫可重用实体）很重要。

　　组件规范仍然作为一个话题在研究。组件标准主要集中在接口定义上，非功能属性在独立文档中被非正式定义（如果全部指定了的话）。通过收集功能性特色和设计特性，在本方面上的一些改进促使了微软的组件模型.NET的产生。

　　基于组件系统开发生命周期
　　CBSE强调需求、挑战和类似于其他软件工程方法中也常遇到的问题。很多方法、工具和软件工程准则可以采用同样或类似的方法在其他软件系统开发中得以应用，但应该注意的一个不同是CBSE包含了组件开发和系统采用组件开发。在需求和商业想法上这两种情况下有略微的不同，而这种不同的方法确是必需的。当然，在开发组件时，其他的组件可以（常常必须）合成一体，但主要的重点还是在重用性上：组件是为在很多应用软件中被采用和重用而开发，其中一些应用软件甚至还不知道是什么，或者根本不存在。一个组件必须有良好定义，易于理解，足够的综合，易于改进和展开，并要易于取代。组件的接口一定要尽量简单和相对于应用软件的严格独立（无论是物理上还是逻辑上）。鉴于开发成本必须在将来的赢利中考虑赚回，市场因素在其中也扮演了很重要的角色，这对COTS（用户定单跟踪系统）来说尤其如此。但是在开发组件时最主要的问题还是需求和COTS选择的获取，因为这个过程包含了基于多方标准做的决定。如果处理过程从需求的选择开始，就很可能发现一个满足所有要求的COTS是不可能存在。如果组件在处理过程中被过早地选择，所得的系统很可能不满足所有的要求。

　　组件的开发集中精力于重用实体和实体间关系的识别上，开始于系统需求的获取。早期的设计过程包含两个非常重要的步骤：首先，对系统体系在功能性组件和他们之间交互关系方面的详述，这为我们提供了对系统体系的宏观把握；第二，系统体系在物理组件方面的规范详述。
软件工程中建立的不同的生命周期模型可以在CBD中被采用。这些模型将被修正以强化以组件为中心的活动。让我们试想如果瀑布模型极端地采用了基于组件的方法将会怎样。图一显示了瀑布模型和相关阶段的描述。识别需求和瀑布过程在发掘和选择组件时结合起来。设计包含了系统体系设计和组件识别/选择。

　　基于组件软件工程的未来
　　很明显CBD和CBSE处于他们生存期的第一阶段。CBD被视为能革命性——至少能深深地——改变常用软件开发和软件应用的新的有力途径。我们相信，组件和基于组件的服务将会在非编程人员开发他们的应用中得到广泛应用。由组件整合来开发这样的系统的工具不久就会开发出来。当今在因特 上已存在的很多应用中组件的自动更新，将会成为系统改进的标准途径。我们可以发现的其他趋势是在接口层次上特定领域组件的标准化。这就使从不同供应商处购买组件来开发应用系统成为可能。特定领域的组件标准化需要特定过程的标准化。在不同领域中广泛的标准化工作已提上日程，（一个典型的例子是OPC Foundation[35]，它是系统/设备和商业/办公应用软件领域中促使自动控制应用中相互协调的标准接口开发）。在因特 上组件、应用软件和系统之间信息交换的一系列支持也很快会发展起来。XML相关的工作将会在不久展开。

　　·组件认证-归纳组件的一个途径是对它们进行认证。尽管一般观点认为认证意味着绝对的可信，事实上这只表明了测试的结果和对当时的测试环境进行的描述。在很多领域认证是一个标准的处理过程，在一般来说软件尤其是软件组件上它还没有建立。

　　·可预见组合-就算我们假定我们可以限定组件的所有相关属性，我们仍然不知道这些属性是如何决定他们所组合成的系统的相关属性。从组件属性中生成系统属性的理想途径目前仍然是研究的课题。还有一个问题-“是否所有的衍生都是可能的我们是否应该专注于组件属性的测量上br>
　　·需求管理和组件选择-需求管理是一个复杂的处理过程。需求管理的一个问题是需求往往是不全面的，不精确的甚至互相矛盾的。在内部开发中，主要的目标是开发一个尽可能地在一个受不同约束的特定框架内满足所有需求的系统。在基于组件的开发中，基本的途径是现存组件的重用。鉴于可能的侯选组件常常缺失一个或几个严格满足系统需求的特征，工程需求的处理要复杂的多。另外，即使一些组件个别性地和系统相符，在和系统其他的组件相互协同时，它们并不一定能表现出良好的性能-甚至可能一点都不良好。这些限制可能需要需求工程中其他的途径采用其他方法-与组件可用相关的系统可行性需求分析和由此引发的需求改进。由于在组件选择过程中有很多不确定性因素，对组件选择和演化过程的风险管理就显得必要了。

　　·开发模式-尽管现存的开发模式要求更有力的技术，他们仍有很多模糊的特性，这导致它们不完整，很难使用。

　　·组件配置-复杂系统可能包括很多组件，而这些组件反过来也包含很多组件。在很多情况下，组件的组合将会作为组件来看待。当我们开始着手处理复杂的结构时，结构配置方面的问题就出现了。例如，两个相同的组合可能含有同一个组件。这些组件是被作为两个不同的实体看待还是作为一个相同的实体呢这些组件有不同的版本，你会选择哪个版本呢这些版本不兼容你又该怎么办的动态更新问题我们已经知道了，但它们的解决方案仍然作为课题在研究。

　　·可靠的系统和CBSE-CBD在安全性要求较高的领域，实时系统和其他不同的过程控制系统等一系列可靠性需求很严格的情况下，CBD的使用面临着特别的挑战。CBD中一个主要的问题是确保质量和组件的其他非功能性属性问题，以及我们在确保特定系统属性时的乏力。

　　·工具支持-软件工程的目的是为现实问题提供可行的解决方案，并且适当工具的存在对于CBSE性能的成功发挥有重要的作用。开发工具如Visual Basic已被证明极其成功，但很多其他工具还没出现如组件选择和进化工具，组件仓库和仓库管理工具，组件测试工具，基于组件设计工具，运行时系统分析工具，组件配置工具等。CBSE的目标是由组件简单而高效地构建系统，而这只有通过扩展工具的支持来达到。

　　当今CBSE面临很多的挑战。CBSE的目标是对支持与CBD相关活动的所有规则的标准化和正式化。CBD的成功途径直接依赖于CBSE的进一步研究和应用。