第5章 类图和对象图精选PPT.ppt

第5章 类图和对象图第1页，本讲稿共90页5.1 类的定义 类 具有相似结构、行为和关系的一组对象的描述符。第2页，本讲稿共90页5.1 类的定义 类的名字 simple name 例如：Shape path name 例如：Banking:CheckingAccount第3页，本讲稿共90页5.1.1 类的属性 属性在类图标的属性分隔框中用文字串说明，UML规范说明1.5版本中定义属性的格式为：可见性属性名：类型多重性 次序=初始值特性 第4页，本讲稿共90页5.1.1 类的属性【例5.1】属性声明的一些例子。+size:Area=(100,100)#visibility:Boolean=false+default-size:Rectangle#maximum-size:Rectangle-xptr:XwindowPtrcolors:Color3points:Point2.*orderedname:String0.1 第5页，本讲稿共90页5.1.2 类的操作 操作（operation）用于修改、检索类的属性或执行某些动作，操作通常也称为功能。UML规范说明1.5中规定操作的格式为：可见性操作名(参数列表)：返回类型特性 操作的特征标记：只包括操作名和参数列表操作接口：包括操作名、参数列表和返回类型第6页，本讲稿共90页5.1.2 类的操作【例5.2】操作声明的一些例子。+display():Location+hide()#create()-attachXWindow(xwin:XwindowPtr)第7页，本讲稿共90页5.2 类之间的关系 类之间的关系 关联 聚集 组合 泛化 依赖第8页，本讲稿共90页5.2.1 关联 关联（association）是模型元素间的一种语义联系，它是对具有共同的结构特性、行为特性、关系和语义的链（link）的描述。图5.2 类之间的关联关系 图5.3 类之间的单向关联关系 第9页，本讲稿共90页5.2.1 关联 类A的代码：public class Apublic B theB;/*roseuid 3DAFBF0F01FC*/public A()第10页，本讲稿共90页5.2.1 关联 类B的代码：public class B/*roseuid 3DAFBF0F01A2*/public B()第11页，本讲稿共90页1 关联名 关联名 描述关联的作用。通常是动词或动词短语。图5.4 使用关联名的关联 第12页，本讲稿共90页2 关联的角色 关联的两端可以某种角色参与关联。图5.5 关联的角色 第13页，本讲稿共90页2 关联的角色在UML中，多重性可以用下面的格式表示：0.10.*（也可以表示为0.n）1（1.1的简写）1.*（也可以表示为1.n）*（即0.n）73,6.90（0.0的简写）（表示没有实例参与关联，一般不用）可以看到，多重性是用非负整数的一个子集来表示的。第14页，本讲稿共90页3 关联类进一步描述关联的属性、操作以及其他信息。关联类通过一条虚线与关联连接。图5.6 使用关联类的关联 第15页，本讲稿共90页3 关联类 为了有助于理解关联类，这里也用Rose生成相应的Java代码，共3个类，如下所示。类Company的代码：public class Company private String companyName;public Person employee;第16页，本讲稿共90页3 关联类 类Person的代码：public class Person private String personName;protected Company employer;类Contract的代码：public class Contract private Double salary;第17页，本讲稿共90页4 关联的约束 对于关联可以加上一些约束，以加强关联的含义。图5.7 带约束的关联 第18页，本讲稿共90页5 限定关联 在关联端紧靠类图标处可以有限定符（qualifier），带有限定符的关联称为限定关联（qualified association）。限定符的作用就是在给定关联一端的一个对象和限定符值以后，可确定另一端的一个对象或对象集。第19页，本讲稿共90页5 限定关联图5.8 限定符和限定关联 图5.9 限定关联和一般关联第20页，本讲稿共90页5 限定关联 图5.8表示的意思是，一个Person可以在bank中有多个account。但给定了一个account值后，就可以对应一个Person值，或者对应的person值为null，因为Person端的多重性为0.1。这里的多重性表示的是person和(bank,account)之间的关系，而不是person和bank之间的关系。即：（bank,account）0个或1个person Person多个（bank,account）第21页，本讲稿共90页5 限定关联 需要注意的是，限定符是关联的属性，而不是类的属性。也就是说，在具体实现图5.8中的结构时，account这个属性有可能是Person类中的一个属性，也可能是Bank类中的一个属性（当然，这里在Bank类中包含account属性并不好），也可能是在其他类中有一个account属性。第22页，本讲稿共90页5 限定关联 限定符这个概念在设计软件时非常有用，如果一个应用系统需要根据关键字对一个数据集做查询操作，则经常会用到限定关联。引入限定符的一个目的就是把多重性从n将为1或0.1，这样如果做查询操作，则这个查询操作的效率会很高。所以在使用限定符时，如果限定符另一端的多重性仍为n，则引入这个限定符的作用就不是很大。因为查询结果仍然还是一个结果集，所以也可以根据多重性来判断一个限定符的设计是否合理。第23页，本讲稿共90页6 关联的种类 按照关联所连接的类的数量 自返关联 二元关联 N元关联第24页，本讲稿共90页6 关联的种类 自返关联(reflexive association)又称递归关联(recursive association)，是一个类与自身的关联，即同一个类的两个对象间的关系。图5.10 自返关联 第25页，本讲稿共90页6 关联的种类 对于图5.10中的类，在Rose中所生成的Java代码如下所示：类EnginePart的代码：public class EnginePart public EnginePart theEnginePart;/*roseuid 3E9290390281 */public EnginePart()第26页，本讲稿共90页6 关联的种类 二元关联略。第27页，本讲稿共90页6 关联的种类 N元关联(n-ary association)是在3个或3个以上类之间的关联。第28页，本讲稿共90页5.2.2 聚集和组合 聚集（aggregation）是一种特殊形式的关联。聚集表示类之间整体与部分的关系。在对系统进行分析和设计时，需要描述中的“包含”，“组成”、“分为部分”等词常常意味着存在聚集关系。图5.12 聚集关系 第29页，本讲稿共90页5.2.2 聚集和组合 组合（composition）表示的也是类之间整体与部分的关系，但组合关系中的整体与部分具有同样的生存期。也就是说，组合是一种特殊形式的聚集。图5.13 组合关系 第30页，本讲稿共90页5.2.2 聚集和组合 聚集关系的实例是传递的，反对称的，也就是说，聚集关系的实例之间存在偏序关系，即聚集关系的实例之间不能形成环。需要注意的是，这里说的是聚集关系的实例（即链）不能形成环，而不是说聚集关系不能形成环。事实上，聚集关系可以形成环。第31页，本讲稿共90页5.2.2 聚集和组合-两者的区别 聚集关系也称为“has-a”关系，组合关系也称为“contains-a”关系。聚集关系表示事物的整体/部分关系的较弱的情况，组合关系表示事物的整体/部分关系的较强的情况。在聚集关系中，代表部分事物的对象可以属于多个聚集对象，可以为多个聚集对象所共享，而且可以随时改变它所从属的聚集对象。代表部分事物的对象与代表聚集事物对象的生存期无关，一旦删除了它的一个聚集对象，不一定也就随即删除代表部分事物的对象。在组合关系中，代表整体事物的对象负责创建和删除代表部分事物的对象，代表部分事物的对象只属于一个组合对象。一旦删除了组合对象，也就随即删除了相应的代表部分事物的对象。第32页，本讲稿共90页5.2.3 泛化关系 泛化（generalization）定义了一般元素和特殊元素之间的分类关系，如果从面向对象程序设计语言的角度来说，类与类之间的泛化关系就是平常所说的类之间的继承关系。图5.14 泛化关系 第33页，本讲稿共90页5.2.4 依赖关系 假设有两个元素X、Y，如果修改元素X的定义可能会导致对另一个元素Y的定义修改，则称元素Y依赖于元素X。图5.15 依赖关系 第34页，本讲稿共90页5.3 派生属性和派生关联 派生属性 可以从其他属性推演得到的属性。图5.16 派生属性第35页，本讲稿共90页5.3 派生属性和派生关联 派生关联 可以从其他属性推演得到的关联。图5.17 派生关联第36页，本讲稿共90页5.4 抽象类和接口 抽象类（abstract class）是不能直接产生实例的类，因为抽象类中的方法往往只是一些声明，而没有具体的实现，因此不能对抽象类实例化。第37页，本讲稿共90页5.4 抽象类和接口 接口是类的版型，对于版型这个概念在5.5节中还会介绍。如图5.18所示是接口的3种表示方式。图5.18 接口的3种表示方式第38页，本讲稿共90页5.4 抽象类和接口 需要注意的是，UML中接口的概念和一般的程序设计语言（如Java）中接口的概念稍有不同。例如，Java中的接口可以包含属性，但UML中的接口不包括属性，只包含方法的声明。接口与抽象类很相似，但两者之间存在不同的地方：接口不能含有属性，而抽象类可以含有属性；接口中声明的所有方法都没有实现部分，而抽象类中某些方法可以有具体的实现。第39页，本讲稿共90页5.5 版型 版型是UML的3种扩展机制之一，UML中的另外两种扩展机制是标记值和约束。Stereotype这个词来源于印刷业中的术语，一般在进行正式印刷前，需要进行制版，然后根据做好的版型进行批量印刷。第40页，本讲稿共90页5.5 版型 在2.4节介绍UML的构成时，已提到UML中的基本构造块包括事物（thing）、关系（relationship）、图（diagram）这3种类型。版型是建模人员在已有的构造块上派生出的新构造块，这些新构造块是和特定问题相关的。需要注意的是，版型必须定义在UML中已经有定义的基本构造块之上，是在已有元素上增加新的语义，而不是增加新的文法结构。第41页，本讲稿共90页5.5 版型 UML中预定义了一些版型，如接口是类的版型，子系统是包的版型等。当然用户也可以自己定义版型。图5.19 Actor的3种表示方式 第42页，本讲稿共90页5.5 版型 由于Actor事实上就是一个类，所以也可以给Actor添加属性和操作，就像给类添加属性和操作一样。如图5.20所示是带有操作的Actor的例子。除了预定义的版型外，用户也可以自定义版型，如图5.21所示是自定义版型的例子。第43页，本讲稿共90页5.5 版型图5.20 Actor及其操作 图5.21 自定义版型 第44页，本讲稿共90页5.6 边界类、控制类和实体类 UML中有3种主要的类的版型，即边界类、控制类和实体类。在进行OO分析和设计时，如何确定系统中的类是一个比较困难的工作，引入边界类、控制类和实体类的概念有助于分析和设计人员确定系统中的类。第45页，本讲稿共90页5.6.1 边界类 边界类位于系统与外界的交界处，窗体（form）、对话框（dialog box）、报表（report）以及表示通讯协议（如TCP/IP）的类、直接与外部设备交互的类、直接与外部系统交互的类等是边界类的例子。第46页，本讲稿共90页5.6.1 边界类 如图5.22所示是UML中边界类的3种表示方式。图5.22 边界类的3种表示方式 第47页，本讲稿共90页5.6.1 边界类 通过用例图可以确定需要的边界类。每个actor/use case对至少要有一个边界类，但并非每个actor/use case对都要生成唯一边界类。例如多个actor启动同一use case时，可以用一个边界类与系统通信。如图5.23所示。第48页，本讲稿共90页5.6.1 边界类图5.23 多个参与者使用同一个边界类 第49页，本讲稿共90页5.6.2 实体类 实体类保存要放进持久存储体的信息。所谓持久存储体就是数据库、文件等可以永久存储数据的介质。图5.24 实体类的3种表示方式 第50页，本讲稿共90页5.6.1 实体类 一般地，实体类可以通过事件流和交互图发现，实体类通常用领域术语命名。通常，每个实体类在数据库中有相应的表，实体类中的属性对应数据库中表的字段。但这并不是意味着，实体类和数据库中的表是一一对应的。有可能是一个实体类对应多个表，也可能是多个实体类对应一个表。至于如何对应，已经是数据库模式设计方面的问题了。第51页，本讲稿共90页5.6.3 控制类 控制类是负责其他类工作的类。图5.25是UML中控制类的3种表示方式。图5.25 控制类的3种表示方式 第52页，本讲稿共90页5.7 类图 类加上他们之间得关系就构成了类图，类图中可以包含接口、包、关系等建模元素，也可以包含对象、链等实例。类、对象和他们之间的关系是面向对象技术中最基本的元素，类图可以说是UML中的核心。类图描述的是类和类之间的静态关系。与数据模型不同，类图不仅显示了信息的结构，同时还描述了系统的行为。第53页，本讲稿共90页5.7.1 类图的抽象层次 概念层（conceptual）类图描述应用领域中的概念，一般这些概念和类又很自然的联系，但两者并没有直接的映射关系。画概念层类图时，很少考虑或不考虑实现问题，因此，概念层类图应独立于具体的程序设计语言。说明层（specification）类图描述软件的接口部分，而不是软件的实现部分。这个接口可能因为实现环境、运行特性或者开发商的不同而有多种不同的实现。实现层（implementation）类图才真正考虑类的实现问题，提供类的实现细节。第54页，本讲稿共90页5.7.1 类图的抽象层次 如图5.26所示是同一个Circle类的3个不同层次的情况。概念层 说明层 实现层 第55页，本讲稿共90页5.7.2 构造类图 确定系统中的类是OO分析和设计的核心工作。但类的确定是一个需要技巧的工作，系统中的有些类可能比较容易发现，而另外一些类可能很难发现，不可能存在一个简单的算法来找到所有类。第56页，本讲稿共90页5.7.2 构造类图 寻找类的一些技巧包括：根据用例描述中的名词确定类的候选者。使用CRC分析法寻找类。CRC是类（class）、职责（responsibility）和协作（collaboration）的简称，CRC分析法根据类所要扮演的职责来确定类。根据边界类、控制类和实体类的划分来帮助发现系统中的类。对领域进行分析，或利用已有的领域分析结果得到类。第57页，本讲稿共90页5.7.2 构造类图 参考设计模式来确定类。第14章将介绍软件的设计模式，以及如何根据设计模式得到好的设计。根据某些软件开发过程提供的指导原则进行寻找类的工作。如在RUP（Rational Unified Process）中，有对分析和设计过程如何寻找类的比较详细的步骤说明，可以以这些说明为准则寻找类。第58页，本讲稿共90页5.7.2 构造类图 在构造类图时，不要试图使用所有的符号，这个建议对于构造别的图也是适用的。在UML中，有些符号仅用于特殊的场合和方法中，有些符号只有在需要时才去使用。UML中大约20%的建模元素可以满足80%的建模要求。第59页，本讲稿共90页5.7.2 构造类图 构造类图时不要过早陷入实现细节，应该根据项目开发的不同阶段，采用不同层次的类图。如果处于分析阶段，应画概念层类图；当开始着手软件设计时，应画说明层类图；当考察某个特定的实现技术时，则应画实现层类图。对于构造好的类图，应考虑该模型是否真实地反映了应用领域的实际情况，模型和模型中的元素是否有清楚的目的和职责，模型和模型元素的大小是否适中，对过于复杂的模型和模型元素应将其分解成几个相互合作的部分。第60页，本讲稿共90页5.7.2 构造类图下面给出建立类图的步骤：（1）研究分析问题领域，确定系统的需求。（2）确定类，明确类的含义和职责，确定属性和操作。（3）确定类之间的关系。把类之间的关系用关联、泛化、聚集、组合、依赖等关系表达出来。（4）调整和细化已得到的类和类之间的关系，解决诸如命名冲突、功能重复等问题。（5）绘制类图并增加相应的说明。第61页，本讲稿共90页5.8 领域分析 建立类图的过程就是对领域及其解决方案的分析和设计过程。类的获取是一个依赖于人的创造力的过程，有时需要与领域专家合作，对研究领域进行仔细分析，抽象出领域中的概念，定义其含义及相互关系，分析出系统类，并用领域中的术语为类命名。第62页，本讲稿共90页5.8 领域分析 领域分析（domain analysis）也称问题域分析（problem domain analysis），按A.Spencer Peterson的定义Per91，领域分析是：（1）通过对某一领域中的已有应用系统、理论、技术、开发史等的研究，来标识、收集、组织、分析和标示领域模型及软件体系结构的过程；（2）根据（1）中进行的过程得到的结果。第63页，本讲稿共90页5.8 领域分析第64页，本讲稿共90页5.8 领域分析 对于每个步骤，图中的plan给出了这个步骤和各子步骤的关系。如对于1.2数据收集这一步，有建立数据目录、文献检查、获取专家知识这3个子步骤。数据收集和这3个子步骤的关系用下面的符号来说明：第65页，本讲稿共90页5.9 OO设计的原则 对于OO设计，主要是要求系统的设计结果要能适应系统新的需求变化，一旦需求发生变化，整个系统不用做变动或做很少的变动就可以满足新的需求。下面是OO设计的几条原则：开闭原则（Open/Closed Principle，OCP）Liskov替换原则（Liskov Substitution Principle，LSP）依赖倒置原则（Dependency Inversion Principle，DIP）接口分离原则（Interface Segregation Principle，ISP）第66页，本讲稿共90页5.9.1 开闭原则 开闭原则指的是一个模块在扩展性方面应该是开放的，而在更改性方面应该是封闭的。这个原则说的是，在写模块的时候，应该尽量使得模块可以扩展，并且在扩展时不需要对模块的源代码进行修改。开闭原则最初是由Bertrand Meyer提出来的Mey88，在所有的OO设计原则中，这个原则可能是最重要的。第67页，本讲稿共90页5.9.1 开闭原则 为了达到开闭原则的要求，在设计时要有意识地使用接口进行封装等，采用抽象机制，并利用OO中的多态技术。图5.28 打印输出设计1第68页，本讲稿共90页5.9.1 开闭原则如图5.29所示是改进的设计。图5.29 打印输出设计2第69页，本讲稿共90页5.9.2 Liskov替换原则 Liskov替换原则最早是由Liskov于1987年在OOPSLA会议上提出来的Lis88，这个原则指的是子类可以替换父类出现在父类能出现的任何地方。第70页，本讲稿共90页5.9.2 Liskov替换原则图5.30 Liskov替换原则的图示说明 第71页，本讲稿共90页5.9.3 依赖倒置原则 依赖倒置原则指的是依赖关系应该是尽量依赖接口（或抽象类），而不是依赖于具体类。为了说明依赖倒置原则，先看结构化设计中的依赖关系。如图5.31所示。第72页，本讲稿共90页5.9.3 依赖倒置原则图5.31 结构化设计中的依赖关系 第73页，本讲稿共90页5.9.3 依赖倒置原则 在面向对象的设计中，依赖关系正好是相反的，即与具体实现有关的类是依赖于抽象类或接口的，其依赖关系的结构一般如图5.32所示。第74页，本讲稿共90页5.9.3 依赖倒置原则图5.32 面向对象设计中的依赖关系 第75页，本讲稿共90页5.9.4 接口分离原则 接口分离原则指的是在设计时采用多个与特定客户类（client）有关的接口比采用一个通用的接口要好。也就是说，一个类要给多个客户类使用，那么可以为每个客户类创建一个接口，然后这个类实现所有这些接口，而不要只创建一个接口，其中包含了所有客户类需要的方法，然后这个类实现这个接口。第76页，本讲稿共90页1 使用通用接口的设计第77页，本讲稿共90页2 使用分离接口的设计第78页，本讲稿共90页3 额外注意的问题 不同类中相似方法的名字应该相同。例如，对于输入/输出方法，不要在一个类中用input/output命名，在另一个类中用read/write命名。遵守已有的约定俗成的习惯。例如，对类名、方法名、属性名的命名应遵守已有的约定，或者遵守开发机构中规定的命名方法。第79页，本讲稿共90页3 额外注意的问题 尽量减少消息模式的数目。只要可能，就使消息具有一致的模式，以利于理解。例如，不要在一个消息中，其第一个参数表示消息发送者的URL地址，而在另一个消息中，是最后一个参数表示消息发送者的URL地址。设计简单的类。类的职责要明确，不要在类中提供太多的服务，应该从类名就可以较容易地推断出类的用途。第80页，本讲稿共90页3 额外注意的问题 泛化结构的深度要适当。类之间的泛化关系增加了类之间的耦合性。除非是在特殊情况下（如图形用户界面的类库），一般不要设计有很深层次的类的泛化关系。定义简单的方法。一个类中的方法不应太复杂。如果一个方法太大，很可能就是这个方法包含的功能太多，而有些功能可能是不相关的。第81页，本讲稿共90页3 额外注意的问题 评价设计质量的方法之一是观察它在一段时间内的易变性。一般好的设计变动轨迹如图5.35所示。图5.35 设计变动轨迹 第82页，本讲稿共90页5.10 对象图 对象图表示一组对象及他们之间的联系。对象图是系统的详细状态在某一时刻的快照，常用于表示复杂的类图的一个实例。UML中对象图与类图具有相同的表示形式，对象图中的建模元素有对象和链。对象是类的实例，对象之间的链是类之间的关联的实例，对象图实质上是类图的实例。第83页，本讲稿共90页5.10 对象图 在UML中，对象图的使用相当有限，主要用于表达数据结构的示例，以及了解系统在某个特定时刻的具体情况等。第84页，本讲稿共90页5.10 对象图第85页，本讲稿共90页5.11 小结1UML中的类图具有充分强大的表达能力和丰富的语义，是建模时非常重要的一个图。2类之间可以有关联、聚集、组合、泛化、依赖等关系。3关联是类图中比较重要的一个概念，一些相关的概念有关联名、关联角色、关联类、关联上的角色、限定关联、自返关联、二元关联、N元关联等。4关联类是用于描述关联本身的特性。第86页，本讲稿共90页5.11 小结5带有限定符的关联称为限定关联，限定符的作用就是在给定关联一端的一个对象和限定符值以后，可确定另一端的一个对象或对象集。6派生属性和派生关系是指可以从其他属性和关联计算推演得到的属性和关联，在生成代码时，派生属性和派生关系不产生相应的代码。7抽象类和接口为OO设计提供了抽象机制。第87页，本讲稿共90页5.11 小结8版型是UML中非常重要的一种扩展机制，UML之所以有强大而且灵活的表示能力，与版型这种扩展机制有很大的关系。9边界类、控制类和实体类是对类的一种划分，他们都是类的版型。10类图可分为概念层、说明层和实现层3个层次，他们在软件开发的不同阶段使用。第88页，本讲稿共90页5.11 小结11OO分析和设计中，确定系统中的类是一个比较困难的工作，有一些启发式原则可以帮助发现类，但没有一个固定的方法来确定所有类。12领域分析是帮助发现类的一个有效方法。13OO设计应该遵循一定的原则，如开闭原则、Liskov替换原则、依赖倒置原则、接口分离原则等。第89页，本讲稿共90页5.11 小结14一个设计得好的系统应该具有友好性、可理解性、可靠性、可扩展性、可移植性、可伸缩性、可重用性、简单性等特性。在设计时可能会发现有些特性不能同时满足，这是需要设计人员做出权衡。15对象图是类图的实例，是系统的详细状态在某一时刻的快照。相对于UML的别的图来说，对象图的重要性低一些，在实际应用中，使用对象图的情况不是很多。第90页，本讲稿共90页