第14章基于构件的软件开发.pptVIP

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */57 创建领域构件的设计框架 除应遵循已有的设计概念和原则外，还必须考虑应用领域的特征，例如： 标准数据：应该研究应用领域，并标识出标准的全局数据结构(如文件结构或完整的数据库)。于是所有设计的构件都可以用这些标准数据结构来刻画 标准接口协议：应该建立三个层次的接口协议：构件内(intramodular)接口、构件外接口以及人机接口 程序模板：程序的结构模型可以作为新程序的体系结构设计的模板 */57 可变性分析 构件应具有较强的通用性和可变性 为了满足不同的复用需求，需要在构件复用时可能发生变化的一个或多个位置上标识变化点(variation point)，同时为变化点附加一个或多个变体(variant) 例如Account构件的帐号编码规则以及透支规则在不同的国家可能不一样 · VP1 · VP2 C VP1 description context */57 构件系统中的门面和变体 */57 可变性机制 继承：在变化点上创建指定抽象类型或抽象类的子类型或子类。 扩展和扩展点：可以在用况和对象构件中的变化点(或扩展点)上附加变体(或扩展) 参数化：用于模板、框架和宏的类型和类 适用于变体较小时(经常是一个数值、短语或表达式) */57 内容摘要 基于构件的软件开发概述 建造可复用构件 应用系统工程 构件的管理 小结 */57 应用系统工程 任务：通过组装可复用构件得到应用系统 CBSD中构件是组成应用系统的基本单元 注重体系结构和构件接口的分析和设计，忽略构件内部实现的设计 */57 关注接口的设计 接口是构件行为的描述机制，并提供了对其服务的访问 供应接口(Provided interface)：描述构件所提供的服务，可以被其它构件访问 请求接口(requived interface)：请求接口描述构件为完成其功能(服务)需请求其它构件为其提供的服务 一个接口可以有多种实现，并且对使用者隐蔽 接口描述是构件使用者能依赖的所有信息，因此构件接口描述的表达能力和完整性是CBSD方法主要关注的问题之一 */57 基于构件的体系结构 基于构件的应用系统体系结构 描述了组成应用系统的构件，构件之间的组织结构、交互、约束和关系 对系统的组成、结构以及系统如何工作的较为宏观的描述 如果在领域工程中已开发了领域基准体系结构(reference architecture)，则可以通过对基准体系结构的剪裁和/或扩充获得应用系统的体系结构 */57 基于构件的体系结构层次 逻辑体系结构 以接口形式对每组服务进行描述，并描述那些包怎样交互来满足通常的用户使用场景 展示了系统设计的蓝图，可用于验证系统是否提供了适当的功能，并能在系统功能需求变化时方便地改变系统的设计 物理体系结构 描述系统的物理设计，包括硬件及其拓扑结构、网络和通信协议、基础设施(如运行平台、中间件、数据库管理系统等)，以及软件系统的部署 展示了系统的实现构架，有助于理解系统的许多非功能属性，如性能、吞吐量、服务的可用性等 */57 基于构件的应用系统开发方法 Rationel统一过程 Rational’s Unified Process，简称RUP 一个关于软件开发的广泛的过程框架，覆盖了整个软件生命周期 使用UML进行分析和设计建模，鼓励使用CBSD方法 The Select Perspective Method 支持通用的构件设计方法，并以Select Component Manager为目标 通用构件设计准则使用UML作为构件设计符号 Sterling Software的Enterprise-CBD方法 鼓励使用UML的扩展形式把构件的规格说明和实现分离 允许制作技术中立的规格说明，然后再使用不同的实现技术来实现规格说明 共同点：关注构件库中的构件、接口的设计和基于构件构架的应用程序组装 */57 构件鉴定(qualification) 目的：确保获得的构件可以完成所需的功能并能被集成在系统中与系统的其它构件正确交互 主要依据是构件的接口描述和相关的规格说明，但这些信息往往还不足以确保构件能成功地集成到系统中 对于外部提供的成品构件(COTS)可通过运行构件测试版进行鉴定 */57 构件鉴定需考虑的因素 应用编程接口(API) 该构件所需的开发和集成工具 运行时需求，包括使用的资源(如内存或存储器)、时间或速度以及网络协议 服务需求，包括操作系统接口和来自其他构件的支持 安全特征，包括访问控制和身份验证协议 嵌入式设计假定，包括特定的数值或非数值算法的使用 异常处