第五章类图和对象图.ppt

1、2020/12/10,第5 .1页,第五章 类图和对象图,5.1 类的定义 5.2 类之间的关系 5.3 派生属性和派生关联 5.4 抽象类和接口 5.5 版型 5.6 边界类、控制类和实体类 5.7 类图 5.8 对象图 5.9 小结,2020/12/10,第5 .2页,5.1 类的定义,在UML中,有两个图非常重要,一个是用例图,一个是类图。 一、Rumbaugh对类的定义： 类是具有相似结构、行为和关系的一组对象的描述符,第五章 类图和对象图,2020/12/10,第5 .3页,5.1 类的定义,二、类的描述符,第五章 类图和对象图,版型,类名,属性,操作,版型,静态属性,2020/12

2、/10,第5 .4页,5.1 类的定义,三、类的命名 类名用名词。 类的命名应尽量用应用领域中的术语，应明确、无歧义，以利于开发人员与用户之间在相互理解和交流,第五章 类图和对象图,类名的命名形式,Shape：是一个简单类名,Banking：CheckingAccount 是一个path name 其中， Banking是包名， CheckingAccount 是包 Banking中的一个类,2020/12/10,第5 .5页,5.1.1 类的属性,一、属性的格式 可见性属性名:类型多重性次序=初始值特性,第五章 类图和对象图,二、可见性 在类的属性和操作中都会用到可见性。UML里规定的可见性

3、和OO编程语言里的可见性类似,Rose2003无此可见性,2020/12/10,第5 .6页,5.1.1 类的属性,例5.1、属性声明的一些例子,第五章 类图和对象图,size： Area=（100，100,public,属性名,类型,初始值,visibility：Boolean=false,default-size：Rectangle,protected,maximum-size：Rectangle,xptr：XwindowPtr,private,2020/12/10,第5 .7页,5.1.1 类的属性,例5.1、属性声明的一些例子,第五章 类图和对象图,Colors:color3,属性名,

4、该属性值有3个,Points:Point2.* ordered,name：String0.1,该属性值有两个或多个，且是有序的,该属性可能有1个值，是字符串。也有可能值为null,2020/12/10,第5 .8页,5.1.2 类的操作,一、操作的格式,第五章 类图和对象图,操作（operation）用于修改、检索类的属性或执行某些动作，操作通常也称为功能。操作被约束在类的内部，只能作用到该类的对象上,可见性操作名（参数列表） ：返回值 特性,二、操作与接口的区别,区别,2020/12/10,第5 .9页,5.1.2 类的操作,例5.2,第五章 类图和对象图,接口,三、操作声明的例子,disp

5、lay():Location,hide() #create(,attachXWindow(xwin:XwindowPtr,2020/12/10,第5 .10页,5. 2 类之间的关系,5.2.1 关联（association,第五章 类图和对象图,类之间的关系,一、定义,关联是模型元素间的一种语义联系，它是对具有共同的结构特性、行为特性、关系和语义的链的描述,链是关联的实例，关联表示的是类与类之间的关系，链表示的是对象与对象之间的关系,2020/12/10,第5 .11页,5. 2 类之间的关系,二、关联（association)的符号表示,第五章 类图和对象图,图5.2 类之间的关联关系,图

6、5.3 类之间的单向关联关系,5.2.1 关联（association,一个关联可以有两个或多个关联端（association end），每个关联端连接到一个类。关联也可以有方向，可以是单向关联（un-directional association）或双向关联（bi- directional association,2020/12/10,第5 .12页,图5.3所示的类图,用Rose生成的java代码,类A的代码 public class A public B theB; /* * roseuid 450CA7DB0196 */ public A(),第五章 类图和对象图,5.2.1 关联（a

7、ssociation,图5.3 类之间的单向关联关系,代码标识号,其作用是标识代码中的类、操作和其它模型元素,2020/12/10,第5 .13页,private class B /* * roseuid 450CA7DB0222 */ public B(),第五章 类图和对象图,5.2.1 关联（association,2020/12/10,第5 .14页,图5.2 生成的java代码: public class A /* * roseuid 44E4ECA20213 */ public A(),第五章 类图和对象图,5.2.1 关联（association,图5.2 类之间的关联关系,20

8、20/12/10,第5 .15页,private class B /* * roseuid 44E4ECA300CA */ public B(),第五章 类图和对象图,5.2.1 关联（association,2020/12/10,第5 .16页,图5.3生成的VC+代码，A.H ifndef A_H_HEADER_INCLUDED_BAF31D1A #define A_H_HEADER_INCLUDED_BAF31D1A /#ModelId=450CA5F70000 class A public: /#ModelId=450CA7DB0196 A(); /#ModelId=450CA6140

9、160 B *theB; ; #endif /* A_H_HEADER_INCLUDED_BAF31D1A *,第五章 类图和对象图,5.2.1 关联（association,图5.3 类之间的单向关联关系,2020/12/10,第5 .17页,图5.3生成的VC+代码，A.CPP #include A.h /#ModelId=450CA7DB0196 A:A(),第五章 类图和对象图,5.2.1 关联（association,图5.3 类之间的单向关联关系,2020/12/10,第5 .18页,图5.3生成的VB代码，类A（CODE） Option Explicit #ModelId=450

10、CA6140160 Public theB As B #ModelId=450CA7DB0196 Public Sub A() End Sub,第五章 类图和对象图,5.2.1 关联（association,图5.3 类之间的单向关联关系,2020/12/10,第5 .19页,图5.3生成的VB代码，类B（CODE） #ModelId=450CA7DB0222 Public Sub B() End Sub,第五章 类图和对象图,5.2.1 关联（association,图5.3 类之间的单向关联关系,2020/12/10,第5 .20页,图5.4中加上关联名后，表示company类和 Pers

11、on类之间是雇佣关系,第五章 类图和对象图,5.2.1 关联（association,三、 关联名,图5.4 使用关联名的关联,关联名,关联名通常是动词或动词短语,在一个类图中如果一个关联的意思已经很明确了，可以不用加关联名,2020/12/10,第5 .21页,关联两端的类可以某种角色参与关联,第五章 类图和对象图,5.2.1 关联（association,四、 关联的角色,角色,图5.5 关联的角色,protected,public,2020/12/10,第5 .22页,在UML中，多重性可以用下面的格式表示,第五章 类图和对象图,5.2.1 关联（association,四、 关联的角色

12、,0.1 表示0个或1个,0.* （也可以表示成0.n） 表示0个或多个,1 （1.1的简写） 表示1个,1.* （也可以表示成1.n） 表示1个或多个,（即0.n） 表示多个,7 表示7个,3，6，9 表示3个，6个，9个,0 （0.0的简写）表示没有实例参与关联，一般不用,多重性用非负整数的一个子集来表示,2020/12/10,第5 .23页,关联本身也可以有特性，通过关联类（association class）可以进一步描述关联的属性、操作以及其它信息,第五章 类图和对象图,5.2.1 关联（association,五、 关联类,图5.6 使用关联类的关联,2020/12/10,第5 .

13、24页,public class company private String companyName; protected person employee; /* * roseuid 450D1851016D */ public company(),第五章 类图和对象图,在关联的employee端的多重性是n，所以在生成的代码中， employee是类型为Person的数组,2020/12/10,第5 .25页,private class person private string personName; public company employer; /* * roseuid 450D1

14、851005F */ public person(),第五章 类图和对象图,图5.6 生成的java代码,2020/12/10,第5 .26页,private class contract private Double salary; /* * roseuid 450D185101F9 */ public contract(),第五章 类图和对象图,2020/12/10,第5 .27页,对于关联可以加上一些约束，以加强关联的含义,第五章 类图和对象图,六、 关联的约束,图5.7 带约束的关联,2020/12/10,第5 .28页,在关联端紧靠源类图标处可以有限定符（qualifier），带有限

15、定符的关联称为限定关联（qualified association）。限定符的作用就是在给定关联一端的一个对象和限定符值以后，可确定另一端的一个对象或对象集,第五章 类图和对象图,七、 限定关联,图5.8 限定符和限定关联,bank，accoount）-0个或1个person,Person-多个（bank，accoount,2020/12/10,第5 .29页,第五章 类图和对象图,七、 限定关联,图5.9 限定关联和一般关联,bank，accoount）-0个或1个person,Person-多个（bank，accoount,Person-多个 bank,限定符是关联的属性，而不是类的属性,

16、限定符这个概念在设计软件时非常有用。引入限定符的一个目的是把多重性从n降低为1，或0.1，这样，做查询操作时的效率会较高,2020/12/10,第5 .30页,第五章 类图和对象图,八、 关联的种类,5.2.1 关联（association,关联的种类,又称递归关联,一个类与自身的关联,两个类之间的关联,三个或三个以上类之间的关联,2020/12/10,第5 .31页,第五章 类图和对象图,八、 关联的种类,5.2.1 关联（association,1、自返关联,public class EnginePart public EnginePart theEnginePart ; /* * ros

17、euid 4508D2A701AC */ public EnginePart(),2020/12/10,第5 .32页,第五章 类图和对象图,5.2.1 关联（association,2、N元关联,N元关联的例子如图5.11所示,Player、Team和Year这3个类之间存在三元关联，而Record类是关联类,N元关联中的多重性的意义是： 在其他N-1个实例值确定的情况下， 关联实例元组的个数,N元关联没有限定符的概念，也没有聚合、组合等概念,2020/12/10,第5 .33页,第五章 类图和对象图,5.2.2 聚集和组合,一、聚集,聚集（aggregation）一种特殊形式的关联。聚集表

18、示 类之间整体与部分的关系,在对系统进行分析和设计时，需求描述中的“包含”，“组成”、“分为部分”等词，常常意味着存在聚集关系,聚集关系的实例是传递的、反对称的，即聚集关系的实例之间存在偏序关系，聚集关系的实例之间不能形成环,图5.12 聚集关系,2020/12/10,第5 .34页,第五章 类图和对象图,5.2.2 聚集和组合,二、组合,组合（composition）表示的也是类之间整体与部分的关系，但组合关系的整体与部分具有同样的生存期,圆心,2020/12/10,第5 .35页,第五章 类图和对象图,5.2.2 聚集和组合,三、聚集和组合的区别,1、聚集关系也称为“has a”关系，组合

19、关系也称为“contains a”关系。 2、聚集关系表示事物的整体/部分关系的较弱的情况，组合关系表示事物的整体/部分关系的较强的情况 3、在聚集关系中，代表部分事物的对象，可以属于多个聚集对象，可以为多个聚集对象所分享，而且可以随时改变客观存在所从属的聚集对象。代表部分事物的对象与代表整体事物对象的生存期无关，一旦删除了它的一个聚集对象，不一定也就随即删除代表部分事物的对象。在组合关系中，代表整体事物的对象负责创建和删除代表部分事物的对象，代表部分事物的对象只属于一个组合对象，一旦删除了组合对象，也就随即删除了代表部分事物的对象,2020/12/10,第5 .36页,5.2.3 泛化关系,

20、泛化（generalization)关系定义了一般元素和特殊元素之间的分类关系,第五章 类图和对象图,从面向对象程序设计语言的角度来说，类与类之间的泛化关系就是平常所说的类与类之间的继承关系,图5.14 泛化关系,抽象类,泛化关系在很多模型元素之间都有。 在用例、参与者、数据类型等之间也可以有泛化关系,2020/12/10,第5 .37页,5.2.4 依赖（dependency）关系,定义：假设有两个元素X、Y，如果修改元素X的定义可能会导致对另一个元素Y的定义的修改，则称元素Y依赖于X,第五章 类图和对象图,依赖关系可能由各种原因引起，如一个类向另一个类发送消息，或者一个类是另一个的数据成员

21、类型，或者一个类是另一个类的操作的参数类型等,被依赖类,依赖关系本身不生成专门的实现代码,图5.15 依赖关系,用例与用例之间、包与包之间也可以有依赖关系,2020/12/10,第5 .38页,5.3 派生属性和派生关联,派生属性（derived attribute)和派生关联（derived association)是指可以从其他属性和关联计算推演得到的属性和关联,第五章 类图和对象图,在生成代码时，派生属性和派生关联不产生相应的代码,指明某些属性和关联是派生属性和派生关联有助于保持数据的一致性,图5.1 派生属性,派生属性,2020/12/10,第5 .39页,5. 抽象类和接口,抽象类(

22、abstract class)是不能直接产生实例的类，因为抽象类中的方法往往只是一些声明，而没有具体的实现，因此，不能对抽象类实例化,第五章 类图和对象图,前面讲的类Athlete就是抽象类,接口是类的版型,接口的3种表示方式,2020/12/10,第5 .40页,5. 抽象类和接口,接口是一个声明而不是一个实际的类，接口没有属性，接口的实现有赖于和接口相连的具体的类,第五章 类图和对象图,定义：只含有操作特征标记的类被称为接口,接口与抽象类的异同,下面是接口的例,2020/12/10,第5 .41页,例如，定义衬衫、香水和割草机的类没有什么相似的地方，所以它们没有共同的超类，但是某个商店同时

23、拥有这些东西作为商品。作为商品，商店就要对它们买进，定价，卖出，但买进任何一样商品的处理过程是不同的，商店从不同的渠道购买它们，使用不同的条款，因此使用同一种方法来满足不同商品行为需求是不可能的。 变通的方法是定义一个产品接口类，如图518所示，该产品接口类定义了操作buy，price和sell（买进、定价和卖出），在衬衫、香水和割草机实现产品接口类的时候，它们必须对每个操作提供自己的方法,第五章 类图和对象图,2020/12/10,第5 .42页,第五章 类图和对象图,2020/12/10,第5 .43页,5.5 版型,版型（stereotype)是UML的3种扩展机制之一,第五章 类图和对

24、象图,UML中的另外两种扩展机制是标记值（tagged value)和约束,版型是建模人员在已有的构造块上派生出的新构造块，这些构造块是和特定问题相关的,版型必须定义在UML中已经有定义的基本构造块上,UML的基本构造块,版型可以应用于所有类型的模型元素，包括类、结点、构件、 注解、关系、包、操作等,2020/12/10,第5 .44页,5.5 版型,UML中预定义了一些版型，如接口是类的版型、子系统是包的版型,第五章 类图和对象图,参与者是一个版型化的类，其版型为,图5.20 Actor及其操作,Actor事实上是一个类，故可为其添加属性和方法,System,2020/12/10,第5 .4

25、5页,5.5 版型,第五章 类图和对象图,用户可以自定义版型,这个版型说明ManagementWindow是一个专用于图形 用户界面的类,图5.21 自定义版型,2020/12/10,第5 .46页,5.6 边界类、控制类和实体类,第五章 类图和对象图,UML中有3种主要的类版型，即边界类（boundary class)、控制类(control class)和实体类（entity class,在进行OO分析和设计时，如何确定系统中的类是一个 比较困难的工作，引入边界类、控制类和实体类的概念， 有助于分析和设计人员确定系统中的类,边界类位于系统与外界的交界处,边界类,5.6.1 边界类,2020

26、/12/10,第5 .47页,第五章 类图和对象图,UML中边界类的3种表示方式,通过用例图可以确定需要的边界类,5.6.1 边界类,边界类是抽象的用户接口，处理输入和输出,2020/12/10,第5 .48页,第五章 类图和对象图,通过用例图可以确定需要的边界类,5.6.1 边界类,每个actor/use case对至少要有一个边界类，但并非每个actor/use case对都要生成惟一边界类,图5.23 多个参与者使用同一个边界,2020/12/10,第5 .49页,第五章 类图和对象图,实体类保存要放进持久存储体的信息。所谓持久存储体就是数据库、文件等可以永久性存储数据的介质,5.6.2

27、 实体类（负责维护数据,UML中实体类的3种表示方式,实体类可以通过事件流和交互图发现，实体类通常用领域术语命名,通常，每个实体类在数据库中有相应的表，实体类中的属性对应数据库中表的字段。但并非实体类和数据库中的表是一一对应的，有可能是一个实体类对应多个表，也可能是多个实体类对应一个表,2020/12/10,第5 .50页,第五章 类图和对象图,控制类是负责其他类工作的类,5.6.3 控制类,UML中控制类的3种表示方式,每个用例通常有一个控制类，控制用例中的事件顺序。控制类也可在多个用例间共用,图5.25 控制类的3种表示方式,其他类并不向控制类发送很多消息，而是由控制类发出很多消息,控制用

28、例应用层上的交互，不处理输入和输出,2020/12/10,第5 .51页,第五章 类图和对象图,类加上它们之间的关系就构成了类图，类图中可以包含接口，包、关系等建模元素，也可以包含对象、链等实例,5.7.1 类图的抽象层次,类图描述的是类和类之间的静态关系,类图的抽象层次,5.7 类 图,类图不仅显示了信息的结构，同时还描述了系统的行为,涉及应用领域的概念，独立于程序设计语言,描述软件的接口部分,提供类的实现细节,2020/12/10,第5 .52页,概念层,概念层(Conceptual)类图描述应用领域中的概念。实现它们的类可以从这些概念中得出,但两者并没有直接的映射关系。事实上,一个概念模

29、型应独立于实现它的软件和程序设计语言,5.7.1 类图的抽象层次,说明层,说明层(Specification)类图描述软件的接口部分,而不是软件的实现部分。面向对象开发方法非常重视区别接口与实现之间的差异,但在实际应用中却常常忽略这一差异。这主要是因为OO语言中类的概念将接口与实现合在了一起。大多数方法由于受到语言的影响,也仿效了这一做法。现在这种情况正在发生变化。可以用一个类型(Type )描述一个接口,这个接口可能因为实现环境、运行特性或者用户的不同而具有多种实现,2020/12/10,第5 .53页,实现层,只有在实现层(Implementation)才真正有类的概念,并且揭示软件的实现

30、部分。这可能是大多数人最常用的类图,但在很多时候,说明层的类图更易于开发者之间的相互理解和交流。 理解以上层次对于画类图和读懂类图都是至关重要的。但是由于各层次之间没有一个清晰的界限,所以大多数建模者在画图时没能对其加以区分。画图时,要从一个清晰的层次观念出发;而读图时,则要弄清它是根据哪种层次观念来绘制的。要正确地理解类图,首先应正确地理解上述三种层次。虽然将类图分成三个层次的观点并不是UML的组成部分,但是它们对于建模或者评价模型非常有用。尽管迄今为止人们似乎更强调实现层类图,但这三个层次都可应用于UML,而且实际上另外两个层次的类图更有用,5.7.1 类图的抽象层次,2020/12/10

31、,第5 .54页,5.7.1 类图的抽象层次,概念层,说明层,实现层,图5.26 类的3个不同层次,2020/12/10,第5 .55页,5.7.2 构造类图,根据用例描述中的名词确定类的候选者。 使用CRC分析法寻找类。CRC：类（class）、职责（responsibility）和协作（collaboration），CRC分析法根据类所要扮演的职责来确定类。 根据边界类、控制类和实体类的划分来帮助发现系统中的类。 对领域进行分析，或利用已有的领域分析得到类。 参考设计模型来确定类。 根据某些软件开发过程提供的指导原则进行寻找类的工作,第五章 类图和对象图,在构造类图时不要过早陷入实现细节，应根据项目开发的不同阶段，采用不同层次的类图,一、寻找类的技巧,2020/12/10,第5 .56页,5.7.2 构造类图,研究分析问题领域，确定系统的需