第8章基于构件的软件开发.doc

PAGE  PAGE 12 第8章 基于构件的软件开发 在软件工程的范围内，复用既是旧概念，也是新概念。软件开发人员从软件开发的早期阶段，就已经开始复用概念、对象、论据、抽象和过程，但其复用的层次是较为特定的。而今，更为复杂的基于计算机的系统必须在非常短的时间内建立，这就需要更有组织的复用方法。 基于构件的软件工程（component-based software engineering, CBSE）是强调使用可复用的软件“构件”来设计和构造基于计算机的系统。 8.1构件和基于构件的系统开发 从表面上看，CBSE似乎类似于传统的或面向对象软件工程。当软件小组使用传统的需求分析技术建立了待建造系统的需求时，该过程开始，体系结构设计（见§4.4）被建立，但是，项目开发小组并不是立即转向更细节的设计任务，而是必须检查需求以确定系统的什么子集可直接通过组装而不是构造完成。也??是说，项目小组针对每个系统需求询问如下问题： 1) 是否存在商用成品构件（commercial off-the-shelf，COTS）可实现该需求？ 2) 是否存在内部开发的可复用构件可实现该需求？ 3) 可用构件的接口和待建造系统的体系结构相容吗？ 在此，术语“构件”被重复地使用，而对该术语的确定性的描述未曾明确给出。常用的相关定义可为： 1) 构件——某系统中有价值的、几乎独立的并可替换的一部分，它在很好定义的体系结构语境内满足某清楚的功能。亦可定义为“系统中可以明确辨识的构成成分。 2) 运行时软件构件——作为单元管理的软件包，安装运行时可通过接口动态绑定其相关的一个或多个程序。 3) 软件构件——仅具有合约性描述的，显示的语境依赖的组装单元，亦即为一个独立发布的功能部分，它提供了通过接口对它的服务的方向。 4) 业务构件——某“自治的”业务概念或业务过程的软件实现。 5) 商品构件COTS，由第三个构造的满足一定构件标准的，可组装的软件构件。 在基于构件的软件系统开发指导下，开发小组试图修改或去除那些不能用COTS构件和自有构件实现的系统需求。如果需求不能被修改或删除，就必须传统的或面向对象的软件工程方法开发以满足需求的新构件。但是，对那些可被现存构件满足的需求，亦需采用不同的软件工程活动： 1) 构件合格性认证（component qualification）。系统需求和体系结构定义了所需的构件。可复用的构件（不管是COTS或自有）通常是通过它们的接口特征来标识的，即“被提供的服务，以及客户访问这些服务的方式”被作为构件接口的一部分而描述。但是，接口并不提供构件将符合体系结构和需求的全面描述。软件工程师必须通过一个发现和分析过程来认证每个构件的适合性。 2) 构件适应性修改(component adaptation)。在第4章，我们提到软件体系结构表示了由构件（功能性单元）、连接和协同构成的设计模式。在某些情形，现存的可复用构件可能和体系结构的设计规则不匹配，这些构件必须被自适应以满足体系结构的需要或被丢弃并被其他更合适的构件替代。亦可通过适应性修改以更改（也称掩盖(mask)或包装(wrap)不想要的或不希望的特征）。 3) 构件组装（component composition）。体系结构风格再次在软件构件被集成以形成工作系统的方式中扮演了关键角色。通过标识连接和协同机制（如设计的运行时性质），体系结构指导最终产品的组装。 4) 构件更新（component update）。当系统由COTS构件实现时，更新由于第三方的强行进入而变得复杂（即开发可复用构件的组织可能是在软件工程组织的直接控制范围之外）。 8.1.1 CBSE对质量、生产率和成本的影响 大量来自产业实例研究的证据表明从积极的软件复用可以导出实质性的商业收益，产品质量、开发生产率和整体成本都将得到改善。 1) 对质量的影响 理想情况下，为了复用而开发的软件构件已被验证是正确的且不含有错误。在现实中，形式化验证并不能例行公事地进行，错误可能而且也确实存在。然而，随着每一次复用，错误被发现和消除，构件的质量也随之改善。随时间推移，构件变成实质上无错误的。 在HP公司的研究中，Lim报告说：被复用的代码的缺陷率是每KLOC有0.9个缺陷，而新开发的代码的缺陷率是每KLOC有4.1个缺陷。对一个包含68%复用代码的应用来说，缺陷率是每KLOC有2.0个缺陷——相对应用的无复用开发，对期望的缺陷率有35%~51%的改善。虽然不同的报告跨越了质量改善百分率的一个合理的范围，但是，显然我们可以说，复用对交付的软件在质量和可靠性方面确实带来的实质性的收益。 2) 对生产率的影响 当可复用软件制品被应用于软件开发过程中，在创建对开发一个可交付系统所需要的计划、模型、