在 Rational Method Composer 中使用 Web 2.0 创建协作和动态的方法内

利用 Web 2.0 技术扩展软件开发的流程内容，通常将该内容静态发布为 HTML。本文介绍如何开发以协作方式编辑方法内容的能力，以及如何获得访问方法上下文中最新动态内容的权限。
引言

IT 专业人员通常使用软件开发方法论，如 IBM® Rational® Unified Process (RUP®)。在各种软件开发规程和垂直行业中可以应用此类方法。软件开发方法（如 RUP 和 IBM RUP 面向服务的建模和体系结构 (SOMA)）可提供发布为 HTML 的静态流程指导。IBM Rational Method Composer 是一种流程工程师用来自定义流程的工具；不过，您可以将新的流程发布为只读网页。

要获得真正有用的方法，需要使用特定于上下文的资产进行扩充。这些资产通常是内容、工具和人员资产。内容资产包括各种资源，如文档、演示文稿、模型、社会书签和其他资源。例如，如果在电话公司 (telco) 的垂直帐户中应用此方法帮助业务建模，则该方法应提供关于可利用的特定工具和内容的指导。

因为发布后，方法内容是被冻结的，所以它不可扩展。因此，您可以通过 Web 2.0 技术使用补充的 wiki 页扩充静态内容，以启用协作编辑和动态 Web Feeds。在接下来的部分中，将这些页称为扩展点。

那么为什么缺乏方法可扩展性会成为问题？因为方法内容：

过期；例如，指导构件（如模板、资产或工具使用指导信息）已过时。
在不进行自定义的情况下，缺乏特定的上下文详细信息。例如，由于现成的方法内容的不具体性，所以它需要适用于所应用的情形，如组织、行业领域、角色、活动、资产和工具。
自定义需要重新发布。
缺乏用户或专业人员扩充的能力，因此，无法利用用户对社区内容开发和增强的贡献。因此，通常缺少用户社区的反馈和协作的机会。
缺乏利用富媒体内容（如视频、Podcast 和 Flash 演示文稿）的能力，因为它们通常很快会过时。
趋向于缺乏详细的商业工具指导。
缺乏对组织资产或工具的现成指导。
另一个问题是流程工程部门没有足够的资源产生领域所需的所有方法内容。例如，他们通常不能为同一工具的不同版本提供内容。因此，方法内容始终保持不变，组织无法得到聚集起来的知识和基于实际领域知识来修改内容的专业人员的见解。

注意：其中某些内容通常对组织具有很高的优先级；例如 Insurance Application Architecture (IAA) 模型，它是由 IBM 公司所专有的。

已使用其他技术解决同一问题。请考虑以下事项：管理员或流程工程师可以定期重新发布静态方法（例如，每月、每周和每天）。不过，需要建立流程，将专业人员的反馈或贡献合并到方法。另外，下面的事实会加剧此问题：方法随工具（如 IBM Rational Software Architect）一起发布，并且在更新 Rational Software Architect 之前不能更新方法。专业人员使用最新的信息构建自己的页面，但是这些页面是分散的，不能与方法和流程内容集成。



使用 Web 2.0 创建可扩展的方法内容

您希望使用扩展来更新软件开发流程和方法，这些扩展是以协作方式构建的，并且可以在专业人员使用方法时以动态方式进行填充。图 1 显示了与此类似的内容。


图 1. 协作和动态方法概述



有多个与此协作和动态内容相关的活动。让我们深入了解一下这些活动。

扩展点标识

流程工程师在静态方法中标识扩展点。这些扩展点通常位于描述新技术或改进技术的方法区域中，或者同时位于这两个区域中，并位于需要使用社区帮助进行构建的区域中，否则会很快过期。

扩展页的创建

标识了扩展点后，流程工程师将为此扩展点创建扩展页面。此扩展页面的用途是除提供静态方法外，还提供最新的指导。扩展页面包含两个区域：

协作指导内容区域
动态内容区域
协作指导区域

协作指导内容区域为此扩展点提供关于方法的最新指导。此页面中的原始内容通常由对此特定的扩展点有丰富经验的另一个流程工程师填充的。例如，此区域中的内容可以是关于工具以及如何获取工具的最新信息，然后使用这些信息更有效地执行此扩展点。用户（专业人员或架构师）还可以编辑此协作区域，允许捕获基于领域的课程和输入，这样可以保持所学的关于此扩展点的最佳实践和基于领域的课程是最新的。Web 2.0 实现此协作指导区域的示例是 wiki。

动态内容区域

动态内容区域以动态方式为用户或专业人员提供资产和构件，以帮助他们执行此扩展点描述的任务。资产和构件的种类包括社会书签、主题专家（包括他们的即时消息传递状态）、文档、出版物、演示文稿、富媒体联合内容（如 Podcast 和影片）和教育材料（包括 Blog、在线课程材料和课堂学习）。因为此区域中的信息是动态的，系统在专业人员请求页面时构建内容，这样总能保证他们获得最新信息。Web 2.0 实现此动态内容区域的示例是聚合 Web feeds。

静态方法流程工程师为使用静态方法标识的每个扩展点重复创建扩展页面。

通过采用此技术来创建方法，当用户请求特定的页面并包括来自核心方法内容外部的许多不同来源的信息时，自动构建动态内容。此动态内容可以由专业人员提供，而不仅仅是方法作者（流程工程师）。需要从方法来访问此动态内容，它们并未分散在互联网或内部网上。

图 2 演示了方法内容的位置（拓扑视图）。最好从下至上阅读注释，并从顾问的本地计算机开始。


图 2. 协作和动态方法结构


开发软件方法时，采用这种方法的优点是：

方法内容并不局限于特定版本中的方法提供的内容。
方法内容始终保持最新。
专业人员（而不仅仅是流程工程师）可以提供方法内容。
专业人员无需下载新版本的冻结方法。
内容不再局限于工程部门在有限的时间、预算和人员情况下提供的内容。
可以非常容易地将富媒体和创新内容（例如有关主题、Podcast和 flash 影片的专家列表）集成到方法内容中。
方法可以包含冻结（静态）的核心内容和组织或社区可以扩展和自定义内容的点。
专业人员可以非常容易地找到特定相关主题的专家。
此类方法的实现：

标识可在静态方法中扩展的点。
提供链接，以协作方式从这些扩展点构建动态内容。
对于每个链接，使用两个区域提供 wiki 页：
最新的可编辑的文本信息
动态填充的关于社会书签、人员、活动、Blog 或资产的 Web feeds
下面是此方法的工作原理以及如何为特定的面向服务的体系结构 (SOA) 分析场景实现该方法（请参见图 3）：


图 3. 协作和动态方法实现



如何使用该方法的示例如下：SOA 项目中的软件架构师现在参与了 SOA 系统的分析。在 SOA 中，核心活动之一称为服务标志。因为 SOA 项目本质上非常复杂，并且 SOA 仍处于了解阶段，所以只有少数专业人员才能完全了解 SOA 活动和支持这些活动的工具。

静态方法几乎不可能包括关于这些活动的最佳实践的最新内容，实际上是优化这些活动的工具。为克服此缺点，在基本方法中标识了扩展点。静态方法以 HTML 形式呈现，这些扩展点是方法内部的超链接。在本示例中，SOA 架构师在执行服务标志。静态方法包含关于服务标志的高级指导和在用于服务标志的特定工具上以协作方式构建动态内容的链接。此链接将架构师引入协作网站，例如，此扩展点专用的 wiki。






Wiki 实现

此 wiki 网站包含以下两个区域。

协作内容区域

第一个区域包含关于服务标志工具的最新信息，使活动更一致和简化。因为这是协作区域，所以鼓励 SOA 架构师编辑这些说明，保持内容最新，并围绕这些工具提供基于最新领域的开发思想。

动态内容区域

这是 wiki 网站的第二个区域，它以 Web feeds 的形式为此特定的扩展点提供与架构师相关的动态内容。在服务标志扩展情况中，该区域由关于服务标志的动态内容填充。根据一组与此特定扩展点相关的独特标志筛选此动态信息（例如，用于服务建模活动的标志可能是：services modeling 和 service-modeling）。此类联合动态内容包括：

服务标志的社会书签和主题专家（包括它们的即时消息传递状态）。
资产存储库中的可重用资产（包括文档模式和甚至用于服务标志的工具）。
富媒体内容（包括技术讲座、影片或 Podcast）。
教育内容（包括 Blog、课程材料、其他阅读材料和 IBM Redbooks®）。
架构师需要进行一些活动才能成功完成关于服务标志的扩展点。
使用格式为 RSS 或 Atom 的联合 Web feeds 将所有此类动态内容嵌入 wiki 可做到这一点。上述的每个动态项目都有自己的 Web feeds ，可以聚合这些 feeds 来提供所有的动态内容。这种情况已经成为可能，例如，通过标准化 Web 2.0 技术和标志，所有写入资产存储库并与服务标志相关的内容都是带有服务标志和动态方法关键字的标志的。使用这些关键字将项目写入支持 Web feeds 的资产存储库后，将自动更新资产存储库提供的 Web feeds。因为刷新了服务标志扩展点的扩展页，所以方法专业人员（架构师）现在可以使用更新的内容。对所有其它动态 feeds 的内容也可以做到这一点。