软件生产线集成框架 参考规范.doc

I 软软件件生生产产线线集集成成 框框架架 参参考考规规范范 V0 1 2 变变更更记录记录 变更版 本 日期图表 表格 段落 号 A M D 原因与修改情况描述修订 人 审核 人 注 A 增加 M 修改 D 删节 3 目录目录 1 介绍 5 1 1 背景和需求 5 1 2 规范组织结构 7 2 概述 8 2 1 定义 8 2 1 1 软件产品线 8 2 1 2 软件产品线实践 8 2 1 3 软件生产线 9 2 1 4 软件工具 9 2 1 5 软件生产线集成框架 9 2 2 角色 9 2 3 目的 10 3 软件生产线集成框架的需求分析 11 4 面向数据的工具集成 12 4 1 概述 12 4 2 目的 12 4 3 参考方案 13 4 3 1 基于元建模框架 EMF 的互操作性解决方案 13 4 3 1 1 集成机制 13 4 3 1 2 集成方法 14 4 3 1 3 集成示例 14 4 3 2 基于版本控制模型的文件非冗余性解决方案 15 4 3 2 1 集成机制 15 4 3 2 2 集成方法 16 4 3 2 3 集成示例 16 4 3 3 基于资源共享的 Eclipse 数据一致性解决方案 16 4 3 3 1 集成机制 17 4 3 3 2 集成方法 17 4 3 4 基于模型同步机制的数据一致性解决方案 17 4 3 4 1 集成机制 18 4 3 4 2 集成方法 19 4 3 4 3 集成示例 21 5 面向控制的工具集成 24 5 1 概述 24 5 2 目的 24 5 3 参考方案 25 5 3 1 基于插件体系结构的 Eclipse 平台解决方案 25 5 3 1 1 集成机制 27 5 3 1 2 集成方法 27 5 3 2 基于 SOA 的 Web Services 解决方案 30 5 3 2 1 集成机制 31 4 5 3 2 2 集成方法 31 5 3 3 基于跨平台调用的解决方案 32 5 3 3 1 集成机制 32 5 3 3 2 集成方法 33 6 面向过程的工具集成 36 6 1 概述 36 6 2 目的 36 6 3 参考方案 37 6 3 1 基于 SOA 的面向过程工具集成方案 38 6 3 1 1 集成机制 38 6 3 1 2 集成方法 39 附件 41 A 案例介绍 基于构件的软件生产线 41 B 案例介绍 面向服务的软件生产线 41 C 案例介绍 支持监控的软件生产线 41 D 案例介绍 流程制导 支持异构集成的软件生产线 41 参考文献 42 5 1 介绍介绍 1 1 背景和需求背景和需求 1 软件开发环境的发展 软件工具是一类用来辅助计算机软件开发 运行 维护 管理 支持等过程中的活动 或任务的软件 使用软件工具能节省软件生产开销 提高软件生产率和产品质量 随着软 件结构的日益复杂 为细化软件开发的分工 开发过程被划分为多个阶段 例如需求分析 设计建模 代码编写 部署监控等阶段 软件工具也被进一步分类 出现了针对各个阶段 不同粒度的开发工具 例如 UML 建模工具 调试工具等 众多纷繁的开发工具给用户在 选择和集成上都带来了许多问题 软件生产环境应运而生 软件生产环境是一个复杂的系 统 包括了用来辅助计算机软件开发 运行 维护 管理 支持等过程中的活动或任务的 众多软件 纵观软件生产环境的发展 可以把它们总结为五个发展阶段 1945 1960 时期 直接运行在裸机上的专用开发工具 1960 1980 时期 基于命令行的开发环境 Command Line Environments CLE 1980 2000 时期 集成开发环境 Integrated Development Environments IDE 2000 2004 时期 扩展开发环境 eXtended Development Environments XDE 2005 年开始兴起的协同开发环境 Collaborative Development Environments CDE 最早的软件开发环境就是一种集代码编写 调试运行等工具于一体的集成开发环境 集成开发环境提供的特性主要聚焦于以语法为导向的编辑器扩展 用于增强用户的开发过 程体验 典型的代表为 Smalltalk 第一个 PC 图形化 IDE 工具 Visual Basic 支持增量编译 的 Rational 开发环境 微软的 Visual Studio IBM 的 WebSphere Studio 以及 Sun 的 Studio One 也属于此类 集成环境无法满足不断出现的新开发工具的集成需求 于是 软件开发环境发展到一 个可扩展的环境的阶段 这种扩展的开发环境基于一定的集成和扩展体系结构 由一系列 互相依赖的工具组成 XDE 不仅支持时间上的松耦合开发 也支持空间上的分布开发 并 且开始考虑对非软件依赖因素的管理 扩展开发环境提供的特性包括重构支持 需求变更 管理 配置管理 建模等 典型的代表为 Eclipse 4 Rational XDE 5 其中 Eclipse 是 6 当前开源社区中应用最为广泛的 XDE 平台 它确定了一整套工具接口和模型规范 作为 集成框架 可以支持众多的工具集成为一个整体 软件开发不仅仅是单纯的编码 它是团队开发者相互合作来设计解决方案 构建高质 量代码的协同过程 因此以协同开发思想为基础的协同开发环境成为发展趋势 协同开发 环境以协同开发思想为基础 通过整合协同工具 实现无缝的 完整的软件开发 协同开 发环境的使用者扩展到了目标软件的行业领域专家 网络与硬件工程师等 使得软件产品 相关的所有利益相关方均能配置其感兴趣的属性 在互动的软件开发协作过程中及时沟通 并做出对策 协同开发环境提供的特性包括虚拟团队 即时通讯 网络会议 讨论等协同 机制 典型的代表为 Collabnet 的 SourceForge 6 SourceCast 7 等 目前这些协同开发环 境提供的功能主要在代码协同方面 包括配置管理 冲突检测等 2 软件生产线 软件生产线工具集成参考规范是 可信的国家软件资源共享与协同生产环境 课题的 重要组成部分 此课题是国家 863 计划 高可信软件生产工具及集成环境 重点项目的主 体和核心 旨在突破关键性的高可信软件生产技术 可信软件资源共享支撑技术 软件可 信度分级机制以及软件开发协同技术等基础技术 研制覆盖软件开发主要活动和任务的软 件工具 建立国家级软件资源库和面向不同技术特征的若干软件生产线 提供开发协同平 台 建立 可信的国家软件资源共享与协同生产环境 以及配套的 可持续发展的运行机 制 形成指导本项目其他课题发布软件资源 集成软件工具 开展协同开发的技术规范 从而为构建高可信软件生产工具及集成环境提供核心基础设施 1 其中 软件生产线的体 系结构如图所示 7 图 1 1 软件生产线体系结构图 该课题以可信软件生产活动为中心 研究可信软件生产的基本特点 针对工具的集成 化 可扩展 协同化开发需求 研究灵活可扩展的软件工具集成框架 生产线数据集成方 法和机制 实现生产线与各类工具 软件资源库和开发协同平台之间的集成方法和交互机 制 支持生产线的灵活集成 进而形成软件工具与生产线集成的系列国家行业标准 规范 软件工具 制品的集成和共享能力 1 本规范是 高可信的软件生产平台和集成环境 项目的重要组成部分 3 软件生产线工具的集成 在软件生产线集成方面 课题研究基于 XMI XML Metadata Interchange 的数据集成方 法和规范 支持工具间数据互操作 建立灵活可扩展的软件工具集成框架 研究生产线间 生产线与软件资源库间 生产线与开发协同平台间的集成方法和交互机制 1 最终实现生 产线中的工具和软件资源库通过遵循软件生产线集成框架的技术规范 集成组装成若干面 向技术特征的软件生产线 1 2 规范组织结构规范组织结构 本规范按以下方式组织 第二章首先对规范中使用的概念和定义进行总结 然后阐述规范目的以及集成框架参 考模型涉及的角色 第三章介绍软件生产线集成框架需求分析及其参考模型 8 第四 五 六章分别从数据 控制 流程等三个方面对集成框架参考模型进行详细的 阐述 包括该方面集成的目的和相关参考方案 在参考方案中 功能机制和使用场景进行 阐述 最后 在附件中介绍相关案例 9 2 概述概述 本章对规范涉及的一些概念定义进行总结 阐述规范的目的 介绍软件生产线集成框 架参考模型所涉及的各种角色 2 1 定义定义 2 1 1 软件产品线软件产品线 软件产品线是一个产品集合 这些产品共享一个公共的可管理的特征集 这个特征集 能满足选定的市场或任务领域的特定需求 软件生产线是多个软件密集系统组成的集合 这些系统共享一个公共的 可管理的特征集 这个特征集能满足选定的市场或任务领域的 特定需求 这些系统遵循一个预描述的方式 在公共的核心资源 Core Aassets 基础上开发 的 卡内基梅隆大学 CMU 关于软件产品线的定义 8 Some practitioners use a different set of terms to convey essentially the same meaning For some a product line is a profit and loss center concerned with turning out a set of products it refers to a business unit not a set of products The product family is that set of products we call the product line The software assets in the core asset base are sometimes called a platform What we call core asset development is sometimes referred to as domain engineering and what we call product development is sometimes referred to as application engineering 2 1 2 软件产品线实践软件产品线实践 由 CMU 给出的概念可知 软件产品线是一个软件产品家族 这是一种名词性的内涵 强调的是软件产品家族 CMU 关于软件产品线实践 software product line practice 的定义 如下 8 Software product line practice is the systematic use of core assets to assemble instantiate or generate the multiple products that constitute a software product line The appropriate verb depends on the production method for the product line Software product line practice involves strategic large grained reuse 10 2 1 3 软件生产线软件生产线 软件生产线是按照一定的软件生产方法 将若干软件生产工具和构件有序组织起来的 软件开发环境 生产线能够较为完整地提供成套的软件开发支撑 软件生产线其内涵是软件生产 一种动词性的内涵 目的是生产软件产品 软件产品 线实践和软件生产线的内涵特征基本一致 且如下 面向软件产品家族生产 以整个软件产品家族的需求分析 设计和开发为中心 开发方法学 工具支持 管理学 包括领域工程 即核心资产开发 应用工程 即软件产品的开发 和管理学 系统级复用 可将软件产品线实践统称为软件生产线 即利用软件生产线进行软件产品线 即软件 产品家族 的生产 2 1 4 软件工具软件工具 软件工具是一类用来辅助计算机软件开发 运行 维护 管理 支持等过程中的活动 或任务的软件 软件工具利用软件生产线集成规范中相关机制进行集成 形成软件生产线 2 1 5 软件生产线集成框架软件生产线集成框架 软件生产线本质上是软件开发环境 软件开发环境中的集成 指该环境中的所有构件 包括工具 制品 平台支撑集成的基础设施 平台服务 能作为一部分工作起来 形成统 一 一致 和谐的一个整体 软件生产线集成框架即是该类平台支撑集成的基础设施 主要关注工具的集成 工具集成关心工具间的集成关系以及这些关系所具备的属性特征 2 2 角色角色 本节介绍软件生产线集成框架相关角色 目的在于两方面 一方面便于本规范读者更 好的理解软件生产线工具集成 另一方面 在实施软件生产线工具集成过程中 明确参与 11 者的职能 软件生产线集成框架涉及以下三种角色 其中 软件生产线使用人员软件生产线使用人员是软件生产线及工具的使用者 使用者可以对软件生产线环境下 的工具集成提出需求 软件生产线开发人员软件生产线开发人员负责构建软件生产线的集成环境 为工具开发人员提供工具集成 方案和框架 软件生产线工具开发人员软件生产线工具开发人员是软件生产线工具的设计和开发人员 根据生产线开发人员 提供的方案和框架进行工具开发 2 3 目的目的 本规范的目的包括 给出软件生产线集成框架的参考模型 给出软件生产线工具间的集成关系 并以此划分工具集成类型 定义和描述各类型集成的属性特征 针对集成属性特征为软件生产线开发人员和工具开发人员提供参考集成方案 12 3 软件生产线集成框架的需求分析软件生产线集成框架的需求分析 软件生产线集成框架核心是形成软件生产线的工具间的集成机制及其实现 文献 2 总 结了 5 种工具集成类型 分别是平台 platform 表示 presentation 数据 data 控制 control 和流程 process 文献 3 在此基础上对表示 数据 控制和流程等 4 种集成 类型进行分析和总结 分别归纳出上述集成类型的属性特征 本规范基于上述工作给出软件生产线集成框架的需求分析模型 如图 3 1 所示 该模 型刻画了软件生产线工具间的集成关系以及这些关系所具备的属性特征 面向数据 Data 的工具集成 保证软件生产线工具间数据的互操作性 非冗余性和一致性 面向控制 Control 的工具集成 从提供和使用两方面阐述软件生产线工具的功能组合机制 面向过程 Process 的工具集成 将软件生产线工具间的调用关系和软件制品间的转换关系及约束显示描述 互互操操作作性性互互操操作作性性 非非冗冗余余性性非非冗冗余余性性 数数据据一一致致性性数数据据一一致致性性 提提供供提提供供 使使用用使使用用 过过程程步步骤骤过过程程步步骤骤 事事件件事事件件 约约束束约约束束 数数据据集集成成数数据据集集成成控控制制集集成成控控制制集集成成过过程程集集成成过过程程集集成成 工工具具工工具具 图 3 1 软件生产线集成框架需求分析模型 实体 关系图 13 4 面向数据的工具集成面向数据的工具集成 4 1 概述概述 面向数据的工具集成 描述了被集成的工具间存在共享 关联数据时所应具有属性 对于软件生产线的使用者 在进行数据操作或转换时 通过工具间的数据集成维护信息数 据的一致性 对于工具开发者而言 实现工具间的数据集成 需满足数据在管理 表示等 方面的集成属性 4 2 目的目的 数据集成的目的是保证软件生产线中数据的一致性 为了达到这个目的 需要从数据 管理和数据表示两个方面定义面向数据的集成属性 互操作性互操作性 工具间数据的互操作性是为了保障数据表示的一致性 对于软件生产线的使用者而言 该性质体现为工具间数据具有公共视图 对于软件生产线开发人员 该性质则体现为各工 具数据模型具有相同的 schema 若各工具数据模型的 schema 不同 则软件生产线开发人 员需要通过大量的工作实现数据模型的互操作 场景举例 在基于模型驱动的开发环境下 一个模型设计工具产生的数据被另一设计 工具理解 参考方案 参考 4 3 1 非冗余性非冗余性 非冗余性强调工具间数据的冗余程度 对于软件生产线开发人员 该性质体现为各工 具数据间的冗余度 若各工具数据间不存在共享数据副本或一方数据可自动推导出另一方 数据的情况 则工具间的数据冗余度低 否则 将导致共享数据维护问题 场景举例 版本控制 参考方案 参考 4 3 2 数据一致性数据一致性 在工具对数据进行处理时 数据一致性是为了维护各工具数据间的约束 对于软件生 产线的使用者而言 该性质体现为工具间共享数据的同步 对于软件生产线开发人员 该 14 性质要求各工具对数据的操作行为不会对工具间数据的约束产生影响 场景举例 在基于模型驱动的开发环境下 两个相关联的模型设计工具产生的数据不 冲突 参考方案 参考 4 3 3 4 3 4 4 3 参考方案参考方案 为了具体的实现面向数据的工具集成 经过调研推荐以下的几种实际的技术实现方案 4 3 1 基于元建模框架基于元建模框架 EMF 的互操作性解决方案的互操作性解决方案 统一建模语言 UML unified modeling language 和 MDA model driven architecture 的流行 使 得模型成为软件开发的核心制品 提升了软件开发的抽象层次 但是长期以来 由 Rational Rose 等可视化对象建模工具得到的模型只能用于软件设计过程 其次 人们通常需要根据 应用系统 领域 的需求建立自己的建模语言及其建模环境 这种建模语言称为领域建模语 言 domain specific language 简称 DSL 随着元建模技术的发展 这一局面得到改善 元建模 即建立用以刻画某种建模语言的元模型 并提供支持该建模语言的建模工具 从软件生产线工具集成的角度分析 可以通过元建模技术建立领域模型 实现数据模型一 致性保障 9 基于 Eclipse 的模型框架 Eclipse Modelling Framework 简称 EMF 10 是支持元 建模的一种框架实现 它是 Eclipse MDA 的一个重要组成部分 是 Eclipse 中许多项目的基 础 e g GEF EMF 可以将模型转换成高效的 正确的 和易于定制的 Java 代码 EMF 项 目的最初目标是要实现 OMG Object Management Group 的 MOF 规范 Meta Object Facility 在项目的进行中 EMF 的开发人员根据大量的实践经验对 MOF 规范进行了再加 工 提取出了一些核心的元素集 MOF 2 0 中称为 EMOF Essential MOF EMF 是 MOF 核心子集的 java 实现 在 EMF 中 MOF 核心子集的实现称为 Ecore 4 3 1 1 集成机制集成机制 EMF 建模工具生成器可以根据元模型生成相应的建模工具 生成建模工具的好处是可 以给用户提供一个独立的工具 有利于对建模工具的定制 修改和提高 例如 如果生成的 15 建模工具不具备某些功能 比如代码生成能力 那么用户可以对生成的建模工具进行修改 以添加所需的能力 为了保证模型在各种工具之间的可交换性 EMF 一方面使用 XMI XML Metadata Interchange 作为模型定义的语言规范 另一方面只用到了 UML 的一个子集来定义必要的 类 属性和关联 这些都使得 EMF 中的模型定义变得相对简单起来 即使没有复杂的可 视化建模工具也同样能够完成 4 3 1 2 集成方法集成方法 EMF 建模框架通过构建具有共同特征的数据模型 例如模型的属性用 EStructureFeature 表示 模型都扩展 AdapterImpl 以支持监听机制等 提供相似的数据模型 操作接口 增加模型的互操作性 EMF 由核心框架 Ecore 和 EMF Edit 两个基本部分组成 其中核心框架负责为模型的 生成和运行提供最基本的支持 而 EMF Edit 则在核心框架之上提供了查看和修改模型的 相应方法 以及一个现成的模型编辑器 按以下步骤可以构建一个完整的数据模型操作工 具 EMF 是 Eclipse 提供的一种建模框架 它采用 XMI 作为标准语言来描述模型 但 在实际应用时可以使用如下三种方法来产生模型 用 XML 或者文本编辑器直接 创建用 XMI 描述的模型 从 Rational Rose 等可视化建模工具中导人模型以及在 Java 接口定义中加入建模注释标记来生成模型 对数据模型描述完成之后 框架读入描述文件 进行代码生成 如果代码创建过 程一切正常 模型中对应的接口类要么会被自动生成 如果模型最初是从 Rational Rose 中引入的 要么会被自动补全 如果模型最初是用 Java 接口描述的 同时还 将创建两个名为 impl 和 util 的包 分别包含接口的具体实现和一些辅助类 除了能够为模型自动生成实现代码之外 EMF 还能够为每个模型提供一个功能强 大的编辑器 它是以 Eclipse 中两个插件的形式出现的 edit 插件负责为模型提供 结构化浏览和命令编辑的适配对象 adapter 而 editor 插件则负责提供编辑器和向 导器的用户界面 16 4 3 1 3 集成示例集成示例 WTP 工具包提供一系列辅助 Web J2EE 开发的工具 WTP 工具包体现了 基于 EMF 模型框架的解决方案的特点 它包含的工程管理工具 各种文件编辑 工具等均操作一组基于 EMF 构建的核心模型 图 4 1 WTP 体系结构 如图 4 1 所示 WTP 由 WST JST 两部分组成 它们的 Common 部分包含 了利用 EMF 框架 从 web 以及 j2ee 的 schema 中生成的相应的 Web 以及 J2EE 组件模型 基于这两组模型 WTP 实现了相关的各种视图 操作工具等 4 3 2 基于版本控制模型的文件非冗余性解决方案基于版本控制模型的文件非冗余性解决方案 版本控制系统的核心任务是实现协作编辑和数据共享 不同的系统使用不同的策略实 现这个目的 目前流行的版本控制工具有 Visual Source Safe VSS 11 Concurrent Versions System CVS 12 Subversion SVN 13 等 其中 VSS 使用锁定 修改 解锁模型实现版本控 制 CVS 和 SVN 则利用拷贝 修改 合并模型实现版本控制 4 3 2 1 集成机制集成机制 锁定锁定 修改修改 解锁模型解锁模型 在这样的模型里 在一个时间段里版本库的一个文件只允许被一个人修改 但该模型 会导致一些问题 锁定可能导致管理问题 17 锁定可能导致不必要的线性化开发 锁定可能导致错误的安全状态 拷贝拷贝 修改修改 合并模型合并模型 在这种模型里 copy 的含义是每一个用户读取项目版本库建立一个私有工作拷贝 版本库中文件和目录的本地映射 modify 是说用户获得私有 copy 后 可以并行工作 独 立修改各自的工作拷贝 merge 表明 将用户修改后认为 满意 的各自私有工作拷贝合 并在一起 成为版本库中最新版本 这种系统通常可以通过工具辅助合并操作 但是如果 合并过程中发生冲突 多个用户修改了同一文件的同一行内容 则需要手工解决冲突 4 3 2 2 集成方法集成方法 在基于版本控制模型的文件非冗余性解决方案中 采用集中管理的方法 将生产线中 的共享数据存入到文件资源库中 通过对文件资源库实现集中式的管理 保持文件资源的 非冗余性 文件资源库提供以下控制机制 文件资源的版本控制机制 合理组织文件资源的结构和版本模型 通过版本 控制方法对文件资源实施变更管理 拷贝 修改 合并的管理机制 多个客户端可以对文件资源库中的内容同时进 行修改 并将最终修改结果合并到资源库中 文件资源库中副本管理机制 实现副本和资源库中共享数据的非冗余性处理 通过对资源库的控制和管理 在生产线中共享数据只有一个是正确完整的 其他副本 都要和资源库中的数据进行比较 更新 保持数据的非冗余性 4 3 2 3 集成示例集成示例 Subversion 是一个流行的 自由 开源的版本控制系统 采用 Subversion 实现基于版 本模型的文件非冗余性解决方案 首先利用 Subversion 服务器实现文件资源库 控制文件 的版本模型和拷贝 修改 合并机制 同时利用 Subversion 客户端 如命令行客户端 或者 基于 Eclipse 的 Subclipse 客户端 控制对资源库中副本的使用 保持副本与资源库中数据 的一致性 保持共享资源的非冗余性 18 4 3 3 基于资源共享的基于资源共享的 Eclipse 数据一致性解决方案数据一致性解决方案 Eclipse 的资源管理架构由编程接口以及与工作空间 work space 相关的扩展点组成 并且由 org eclipse core resources 插件实现 org eclipse core resources 插件提供了各种支持 包括对 Navigator 视图中可见资源的支持 资源事件处理的支持和资源属性的支持 通过理 解资源模型的结构 插件开发人员可以有效地利用工作空间 API 来创建资源和管理资源 并且动态地对资源的各种更改作出反应 14 4 3 3 1 集成机制集成机制 Eclipse 平台的资源模型支持插件创建和管理资源 并且使用资源更改事件通知机制动 态地对资源的各种更改做出反应 这样 插件只需要与 Eclipse 资源模型进行交互 利用资 源模型提供的机制实现资源共享 Eclipse 资源模型允许插件对它所感兴趣的资源更改事件 进行注册 以便插件利用资源更改侦听器来对事件做出响应 4 3 3 2 集成方法集成方法 在 Eclipse 资源框架中 通过一系列接口提供资源更改的事件通知机制 包括创建资源 更改侦听器 处理资源更改事件以及访问更改所引起的资源变化等 通过以下步骤使用资 源更改事件通知机制 1 创建资源更改侦听器 通过实现 IResourceChangeListener 接口 该接口定义了 resourceChanged 方法 创建 一个资源更改侦听器 在这个侦听器实现的 resourceChanged 方法中 可以使用传入的 IResourceChangeEvent 参数查询事件类型 进行事件处理 并在需要的时候 可以获得一 个 IResourceDelta 对象 以便了解资源更改事件引起的资源变化细节 更细致地对资源更 改事件做出响应 2 注册资源更改侦听器 使用 IWorkspace addResourceChangeListener 方法将创建好的资源更改侦听器添加到 自己感兴趣的资源中 之后 每一次对感兴趣资源的更改操作 都会被识别为一次事件 并会通知给所有注册了的资源更改侦听器 来执行工具注册侦听器中实现的 resourceChanged 方法 完成工具对资源更改操作的响应 19 4 3 4 基于模型同步机制的数据一致性解决方案基于模型同步机制的数据一致性解决方案 基于模型同步的工具集成机制 利用模型同步的手段维护模型间数据的一致性 进而 实现插件间的集成与交互 这种集成机制要求开发人员基于某种模型同步框架 遵循一定 的开发模式 实现模型同步过程 4 3 4 1 集成机制集成机制 模型同步框架 15 实际上是一组接口 它定义了一个面向结构化模型的同步过程 为 构建模型的同步工具提供一个指导 基于模型同步框架 开发人员以支持模型同步的方式 将插件连接起来 从而形成一种以各个插件为节点的一种互相关联的网状结构 下面是模型同步框架中的一些重要概念 模型同步 源模型与目标模型满足某种事先定义的模型映射关系 对其中任一模 型做出修改后 通过一个同步过程 修改另一模型 并且修改后的两个模型仍然 满足这种映射 在模型同步框架中 一个同步过程通常由一组同步规则共同完成 同步规则 一个同步规则以源模型对象中某部分为输入 目标模型对象的对应部 分为输出 实现了功能逻辑上相对独立的一部分同步任务 上下文 上下文是同步规则之间共享数据的容器 在同步规则的执行过程中 上 下文会在规则的实现之间传递 每一个规则可以向上下文中存放需要共享的数据 也可以从中获取所需的数据 模型同步框架包含一个基于规则的执行引擎 实现一种基于观察者模式的监听机制 并定义一组接口和抽象方法 给出一个结构化模型间的同步过程 开发人员通过扩展框架 的接口 定义具体两个模型之间的同步规则 设置模型的监听过程 实现这两个模型的同 步工具 完成相关插件的集成 图 4 2 模型同步框架体系结构 模型 监听机制支撑模块 模型 表示同步 监听器模型元 素管理 模块 规则执行引擎 同步规则同步规则 表示执行规则 20 框架的体系结构如图 4 2 框架包含规则执行模块 监听器模块 监听机制支撑模块 三个主要模块 其中规则执行模块获取用户定义的同步规则 并执行它们 监听器模块捕 获模型的修改并做出相应的处理 监听机制支撑模块向模型提供监听机制 使得对模型的 修改可以传递到模型的外部 4 3 4 2 集成方法集成方法 基于模型同步的工具集成是通过实现模型同步 进而达到工具集成的目的 模型同步 框架允许开发人员按照一定的开发模式 扩展接口以实现两个具体模型间的同步过程 基于模型同步框架的开发主要包含以下几个步骤 1 确定模型是否支持监听机制 如果不支持 则利用框架的支撑模块定义的接口对 模型进行扩展 2 扩展 IAdapter 接口 实现对模型的监听 3 扩展 IRule 与 IContext 接口 实现同步规则 4 扩展 ISynchronizerProvider 及 ISynchroinzer 实现规则执行引擎 通过上面四个步骤 可以实现两个模型的同步过程 该过程为操作这两个模型的插件 建立起一种通信方式 使得插件对其中一个模型的修改能够自动传播到另一个插件中 模型同步框架主要接口介绍模型同步框架主要接口介绍 1 接口 ISynchronizeProvider 1 接口所属包名 com onceas modelsync framework 2 接口的可见性 public 3 接口的继承性 4 接口实现的接口 5 接口描述 规则引擎提供商 6 接口的操作描述 public ISynchronizer createSynchronizer 创建一个执行引擎 ISynchronizer public boolean validateContext IContext context 验证同步过程的上下文 从上下文中获取源模型与目标模型信息 验证其是否与引擎所同步的模 型一致 21 2 接口 ISynchronizer 1 接口所属包名 com onceas modelsync framework 2 接口的可见性 public 3 接口的继承性 4 接口实现的接口 5 接口描述 定义规则执行引擎 6 接口的操作描述 public void initialize 初始化引擎 public void addRule IRule rule 向引擎添加同步规则 3 接口 IRule 1 接口所属包名 com onceas modelsync framework 2 接口的可见性 public 3 接口的继承性 4 接口实现的接口 5 接口描述 定义规则 6 接口的操作描述 public boolean canAccess IContext context 判断上下文信息是否满足规 则的执行条件 public void execute IContext context 根据上下文 执行同步过程 通常 包括三个步骤 分别是创建目标模型元素 创建监听器 关联监听器 源模型元素以及目标模型元素 4 接口 IContext 1 接口所属包名 com onceas modelsync framework 2 接口的可见性 public 3 接口的继承性 4 接口实现的接口 5 接口描述 定义上下文 6 接口的操作描述 public void set String id Object object 将需要共享的数据按照一定的标 识放入上下文中 22 public Object get String id 根据标识获取数据 图 4 3 模型同步框架主要接口设计类图 4 3 4 3 集成示例集成示例 为了展示如何利用模型同步的框架进行集成 本节给出一个例子 例子以基于同一个 schema 生成的 EMF 模型与 JAXB 17 模型为输入 利用上节提到的开发步骤开发一个同步 两者的工具 分别操作两个模型的插件通过该工具得以以模型同步的方式被集成在同一开 发平台之上 示例中的 schema 描述如下 它定义了一个商店的结构 商店 shop 包含一个商店名属 性和一组商品分类目录 category 而目录包含一个目录名属性和一组产品 Product 产品 包含价格等信息 23 图 4 4 schema 示例 从 schema 中生成的基于 EMF 的模型以及 JAXB 的模型如下 图 4 5 模型示例 为了同步上述两个模型 根据上节介绍的开发过程 开发人员需要将两者的同步分为 两个方向 1 从 EMF 模型到 JAXB 模型的同步 一个方向是将对 EMF 模型所做的修改同步到 JAXB 模型 分为四步 1 首先为商店 产品目录以及产品这三类模型元素定义同步规则 相应的类有 EMF2JAXBShopRule EMF2JAXBCategoryRule EMF2JAXBProductRule 2 随后实现 Context 类 存放规则间的上下文信息 3 接着实现规则引擎并将规则添加到引擎中 相应的类有 EMF2JAXBSynchronizerProvider EMF2JAXBSynchronizer EMF2JAXB 4 最后实现监听器 Adapter 2 从 JAXB 模型到 EMF 模型的同步 另一个方向是将对 JAXB 模型所作的修改同步到 EMF 模型 与前一个方向不同 的是 JAXB 模型本身并不带有监听机制 开发人员可以使用 AOP 机制 基于框架提 供的接口扩展模型 其余实现与前者类似 代码结构如图 4 6 所示 24 图 4 6 代码示例 至此 开发人员已经基于模型同步框架为两个模型建立一种同步的关系 对其中一个 模型的操作会触发对另一个模型的相应修改 因而 如果插件分别操作两个模型 它们十 分自然地通过开发人员建立的同步过程被集成在同一个开发平台之上 25 5 面向控制的工具集成面向控制的工具集成 5 1 概述概述 面向控制的工具集成 描述了被集成的工具间在控制方面所应具有的关系及这些关系 的特性 实现工具间控制集成的目的 是为了给生产线及工具开发人员 提供灵活的工具 功能组合机制 利用这种机制 开发者可以根据项目的不同 以及所采用的开发流程的不 同 来灵活的组织被集成的各种工具 以形成特定的工具集合 对于工具开发者而言 实现工具间的控制集成 包含两个层面的需求 第一 正确定 义被集成的工具间在控制方面所具有的关系以及这些关系的性质 第二 为实现这些关系 选择或提供高效的技术解决方案 5 2 目的目的 控制集成的目的是为开发环境的使用者提供灵活的工具功能组合机制 为了达到这个 目的 被集成的各种工具间必须共享或者相互理解它们各自所提供的功能 所以各工具间 必须要交换它们所执行的操作及相关的数据 以此补充了工具间的数据集成 控制集成所描述的工具间的控制关系解决控制转移和服务共享的问题 这种关系可以 被分为如下两种 提供提供 控制关系中的提供关系是指 被集成的两工具间 一个工具提供自己的服务供另一个 工具使用 设想在集成环境中有一个项目管理工具 它需要使用者输入被开发工程的任务描述 则项目管理工具便有着对文本输入服务的需求 在这种情况下 文本编辑工具便对项目管 理工具形成了提供关系 使用使用 控制关系中的使用关系是指 被集成的两工具间一个工具使用另一个工具所提供的服 务 为了使工具间可以达到使用集成 必须要求工具在实现时具有清晰的模块化特征 一 个工具在运行中既可以去使用特定的服务 同时 该工具还必须要提供一种方便的机制 26 使它可以用其它工具所提供的等价服务来替换掉自己现在正在使用的服务 对于上例来讲 项目管理工具对文本编辑工具形成了使用关系 并且项目管理工具可 以用其他文本编辑工具所提供的文本编辑服务来替换掉自己正在使用的文本编辑工具 5 3 参考方案参考方案 为了具体的实现面向控制的工具集成中两工具间的提供和使用关系 经过调研推荐以 下的两种实际的技术实现方案 5 3 1 基于插件体系结构的基于插件体系结构的 Eclipse 平台解决方案平台解决方案 插件体系结构可以概括为 微内核 扩展体 的形式 在该体系结构中 扩展体 作 为外围设备按照一定的规范编写并运行在微内核之上 微内核负责 扩展体 的组织 管 理和运行 在这个体系结构中 扩展体 即为插件 插件是一种结构化组件 它将代码 和 或文档 添加至系统并以结构化方式描述它 插件独立地实现某个或者某些功能 在不对原系统作修改和编译的情况下将该功能添加至系统 基于插件体系结构的工具集成 就是将待集成的工具以插件的形式集成在一起运行 利用这种体系结构把各工具插件组织在一起 形成一个整体 并且为工具间的各种交互提 供机制 基于插件体系结构的工具集成要求在开发工具插件时要遵循一定的规范 以实现 工具的插件化 Eclipse 平台便是利用 插件体系结构 思想所开发出的一个良好的软件产品 它是一 个开放源代码的 基于 Java 的可扩展开发平台 已成为目前最为流行的支持插件体系结 构的开发平台 整个 Eclipse 平台是由一个很小的运行时 Platform runtime 以及在此运行时堆砌的一系 列插件组成的 该平台下的各功能组件都是以插件的方法开发并集成的 它附带了一个标 准的插件集 包括 Java 开发工具 以及其它实用机制 为开发人员提供方便 它同时包 含了一个插件开发环境 Plug in Development Environment PDE 允许开发人员构建与 Eclipse 环境无缝集成的插件工具 图 5 1 描述了 Eclipse 的基本体系结构 27 图 5 1 Eclipse 体系结构 Eclipse 中的插件项目通常包括一些特定的配置 比如说它们每一个都有一个插件描述 符 一个 manifest 和 或一个 plug in xml 文件 一个基于描述符指定的依赖关系的动态 classpath 特殊的编译器 和其他配置属性 插件的开发一般分为三个步骤 编写清单文 件 编写程序 部署插件 1 在 Plug in xml 里声明要实现的扩展点 首先 确定插件要对平台的哪些部分进行扩展 然后编写配置文件 plug in xml 文件 采用 XML 语法描述 主要包括扩展点标识 扩展点名称 在用户界面中显示的名称 使 用的图标 实现该扩展点的类名 扩展点实例名等信息 2 编写程序完成插件功能 这与开发其他工程相同 即为编写具体的业务逻辑接口与实现 3 部署插件 以上开发过程结束后就需要以适合在平台上交付的形式来发布插件 部署格式包括 单个 ZIP 文件 目录结构 更新站点的单个 JAR 归档 在部署之前还需在配置文件 MANIFEST MF 中设置该插件与其它插件的依存关系 包括该插件所依赖的其它插件 该 插件的可导出接口 28 5 3 1 1 集成机制集成机制 Eclipse 平台主要通过依存关系和扩展机制实现插件的控制集成 依存关系依存关系 依存关系是各个插件控制集成的重要方式 通过定义依存关系 插件可直接调用其他 插件提供的接口 考虑到安全问题 Eclipse 提供了导出机制 可以对插件的接口进行 可见 和 不可见 的配置 扩展机制扩展机制 扩展机制实际是一种互操作的通用设计原则 即规范化的接口和配置 通过 Eclipse 提 供的扩展以及用户自身提供扩展 插件通过实现其他插件的扩展并被其他插件实现自己的 扩展 从而形成一种围绕在 Eclipse 平台运行时的互相关联 向外辐射的层次结构 下面是扩展机制中的一些关键概念 扩展点 定义平台开放给功能模块开发者的接口 以及必须遵守的规范 包括一 系列的属性及其期望值 它通常包括一个 xml 文件和一个对应的 java 接口 扩展 插件用来将新功能部件添加到平台中的机制 扩展不能随意创建 它必须 符合它正在扩展的扩展点的规范 扩展点 schema 定义扩展点时所使用的 XML Schema 文档规范 是 W3C 的标准 规范的一个真子集 在 Eclipse 中开发人员需要按照扩展点 Extension Point 定义的规范进行明确的声明 用户不仅可以使用 Eclipse 提供的众多现成的扩展点 而且可以定义新的扩展点 并在该扩 展点进行扩展 5 3 1 2 集成方法集成方法 基于依存关系机制的集成方法基于依存关系机制的集成方法 1 对提供关系的实现 在 MANIFEST MF 文件中利用 Export Package 语法为其它插件提供服务 该方法是依 存关系机制中对提供关系的实现 通过 Export Package 头部 插件可以指明允许暴露给其 他插件所共享的包 以这种方式向其它插件暴露自己的接口 使其它插件可以调用在本插 件中定义的功能 它的具体语法为 29 Export Package export export export package names parameter package names package name package name Exprot Package 头部也允许定义 directvive 指令 与 attribute 属性 Directive 包括 Use 指明该导出的包所使用的其他的包 多个不同的包之间采用逗号分隔 Mandatory 当某个插件导入该包时必须指明 madatory 属性 Include 指明该导出包中的哪些类为导入者可见 Exclude 指明该导出包中的哪些类为导入者不可见 Atrribute 包括 version 定义该导出包的版本号 specification version 为 version 属性的别名 当头部中出现 version 属性时 specification version 属性的值必须与 version 属性的值相同 下面的代码摘自 Eclipse 的源码 它表示了 Eclipse 的插件 org eclipse ui navigator 向外 部公开了自己的 org eclipse ui internal navigator actions 包 2 对使用关系的实现 在 MANIFEST MF 文件中利用 Import Package 语法使用其它插件提供的服务 该方法 是依存关系机制中对使用关系的实现 通过 Import Package 头部可以指明所要导入的其他 插件的包 具体的语法如下 在 Import Package 头部中