UML基本概念教程（2）

第二章 Hello World


记得在学习C语言的时候，教科书上的第一个程序就是叫Hello world，一个在屏幕上简单地打印出“Hello world!”语句的例子。在系统的学习UML语言之前我们来看一个简单的例子，让大家有一个系统的认识。

在java中一个在浏览器中显示“Hello World!”的Applet代码如下：
import java.awt.Graphics;
class HelloWorld extends java.applet.Applet{
public void paint( Graphics g ){
g.drawString("Hello World!", 10,10 );
}
}
代码的第一行：
import java.awt.Graphics;
使得程序可以使用Graphics类。前缀 java.awt指出了类Graphics所在的包。
第二行代码：
class HelloWorld extends java.applet.Applet{
从Applet类派生出新的类HelloWorld，Applet类在java.applet包中。
接下来的三行代码：
public void paint( Graphics g ){
g.drawString("Hello World!", 10,10 );
}
声明了类HelloWorld的方法paint，在他的实现中调用了另一个方法drawString来输出“Hello World!”。
我们可以很直接地为这个程序用UML建立模型。如图2-1。
 



图 2-1 HelloWorld

图2-1表达了最基本的HelloWorld模型，但它还有很多东西没有表示出来。在我们的程序中Applet类和Graphics类的使用是不相同的。Applet用作HelloWorld类的父类，而Graphics类用在方法paint的实现中。在UML模型中可以将这些关系表示为图2-2:



图2-2 HelloWorld的类图

在图2-2的类关系图中，我们用简单的矩行图标表示类Applet和Graphics类，没有将它们的属性和方法显露出来是为了简化。图中的空心箭头表示HelloWorld类是Applet类的子类，代表一般化。HelloWorld和Graphics之间的虚线箭头表示依赖关系，表示HelloWorld类使用了Graphics类。
到这里或许你认为已结束了，其实不然，如果认真研究java库中的Applet类和Graphics类会发现他们都是一个庞大的继承关系中的一部分。追踪Applet的实现可以得到另外一个类图，如图2-3所示：



图2-3 HelloWorld继承图

　


 

第三章 类

类是具有相同属性、操作、关系的对象集合的总称。通常在UML中类被画成矩形。

名称

每个类都必须有一个名字，用来区分其它的类。类名是一个字符串，称为简单名字。路径名字是在类名前加包含类的包名为前缀。例如Wall、java::awt::Wall都是合法的类名。
 

属性

属性是指类的命名的特性，常常代表一类取值。类可以有任意多个属性，也可以没有属性。在类图中属性只要写上名字就可以了。如下图




也可以在属性名后跟上类型甚至缺省取值，如下图：
 

 

 

  
 

操作

操作是类的任意一个实例对象都可以调用的，并可能影响该对象行为的实现。操作在类图中如下图描述：

 

 

 

 

 

组织属性和方法

在画类图的时候没有必要将全部的属性和操作都画出来。实际上，在大部分情况下你也不可能在一个图中将类的属性和操作都画出来。在画类图时可以只将感兴趣的属性和操作画出来就可以了。可以用”...”表示还有属性或方法没有画出来。为了更好地组织属性或方法，可以在一组功能相同的属性或方法前加上一个描述的前缀（<<>>中的文字），如下图：

 

 

 

4000
 

 

 

 

职责

职责指的是类所担任的任务，类的设计要完成什么样的功能，要存担的义务。一个类可以有多种职责，设计得好的类一般至少有一种职责，在定义类的时候，将类的职责分解成为类的属性和方法。
通常在UML中在类图的最下方用单独的部分列出类的职责。
类的职责其实只是一段或多段文本描述。
 

通用建模技术

1.         为系统的词汇建立模型
l          标识出用户或解决问题时用来描述问题的东西，使用CRC卡片和基于USE－CASE的分析来找出这些抽象。
l          对每一个抽象，标识出它的职责集合。确定明确地定义了每一个类，在为所有类确定的职责中取得了很好的平衡。
l          为类提供实现类的职责所需要的属性和方法。
2.         为系统的职责分配建立模型
l          标识出行为相类似的对类
l          找出这些类的职责
l          把这些类作为整体看待，把职责多的类分为几个小类
l          考虑这些类如何协作，重新进行类的职责分配已满足协作中没有类太多职责或太少职责
3.         为非软件的事务建立模型
l          为抽象成类的事务建立模型
l          如果你建模的是硬件本身包含有软件，建模时考虑为一种NODE，这样可以对它进一步的分解。
4.         为原始类型建模
l          为类型或枚举建立模型
l          如果要对这种类型取值范围进行说明，使用约束。

 

第四章 关系

依赖关系（Dependency）

依赖关系是一种使用关系，特定事物的改变有可能会影响到使用该事物的事物，反之不成立。在你想显示一个事物使用另一个事物时使用依赖关系。
通常情况下，依赖关系体现在某个类的方法使用另一个类作为参数。在UML中你可以在其它的事物之间使用依赖关系，特别是包和节点之间。

 

 

 

 

  
  
 
图 4-1 依赖关系

一般化（Generalization）

一般化是继承关系，是叫做“is-a-kind-of”的关系。在UML中你可以在包之间建立一般化关系。

 

 

 

 

 

 

 

  
  

图 4-2 一般化
 

关联（Association）

关联是一种结构化的关系，指一种对象和另一种对象有联系。给定有关联的两个类，可以从一个类的对象得到另一个类的对象。关联有两元关系和多元关系。两元关系是指一种一对一的关系，多元关系是一对多或多对一的关系。一般用实线连接有关联的同一个类或不同的两个类。当你想要表示结构化关系时使用关联。
有一些修饰可以应用于关联。
1.         名字：可以给关系取名字

 

 

  
  
 
2.         角色：关系的两端代表不同的两种角色
 

 

 

 

　　3.         重数：表示有多少对象通过一个关系的实例相连接