UML使用经验及总结
今天终于开始使用UML，用于项目分析，并且发现使用UML的时间开销并没有之前想象的那么大。
回顾使用UML的经历，总是断断续续。总结了一下，有以下因素：
- 没有使用UML的环境
- 没有抽象分析的习惯
- 没有充分的UML知识
面对复杂的项目，其实我们要做的只是抽象，抽象的方法有很多种，思路也是仁者见仁，智者见智，而UML给出了抽象的恰当模型。
我们将从以下几个方面，对UML知识，以实用为目的，做一个快速了解
- UML中的4+1模型
- UML中的依赖关系
- UML中的包
UML中的其它图例
- 活动图(Activity Diagram)
- 顺序图(Activity Diagram)
UML中的4+1模型
其实我个人对4+1模型并没有充分了解，在这里提及它只是为了对UML今后的深入学习埋下一个伏笔。
(4+1模型是一个叫Kruchten的人发明的，但网上还有其它版本的4+1 模型:Use case view, Logic view, Process view, Impementation View and Deployment View)
Logic View:对系统各个组成部分进行抽象描述，其焦点在于系统是如何构成的以及构成系统的各个部分之间是如何互动的。我们常用的类视图(class digram)，对象图(object diagram)，顺序图(sequence diagram)/通信图(communication diagram)都属于Logic View。
Process View:描述系统中的各种活动，典型的视图为活动图(activity diagram)。个人认为活动图和流程图非常类似，且目的都是为了将系统中的活动描述清楚
Development View:从开发者的角度描述系统的构成，典型的视图为构件视图(component diagram)
Physical View:该视图关注软件构件在硬件上的top结构，以及构件之间的通信。典型的视图为部署视图(deployment diagram)
Use case View:对系统用例进行描述，典型的视图为用例视图(use case diagram)
UML中的依赖关系
其实分析的本质就是在分析依赖关系。所以，搞清楚UML中对依赖关系的表示，就离使用UML实际建模不远了。(但是，很多UML教材似乎对此不重视，也许他们中的大部分人都不用UML来进行实质性的建模)。
依赖的紧密度由高到低
继承（Inheritance)
组合(Composition)
聚合(Aggregation)
关联(Association)
依赖(Dependency)
通过以上这些线条，将各个抽象的，具体的东西连接起来，最终形成我们常见的复杂的系统。
继承，关联，依赖这三个关系都可以在日常的代码中找到对应关系。
例如，继承关系的代码
class myClass1
{
public string Name{get;set;}
}
class myClass2 : myClass1
{
}
关联关系/组合关系的代码
class myClass2
{
public string Name{get;set;}
}
class myClass1
{
public myClass2 Obj{get;set;}
}
依赖关系的代码
class myClass1
{
...
}
class myClass2
{
void doSomething(myClass2 obj){}
void doSomething2()
{
myClass1 obj1;
...
}void myClass1 doSomething3()
{...} }
组合和聚合这两种关系，我个人认为更偏向于概念上的依赖关系。
组合关系
强调myClass1类型由myClass2类型组成，在代码的实现上，和关联关系类似。
聚合关系
强调myClass1类型拥有myClass2类型，反过来讲，如果myClass2类型不存在也不会影响到myClass1类型的存在。
UML中的包
包是表示系统功能结构的理想方式。在系统设计初期，可以在包的层面上对系统进行建模，然后以此为基础，将系统设计细化。映射到代码，包对应于namespace。
例如，我们通过以下的包，直观反映出系统使用服务的功能构架
活动图(Activity Diagram)
活动图通常配合Use Case使用，用以描述用例中，业务流程的更详细步骤。
顺序图（Sequence Diagram)
顺序图可以反映系统内部的互交，也可以反映构件之间的互交。顺序图和通信图(Communication Diagram)在大多数时候都可以互换，和顺序图相比，通行图显得更加紧凑一些，由于手里面的工具没有提供通信图的模板，所以只在这里提一下。
从上面的图中，我们可以发现，当我们用UML表示我们的系统时，总会有一部分信息会丢失掉。这当中可能存在很重要的细节，如果有，我建议另外体现。
对于一个复杂的系统，不可能将其每一个部分都用UML表述出来，作为构架师，其职责就是对其进行取舍。
参考资料
