UML学习之路（1）

学习面向对象的语言也有不少的时日了，看到过不少大牛们带着我们这些新人做项目，特别是系统比较庞杂的项目时，我就会对大牛们产生无比的敬意，我很难想象他们是如何在一段时间里，就能把一个很复杂的东西，抽丝剥见般的弄得如此透彻。我相信一方面是因为他们的天才和努力，而另一方面他们的确是靠着一些有用的工具做到了这一点。其中有一个工具让我印象深刻，以为这个在软件设计的前期，用到的频率令人咋舌，当然我说的是面向对象的开发，它就是鼎鼎大名的UML。

我是一个不求麻烦只求上进的人，O(∩_∩)O~所以为了成为一个小牛，俺也必须得好好努力，学好UML设计才行。开始一些废话，是说给自己和大家听得，稍微让大家有点激情呵呵。因为这毕竟是我记录的第一篇，上战场前大家互相勉励吧。让咱们成为一名优秀的软件工程设计师来加油吧

在OO与UML成了不可阻挡的潮流之后，程序员大量使用C++和Java等OO语言，同时也进一步带动设计师使用UML来表达OO设计。所以设计师拿到系统分析文件后做的第一件事，便是将非OO文件转成OO的UML图，随后才进行复杂的设计，并生成各式的UML图，交由程序员按图编码。

UML尽管无法根除本质性的难题，但是可以减轻分析的压力。对策如下：

1.使用UML引导访谈，降低遗漏需求的情况。UML提供10多款不同功能的图，可以让系统分析员在访谈过程中，通过多款不同的图来理清需求各种不同角度的面貌，降低遗漏。而且，每款图都有它独特的组成图标，在绘制每一个图示时，都将引导系统分析员提出适时且重要的问题，一遍搜集与理清需求。

2.快速生成可执行的程序片段，以便搜集与理清需求。

3.封装变化，让需求发生变化时，可以追踪到变化之处，迅速改版，并且不让变化起到涟漪效应，向外扩散。

所以，我们要学习多款UML图，并且在编写需求时，不仅得生成让用户签字的文件，还得同时生成让设计师能接续设计的UML图件。

1.UML图

UML有两大类：行为图（Behavior Diagram）与结构图（Structure Diagram）。

BD将引导设计者分析且理清“系统该做些什么”，在绘制行为图时，可以聚焦在系统多方面的动作，像是系统与用户之间的交互，或者是某种对象以为事件的刺激以至于发生某些反应动作，以及一群对象交互完成某项服务等等。我们可以通过这些不同功能的行为图，获知系统多方面的行为。

主要会有如下所示的UML图，他们都属于行为类：

1）用例图（Use Case Diagram）

2）活动图（Activity Diagram）

3）状态图(State Machine Diagram)

4）序列图（Sequence Diagream）

结构图将引导我们获知“系统的重要组成元素是什么”，通常，通过结构图将引导我们理清业务里（Business）的专有名词，以及专有名词之间的关系，以此作为系统的核心结构。

UML中的类图（Class Diagram），属于结构图。

2.OO与UML

OO与UML就类似于表里关系，OO概念是我们头脑里的概念，而UML则是这些OO所设计出来的图形。

2.1 对象

真实世界由琳琅满目的事物组成，但并非所有事物都是和对象成对象。对于我们，候选对象应该同时符合以下两个条件：

1）在企业运作过程中个，业务人员会使用到的专业事物或者概念。

2）在信息化时，系统也会用到或者需要保存。

在访谈业务人员时，可以提出类似下属问句，以便获知重要的对象。如：

1）在执行这项工作时，你们会用到哪些专业概念？（探问对象）

2）你们在执行这项工作时，会需要哪些数据？（探问对象）

诸如此类的问句，有助于找到重要的对象。软件公司可以多向资深的系统分析人员搜集此类的问句的答案，甚至编写成通用的工作手册。

2.2 属性与操作

当试图去了解真实世界中任一事物时，有多元的角度可以去探寻。不过，我们并不需要这样深入了解对象。对于任何一种对象，系统分析员只需要针对下列两个问题进行探寻：

1）对象需要记录哪些属性（Attributes）？

2）对象可以提供哪些操作（Operations）？

举个例子：系统分析人员向业务人员如下提问：

1）某物会记录什么数据呢？（探问属性）

2）某物可以提供我们哪些数据呢？（探问属性）

3）通过某物，我们可以查到哪些数据呢？（探问操作）

4）有了某物，我们可以拿它来做什么呢（探问操作）？

2.3 操作与方法

针对对象的操作，系统分析员还必须进一步探问how，了解操作的实现方法（Method）。简言之，操作时对象的what，而方法则是对象的how，我们其实就是想获知业务人员惯用的操作方法，然后将人为的操作方法转移给对象，成为对象的操作方法。

系统分析员访谈业务人员时，主要获知方法的执行步骤（Procedure），所需或者产生的数据，计算公式，以及企业的特殊约束。

2.4 封装

尽管事物所蕴含的细节被封装（Encapsulation）起来，我们还是可以使用它们。当我们打造软件对象来仿真真实世界，也应该模拟这种封装性。由于软件对象的封装性，所以对象之间仅透露足以进行交互的底限信息。对于对象的封装性，我们要掌握以下要点：

1）已知操作。对象通常仅对其他对象透漏自身的操作，彼此之间通过调用（Call）已知的操作来交互。

2）封装属性。每个对象封装属性值，不透露给其他对象。

3）封装方法。每个对象封装方法，仅对其他对象透露操作，但不透露其方法。

因此，我们要特别注意，在分析规划对象的方法时，如果需要与其他对象进行交互，甚至使用到对象本身的属性或者操作时，我们要严守三条：

1）不得直接提及对象的属性；

2）不得假设对象的执行方法；

3）仅仅能够使用对象的操作。

严守对象的封装性，有一个莫大的好处就是当需求发生变化时，变化都会被局限在对象的属性和方法中，不会起涟漪效应，也不会发生牵一发而动全身的连锁反应。就如同你喝易拉罐饮料，非得打开个口对着口喝，不能直接畅饮，但是至少不会打翻后见得到处都是。

2.5 类

“物以类聚”点出了对象（Object）与类（class）之间的关联。归结起来，类与其对象之间的细微关联如下所示：

1）类定义属性与操作，且所属（对象）共有这些属性和操作。

2）虽然同类（对象）共有属性，可是每一个对象却又独有属性值。

3）因为同类对象共有操作和方法，所以他们可以做相同的事情，而且有相同的做法。

4）类也会定义关系（Relationship），且所属对象共有这些关系。不过每一个对象也可以有独有的关系。

2.6 泛化关系

有些时候同类的一群对象并不全然相同。可能大部分属性和操作相同，但是少部分的属性和操作却不同。在这种情况下泛化关系（Generalization）就派上了用场。

我们可以通过检查下列两项条件，判断是否采用泛化关系：

1）在企业领域的专业概念里，特殊对象必须“是一种”（a kind of）一般对象。

2）多种特殊对象里，有部分通用的属性与操作，也有部分独有的属性与操作。

在泛化的过程中，我们将特殊类里通用的属性和操作记录到一般类里，因此通过泛化关系，特殊类可以继承（Inheritance）一般类的通用属性与操作。由于特殊类通过继承，可以直接重用（Reuse）一般类里的属性，操作与方法，节省开发成本。所以当发生变化需要改版时，也只需要改动其中一个，节省维护成本。

2.7 关联关系

类之间最常见的关系就是关联关系（Association）。系统分析员可以通过检查下列两个条件，判断是否采用关联关系：

1）在企业领域的专业概念里，两种对象之间有一种固定不变且需要保存的静态关系。

2）在信息化时，系统会用到这些静态关系，而且必须将他们存进数据库里。

2.8 聚合关系

聚合关系（Aggregation）是一种特殊的关联关系，所以它继承了关联关系的特质，而且还独有“整体-部分”（Whole-Part）的特质，简而言之，聚合关系两端的对象，需要具有Whole-Part的关系。可以根据下列三个条件来判断聚合关系：

1）在企业领域的专业概念里，两种对象之间有一种固定不变且需要保存的静态关系。（继承自关联关系的条件）

2）在信息化时，系统会用到这些静态关系，而且必须将它们存到数据库里。（同上）

3）在企业领域的专业概念里，两种对象之间有Whole-Part的静态关系。

2.9 组合关系

组合关系（Composition）是一种特殊的聚合关系，所以它继承了关联关系，以及聚合关系的“整体-部分”的特质，又还具有独有全然拥有Part对象的特质。可以通过以下四项，判断是否采用组合关系：

1）~3）都同上

4）Part对象只能连接一个Whole对象，且Whole对象被注销（Destroy）时，Part对象必须一块被注销。（独有条件）

2.10 用例与执行者

用户以为某种目的而是用系统，这样的一段交互（Interaction）过程，就是一个用例（Use Case）。而且，因为用户在这过程中会与系统交互，参与用例，所以特别称为执行者（Actor）。

采用用例的技术，可以引导我们站在用户的角度来描绘系统，开发出用户合意的系统。用户通常在意系统的What，而不是系统的How。他们只需要知道系统提供什么样的服务，以及该如何与系统交互才能获取这些服务。

2.11 业务用例与系统用例

用例可以用来表达用户与信息系统（System）的交互过程，也可以用来表达顾客与企业组织（Business）的交互过程，为区分两者，前者就成为系统用例（System Use Case），后者就成为业务用例（Business Use Case），当然执行者也就区分为系统执行者（System Actor）与业务执行者（Business Actor）。

比如有些投资人不会是用计算机，所以就不可能是用网上基金系统去申购基金。这些人回到银行柜台办理，其间的交互就是一项业务用例。在系统开发初期，系统分析人员将定义并描述业务用例，不过不是全部的业务用例，而是日后系统会涉及到的业务用例。接着，系统分析员进一步分析每一个业务用例内部的执行活动，从中圈选出可以交给系统执行的活动，并将这些可自动化的活动定义为系统用例。接着，这些系统用例将引导整个开发程序。通常，项目会从中挑选出一批系统用例作为首次发布（Release）的范围，随后系统分析员才针对这些系统用例进行深度访谈，理清需求细节且编写文件，递交给其他开发人员进行后续的系统设计和编码工作。

3.MDA开发程序

采用MDA（Model-Driven Architecture）开发程序，我们要进行分析工作，以及生成UML模型的依据。MDA与UML同为OMG（Object Management Group）机构之标准。MDA主要将生成的UML模型，分成下列三个阶段：

1）CIM（Computation Independent Model）-聚焦于系统环境及需求，但不涉及系统内部的结构与运作细节。

2）PIM（Platform Independent Model）-聚焦于系统内部细节，但不涉及实现系统的具体平台。

3）PSM（Platform Specific Model）-聚焦于系统落实与特定具体平台的细节。例如Spring .NET都是一种具体的平台。

MDA主张将设计切分为PIM和PSM。

3.1 程序

MDA项目开发的第一步骤从CIM开始，不同于PIM和PSM，CIM试图表达信息系统的应用环境而非信息系统本身。以银行的基金系统为例，CIM表达的对象是银行的基金业务及组织运作，而PIM与PSM则表达支持银行基金业务的信息系统。

开发MDA项目时，开发团队通产会先以CIM与抽象平台为信息来源，整合设计出PIM。随后才以PIM与具体平台为信息来源，整合设计出PSM

MDA甚至可以用于硬件的开发与设计。

3.2 分析步骤

依据MDA，这里学习的UML的设计归属于CIM与PIM阶段，如下所示：

1）CIM-1：定义业务流程，产生业务用例模型。

2）CIM-2：分析业务流程，产生活动图。

3）CIM-3：定义系统范围，产生系统用例图。

4）PIM-1：分析系统流程，产生系统用例叙述。

5）PIM-2：分析业务规则，产生状态图。

6）PIM-3：定义静态结构，产生类图。

7）PIM-4：定义操作及方法产生序列图。

在CIM阶段，系统分析人员大约花1~2周的时间，尽快生成初步的系统用例，以便相关决策人员可以从中挑选出首期开发的系统用例，这也就是首期的系统范围。随后项目进入PIM阶段，针对首期的系统用例详述细部规格，作为正式需求文件的一部分，也可作为业务人员与开发人员之间沟通的工具。需要注意的是，CIM阶段和PIM阶段的生成方式略有不同，只有CIM结束后才决定PIM阶段的系统范围，也同时进入了PIM阶段。但是，进入PIM阶段后，系统分析员将所有系统用例依相关性分成若干组，一组别的方式生成该组形同用例涉及的PIM-1~4结果，随后交给后续开发人员进行设计、编码和测试。

有点犯困了，第一阶段就到这里吧，期待后续的学习！