| UML软件工程组织 | |||
| |
|||
|
|||
理解 RUP 角色
2008-03-20 作者：Anthony Crain 来源： IBM
引自Rational Edge：本文提供了一个简单的方法以概念化并回顾多个在IBM Rational Unified Process, 或称作RUP中定义的角色。另外，它还对如何使用Myers-Briggs Type Indicator将角色分配匹配至人物类型提出了建议。 你是否认为 IBM Rational Unified Process, 或称作 RUP, 定义了超出你可以记忆的角色数量？阅读下去！你将会发现一个可以使记忆这些任务变为一件很容易事情的隐藏模式。你还将发现使基于组员个人类型的任务分配获得成功的指导。 起初，努力使你的思维围绕于RUP中大量角色周围，看起来会是令人非常畏惧的。但是，存在一种记住 RUP 角色模式，这个模式是从迭代式开发中降低最重要的风险之一的方法中衍生出来的：在任意指定迭代中要清楚需要着重于什么。 包含于RUP中的软件开发迭代式解决方案促进从业者采用两种观点。首先，它促进团队理解整体解决方案，然后在每一次迭代中基于上一次迭代重新评估并调整整体解决方案。第二，在每次迭代中，它促进团队主要着重于解决方案的一个方面 ―― 每次后继迭代构建解决方案的一个方面，直至整体完成。 对应于这两个方面的两种视角通常被称为广度视角与深度视角。在一个迭代式项目中，你首先集中于广度视角，然后精选一个方面以集中于深度。分离的广度与深度，正如我们在迭代式开发中所做的那样，使得一个项目可以更灵活地被更改。不仅仅是广度视角可以更容易的建立，而且当更改来临时，我们可以微笑，耸肩，并且很轻易的调整广度视角。 相反，一个纯粹的瀑布式解决方案将同时集中于深度与广度视角，并且从不回退。但是，如果你想试图一次完成所有的广度与深度工作，这个工作将需要更多的时间来完成，它将更冗长并且以后难于更改，它也许将在很多地方被错误的导入。如果项目团队在工作后期被强制调整项目广度，那么许多深度工作将被废弃。 换句话说，对项目管理规程，一个瀑布式项目领导者会建立一个一或二年的，包括全部时间范围的计划，然后详述整个计划中所有的任务。这种计划当改变不可避免或需要对其做出调整时将很快的崩溃。 相反的，一个迭代式项目领导者将广度从深度中分离开，为广度视角建立一个粗颗粒度的计划以显示各个阶段，列出业务用例，并显示出当项目成熟时如何对评估进行更改。深度视角是对每个单一迭代更细节的计划，也许是在整个持续时间中的六个星期。这个计划将比试图猜测在一或二个星期内的所有项目细节的计划更准确且不容易导致错误。 这个迭代的广度及深度解决方案对所有九个RUP规程都有效，而不仅仅对项目管理而言。 RUP中的广度及深度角色RUP角色定义与分离广度和深度的概念相一致。进行广度工作与进行深度工作的成员类型差异很大。广度工作速度快，不精确并且有弹性。深度工作任务需要更多的时间，关注于细节，并且需要能够得到更好的质量。 RUP九个规程中的每一个都有一个集中于此规程广度的角色，以及另一个不同的集中于此规程深度的角色。一旦你理解了基本原理，记住这些角色将变得非常容易。表1列出了每个RUP规程及其所对应的广度及深度角色，并粗略解释了角色的功能。我仅仅依照广度/深度模式就可以从记忆中构建几乎整个表格。
使用MBTI个性类型进行RUP角色分配我的同事，Ruth Nantais，是一个杰出的项目经理，他将Myers-Briggs Type Indicator （MBTI）介绍给我。现在我鼓励我的客户和学生使用这个工具以发现他们自己的个性类型，并且应用这种知识去决定他们是否适合广度工作还是深度工作。他们也可以使用这个工具去理解如果他们被分配一个并不适合他们类型的角色，等待他们的将有什么问题。 MBTI的第二个方面对人们是直觉的（N）或是感觉的（S）提出建议。直觉类型的是大局观思考者，他们可以使用他们的“内部感观”迅速做出决定。这些人也许更适合进行广度工作。感觉类型，相反的，趋向于使用他们五种感观去收集能够做出决定判断的信息。他们的工作趋向于更精确，更适合于深度工作。 MBTI的第四个方面对人们是 判断者 (J) 还是 感知者 (P)提出建议。判断者趋向于通过进度表更好的工作，并且对闭合空间有非常强的需要。后一种对深度工作来说极为重要，它必须足够完备以为后续工作提供基础服务。感知者，相反的，喜欢更自由的区域，趋向于更有创造力，不需要同样的闭合区间。这些特征更适合于广度工作，它需要对大局更快浏览的能力，以及对其进行通信的能力（典型的使用UML），但是需要承认的是，这种描述并不完备，并且可能随着每一次迭代中深度工作的完成而需要进行更改。判断者趋向于建立更完备的，高质量的工作，而感知者许趋向于更快速地工作，并且在需求要变更时能够更有弹性地进行更改。 因此，基于上述观察，我们可以做出结论， 理想的广度工作者将是NP，同时理想的深度工作者将是SJ。一个NP将可以更快速而有效的建立广度视图，并且当有需要时可以更改这个视图。一个SJ将可以确保驱动后续工作的深度视图更为完备与精确。 现在，这并不意味着落入这些MBTI种类范畴内的人将被阻止从事特定的角色。如果他们具有强烈的从事这些任务的愿望，他们将能克服他们也许要面对的挑战。作为一个团队成员，意识到你的MBTI轮廓可以帮助你聚集能量，并且当你被分配至一个相反的角色时可以赔偿个性趋向。 但是，当你的团队分配人们至RUP角色时，意识到如果你分配NP去完成深度任务，他们也许会有不着重于细节的趋势。他们需要比SJ更努力的集中精力以得到同样的质量等级，而另一些也许会在他们正确完成之前数次拒绝他们的工作。 在不重要的方面，如果你分配SJ至广度工作，所带来的风险是他们将会花费更多的时间以完成任务，主要是因为他们难以保持抽象在一个足够高的级别上。当他们努力使他们的工作更“完备”时，他们也许会持续至错过截至日期，并且在他们的广度视图中包含了过多的细节内容，使其难以更改。 在最近几年中，为了使 UML（统一建模语言) 适合软件过程模型 (SPM) 的特定需求，研究人员已经做出了一个重要的研究成果。结果，已经形成了一些 UML Profiles 和像 SPEM 或 RUP 的元模型。在 IBM Rational Process Workbench (见 资源)中定义的过程建模语言(PML)，仅使用完整的建模语言的一个小子集，如UML定义。RPW 在一个概念的框架 (RUP 元模型) 里执行过程建模；这个框架利用 UML(stereotypes)提供的轻量级扩展机制帮助进行编码，以定义RUP Profile。
值得一提的是，像SPEM 元模型一样，RUP 也被定义为 UML 元模型的一个外在扩展。然而，当重量级扩展在元模型层次确保适当的语言定义时，它转换成UML预定义包以确保和UML一致。 显示RUP预定义包中的描述性原型定义的一个例子。注意关联的特殊类型，它完整提供了被原型化类的参考及元类（metaclasses ）的其它参考，因此 UML 元类（metaclasses） 可以适应特定的域，如 SPM。
基于模型的过程工程过程建模的目的是定义一个过程模型，以使它能为创建过程配置提供蓝图。用过程元件描述过程，而我们使用类的 UML 元件表示角色，以及在特定的过程中涉及到的产物；并且我们使用操作来表示它们的活动及协作。 举例说明在RPW 中用于详细说明过程模型概念的过程组件语义模型。
过程模型是所有过程元件的容器。每一个基本过程或者插件，正好对应一个过程模型。基本过程采用自我包含的过程模型，就是说不扩展任何其它过程模型，而自己表示一个完全的端对端过程。另一方面, 过程插件作为基础过程或可能的其它插件扩展来建模, 而且它们自己只详细说明了那些不同于它们的基本过程的元件。 一个过程组件由相关的过程元件组成，并且成为配置时的过程可选择单位。一般来说，过程组件中的元件都紧密相关。对于过程组件，要引用其它组件中的元件， 需要在它们之间建立稳定的UML 依赖关系。过程组件可以包含子组件以形成组件系统 过程元件 表示结构和过程定义的行为。它们使用 UML 类及操作定义，采用原型以保留它们的特定含义。除此之外，在元件间的多样化联系采用关联定义，也采用原型来记录特定类别。 说明由RPW验证的过程元件片段，及它们之间如何联系。
上面的图表乍看起来可能觉得复杂，现在说明如何看懂它: 图的 " things " 是用来建立我们的过程模型的过程元件类型。在一定程度上，这些是过程建模语言的术语。 每个过程元件类型定义它如何建模(操作或分类) 并如何与其它的过程元件类型相关联。举例来说，角色元件作为分类器被建模，它们定义操作以表示它们的行为及步骤。 如 所举例，RUP 架构被结构化以支持过程组件化。松散的让过程工程师可以通过域和使用特定方针来扩充RUP框架，从而配置他们在给定项目或项目类型中需要的过程集。在 RUP 中，创建这样配置的基础是 RUP 插件技术。RPW 定义了下面二种主要工具，以共同支持在开发过程插件中涉及到的行为。 RUP Modeler，IBM Rational XDE的附加项，允许过程工程师采用UML 标记图形化建模。这一工具认可且强制实行RUP元模型，并支持 SPEM 规约以定义过程建模的概念。 RUP Organizer，一个独立应用程序，为满足过程模型元件的关联过程提供工作空间。RUP Organizer 的关键功能是过程元件的树形表示，称为布局，以及支持拖放定位及该结构的文件关联组织。 过程插件建模新的过程模型的开发总是从分析行为开始。一般来说，最初分析的输入是那些人们正在使用的过程知识。该知识可以由用例图记录，每个用例表示进程中的行为及这些行为运行时涉及到的操作。依据这种方法，用例成为过程片段的半正式的描述，稍后将会作为过程定义的基础。 中的剪裁规范，为项目和采用RUP组织的PEP基础描述，提供了一个高层次的视图。 它显示在工作流细节（WFDs）之间的数据流依赖关系。然而，并非这里所有的控制流都被严格指定，可能有所差异。例如，过程建模者可能认识到分析结果是不足或矛盾的，并要求过程工程师立刻返回这个工作区。
我们的案例研究的要求是尝试半正式地定义结构方面的一套原型COTS-based system (CBS)。这里提议的CBS模型基于那些在文献中发现的，描述一组有限的概念。目的是扩展 RUP 并提供一个基于风险的螺旋形框架来适应CBS概念。 显示在插件建模扩展RUP过程中涉及到的最普遍行为的简短概览。当你建立结构化的插件模型时，你或者创建当前 RUP没有覆盖的新元件，或者定义已经存在于RUP过程模型的元件的扩展。
既然这第一部分主要关注过程结构方面的建模，我们在大多数时间通过练习课程来使用 RUP Modeler 工具。现在, 在你能够开始结构化插件建模之前，你必须确认所有的必需的应用程序都已经安装。先决条件是:
激活 RUP Modeler 附加功能:
现在，你的 RUP Modeler 已经激活了附加功能，让我们创建XDE 项目来容纳插件模型:
为你的插件创建一个新的模型文件。我们推荐储存位置是rup 文件夹的平级(同一层次)文件夹:
应用 RUP 预定义包到新的模型。如前面所述，RUP 预定义包是一套机制，使UML元模型生成的元类可以扩展，从而它们能适应SPM 域 , 如 RUP:
让我们创建一个新的过程组件 (UML包) ，以容纳我们将为CBS实现过程定义的过程元件：
注意这里给出的模型元件名称对于过程用户（开业者)是不可见的。相反的，它实际是在创作者活动中由RUP组织者给出的代表名字，对发布进程确认进行表面处理。
行为用来定义细致的工作，可以分配到可以为其行为负责的特殊角色。行为的目的通常根据创建或修正产物下定义；声明为从行为上下文的输出参数。为了支持行为，它也可能指定一个产物集作为输入。在我们为新的行为指定输入输出产物之前，先让我们建立对两个RUP 过程组件的可见性，这将检查哪个产物可以用作选择的参数。
高级建模技术从 RPW 观点，为了描述在过程建模中涉及的元件，有两个主要的相关概念: 组合关系和类一般化。这一节关注这二个方面;也是静态模型定义的一部分。 产物可能是原子的或组合的。组合产物由较小的 (不那么复杂的) 次产物构成。在 RPW 里可以通过组合聚集体建模。 让我们把组合应用到我们的EPIC过程模型中，并使cbs_integration_build_plan 元件有助于 rup_integration_build_plan 产物，以此来表达组合产物:
在类之间的另外一个有趣的关系是细分，在 RPW 中能通过继承来模仿。 举例说明你能在 RUP 塑告者里面定义的三种继承关系。
<<rupExtends>>继承建立了一个从子类到它的超类的关系。结果，当过程配置生成时, 两个元件将在发布的web站点显示出来，并生成从子类到超类的链接。 当你想要的时候，使用一个存在的元件扩展:
使用 <<rupContributes>> 继承意谓着把特性及/或行为加入基本的组件中。多等级捐助被累加到最终接收的类( 继承结构的的根) 。当你想要的时候，使用对存在的组件的贡献:
<<rupReplaces>> 继承关系准许你给基本的元件下一个专门化的定义，以替换一般化的元件。当你想要的时候，使用一个存在的元件进行替换:
推荐使用 <<rupContributes>> 关系，因为它为附加的建模方法提供了最好的支持。由于 <<rupReplaces>> 的闯入本性和对其它邻接的关系的强制限制，它成为最 “危险”的关系。 下列的规则提供了指导以帮助你决定替换一般化的影响:
这些规则意谓着，尽管特定元件的模型状态图可能在建模过程中被呈现，但只有被上述的限制因素指定的条件存在时，这些数值才是有效的。 现在让我们实施刚刚描述的概念，并使一个已存在的 RUP 角色成为负责CBS产物代替CBS Integrator 。 RUP Integrator 现在将会对两个产物负责，但是由于我们将不直接地修改一个 RUP 元件，我们将不得不再一次使用捐助:
位于选择列表的符合条件的工作流明细是那些常驻于执行角色的可见范围内的那些。而且，在行为和 WFD 之间的关联是“双方向的”, 可以在任一边上被建立。呈现的 WFD 列表包括“ inbound” 和“outbound”两种 WFD 关联。 Conclusion恭喜! 如果你已经做到这一步，你已经成功地利用 RPW 工具定义了一个结构化的过程模型。在这一部分中我们已经见到如何使用 UML 记号和描述，使用在RUP metamodel中定义的类实例来表示经简单类和操作更高层的概念，来建立我们的过程模型。使用 RPW 为不同的过程概念定义的 stereotype 图标,我们指定了对它们的特殊种类的过程元件。基本上，当我们应用 stereotype 时，我们是对建模工具说话 " 我有一个几乎是类( 或操作，关联，等等)，但是更专业的概念 " 。面向对象范例的表达和UML提供的生成系统，已经证明适用于对过程的结构方面建模 (举例来说: 支持元件元件及其关系)。 我们已经看见 RUP 过程模型本质上是自由形式的设计，并被 RPW 强加入一些额外的限制因素的模型。然而，RPW 并不强迫一般面向对象的建模使用表达来定义过程元件的变量。正相反，这样的元件的使用是受鼓励的，并且它也在过程模型推导被要求。因此，一个过程模型可以包含超出RPW认证的附加的模型元件。例如，为了要提供一个模型的全面产物，定义产物的依赖关系是必要的。 最后, 注意你应该避免通过修改RUP底层来定制RUP，因为你可能不得不在新版本的RUP产品发布的任何时候重建这些定制。通过由插件的方法来定制，你可以减弱从RUP的实现，这样两方面都能独立地改变。 RUP Organizer是IBM Rational过程工作平台产品的一个组件，可以作为一个单独的模块进行工作，也可以嵌入到RUP Modeler/XDE中工作（参见资源）。它为关联过程内容提供了工作平台，使得它们能够按照目标来处理模块从而创建过程资料，这些过程资料能够和下游过程结构合为一体。RUP Organizer最关键的特点在于它能将过程元素按照树状结构展现，这种展现叫做 Layout , 下面的图表说明了过程描述领域内的核心概念的概念性关系。 图1. 过程描述概念
我们注意到，层次性展现事实上能够在它们相应的内容库中得到体现，从而能够保持它们很强的耦合性。这说明每一个过程都能由它的内容库和层次性展现表示。这样，过程插件只能在它的基础过程的环境下，创立一个完全的端到端过程。 RUP 的基础下部组织支持很多使用案例，主要能够认可三种不同的应用场景。过程授权不是RUP基础下部组织职责的一部分，从本质上看，它在这里的出现只是为了根据该过程支持的应用案例来给它定位。图2 提供了一个该结构所支持的使用场景的简单全面的介绍： . 用例模型概述
那些 过程工程师负责定义过程模块，组织过程，并使得过程可进行配置。 项目经理负责创建在他们的项目中可以部署的过程实例。 参与者就是一个用户，浏览一个RUP配置来查看各个过程，考虑各方面综合最优，这些方面包括与查找他或她的任务、当前工件以及当前执行的活动相关的指南。 描述一个结构化插件在组织和描述一个程序插件内容时，会有很多相关活动。但是，图3 显示的是我们会在这个部分中会执行的一些活动。 图3. 组织插件内容的活动
定义那些你需要用来查看和编辑内容文档的应用程序：
如果过程模块从上一次层次化展开文件下载后，有一些更改，RUP Organizer不会被自动选中。它只会读上次保存的层次化展开文件。因此，当层次化展开接受了过程模块的一些变化后，你必须明确地调用Refresh from Model命令。
最初的层次化展开的组织直接反映了RUP建模者定义的根本的过程模块。这些过程元素的缺省排列基本按照该元素在过程模块中名字的字母顺序排列，同时考虑这些元素在层次化展开中被创造或者出现的顺序。然而，一旦在层次化展开中出现，这些元素的顺序可以被重新排列，保存，只要简单地将结点在同类列表中上移或下移即可。同样，注意那些基础RUP层次化展开中，视觉效果上被暗化的结点，这说明这些结点是只读的。同样，我们EPIC插件层次化展开中的平常元素是可读，可被编辑的。 当你开始组织你的插件程序模块时，可能你有一个空的内容库。这样，你会发现，在开始的时候，你将会在RUP Organizer中用相当多的时间来例示已有的RPW模板。 要根据RPW模块来创建新的内容文件：
表示名 是文档在发布的过程结构中所采用的名字，它可在任何时间做改动。而且，如果有可能最好直接使用内容文件夹中的表示名，而不要使用其它的，直接在层次展开结点中说明的名字。同样的，尽量用最简单的名词来命名结构方面，和一个动词——名词的组合来命名一行为或者事件。 开发 (事实上是写下) 过程内容，就目前而言是最花时间的活。然而，如果你已经写下了某种形式的内容。比如白皮书或者技术笔记，那你将可以节约很多时间。你最好一开始的时候创建一个该组过程的简单大纲，在创建详细的描述之前最好能将大纲浏览一遍。这是因为在你创建这样一个大纲的时候，你对于这些元素会有进一步的理解，会让你舍弃一些旧的印象和意见，让新的印象和意见能够取而代之。 使用你所偏好的HTML 编辑器 (参见 ), 选择 CBS Integration Mechanism 结点，从树状层级展开的内容菜单中选择 编辑 选项。 观察示例HTML 模板文件如何注意其授权时间, 正如图8所示. . 出版前的描述页面
特殊化的 HTML 命令(在这里指的是 RPW 命令) 已经作为RUP Organizer提供的模板的一部分，被定义为默认值，在你的过程授权中通常不必考虑。他们只是用于在出版的时候，收集根本过程元素的相关信息。 对上面所说的新内容文件夹，尝试用括号去除原文 (见 )以你自己的内容取而代之，从而写入描述。让这些内容尽量简捷明了，避免在你的描述中引入一些不确定的模糊的东西。除了在示例RPW模板中直接写入过程内容之外，你同时也可以从你现有的过程集中复制粘贴一些信息。或者，如果你喜欢，你可以从附件中 (见 下载) 提取预先授权文件夹，将这些文件和文件夹解压缩到 %RPW_CONTENT_HOME% 文件夹。 除了在层次展开中创建新的内容文件之外，你同时也可以用现有的文件夹组建。在你的层次展开中使用现有的文件的先决条件是：该文件存在于插件的内容库或者它基础过程内容库中。比如，你可以将你客户化的浏览图标（通常是小的16 x 16象素的GIF文件）和在层次展开中的可读写结点相联系，而将这些结点和RUP Organizer给定的默认图标解除联系。 现在让我们将一个客户化浏览图标和CBS 综合机制工件建立联系。:
为了保持树状浏览中展示的图标和描述文件中的图标一致性，我们同样需要建立个性化图表和相应的工件的联系。
RUP元模型定义了一系列的二级过程元素，即支持文件类型，以附加过程指南来补充一级元素。这些元素和一级元素不同，因为他们不像一级元素那样被定义为过程模型的一部分，因此他们不像一级元素一样拥有一个UML 表现 一个重要的区别是，他们在过程设置中没有以使用案例示例，因为他们被视为指南，所有使用案例都可以指定使用他们 (和创立和修改不同)来支持他们的工作。以下是一个很常见的文件类型到元素映射的示例。 . 将二级元素映射到一级元素
支持文件能够在层次展开的任何地方展开，也可以与多于一个的一级元素建立联系，（白皮书和路标文件通常会横跨多个元素，甚至有时候并不指定确切的一级元素）。一个插件可以通过在它的层次化展开，或者像基础RUP或者其他插件的上级层次化展开中，以附件形式覆盖现有的元素，来增加它的支持文件。比如，你可能想加入指南和概念到RUP元素中用以提供基础RUP之外的额外信息。为了在RUP单元中加入二级元素，你可以将你的支持文件从内容浏览单中拖到他们在目标层次展开中的相应结点。 因此，如果你希望修正/改变某一页的一级元素的介绍描述, RUP Organizer接受描述性文件在后台结点的放入，从而这些结点能改变前台表现。 (见 ). 在这种情况下，可以获得 移动描述文件 的环境菜单选项，这使得你能够移走最重要的描述文件夹，归还原先的文件夹，结点能够展示这种向后台的回归。 . 使描述文件和后台元素建立联系
另外，如果你发现一些现有的，存在在基础RUP中的二次元素和你的插件的环境毫无联系，那么当你的插件包括在过程结构中时，在他们发布之前你可以压缩这些二次元素。为了压缩RUP单元中的二次元素，点击基础RUP结点来压缩他们，选择内容菜单中的压缩选项，被压缩的文件将呈现跟压缩前不同的状态来指示他们的状态。如所示。 . 压缩了的基础支持文件
描述文件是必须的文件， 检查文件 的功能是指明你的层次展开中，目前还哪些元素没有和描述文件建立联系。尽管如果你进入RUP Organizer，一些文件可能已经存在于内容库中，但他们可能还没有和任何过程元素建立联系。
让我们将附件 (见 下载) 中的预定义文件和缺少描述文件的结点建立联系。或者，如果你愿意，你可以遵从 Create new content file 单元的步骤，从一个新的示例RPW模板建立新的文件。
注意，我们没有为有作用的cbs_integration_build_plan工件创造或者联系相关的描述文件。因为该工件只是一个占位符，不会在过程结构中出现。 为了让RUP 建立者能够使用，你需要导出你的过程插件。你的插件文件在导出时是一个压缩文件，放在你所选择的系统位置，在该处，它可以被导入到RUP建立者的工作空间，并纳入RUP结构中。
下面的简单略图是一个预览，显示了我们努力想达成的目标，以及在完成该系列后RUP过程结构(经由 EPIC 插件扩展)会是什么样子。 . 经由插件的过程元素扩展的RUP WFD
结论如果你意识到每个规程都有其自身的广度角色与深度角色，记忆这些RUP角色以及他们的功能是很容易完成的事情。这部分反应了一个在迭代式开发中减轻重要风险的一个解决方案：在每一次特定迭代中选择什么系统组件应该工作于细节。并且，某些个性类型更适合进行广度工作，而另一些则更适合于深度工作。了解你的Myers-Briggs个性轮廓可以帮助你预测当被分配置一个并不适合于你的个性类型的工作时所需要面对的挑战。虽然NP是自然适合于深度工作的，SJ更适合于广度工作，如果你有足够的根据，你也许也可以学习执行任何一种工作。 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| |||
组织简介 | 联系我们 | Copyright 2002 ® UML软件工程组织 京ICP备10020922号 京公海网安备110108001071号 |
