UML培训总结

[转自http://www.uml.org.cn]

这两天参加了公司组织的UML培训，培训者是火龙果软件公司的老师。通过两天课程的学习，对UML的使用有了更系统，深刻的认识。

之前对UML的使用，仅限于画图，写文档，而且很多时候都是代码完成了再反向工程得到类图，根据类图画出顺序图，最后把UseCase补上，就完工了。和标准的使用顺序刚好相反，呵呵。

1.业务建模

在系统UseCase图之前，应该有业务UseCase图，主要是对业务需求的描述，它的 Actor称为Business Actor(业务Actor)，Business Actor可能最终并不是我们系统中的使用者，但是，从用户的角度，从提出业务需求者的角度，Business Actor是最直接能想到的，也是最重要的。例如，保险公司理赔系统中，Business Actor就是投保人，而实际上投保人并不会操作我们的管理系统，理赔专员，审核员，复核员等才是是系统Actor，但是在与业内人士确定需求时，肯定是以投保人为中心，投保人投保时需要提供什么信息，理赔时需要提供什么信息等。

有了业务UseCase图，就可以开始画活动图，也成泳道图，要尽可能详细，全面的描述客户的需求，此时并不用考虑哪些部分是系统实现的部分，关键在于能够把业务逻辑完整的表述出来。就是什么人(Actor)，做了什么事(业务事件)，产生了什么结果(业务实体，单据等)。注意，跨泳道的交互必须要有业务实体，即交互的数据。

2.需求建模

对活动图进行分析，得到系统UseCase图。就是要确定活动图中哪些业务事件是我们系统需要实现的，哪些部分是用户自己去做的。把系统需要做的业务事件归纳合并整理，得到UseCase，并对UseCase进行归纳整理。主要有三种归纳方法：include,extend和泛化。include是把重复的提出来；extend是备选流，对主业务流的补充，例如超市管理系统中，收银员收银这个UseCase，扫描仪无法扫描条形码，收银员手工输入就是备选流，查询不到商品信息的处理也是备选流；泛化是对过程类似的UseCase进行提炼，例如武松打虎，李逵杀虎，孙悟空打老虎三个UseCase，可以归纳出一个即打虎，只是行为人，实用工具，结果，方式不一样而已。

3.领域分析

从UseCase和活动图中找出类，主要有UI类，控制类，实体类，边界类(outerface)，画顺序图。顺序图是对象之间的交互，对象一定要包含实体类，与实体类的连线以后就是该实体的方法了，注意尽量把对实体中数据的操作作为该实体的方法。

顺序图完成后，就从中抽象，提炼出类。并不是我之前的操作过程，先设计类，再画顺序图，对于简单的业务逻辑，是可以这么做的，一旦业务逻辑过于繁琐，之前也没有接触过，也不理解时，就可见从顺序图提炼类图是多么的关键了。因为顺序图是从活动图来的，活动图直接对应的就是业务需求。

提炼类是注意分配职责给类，而不仅仅是数据，把职责和数据绑定到一起。GRASP职责分配模式：信息专家模式，创建者模式，高内聚模式，低耦合模式，控制器(协调者)模式，中介者。

类之间的关系有4种：依赖关系，关联关系，继承关系和实现接口。

依赖关系用虚线箭头表示，是方法级别的，类A在某个方法中使用了自定义类B，那么A依赖B；

继承关系是实现和三角形表示，实现接口用虚线和三角形表示，都是类级别的；

关联关系是属性级别的，类A的某个属性是自定义类B，那么类A和B就是关联关系，分为组合和聚合两种，如果B的实例必须在A中创建，不能单独存在，随着A的消亡和消亡，那么就是聚合关系，用实心菱形和实线箭头表示，如人和眼睛，就是这种关系。另一种，B的实例也可以独立存在，和A只是一种组合，生命周期没有必然的联系，是组合关系，用空心菱形和实线箭头表示，例如电脑和鼠标。

如果行为逻辑比较复杂，设计多次循环，多方协调，事件驱动，用流程图可能不好描述，或者业务规则比较负责包含多个维度，就需要使用状态图。

状态图有三种：基本，复合，并发。

如果某个类的多个属性都含有状态，即有多个维度的状态，就需要用到复合或者并发了。

原则：把复杂问题简单化，简单的业务逻辑，很容易理解的，完全可以不画，但是对于负责的逻辑，尤其是涉及到算法的业务，必须要画出，只用分析设计，画图了，才能理清业务规则和关系，再进行提炼，合并和重构，就能化繁为简，也能方便日后的维护。

4.面向对象设计

先划分子系统，因为需要从用户的角度建立功能划分，再设计层，每个子系统可能有自己的层次结构，最后设计类和包。

组件图，部署图就在这一步完成。