内容


通过 Rational Method Composer 使用面向方面的 RUP(Aspect-Oriented RUP)

Comments

illustration面向方面的程序设计(AOP)是一种正在兴起的建建软件应用程序扩展的方法。AOP 允许您在不影响原始的应用程序源代码的前提下,对现已存在的应用程序进行修改。AOP 主要是针对面向对象(OO)的应用程序的;然而该方法也能够被用于其它类型的应用程序。

IBM® Rational® Unified Process® 简称为 RUP®,是一款被广泛使用的软件开发过程架构,几乎不需要任何指导。RUP 的特性就是一种迭代开发的方法,它基于用例技术在需求管理过程中为高级风险管理提供支持。

IBM Rational Method Composer (RMC) 是一款为建建定制交付过程而设计的新工具。使用 RMC 能够帮助公司创建和管理最适合其业务模型和原则的过程。RMC 还可以作为 RUP 和其他工业标准过程架构的最佳实践指导,例如 IT Infrastructure Library (ITIL)1,Project Management Body of Knowledge (PMBOK)2 和 IBM Rational SUMMIT® Ascendant®3。包括内容创作环境在内的 RMC 的大多数特性,可以从 Eclipse Process Framework (EPF)4 开源代码中获得。

使用面向方面的原因

在工程中使用面向方面的处理方法(AOA)主要基于以下三个重要原因:

面向方面的处理方法(AOA)正是满足了我们对一种记录过程扩展的标准方法的需要。由于大多数公司和项目都要求一种定制的实现过程,于是过程裁剪就成为了常规。项目团队领导者和涉众通常对经典的 RUP 非常了解,但是对定制过程扩展和过程变量并不是十分适应。这种不适应往往是源于抵触方法论和视角,或者是源于贫乏的记录或者冗余的责任。尽管记录过程定制的方法有许多,但是没有一种方法是被大家视作标准化的,而且各家公司或者实现机构必须创建自己的格式来描述扩展。如果公司不能够适当的记录和实现扩展,那么被扩展的过程将变得难以理解和遵守。正如下面将要讨论到的,面向方面的处理方法(AOA)提供了一种捕获过程扩展的模块化方法。

面向方面的处理方法(AOA)有助于工具积极的辅助过程定制。当前,缺乏广泛支持新的强有力的过程创作工具(例如 RMC 和 EPF)的用法指导,从而阻碍了这些工具更加广泛的应用。与此相关的是,缺乏一种记录过程定制的标准方法5,从而阻碍了项目的实现。正如下面将要讨论到的,面向方面的程序设计(AOP)是一种在开发社区中被普遍接受的标准。面向方面的处理方法(AOA)的实现通过普通的过程工程学工具来实现,有可能在那些裁剪过程和那些制定过程之间搭建起技巧和接受程度的桥梁。

面向方面的处理方法(AOA)的原则同过程创作工具高度的兼容。扩展机制,例如 RMC 可变性和后面将要描述的过程贡献,贯彻一些在面向方面的程序设计(AOP)中所采用的相同的原则。例如,如同在 AOP 中一样,RMC 允许您局部化过程变化和扩展,并且无须改变现已存在的交付过程就能够应用它们。

面向方面的处理方法(AOA)概述

AOA 的原则非常简单,并且适用于各种不同的情况。这种方法处理了软件程序设计中广泛存在的横剖问题。

面向方面的程序设计(AOP)范例

与面向方面的处理方法(AOA)不同,目前在程序设计中被广泛采用的模块设计方法将一个应用程序分解为不同的部分——例如组件、模型、类、方法等——这样做最小化了特定关注或者大量关注的功能性交叠和封装实现。从这点上来讲,关注可以是从狭义定义的业务或者系统问题(例如:“取钱”或者“显示用户信息”)到兴趣和焦点的区域(例如:“安全”和“审核”)中的任何事务。不幸的是,将关注清晰的划分到模块中并不总是可行的,这是因为其他的关注有可能会将这种划分横刀切断。举例来说,“取钱”的“安全”和“日志”就是一个典型例子,如下面的表1所示:

表 1:在这个模块设计业务方法的例子中,分别涉及到“安全”和“日志”的编程代码中的“取钱”交缠。

void moveMoney (Account from, Account to, float amount) {

if  (!getRequestingUser().isAuthorized(OPERATION_WITHDRAW)) {
	throw new SecurityException(MSG_NO_RIGHT_WITHDRAW_MONEY)
}

Transaction trn = database.startTransaction();
try {
	from.withdraw(amount);
	to.deposit(amount);
	trn.commit;

	logger.logOperation(OPERATION_WITHDRAW, from, to, amount);

} catch (DatabaseException e) {
	trn.rollback();
}

所显示的三个分别的关注——“取钱”、“安全性”和“日志记录”——在这个相对简单的方法中已经表现得十分复杂了。如果关注不再被应用到应用程序中的其他地方的化,这种分离的缺乏也就不会成为什么大的问题;但是,“安全性”和“日志记录”在许多业务方法中都会被用到,它们就是所谓的与单一业务逻辑关注相对应的“横剖关注”。

面向方面的程序设计(AOP)将代码分割到不同的模块之中,这些模块就被称为“aspects”(方面)。方面代码也被称作“建议”。当规则也就是“连接点”为真的时候,建议实现。连接点被封装在被称作“pointcuts(横切点)”的可以计量的扩展(查询)之中。

尽管这一简短的总结为您提供了面向方面的程序设计(AOP)的基本语义学,但是要想全面理解这方面知识的话,我建议您参考相关的文章或者书籍。在本文最后,我列出了一些相关的资源。

现在,我将解释面向方面的程序设计(AOP)的语法,并且讨论 AOP 如何能够被应用到过程域中。

面向方面的程序设计(AOP)语法

最初的和最受欢迎的 AOP 实现——AspectJ——使用语法描述了横切点,如下面的图1所示:

AspectJ 使用语法来描述横切点

AspectJ 使用语法来描述横切点

图 1:AspectJ 使用语法来描述横切点

Pointcut Designator

在面向方面的程序设计(AOP)中,许多事件类型能够触发一个建议的实现。事件,例如方法或者构造器调用,类或者对象初始化,以及异常,这些都是有效的 AOP 触发器。为了区别事件的类型,AOP 使用 Primitive横切点 Designators (PPDs)。在上面的例子中,“实现”指示者只激活和使用“签名”的方法的实时实现相关的连接点。

签名

在方法调用期间,签名声明了被传递的参数。

关键字

关键字总是等同于“pointcut”。

Access Specifier

Access Specifier 声明了访问一个函数或者方法的级别。

定义过程扩展的一个被提议的语法

上述用于描述横切点的方法已经被证明是有效的,但是目前并没有一种类似的方法可以用来描述过程横切点。我将讨论造成这种缺乏的个中原因,并且在后面的 “RMC 愿望列表”一节中提供一种可能的解决方案。如果您对 AOP 的实际和实践应用程序十分感兴趣的话,您可能希望继续下去。对于狂热的求知者来说,我现在就将提供用于描述过程横切点 的被提议语法的概述,这些可能会在今后通过过程创作和制定工具被实现。

下面的表2中所显示的语法并不是一个工业标准,而是我自己试图提供的一个不需加以说明的符号:

表 2:笔者提议的描述过程横切点的语法
pointcut RUP_Element_set processExtension(): trigger (RUP_Element_Template), where:
processExtension()横切点名称
RUP_Element来自 RUP 元模型的一个元素
RUP_Element_setRUP_Element 元素的集合
pointcutName任意的横切点名称
trigger横切点指定者
RUP_Element_Trmplate过程元素模板

“RUP_Element”表现了 RUP 元模型的一个元素,而“RUP_element_set”表现了一个元素集。Process-pointcut 指示者根据程序设计域的不同而不同。在其他选项中,pointcut 指示者可能包括“initial_step”、“initial_task”、“initial_iteration”、“input_to”、“final_step”、“final_task”、“final_iteration”、“output_from”、“output_is”、“where_used”和“where_declared”。

我将在本文后面关于使用 RMC 实现 AOA 的讨论中阐明“RUP_Element”、“RUP_Element_set”和“RUP_Element_Mask”的含义。

过程扩展定义模板

过程扩展定义模板提供了另一种以 AO 术语描述过程扩展的方法。我将使用下面表3所显示的模板,提供如何将 AOP 概念应用到 RUP 定制中的若个例子:

表 3:扩展定义模板
概念实现
Concern(关注点)<定义一个关注。一个关注就是一个简单的过程扩展用例,例如“A RUP PM Role has inadequate responsibilities”、“A program director wants tighter control over projects”或者“Insufficient vendor communication” >

<提供一个对关注和被提议的解决方案的简短的描述 >
Join Point(连接点)(s)<提供一个对新的或者更新的过程元素横切过程情况的简要总结 >

<提供一个连接点的列表 >
Pointcut(衡切点)(可选)<使用过程横切点定义语法来定义合并连接点的横切点 >
Aspect(方面)<勾画一种在 RMC 中分组过程方面的方法。该方法通常将使用一种 RUP/RMC 扩展技术(更多详细内容请参见本文后面的“RMC 过程扩展”小节 >

< 提供关于 RMC 方法的包装元素,这些元素包含方面的实现 >
Advice(建议)<选项一:撰写方面的完整实现。如果需要更强大的实现工具,就要以本地格式有效的链接到文档 >

<选项二:提供一个方面实现的轮廓。简要的描述新的和扩展的内容元素。方面的详细实现将被延期到 RMC >

<选项三:在 RMC 中提供到方面实现的 URL >

这个模板能够在现实的过程定制和裁剪项目中被用作描述过程扩展。模板自身就是一种 RUP 指导,它必须被包括在扩展的过程描述中。

当变化必须发生在过程中的许多点上的时候,就必须制作过程描述的多个部分,此时您将看到使用面向方面的处理方法(AOA)的最大好处。然而,您应当使用过程扩展模板来描述所有潜在的过程变化,包括那些目标是过程描述中的一个单独位置而非横切的变化。如果遵循这个建议,过程工程团队成员和使用一个扩展过程的项目团队就可能从暗示声明的一致性中得到好处。

在解释过基本的 AOP 概念之后,我将讨论您如何能够将它们应用到一个 RUP 定制中。

面向方面的程序设计(AOP)的概念和例子

下列 AOP 的例子使用普通的程序设计术语,包括“程序”、“系统”和“模块”。我将突出被提议的概念,例如“过程”、“行为”和“任务”,它们能够被用作在 RUP 中扩展过程方法学。

横切关注

“横切关注”是一个程序(过程)中的一个方面(部分),它影响其他的方面,并且不能从系统(过程、行为、任务)中被完全独立出来。将一个新的方面插入到程序(过程)中,情况也是如此。

日志记录是 AOP 的一个合乎规范的例子,这主要是因为它影响了大量重要的应用程序方法。

AOP 例子:
下面的图2显示了一个具有多个方法的类,其中有些需要存储关于哪些用户访问该方法,以及被转移的资金数额的细节。

Employer
+ updateEmployerFinancialBankAccount() + updateEmployerFinancialPaymentMethod() + updateEmployerFinancialRateGroup() + updateEmployerGeneralCount() + updateEmployerGeneralAddress() + updateEmployerGeneralStatus() ...

图 2:一个雇主类

RUP 例子:

一个“活动”(以前的工作流程细节)由多个“任务”(以前的活动)组成,其中有些必须在任务完成时贡献一个过程“交付”(一包用于交付项目涉众的工作产品)。

连接点

“连接点”是程序源代码(过程描述)中一个明确定义的点,在那里关注横切了程序(交付过程)(并且扩展可能在此处发生)。对于一个有利的 AOP 方法来说,用于单独一个关注的多个连接点必须存在。

AOP 例子:
"当一个影响雇主财务的方法被调用"

RUP 等价物:
"在迭代的开端"
"当一个任务修改了迭代计划工件"

衡切点

一个“衡切点”是一个被用作程序声明和分组连接点的构造。衡切点允许您明确的引用程序代码(方法内容和过程)中的多个连接点。AOP 实现通常使用模板语言声明连接点。

AOP 例子:

pointcut employerFinancialUpdates(Employer e, User u): 
	call (public void updateEmployerFinancial* ());

“employerFinancialUpdates”横切点是指那些被调用的以“updateEmployerFinancial”作为名称开头的方法。

RUP 等价物:

横切点 RUP_Element.BasicMethodElement.Task_set outputArtifactIsIterationPlan ():
output_is (RUP_Element.BasicMethodElement.WorkProduct.rup_iteration_plan)

这个横切点被称作“outputArtifactIsIterationPlan”,它描述了修改 IterationPlan 产品的任务(连接点)。

这些限定词名称将在本文后面关于 RUP 元模型的讨论时变得更加明确。

您可以采用一种更加宽松的方法来描述横切点,使用上下文无关的描述。例如,上面显示的横切点 能够被描述为:“找到所有修改 Iteration Plan 产品的任务”。这句提出了过程工程师识别那些必须关注和潜在扩展的任务的一个适当的需求。

方面

在 AOP 中,一个“方面”俱是一个封装特定关注行为的结构(通常为一个方法、模块或者类)。

AOP 例子:

public aspect logTransaction{pointcut employeeFinanceUpdates(Employer e, User u) : 
call(public void updateEmployerFinancials* ()) & args(e, u); after (Employer e) 
returning : employerFinanceUpdates(e, u) {< Advice >} 
}

<Advice> 的实现提供如下。

RUP 等价物:

Extension Work Product (Artifact, Deliverable)
Extension Activity (Task, Activity, Iteration, Phase)
Extension Role
Extension Step
Extension Capability Pattern
Extension Delivery Process

RUP 例子:
"Rationalization phase" (extended phase)
"Program update memo" (extended artifact)

建议

“建议”就是一个解决关注的额外行为的物理实现。

AOP 例子:

System.out.println("\t>User : " +u.getFullUserName() + " has made a financial transaction through "); System.out.println("\t>method " + thisJoinPoint.getSignature());

这个实现代码打印出访问方法的用户的名称和方法名称。

RUP 例子:

该任务的目的是:

  • 识别完成事件的一个用例流程的类;
  • 将用例行为分发到那些类中,通过分析用例实现;
  • 识别类的责任、属性和关联;
  • 标注体系结构机制的用法。

为了更加完整的回顾 AOP 方法,请您参考本文最后“引用”一节中所提供的资源。

通过 RMC 实现 AO 扩展

实现一个建议到一个基本模块的过程被称作“编排”。今天,编排的 AOP 实现的使用范围从源级的编排(典型的是使用预处理程序),到装入时间和运行时间的编排(通常是使用智能中间件平台)。运行时间编排的例子包括 AO-ready 应用程序服务和虚拟机。

由于 RMC 并不包括一个过程实时环境(我将在“RMC 愿望列表”小节中讨论这个限制),所以它只能支持源级的编排。在这种情况下,“源”就是将要被扩展的一个交付过程的一个实例。

实现的先决条件

尽管对于一个面向方面的处理方法(AOA)的实现来说没有确定的要求,但是公司应当考虑使用一种过程创作工具来保持其现已存在的实现过程的描述。RMC 是一个标准的过程定制工具,它能够支持特定方法插件程序的创建和过程配置。RMC 中的一个过程模型通过提高对现已存在的实现过程的易管理性和可理解性,增加了 AOA 实现的目的。

RMC 的导入功能允许您通过 Rational Process Workbench 在创作之前将工作带入到工具之中。

RMC 过程扩展功能

RMC 支持若干过程扩展技术:

过程插件程序

RMC 插件程序(以前的 RUP 插件程序)提供了一种构建和贡献定制过程扩展的标准方法。该插件程序方法使用模块化体系结构,它能够支持通过新的方法和技术指导,对现已存在的方法内容加以扩展。您能够在一个类似 Lego 的方式中使用插件程序,集合新的过程,修改现已存在的过程。大量特定的插件程序可以从 IBM 及其商业伙伴,以及开源社区中获得。随着方法配置的开展(下面将会讨论到),插件程序还为模块化现已存在的过程内容提供了一套解决方案,并且允许您立即创建过程扩展。

方法配置

方法配置在方法内容和交付过程之间形成了一个薄层。它可能横跨多个插件程序,仅包含需求内容的单一事件。方法配置使得从逻辑构建块中集合过程变得容易,而逻辑构建块可能既包括内容也包括过程。使用方法配置,您能够将交付过程发布为一个适于导航的 HTML 结构,以便团队能够对它进行访问。

内容可变性

当从现已存在的方法内容中创建新的方法内容时,被构建在 RMC 之中的内容可变性机制变得唾手可得。该工具通过在整个内容库中自动繁殖改变来支持内容更新和置换,并且在交付过程中将内容更新。这一特性使得横剖关注(下面将会讨论)的设计时间实现变得简单化,这是因为实际的内容修改在一个单一的地点发生,而工具将负责编排的处理。

由 RMC 所提供的三个不同的可变性模式是:贡献、扩展和置换。

当在“贡献”模型中被使用的时候,一个元素能够将新的内容添加到一个基本元素之中,而无需直接修改现任何一个已存在的性质。当补充使用贡献模式的时侯,基本元素在方法配置中伴着被添加的内容浮现出来。

使用“置换”模式,您能够修改元素的各个部分而不会影响到内容库中的初始的元素定义。“置换”对于开发新的插进程序是最有用的,它能够隐藏或者改变基本内容的各个方面。置换一个元素的结果是创建出一个具有不同内容的新元素,但它仍然被所有相同的交付过程和功能模式所引用。

“扩展”允许一个扩展元素继承基本元素的特性。在这个场景中,在方法配置中将出现两个元素——一个基本元素和一个扩展元素。“贡献”模式将新的内容添加到基本元素中,并且允许在不修改基本元素的情况下对交付过程或者性能模式的上下文进行修改,与之不同的是,“扩展”模式创建了一个全新的元素,它在引用基本元素的同时贡献出新的内容。

功能模式

“性能模式”是一个小型过程,它定义了一组可用的活动。来自基本 RUP 的性能模式的例子包括“基于用例的需求管理”和“有效构建”。RMC 过程的可变性允许您在一个性能模式和交付过程中构建另一个性能模式。当这个性能模式被构建好之后,任何影响该结构的变化都会自动的被传播到所有引用过程和性能模式中。

过程贡献

RMC 过程的可变性允许您创建定制的交付过程,它仅包含针对现已存在的交付过程和性能模式的微分变化。由于它并不要求变化同方法配置相适应,所以这个特性难以对交付过程制造变化。您能够通过使用复制或者扩展这两种方法之中的一种,从性能模式和其他交付过程中创建过程贡献。

“复制”的方法允许您从其他的过程或者性能模式中复制内容。复制并不是一种动态的工具,这是因为在基本内容元素和被创建的目标交付过程或者性能模式之间不存在链接。

“扩展”的方法提供了一种动态扩展过程的方式。当一个过程被扩展的时候,所有对于基本过程或者性能模式的变化都会自动的被传递到目标过程(使用者必须手动初始化同步),它提供了一种很好的向上传达和维护目的的手段。这种方法的一个局限在于所有被关联的内容都在得出的结果过程中以“只读”的形式出现,它们不能够被直接修改。

综合搜索

RMC 搜索功能在 AOA 实现期间可能会对过程工程师给予很大的帮助。下面的图3显示了 RMC 的上下文相关的搜索性能,它允许您在一个由过程和方法内容所组成的选择范围内寻找一个实体。请注意图2中所显示的范围元素有些类似于 RUP 元模型中的元素,它并不认为许多搜索必须发生在方法或者过程内容的选定部分。

RMC 搜索对话框

RMC 搜索对话框

图 3:RMC 搜索对话框

RMC 适航性

RMC 的适航性有助于您识别和跟踪内容的依赖关系。Element Preview 标签显示了作用于一个给定 RUP 元素的所有关系。在一个 RUP 扩展练习期间,适当的制定一个扩展目标往往是必要的。例如,下面的图4描述了修改一个工作产品时您需要了解的元素依赖关系。

RMC 中的元素依赖关系

RMC 中的元素依赖关系

图 4:RMC 中的元素依赖关系

RUP 元模型

为了将过程关注(扩展)描述为方面,并且潜在的创建过程横切点(参见下文),您必须对 RUP 结构有深入的了解。该工具结构是基于 IBM Rational 的 Unified Method Architecture (UMA) 的,它是从基于 Object Management Group (OMG) Software Process Engineering Meta-model (SPEM) 1.1 的 RUP 2003 计划发展出来的。该工具结构将最近的 SPEM6 标准(2.0)以及其他过程(例如 IBM Global Services Method 和 SUMMIT Ascendant)中的元素考虑了进来。

RUP 元模型的一个分级表示法的例子如下面的表4所示。这个结构是基于 RMC 元素的自然分组的,并且适合于任何的 AOA 实现。

表 4:RUP 元模型的分等级表示
第一层第二层第三层第四层第五层
RUP_Element
BasicMethodElement
Role
Work Product
Artifact
Deliverable
Outcome
Task
Step
ProcessElement
Activity
Iteration
Phase
Capability Pattern
Delivery Process
CategorizationElement
Discipline
Domain
Roleset
Tool
MethodPackagingElement
Plug-in
MethodPackage
ContentPackage
ProcessPackage
ProcessComponent
GuidanceElement
Guideline Concept
Whitepaper
Checklist
ToolMentor
Template
Report
Estimate
Example
Roadmap
TermDefinition
Practice

如果您希望获得关于 RUP 元模型的更加全面的描述,请参见:http://www.eclipse.org/epf/

使用 RMC 进行过程扩展

过程扩展捕获是 Process Tailoring 规程的一个核心部分,如下面的图5所示。关注捕获通常发生在三个初始过程活动期间:Process Analysis(以关注识别、分析和捕获的形式)、Process Modeling(以连接点识别和横切点 声明的形式)、以及 Process Description(以方面定义和建议撰写的形式)。在 RMC 过程配置被用作一种从若干不同的插件程序中合并内容的技术的情况下,扩展方面的实现可能在 Process Configuration 活动期间继续。

在 Process Tailoring 规程中的关注定义

在 Process Tailoring 规程中的关注定义

图 5:在 Process Tailoring 规程中的关注定义

下面,我向您提供了如何能够使用 Extension-Definition 模板来捕获 RUP 定制需求的若干例子。

需求:在一个可重复活动的包装上生产一个工作产品

RUP 迭代是可重复活动的一个经典的例子。一个基于 RUP 的项目可能具有一次(通常是一个坏的实践)到一打或者更多的迭代。

通常,在一个迭代的开始生产一个新的工作产品是必要的,例如当涉众希望收到一份“迭代报告”或者“集成数据模型”或者参与到一份“产品示范”中的时候,当大量新的功能被放到产品中的时候。下面的表5显示了“迭代报告”如何使用 Extension-Definition 模板被描述:

表 5:一个使用 Extension-Definition 模板的“迭代报告”描述
概念实现
关注点迭代报告给一个项目发起人

问题是:
项目发起人希望牢牢控制项目的进展和实现。

需要是:
一旦项目的迭代结束,项目就必须向项目发起人交付一份操作实现和技术风险处理的总结报告。

解决方案是:
迭代将产生一个新的被称作 Iteration Report 的文档。该文档将会在一个迭代的最终任务中由项目管理者创建。
连接点扩展必须被用于所有的项目迭代中,包括启始、精化、构建和产品化中的迭代。由于每一次迭代的交付都是不同的,所以目标就是将过程任务看作是所有迭代一样的,并且 Project Manager 是同一个 Primary Performer。

Iteration Report 产品将会由位于 Manage Iteration 活动中的 Assess Results 任务生产出来。尽管该任务已经输出了 Iteration Assessment 和 Status Assessment 产品,但是这些并没有完全满足涉众的需要,也没有能够在不影响他们定义的消费者的前提下进行修改。Iteration Report 产品将主要处理若干独特的方面,并且将包含关于该项目的敏感的信息,而现已存在的的产品将仍然扮演内部项目交付的角色。
横切点(可选)pointcut RUP_Element.BasicMethodElment.Task_set createIterationReport(): final_task (RUP_Element.ProcessElement.Iteration.*)

这一横切点引用了一组 RUP_Elements(任务),它们是各自迭代中的最终任务。
方面
  • 迭代报告(新的工作产品)
  • 评估结果(扩展任务)
  • 创建迭代报告(评估结果任务中的新步骤)
该方面将被保存在 extended_org_rup_content 内容包中。
建议迭代报告(新的产品模板)
  1. 迭代性能概述
    • 计划的性能
    • 达到的性能
    • 两者不相同的原因
  2. 迭代风险管理
    • 在迭代开始之前识别风险
    • 在迭代期间识别风险
    • 风险缓解应用程序分析
  3. 团队的优势和缺点
  4. 结论和建议
    <提供进一步的产品指导>
    创建迭代报告(评估结果任务中的新步骤)
    <提供步骤描述>

需求:当一个工作产品改变时实现一项操作

如下面的表6所示,这是一个工作产品改变的时候需要实现一项操作的例子,此处一个内部的或者是外部的涉众希望立即得知关于计划改变一个或者大量工作产品的消息。另一个例子发生在您希望在分离的文档中跟踪项目的关键工作产品的变化。

表 6:Extension-Definition 模板被用来描述需求,在一个工作产品变更时通知涉众
概念实现
关注同项目涉众(供应商)进行适时的合作。

问题是:
缺乏同供应商之间适时的协作导致增加项目开支。

需要是:
大多数重要项目产品的改变必须迅速同参与项目的供应商进行沟通。

解决方案是:
将 Software Architecture 文档、Software Requirements 规范以及 Software Development 计划的所有改变通知供应商。当这些产品中的任何一个发生改变时,通过电子邮件立即通知供应商。询问他们的反应,然后作出相应的操作。
连接点为了对这三种产品的改变作出反应,任务生产就必须被扩展。下列任务创建或者修改了上面提到的产品:

对于 Software Architecture 文档来说:
  • 体系结构分析
  • 描述分发
  • 描述实时体系结构
  • 识别设计机制
  • 合并现已存在的设计元素
  • 优先级用例
  • 构造实现模型
对于 Software Requirements 规范来说:
  • 编译软件开发计划
  • 定义监视 & 控制过程
对于 Software Development 计划来说:
  • 详细定义软件需求

上面列出的任务创建或者更新了 Summary of Changes _ <产品> _ <日期> (新的产品),此处 <产品> 就是被更新的工作产品的一个名称,<日期> 就是当前的日期。被称作 Notify Vendor By E-mail and Receive and Communicate Vendor Acknowledgment 的新的步骤将被添加到任务中,以便生产所需要的产品。上一个步骤将包含同供应商沟通的指示。下一个步骤将包含顺应供应商反应的处理程序。
横切点 (可选)pointcut RUP_Element.BasicMethodElement.Task_set notifyVendorOfChangesByEmail(): where_used (RUP_Element.BasicMethodElement.Artifact. rup_software_architecture_document)

pointcut RUP_Element.BasicMethodElement.Task_set notifyVendorOfChangesByEmail(): where_used (RUP_Element.BasicMethodElement.Artifact. rup_requirements_specification)

pointcut RUP_Element.BasicMethodElement.Task_set notifyVendorOfChangesByEmail(): where_used (RUP_Element.BasicMethodElement.Artifact. rup_software_development_plan)
方面
  • 变更总结(新的工作产品)
  • 通过邮件通知供应商(上面列出的每一项任务中的新步骤)
  • 供应商(新的角色)


该方面将被保存在 extended_org_rup_content 内容包中。
建议被影响部分的变更总结 <产品> <日期>(新的产品模板)
指定了被改变所影响的原始档案

老内容
提供了修改之前的内容的备份

新内容
提供了新内容的备份

供应商注释
供应商将在此处提供反馈意见

通过邮件通知供应商(新的步骤描述)<在此处提供步骤描述>

沟通并协调供应商反馈(新的步骤描述)<在此处提供步骤描述>

需求:在过程生命周期期间置换一个工作产品

用一个定制产品取代一个标准的工作产品是 RUP 裁剪期间的一个通常需求。例如,如下面的表7所示,有些公司希望生产一个“Architecture Blueprint”来代替 Software Architecture 文档。虽然这通常涉及一个简单的名称改变,但是这个需求有可能完全改变文档的结构以及它同其他过程元素之间的关系。

表 7:Extension-Definition 模板描述了用一个定制产品替代一个标准工作产品的需求
概念实现
关注点Software Architecture Document 并没有完全符合公司现已存在的标准。

问题是:
现已存在的公司标准要求 Architecture Blueprint 由所有实现项目生产。公司必须同其以前的项目中所使用的产品格式相匹配。另外,要进行分析和设计的话,这个格式还要包括管理、业务分析和项目管理等方面。

解决方案是:
使 Software Architecture 文档的结构符合现已存在的公司标准。将现已存在的 Software Architecture 文档产品重新命名为 Architecture Blueprint。
连接点Software Architecture Document 是中心产品,它被 RUP 生命周期期间的多个任务进行更新和消费。被引介的关注可能通过在交付过程中置换产品定义而不是产品用法被解决。

Software Architecture Document 将被 Application Blueprint 文档置换,使用 Replace 可变性模型允许在交付过程中保留文档的用法。Application Blueprint 文档将被赋予一个全新的结构,它既包括新的部分,也包括基本 RUP 中的部分。
横切点(可选)RUP_Element.BasicMethodElement.Artifact_set replaceSoftwareArchitectureDocument(): where_declared rup_software_architecture_document
方面
  • Architecture Blueprint(置换工作产品)
该方面将被保存在 extended_org_rup_content 包中。
建议Architecture Blueprint
<提供文档的描述>

RMC 愿望列表

过程制定引擎

尚没有工业标准的 RUP 运行环境,也就是说,尚没有一个支持管理和监控基于 RUP 项目的状态的应用程序。通常这项任务由项目管理和组合管理工具来实现,鉴于所有的 RUP 活动将它们的状态有规律的报告给锚定项目管理过程,然后更新组合管理过程。

IBM/Rational 过程包括一个用于运行 RMC 生成的交付过程实例的环境。Agile(敏捷)运动的某些支持者可能会站出来反对了;然而,我经常遇到这种特性的需要,甚至是在一个最小型的项目中。

分等级搜索

要成为一个真正有价值的 AOA 过程工程师,现已存在的搜索功能就必须被扩展为完全支持 RUP 的元模型。尽管 RMC 搜索对话(参见图3)确实区分了方法内容和过程,但是它并没有通过装载到工具之中的内容对分等级的搜索提供足够的支持。

举例来说,一个查询,或者使用一个搜索“向导”UI,或者使用横切点 定义语言被构建,都将允许用户通过指定的标准实现分等级的搜索。一个类似的功能有助于横切点 调试用途。

用于定义横切点的嵌入式语言

为了完全支持动态 AOA 编排,RMC要求一种声明过程横切点 的嵌入式语言。横切点使用一个模板语言来撰写,而不是使用纯文本来撰写,以便生成实时的过程事件。当然,这样一个动态的语法仅仅在过程制定引擎或者分等级搜索功能充分发挥优势的情况下是可能的。

面向方面的处理方法(AOA)是否敏捷?

在全世界的 IT 环境中,Agile(敏捷)运动正在获得越来越多的关注,引介另一种形式的思想有可能刺到某些从业者的痛处。尽管我分享了许多敏捷的原则,我更愿意明确区分愿望和需要,良好的记录过程描述有可能减少许多实现项目中固有的模糊性——特别是,如果哪些项目是由许多涉众组成,各个涉众分别怀有各自需要的时候,或者是团队成员在技术和/或方法方面具备有限的专业知识的时候。虽然敏捷的方法在一组经验丰富的、高度动机的、或者连接非常紧密的个体中能够工作的很好,但是在其他某些情况下却并不一定如此。正在进行的 EPF 努力描述由 统一过程(Unified Process (UP))6 形成的敏捷将涉及包含和联合定位团队来开发业务应用程序。在完成之后,该过程和 AOA 将会更加完善。

敏捷从业者不应当高度关心涉及明确叙述和捕获过程扩展的形式。例如,在多个比实际交付过程更加详细的页面中捕获扩展就是不必要的。您可能选择遵从该策略来捕获由 Active Stakeholder Participation 提议的扩展,也就是说,较早的涉及涉众。或者,您也可能选择使用 Inclusive Modeling 技术,如果它们能够更好的为简明而清晰的描述关注或者其实现这一目标服务的话。您甚至可以选择将使用任何技术描绘的图表嵌入到过程扩展定义模板中。不管采用何种方法,如果您没有能够捕获到扩展的足够细节,或者根本就没有捕获到扩展的话,实现团队就有可能面临如此之多的选择,他们将无法使用创建的扩展为项目带来好处。

尽管捕获扩展尚需要完成一些工作,但是相比起修补由于错失重要的实现活动而产生的问题来说,这已经是最小限度的工作量了。

总结

面向方面的程序设计(AOP)已经被证明是一种构建程序扩展的灵活的方法。它的原则可以通过本文中所描述的方式被应用到构建过程扩展中。一个过程工程任务需要对 RUP 分类法(元模型)具备很好的理解,以及具备相互兼容的扩展机制。本文提供了一个模板,它能够以一种兼容的和可重复的方式被用于捕获内容和过程扩展。为了制作度身定制和更加有效的实现过程,充分利用嵌入到扩展机制中的工具的优势,公司就必须在 RMC 中构建一个已经存在的过程的模型。RMC 及其免费的搭档 EPF 都是完成此项任务的候选者,这是因为它们包括了一套全面的方法内容库和灵活的扩展模式,并且它们都是基于 SPEM 标准的。

致谢

衷心感谢 Scott W. Ambler 富有洞察力的评论和思想。

注释

1IT Service Management - ITIL®

2PMI 网站

3Rational SUMMIT Ascendant

4Eclipse Process Framework (EPF) 项目

5 RUP/RMC 插件程序为实现过程扩展提供了一个标准方法。

6 请参见 The Agile Unified Process (AUP) 获取更新。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational
ArticleID=292433
ArticleTitle=通过 Rational Method Composer 使用面向方面的 RUP(Aspect-Oriented RUP)
publish-date=02152008