UML的奥妙 - 学习UML笔记(1)

 

前两天买了一本《大象 Thinking in UML》，其实本就有学习UML的念头，但都因这样那样的事儿耽搁了，当然，也有些惰性在作祟......

闲话少说，这本书看完了一章，发现还是不错的，先把这两天的学习情况总结一下：

一、UML来龙去脉的第一章：

从现实情况而言，面向过程方法在复杂度不是很大的项目中应该说是适用的，但是对于规模较大、复杂度较高的项目而言，应该尽可能考虑面向对象的方法，也就是OOA/OOD/OOP。

=>说明方法方式是死的，活学活用+实践总结才是正解。

面向对象的方法的重点和难点在于抽象、如何抽象才能贴近现实之需？我们需要解决及面对以下三点问题：

1）现实环境怎样映射到对象环境？

2）用对象的角度怎样来描述现实环境？

3）怎样验证对象环境的描述是正确反映了现实环境的实际的？

当然，答案就是UML，确切地说，UML是工具，我个人觉得作者应该在这个时侯先不紧跟着就提UML，应该先说说RUP，在说UML会比较好。我的理解是：要回答上述三个问题，答案应该是各种软件工程方法，比如RUP，同时运用的工具是UML，这么理解比较好。

UML中，有用例（use case）、类、包等等，称之为元模型；规则和图形称之为表示法或视图（View）。

一般整个建模的过程是：

1）先从现实世界->业务模型：

 整个面向对象方法围绕这这四个基本因素：人、事、物以及规则。

 这时候用例即事（要实现的业务目标），参与者（actor）即人，业务场景（business scenario）和用例场景（use case scenario）是规则，业务对象模型（business object model）是物。

2）业务模型->概念模型：

上面的业务模型就是开始，得到了业务模型后，要把业务模型转换为计算机能够理解的模型：先过渡到概念模型吧。

UML通过概念化的过程（conceptual）建立分析模型，分析模型向上映射了原始需求，向下为计算机实现规定了高层次的抽象，承上启下。

人：用户，边界类（boundary）：事，实体类（entity）：物，控制类（control）：规则。

概念模型描绘出了软件蓝图，比如造汽车，已经在图纸上绘制了汽车所有的零部件，以及如何组装这些零部件的步骤。

3）概念模型->设计模型：

汽车蓝图描绘出来后，就是样建造零部件，以及生产汽车了。

从软件开发角度而言，就是要把概念模型实例化，实例化的情况因使用的技术不同而不同，如选择的软件架构和框架、选择的语言实现、中间件等等，不同的技术有不同的实现，这很容易理解。

 

经过上述3个步骤，就回答了前面的三个问题，就是贯穿各个阶段，使用UML工具来加于辅助解决。

接下来介绍RUP：统一过程。

说明了RUP和UML的关系，是紧密的，但不是一回事儿，这很重要，RUP是一个软件开发过程中的庞大知识体系，是内功，UML是语言，是招式或武器，RUP中大量使用UML，但UML并不是只能在RUP中使用。

好了，今天先到这里吧，后面继续......