《火球——UML大战需求分析》(第3章 分析业务模型-类图)——3.3 类之间的关系

摘要类图(Class Diagram)可能是用得最多的一种UML图。类图的基本语法并不复杂,你可能最多学习两三天就可以掌握,然而要真正做到活用类图则可能需要几年的功力。类图是锻炼面向对象分析(OOA:Object-Oriented Analysis)和面向对象设计(OOD:Object-Oriented Design)思想的重要的工具,是业务结构建模的重要工具。本章将会有大量的实战练习,你的OOA思想将会接受极大的考验和提升。


3.3 类之间的关系


表达类之间关系时,类只需要画出名字就可以了,属性和方法可以省略显示。

“直线”关系

A、B两个类,它们之间有关系,但又不能确定是怎样的关系,我们可以这样画:

image004.jpg


图 3.4 “直线”关系

这个“直线”关系其实就是关联(Association)关系,“关联”是 UML中文术语的标准说法,但为了能让大家更容易理解和记忆,我会使用一些“老土”的说法。
软件 需求分析时,如果觉得两个业务概念之间有联系,但暂时不能确定具体是怎样的,那么就先画一条线将两者连起来再说。随着你对业务的理解,这条线条会进一步具体化,你可以为这条线添加更多的元素。

image005.jpg
图 3.5 一对一关系

这个图C、D两个类有一条直线相连,但在直线两端各有一个数字1,表示一个C对应一个D。

image006.jpg
图 3.6 一对多关系

这个图表示一个E对应0到多个F,*号的意思就是表示0到多个。

image007.jpg
图 3.7 一对零到三个关系

这个图表示一个G对应0到3个M,“0..3”表示0到3个,“1..4”表示1到4个,“x..y”表示x到y个(x,y表示任意自然数,而且x < y),注意有两个点(“..”)而不是一个点(“.”)。

image008.jpg
图 3.8 角色关系

这个图表示I和J之间有关系,在这个关系中I的身份是上司,J的身份是下属。我们可以在线条的两端标记在这个关系中,两者分别是处在怎样的角色。
你可能会留意到,为什么“上司”、“下属”前面有一个“+”号?“+”号表示这个角色的类型是public的,“-”号表示private,这些符号在 软件设计时才需要用到,我们做软件 需求分析时,不需要理会这些符号,全部画成“+”号就可以了。
这条直线如果变成带箭头的,又是表示怎样的意思呢?请看下图:

image009.jpg
图 3.9 “导航”关系

这个图表示由A可找到B,箭头表示方向,由A可“导航”到B。
写代码时,如果A类有一个成员变量保存的是类B的引用,也就是说由类A可以找到类B,那么可以画成图3.9的样子。这是从软件设计的角度来解释这个箭头的意义,如果是 软件需求分析,这个箭头是怎样的意思呢?下面是一个实例:

image010.jpg
图 3.10 请假单与请假者的关系

请假单上会列明是谁请的假,所以我们由请假单可以找到请假者。进行业务分析时,往往会发现由业务概念A可找到B,这时可以使用带箭头的线条。
直线关系是最常见的关系,最简单的直线关系就是两个类之间画条线就可以了。我们也可以进一步细化这条直线关系:在这条直线的两端,可以标记上数字和名称,数字表示是几对几的关系,名称则表示在这个关系中,直线两端的两个类分别是怎样的一个角色,而这条直线也可以变成带箭头的直线。直线、几对几的关系、角色、箭头可以搭配使用,只要能准确反应出业务关系就可以了。
直线关系只是一种老土的说法,UML中文术语标准是关联(Association)关系。另外要说明的是,有时候因为类太多,为了让 类图更容易阅读,需要将“直线”画成“折线”,如下图:

image011.jpg
图 3.11 “折线”关系

“包含”关系

一个部门有多个员工,用类图可以这样表示:

《火球——UML大战需求分析》(第3章 分析业务模型-类图)——3.3 类之间的关系_第1张图片
图 3.12 “包含”关系

这里有两种表示法,一种是空心菱形,一种是实心菱形。两种菱形表示包含的强烈程度不同,空心菱形是“弱”包含,实心菱形则是“强”包含。你可以这样记忆:空心菱形是空心的,显得虚弱一点,这是“弱”包含;实心菱形是实心的,显得更加强壮,这是“强”包含。
“弱”包含表示如果部门没有了,员工也可以继续存在;“强”包含表示如果部门没有了,员工也不再存在。关于这两者的另外一个重要区别是:如果是“弱”包含关系,儿子可以有多个父亲(当然只有一个父亲也是可以的);如果是“强”包含关系,则儿子只能有一个父亲。
做软件需求分析时,我往往会将所有的包含关系画成“弱包含”,如果后面发现某些关系可以表示为“强包含”时,我才转为实心菱形。
请留意包含的方向,谁包含谁,刚学习的朋友很容易把方向画反了。
在员工这边的“*”号表示零到多名的意思,如果是“1..100” 则表示1到100名;而部门这边没有具体的数字,则表示是“1”,则一名员工只能属于一个部门。如果一名员工同属于多个部门,那应该怎样画呢?

image013.jpg
图 3.13 部门与员工的多对多关系

部门这边的“*”表示一名员工可同属于多个部门,请注意,在“强包含”关系中,一名员工只能属于一个部门。
“弱包含”、“强包含”的说法只是一种方便大家记忆和理解的老土说法而已,空心菱形的UML中文术语标准说法是聚合(Aggregation),实心菱形是组合(Composition)。以前看UML资料遇到聚合和组合两个词都会让我头晕一番,因为那些解释说得太复杂了,就算是现在我遇到这两个词也需要稍微停顿一下来想一想。刚学习包含关系的朋友,建议你只需要记住“弱包含”“强包含”的说法就可以了。

“继承”关系

我以前的公司有一个每日培训的制度,由公司内部员工做讲师,分享知识和经验。员工可以做学生,也可以上台做老师,下面是学生和老师的类图:

《火球——UML大战需求分析》(第3章 分析业务模型-类图)——3.3 类之间的关系_第2张图片
图 3.14 学生和老师

请思考,学生和讲师有什么共性呢?
学生和讲师不都是员工吗,凡是员工都有这样的属性了:

《火球——UML大战需求分析》(第3章 分析业务模型-类图)——3.3 类之间的关系_第3张图片
图 3.15 员工

说明:此图只列了三个员工的属性,仅作示意。
员工、学生、讲师可以表示为以下的关系:

《火球——UML大战需求分析》(第3章 分析业务模型-类图)——3.3 类之间的关系_第4张图片
图 3.16 员工、学生、老师关系

学生、讲师都“继承”了员工,他们具备员工的属性,同时也有自己特有的属性。另外一种说法是:学生、讲师是员工的一种。
“继承”的基本画法如下:

image016.jpg
图 3.17 “继承”关系

这表示A继承了B,A具备B的特点,同时也有自己特有的特点,注意不要搞错继承方向。
“继承”同样是一种老土的说法,UML中文术语标准是泛化(Generalization),该图可这样读:A泛化为B。泛化这个词比较难理解,你可以理解为抽象、提炼等。
在实际的软件需求分析工作中,我们往往有两种认识事物的角度,我们以员工、学生、老师的关系为例子来说明。
角度一:在培训现场,我们看到的是学生和老师,后来你发现,原来老师是内部员工来的!于是你可以从学生和老师这两个类出发,发现学生和老师其实都是员工!
角度二:作为这个公司的领导,希望公司形成一种学习和进步的风气,促进公司的进步,于是领导希望员工之间能互相分享知识和经验。从这个角度看来,领导先想到的是员工,然后再进一步发现员工可以当学生也可以当老师。
在泛化关系中,以图1.17为例,我们有可能先发现A,然后导出B,这时可以说由A泛化为B;也有可能是先发现B,然后导出A,这时可以说A继承B。泛化(继承)是我们进行业务提炼的重要手段,后面我们将有更多的具体例子和练习。

依赖关系

如果一个烟鬼嗜烟如命,没有烟不能生活,用类图可以这样表示:

image017.jpg
图 3.18 烟鬼与香烟的关系

这个虚线箭头就是依赖(Dependency)关系,这虚线箭头与导航关系的实线箭头很相似,注意不要搞混了,两者表示的意思是完全不一样的。
如果说类A依赖于类B,类图表示如下:

image018.jpg
图 3.19 依赖关系

所谓的依赖关系,依赖的程度是相当而言的,不一定是A没有B就不能“生存”了。在具体的业务逻辑中,对于某个事情,A需要B来协助才能完成,这样也是一种依赖。

这个小节内容非常多,你可能有点消化不良了。上面介绍的内容其实在需求分析工作中是经常需要用到的,而其中最常用的是直线关系。
下面开始你将会通过一个个的练习来帮助你理解和巩固这些知识,强烈建议你看完题目后先独立思考完成,然后再继续看参考答案。
 
 
 

请看下一节……




作者:张传波

创新工场创业课堂讲师

软件研发管理资深顾问

《火球——UML大战需求分析》作者

www.umlonline.org 创办人

你可能感兴趣的:(UML,需求,需求分析,需求管理,火球)