开发人员如何才能交付符合客户期望的高质量的系统呢？如果有一种可以让开发人员和用户一起使用的语言，而且这种语言清晰、简明，可以用来尽可能彻底地建模所需的系统，又会怎样呢？现今，大多数企业内的系统架构都错综复杂，刚才所说的那样的语言的确是必不可少的。
似乎正是架构的复杂性才导致了统一建模语言（Unified Modeling Language，UML）的广泛采用，这种语言是为建模面向对象的系统而开发出来的一种标准化的表示法（notation ）。随着系统越来越大，越来越复杂，人们就越来越需要能够轻松容易地理解系统所基于的蓝图（blueprint）。这些蓝图，或者说模型，可以帮助开发人员在开始编码之前，确信他们所开发的应用程序能够提供所需的业务功能，符合用户需求，并且支持可伸缩性、健壮性、安全性之类的需求。
UML 是由 Rational Software 开发出来的，后来被 Object Management Group (OMG) 采纳作为一种标准，它不是一种编程语言，更不是一种方法论（methodology）。它只是用于画出模型图并作出注释的一种标准化的方式。UML 使用一套标准的为软件工程和设计而创建的直观的规则和过程，从而使得设计的意图更加直观、清晰。目标是使所有项目涉众（stakeholder），从开发人员到投资方，都能理解每个片段的功能性，片段之间如何交互，片段组之间如何交互，以及整个系统如何运转。UML 有助于弥合技术设计与技术开发之间的鸿沟。
参考资料IBM alphaWorks Object Management Group Rational Software |
开始
在召开规划会议时将 UML 图画在纸上或白色书写板上当然是可以的。但是，大多数人都会使用市场上众多可视化建模工具中的一种（您可以在 www.uml.org 找到可访问这些工具列表的链接）。其中一种流行的工具是 Rational Software 的 Rational Rose，这种工具可以访问 DB2 Universal Database (DB2 UDB) Version 8 或更早版本中的数据模型。该工具可以将现有数据库模式提取到一个逻辑 UML 模型中，或者直接从 UML 模型生成模式。
UML 是如何节省时间的呢？简单来说，数据库图对于那些不参与管理和设计数据库的人来说不是那么容易理解。如果您只是依赖于数据库图，就很可能会遗漏很多系统和设计的需求，因为并不是所有的涉众都能参与或理解系统的细节。
如果在需求分析和设计阶段没有正确地识别需求，就常常会遗漏某些特定的期望。到了验收测试开始的时候，就会发现这些疏忽，导致项目被推迟，又要匆忙地重新设计系统，这样质量就降下来了，项目的适用范围也小了。
在开发阶段，越是往后出现新需求，完成项目所需花费的时间和精力就越多。如果要在一座高耸的摩天大楼中间新加一层，那么在项目正在进行时才考虑比在蓝图规划阶段就考虑要困难得多。这一思想同样也适用于软件设计。
可以使用 UML 图来确保所有的项目涉众，甚至那些没有技术背景的人，都能理解项目的设计，并且在模型阶段就能找出任何缺点。UML 可用于建模数据库、应用程序逻辑和业务流程，涵盖软件开发的所有方面。
UML 训练用户遵循它所建立的惯例和过程。UML 直接应付的挑战包括：
- 有些用户不理解自己想要什么。
- 有些用户不会同意已经写下的需求。
- 与用户之间的交流很缓慢。
- 有些用户技术水平不高。
UML 的当前发行版 Version 1.4 包含 8 种基本图，这些图为构造、配置和部署应用程序或系统提供了基础。 表 1 展示每种图的一般用途。
表 1：UML 的基本图
UML 还包含这 8 个基本图的变种（所以有时 UML 文档会提到不止 8 种图）。例如，UML Object Modeling 表示法就是类图的一个变种，它显示对象之间的关系，这些对象是在运行时从类模板创建出的实例。UML 对象图描绘了一个典型的模型设计的基本布局，并且是更深入地理解 UML 的一个很好的切入点。 图 1 展示标准 UML 对象定义。
图 1： 对象建模表示法 
图 2 演示了如何将 UML 表示法用于实际的应用程序建模，即对一个标准帐户处理银行解决方案（见第 24 页）基于应用程序的架构的建模。
图 2：用于应用程序建模的 UML 表示法 
该图包含与类结构有关的以下信息：
- Corporate 类（包含 Bank Name 和 Address 属性）管理着数量不定的一些 Branch 类。一个 Branch 只能由一个 Corporate 管理（黑色小箭头表明方向，关系名应该按照这个方向来读）。在该图中，直线表示该关系是从 Corporate 类到 Branch 类的关系，该关系被标为“Administers”。直线靠 Corporate 端的数字“1”表示只有刚好一个 Corporate 与每个 Branch 相关。直线靠 Branch 端的“*”表示一个 Corporate 管理零个或多个 Branch。
- 一个 Branch 类（包含 Address 和 Manager 属性）拥有多个 Account 类。每个 Account 只能被刚好一个 Branch 所拥有。而且，Account 类定义了一个“Calculate Charges”方法（也叫操作函数或成员函数）。这个方法在被调用时将查看存储在 Account 对象中的细节，并对该 Account 应用适当的费用（charge）。第二个方法是“Record Statement”，该方法取出 Account 中的细节并记录到一条常规语句中。
- 继承三角形（作为“Account Type”列出）表明我们的系统知道三种类型的 Account：基本帐户（在本例中是一个名为 Account 的虚类）和两个专门化的帐户（Checking Account 和 Savings Account，它们是从 Account 派生而来的）。“Calculate Charges”在两个子类中都出现了，这表明它的实现在这些类中重新进行了定义。因此，“Savings Account”的计算与“Checking Account”的计算不一样。
- 每个 Account 都为一个 Customer 所拥有。Customer 可能有多个 Account。
因为一个帐户可以为一个 Customer 所拥有，所以支票帐户和储蓄帐户两者都可以为一个客户所拥有。换句话说，Checking Account 和 Savings Account 类继承了 Account 和 Customer 之间的“owned by”关系。这样就不需要再去显式地标注这些关系，从而大大简化了这个图。
注意，该图显示了 Account 与 Transaction 类之间的两种关系。这是因为每个事务（贷出，借入，等等）都必须有两个相关的帐户：贷出钱的 Account 和借入钱的 Account。这样银行就可以确切地记录整个事务过程。
这就导致对象模型上所显示的东西有一个有趣的特点：对于每个事务来说，从同一个帐户贷出和借入是无效的 —— 没有钱会发生转移！虽然这种方法非常好，但是根本不能用于任何实际用途。周详地考虑所有情况，并通过 UML 图加以“谋划”，有助于清除异常情况，并在最终部署之前解决。
用例
UML 最强大的组件之一就是用例（use case）这个概念。有了用例，就可以以一种工程师和业务经理都能理解的直观方式，独立于设计来建立需求。
图 3 展示了某一特定应用程序开发项目所需的业务功能：
- 经理将使用这个系统来获得客户使用报告，以确定交易量和受欢迎的功能。
- 客户可以使用这个系统来查询余额、转帐和重设密码。
- 商家将使用这个系统来核实资金是否充足。
- 客户代表必须能够代表客户重设密码。
- 定时进程（Timed Process）将运行系统备份程序。
图 3：一个应用程序开发项目的用例图 
所以，该系统有 5 种截然不同的用户，分别是银行经理、客户代表、商家、客户以及定时进程。每种用户通常都有一套特定的需求。识别用户类型有助于识别所有所需的系统功能。
用例图技术让您可以定义系统功能需求，并将这些需求以一种所有涉众都能理解的形式再呈现给系统用户。这种技术还划分了业务功能，业务功能可以为估计系统花费或者规划分阶段迭代的系统交付奠定基础。完整的用例要求写下细节。
在 UML 设计术语中，图 4 中的用例细节后面有一个分为 4 级的迭代方法，这 4 级分别是 Facade、Filled、Focused 和 Finished，这是为了使功能需求的细节与客户的显式需要相符。通常，一个项目要经历很多的开发阶段，从启动项目和收集高级需求到设计、构建、测试、实施，再到支持和维护。用例是围绕一种迭代方法建立的，随着项目往后发展，该迭代方法会不断变化，不断添加一些细节。这很像数据库，我们需要通过重索引、修改触发器和存储过程等将数据库调优到最佳性能。如果相信用例需要第五层，通常要将软件设计过程细分一下，否则用例就会很大，就需要再去划分。
图 4 
在跟踪项目的进展以及判断当前构建的产品是否符合产品规范时，用例方法同样非常有帮助。
随着在用例上的工作越做越多，系统需求就会变得更加清晰，使得对象模型（Object Model）可以并行地更新，确保该模型（以及随后的实现）包含所有必需的类和类连环（interlink）。这样您将得到一个完整的模型，该模型完完整整地描述了所有达成一致的需求。
共享 UML 图
如今，几乎每个大型企业都在使用 UML，许多公司正在寻求与他们的业务伙伴共享和交换 UML 图的方法 —— 他们可能在不同的专有系统上创建他们的 UML 图。由于 XML 被公认为交换文档和其他信息的标准方法，因此大家都越来越有兴趣使用 XML 来交换 UML 图（不管创建这些 UML 图时所使用的工具是什么）。大家在这一方面的所有兴趣最终导致了 XML Metadata Interchange (XMI) 的诞生，XMI 使得分布式环境中建模工具之间元数据的交换变得比较容易。XMI 最初是由 IBM 和 Unisys 投资研发的，它是一套文件共享标准，用于使用 XML 共享 UML。XMI 标准中描述的 Meta Object Facility 包含了数据操纵的四个层：
1. User Objects (M0)，组成模型的组件或数据。
2. Model (M1)，模型本身。
3. Metamodel (M2)，对所创建的模型以及该模型行为方式的描述。
4. Metameta model (M3)，对元模型组织方式的描述。在 UML 中，为了完整解释建模案例（modeling case）或用例，需要用到描述的第二级。
通过这些层，XMI 使用 Model Object Framework 技术来遵循 OMG 标准。XMI 可用于生成文档类型定义（XML 用户眼中的 DTD）来描述图元素的语法，该文档类型定义可以在一个 XML 文件中使用。
接下来的一步
UML 为归档复杂系统提供了一个标准的、简单的框架，但是并没有提供管理实际的软件工程的过程。很多标准过程都是为管理软件开发而存在的。Rational 的 Rational Unified Process (RUP) 是 UML 最亲密的搭档，在软件开发社区已经得到了认可。
UML 提供了一系列不同的关于如何构建项目的蓝图。RUP 提供了一个过程，通过这个过程开发团队可以将蓝图所描述的系统付诸实施。RUP 包括对于开发视频、管理计划、识别风险、跟踪问题以及设计架构、业务案例，还有构建和测试、检验和评估以及管理和控制等步骤的指南。RUP 遵循标准的项目管理程序，但是它与软件工程开发过程关系更为紧密。
当今潮流
自从软件工程经典书籍 人月神话（Addison-Wesley, 1975 年）描述了软件设计过程的危机以来，整个软件开发实践已经经历了 25 个年头。Internet 时代的通信、大量可用的信息以及新 IT 项目的急剧增长，共同催生了从累积起来的教训发展而来的各种标准。
面向对象的开发以及相关的过程和工具都是从那些教训中得来的经过证明的东西。UML 为在一个快照中解释和简化软件开发过程提供了一种图表法（diagramming method）。RUP 概括了用于管理软件开发的、经过证明的过程。XMI 用于互相转换这些过程。随着这些实际上的标准进一步演化，软件开发实践将变得更加可靠和值得信赖。
关于作者
Michael S. Dougherty 从事系统级编程、应用程序开发和项目管理方面的咨询工作已经有 10 年了。他最近已与 D&L Consulting 合伙。可以通过 mikjza@kingwoodcable.com 与他联系。
