基于构件的软件开发

（Component-Based Software Development, CBSD，有时也称为基于构件的软件工程CBSE）是一种基于分布对象技术、强调通过可复用构件设计与构造软件系统的软件复用途径。基于构件的软件系统中的构件可以是COTS（Commercial-Off-the-Shelf）构件，也可以是通过其它途径获得的构件（如自行开发）。CBSD体现了“购买而不是重新构造”的哲学，将软件开发的重点从程序编写转移到了基于已有构件的组装，以更快地构造系统，减轻用来支持和升级大型系统所需要的维护负担 ，从而降低软件开发的费用。

编辑摘要

基于构件的软件开发（Component-Based Software Development, CBSD，有时也称为基于构件的软件工程 CBSE）是一种基于分布对象技术、强调通过可复用构件设计与构造软件系统的软件复用途径。基于构件的软件系统中的构件可以是 COTS（Commercial-Off-the-Shelf）构件，也可以是通过其它途径获得的构件（如自行开发）。CBSD体现了“购买而不是重新构造”的哲学，将软件开发的重点从程序编写转移到了基于已有构件的组装，以更快地 构造系统，减轻用来支持和升级大型系统所需要的维护负担 ，从而降低软件开发的费用。
　　开发基于构件的软件系统受到以下几方面因素的影响：1）COTS构件质量的提高和种类的增加；2）要求降低系统开发和维护成本的经济压力；3）构件集成技术的出现；4）软件开发组织内可以用于新系统开发的已有软件制品的数量增加。
　　CBSD整个过程从需求开始，由开发团队使用传统的需求获取技术建立系统的需求规约。在完成体系结构设计后，并不立即开始详细设计，而是确定哪些部分可由构件组装而成。此时开发人员面临的设计决策包括“是否存在满足某种需求的COTS 构件”，“是否存在满足某种需求的内部开发的可复用构件”，“这些可用构件的接口与体系结构的设计是否匹配”等。对于那些无法通过已有构件满足的需求，就只能采用传统的或面向对象的 软件工程方法开发新构件。对于那些满足需求的可用构件，开发人员通常需要进行如下活动：
　　构件鉴定（qualification）：通过接口以及其它约束判断COTS 构件是否可在新系统中复用。构件鉴定分为发现和评估两个阶段。发现阶段需要确定COTS 构件的各种属性，如构件接口的功能性（构件能够提供什么服务）及其附加属性（如，是否遵循某种标准）、构件的质量属性（如，可靠性）等。构件发现难度较大，因为构件的属性往往难以获取、无法量化。评估阶段根据COTS 构件属性以及新系统的需求判断构件是否可在系统中复用。评估方法常常涉及分析构件文档、与构件已有用户交流经验、甚至开发系统原型。构件鉴定有时还需要考虑非技术因素，如构件提供商的市场占有率、构件开发商的过程成熟度等级等。
　　构件适配（adaptation）：独立开发的可复用构件满足不同的应用需求，并对运行上下文做出了某些假设。系统的 软件体系结构定义了系统中所有构件的设计规则、连接模式和交互模式。如果被复用的构件不符合目标系统的软件体系结构就可能导致该构件无法正常工作，甚至影响整个系统的运行，这种情形称为失配（mismatch）。调整构件使之满足体系结构要求的行为就是构件适配。构件适配可通过白盒、灰盒或黑盒的方式对构件进行修改或配置。白盒方式允许直接修改构件源代码；灰盒方式不允许直接修改构件源代码，但提供了可修改构件行为的扩展语言或编程接口；黑盒方式是指调整那些只有可执行代码且没有任何扩展机制的构件。如果构件无法适配，就不得不寻找其它适合的构件。
　　构件组装（composition）：构件必须通过某些良好定义的基础设施才能组装成目标系统。体系风格决定了构件之间连接或协调的机制，是构件组装成功与否的关键因素之一。典型的体系风格包括黑板、消息总线、对象请求代理等。
　　构件更新（update）：基于构件的系统演化往往表现为构件的替换或增加，其关键在于如何充分测试新构件以保证其正确工作且不对其它构件的运行产生副面影响，对于由COTS 构件组装而成的系统，其更新的工作往往由提供COTS 构件的第三方完成。