再次说UML 中的关系
用了半个的时间第一遍学习了第一遍大话设计模式,在大话设计模式中每个模式的解释都用了类图,每个类和每个
类都用不同的关系连接起来.所以我根据自己的理解有总结了一下他们的关系.
"直线"关系----关联关系
A,B两个类,它们之间有关系,但又不能确定是怎么的关心地,我们可以这样画:
用比较通俗的话说是"直线"关系,使用UML 专业的术语说是"关联"关系.
我们在做软件需求分析时,如果觉得两个业务感念之间有联系,但是暂时不能确定具体是怎么的,那么就先画一条线
将两者连起来再说.随着自己对业务的了解,这条线条会进一步具体化,你就可以为这两条线添加更多的元素.
(1)一对一的关系
这个图A.B两个类有一条直线相连,但在直线两端各有一个数字1,表示一个A对应一个B,
(2)一对多的关系
这个表示一个A对应多个B,*号表示0到多个.
"包含"关系
一个部分由多个员工,用类图可以这样表示:
用uml的标准术语来说,第一种空心菱形表示的是聚合关系,它的关系就如计算机主机和CPU的关系.第二种实心菱
形表示的是组合关系,它的关系就如孕妇和胚胎的关系.
这里有两种表示方法,一种是空心菱形,一种是实心菱形.两种菱形表示包含的强烈程度不同,空心菱形是"弱"包含,实
心菱形则是"强"包含.
米老师常常说的"记是永远记不住的".如果有技巧的记忆,会让你"忘也不掉"的.我们来看看这个记忆技巧:空心菱形
是空心的,显得虚弱一点,这就是"弱"包含;实心菱形是实心的,显得更加的强壮,这就是"强"关系.
"继承"关系
在提高班提倡的是导师制,在提高班内部的学生做师傅,分享知识和学习经验.学生可以做徒弟,也可以做师傅,把自己
的经验传给徒弟,下面是徒弟和老师的类图:
现在我们来思考一个问题:徒弟和师傅有些什么共性呢?
徒弟和师傅不都是学生吗,凡是学生都有这样的属性:
学生,师傅,徒弟可以表示以下的关系:
师傅和徒弟都"继承"了员工,它们具备学生的属性,同时也有自己特有的属性.
我们还可以这样说:师傅,徒弟都是员工的一种.
"继承"关系画法如下:
这表示A继承B,A具有B的特点,同时也具有自己特有的特点.
在UML的标准术语中这种"继承"关系被称为"泛化"关系(Generalization).
依赖关系
若果一个酒鬼嗜酒如命,没有酒的话就不能生活,用类图就可以这样来表示:
这个虚箭头就表示依赖关系(Dependency),
如果说A依赖于B,用类图就可以这样来表示:
所谓的依赖关系,依赖的程度是相当而言的,不一定是A没有B就不能"生存"了.
在具体的业务逻辑中,对于某个事情,A需要B来协助才能完成,这样也是一种依赖关系.
扩展关系:
在机房收费系统中,当涉及到钱的地方,比如查询充值情况,日结算,周结算的地方都涉及到了打印,打印预览的功能,
我们用用例图可以这样表示:
从图中我们可以看出扩展关系式用一条带箭头的虚线加上<<extends>>来表示的.
如果A扩展出B,用用例图我们可以这样表示:
扩展关系表示的是"可选"的,而不是"必选",这意味着即使没有扩展用例,基本用例也是完整的,如果哦没哟基本用例,
扩展用例是不能单独存在的;如果有多个扩展用例,同一时间用例实例也只会使用其中一个.
使用扩展关系的情况:
1.用例的某一个部分是可选的系统行为.
2.只在特定条件下才执行分支流,如触发警报器
3.可能有一组行为段,其中的一个或者多个可以再基本用例扩展点处插入.所插入的行为段将取决于执行基本用例时与
主角进行的交互.
包含关系(include)
如果我们想要使用机房收费系统,我们必选先登录机房收费系统,才能进行各自的操作,才能对数据库进行增删改查.
用用例图我么可以这样表示:
包含关系式用一条带箭头的虚线加<<include>来表示的.
如果A包含B,用例图可以这样表示:
与扩展用例不同的是:包含用例表示的是"必选"而不是"可选",这意味着如果没有包含用例,基本用例是不完整,同时
没有基本用例,包含用例是不能单独存在的.
在用例图中使用包含关系的理由:
1.从基本用例中分解出这样的行为:它对于了解基本用例的主要目的并不是必需的,只有它的结果才比较重要.
2.分解出两个或更多个用例所共有的行为.
实现关系(Realize)
手机是现在生活中不可缺少的一部分.使用手机通话,就必须要交话费,交话费的实现途径可能有营业厅交费,银行交
费, 预存话费等.用类图我们可以表示为:
实现关系是由一条带空心箭头的虚线表示的.
如果A实现B ,用类图可以这样表示:
在前面我曾说过<<uml ---关系>>.但是说的比较简单,那是刚学习的时候,对关系还是处于很模糊的状态写的.