软件生产线调研报告.doc

软软件件工工程程研研究究方方向向 软软件件生生产产线线调调研研文文档档 变变更更记录记录 变更版本日期图表 表格 段落号 A M D 原因与修改情况描述修订人审核人 1 02007 12A创建尹铨 1 12008 7M 更换模板 并修改产品线与生 产线区别章节 尹铨 注 A 增加 M 修改 D 删节 目录 XXXXXX 研究方向 XXX 文档 I 目目录录 第第 1 章章 绪论绪论 1 1 1 软件开发环境演化 1 1 1 1 早期的专用开发工具 1 1 1 2 命令行开发环境 2 1 1 3 集成开发环境 2 1 1 4 扩展开发环境 2 1 1 5 协同开发环境 2 1 2 软件开发环境的现状 5 1 3 开源阵营的贡献 5 1 4 软件生产线的出现和发展 7 1 5 软件生产线的主要研究团队及其研究现状 8 1 5 1 SEI 8 1 5 2 PLARG 9 1 5 3 IESE 9 1 5 4 其他 10 1 6 软件开发技术的发展与挑战 10 第第 2 章章 OSGI 插件体系结构与软件构件技术插件体系结构与软件构件技术 12 2 1 OSGI 插件体系 12 2 1 1 标准服务 14 2 1 2 框架服务 14 2 1 3 系统服务 14 2 1 4 协议服务 15 2 1 5 其他服务 15 2 1 6 总结 15 2 2 架构 15 2 3 平台运行时和插件体系结构 16 2 3 1 工作空间 17 2 3 2 工作台和UI组件 17 2 3 3 团队支持 17 2 3 4 帮助 17 2 3 5 总结 17 2 4 软件构件技术 17 第第 3 章章 软件生产线软件生产线 19 3 1 软件产品线的提出 19 3 2 可信软件生产线的体系结构 20 目录 XXXXXX 研究方向 XXX 文档 II 3 2 1 集成性 20 3 2 2 可扩展性 20 3 2 3 协同性 21 3 2 4 标准化 21 3 2 5 模块化 可定制性 21 3 2 6 覆盖软件生产全部生命周期 21 3 2 7 可信性 21 3 3 可信软件生产线的工具集成机制 21 3 3 1 Eclipse的插件集成机制 22 3 3 2 OSGi绑定包的协作 22 3 3 3 拟采取的工具集成机制 23 3 3 4 进一步的研究 SCA 23 3 4 可信软件生产线的数据交换机制 24 3 4 1 MDA 24 3 4 2 MOF 25 3 4 3 XMI 26 3 4 4 进一步的研究 SDO 27 3 5 可信软件生产线的优势 28 第第 4 章章 支持运行监控的可信软件生产线支持运行监控的可信软件生产线 1 4 1 提出背景 1 4 2 体系结构 1 4 3 可信软件构造模型 TSCM 1 4 4 支持运行监控可信软件生产线构造方法 3 4 5 目前进展 4 4 6 不足与下一步计划 5 参考文献参考文献 1 目录 XXXXXX 研究方向 XXX 文档 1 第第 1 章章 绪绪论论 1 1 软件开发环境演化 如何保证软件开发的成功 如何克服 软件危机 成为世界范围内计算机软件领域专家关注 的一个焦点 软件工程思想的精髓 就是希望软件开发能够借鉴其它工程学科的成功做法 走 软 件工程化 的道路 要实现软件的工程化 最关键的是建立配套的计算机辅助软件工程工具组成的 软件开发环境 软件开发环境的本质是对软件产品的元数据和过程进行管理 通过信息集成 有效管理贯彻 整个软件产品生命周期的产品数据和过程数据 一方面 可以帮助软件企业组织软件系统需求分析 设计规划 系统建模 完善结构配置和修改 跟踪进展中的设计信息 并方便地查找和重用相关软 件产品信息 另一方面 软件开发环境可以协调软件企业进行规范化 标准化和自动化管理 实现 软件产品的无纸化设计 从而缩短软件的开发周期 保证软件质量 软件开发环境作为开发软件产品的平台 与软件开发本身的发展具有紧密的联系 随着软件系 统的规模和复杂度不断提高 软件开发呈现出许多新的特点 如系统的需求分析 设计 实现和集 成等越来越困难 系统开发周期长 费用高 进度难以控制 激烈的市场竞争要求软件必须在尽可 能短的时间内推向市场 群组协作和并行开发成为软件开发的主要形式 要求加强开发人员之间的 协作和交流等 软件开发的发展过程 就是一个不断抽象的过程 在开发语言 开发平台 开发过 程 开发方法基于的计算范型等方面 都是不断抽象的过程 如下表 语言汇编 Fortran COBOL Simula C Java 平台裸机 BIOS 操作系统 中间件 领域特定平台 流程瀑布模型 螺旋模型 迭代开发 敏捷方法 计算范型面向过程 面向对象 面向服务 纵观软件开发环境的发展 可以把它们总结为五个发展阶段 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 1 1 1 1 早期的专用开发工具 计算机诞生后的开始一段时间里 硬件的人机接口从完全裸机发展到终端显示 编程语言从机 器语言发展到高级语言 相应的 此时期的软件的开发使用专用的工具 这些开发工具用于串行软 件开发 专用开发工具不区分开发环境与运行环境 开发出的软件产品都是特定于开发环境的 因此也 就特定于硬件环境 由于开发工具在不同硬件间是不可移植的 所以我们称之为专用开发工具 这些专用的开发工具提供的特性为加载器 执行器 典型的代表为 1945 年使用机器语言编写的第一个调试器 Mark II 1976 年使用 Basic 语言编写 目录 XXXXXX 研究方向 XXX 文档 2 的第一个 PC 机上的 Basic 开发工具 Altair Basic 1 1 2 命令行开发环境 此时期硬件发展方面人机交互接口出现图形化桌面系统 编程语言与编译方面出现翻译执行技 术 相应的软件开发环境是命令行开发环境 命令行开发环境运行在操作系统上 基于命令行 用 于串行的软件开发 与专用开发工具相比 命令行开发环境对开发环境与执行环境进行了某种程度 的区分 相同操作系统上开发的软件是可移植的 命令行开发环境提供的特性包括编辑器 编译器 链接器以及调试器 典型的代表为 1975 年 Stallman 开发的 Emacs 1980 年贝尔实验室开发的 Unix 交互式变成环 境 Kernighan B and Mashey J 1983 The UNIX Programming Environment Interactive Programming Environments McGraw Hill 1 1 3 集成开发环境 此时期硬件与软件的不断发展导致中间件技术的蓬勃发展 开发流程也从以前的面向过程发展 到面向对象 再到分布对象 基于连续演化 异构性 分布性以及并发性的需求 此时迫切需要能 支持并行软件开发的环境 集成开发环境是一个集成了编码 编译 调试 运行功能的统一开发环境软件 由于集成了不 同的功能 软件的开发过程中的不同的利益相关方均可以使用这些功能来协调开发 因此集成开发 环境可用于串行或并行的软件开发过程 后来又进一步增加了许多提高开发效率的实用功能 如高 级编辑功能 自动编译 设置断点逐步调试 在 IDE 内部显示运行结果等 集成开发环境提供的特性主要聚焦于以语法为导向的编辑器扩展 用于增强用户的开发过程体 验 典型的代表为 Smalltalk 第一个 PC 图形化 IDE 工具 Visual Basic 以及支持增量编译的 Rational 开发环境 微软的 Visual Studio IBM 的 Websphere Studio Sun 的 Studio One 也属于此类 1 1 4 扩展开发环境 此时期软件的体系结构模式发生变化 建模语言不断成熟 迫切需要对软件开发过程中空间 时间的分布开发特性 以及对非软件因素依赖的管理支持 扩展开发环境聚焦于为分布环境下软件开发提供集成开发环境 与集成开发环境相比 扩展开 发环境扩展了其使用的范畴 包括系统分析人员 架构师 开发人员 测试人员均可基于统一整合 的开发环境实现开发协作 开发环境由一系列互相依赖的工具组成 扩展开发环境不仅支持时间上 的分布开发 也支持空间上的分布开发 并且开始考虑对非软件依赖因素的管理 扩展开发环境提供的特性包括重构支持 需求管理 配置更改管理 建模等 典型的代表为 Eclipse Rational XDE 1 1 5 协同开发环境 硬件与软件的区别逐渐淡化 领域相关的编程语言出现 对关注点分离的需求使得相应的软件 目录 XXXXXX 研究方向 XXX 文档 3 开发环境可以在更高层次上开发系统 软件开发不仅仅是单纯的编码 它是团队开发者相互合作来设计解决方案 构建高质量代码的 协同过程 协同开发环境以协同开发思想为基础 通过整合协同工具 实现无缝的 完整的软件 开发 协同开发通过协同提高任务完成效率 通过资源共享 信息 专家知识 手段和设备等 缩短 任务完成的时间 系统开发过程是多人同时 分布参与的协同工作过程 协同开发环境的使用者扩 展到了目标软件的行业领域专家 网络与硬件工程师等 使得软件产品相关的所有利益相关方均能 配置其感兴趣的属性 在互动的软件开发协作过程中及时沟通并作出对策 协同开发环境 Collaborative Development Environment CDE 是一个虚拟空间 项目的所有利 益相关方 即使他们之间在时间 空间上是广泛分布的 可以基于此空间一起协商 集体讨论 争论 共享知识 目标通常是为了合作执行某种任务 大多数情况下都会交付具有可执行功能的产 品以及相关制品 工件 协同工作对于所有的工程领域都是必须的 分布的团队有效协作对成功是很必要的 这也是很 多中型 大型软件开发组织成功与否的显著标志 CDE 的本质是将支持软件开发活动的所有工具 集成在一起 对开发团队中日常的 无创新性的活动进行剔除或者自动化 以支持项目各利益相关 方通过创新的 有益的 高带宽的通讯模式来创建无摩擦的开发平面 Surface 传统的 IDE 聚焦于提供单个开发者的效率 CDE 聚焦于提供开放团队整体上的效率 IDE 本质上是以开发者为中心的 意味着他们的主要用户体验聚焦于单个的开发者 而 CDE 本质上是 以团队为中心的 意味着他们的主要的用户体验聚焦于团队的需要 以上概念和观点来自于Grady Booch1 and Alan W Brown2的 Collaborative Development Environments 1 一文 目前 软件的协同开发环境 SCDE 的各个环节中 有大量的开源软件 这些软件存在发展 持续性 产品稳定可靠性 应用适用性 各种不同计算环境的适应能力 服务支持能力等方面的 局限 通过 SCDE 进行有效的整合 形成一个配套的 稳定的工具体系 缩短 SCDE 的开发周期 尽快应用到软件企业中 同时 SCDE 为软件企业开发自主的开发工具提供基本的服务和构件 如 Error Reference source not found 所示是 SCDE 的功能视图 SCDE 将会努力为软件的开发创建一个绝对光滑的平面 Frictionless Surface 实现无损耗的开 发过程 以提高开发效率 为了实现无损耗的开发过程 SCDE 将会关注以下几个方面 起步阶段方面 协作开发方面 维护开发团队有效沟通方面 多个任务的时间协调方面 相互协商方面 1 Grady Booch 是 IBM Rational 的首席科学家 在软件架构 建模和软件工程过程领域的创新性工作是被国际公认的 他的工作已经极大地改善了软件开发世界 Grady 是统一建模语言的创始人 并且也是一些 Rational 产品的创始人 Grady 是六本最热销的书籍的作者 发表了几百篇关于软件工程的技术文章 他在世界各地进行讲演和咨询 2 Alan Brown 负责 IBM Rational 桌面产品的技术策略工作 并且是负责协调 IBM Rational 工具和软件开发平台产 品的领导团队中的关键成员 另外 他负责为公司的模型驱动开发工具制定前景和策略 Alan Brown 于 1988 年取 得 Newcastle upon Tyne 大学博士学位 目录 XXXXXX 研究方向 XXX 文档 4 资料有效性方面 上述 6 个方面是最容易出现损耗的地方 如果出现了损耗将会浪费时间和金钱 降低整个团队 的开发效率 比如 每个开发人员都有这样的经历 当一个新的项目开始时 总要有一个了解的过 程 而进入新的开发团队时也需要一个适应过程 这些都叫起步损耗 在起步阶段花费的时间越少 起步损耗就越少 而开发的效率就越高 SCDE 将不懈地对下面三个方面进行改进 提高集成在软件开发环境中开发工具的性能和易用性 将开发环境尽可能的覆盖到整个软件的开发生命周期 集成人与人 人与团队以及团队与团队进行交流的工具 图 1 1 软件的协同开发环境 协同开发环境中的协同工具主要提供三个方面的功能 实时交流 实时交流提供成员获知任务完成进度 更改计划 寻求帮助 提供解答 调度网络会议等 实时性要求 包括团队成员间 也可能涉及到与其它开发团队的整合 软件构件管理 一个组织内的软件构件间互相依赖度高 因此要求对构件的更改必须是可管理的 使得软 件整体实时更新 保证软件的正确性 此功能对于大型项目尤其重要 由于软件的协同开 发过程是围绕这些软件构件进行展开的 因此软件工件的管理是协同开发环境的最关键部 分 任务管理 任务管理主要聚焦于把软件项目分解成不同的任务 分配到各专长人员 并实现优化的任 务调度 协同开发环境提供的特性包括虚拟团队 即时通讯 网络会议 讨论等 典型的代表为 2 的 SourceForge 4 SourceCast 3 以及集成了连续集成管理功能的 目录 XXXXXX 研究方向 XXX 文档 5 XDE 目前这些协同开发环境提供的功能主要在代码协同方面 包括配置管理 冲突检测等 而忽 略了软件开发流程中其它占重要角色的软件开发活动 例如需求管理 项目管理 设计等 可以预见 软件开发环境将随着开发语言 开发平台 开发过程的不断抽象继续演化 反过来 也将导致这些方面的技术自身的演化 1 2 软件开发环境的现状 通过十多年的发展 Java 已经成为企业级应用开发主流平台 Java 开发环境的状况 基本上反 映了目前软件开发环境的现状 现在的 Java 环境可以分为三个集团 第一集团是 Eclispe 它大约占据 1 3 的份额 第二集团 是 IntelliJ IDEA 5 NetBeans 6 和 JBuilder 7 占据另外 1 3 的份额 相互之间旗鼓相当 第三集团 是以 JDeveloper 和 WSAD 为代表的十几种 Java 开发环境占据剩下的 1 3 份额 但每种开发环境占 总份额的比重不超过 5 我们考察 Eclipse intelliJ IDEA NetBeans 和 Jbuilder 2006 年发布的 版本已经基于 Eclipse 平台 这些主流开发环境 尽管在实现手段上各有不同 但它们有一个共同 的特点 可扩展 这就是为什么称现在的 Java 开发环境为 XDE 的原因 由于市场的压力 一个软件企业不仅要提高开发人员个体的工作效率 还要提高整个开发团队 以及整个企业的开发效率 但在现有的 Java 开发环境 XDE 下无法完全做到这些 所以新一代开发 环境 CDE 就产生 Grady Booch 和 Alan W Brown 的研究表明 一个程序员一天工作时间的分配是 这样的 分析占 16 从 5 到 40 不等 设计占 14 从 1 到 40 不等 编程占 16 从 0 到 60 不等 测试占 10 打电话占 3 阅读占 7 电子邮件 文档 月刊和杂志 参加开发会议 占 10 无关的会议占 7 从这些数据可以发现 开发人员用于交流的时间约占工作时间的 1 3 开发人员的相互交流非常重要 可是现有的主流 Java 开发环境一般仅将分析 设计 编程和 测试等工具集成进来 却未包括用于交流的工具 这显然不合理 因此 所谓 CDE 就是将用于人 与人 人与团队以及团队与团队进行交流的工具集成进来的开发环境 比如 CDE 常具有发送电 子邮件 进行及时通讯和屏幕分享等功能 通过实现无损耗过程的交流提高开发团队的开发效率 现在已经商业化的 Java CDE 是 CodeBeamer Collaborative Development Platform 和 CodePro AnalytiX 上述两款软件都提供 Eclipse 的插件 可以与 Eclipse 集成在一起 使 Eclipse 升级成为一 个 CDEs 即将发布的 JBuilder 2007 就是建立在 Eclipse 的框架之上 并加入了更多的协同开发的 特性 这就意味着 Java 开发环境将进入 CDE 时代 现在 Java 开发环境还处于 XDE 与 CDE 交替的 阶段 1 3 开源阵营的贡献 目前 开源软件正在国内外如火如荼的发展 开源阵营与传统的商业阵营从当初的对立逐渐地 走向了合作与融合 传统意义上的开发 软件工具 平台 价格昂贵 面向对象建模工具 Rose 平 均价格为一个 License 人民币 4 万元左右 配置管理系统 Clearcase CA 公司的 CCC Harvest 均以 一个 License 4000 美元的价格销售 一套系统价值 40 万元人民币 加上过程管理 项目管理 程 序理解 逆向 工具 软件测试辅助工具等 适合一个 50 人左右的基本完善的开发平台即需要 100 万元人民币以上 同时还有数额巨大的技术支持和服务费用 这使得我国软件企业缺乏必要的 软件生产配套装备 大量企业或使用盗版或依赖开源工具 而缺少必要的技术支持 使得先进软件 技术在企业中推广难度大 制约了软件生产效率的提升 而目前 随着开源软件的不断发展 对开 目录 XXXXXX 研究方向 XXX 文档 6 源软件的技术支持从个人 小团体渐渐地转向由转业公司提供 技术支持有了保障 因此 采用开 源软件搭建一个协同开发环境成为了国内外软件企业的一种节省经费的选择方案 经过对 Sourceforge 和国内一些协同开发环境的研究 下面根据形成覆盖软件开发的主要活动基础技术和工下面根据形成覆盖软件开发的主要活动基础技术和工 具体系给出了一种搭建协同开发环境的开源解决方案具体系给出了一种搭建协同开发环境的开源解决方案 有些商业产品提供开源 有些商业产品提供开源 lincense 3 1 软件开发方面 软件开发 组装 集成 部署 Eclipse NetBeans 开发平台 Linux 数据库平台 MySQL Server HSQLDB 企业级应用服务器 JBoss JFox Web 服务器 Apache Tomcat 开发语言 Java PHP Perl 开发框架 JEE 框架 Spring Framework Web 开发框架 WebWork Struts 持久层框架 Hibernate iBatis 模板引擎 Velocity 搜索引擎 Lucene 2 协同生产方面 过程管理 配置管理 AccuRev 版本控制 CVS Subversion 缺陷跟踪与管理集成工具 JIRA 8 Mantis Bugzilla 测试工具 Junit 项目管理 3 目前 商业专有软件仍占统治地位 但是商业专有软件配上部分开源软件来搭建一个企业协同开发平台成为了广 大企业的首选解决方案 目录 XXXXXX 研究方向 XXX 文档 7 协同任务管理工具 OpenProj dotProject Xplanner 报表工具 JasperAssistant 代码评审 Crucible 8 通信管理 协同平台邮件服务工具 sendmail XMail 协同平台公告管理 邮件列表管理 论坛 技术人员博客管理工具 Confluence wiki 8 xWiki 9 等 协同平台即时通信工具 Openfire 包括了桌面和 Web 两种客户端 10 协同平台浏览器工具 Firefox 知识管理 内容管理 文档协同创作 Confluence wiki 集成管理 持续集成工具 4 CruiseControl Bamboo 8 由上给出的一个搭建协同开发环境开源解决方案可以看出 开源阵营在软件开发技术和开发环 境的发展上做出了卓越的贡献 虽然短期内不可能完全撼动专有软件的统治性地位 但相信在不久 的将来将扮演着更加重要的角色 这也给了我们关于软件开发技术和开发环境发展的另外一种参考 选择 1 4 软件产品线的出现和发展 随着开发工具集成平台和软件开发技术的不断发展 完善 人们认识到 要提高软件开发效率 提高软件产品质量 必须改变手工作坊式的开发方法 采取工程化 协同化的开发方法和工业化的 生产技术 因此 人们根据工业界的产品线思想提出了软件产品线的思想 产品线的起源可以追溯到 1976 年 Parans 对程序族的研究 软件产品线的实践早在 20 世纪 80 年代中期就出现 最著名的例子是瑞士 CelsiusTech 公司的舰艇防御系统的开发 该公司从 1986 年 开始使用软件生产线开发方法 使得整个系统中软件和硬件在总成本中所占比例之比从使用软件生 产线方法之前的 65 35 下降到使用后 20 80 系统开发时间从近 9 年下降到不到 3 年 181 据 HP 公 司 19 年对 HP IBM NEC AT同时 插件还可以自由的定义新的扩展点 为其他插件提供新的 API 启动的时候 平台运行时会发现可用的插件 并读取他们的说明性文件 在内存中进行注册 平台通过名字来匹配扩展声明和扩展点声明 任何问题都会被检测到并存入日志 当然启动完成之 后 也可以添加 删除插件 插件的说明性文件需要有两部分组成 一部分要用来描述插件的运行 时依赖 另一部分则用来声明插件的扩展和扩展点 扩展点可以声明额外的特定的 XML 元素 允 许插件提供扩展来与对应的扩展点之间进行任意的信息交换 并且 插件从注册到内存中开始 其 扩展和扩展点就是可用的 而不需要激活其实现插件或加载任何代码 因此 除非插件的代码被加 载 否则插件占有的内存及对启动时间的影响几乎是可以忽略的 基于 XML 的插件的说明性文件 也使得插件的开发变得容易 只有当代码真正需要运行的时候 插件才会被激活 一旦激活 插件便利用插件注册中心来发 现并访问对其扩展点进行的扩展 通过决定可用的插件以及支持在插件之间交换消息时不需要激活 他们 平台可以为每个插件提供一个它运行时关于上下文的一个中肯并且丰富的资料信息 当平台 运行时 上下文是不能改变的 因此 当上下文发生变化时 就不需要通知插件各种复杂的生命周 期事件 因此也就避免了一个很长的启动序列 插件机制用来分离平台本身 确切地说是分离插件提供的工作空间 工作台等 甚至于平台运 行时也有自己的插件 对于那些不是基于 GUI 的配置 就可以忽略工作台以及其他的依赖于工作 台的插件 目录 XXXXXX 研究方向 XXX 文档 17 2 3 1 工作空间 插件可以操作用户工作空间中的文件 工作空间中包括一个或几个顶层项目 每个项目对应到 文件系统中用户特定的目录 每个项目包含用户创建和管理的文件 工作空间中所有的文件都是可 以用操作系统下的工具和标准程序直接访问的 被集成到平台上的插件通过 API 来处理工作空间中 的资源 2 3 2 工作台和 UI 组件 工作台与平台的 UI 是完全同义的 为用户提供所有的结构和可扩展的 UI 当平台运行时 提 供用户可以看到的主窗口 平台 UI 包括编辑器 视图和透视图等 编辑器允许用户打开 编辑和 保存对象 与基于系统的工具一样遵循打开 保存 关闭的生命周期 但是却是更紧密的集成到工作 台中的 当激活的时候 编辑器便可以向工作台的菜单和工具按钮贡献 actions 视图可以提供工作 台中用户正在操作的对象的信息 一个工作台窗口可以有几个透视图 但是在给定时刻 只有一个 透视图是可见的 每个透视图都有自己的视图和编辑器 打开一个透视图的时候会打开几个不同类 型的视图和编辑器 透视图控制着这些视图和编辑器的可见性 布局等 2 3 3 团队支持 工作空间是在开发人员的机器上本地进行维护的 而团队通过外部资源库进行协作 不同开发 软元的代码在资源库进行汇集 平台提供了对于直接从工作空间进行托对开发操作的支持 这种支 持允许开发人员并发地与几个独立的资源库既不同版本的代码或项目进行交互 工作空间中的资源 允许团队支持组件处理版本和配置管理问题 当然 每个工作空间可以同时访问不同类型的资源库 2 3 4 帮助 平台帮助机制允许工具为在线帮助手册来定义和扩充文档 例如可以用工具经常需要贡献帮助 类型的文档到用户指南 或者是贡献 API 文档到程序员指南 2 3 5 总结 软件开发的集成平台需要提供一个通用的构件块和像工作空间 工作台等类似的 API 以及可 以用来集成新功能的扩展点 通过这些扩展点 可以用来开发新的工具来扩展集成平台 同时 又 可以在新开发的插件上定义新的扩展点和他们自己的 API 2 4 软件构件技术 构件 Component 是指应用系统中可以明确辨识的构成成分 而可复用构件 Reusable Component 是指具有相对独立的功能和可复用价值的构件 12 可复用构件应具备以下属性 16 有用性 Usefulness 构件必须提供有用的功能 可用性 Usability 构件必须易于理解和使用 质量 Quality 构件及其变形必须能正确工作 适应性 Adaptability 构件应该易于通过参数化等方式在不同语境中进行配置 可移植性 Portability 目录 XXXXXX 研究方向 XXX 文档 18 构件应能在不同的硬件运行平台和软件环境中工作 随着对软件复用理解的深入 构件的概念已不再局限于源代码构件 而是延伸到需求 系统和 软件的需求规约 系统和软件的构架 文档 测试计划 测试案例和数据以及其他对开发活动有用 的信息 这些信息都可以称为可复用软件构件 软件构件技术是支持软件复用的核心技术 是近几 年来迅速发展并受到高度重视的一个学科分支 其主要研究内容包括 构件获取 有目的的构件生产和从已有系统中挖掘提取构件 构件模型 研究构件的本质特征及构件间的关系 构件描述语言 以构件模型为基础 解决构件的精确描述 理解及组装问题 构件分类与检索 研究构件分类策略 组织模式及检索策略 建立构件库系统 支持构件 的有效管理 构件复合组装 在构件模型的基础上研究构件组装机制 包括源代码级的组装和基于构件 对象互操作性的运行级组装 标准化 构件模型的标准化和构件库系统的标准化 目录 XXXXXX 研究方向 XXX 文档 19 第第 3 章章 软软件件生生产产线线 随着开发工具集成平台和构件开发技术的不断发展 完善 人们逐渐认识到 要提高软件开发 效率 提高软件产品质量 必须改变手工作坊式的开发方法 采取工程化的开发方法和工业化的生 产技术 因此 人们根据工业界的产品线思想提出了软件产品线的思想 这种思想是软件开发走向 产业化的基础 也是软件重用的一大提升 软件产品线是一个十分适合专业的软件开发组织的软件开发方法 能有效的提高软件生产率和 质量 缩短开发时间 降低总开发成本 它也是一个新兴的 多学科交叉的研究领域 研究内容和 范围相当广泛 本章主要讨论了软件产品线的提出 可信软件产品线体系结构 工具集成机制和数 据交换机制 3 1 软件产品线的提出 软件产品线最早是由 ParnasError Reference source not found 提出 最初被称作 software product line 也被称作 product family 和 system family 目前 Software Product Line 是 CMU SEI 提 出的产品开发的组织方式 SPLC 会议是在此领域最受瞩目的会议之一 已举办了 5 届 CMU SEI 给出了 SPL 的确切定义 定义定义 1 软件产品线 A software product line SPL is a set of software intensive systems that share a common managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way 产品线是一个产品集合 这些产品共享一个公共的可管理的特征集 这个特征集能满足选定的 市场或任务领域的特定需求 软件产品线是多个软件密集系统组成的集合 这些系统共享一个公共 的 可管理的特征集 这个特征集能满足选定的市场或任务领域的特定需求 这些系统遵循一个预 描述的方式 在公共的核心资源 core assets 基础上开发的 以上概念来自http www sei cmu edu productlines 针对软件产品线的提出 CMU SEI 相应的提出了开发软件产品线的方法 软件产品线实践 即 Software Product Line Practice 关于 Software Product Line Practice 的确切定义为 定义定义 2 软件产品线实践 软件产品线实践是一种系统的方法 通过按照一定的生产方式 使用核心资产进行集成 实例 化或者产生多种产品来构成软件产品线 软件产品线实践包括了战略级 粗粒度的重用 国外从事软件产品线领域研究最活跃的学术团体是 CMU SEI SEI 主要研究方向为产品线实践 是以其对软件工程实践的研究为基础推动和促进向软件产品线方法的转化 Don Batory 领导的德克 萨斯大学产品线体系结构研究组 PLARG Product Line Architecture Research Group 11 主要研究方向 为 产品线体系结构 即插即用的软件构件 面向对象设计模式的自动化应用 软件生成器和领域 建模等 Fraunhofer IESE Institute for Experimental Software Engineering 12 隶属于德国凯撒斯劳腾大 学 它由 Dieter Rombach 教授等领导 该研究院致力于推动创新的软件开发技术 方法和工具向工 目录 XXXXXX 研究方向 XXX 文档 20 业实践的转化 并向公司企业提供开发产品线和提高其竞争力的帮助 3 2 软件生产线的引入 为了进行软件产品线实践 人们引入了软件生产线的概念 软件生产线被称为 Software Production Line 自北大青鸟工程提出软件生产线概念和思想之后 在国家 863 计划重点课题 可 信的国家软件资源共享与协同生产环境 中给出了 Software Production Line 的确切定义 定义定义 3 软件生产线 软件生产线是按照一定的软件生产方法 将若干软件生产工具和构件有序组织起来的软件开发 环境 生产线能够较为完整地提供成套的软件开发支撑 由于生产环境中的软件工具适应多种软件开发方法 支持多种软件开发技术和运行平台 生产 线工具可以涵盖软件生产过程 管理协同过程和质量过程等软件开发全生命周期 通过软件生产线 集成框架能够集成软件工具 软件构件 软件服务 以及相应的协同机制 从而形成一条软件生产 线 实现软件制品的开发或加工处理 根据不同软件生产模式和集成策略 可以形成不同的软件生产线 例如基于构件的软件生产线 面向服务的软件生产线 支持异构集成的软件生产线和支持监控的软件生产线等 软件生产线实现 软件制品的加工处理 其共性基础是 在软件可信保障机制 开发协同平台 以及共享资源库的共 同支撑下 灵活组合软件需求分析 建模 开发 组装 集成和部署等各阶段生产工具 形成一条 软件制品转换流程 通过对输入制品的有序加工处理 形成所需要的加工后软件制品 因此 我们因此 我们 认为这里的软件生产线实质就是支持软件产品线实践的开发环境 其内涵为按照一定的软件生产方认为这里的软件生产线实质就是支持软件产品线实践的开发环境 其内涵为按照一定的软件生产方 法 利用核心资产和相关工具支持进行特定领域内软件家族制品的生产 法 利用核心资产和相关工具支持进行特定领域内软件家族制品的生产 国内 青鸟工程 七五 期间 已提出了软件生产线的概念和思想 17 其中将软件的生产过程 分成3类不同的生产车间 即应用构架生产车间 构件生产车间和基于构件 构架复用的应用集成 组装车间 从而形成软件产业内部的合理分工 实现软件的工业化生产 软件开发人员被划分成三 类 构件生产者 构件库管理者和构件复用者 这三种角色所需完成的任务是不同的 构件生产者 负责构件的生产 描述 构件库管理者负责构件分类以及构件库的管理工作 而构件复用者负责进 行基于构件的软件开发 包括构件查询 构件理解 适应性修改 构件组装以及系统演化 软件生产线能够较为完整地提供成套的软件开发支撑 实现软件制品的加工处理 其共性基础 是 在软件可信保障机制 开发协同平台 以及共享资源库的共同支撑下 灵活组合软件需求分析 在软件可信保障机制 开发协同平台 以及共享资源库的共同支撑下 灵活组合软件需求分析 建模 开发 组装建模 开发 组装 集成和部署等各阶段生产工具 形成一条软件制品转换流程 通过对输入制品集成和部署等各阶段生产工具 形成一条软件制品转换流程 通过对输入制品 的有序加工处理 形成所需要的加工后软件制品 的有序加工处理 形成所需要的加工后软件制品 3 3 可信软件生产线的体系结构 软件产品线的发展方法的主流是把不同的管理技术用于一般的软件产品线体系结构中 设计者 可以通过重用一般体系结构内的普通的软件产品线集合生产新产品 这种方法是以可重用构件的组 装作为基础 传统的软件产品线是软件系统发展的基于体系结构的方法 它是通过选择组装一个产 品线的产品集合开始 然后识别所有产品的通用的需求和产品不同的特性 根据需求分析 一个普 通的软件产品线体系结构和可重用构件集合被设计为实现 最后 实际软件制品就由这些共享资源 产生 但是 可重用的体系结构设计是一个复杂的问题 有多少共性和变化性应该被引入到一个普 通的软件生产线体系结构中 当然 变化性越多 重用的好处就越多 因此 设计一个灵活的体系 目录 XXXXXX 研究方向 XXX 文档 21 结构成为了构建软件产品线的一项挑战 稳定而不失灵活性的体系结构是一个成功的软件产品线的基础 体系结构描述了软件产品线应 用领域的业务体系结构共性和个性 支持该业务体系结构的信息体系结构 应用体系结构和技术体 系结构 软件生产线为获得体系结构的重用 必须依据 低耦合 高内聚 的原则 设计能够适应变 更的体系结构 这就要求在捕获需求时使用域分析的方法 对历史和前景进行分析 历史分析用于 总结该类系统需求的不变点和可变点 前景分析用来预测系统需求今后可能发生的变化 得到不 变和可变的功能需求和质量场景 从体系结构的各个侧面来看 变更对体系结构影响的程度从大到 小依次为业务 位置 技术 组织 信息和应用 而这些都是软件产品线实践的所关心的主要内容 这里我们为了对软件产品线实践进行很好的开发支持 提出了这样的一种可信软件生产线体系 结构如图 3 1所示 图 3 1 软件生产线体系结构 这里的可信软件生产线由一系列的生产工具集成在提供协同开发的软件开发协同平台上 通过 可信保障机制 利用生产线包含的共享资源库 实现一个 软件原材料 到 软件成品 的转变过 程 体系结构的组成使得了软件生产线将具有以下一些特性 3 3 1 集成性 软件生产线集成了软件开发所需的开发环境 并集成不同的功能实现 软件在开发过程中的不 同的利益相关方均可以使用这些工具来协调开发 因此集成了大多数工具 开发环境和不同功能实 现的软件生产线可用于串行或并行的软件开发过程 3 3 2 可扩展性 可扩展性是软件生产线的基本要求之一 软件生产线要实现生产线的可定制性 则必定具有可 扩展性 软件生产线的可扩展性扩展了其生产的范畴和被使用的范畴 包括系统分析人员 架构师 开发人员 测试人员 部署人员 维护人员均可基于统一整合的软件生产线实现业务上的协作 生 产出所定制的软件制品 3 3 3 协同性 软件生产线要提高产品生产效率 增强生产线的开发能力 则必定通过资源共享 信息 专家 知识 手段和设备等 缩短生产线开发周期 生产线的开发过程是一个多人同时 并可能分布 参 目录 XXXXXX 研究方向 XXX 文档 22 与的协同工作过程 软件生产线的使用者扩展到了软件制品的行业领域专家 网络与硬件工程师等 等人员 要他们之间互相有效的协作 则软件生产线必须提供协同机制 这也是在体系结构中工具 集成在软件开发协同平台上的最主要因素 3 3 4 标准化 软件生产线工具间的接口 工具间互操作的数据格式都应该标准化 只有接口的标准化 不同 工具间才可以通过生产线进行集成和互相调用 只有数据格式的标准化才使软件生产线工具间的通 信与互操作成为可能 因此 标准化也应该是软件生产线的特征之一 3 3 5 模块化 可定制性 软件生产线的应该具有模块化及可定制性 软件生产线是由若干软件生产工具和构件有序组织 起来的软件开发环境 并为软件开发提供成套的开发支撑 这也就决定了软件生产线的模块化和可 根据不同的模块构件搭建一个特定的软件制品的生产线 3 3 6 覆盖软件生产全部生命周期 一个高质量的软件产品的生产过程一定覆盖了软件生产的全部生命周期 而提供这样一种产品 开发流程的软件生产线理所应当的覆盖软件生产的全部生命周期 3 3 7 可信性 这里 我们并不纠缠于可信的定义 这里软件生产线的可信性 指得是软件生产流程与软件制 品的身份可信 能力可信以及行为可信 一个计算实体的身份可信是指其身份声明在其工作环境中 可以被鉴别和验证的特性 一个计算实体的能力可信是指其能力声明可在其工作环境中得到验证的 特性 一个计算实体的行为可信是指其行为总是符合其承诺遵循的组织约定的特性 软件生产 流程可信 是软件制品可信的前提 而软件制品的可信又是证明生产流程可信的保证 3 4 可信软件生产线的 工具集成机制 在软件生产线的工具集成框架层面 可以通过轻量级的开放服务网关协议 OSGi 实现灵活 可扩展的生产线工具集成框架 但在讨论可信软件生产线工具集成框架之前 我们先看一下目前的 主流集成开发环境 Eclipse 是如何提供多种工具集成支持的 3 4 1 Eclipse 的插件集成机制 集成开发环境 IDE 经常将其应用范围限定在 开发 构建和调试 的周期之中 其它开发任 务 如系统设计与分析 必须由主 IDE 以外的专用工具来执行 这种双重标准 即紧密集成一些工 具 又冷落其它工具的做法导致开发环境出现不必要的分裂 而且对生产力造成负面影响 一些供 应商试图将他们的 IDE 扩展到上述周期的 三步曲 之外 但没有取得完全成功 问题在于成本 第三方工具提供商发现把他们的产品移植到每一种 IDE 中所需的费用实在过于昂贵 使事态更复杂 化的是 很少 IDE 能提供对用户接口的控制 以及完全实现 工具至工具 集成所需的用户体验 目录 XXXXXX 研究方向 XXX 文档 23 这些因素加在一起 使得很难或几乎不可能在单个环境中完成所有开发任务 为克服这些障碍 Eclipse 插件体系结构平台应运而生 Eclipse 提供一种公共集成机制 允许开发者只编写一次工具 即能在几乎所有类型的开发环境中应用它 其结果是 工具供应商不必浪费宝贵的资源来支持多种 IDE 相反 他们可以集中精力为自己的特定工具增添附加价值 此外 Eclipse 允许来自不同供应 商的工具集成到同一环境中 在许多情况下还能扩展彼此的能力 18 大多数 Java 编程语言开发人员通过作为 IDE 的功能认识了 Eclipse Eclipse 平台是一个开 放式插件体系结构 它提供了一些自身的扩展点来给其他插件做扩展 并且 Eclipse 平台负责管理 这些插件的运行 这样开发者可以只专注开发自己的插件 而不用去关心如何在运行时和其他插件 进行配合 Eclipse IDE 实际上由叫做插件的交互式构件的集合 组成 Eclipse 的核心是非常小的 其他所有的功能都是以插件的形式附加到这个 Eclipse 核心之上 这样的功能插件包括图形 API 称为 SWT Jface Java 开发环境 简称 JDT 插件开发环境 简称 PDE 等 这些插件组 成了 IDE 的基础 它们还可用于创建其他桌面应用程序 Eclipse 联机帮助将插件定义为 插件 是为系统提供功能的代码和 或数据的结构化包 可以以代码库 带有公共 应用程序接口 API 的 Java 类 平台扩展甚至文档的形式来提供功能 插件可以定义扩展点 定义良好的位置 其他插 件可以在这些位置添加功能 早期版本的 Eclipse 设计为插件集合 使用 Eclipse 自己专用的插 件系统来管理交互 但是 随着 Eclipse IDE 要求的增长 必须需要一个更强壮的解决方案 这个 新系统的基本要求包括动态添加新插件和停止现有插件的能力 经过大量研究之后 Eclipse 创建 者决定通过实现 OSGi 框架规范替换专用的插件框架 这里 很自然的就会联想到 为什么一定 要替换原有的插件框架而采用 OSGi 框架呢 3 4 2 OSGi 绑定包的协作 OSGi 是服务平台的规范 Eclipse 提供了该规范的许多可用实现之一 并用作最新 OSGi R4 规范的参考实现 OSGi 是基于 Java 的框架 旨在用于需要长运行时间 动态更新和对运行环境 破坏最小的系统 起初 OSGi 旨在用于家庭自动化和家庭网关设备 最近 从手机到汽车都发现 了它的踪迹 在核心 OSGi 是一个构件和服务模型 定义了一个叫做绑定包的模块化单位 见第 2 章 所有 Eclipse 插件现在都是 OSGi 绑定包 OSGi 规范定义了绑定包生命周期的基础架 构和绑定包的交互方式 规范中对每一个构件的安装 启动 运行 停止和卸载这些生命活动的管 理给予了具体的规范 OSGi 规范也提供了应用协作功能 应用 Bundle 可以向服务注册表注册服务 之后 别的应用 Bundle 就可以使用已经注册过的服务 OSGI 服务平台提供了一整套轻量级的发布 查找与绑定服 务的