章基于组件的软件工程.pptVIP

第19章 基于组件的软件工程 内容 CBSE(要素，存在问题) 组件和组件模型 CBSE过程 组件合成 CBSE 基于组件的软件工程 (Component-based software engineering)，简称CBSE。 定义、实现和集成或组合松散耦合的独立组件成系统的过程。 它的产生是由于设计者们在使用面向对象的开发过程中所受到的挫折，这种挫折来自于面向对象开发不能支持有效的复用。单个对象类太细节且太特殊。 组件比对象类更抽象，可以被认为是独立服务的提供者。 CBSE 要素 独立组件 组件标准 中间件 开发过程 由接口完全定义。把组件接口和组件实现分离开。 使组件集成变得更容易。若构造的组件符合标准的话，它们将是独立于编程语言的。 为组件集成提供软件支持。需要有中间件来支持这些独立的组件之间的交互问题。 适应于软件复用的开发过程。 CBSE 设计原则 除了可以复用的好处外，CBSE还遵循一套完整的软件工程设计原则： 组件是独立的，因此它们不会影响彼此的操作； 组件细节的实现是隐藏的； 组件通过良好定义的接口进行交互； 组件平台是共享的，减少了开发成本。 CBSE 的问题 组件的可信度 —组件是以二进制形式移交，用户没有源代码，如何能知道组件是否可靠呢？未说明的失败模式、隐藏的恶意代码，会破坏系统的安全。 组件的证明—谁来证明这些组件的质量呢？ 总体特性预测 —组件是不透明的，预测它的总体特性就很困难。当多个组件集成在一起的时候，所得的系统又会产生新的属性，怎样预测新出现的属性呢？ 需求权衡—在理想需求和现实可用的组件之间，我们该怎样进行权衡分析呢？要有一个更结构化的、更系统的权衡分析方法帮助设计者选择组件。 组件的定义 Councill 和 Heinmann的定义: 组件是一种软件元素，与某个组件模型要求相一致，按照组成标准无需修改即可独立进行部署和组合。 Szyperski的定义: 组件具有合同定义的接口和显式的上下文依赖，是可独立进行部署的并服从于第三方的组成的软件单元。 组件特性 组件特性 组件作为服务的提供者 组件提供了一种服务，调用组件的系统不需要考虑组件正在哪儿执行和它的编程语言。 强调了组件的两个关键特性： 组件是独立可执行的实体。在与系统其他组件一起使用之前，无需编译组件。 组件所提供的服务可以通过其接口得到，而且所有的交互都是通过接口实现。 组件接口 提供接口 表示组件能提供给其他组件的服务，定义了组件用户可以调用的方法。用一个圆圈表示。 需要接口 指定系统其他组件必须提供哪些服务。如果这些服务不能实现，组件将无法工作。这并不影响组件的独立性和可部署性。用一个半圆表示。 组件接口 组件模型 组件模型定义了组件实现、文档书写及部署的标准。这些标准是为确保组件的互操作性而设立的。 组件模型的例子： EJB 模型 (Enterprise Java Beans) COM+ 模型 (.NET 模型) Corba 组件模型 组件模型的基本要素 如何定义组件接口 在接口定义中应该包括的要素 指定用于定义接口的语言IDL 给组件一个特定的名字或者句柄。 通过元数据发现组件提供的和所要的服务 根据所使用的特定的应用环境进行定制 如何打包为一个独立可执行实体 何时和怎样替换组件 定义应该产生的组件文档 面向复用的组件开发 对于一些现有的组件，这些组件已经实现了并且已经在系统中使用了，它们包含某个应用专用的特征和接口，这些组件不是立即就能被复用的。 要改写和拓展某些组件以创建更通用的，更适合复用的版本。显然，这是一个成本问题： 组件是否可能被复用？ 可复用节约的成本是否能值得上使组件可复用的成本？ 面向复用的组件开发 组件是否可能被复用？ 组件是否实现了一个或多个稳定的领域抽象（业务对象）？ 稳定的领域抽象是指应用领域中变化缓慢的基本概念。银行系统（账户、账户持有者、账目）医院管理系统（病人、护士） 如果组件是对普遍使用的业务对象或是一组相关对象的实现，它就可能被复用。 可复用组件的开发 组件可复用了节约的成本是否能值得上使组件可复用的成本？ 为回答有关成本效益问题，必须评估使组件可复用而需要进行的变更成本。这些成本包括组件文档的成本、组件验证的成本及使组件更通用的成本。 那么可以提高组件的复用性的变更又有哪些呢？ 可提高组件的复用性的变更 去除特定应用专有的方法； 更名使其更通用； 添加方法提供更完备的功能覆盖； 为所有方法构造一致的异常处理； 添加配置接口允许对组件改编以适用不同的使用情况； 集成所需要的组件以增强独立性。 原则上，组件不应该处理自身的异常， 组件应该定义哪些是会产生的异常并 将之发布作为接口的一部分。 例如，实现堆栈数据结构的简单组件 应该检测和发布栈上溢和下溢的异常。 组件的可复用性与可用性