基本信息

Clements对CBSE有如下描述：

[CBSE]正在改变大型软件系统被开发的方式。[CBSE]体现了Fred Brooks等人支持的“购买，而非建造”的思想。就像早期的子例程将程序员从思考细节中解放出来一样，[CBSE]将考虑的重点从编程软件移到组装软件系统。“实现”已经让位给“集成”作为考虑的焦点。这样做的基础是假定在很多大型软件系统中存在足够多的共性，从而使得开发可复用软件组件来满足这些共性是值得的。

系统开发

从表面看，CBSE似乎类似于传统的或面向对象的软件工程。当软件小组使用传统的需求诱导技术建立了待建造系统的需求时，该过程开始，系统结构设计被建立，但是，并不是立即转向更细节的设计任务，小组检查需求以确定系统的什么子集可以直接通过组装而不是构造完成。也就是说，小组针对每个系统需求询问如下问题：

l 是否存在商用成品组件（component off-the-shelf，COTS）可实现该需求？

l 是否存在内部开发的可复用组件可实现该需求？

l 可用组件的接口与待建系统兼容吗？

小组试图修改或去除那些不能用COTS和自有组件实现的系统需求。如果需求不能被修改或删除，传统的或面向对象的软件工程方法被用于开发那些必须被开发以满足需求的新组件。但是，对那些可被现存组件满足的需求，采用不同的软件工程活动：

l 组件合格性认证。系统需求和体系结构定义了所需的组件。可复用的组件（不管是COTS的还是自有的）通常是通过它们的接口特征来标识的，即“被提供的服务，以及客户访问这些服务的方式”被作为组件接口的一部分而描述。但是，接口并不提供组件是否符合体系结构和需求的全面描述。软件工程师必须通过一个发现和分析过程来认证每个组件的合格性。

l 组件适应性修改。软件体系结构表示了由组件（功能性单元）、连接和协同构成的设计模式。在某些情形中，现存的可复用组件可能和体系结构的设计规则不匹配，这些组件必须被自适应以满足体系结构的需要或被丢弃而被其它更合适的组件代替。

l 组件组装。体系结构风格再次在软件组件被集成以形成工作系统的方式中扮演了关键角色。通过标识连接和协同机制（如设计时的运行时性质），体系结构指导最终产品的组装。

l 组件更新。当系统由COTS组件实现时，更新由于第三方的进入而变得复杂（即开发可复用组件的组织可能是在软件工程组织的直接控制范围之外）。

领域工程

领域工程的目的是标识、构造、分类和传播一组软件组件，它们对某特定应用领域中现存的和未来的软件系统具有很好适用性。其整体目标是建立相应的机制，来使得软件工程师在开发新的或现存的系统时可以共享这些软件复制品。领域工程包括三个主要的活动----分析、构造和传播。

CBSE过程

CBSE过程的刻画：不仅标识候选的组件，还认证每个组件接口合格性、适应性修改组件以消除体系结构不匹配、组装组件到选择的体系结构风格中以及当系统需求变化时更新组件。

基于组件的软件工程的工程模型强调并行的轨迹，其中领域工程和基于组件的开发并发地发生。领域工程完成一系列工作，以建立一组可以被其它软件工程师复用的软件结构，然后这些软件结构被越过分隔领域工程和基于组件的开发的“边界”传送

领域工程创建应用领域的模型，该模型被用作在软件工程流中分析用户需求的基础。类属的软件体系结构为应用的设计提供了输入。最后，在可复用组件已经被购买、从现存库中选出或构造好后（作为领域工程的一部分），它们可以被从事基于组件开发的软件工程师使用。