UML、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”(面向服务的构架)可能的角色。

　　图7：根据 Zachman 设计的工件分布

　　事实上，因为一些原因没有描述组织系统的工件或者没有与 Zachman 清晰的映射的情况是可能发生的。在这样的情况下，RUP 变量的选择可以围绕预期的辅助项目计划的工件分布来考虑。

　　应用6：RUP 项目结束后，可以由 Zachman 接替

　　从项目级到企业级(或者相反)转化系统工件的活动可能是十分痛苦的，因为它不能被很好地理解，也没有被很好的描述。虽然RUP部署规程有很多对将开发的系统移植到产品环境活动的支持，但是它不能涵盖围绕转换项目中创建的构架模型的活动。 11 这对RUP引入方面同样是适用的;在企业级别中，在启始和精化阶段并没有系统地讲述使用可用模型的活动。

　　既然RUP生命周期不包含企业构架规程，在RUP中就没有关于模型应该如何被项目接收、如何被向后转化至企业和系统被移植生产环境之后如何维护模型方面的指导。如果企业构架在RUP计划和和转化活动中被正式认可(事实不是如此)，那么这将不是上述情况。

　　有一个企业和项目构架师必须协同合作的局限性，Zachman 在这里要扮演一个角色——使项目构架工作具体化的框架。尽管每个组织将为连接企业和项目级别工件开发其自己独特的方法，但是一个共同的目标是将 Zachman 单元格与 RUP 的工作流和活动连接起来(见图8)。 12 不幸的是这些例子仅代表描述的一部分，因为他们只描述工件到表格的静态映射，通常不提供动态的阶段/迭代/活动事件方面的指导。

　　图8：RUP 与 Zachman 之间的工件的可追踪性(图解)

　　当RUP项目计划工作正在进行的时候，需要为连接工件引入一个容易操作的结构。最普遍的做法是复制RUP生命周期结构。我看见过许多设置的例子，其中文件夹相当于迭代，下面的子文件夹通过规程来组织。这种方法有明显的缺点，因为项目结构只在项目存活时有关系，当项目结束后这种关系将立即消失。

　　Zachman 的例子可以在这一点上产生，因为它的主要结构可能用于在信息来源和文件管理工具里建立项目配置。更简单的实现可以使用文件系统文件夹复制 Zachman 结构。如果在RUP项目完成时，工件被移至已建立的档案中来连接 Zachman 结构，那么以后的企业和项目团队可以很容易得到它们。像这样的一个投资将有益于未来的RUP和企业项目，并使得企业构架更加清晰并具有可持续性。

　　应用7：在计划 RUP 项目时，考虑 Zachman 结构

　　如果您的组织已经根据 Zachman 已有组织的结构形式管理其工件，那么是一件不错的事情。如果不是，还是有可能从在建模活动和询查框架侧重的各个方面过程中从系统的评价 Zachman 结构中受益的。关于这个框架需要记住的一件事情是它是 John Zachman 和其他取得系统工程项目经验的人的集体智慧的结晶。因此 Zachman 不同的观点都是针对项目团队可能面对的许多相同问题(见图9)。

　　图9：RUP 计划中的 Zachman 元分析

　　Zachman 结构的一些方面通过一些公式化的问题，例如，什么、哪里、如何，来表述，这些问题对所有的项目类型来说是通用的，而且如果有必要，也可以转化成为针对特定项目的问题。另外一些方面涉及关于系统构架提出的重要问题;例如“规则设计”可能会引出“解决方案将需要一个规则引擎吗?”这样的问题。其他像“实体=业务事件类”或者“过程=应用功能”这样的表述可能传递特定技术的需要，例如模型驱动构架(MDA)或者业务过程建模(BPM)，这些可以在开发过程的不同阶段被使用。

　　Zachman 产生的观点可能也在项目和迭代计划期间有帮助，不难想象“迭代评估”或者“开发风险管理计划”活动可能如何使用那些极好的方面。

　　当然，对于一些(特别是缺乏经验的)构架师来说，按照我所描述的方法使用 Zachman 听起来可能太混乱，而经验丰富的专业人员可能觉得对于他们自己的知识框架来说那是多余的。我仍相信大多数实践人员将会发现 Zachman 在他们的工作中是便利的分析参考资源。当为项目建立环境时，计划自身是一项重要的任务，它通常不是很难，而且对项目和组织来说都很有价值。

　　应用8：结合使用 Zachman 与 RUP，来帮助架起企业和项目构架之间的桥梁

　　许多开发组织的一个共同特点是在感知到复杂的事物蔓延之前忽视企业构架。大多数组织尝试通过引入企业构架实践并要求其处理跨系统和跨项目的问题的办法来解决这一问题。这一方法可以帮助管理项目生产的工件，而同时通过使项目拥有公有的企业模型来减少业务风险。最后也是最重要的一点是，企业构架实践将鼓励企业和项目团队之间的相互作用，这将使得他们彼此受益。

　　通常情况，企业和项目构架之间在他们各自的影响领域会有冲突发生，全部归结为什么工件(是否是UML)最好地代表企业系统、什么团队创建了它们以及如何维护和使用它们。如图10所示，当工件从被创建(在开发项目或者其他企业项目的时候)，再到随后的使用，最后到工件不再被需要(可能在退出系统之后)的生命周期可以被清楚的跟踪时，可以达到构架透明度的最终水平。RUP 和 Zachman 的结合覆盖了工件生命周期的重要部分，这可以帮助组织实现一个统一的、完全透明的构架的重要益处。

　　图10：工件的生命周期

　　总结

　　作为他们各自领域的领导者，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 中结合应用用例可以帮助缩小企业与其项目之间的差距，从而使得组织更加有效。最后，那就是所有的一切。

查看本文来源