摘要：基于组件的软件工程的主要任务是从事把部件（组件）集成为系统的开发，这种开发中部件作为可重用实体，系统的维护和更新是通过定制和替换这些部件来实现的。这需要贯穿于组件和系统整个生命周期的确定的方法体系和工具的支持，包括技术、组织、市场、法律等其他方面。传统的软件工程学科需要新的方法学支持基于组件的开发。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其他方面需要特定的特殊的方法，技术和管理。例如，开发环境工具，组件模型及其应用支持，软件配置管理，测试，软件美感，法定发行，项目管理，开发过程，事务规范和确认等等。在这些领域的详细讨论超出了本文的范畴，下文我们将会介绍软件体系和CBD之间的关系。

　　软件体系和基于组件的开发
　　软件体系和组件有密切的联系。所有软件系统都有一个可视为将系统分解成组件及其关系的体系。一个常见的软件体系的定义是：“一个项目或计算系统的软件体系结构是系统体系的系统结构，这一系统结构含有软件的组件及这些组件尽可能可见的属性和其间关系。”一般来说，软件体系结构在前期设计阶段处于中心位置，前期整个系统结构被设计来满足功能性和非功能性需求。在单个大型应用中，在设计过程中的体系规范在执行期间作为可执行代码隐藏起来。组件技术致力于在接近或正值执行期间合成和配置。在一个基于组件的系统中，体系结构在应用和执行期间仍然可辨。基于组件的软件工程包含组件和基于组件系统的整个生命周期，而各处理过程正好包含在这些生命周期中。

　　传统上，软件的设计开始时先决定它的体系，从小的部件来构建系统，并尽可能的独立来完成这些工作。构建的第一个阶段是功能性体系的设计。第二个阶段是软件体系的评估，在此阶段软件的体系结合相应质量需求被估值。一旦软件体系被定义了，组成系统的组件必须被开发或者选择。我们可以结合系统的需求来区分不同的组件种类：特定用途的组件，本系统已开发的特定组件，精简的组件，内部开发的多用组件和终态商业组件（COTS）。预存的组件往往要在集成到系统前用特定的衔接代码连接，要么组件本身要做一些修正。这种自上向下的开发方法保证了需求的满足和实现，至少能对需求的实现起到更好的控制作用。但是，这种途径并不鼓励重用预存的组件，特别是商业组件，因为很可能发生现存的组件不能很好适应系统的情况。另一种方法是自下向上和自顶向下方法的结合，这种方法开始于系统需求和对可能的侯选组件分析。组件规范和选择对最后的需求和系统机构有一定的影响。这种情况下，软件体系主要关心识别优化给定组件之间关系的方式。既然对系统体系和组件技术来说基本的成品是组件，那么他们的组合很自然地就会合并，这要通过一些常用技术，方法和工具。体系描述语言ADLS如ACME，可以用来设计基于组件的系统，并应用于现存的组件模型中。

　　软件体系常和协定和分析过程相关。经验证明，很多大型软件系统的属性主要存在系统软件体系中。在这些系统中，质量品质的程度更多的取决于整个软件体系，而非编程方面如编程语言的选择，详细设计，算法，数据结构，测试等等。这样的分析有以下几种方法，例如SAAM（软件体系分析方法）和ATAM（体系折中分析方法）。ATAM和SAAM都基于特定的方法。但是，ATAM专注于多种质量属性（修正，可用，安全和性能），它的目的是查找定位并分析协定软件体系，这不同于SAAM。组件有预先定义的属性，其中一些只为组件所有；但有一些在组件合成时才显现出来。平衡分析可以帮助选择合适的组件并预见组件合成时其他属性。同时，含有现存组件为分析可能生效的范围限定了范围。例如，一个侯选组件的特点可以是高度的可重用性，但可能会有低下的性能。而其他的一些侯选组件可能会有较高的性能，但可重用性不高。体系分析可以在我们选择组件时帮助我们作决定。

　　软件体系和CBD在软件生产线开发中得到成功应用，并发布了很多种类的产品。代表产品含有一套核心组件和一系列附加组件。基于组件的方法和系统设计在产品配置管理中发挥了重要的作用。

　　UML和基于组件的系统模型
　　正如[21]所示，UML（统一建模语言）可以被用于组件和系统建模。组件驱动设计致力于接口定义和组件通过接口的协作。设计过程接下来是采用物理组件的系统建模，其中物理模型不一定要和逻辑结构相一致。或许会有现存的组件，这些组件有详细说明的接口，但或许需要包装。在第一设计阶段识别的逻辑组件可能含有几个物理组件。最终，形成了一个配置方面的问题，在这里组件在分布式应用中会在不同的电脑中运行。在非基于组件的开发方法中，第一阶段即设计阶段是非常重要的，在概念和执行层次之间的映射是直接映射；对整个应用软件来说，配置阶段也是一样的。理论上，UML可以被用来为设计基于组件的系统提供以上各个方面的支持。接口表现为多用子系统（或称多用接口可以被子系统实现），这说明了在不改变接口的情况下改变执行是可能的。一个接口可以通过以下两种形式表示（如图2），其中第二个途径是比较常见的。

　　
　 　图3展示了系统结构的三个方面。概念体系是对系统自上而下分析和设计的结果，至少第一步和非基于组件设计没什么不同。在概念部分，组件被UML包用<<subsystems>> 套用表达。在执行体系部分，物理组件用UML组件和<<imp>> 套用表达。注意，执行部分并不是对概念层次唯一改进的地方，结构也可能被改变。例如，不同的包可以含有同样的物理组件，也可能出现组件选择需要改进概念体系的情况。
尽管如此，UML并不是专门为CBD设计的，而标准UML（如名字协定，原型）也需要进行一些扩展。组件接口不能像直接使用时一样在用UML描述时达到如此详细的程度。正因为如此，UML存在扩展，如Catalysis[33]。对UML应用到CBSE，更进一步的工作要做。下一主要的UML版本（UML2.0）包含了对一些扩展的建议，如EJB，数据模型实体，实时组件，XML组件等等。很多这些都直接和CBSE相关。

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

　　
　 　当今CBSE面临很多挑战，其中很多可以总结为如下：
　　·可信组件-因为趋势是组件以二进制形式发布，而组件的开发过程不受组件用户的控制，与组件可信性的相关问题变得很重要。但是，可信性的意思是严格定义的。尽管与可信性相关的很多属性都有正式的定义（如可依赖性和健壮性），对可信性这个词却没有正式的定义和理解，没有标准的测量和可信的说法。对系统属性不同程度的可信性究竟各有什么影响目前还不清楚。

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

　　·可预见组合-就算我们假定我们可以限定组件的所有相关属性，我们仍然不知道这些属性是如何决定他们所组合成的系统的相关属性。从组件属性中生成系统属性的理想途径目前仍然是研究的课题。还有一个问题-“是否所有的衍生都是可能的？或者我们是否应该专注于组件属性的测量上？”

　　·需求管理和组件选择-需求管理是一个复杂的处理过程。需求管理的一个问题是需求往往是不全面的，不精确的甚至互相矛盾的。在内部开发中，主要的目标是开发一个尽可能地在一个受不同约束的特定框架内满足所有需求的系统。在基于组件的开发中，基本的途径是现存组件的重用。鉴于可能的侯选组件常常缺失一个或几个严格满足系统需求的特征，工程需求的处理要复杂的多。另外，即使一些组件个别性地和系统相符，在和系统其他的组件相互协同时，它们并不一定能表现出良好的性能-甚至可能一点都不良好。这些限制可能需要需求工程中其他的途径采用其他方法-与组件可用相关的系统可行性需求分析和由此引发的需求改进。由于在组件选择过程中有很多不确定性因素，对组件选择和演化过程的风险管理就显得必要了。

　　·基于组件系统长期的管理-由于基于组件系统包含子系统和拥有独立生命周期的组件，系统进化的问题变得特别复杂。有很多不同的问题因此产生了：技术问题（一个系统可以被技术更新还是被其他组件替代？），管理和组织问题（哪些组件可能更新，应该或者必须更新的问题），法定问题（谁对系统崩溃负责，系统和组件的制作者的问题）等等。CBSE是一个崭新的方法，但我们对这样系统的可维护性并没有多少经验。这就存在着维护困难的风险。

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

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

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

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

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