从学生时代就接触到UML，几年的工作中也没少使用，各种图形的概念、图形的元素和属性，以及图形的画法都不能说不熟悉。但是怎样在实际中有效地使用UML使之发挥应有的作用，怎样捕捉用户心中的需求并转换成明确的UML图形，怎样把自己心中的设计意图通过UML图形准确地表达出来，以及各职责人员如何通过UML图形进行有效沟通，关于这些，却深感迷茫。
最近有幸得到了一个台湾人赖信仁写的《UML团队开发流程与管理》这本书，才拜读了前两章，就已经爱不释手了，颇有点欣喜若狂的感觉，看了半本书之后，上述的种种疑惑均已雾开云散了。
这本书与我之前看到过的任何一本UML的书籍都不同，它并没有详细介绍每种UML图形的各种元素和属性，而是重点讲述每种UML图形的使用场景，以及具体项目过程中如何进行分析和设计，并使用相应的UML图形精确传达设计意图。也就是说，它不是讲述UML是什么，而是结合具体项目实战讲述UML图形应该何时用、以及怎么用。
书中共有三个部分，第一部分结合一个完整的按钮“信仁医院住出院系统”逐个讲解UML2.0的14个图形，讲解每个图形的最佳使用场景以及如何构思和绘制图形；第二部分结合另一个完整的案例“电子化采购系统”，讲解以UML驱动的整个从分析到设计到编码到测试的全过程；第三部分则是关于如何将UML应用于团队合作当中。
本文将采用两个案例进行实例演示：
【电子化采购系统】案例背景介绍客户企业是一家大型家电制造商，主要业务是制造和销售家电产品。客户企业的信息系统包括了一个大型ERP。因为想要厂商提供更加即时快捷的服务，客户企业委托设计一个电子化采购系统。
【信仁医院住出院系统】案例背景介绍信仁医院是一家区域医院，共有200张病床，医院的只能科室包括内科、外科以及皮肤科。该医院在2000年采购了一套医院内部的医院管理系统，其中包括门诊系统、挂号系统、收费管理系统、医保申报系统以及财会系统。以往，信仁医院在办理住院出院时都必须使用人工填表的方式，只有在医保给付、门诊医嘱以及收费管理方面，才能进入医院管理系统进行记录。但为了实现“e化医院项目”，信仁医院需要重新设计一整套住院、出院系统。
这个阶段，也就是相当于传统软件工程中的问题定义和可行性研究，这个阶段主要是通过与用户的访谈，以确认待开发系统“要做什么”，并进行可行性研究，简单来说就是从企业的角度出发研究这个项目是否能做、是否能盈利，否则最终项目失败那对企业就会造成损失了。
项目开始阶段的初期访谈需要抓住以下几个重点：
上述四个重点，其实在一开始就决定了项目是否会成功，如果在项目开始时就落入了细节性的讨论，反而容易造成项目的失败，对于开发团队来说不可不慎。
本阶段结束之后，如果正式立项，那么便进入下一个阶段——需求分析。
需求分析阶段，主要是跟客户（领域专家）沟通，进行需求的收集和分析，然后通过标准的文书准确地表达出来，并形成需求规格说明书之类的文档，交由设计人员进行后续的系统设计工作。
UML中的用例图正是用于需求收集和表达的有力工具，但是如何找出用例并非易事，这是因为从用户那里收集来的信息很可能是零散的、没有系统性的，要直接从中找出正确的用例非常困难。
因此在分析用例之前，可以先对企业级的业务流程进行规划和设计，抓住企业的本质工作流，为后续进行详细的需求收集和用例分析做好准备。
对于企业的经营管理团队来说，业务流程规划与企业的永续经营之间存在着密切关系。简单来说，业务流程就是为了服务客户而执行的一连串业务内部活动。业务流程分析的目的在于了解整体流程对企业目标的支持分别有何贡献，进而对流程的细节进行规划。
那么如何进行业务流程的设计呢？Jacbson认为，利用“用例”的“目标导向”特性，可以通过一个“企业级的用例”来完善工作流程的规划与设计。不过衡量实际状况，大部分领域专家对“用例”的接受度较差，因此可以使用另一个工具来进行企业的建模，这个工具是由Erickson和Penker所提出的一个活动图的构造型，称为“Eriksson-Penker业务扩展模型”。
★Eriksson-Penker业务扩展模型示例
在与领域专家进一步沟通后，就可以对“Eriksson-Penker业务扩展模型”中的每一个“处理”绘制一个对应的活动图，在绘制活动图时，应该将重点放在“活动”本身，而不需要加入其他因素（文件、数据、表单等）。在活动图中，这些因素应该要在上层的“Eriksson-Penker业务扩展模型”就表达完成。
活动图的使用场景：
在设计活动图时需要遵循以下原则：
关于设计活动图时的两点重要建议：
★表达业务流程的活动图示例
在完成各主要业务流程的分析，绘制出活动图以后，便可以开始下个分阶段的工作——从业务流程中找出用例，进行需求收集，完成用例模型。
根据前面所绘制的业务流程的活动图，可以通过以下三个步骤找出用例：
将活动图中的每个“活动”当作“用例”的候选，接着针对每个”活动“询问用户以下几个问题：
编写用例叙述时遵循的原则：
替代流本身仅仅只是正常流的“分支”而非“主干”。举例来说，如果在正常流2有三个替代流，则在替代流的区块中，就会有2a、2b、2c三个分支，而在这三个分支的编写中，仍然必须遵循着每一句都是“肯定句”的原则。如果在其中又有替代流，则一样必须要利用分支的方式来编写。这样，由于每个叙述都是简短的肯定句，自然而然增加了未来的扩展空间。
配合“迭代增量”的开发方式，这三个步骤不是一次就全部完成，而必须要分批完成。
用例的叙述是非常关键的部分，必须能够准确地把握用户的真正期望是什么，后续的设计工作都将围绕用例特别是用例叙述来展开。
一般来说，在找出用例后就应该编写用例的测试案例，测试案例的编写主要利用“输入→预期产出“的方式来描述，每个测试案例都需要准备对应的测试数据。
前一阶段的主要产物是用例图，后续的设计和开发阶段都将以用例驱动，围绕用例展开，而系统设计阶段的主要工作，便是实现用例。
实现用例的目的在于保证系统的设计可以满足用户的功能性需求，在实现用例的过程中，应该利用Jacobson所分类的三种分析类：
①针对每个用例提供一个“控制对象”②明确这个控制对象的责任（Responsibility）是什么从“主执行者”在正常流的叙述中出现的次数来决定系统要提供几个服务；再从每一个“对话块”中，“系统”当主语的最后一句话，找出这个责任的名称。③明确这个服务的输入输出判断这个服务中，是否需要“主执行者”提供什么信息，而“系统”又需要回复主执行者什么信息④进入到服务内部，审视服务的实现方式在控制对象的内部，每一个以“系统”当主语的叙述都可以独立成一个新的功能函数；只是该功能函数并非是提供给主执行者的，因此是一个“私有”的函数，只提供给控制对象使用。
针对前面用例图中的第一个用例“产生请购需求（RFP）”，我们可以提供一个“产生请购需求（RFP）控制对象”。
“产生请购需求（RFP）”的“正常流”叙述：
(1)ERP系统提供[年度物料采购计划]给系统。(2)系统根据[BR1]产生[厂商询价推荐名单]。(3)系统依照[厂商询价推荐名单]请通知系统将[物料请购需求]传给名单上的厂商。
分析过程如下：
从（1）得知“主执行者”是：ERP系统；
“主执行者”总共出现了1次，也就是所只有一个“对话块”，所以系统要提供1个服务；
“对话块”中“系统”当主语的最后一句（3），可得知系统所需提供的服务是：产生厂商询价推荐名单；
从（1）可知服务的输入是：年度物料采购计划；
从（3）可知服务的输出是：厂商询价推荐名单；
从（2）可知服务内部必须完成的第一件事：根据[BR1]产生[厂商询价推荐名单]；
从（3）可知服务内部必须完成的第二件事：依照[厂商询价推荐名单]请通知系统将[物料请购需求]传给名单上的厂商；
所以从上面两步可知控制对象内部需要两个“私有函数”。
前面探讨了如何找出信息系统中所需的控制对象，但这样仍然不够，因为前面并没有完整描述出究竟对象与对象之间是如何通力协作，来满足用例所描述的用户需求。因此，必须要使用序列图来说明这个交互过程。
在绘制序列图时，可以采用两阶段序列图绘制法：
①把信息系统当黑箱，利用用例叙述找出系统所应负责的服务。
这个步骤可以先绘制一个序列图，然后把用例叙述放在该序列图的右方（这样便于对比），然后参照用例图，把相对应的用例转换为一个叫做“系统”的对象。
②把黑箱打开，加入找出的分析对象，并把系统所需实现的责任分配给适当的对象。
把上个步骤得到的“黑箱”序列图中的“系统”换成实际的控制对象，并且依据找出的控制对象的责任，看看是否一致，这样就完成了序列图的设计了。
★控制对象的“黑箱”序列图示例
总之，实体对象主要是根据对于问题领域的理解来找出问题领域中的重要概念，对于实体对象的分析，无论是对于进行“实体关系图的”的数据库设计，或是利用“对象模型”做的“结构分析”来说，都是相当重要的设计准则。
实体对象属于领域模型的重要概念，将在下一节“建立领域模型”中重点讲解。
①通过对用例的理解以及对用例叙述的分析，找出系统的控制对象及其操作。
②通过与领域专家的访谈过程，找出系统的实体对象以及重要熟悉。
③设计人员利用两阶段绘制的序列图，验证前述的控制对象及操作的正确性。
前面通过三种分析类实现用例的方式，会从用例出发分别找出控制对象、实体对象和边界对象，在找出这些“对象”（这里的对象并非指类的实现，而是指一种分析类）之后，便可以建立完整的“领域模型”了。
要了解领域模型，就要先了解何为软件的“本质”：“本质”指得就是要想办法直指想要解决的问题的“核心”。
从软件结构的层面来看，“本质”指的就是你所要解决的问题领域中的重要“概念”在抽象层次的呈现。一般来说，这样的呈现方式的会通过“概念模型”来表示。“概念模型”就是能够用最简化的方式表达一个完整的“问题领域”的抽象表示法。概念模型的原始定义是表达问题领域中的概念，因此，通常将概念模型称为“领域模型”。
在UML中通常建议使用“类图”作为表达领域模型的图形。类图主要表达的是问题领域的“抽象概念”，在这个抽象概念中，除了表达该抽象概念的名称外，另外需要表达该抽象概念的“属性”与”行为”。类图的主要目的是在进行软件开发前，先对软件所需面对问题领域的本质作一个通盘性的了解，但类图在软件设计之初并不完全正确，必须通过后续的检查才能够逐渐趋近于真实世界的领域模型。
接下来将采用信仁医院住出院管理系统的案例来进行演示，为了分析和设计流程的连贯性，将从业务流程分析的部分开始。
在得到用例图之后，便进入实现用例的阶段，可以通过上一节所介绍的三种分析类找到问题领域中的重要概念，从而得到领域模型，然后通过类图来表达。
通常领域模型中会包含很多的类，必须对这些类进行分类，放置在不同的命名空间中，利用命名空间之间的关系图，来限制住不同分类对象之间的访问，这就是“包图”的使用场景。
“包图”是一个高阶的视图，由于所有的类都必须属于某一个包，因此当包之间的关系被限定时，该包内部所有的类，都会受到包图中设置的影响。
★住出院系统包图
一般来说，我们在用例分析中将系统应该满足的用户期望找出来了；而在类图中则将系统的架构构造出来。但是，针对每个特定的用例的场景，要如何利用类图所规范的对象，通过交互协作来完成用例所交付的任务，就必须要用序列图来表达。
序列图的主要任务包括：
绘制序列图的两点重要建议：
★登记出院记录序列图
验证领域模型正确性
从前面的类图来看，“登记出院记录BPO”是与“住院事件”想关联的，但在序列图中，“登记出院记录BPO”却是和“病床”有消息传递，这似乎并不符合类图所表达的领域模型。我们可以进一步通过另一个表达对象交互协作的通信图来进行验证。
通信图与序列图其实都是在表达同一件事情：对象相互合作，以实现用例的“事件流”。
为什么要使用通信图进一步验证呢？
究竟项目设计人员在设计序列图时，心中是否对象模型，因此希望项目设计人员能利用“通信图”来重新审视自己对对象模型的理解，来确认序列图有没有违反领域模型。
在绘制序列图和通信图等交互图时，需要注意：
那么，这些分散的交互图怎么才能组合在一起呢？这时可以利用交互概述图。
对象图的使用场景：当与领域专家沟通时，可以用对象图解释类图的设计，以验证类图的正确性。当与编码人员沟通时，可以利用部分的对象图，来解释类图中的复杂结构。
★住出院系统对象图
类图中某一个实体对象，它的状态迁移分散在不同的用例中，需要在这些状态和事件之间进行一番整理，才能让项目开发人员更简便地完成设计，这时可以使用状态机图来表达。为了成功地设计软件，将“状态”分配到不同的“领域模型”中，并利用“状态机图”来表达这些状态的迁移情形。
★病床状态机图
到此为止，本文已经讲解了需求分析阶段和系统设计阶段使用的主要UML图形，除了这些图形之外，还有以下UML图形，本文不做详细介绍：