UML:与Zachman完美结合

在过去的十年，使用统一建模语言（UML）为软件应用程序进行建模的优势已变得日益明显。与此同时，RUP已经是一种经证明的软件开发过程，Zachman框架是一种被证明的构架工件组织和通信的框架。

 

UML、RUP 和 Zachman 框架的功能重迭

在众多交叠的方法中，UML、RUP和Zachman分别作为现代信息系统构架的三个重要支柱。通过检验它们的元特性并提出一些将它们与组织结合的方法来考虑这些方法组合使用。

根据定义，UML是一个建模语言。它试图将软件密集型建模系统的图形语言元素标准化。它的最新版本UML2.0由用于结构建模、行为建模和交互建模的十三个图类型组成。毫无意义的是，虽然主要是为了面向对象（OO）的分析和设计，但UML可以在许多其他条件下使用。例如，UML用例方法本身不是一个OO过程，但它却已被证实为进行一般功能需求分析的最佳技术。其他UML图，例如交互作用、状态和活动图同样也是我们经常用户描述真实世界项目情况的可用工具。

Zachman的起源

构架框架是一种用来开发和维护较广范围构架的工具。当涉及支持企业里的定制企业构架（EA）功能时，Zachman框架可以提供很多帮助。它将企业主题分级成一个6x6的单元格矩阵，每个单元格代表每个组织的一个唯一视图。

Zachman里的列代表企业最重要的方面（数据、功能、网络、人、时间、动机），而行不同，按照不同角度（规模、业务、系统、技术、细节、资产）和与一个方面相关的涉众（计划者、业务所有者、设计者、实施者、子承接者）来划分。此外，行也因细节级别而不同，因为它们是企业的抽象表达（环境中的、概念上的、逻辑的、物理的、详细的和实际的），这反过来可能与涉众和角度相连接来形成企业模型和职责的单元格。实例是:“一个系统模型（角度）是一个设计者（群体）职责范围一部分的合乎逻辑（抽象）的实体。”

三十六个框架单元格可以通过根据选择元特性描述企业的模型和工件来划分，例如方面、细节级别或者兴趣种类。框架并不规定要填充的单元格的符号或顺序，因为这一知识点已经超出了参考结构目标的范围。（后面的假设为创建使用UML和RUP框架的案例提供支持。）

过程可以被定义为“产生结果的一系列动作、变更或功能”。RUP是一个过程框架，它允许项目工作流程和任务被组织成为为最终目标为交付软件产品或解决方案的一系列动作。RUP应该被裁剪以创建满足特定组织或者项目需要的过程实例和方法。

RUP思想源于一个统一的系统的实现，这个系统通过使用UML符号来描述交付工件。重要的是新的过程具有迭代的、以构架为中心的，以及需求驱动的特征，而这些特性是已有系统所不具备的。

自出现以来，RUP已经从源于Objectory方法的软件工程过程发展为一个基于UML2.0并由Rational Method Composer(RMC)支持的用于裁剪过程的灵活的、可完全定制的平台。7例如，使用RMC，一个熟练的过程工程师可以创建一个系统工程过程的实例，定制其结构，从其他行业标准方法和最佳实践中添加需要的内容并且以超链接文本的形式产生一个备用的、适应组织或项目的过程实例。

集成的驱动力

根据前面的讨论，这三个系统中的每一个都被创建来服务特定的需求，同时他们也都有缺乏对他们侧重领域之外的更广适应性的缺点。在许多组织里，关于Zachman框架我所注意到的一点是，表面上它是一个每个人都称好的巨大海报，但是没有人使用它。我将这一点归结于这样一个事实:与其它任何静态框架一样，Zachman没有说明如何处理工件引入。另一个实用方面的缺点，通常被认为是优点，是框架缺少标准的符号。

UML在角色依赖关系上的问题稍微少一些，因为与RUP不同，它并不提出角色，因此没有方法映射的需要。尽管如此，过程和框架的独立也限制了UML的有效性。对UML来说幸运的是，尽管许多组织使用其他像实体关系图（ERD）和业务进程建模符号(BPMN)这样的结构方法和符号，但UML仍得到了普遍认可。

在尝试表达这些局限性以及为三种方法找到的共同的应用的过程中，要再一次注意的是它们被创建以表示同一个领域的不同的问题（信息系统构架），而且它们之前的目标设置实际上没有功能重迭。对企业和项目构架师来说这都是好消息，因为那意味着UML、Zachman和RUP可以共同使用以产生更全面的企业价值。

UML将Zachman和RUP结合

在大多数组织里，当系统可能以某种形式存在很长时间的时候，例如UML起码已经有大约十年的时间，缺少标准的符号是可以理解的。即使在相对现代化的系统环境里，UML也可能由于文档设计的时间限制和缺少必要的技巧设置等原因没有被使用。

通过RUP驱动系统交付项目将UML应用到组织之后，它的用途可以扩展到以Zachman为基础的企业构架，没有减少它的需求的风险。

正如我上面所陈述的，Zachman和RUP都依赖UML。RUP专门由UML驱动，而符号未知的Zachman依赖其实现符号。UML可被证明是Zachman使用的最好符号，因为它不依赖其他方法，因此可以作为RUP和Zachman的出发点。此外，即使以后您决定不使用RUP或者Zachman，UML仍是一个十分有用而且易于理解的可视化语言，可用于全面分析、解决方案的分析和设计以及提高团队交流。

和Zachman一起学习RUP

在RUP实践中可以有许多Zachman方面可以与之并行，这样一个方法也的确帮助Zachman增加价值。例如，用RUP业务过程建模、用例和序列图来表示Zachman“功能”，同样地，使用用例和UI设计来处理“人机交互”，使用类和对象图来处理“数据”。Zachman结构的某些行与RUP的需求驱动、递增和以构架为中心的原则是相通的，而列相当于一些UML模型和最佳实践的目标设置。例如，“如何实现”这一列重点强调处理过程，并可以与UML活动图相比较。

可以证明，了解Zachman比了解RUP和UML更简单，因为Zachman处理的是企业系统构架的静态视图，而不是动态模型和过程。尽管如此，学习Zachman的方法可能主要受益于一些RUP主要原则——例如，“需求驱动”、“以架构为中心”、“模型驱动”和“迭代”——的应用。我的看法是当这些原则加入到学习过程和它的实际应用时，Zachman框架更容易掌握。

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

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

作为他们各自领域的领导者，UML、RUP和Zachman框架可以在任何组织中共同使用以产生更加全面的构架价值。RUP和Zachman都是模型驱动的并需要某种符号来实现功能。既然RUP规定UML作为其符号，那么对于企业构架来说，使UML作为标准化的符号可能更加有意义，因为通常情况下，它没有任何缺点。

虽然RUP和Zachman都依赖模型，但实际上它们没有功能交迭。这主要是因为RUP是一个过程，而Zachman是一个框架，但是也反映了RUP以项目构架为目标，而Zachman的重点是在企业组织上。

既然RUP和Zachman都可以依赖UML，后者是三个方法中先要引入的首选方法。将RUP应用于Zachman或者相反，有助于更全面的学习经验。

项目计划成果也得益于对Zachman的应用，因为它可以很快地使您得到需求收集或分析/设计中可以用到的工件。即使在没有连接到Zachman工件时，Zachman结构本身仍是非常有帮助的，因为在项目反映的业务问题上它提供了各种有用的观点。

一个组织几乎必然将从支持企业构架和其项目之间的工件可追踪性中受益，这种可追踪性可以通过建立对一个工件从创建到结束的生命周期的控制来取得。通过这种方法，RUP和Zachman都可以被应用于管理工件。

当要创建灵活的和可维护的解决方案的时候，项目和企业团队应该协同合作。项目成员应该了解更广泛的企业环境，而他们对应的企业必须不断地监控项目以保持知识是最新的。在RUP和Zachman中结合应用用例可以帮助缩小企业与其项目之间的差距，从而使得组织更加有效。最后，那就是所有的一切。

 

UML 连接 RUP 和 Zachman 框架

<!--新闻内容//--><!--评论发布-->