UML总结与实践(一)

      UML--统一建模语言，它作为一种描述软件设计的中间语言来说由于具有方便和一致性还是很有价值的，最近几年也是炒得比较热（以后可能的软件开发就可以靠它建立的模型直接生成某种语言的代码，当然现在UML工具也有这样的正项工程，但大多只能生成代码框架）。UML的内容感觉比较多，而且其工具使用起来也相对比较复杂（比如Rose和EA，都不是特别简单)，所以要想把UML真正的学好，用好，能给我们的编程带来方便，而不是仅仅是炒作式的学习还是要费不少功夫的。
      UML中个人觉得其最基本的是一些图的使用，所以我们在学习时最先要了解这些图，而且要分类的去考虑它们，UML在这方面也已经做好了。
     在UML中有视图(view)和图(diagram)两个层次的概念：视图是表达系统的某一方面特征的UML建模元素的子集，由多个图构成，是在某一个抽象层上，对系统的抽象表示；而图是模型元素集的图形表示，通常由弧(关系)和顶点(其他模型元素)相互连接构成。
     UML中的视图分为5大类(每一类的名称都有好几种说法，但表示的意思是差不多的，下面主要是按照EA中的分法）：
a)    用例视图(Use Case View)，强调从用户角度看到的或需要的系统功能，是被称为参与者的外部用户所能观察到的系统功能的模型图。

b)     动态视图(Dynamic View)，体现了系统的动态或者行为特征，也称为行为模型视图(Behavioral Model View)或并发视图(Concurrent View)。
c)    逻辑视图(Logical View)，展现系统的静态或结构组成及特征，也被称为结构模型视图(Structural Model View)或者静态视图(Static View)。
d)     组件视图(Component View)，体现了系统实现的结构和行为特征，也称为实现模型视图(Implementation Model View)。
e)     配置视图(Deployment View)，体现了系统实现环境的结构和行为特征，也被称为环境模型视图(Environment Model View)或者物理视图(Physical View)。

      在EA中还有一个Custom,其相当于设计者自己定义的一个视图，并不是UML的定义。

      UML中的图有9种：

a)     用例图(Use Case Diagram)，描述系统功能；

b)     类图(Class Diagram)，描述系统的静态结构；

c)     对象图(Object Diagram)，描述系统在某个时刻的静态结构；

d)     时序图(Sequence Diagram)，按时间顺序描述系统元素间的交互；

e)     协作图(Collaboration Diagram)，按照时间和空间顺序描述系统元素间的交互和他们之间的关系；

f)      状态图(State Diagram)，描述了系统元素的状态条件和响应；

g)     活动图(Activity Diagram)，描述了系统元素的活动；

h)     组件图(Component Diagram)，描述了实现系统的元素的组织；

i)       配置图(Deployment Diagram)，描述了环境元素的配置，并把实现系统的元素映射到配置上。

      在UML中视图是由图构成的，视 图和图之间的对应关系：
用例视图：用例图

动态视图：时序图、协作图、状态图和活动图
逻辑视图：类图和对象图 

组件视图：组件图
配置视图：配置图     

      在理清了UML中最基本的视图和图的概念定义之后，我们可以开始实际的使用它们来方面我们的设计和交流。按照《UML精粹》中的重点，在实际应用中我们使用的最频繁的是类图和时序图。下面就这两种图展开说明和学习。

     类图其实在画法上比较简单，在理解上也比较贴近我们实际的程序代码，当然我们在用好类图的前提是我们要弄清楚下面几种关系：

     关联，依赖，聚合，组合（以下是我个人的理解，与官方的说法在遣词造句上有些不同，个人感觉官方的说法不太好理解，还不如大白话，呵呵）。

     关联--类之间存在着引用关系，谁引用谁，所以关联有方向性，而且还有重数。简单的说A关联B，即A中有B的一个成员变量。

public   class  A
... {
private B b;
}

     

     依赖--类之间的一种使用关系，简单的说如果一个类向另一个类发送消息,或者一个类是另一个类的数据成员（不是成员变量）,或者一个类是另一个类的某个操作参数,则两者为依赖关系。

public   class  A
... {
public B getB(C c, D d)
...{
E e = new E();
B b = new B(c, d, e);
}
}

    这里类A就依赖于类B（方法返回类）、C和D（参数类）、E（方法内变量的类），因为这几个类的变化都有可能影响到类A。

    在这里有一点要说明的，由于在依赖关系中例如类B，它并不是A的成员变量，所以我们在利用实际的UML工具，如EA时当画出依赖关系后，在正项和逆向工程中都无法使图和代码想对应，这一点在现在的UML工具中比较不爽。

     聚合--聚合也是一种关联关系，与普通的关联不同的是，它描述的是一个整体和组成部分的关系，即“has-a”关系，意思是整体对象拥有部分对象，例如学校和学生的关系。聚合的整体和部分之间在生命周期上没有什么必然的联系，部分对象可以在整体对象创建之前创建，也可以在整体对象销毁之后销毁。

      实际上在用程序代码来表示关联关系和聚合关系时，两者比较相似。

public   class  Bicycle ... {
private Bell bell;
public Bell getBell()...{
return bell;
}
public void setBell(Bell bell)...{
this.bell=bell;
}
// 发出铃声 
public void alert()...{
bell.ring();
}
}

     组合--组合是比聚合更强的关联形式。组合是指带有很强的拥有有关系且整体与部分的生命周期一致的聚合关联形式。例如Windows的窗口和窗口上的菜单就是组合关系。生命周期一致指的是部分必须在组合创建的同时或者之后创建，在组合销毁之前或者同时销毁，部分的生命周期不会超出组合的生命周期。

     组合和聚合在代码实现上的主要差别在于生命周期的实现上，组成需要负责其部分的创建和销毁。另外还有一个差别是组合中的一个对象在同一时刻只能属于一个组成对象，而聚合的一个部分对象可以被多个整体对象聚合，例如一个学生可以在多个学校就读，而一个菜单在同一时刻只能是某个窗口内的对象。    

public  Class Window
... {
private Menu menu;
public Window()
...{
menu = new Menu();
}//可以在这时候创建Menu对象，也可以在之后创建
public void destory()
...{
menu.destory();
}//必须同时或者在这之前销毁关联的Menu对象
}

      总体来说，关联和依赖是同级的，组合是一种聚合，而聚合是一种关联。我们知道在Java的面向对象的体系中有个概念叫引用，而在UML中没有这个概念，但我们能发现在实现组合、聚合和关联时无可避免的要用到引用，但实现依赖时却不一定用到。       
      如果我们能真正理解上述四种关系，那么实际应用起类图来就很简单了。

      未完，待续.........