学习英语很重要!这句话不是因为明天考四级和六级才说的,是因为今天总结UML时候突然间的感慨啊!不知道为什么,英文翻译Use
case 翻译成用例?如果我没记错的话,英语翻译应该有直译(直接翻译)和意译(按照意思翻译),当翻译的时候,二者择优而选,尽量使读者能够明白即可.从这点来,我不得不佩服那个将Use
case 翻译成用例的语言学家.直到现在,我才突然明白:UML中的用例,好像给我日常理解的功能没有什么大的区别.如此,这样说来,你为什么不翻译成一个简单而又容易理解的单词:功能呢?害的我本来对UML挺恐惧的心变的更加惊恐,更加惴惴不安.
前面废话讲了那么多,但是铺垫已经做好了.用例图就是由主角、用例以及它们之间的关系构成的图。该图说明了用例模型中的关系,是由参与者（Actor）、用例（UseCase）以及它们之间的关系构成的用于描述系统功能的动态视图。理解么?费解么?不想解,是么?为什么,因为中间有一个让我头疼(Use
case),但是,根据笔者前面的废话,如果你将上面语句中的用例两个字用'功能'来替换,再读一遍,理解一下!告诉我,你费解么?简而言之,用例图就是一个项目程序中,什么人干什么事的图! 再看用例图中的关系:包含关系,泛化关系,扩展关系.
包含关系:基本用例的行为包含了另一个用例的行为。基本用例描述在多个用例中都有的公共行为。包含关系本质上是比较特殊的依赖关系。它比一般的依赖关系多了一些语义。在包含关系中箭头的方向是从基本用例到包含用例。
泛化关系：代表一般于特殊的关系。它的意思和面向对象程序设计中的继承的概念是类似的。不同的是继承使用在实施阶段，泛化使用在分析、设计阶段。在泛化关系中子用例继承了父用例的行为和含义，子用例也可以增加新的行为和含义或者覆盖父用例中的行为和含义。
扩展关系:基本含义和泛化关系类似，但在扩展关系中，对于扩展用例有更多的规则限制，基本用例必须声明扩展点，而扩展用例只能在扩展点上增加新的行为和含义。与包含关系一样，扩展关系也是依赖关系的版型。在扩展关系中，箭头的方向是从扩展用例到基本用例。