| UML软件工程组织 | |||
| |
|||
|
|||
UML、RUP 和 Zachman 框架：完美结合
Vitalie Temnenco, 构架师, Uniserve
Communications Corporation
| 本文内容包括:
本文来自于 Rational Edge：这篇文章提出了许多有创意的方法，将过去十年里出现在信息系统构架领域的三个最重要的方法:
UML、Rational 统一过程（RUP）和 Zachman 框架，结合起来。 根据定义，UML是一个建模语言。它试图将软件密集型建模系统的图形语言元素标准化。它的最新版本UML 2.0由用于结构建模、行为建模和交互建模的十三个图类型组成。毫无意义的是，虽然主要是为了面向对象（OO）的分析和设计，但UML可以在许多其他条件下使用。例如，UML用例方法（如图1所示）本身不是一个OO过程，但它却已被证实为进行一般功能需求分析的最佳技术。其他UML图，例如交互作用、状态和活动图同样也是我们经常用户描述真实世界项目情况的可用工具。
关于 Zachman 构架框架是一种用来开发和维护较广范围构架的工具。当涉及支持企业里的定制企业构架（EA）功能时，Zachman 框架可以提供很多帮助。它将企业主题分级成一个6x6的单元格矩阵，每个单元格代表每个组织的一个唯一视图（见图2）。
Zachman 里的列代表企业最重要的方面（数据、功能、网络、人、时间、动机），而行不同，按照不同角度（规模、业务、系统、技术、细节、资产）和与一个方面相关的涉众（计划者、业务所有者、设计者、实施者、子承接者）来划分。此外，行也因细节级别而不同，因为它们是企业的抽象表达（环境中的、概念上的、逻辑的、物理的、详细的和实际的），这反过来可能与涉众和角度相连接来形成企业模型和职责的单元格。实例是：“一个系统模型（角度）是一个 设计者（群体）职责范围一部分的合乎逻辑（抽象）的实体。” 三十六个框架单元格可以通过根据选择元特性描述企业的模型和工件来划分，例如方面、细节级别或者兴趣种类。框架并不规定要填充的单元格的符号或顺序，因为这一知识点已经超出了参考结构目标的范围。（后面的假设为创建使用 UML 和 RUP 框架的案例提供支持。 ） 关于 RUP 过程可以被定义为“产生结果的一系列动作、变更或功能 ”。RUP 是一个过程框架（见图3），它允许项目工作流程和任务被组织成为为最终目标为交付软件产品或解决方案的一系列动作。RUP
应该被裁剪以创建满足特定组织或者项目需要的过程实例和方法。 RUP 思想源于一个统一的系统的实现，这个系统通过使用 UML 符号来描述交付工件 。重要的是新的过程具有迭代的、以构架为中心的，以及需求驱动的特征，而这些特性是已有系统所不具备的。 自出现以来，RUP 已经从源于 Objectory 方法的软件工程过程发展为一个基于 UML 2.0 并由 Rational Method Composer (RMC)支持的用于裁剪过程的灵活的、可完全定制的平台。 7 例如，使用 RMC，一个熟练的过程工程师可以创建一个系统工程过程的实例，定制其结构，从其他行业标准方法和最佳实践中添加需要的内容并且以超链接文本的形式产生一个备用的、适应组织或项目的过程实例。 根据前面的讨论，这三个系统中的每一个都被创建来服务特定的需求， 同时他们也都有缺乏对他们侧重领域之外的更广适应性的缺点。在许多组织里，关于 Zachman 框架我所注意到的一点是，表面上它是一个每个人都称好的巨大海报，但是没有人使用它。我将这一点归结于这样一个事实：与其它任何静态框架一样，Zachman没有说明如何处理工件引入。另一个实用方面的缺点，通常被认为是优点，是框架缺少标准的符号。 更普遍的是，应用 RUP 的问题在于它作为软件开发过程的主要优势，然而这一点对构架师和开发人员等人是有吸引力的，但来自其他领域的人不会购买它作为主要技术。例如，项目经理会选择其他的方法（比如，RUP 项目管理规程基于的项目管理知识体系(PMBOK)），并将 RUP 作为这些更有利的方法的一个附属物。相反，企业架构师通常选择 Zachman。 UML 在角色依赖关系上的问题稍微少一些，因为与 RUP 不同，它并不提出角色，因此没有方法映射的需要。尽管如此，过程和框架的独立也限制了UML的有效性。对UML来说幸运的是，尽管许多组织使用其他像实体关系图（ERD）和业务进程建模符号(BPMN) 这样的结构方法和符号，但UML仍得到了普遍认可。 在尝试表达这些局限性以及为三种方法找到的共同的应用的过程中，要再一次注意的是它们被创建以表示同一个领域的不同的问题（信息系统构架），而且它们之前的目标设置实际上没有功能重迭（见图4）。对企业和项目构架师来说这都是好消息，因为那意味着 UML、Zachman 和 RUP 可以共同使用以产生更全面的企业价值。
关于交叉功能适用性的思考 RUP已经使用UML和其他像ERD这样的可视化建模语言以及像用例、业务角色和验收测试这样的非可视化建模产品。Zachman 框架并不与一个符号或一个过程结合，也不他们的选择加以限制。两种技术可以最佳使用的情况也是不同的。例如，由于其固有的不适应性，在开发环境中使用 Zachman 是值得置疑的。同样地，使用 RUP 作为一个企业信息构架的基础也未被证明是合理的。 在各自的生命周期定义之间的相似之处（比较上面的图2和图3十分明显）有助于解释这样一事实：RUP 和 Zachman 都是受工件驱动的并继承源于以构架为中心的设计原理的结构。明显的相似之处意味着假定企业系统和项目的复杂性不断增加，两个过程可能会互相强化。 这样已经在指出三种方法的不同之处方面进行了相当多的阐述，我将考虑正在探讨的方法在什么地方可以互相补充。 通常情况下，为响应在管理上的“call for action”，组织直接将注意力投向 Zachman 来为企业的IT系统驱动“未来的”模型，或者针对一个非同小可的业务转型项目。在类似这样的场景中，架构师们将分散在跨越储存库的系统知识资产汇集起来（这实际上是件正确的事情）只是为了了解到他们的前辈们生产出的工件并不能很好的适合 Zachman 结构。不适合的普遍原因是大多数现有的工件是至少几个不同方面的混合（还记得 Zachman 的列吗？），另外一个原因是工件总是被使用不同的符号进行创建。而在大多数情况下，对工件进行式样翻新是不可行的，这些“经验教训”是与通用符号的重要性相关的。您是否也正在思考我所考虑的事情？那好—— UML 也许能够帮助您解决这一难题。 Zachman 不限定也不推荐使用 UML 或者其他任何符号。然而， RUP 要求使用 UML。既然应该避免使用多样的符号，那么后面的论述将着重展示一个利用 UML 作为企业和项目架构的通用符号的情况。 应用2：使用 UML 将 Zachman 和 RUP 结合起来 在大多数组织里，当系统可能以某种形式存在很长时间的时候，例如 UML 起码已经有大约十年的时间，缺少标准的符号是可以理解的。即使在相对现代化的系统环境里，UML 也可能由于文档设计的时间限制和缺少必要的技巧设置等 原因没有被使用。 除了对于分析和设计需要良好的建模语言外，两个因素中任何一个都可能引发组织——一个RUP项目或者企业架构现代化成果——对 UML 的需要。任何一个理由都很好，因为它允许组织启用 UML。尽管如此，RUP 项目产生的结果可能要比从未来重用的角度而由构架现代化工作产生的结果更重要，因为RUP项目趋向于产生更加细化而且更加容易跟踪的工件。RUP方法的另一个优点是，通常只生产真正有价值的工件。从另一方面来看，构架现代化成果可能会产生很多实用价值很小，而且带有不确定性的UML图。事实上，这种情况可能会影响组织对UML的认可以及它在组织中的未来。 通过RUP驱动系统交付项目将UML应用到组织之后，它的用途可以扩展到以 Zachman 为基础的企业构架，没有减少它的需求的风险（见图5）。 这一应用在过去已经尝试过很多次，而近期大多是在企业统一过程(EUP)环境中实现的。 以我的经验来看，无论是为组织引入 RUP 还是 Zachman ，如果 UML 已经在组织中被使用，成功的可能性更大。图6 试图通过描述三个技术之间的依赖关系解释这一点。
正如我上面所陈述的，Zachman 和 RUP 都依赖 UML。RUP 专门由 UML 驱动，而符号未知的 Zachman 依赖其实现符号。UML可被证明是 Zachman 使用的最好符号，因为它不依赖其他方法，因此可以作为 RUP 和 Zachman 的出发点。此外，即使以后您决定不使用 RUP 或者 Zachman，UML 仍是一个十分有用而且易于理解的可视化语言，可用于全面分析、解决方案的分析和设计以及提高团队交流。 应用4：和 Zachman 一起学习 RUP（或者相反）可能更加容易 学习RUP需要理解它的结构和规程是如何服务于管理项目团队的。因此，学习RUP最好的办法是通过相关的项目经验或在有指导的环境中进行。为了获得这一经验，有必要在贯穿RUP生命周期的活动中扮演一定的角色。 正如在 RUP 实践中可以有许多 Zachman 方面可以与之并行，这样一个方法也的确帮助 Zachman 增加价值。例如，用RUP业务过程建模、用例和序列图来表示 Zachman“功能”，同样地，使用用例和UI设计来处理“人机交互”，使用类和对象图来处理“数据”。Zachman 结构的某些行与RUP 的需求驱动、递增和以构架为中心的原则是相通的，而列相当于一些UML模型和最佳实践的目标设置。例如，“如何实现”这一列重点强调处理过程，并可以与UML活动图相比较。 可以证明，了解 Zachman 比了解 RUP 和 UML 更简单，因为 Zachman 处理的是企业系统构架的静态视图，而不是动态模型和过程。尽管如此，学习 Zachman 的方法可能主要受益于一些 RUP 主要原则——例如，“需求驱动”、“以构架为中心”、“模型驱动”和“迭代”——的应用。我的看法是当这些原则加入到学习过程和它的实际应用时，Zachman 框架更容易掌握。 在 RUP 裁剪过程中，工作的重点是在开发组织的结构上。角色、时间和职能是每一个这样的活动中要考虑的重要方面，要提出的问题包括：“在这个过程中谁来做构架建模？”“过程建模何时发生？”“什么技术应该用于用途建模？”以及“应该如何基于详细级别划分职责？”。Zachman 具有固定的结构，可能恰恰是回答像这样问题的合适的信息来源。 10 尽管 RUP 中带有对工作流程的指导，但是它可能在真实的项目里并不适用或者只是部分适用。为了帮助过程工程师处理方法上的变化，IBM Rational 已经对 RUP 做了一些专门的扩展，例如“RUP for COTS”（商业现货软件）和“RUP for Systems Engineering”。为了在裁剪工作期间挑选一个合适的 RUP 变量作为基线，过程构架师必须了解组织的企业构架的现有的和未来状态。如果组织已经为企业构架分析/计划使用 Zachman，那么产生的框架可以提供有用的线索来选择正确的 RUP 变量。例如，相应的 Zachman 结构的业务模型（第二行）里的工件集合可能意味着重点是在业务建模上（见图7）并提示密切观注“RUP for Business Modeling”变量，而在网络一栏里的更高的工件密度暗示着 “RUP for SOA”（面向服务的构架）可能的角色。
事实上，因为一些原因没有描述组织系统的工件或者没有与 Zachman 清晰的映射的情况是可能发生的。在这样的情况下，RUP 变量的选择可以围绕预期的辅助项目计划的工件分布来考虑。 从项目级到企业级（或者相反）转化系统工件的活动可能是十分痛苦的，因为它不能被很好地理解，也没有被很好的描述。虽然RUP部署规程有很多对将开发的系统移植到产品环境活动的支持，但是它不能涵盖围绕转换项目中创建的构架模型的活动。这对RUP引入方面同样是适用的；在企业级别中，在启始和精化阶段并没有系统地讲述使用可用模型的活动。 既然RUP生命周期不包含企业构架规程，在RUP中就没有关于模型应该如何被项目接收、如何被向后转化至企业和系统被移植生产环境之后如何维护模型方面的指导。如果企业构架在RUP计划和和转化活动中被正式认可（事实不是如此），那么这将不是上述情况。 有一个企业和项目构架师必须协同合作的局限性，Zachman 在这里要扮演一个角色——使项目构架工作具体化的框架。尽管每个组织将为连接企业和项目级别工件开发其自己独特的方法，但是一个共同的目标是将 Zachman 单元格与 RUP 的工作流和活动连接起来（见图8）。不幸的是这些例子仅代表描述的一部分，因为他们只描述工件到表格的静态映射，通常不提供动态的阶段/迭代/活动事件方面的指导。
当RUP项目计划工作正在进行的时候，需要为连接工件引入一个容易操作的结构。最普遍的做法是复制RUP生命周期结构。我看见过许多设置的例子，其中文件夹相当于迭代，下面的子文件夹通过规程来组织。这种方法有明显的缺点，因为项目结构只在项目存活时有关系，当项目结束后这种关系将立即消失。 Zachman 的例子可以在这一点上产生，因为它的主要结构可能用于在信息来源和文件管理工具里建立项目配置。更简单的实现可以使用文件系统文件夹复制 Zachman 结构。如果在RUP项目完成时，工件被移至已建立的档案中来连接 Zachman 结构，那么以后的企业和项目团队可以很容易得到它们。像这样的一个投资将有益于未来的RUP和企业项目，并使得企业构架更加清晰并具有可持续性。 如果您的组织已经根据 Zachman 已有组织的结构形式管理其工件，那么是一件不错的事情。如果不是，还是有可能从在建模活动和询查框架侧重的各个方面过程中从系统的评价 Zachman 结构中受益的。关于这个框架需要记住的一件事情是它是 John Zachman 和其他取得系统工程项目经验的人的集体智慧的结晶。因此 Zachman 不同的观点都是针对项目团队可能面对的许多相同问题（见图9）。
Zachman 结构的一些方面通过一些公式化的问题，例如，什么、哪里、如何，来表述，这些问题对所有的项目类型来说是通用的，而且如果有必要，也可以转化成为针对特定项目的问题。另外一些方面涉及关于系统构架提出的重要问题；例如“规则设计”可能会引出“解决方案将需要一个规则引擎吗？”这样的问题。其他像“实体=业务事件类”或者“过程=应用功能”这样的表述可能传递特定技术的需要，例如模型驱动构架(MDA)或者业务过程建模(BPM)，这些可以在开发过程的不同阶段被使用。 Zachman 产生的观点可能也在项目和迭代计划期间有帮助，不难想象“迭代评估”或者“开发风险管理计划”活动可能如何使用那些极好的方面。 当然，对于一些（特别是缺乏经验的）构架师来说，按照我所描述的方法使用 Zachman 听起来可能太混乱，而经验丰富的专业人员可能觉得对于他们自己的知识框架来说那是多余的。我仍相信大多数实践人员将会发现 Zachman 在他们的工作中是便利的分析参考资源。当为项目建立环境时，计划自身是一项重要的任务，它通常不是很难，而且对项目和组织来说都很有价值。 应用8：结合使用 Zachman 与 RUP，来帮助架起企业和项目构架之间的桥梁 许多开发组织的一个共同特点是在感知到复杂的事物蔓延之前忽视企业构架。大多数组织尝试通过引入企业构架实践并要求其处理跨系统和跨项目的问题的办法来解决这一问题。这一方法可以帮助管理项目生产的工件，而同时通过使项目拥有公有的企业模型来减少业务风险。最后也是最重要的一点是，企业构架实践将鼓励企业和项目团队之间的相互作用，这将使得他们彼此受益。 通常情况，企业和项目构架之间在他们各自的影响领域会有冲突发生，全部归结为什么工件（是否是UML）最好地代表企业系统、什么团队创建了它们以及如何维护和使用它们。如图10所示，当工件从被创建（在开发项目或者其他企业项目的时候），再到随后的使用，最后到工件不再被需要（可能在退出系统之后）的生命周期可以被清楚的跟踪时，可以达到构架透明度的最终水平。RUP 和 Zachman 的结合覆盖了工件生命周期的重要部分，这可以帮助组织实现一个统一的、完全透明的构架的重要益处。
作为他们各自领域的领导者，UML、RUP 和 Zachman 框架可以在任何组织中共同使用以产生更加全面的构架价值。RUP 和 Zachman 都是模型驱动的并需要某种符号来实现功能。既然 RUP 规定 UML 作为其符号，那么对于企业构架来说，使 UML 作为标准化的符号可能更加有意义，因为通常情况下，它没有任何缺点。 虽然 RUP 和 Zachman 都依赖模型，但实际上它们没有功能交迭。这主要是因为 RUP 是一个过程，而 Zachman 是一个框架，但是也反映了 RUP 以项目构架为目标，而 Zachman 的重点是在企业组织上。 既然 RU P和 Zachman 都可以依赖 UML，后者是三个方法中先要引入的首选方法。将 RUP 应用于 Zachman 或者相反，有助于更全面的学习经验。 使用 Zachma 将现有的工件分类或者只是提及 Zachman 结构和规程使得裁剪 RUP 更加简单，因为它引起了关于对开发组织重要的角色、工件、工作流程和活动的思考。 项目计划成果也得益于对 Zachman 的应用，因为它可以很快地使您得到需求收集或分析/设计中可以用到的工件。即使在没有连接到 Zachman 工件时，Zachman 结构本身仍是非常有帮助的，因为在项目反映的业务问题上它提供了各种有用的观点。 一个组织几乎必然将从支持企业构架和其项目之间的工件可追踪性中受益，这种可追踪性可以通过建立对一个工件从创建到结束的生命周期的控制来取得。通过这种方法，RUP 和 Zachman 都可以被应用于管理工件。 最终的思考 当要创建灵活的和可维护的解决方案的时候，项目和企业团队应该协同合作。项目成员应该了解更广泛的企业环境，而他们对应的企业必须不断地监控项目以保持知识是最新的。在 RUP 和 Zachman 中结合应用用例可以帮助缩小企业与其项目之间的差距，从而使得组织更加有效。最后，那就是所有的一切。 我要感谢 S. Ambler、D. Bentley 和 J. Reading 为这篇文章所做的直接与间接的贡献。 |
| |||
组织简介 | 联系我们 | Copyright 2002 ® UML软件工程组织 京ICP备10020922号 京公海网安备110108001071号 |
