【IT168 技术文章】
软件开发人员总是在困惑为什么软件分明是按照需求做出来的，可是客户为什么仍然不满意。客户总是在困惑为什么软件和自己想要的差距会那么大。这究竟是怎么回事？如何才能把开发人员和客户之间的沟壑填平？本文作为这个关于需求的软件工程专栏的第三篇，将向您介绍这个把客户和开发人员联系在一起的工具――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. 用例和需求，用例和过程可以说，之前说的所有的东西都是为了能够导出用例在需求中的作用。用例是从用户的角度看待系统，而不是基于程序员的角度。这样的话，用例驱动的系统能够真正做到以用户为中心，用户的任何需求都能够在系统开发链中完整的体现。用户和程序员间通过用例沟通，避免了牛头马嘴的尴尬局面。
从前，系统开发者总是通过情节来获取需求，是问用户希望系统为他做什么。在可爱的Jacobson发明了用例的概念之后，需求获取就变成问用户要利用系统做什么。这是立场不同导致的结果。用户通常并不关心系统是如何实现的（也有少数可爱的技术狂是例外）。对他们来说，更重要的是要达到他的目的。相反的，大部分的程序员的工作习惯就是考虑计算机应该如何实现用户的要求。所幸的是，用例方法能够调和双方的矛盾，因为虽然用例是来源于用户，服务于用户，但是它同样可以用于开发的流程。当系统的开发过程都是基于用例的，用用例获取需求，用用例设计，用用例编码，用用例测试的时候。这个开发过程就是用例驱动的。
在具体的需求过程中，有大的用例（业务用例），也有小的用例。主要是由于用例的范围决定的。用例像是一个黑盒，它没有包括任何和实现有关或是内部的一些信息。它很容易就被用户（也包括开发者）所理解（简单的谓词短语）。如果用例不足以表达足够的信息来支持系统的开发，就有必要把用例黑盒打开，审视其内部的结构，找出黑盒内部的Actor和Use Case.就这样通过不断的打开黑盒，分析黑盒，再打开新的黑盒。直到整个系统可以被清晰的了解为止。
用例是重要的，用例图只是用例的表达方式，其实用例的表达不仅仅是用例图，还有很多方式，我们在下面会具体讲到。
