UML类图详细教程

第4章UML类图·定义类图·为什么要建模类图·类图的主要标记符号·如何建模类图【学习目标】4.1UML基本类图面向对象的基础就是使用类。类是用来代表现实事务或者功能的构造块。在本节中，我们将要学习如何建模类及其相互之间的关系，以便在编写代码之前让你对系统拥有全面的认识。类图是由若干类关联在一起，反映系统或者子系统组成结构的静态图。类图的建模贯穿工程的分析和设计阶段的始终，通常从商务伙伴能够理解的类开始建模，最终往往成为只有开发小组才能够完全理解的类。一、类图的组成类图由如下元素组成：类(Class)：是具有共同结构特征、行为特征、联系和语义的对象集合的抽象形式。关联（Association）：它表示类与类之间的关系。二、UML类图中的符号（一）类类（Class）在UML中通常以实线矩形框表示，矩形框中含有若干分隔框，分别包含类的名字、属性、操作、约束以及其他成分等，如下图所示。类的图形表示和示例在类图中，根据建模的不同景象，类图标中不一定列出全部的内容。如在建立分析模型或设计模型时，甚至可以只列出类名，在图中着重表达的是类与类之间的联系；在建立实现模型时，则应当在类图标中详细给出类的属性和方法等细节。1.属性属性（Attribute）在UML类图标的矩形框中用文字串说明，如下图所示。可视性（Visibility）标记表示：+公共＃保护-私用可视性也可以用以下关键字表示：public（公共）、protected（保护）、private（私用）。若可视性标记为“+”或“public”，则为公共属性，可以被外部对象访问。若可视性标记为“#’或“protected”，则为保护属性，可以被本类或子类的对象访问。若可视性标记为“-”或“private”，则为私用属性，不可以被外部对象访问，只能为本类的对象使用。可视性可以缺省，表示该属性不可视。Student类属性类型表示：冒号“：”后跟属性值的数据类型。数据类型的表示依赖于实现语言，如有的程序设计语言规定浮点数用保留字“Float”表示，有的则规定用保留字“Real”表示。Student类数据类型可以是任何用户需要的内容，包括：来自程序设计语言如VisualBasic、C＋＋、C＃和Java的任何标准数据类型。一个已经定义的类。接口定义语言（InterfaceDefinitionLanguage，IDL）中的数据类型列表中的数据类型。读者在自己的系统建模中能够使用的其他类型。属性初始值设置：可以通过在属性名称和数据类型之后添加等于号（＝）来为属性指定默认值，如下图所示。属性多重性：多重性为可选项，它表达该类的每个实例的属性值的个数。可以像应用于类之间的关系中那样把多重性应用于属性。例如，Student类具有属性Grades。不希望该属性只包含单个值，而是希望它包含该学生的所有成绩，可以是任意多个。派生的属性：另一种可以为属性提供的信息是派生值，它可以使用数学函数、字符串函数或者将要在应用程序中实现的其他商务逻辑。要想指出一个属性是派生的，需要在属性名之前添加一个前斜线（／），并且要附加一个注释，其中包含了派生属性值的指令，如下图所示。2.操作(方法)操作（Operation）表示类能够提供的功能服务。它在UML类矩形框中用文字串说明，如下图所示。操作名指示类可提供的功能服务，它后跟圆括号中的参数列表是可选项，即一个操作可以有参数，也可以没有参数。参数列表由逗号分隔的操作的形式参数组成，其格式为：参数名：类型=缺省值，…Student类返回列表是返回给调用者的单个变量值，它可以表示该操作程序运行的一个成功标志或者计算的值。3、类的关系类之间可以建立四种关系：关联、依赖、聚合和泛化。其标记如下图所示。1）关联关系关联关系是指类之间的语义联系。关联可以具有如下特性：关联名称角色名称多重性导航性多个类可以关联到同一个类多重性：多重性（mutiplicity）用来指示一个类的多少对象与另一个类的一个对象相关。可以在类关系的任何一端添加多重性，来指示出多重性，如下图所示。多重性是一个数值或者数值范围，用来指示一个类的几个对象与另一个类的一个对象相关。如下图所示。关联的多重性角色类关系还可以通过添加角色来进一步丰富。在类图中使用角色可以帮助读者理解第一个类对于第二个类的作用。角色与多重性显示在相同的位置，在指示类之间关系线的上面或者下面，如下图所示。下图显示了player类和Team类在关联中分别扮演两个角色。关联的限定关联的限定类的关联还可以通过限定条件来明确类之间的关系。如下图所示。类的自反关联自反关联：类具有到自身的关联，称为自反关联。类的自反关联关联的导航性导航性表明类的关联方向。如下图所示。关联和属性在类关联和类属性之间存在精密的联系。源类和目标类之间的关联意味着源类的对象能够承载到目标类对象的引用。如下图所示。关联类OO建模的一个普遍问是，当类之间具有多对多关系时，一些属性不能容易地放人任何一个类中。例如，下图所示的公司与员工的类关系。模型表达意义：每个Person对象能够为很多Company对象工作。每个Company对象能够雇佣很多Person对象然而，当每个Person与雇佣它的Company间存在薪水属性时会发生什么呢？薪水记录在何处呢？记录在Person类中还是在Company类中？答案是薪水实际上是关联本身的特性，对于Person对象和Company对象之间的每个雇佣链接都存在特定雇佣的特定薪水。UML允许你使用关联类来建模这种情况，如下图所示。2）依赖关系依赖关系是指一个类的元素使用了另一个类。依赖关系描述类之间的引用关系。3）泛化关系泛化关系是描述类之间的继承关系。利用泛化来表达类之间的相似性。练习：阅读一个类图在这个练习中，将会通过识别到目前为止学习的UML标记符来阅读下面的类图，如图所示。练习步骤：1）指出建模的类。2）指出所有属性及其显示的数据类型。3）指出所有显示的操作。4）指出找到的关联。5）指出建模的角色。6）指出图中使用的多重性。例售票系统的类图上图中的售票系统类图，它只是售票系统领域模型的一部分。图中表示了几个重要的类，如Customer、Reservation、Ticket和Performance。一个顾客可多次订票，但每一次订票只能由一个顾客来执行。有两种订票方式：个人票或套票，前者只是一张票，后者包括多张票。每场演出都有多张票可供预定，每张票对应一个唯一的座位号。每次演出用剧目名、日期和时间来标识。三、学习如何建模类图创建类图需要两个反复执行的步骤：1)确定类及其关联。2)确定属性和操作。开始创建类图的好起点就是用例图。如下面成绩管理的用例图所示。1．确定类和关联首先要做的是通过分析用例图确定类及其关联。找到第一批类，确定它们的内容。在用例图中，首先确定了Grades类和ReportCard类。接下来，通过同时使用参与者名称确定附加的类。这时将会确定Teacher类，Student类和Administrator类。下面检查用例图并且确定各个功能所属的类：发布卡一Grades类记录分数一Grades类更新分数一Grades类保存分数一Grades类加载分数一Grades类登录一？查看分数一Grades类生成报告卡一ReportCard类首先发现的是登录没有所属的类。可以添加一个Logon类来处理Logon用例。现在可以开始创建类的关联：Teacher记录、更新、查看GradesAdministrator查看Grades、生成ReportCardsStudent查看GradesReportCards包含Grades进一步创建类的关联：增添WebSite类和Logon类下一步通过添加多重性让类图的信息更加详细，并且对类图进行调整以便保证没有冗余的类和关联。2．确定属性和操作现在我们已经创建好了类和关联，可以开始添加属性和操作以便提供数据存储和需要的功能来完成系统功能。在下图中可以看到，表示参与者的类没有显示属性和操作，这并不意味着它们不存在，而只是表示类图不需要该细节。最后，为属性和操作提供参数、数据类型和初始值。如下图所示:练习：建模一个类图在这个练习中，将会从用例图建模一个类图。读者应该遵循前面介绍的步骤来建模类图支持如下面用例图中用例。练习步骤：1）确定可以在用例图中找到的类。2）创建关联类，给出它们的关联名词。3）巩固相似的类。4）确定任何合适的角色名。5）为任何已经封装到另一个类中的独立功能添加类。6）添加属性和操作以便提供类图中需要的功能。7）为操作和属性提供数据类型和参数等信息公司直销系统用例图4.2UML扩展类图一、聚合和组合在前面，已经介绍过类之间的简单关联，知道了它们在类图中使用连接类的单线表示。本节将介绍如何更好地限定这些关联，其方法是以聚合或者组合的形式来定义关联。这两种新的关联类型都描述了类之间的整体——部分组成关系。1．聚合聚合用来描述两个类之间的整体——部分关系，其中一个类为整体，它由一个或者多个部分类组成。在聚合中，部分类可以没有整体类而存在。如下图所示。例如，CPU和显示器都可以以独立类的形式存在，但是当它们组成Computer类时，它们就变为整个计算机的组成部分。通过提供其他的计算机部件，如键盘、鼠标和扬声器来扩展该示例，如下图所示。2．组合组合是一种特殊的聚合关联。在组合关联中用来组成整体类的部分类是不能独立存在。整体类由部分类组成，部分类需要整体类才能存在。这种关系意味着销毁整体类将会同时销毁部分类。组合关联使用带有实心菱形的实线连接，如下图所示。由于组合关联指示的部分类是强制的，对于整体类意味着至少有一个多重性。在下面的示例中，整体类数据库由表和查询组成。这些关联使用组合表示，因为如果没有数据库，表和查询也不会存在，如图所示。另一种建模组合关联的方法称为图形容器。使用这种方法，整体类绘制成一个大矩形框，所有的部分类都包含在其中，如下图所示。3．使用带有泛化的聚合和组合聚合和组合表示的是类之间的关系，它们可以与泛化结合来进一步扩展类图模型，如下图所示。练习：建模聚合关联和组合关联在这个练习中，将会使用目前为止学习到的所有类型的关系来创建一个类图，这些关系包括普通关联、泛化、聚合和组合。读者将会综合运用自己的知识从需求构造一个类图。下面是一个制造商和维修店使用的存货清单系统的需求列表，从这些信息构造一个类图：存货由两个部分组成（零件和产品）。产品由两个或者更多零件组成，系统可以拥有无限多个零件和产品。存货中的部分零件包括调速轮、轮齿和加力燃烧室。一名仓库保管员维护货存。一名装配工组装产品，一名维修员维修产品。完成的产品包括1-3个标签：Manufacturer标签指示产品已经完成；Repair标签指示产品已经检修过；FCC标签指示产品中包含加力燃烧室。二、关联注释本节学习如何使用约束和鉴别器来标注泛化关联。约束用来指示泛化有一个与其相关的约束。鉴别器用来指示泛化关系对于两个相关的类扮演什么角色。1．约束约束可以预定义或者由用户定义。用户定义的约束可以在系统中具有任何需要的意义。下面介绍几个UML提供的预定义约束。掌握了这些预定义约束之后，读者就可以生成自己的约束以便更好地符合自己系统需求。有两种方式用来为泛化建模约束。当有两个或者多个泛化使用相同的约束时，可以绘制虚线穿过两个泛化，并且在花括号（{…}）中标注约束名。如果只有一个泛化，或者多个泛化共享关联的空箭头部分，只需在朝向空箭头的花括号中建模约束即可，如下图所示。第一个要介绍的约束是不完全约束。这种约束表示泛化或者子类化的类清单是不完全的，即类图中没有完全显示出它们。这种约束可以让读者知道实际内容不止他们在眼前类图中所看到的，另一个类图中可能还有，如下图所示。第二种约束是完全约束。这种约束与不完全约束相反，表示读者看到的是全部内容，如下图所示。解体约束表示在紧靠约束下面的泛化类不能子类化为通用类。重叠约束与解体约束的作用相反。重叠约束表示两个子类可以共享相同的子类。2．鉴别器鉴别器用来说明泛化的作用。它们指示出泛化关联中的子类应用于相关超类时的角色。鉴别器的标记符非常简单，在关联的空箭头的旁边标注即可，如下图所示。在下面的示例中，使用了鉴别器来表示Flywheel和Afterbumer子类是Part类的类型，如下图所示。一个更加详细的示例如下图所示，其中为4个指定了重叠约束的类图添加了鉴别器。三、端点标记符讨论关联的有序、排序和导航。有序和排序允许向读者说明与超类相关的子类指定了特定的顺序，而使用导航可以指定处理流遍历关联关系的方向。1．有序和排序有序约束用来说明一个类的对象以某个次序与另一个类的对象相关。这种标记符并没有指定顺序。排序约束表示类中的对象在与关联中其他类对象相关是排序好的。可以在任何关系的底部添加有序约束和排序约束，如下图所示。2．导航对于读者前面看到的关联，导航都是双向的。可以从一个类到另一个类双向使用关系中向用户公开的属性。如果你不想让自己的系统或者特定的类关系以这种方式操作，可以指定单向的导航。导航使用指向被访问类的开放箭头表示。练习：建模类图的多个关联在这个练习中，将使用所有类型的关联以及关联注释和端点标记符来创建一个类图。综合运用所学的知识从需求构造一个类图。下面是前面的货存清单系统Part类的更加详细需求清单，从这些信息构造一个类图。两个或者多个Parts组装成一个Product。Product类可以访问Part类，反之则不行。3个Parts类型(Flywheel，Cog和Afterburner）不能构成货存清单系统中零件的完整清单，但是这里我们只考虑这3个零件。Flywheel有两种不同的规格：toothflywheel和gearflywheel，它们之间没有任何相似性。Afterburner可以分类为turbo或者hydro。这两种类型都可以分拆为ballistic类型。ballistichydro和ballisticturbo加力燃烧室由plutoniummarbles组成，后者已经组装好。4.3UML类图建模案例例1图书管理系统的类图建模1、图书管理系统的用例图模型如下：2．确定类和关联首先要做的是通过分析用例图确定类及其关联。找到第一批类，确定它们的内容。在用例图中，可首先确定了如下对象类：借阅者（Borrower）类，书刊（Title）类，物理书（Book）类，借阅记录（Loan），预定记录（Reservation）,图书管理员（librarian）等六个类。实体类图3．建立类图用户界面类图类图类图类图类图练习：对选课系统建模UML类图4.4分析模型和设计模型中的UML类图一、分析模型分析模型是在系统需求描述（用例图模型）的基础上，对如何构造系统给出的系统逻辑结构描述。即把用例图模型中的用例需求描述推进到分析模型中的如何构造系统来实现用例功能。分析模型是系统构造的概念模型。分析模型包含如下部分：分析模型的组成1.分析包分析包是指分析模型中使用的包，它可以包含：分析类用例实现（交互图）包是UML的分组模型元素的容器，它是把UML图形元素和图本身组织到组中的通用机制。包可应用在任何UML模型中，如用例图模型、分析模型、设计模型等。包的UML标记包的依赖包的嵌套包的泛化构架分析角色可以通过这三种分析类协同实现用例的功能。2.分析类分析类是指分析模型中使用的类，它可以包含如下形式：边界类实体类控制类边界类实体类控制类1．边界类边界类位于系统和外界角色的交界处，边界类实现业务角色、业务员工与用例的交互，它可以是窗体类、报表类，也可以是与信用卡阅读器、条形扫描器等设备的接口。边界类接收角色的交互信息，有时它还承担交互信息的转换任务，边界类是类的变体。2．实体类实体类负责存储、加工信息，是对用户最有意义的类，通常用业务领域的术语命名。一般利用数据库对这种实体类建立相应表格。实体类是业务实体的计算机描述。3．控制类控制类协调边界类和实体类的工作。每个用例通常有一个控制类控制用例中的动作顺序。控制类也称管理类，一般控制类在用例之间是共用的。用例向控制类委托责任。控制类本身不完成任何服务功能，被控制的类并不向控制类发送许多信息，而是由控制类发出许多信息。二、设计模型设计模型可看成是分析模型的细化，它与分析模型都是为系统同一个部分建模，但是设计模型添加了详细和特定技术的解决，并包含实现的详细信息。设计模型是系统构造的物理模型。设计模型由下面部分组成：设计子系统设计类设计接口设计交互图1.设计子系统设计子系统是将包的概念从分析的概念视图发展到了系统的物理模型。分析包与设计子系统（设计包）存在对应关系，即可追踪。大多数情况下，它们是一一对应。但有时，可能根据系统构架和技术的考虑而将一个分析包撤分成一个或多个设计子系统。设计类主要集中在类图、类、类属性、类操作和类与类之间的关联、关联基数等基本要素的细化，如下图所示。2.设计类完整的原始的高内聚的低偶合的形式良好设计类的基本特征：一个分析类可以被分解为一个或多个设计类与接口3.设计接口接口说明了操作的命名集合。接口背后的关键思想是通过诸如类或子系统这样的类元将功能性规格说明同它的实现相分离。接口的UML标记接口的依赖关系接口的实现关系完整的操作名操作语义可选的构造型接口中可包含的内容：属性操作实现接口中不可包含：子系统与接口组件与接口三、分析模型与设计模型的取舍在如下情况下，需要建立系统的分析模型：介绍新人加入项目。在交付几个月或几年后重新理解系统。理解系统是怎样满足客户需求以及提供可跟踪性。维护和增强。理解系统的逻辑构架。外包系统的构造。案例分析：进销存系统建模