基于组件的软件工程－软件开发中的新挑战[3]

　　组件的开发集中精力于重用实体和实体间关系的识别上，开始于系统需求的获取。早期的设计过程包含两个非常重要的步骤：首先，对系统体系在功能性组件和他们之间交互关系方面的详述，这为我们提供了对系统体系的宏观把握；第二，系统体系在物理组件方面的规范详述。

　　 软件工程中建立的不同的生命周期模型可以在CBD中被采用。这些模型将被修正以强化以组件为中心的活动。让我们试想如果瀑布模型极端地采用了基于组件的方法将会怎样。图一显示了瀑布模型和相关阶段的描述。识别需求和瀑布过程在发掘和选择组件时结合起来。设计包含了系统体系设计和组件识别/选择。

　　基于组件的系统开发过程不同处如下：

　　·发掘可以为本系统所采用的组件。所有可能的组件在这里被列出来，以备将来调查研究使用。为了更好地处理这个过程，必须要有大量能使用并可能被采用的侯选组件和用以寻找它们的工具。这不单是技术问题，还是商业问题。

　　·选择那些满足系统需求的组件。通常不是所有的要求都能得到满足，这时就需要综合权衡来协调软件系统体系以调整软件的需求，好尽可能地采用现有的组件。

　　·可选的，创建一些只为本系统使用的组件。在基于组件的开发过程中，这个过程需要较少的精力和时间，也乏吸引性。但由于含有产品核心功能的组件要提供具有竞争性优点的产品，它们趋于在内部开发。

　　·改编选中的组件以让它们适应现存的组件模型和需求规范。一些组件可能会被直接集成到系统中，一些可能在含参数处理过程中被改进，还有一些可能需要为改编附加一些代码。

　　·采用组件专用的框架排版并配置这些组件。往往由组件模型来提供这些服务。

　　·用新版本的组件代替旧版本的组件。这和系统维护相对应。漏洞将会降低，并会加进新的特色。

　　还有很多CBD其他方面需要特定的特殊的方法，技术和管理。例如，开发环境工具，组件模型及其应用支持，软件 配置管理，测试，软件美感，法定发行，项目管理，开发过程，事务规范和确认等等。在这些领域的详细讨论超出了本文的范畴，下文我们将会介绍软件体系和CBD之间的关系。

　　软件体系和基于组件的开发

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

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

原文转自：http://www.ltesting.net