UML中种关系的辨析.docVIP

UML中五种关系的辨析 ?????????????????????? Figure 1. UML offers five different types of class relationship ???? 要理解这5中关系就不能简单的把它们和具体的语言实现相关联，UML介于问题域和解域之间，因而兼有这两者的概念。虽然类图是静态的，但类之间的这5种关系却是动静兼有的（也就是编译时和运行时混合的）。 ???? 问题域、解域混合，编译时、运行时混合是这5种关系的特点。 用词问题域解域编译时运行时Dependency uses a短暂的或者对非业务类的（如工具类）依赖作用域在方法内部的reference（可能是方法参数或方法内部声明的 reference ） 作用域在方法内部的reference（可能是方法参数或方法内部声明的 reference ） 短暂的Association has a相对固定的，对业务类的依赖类属性 类属性 持续一定时间的Aggregation owns but may shareowns but may share 类属性 类属性 生命线可能相关联Composition is part ofis part of 类属性 类属性 生命线总是关联Generalization is a type ofis a type of 继承继承? Dependency依赖:uses a ??? Dependency表示一个类uses或者知道另一个类。一方的改动将引起另一方的改动。这是一种典型的临时关系，代表了类之间的一种短暂的交互。 ??? 针对“一方的改动将引起另一方的改动”这句话来讲，所有强于dependency的关系都蕴含/隐含者dependency关系 。且这个意义常用来表示package之间的依赖关系。（package之间只有依赖和继承2种关系） ??? 因为是一种短暂的关系，所以依赖类指向目标类的reference的作用域一般在一个方法的内部（这有可能是方法的传入参数或者在方法内部声明的reference），而不是 类的属性。因为属性代表一种相对持久的关系，而方法内部的对象，只有在方法被调用时（短暂的）才与依赖类（方法所在的类）发生关系。比如window和 event之间，只有用户事件时两者才会发生关联，当没有事件时两者并不一起工作，他们之间的合作关系是短时间的。我们也不会把event声明为 windows的一个属性，而一般在windows的方法里进行处理。 ??? Dependency 还经常用于表示一种对通用模块（如java.util.regex ，java.math ）而非业务模块的依赖关系。这显然是一种问题域（而不是解域或技术角度）的思维角度。 Association关联:has a ??? Associations表示类之间的一种持续一段时间的合作关系，但被关联的2者生命线（顺序图的概念）不被绑定（也就是说如果一个类被销毁，另一个类不一定被销毁）。 ??? 在具体实现时往往表示为类的属性。但也不是所有的属性都是Associations，像int/bool这类的属性就不易表示为Associations。 ??? 关联是可以有导航的，就是可以有方向，用带箭头的实线表示。 Aggregation聚合: owns but may share ??? Aggregation 表示一种owns（拥有）关系，并且 被关联的2者生命线可能 被关联。 ??? 在UML规范中对这种关系的定义非常模糊，充斥这也许、可能这类字眼。《UML Distilled》中甚至说“聚合是完全没有意义的。因此，我建议，你在自己的的图中略去聚合。” ??? 我个人也认为Aggregation 是较难判断的一类关系，很难确切定义它。它的上面association和下面composition的定义都很明确，大概可理解为介于两者之间，但偏composition。 Composition组合:is part of ??? Composition用于表示“整体-部分”关系。这种关系是“非共享”的，也就是说，在任何时间，“部分”只能包含在一个“整体”中。二者的生命线总是相连的，如果整体被销毁了，部分也就不存在了。 ??? 这里的“部分”不一定是多个。 ??? 这里要提醒一下，这里的“非共享”关系指的是实例，而不是类。就是说一个类的不同实例可以属于不同的拥有者，但一个特定的实例只能有一个拥有者。 Generalization 泛化(Otherwise Known as Inheritance): is a type of ? 以上5类关