UML的组合,依赖

今天和一个家伙对一个uml图有意见分歧,他说我画的不对。说我把一个引用(这是他用的词,我从来不知道uml里引用到底是什么东西)画成了组合。我后来想想可能他说的引用就是依赖的意思。我先说说我的理解,组合就是说某个类作为另一个类的成员变量,比如现在有类B,类A定义如下:
[code="java"]
public class A{
B b;
}
[/code]

那么A和B就是组合关系,A组合了B,难道说A和B之间必须要有实际上的整体部分关系才能构成组合关系吗。我认为组合就是B作为A的一部分,增强了A的功能,这就是组合。
然后是依赖,如果B是A某个方法的参数或方法中的局部变量,B就依赖于B。
现在极度迷茫中,请指教,谢谢
[b]问题补充:[/b]
[quote "lovewhzlq"]你的理解基本上是正确的[/quote]
基本上是什么意思,我就是不清楚,所以想找清楚的答案。

刚才提问完发现有http://www.iteye.com/topic/343488,看此贴一楼的回答。但是还是不能肯定,如果按一楼的说法,那么基本上可以说不存在“组合”。根据一楼的例子,如果B是StringUtil类,因为B是单独存在的,所以是关联关系,那么方向盘难道不是单独存在的吗

UML是让各个人之间能更好的理解,如果像这样,还要考虑情形进行区分恐怕只能让所有人都不理解设计。对于整体和局部,每个人都有自己的看法
[b]问题补充:[/b]
----------最佳答案的评论-------------------
对大部分人来说,你说的是对的。我对组合和依赖的理解确实是错误的。

然而我不明白uml为什么要搞的这么复杂,非要扯出这么多难以理解的概念。就像我问题中说的,uml的本意是为了让大家清楚地理解你的设计,但按uml现在的情况看,很多人都不是很清楚这些概念,更不要说清楚这些概念间的区别,画出来的uml图各有各的看法。如果uml和具体的代码结合起来,组合(不再区分组合聚合)就是作为成员变量,依赖就是作为方法参数,那么看得uml图就知道你的代码将会是什么样子,各人在理解上也不会有偏差,uml更简单。难道这样不好,还是为了抽象出一个语言无关的层?

另外,感谢lovewhzlq的回答。我完全同意你的看法,不要怪我为什么而没选择你的答案为最佳答案

[quote]
public class A{
B b;
}

[/quote]
从这里我只看出A和B的关联关系,至于是聚集还是结合,我实在看不出,这要结合上下文的。(聚集和结合都是特殊形式的关联)

举个例子吧。
[b]聚集关系[/b][color=red][/color]
假如A是Circle类(圆),B是Style类,一个圆可以有颜色,是否填充这些样式(style)方面的属性,可以用一个style对象表示这些属性,但同一个style对象也可以表示别的对象如三角形的一些样式方面的属性,也就是说,style对象可以用于不同的地方。如果circle对象不存在了,不一定意味着style这个对象也不存在了。

[b]结合关系[/b][color=red][/color]
假如A是Circle类,B是Point类。一个圆可以由半径和圆心确定,如果圆不存在了那么表示这个圆的圆心也就不存在了。所以Circle和Point类是结合关系。

你的理解基本上是正确的

uml手册的标准描述

依赖表示两个或多个模型元素之间语义上的关系。它只将模型元素本身连接起来而不需
要用一组实例来表达它的意思。它表示了这样一种情形,提供者的某些变化会要求或指示依赖关系中客户的变化。
根据这个定义,关联和泛化都是依赖关系,但是它们有更特别的语义,故它们有自己的
名字和详细的语义。我们通常用依赖这个词来指其他的关系。

依赖关系种类
依 赖 关 系 功 能 关 键 字
访问 允许一个包访问另一个包的内容 a c c e s s
绑定 为模板参数指定值,以生成一个新的模型元素 bind
调用 声明一个类调用其他类的操作的方法 c a l l
导出 声明一个实例可从另一个实例导出 d e r i v e
友员 允许一个元素访问另一个元素,不管被访问的元素是否具有可见性 f r i e n d
引入 允许一个包访问另一个包的内容并为被访问包的组成部分增加别名 i m p o r t
实例化 关于一个类的方法创建了另一个类的实例的声明 i n s t a n t i a t e
参数 一个操作和它的参数之间的关系 p a r a m e t e r
实现 说明和其实之间的映射关系 r e a l i z e
精化 声明具有两个不同语义层次上的元素之间的映射 r e f i n e
发送 信号发送者和信号接收者之间的关系 s e n d
跟踪 声明不同模型中的元素之间存在一些连接,但不如映射精确 trace
使用 声明使用一个模型元素需要用到已存在的另一个模型元素,这样才 u s e
能正确实现使用者的功能(包括调用、实例化、参数、发送)

其实uml的依赖关系嘛,本来就要看情况而定,就像组合本质上也是属于依赖的,
说真的,uml图不过也是帮助大家一起来理解系统,如果背离了用来理解系统这个初衷,而搞得这么学术化,就没什么意义的,

那么在这过程中,你认为uml起到了它的作用了吗?
我看是起了反作用。