软件开发人员总是在困惑为什么软件分明是按照需求做出来的，可是客户为什么仍然不满意。客户总是在困惑为什么软件和自己想要的差距会那么大。这究竟是怎么回事？如何才能把开发人员和客户之间的沟壑填平？本文作为这个关于需求的软件工程专栏的第三篇，将向您介绍这个把客户和开发人员联系在一起的工具――UML（统一建模语言，Unified Modeling Language）。

一个软件系统的开发过程说到底是由客户提出需求，再由开发人员将之翻译成机器能够理解的语言，构建成系统，交付给客户使用。在客户看到软件的时候，客户通常会说一句话："哦，那正是我所说的，但那不是我想要的。"

即使是开发人员异常的尽责，花费大量的时间了解客户需求，依然避免不了出现上述的客户抱怨。更何况开发人员通常都想当然的认为自己已经了解了需求，并喜欢按照自己的想法给软件加入一些新特性（feature）。在这样的情况下，用户的"真正"的需求更加得不到保障了。

出现了什么问题？因为大部分的软件开发工作都是Program Oriented，而不是Customer Oriented。开发人员认为自己已经了解了客户的需求；客户表达不出或是表达不全自己的需求；开发人员抱怨客户经常修改需求；客户不明白软件开发为什么有如此多的限制…。所有这些，都是Program Oriented的软件开发模式避免不了的弊病。

归根结底，这些问题都是由于客户和开发人员的立场不同而导致的。

所以呢，在客户和开发人员之间，缺少一种东西来把他们联系在一起。因此，众多的方法学，都把这个问题视为重中之重。

1. UML
UML（统一建模语言，Unified Modeling Language）是一种面向对象的建模语言。在软件工业化方面做出了杰出的贡献。被OMG（Object Management Group）采纳为业界标准。

UML是解决上面这个问题的一个相当有代表性的例子。UML的实质，是一种沟通方法，象是英语能够解决把世界各地的人交流的问题一样。

2. UML起源
公认的面向对象建模语言出现于70年代中期。1989年到1994年是建模语言的战国时期，其数量从不到十种增加到了五十多种。虽然有利于学术的发展，但是对于终用户来说，了解众多的建模语言是一件非常没有必要的事。在建模语言的战国时期出现了三个强者：Grady Booch，James Rumbaugh和Ivar Jacobson（人称"The Three Amigos"），以及他们的方法：Booch 1993、OOSE和OMT-2。

Booch是面向对象方法早的倡导者之一，他提出了面向对象软件工程的概念。Booch 1993比较适合于系统的设计和构造；Rumbaugh提出了面向对象的建模技术（OMT）方法，采用了面向对象的概念，并引入各种独立于语言的表示符。这种方法用对象模型、动态模型、功能模型和用例模型。 OMT-2特别适用于分析和描述以数据为中心的信息系统；Jacobson于1994年提出了OOSE方法，其大特点是面向用例（Use-Case），并在用例的描述中引入了外部角色的概念。用例的概念是精确描述需求的重要武器，但用例贯穿于整个开发过程，包括对系统的测试和验证。OOSE比较适合支持商业工程和需求分析。

天下大势，分久必合。Grady Booch，James Rumbaugh和Ivar Jacobson三个人的方法各有所长，而用户有希望能够有一种标准出现，结束混乱的百家争鸣的现状。1994年10月，Grady Booch和Jim Rumbaugh开始致力于这一工作。他们首先将Booch9 3和OMT-2 统一起来，并于1995年10月发布了第一个公开版本，称之为统一方法UM 0.8（Un ified Method）。1995年秋，OOSE 的创始人Ivar Jacobson加盟到这一工作。经过Booch、Rumbaugh和Jacobson三人的共同努力，于1996年6月和10月分别发布了两个新的版本，即UML 0.9和UML 0.91，并将UM重新命名为UML（Unified Modeling Language）。1996年，一些机构将UML作为其商业策略已日趋明显。UML的开发者得到了来自公众的正面反应，并倡议成立了UML成员协会，以完善、加强和促进UML的定义工作。当时的成员有DEC、HP、I-Logix、 Itellicorp、 IBM、ICON Computing、MCI Systemhouse、Microsoft、Oracle、Rational Software、TI以及Unisys。这一机构对UML 1.0（1997年1月）及UML 1.1（1997年11月17日）的定义和发布起了重要的促进作用。

UML是集合了众家之长的建模语言，从诞生的那开始，经过了不断的验证和修改，它着重强调的是一种标准的建模思想，但它并不是一种标准建模过程，对于不同的软件企业来说，建模的过程是不同的。UML并没有特定的平台，与具体的实现无关。它是一种图形化的面向对象建模语言。UML通过不同的图形表示来捕捉系统静态结构和动态行为的信息，建立起对象模型。不同的图形是从不同的角度来看待系统。由于UML的独立性，所以它可以通过专用的工具转化成具体的编程语言，或是从编程语言代码转回UML，这叫做"逆向工程"。

3. UML是什么
UML的概念包括了UML语义（Semantics）和UML表示符（Notation）两个部分，UML语义定义了结构（Structural）模型和行为（Behavioral）模型。结构模型（又称为静态模型）强调系统的对象结构，如对象的类（Classes）、接口（Interfaces）、属性（Attributes）和关系（Relations）；行为模型（动态模型）关注的是系统对象的行为动作，如对象的方法（Methods）、交互（Interactions）、协作（Collaborations）和状态（State Histories）。以此为基础，UML为UML表示符提供了完整的语义定义。UML的表示符包括了下面的几种主要的图：类图（Class Diagram），用例图（Use Case Diagram），顺序图（Sequence Diagram），协作图（Collaboration Diagram），状态图（State Diagram），活动图（Activity Diagram），部署图（Deployment Diagram）语义由于我们的讨论重点并不是UML语言，我们只是简单的介绍UML的实际应用，如果大家对UML有兴趣，可以参看《UML1.3白皮书》。

4. 用例图和用例
用例图（Use Case Diagram）是UML中简单也是复杂的一种图。说它简单，是因为采用了面向对象的思想，又是基于用户视角的，绘制非常容易，简单的图形表示让人一看懂。说它复杂是因为用例图往往不容易控制，要么过于复杂，要么过于简单。一个系统的用例图太泛不行，太精不行，太多不行，太少也不行。用例的控制可以算是一门艺术。突然想起当年我刚刚接触UML的时候，对用例不屑一顾，认为是UML中无用的一种图，现在每每想到不禁感慨自己的愚蠢。

Use case diagrams show actors and use cases together with their relationships.『OMG-UML V1.3』

用例图表示了角色和用例以及它们之间的关系。

A use case is a kind of classifier representing a coherent unit of functionality provided by a system， a subsystem， or a class as manifested by sequences of messages exchanged among the system and one or more outside interactors (called actors) together with actions performed by the system. 『OMG-UML V1.3』

用例描述了系统，子系统和类的一致的功能集合，表现为系统和一个或多个外部交互者（角色）的消息交互动作序列。

有点复杂是吗，是角色（用户或外部系统）和系统（要设计的系统）的一个交互，为了实现一个目的（Goal），这个目的的描述通常是一个谓词短语，例如，开立信用证，给客户回单等。用例图则图形化的表示了这种关系。

一个具体的用例图可能是这样的：


　

5. 用例和需求，用例和过程
可以说，之前说的所有的东西都是为了能够导出用例在需求中的作用。用例是从用户的角度看待系统，而不是基于程序员的角度。这样的话，用例驱动的系统能够真正做到以用户为中心，用户的任何需求都能够在系统开发链中完整的体现。用户和程序员间通过用例沟通，避免了牛头马嘴的尴尬局面。