UML类图几种关系的总结-tf

第一篇：UML类图几种关系的总结-tf

UML类图几种关系的总结

在UML类图中，常见的有以下几种关系: 泛化（Generalization）, 实现（Realization），关联（Association)，聚合（Aggregation），组合(Composition)，依赖(Dependency)1.泛化（Generalization）

【泛化关系】：是一种继承关系，表示一般与特殊的关系，它指定了子类如何特化父类的所有特征和行为。例如：马是动物的一种，即有马的特性也有动物的共性。

【箭头指向】：带三角箭头的实线，箭头指向父类

2.实现（Realization）

【实现关系】：是一种类与接口的关系，它表示不继承结构而只继承行为，是类与接口之间最常见的关系。准确的说，类不是继承(inherit)接口，而是实现(implement)接口。

【箭头指向】：UML中用带三角箭头的虚线，箭头指向接口

3.关联（Association)

【关联关系】：是一种拥有的关系，它使一个类知道另一个类的属性和方法；如：老师与学生，丈夫与妻子关联可以是双向的，也可以是单向的。双向的关联可以有两个箭头或者没有箭头，单向的关联有一个箭头。

【代码体现】：成员变量

【箭头及指向】：单向关联为带普通箭头的实心线，箭头指向被拥有者，如下图

上图中，老师与学生是双向关联，老师有多名学生，学生也可能有多名老师。但学生与某课程间的关系为单向关联，一名学生可能要上多门课程，课程是个抽象的东西他不拥有学生。

4.聚合（Aggregation）【聚合关系】：是整体与部分的关系，且部分可以离开整体而单独存在。如车和轮胎是整体和部分的关系，轮胎离开车仍然可以存在。

聚合关系是关联关系的一种，是强的关联关系；关联和聚合在语法上无法区分，必须考察具体的逻辑关系。

【代码体现】：成员变量

【箭头及指向】：带空心菱形的实心线，菱形指向整体

5.组合(Composition)

【组合关系】：是整体与部分的关系，但部分不能离开整体而单独存在。如线段和点是整体和部分的关系，没有点就不存在线段。

组合关系是关联关系的一种，是比聚合关系还要强的关系，它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期。【代码体现】：成员变量

【箭头及指向】：带实心菱形的实线，菱形指向整体

6.依赖(Dependency)

【依赖关系】：是一种使用的关系，即一个类的实现需要另一个类的协助，所以要尽量不使用双向的互相依赖.【依赖扩展】：Trufun Plato工具根据实际开发中的需要，在工具箱还提供两个预定义的依赖：许可(permission)依赖和使用(usage)依赖。

 许可依赖（通常作为特定的构造类型）将包或者类与另一个允许它使用某些内容的包或者类相连。许可依赖关系的构造类型有访问、友元、输入。

 使用依赖关系（关键字《use》）将客户元素与服务者元素相连。服务者的变化将导致客户的变化。使用通常表示一种实现的依赖关系，其中的一个元素依靠另一个元素的服务来实现自身的操作。使用的构造类型包括调用、实例（关键字《instantiate》）、参数、发送。

【代码表现】：局部变量、方法的参数或者对静态方法的调用

【箭头及指向】：带箭头的虚线，指向被使用者

各种关系的强弱顺序：

泛化 = 实现 > 组合 > 聚合 > 关联 > 依赖

下面这张UML图，比较形象地展示了各种类图关系： UML因其简单、统一的特点，而且能表达软件设计中的动态和静态信息，目前已成为可视化建模语言的工业标准。

好处：帮助开发团队以一种可视化的方式理解系统的功能需求，UML为交流面向对象的设计中的需求，行为、体系结构以及最后实现提供了一套综合的表示法。

1，UML统一了各种方法对不同类型的系统、不同开发阶段以及不同内部概念的不同观点，从而有效的消除了各种建模语言之间不必要的差异。

2，UML建模能力比其它面向对象建模方法更强。它不仅适合于一般系统的开发，而且对并行、分布式系统的建模尤为适宜。

3，使用UML使硬件组件和软件组件之间将会有更大的透明度。便携性和综合效率将会增加。

我们会编程只是实现的能力，而我们会进行UML建模，则是从全局出发设计和管理的能力。

Trufun致力于软件工程全过程解决方案，提供从需求到测试的完整跟踪过程，愿与各方进行科研、开发等方面的合作。

第二篇：uml实验三 构建类图

实验三 构建类图

【实验目的】

1.理解类的基本概念 2.理解类间的关系 3.掌握类图的绘制方法

4.掌握简单的类图设计方法

【实验器材】

1.计算机一台；

2.Rational Rose 工具软件；

【实验内容】

【题目一】

分析选课系统中的类及关系，然后画出它们的类图。

1）.分析

在选课系统中，通过分析可抽象出如下几个类：（1）学生类（2）管理员类（3）课程类

学生类和管理员类的属性较容易分析，这里只列出课程类的属性和方法：（1）课程名称（2）开课教室（3）课程号（4）授课教师（5）选课的学生（6）开课起始时间

（7）允许选课的学生人数（8）设置课程号（9）设置课程名称（10）查询课程号

（11）查询允许选课的学生人数 2）绘图步骤

下面介绍在Rose2003中创建类和它们之间关系的过程：

（1）在“Logical View“中双击Main图，或者右击“Logical View“，弹出在快捷菜单中选择“New”－>“Class Diagram”，双击图标，出现图2.1，为编辑类图做好准备。

图2.1（2）在逻辑视图中，从工具栏中选择class图标，在右边的绘图区中添加一个新元素，并取名Student表明新增一个类，如图2.2所示。

图2.2（3）选择新创建的元素，点击鼠标右键，在弹出的菜单中选择“Open Sepcification”,弹出图2.3对话框。

（4）在对话框中，可以修改元素的名称，这里新元素的名称定为“Student”，如图2.4所示。

图2.3

图2.4（5）点击“Attributes”选项卡，添加属性，如图2.5所示。

图2.5（6）点击“operations”选项卡，添加方法如图2.6所示。

图2.6（7）同样的方法添加Course类，如图2.7所示。

图2.7（8）创建两个类之间的关系，通过分析得出：学生类和课程类之间为单向关联。选择图标栏的“关联”，由学生类指向课程类。如图2.8所示。

图2.8（9）创建关联名。右击关联，选择“open specification“，键入关联名（select），如图2.9所示。

图2.9（10）分别在“Role A Detail“和“Role B Detail“选项卡中键入名称和多重性，如图2.10所示。

图2.10（11）重复（2）－（10）中的步骤完成选课系统整个类图的创建。（12）如图2.11转换生成代码，查看所生成的三个的代码。

图2.11

【题目二】

已知三个类A、B和C，其中类A由类B的一个实例类和类C的1个或多个实例类构成，请画出能够正确表示类A、B和C之间关系的UML类图。

【题目三】

根据以下描述画出类图，并注明多重性关系：一个学生可以选修多门课程，也可能没有任何课程；一门课程可以被多个学生选修；一个老师可以教多门课程或者不教课；每门课程至少有一个老师，也可以有多个老师任教；每门课程可以有0或1本教材，每本教材只能用于一门课程。

【题目四】

根据下面的代码画出Invoice类的类图，要求标明各属性的类型和可见性以及类方法。

public class Invoice { public double amount;public Date date = new Date();public string customer;public string specification;public string administrator = “unspecified”;static private int number_of_invoices=0;public invoice（）{

number_of_invoices++； } public void print（）

{ System.out.println("The number of invoices is ”+ number_of_invoices);} }

【题目五】

下图是一个仓库管理系统的类模型局部，其中IncomeOrder是指入库单，OrderItem是指入库中的每一项，Product则是产品信息。请指出模型中的错误，说明原因并改正类图。

IncomeOrder11ProductOrderItem

【题目六】

（1）现有一系统需要对商品进行管理，包括添加，删除商品，修改商品信息三项功能，画出系统类图。（商品信息包括商品编号，商品名称，价格，生产厂商等）

（2）如果现在系统需求发生变化，需要能够对损坏商品进行打折，以及可以按照商品的颜色和外形进行查询，则系统类图应该如何修改？

【实验报告要求】

1． 整理实验结果。

2． 小结实验心得体会。

3.所有题目以doc文档或Rose文档形式上传到服务器，而实验报告中只需写题目五和题目六。

第三篇：UML用例图总结

UML用例图

用例图主要用来图示化系统的主事件流程，它主要用来描述客户的需求，即用户希望系统具备的完成一定功能的动作，通俗地理解用例就是软件的功能模块，所以是设计系统分析阶段的起点，设计人员根据客户的需求来创建和解释用例图，用来描述软件应具备哪些功能模块以及这些模块之间的调用关系，用例图包含了用例和参与者，用例之间用关联来连接以求把系统的整个结构和功能反映给非技术人员（通常是软件的用户），对应的是软件的结构和功能分解。

用例是从系统外部可见的行为，是系统为某一个或几个参与者（Actor）提供的一段完整的服务。从原则上来讲，用例之间都是独立、并列的，它们之间并不存在着包含从属关系。但是为了体现一些用例之间的业务关系，提高可维护性和一致性，用例之间可以抽象出包含(include)、扩展(extend)和泛(generalization)几种关系。

共性：都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通后过不同的方法来重用这个公共的用例，以减少模型维护的工作量。

1、包含(include)

包含关系：使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用。基用例控制与包含用例的关系，以及被包含用例的事件流是否会插入到基用例的事件流中。基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。

包含关系对典型的应用就是复用，也就是定义中说的情景。但是有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。

例如：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。这时包含关系可以用来理清关系。

2、扩展(extend)扩展关系：将基用例中一段相对独立并且可选的动作，用扩展（Extension）用例加以封装，再让它从基用例中声明的扩展点（Extension Point）上进行扩展，从而使基用例行为更简练和目标更集中。扩展用例为基用例添加新的行为。扩展用例可以访问基用例的属性，因此它能根据基用例中扩展点的当前状态来判断是否执行自己。但是扩展用例对基用例不可见。对于一个扩展用例，可以在基用例上有几个扩展点。

例如，系统中允许用户对查询的结果进行导出、打印。对于查询而言，能不能导出、打印查询都是一样的，导出、打印是不可见的。导入、打印和查询相对独立，而且为查询添加了新行为。因此可以采用扩展关系来描述：

4、泛化(generalization)泛化关系：子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。在实际应用中很少使用泛化关系，子用例中的特殊行为都可以作为父用例中的备选流存在。

例如，业务中可能存在许多需要部门领导审批的事情，但是领导审批的流程是很相似的，这时可以做成泛化关系表示：

上面是我参考的一篇文章，觉得将三种关系的区别讲得很清晰，在此基础上结合自己的系统，对项目(在线购物系统)的用例做了整体的描绘。

*****************************************************************

(1)系统整体用例图

(商品用例图)

（购买信息用例）

(用户资料用例)

按照先整体用例，后子系统用例来进行描绘的，欢迎大家提出好的建议!

转：UML中扩展和泛化的区别

泛化表示类似于OO术语“继承”或“多态”。UML中的Use Case泛化过程是将不同Use Case之间的可合并部分抽象成独立的父Use Case，并将不可合并部分单独成各自的子Use Case；包含以及扩展过程与泛化过程类似，但三者对用例关系的优化侧重点是不同的。如下：

●泛化侧重表示子用例间的互斥性；

●包含侧重表示被包含用例对Actor提供服务的间接性；

●扩展侧重表示扩展用例的触发不定性；详述如下：

既然用例是系统提供服务的UML表述，那么服务这个过程在所有用例场景中是必然发生的，但发生按照发生条件可分为如下两种情况：

⒈无条件发生：肯定发生的；

⒉有条件发生：未必发生，发生与否取决于系统状态；

因此，针对用例的三种关系结合系统状态考虑，泛化与包含用例属于无条件发生的用例，而扩展属于有条件发生的用例。进一步，用例的存在是为Actor提供服务，但用例提供服务的方式可分为间接和直接两种，依据于此，泛化中的子用例提供的是直接服务，而包含中的被包含用例提供的是间接服务。同样，扩展用例提供的也是直接服务，但扩展用例的发生是有条件的。

另外一点需要提及的是：泛化中的子用例和扩展中的扩展用例均可以作为基本用例事件的备选择流而存在。

第四篇：Uml用例图心得（精选）

Uml用例图心得

序言：用例图主要用来描述“用户、需求、系统功能单元”之间的关系。它展示了一个外部用户能够观察到的系统功能模型图。

【用途】：帮助开发团队以一种可视化的方式理解系统的功能需求。

用例图所包含的元素如下：

1.参与者(Actor)

表示与您的应用程序或系统进行交互的用户、组织或外部系统。用一个小人表示。

2.用例(Use Case)

用例就是外部可见的系统功能，对系统提供的服务进行描述。用椭圆表示。

3.子系统(Subsystem)

用来展示系统的一部分功能，这部分功能联系紧密。

4.关系

用例图中涉及的关系有：关联、泛化、包含、扩展。

如下表所示：

a.关联(Association)

表示参与者与用例之间的通信，任何一方都可发送或接受消息。

【箭头指向】：指向消息接收方

b.泛化(Inheritance)

就是通常理解的继承关系，子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。

【箭头指向】：指向父用例

c.包含(Include)

包含关系用来把一个较复杂用例所表示的功能分解成较小的步骤。

【箭头指向】：指向分解出来的功能用例

d.扩展(Extend)

扩展关系是指用例功能的延伸，相当于为基础用例提供一个附加功能。

【箭头指向】：指向基础用例

e.依赖(Dependency)

以上4种关系，是UML定义的标准关系。但VS2010的用例模型图中，添加了依赖关系，用带箭头的虚线表示，表示源用例依赖于目标用例。

【箭头指向】：指向被依赖项

5.项目(Artifact)

用例图虽然是用来帮助人们形象地理解功能需求，但却没多少人能够通看懂它。很多时候跟用户交流甚至用Excel都比用例图强，VS2010中引入了“项目”这样一个元素，以便让开发人员能够在用例图中链接一个普通文档。

用依赖关系把某个用例依赖到项目上：

然后把项目-》属性 的Hyperlink设置到你的文档上；

这样当你在用例图上双击项目时，就会打开相关联的文档。

6.注释(Comment)

包含(include)、扩展(extend)、泛化(Inheritance)的区别：

条件性：泛化中的子用例和include中的被包含的用例会无条件发生，而extend中的延伸用例的发生是有条件的；

直接性：泛化中的子用例和extend中的延伸用例为参与者提供直接服务，而include中被包含的用例为参与者提供间接服务。

对extend而言，延伸用例并不包含基础用例的内容，基础用例也不包含延伸用例的内容。

对Inheritance而言，子用例包含基础用例的所有内容及其和其他用例或参与者之间的关系；

一个用例图示例：

第五篇：UML复习总结

1.UML(unified modeling language): 统一建模语言是创建描绘软件系统结构和设计蓝图的标准语言。它用于指定、构造、记录软件系统的工件并使之可视化。~ 的基本组成部分：包括 UML 的静态、动态、包和注释等部分。~ 的构建块包含基本的成分、关系和关系图。基本成分包括结构、行为、分组和注释成分。

2.RUP(rational unified process): 统一开发过程是一种过程框架，有助于使用创建和部署用UML设计的软件。~生命周期分为四个阶段：起始阶段、细化阶段、构造阶段、转换 3.软件开发生命周期(SDLC)是一个规范的、系统的软件开发方法。可分为六个阶段：可行性分析、需求分析和规范说明、设计、编码、测试、维护。软件的开发方法：瀑布方法、原型方法、螺旋方法、双赢螺旋方法、增量方法。在设计阶段，有两种~：①面向功能方法以模块为中心，注重软件的功能。②面向对象（OO）方法支持重用、数据封装、以及继承、抽象和多态性等概念。

4.面向对象分析和设计（OOAD）是指根据对象、类、封装、继承、多态、抽象和动态邦定来分析需求以及设计软件系统。

5.软件系统的各个视图：①用例视图：表示系统为客户提供的功能②设计~：侧重于系统的静态和动态表示③实施~：表示软件系统中组成系统所需的各个文件和组件④部署~：表示将执行软件系统和硬件的组合关系。

6.四种建模技术：①需求建模：包括使用用例关系图描述需求。②静态~：包括使用类、对象和复合结构关系图来描述软件系统的静态成分③动态~：包括使用以下关系图来描述动态成分的行为：活动关系图、状态机关系图、通信关系图、序列关系图、交互概览图、时序关系图④架构~： 描述软件系统的内部结构如何构成：包关系图、主件关系图、部署关系图 7.需求管理是一种持续的系统化方法。~的四个阶段： 需求收集、~分析与协商、~规格化、~验证。需求分析指将需求分类和组织为功能性需求和非功能性需求的过程。功能需求指软件系统需要实现的功能和特性。非功能性需求指软件系统需要达到的性能指标。需求验证是在指定需求规范化后对需求进行验证的活动。需求验证包括：①确定所有的模糊需求②确定每条需求的来源③说明需求数量④确定需求之间的依赖关系⑤验证需求是否简明、可测试并且可跟踪⑥验证需求与软件系统中的约束是否有冲突

8.软件需求规格化（SRS）是详细分析任务后产生的文档。~必须提供信息：软件系统定义、SRS文档的用途、软件系统的范围、功能性需求、非功能性需求、目标软件系统的运行条件 9.角色有关的关系：泛化~： 存在于有类似的行为和特性的角色之间继承关系。关联~： 显示用例与角色之间通信关系。

10.用例关系图：①显示目标软件系统的用例和角色之间的交互关系②显示用例之间或角色之间的关系（如关联和泛化等）。用例可以（文本方式，事件流方式）描述外部角色与软件系统之间的交互过程。用例之间的关系：①扩展：指通过获取其它用例的某些功能来建立当前用例的方式扩展关系的箭头方向指向要被扩展的用例②包含：指一个用例的功能包含在另一个用例的功能中。包含关系里箭头指向被包含在另一个用例中的用例。11.类关系图表示类、接口、以及它们之间的关系。对象关系图表示类的特定实例的属性值以及对象之间的关系。类的属性和操作的可见性是：+ :表示属性或操作对于其它类可见。-：表示属性或操作对其它类不可见。#：表示基类的属性或操作仅对它的派生类可见。~:表示属性或操作只对同一个包里的类是可见的。类和对象之间的关系：①关联：表示两个类的对象之间一般上的逻辑意义上的联系。②聚合：表示两个类之间的整体与局部的关系③组合：表示两个类之间的整体与局部的关系④依赖性：表示两个类的对象之间一般上的动态功能上的联系⑤泛化：表示父类与子类之间派生关系⑥实现：表示类关系图里两个元素之间的语义关系，其中一个元素定义一个协议，另一个元素实现这个协议。12．抽象类是没有任何直接实例的类，继承于抽象类的类可以有直接实例，用于定义一组子类的公共特征和公共行为。接口是一组用于表示由类或组件提供的服务的操作集合，只能提供公共方法的声明，而不能提供这些公共方法的实现，不可以创建接口的对象。两者的相同处：①抽象类和接口都提供方法的规范，但是都不允许您直接创建实例。②抽象类和接口中指定的方法实现都在派生类中提供。不同处：①接口使您能实现多继承，因为一个类可以实现多个接口。但是，抽象类不支持多继承。一个类无法继承多个抽象类②抽象类包含的属性和方法可以是公共的、私有的或受保护的。接口只包含方法③抽象类可提供一部分方法的定义但接口不提供任何定义④抽象类在同一个包内使用，而接口可以跨多个包里实现。接口继承与抽象类继承的区别：①接口继承可多继承，而抽象类继承不行②接口继承中全是抽象方法，不提供定义，而抽象类继承中可有方法定义。

13.交互关系图：描述软件系统的成分如何彼此交互以实现系统用例的功能。~有两个部分：①协作者：描述交互关系图中参与交换的系统静态部分②交互：描述交互关系图中静态部分是怎样参与动态协作的。常用的交互关系图有：①序列关系图：以一组按时间顺序排序的消息的形式表示对象之间的交互②通信关系图：以消息的形式表示对象间的交互

14.包关系图用于描述软件系统的各个包以及包之间的关系。使用包来建模软件系统成分的好处有：①以可视化的方式显示功能组以及它们之间的关系②使得大型软件系统易于管理。用例分包规则：①以可视化的方式显示功能组以及它们之间的关系② 使得大型软件系统易于管理。类分包~：①具有相同继承层次结构的类分组在一个包里②具有复合关系的类分组在一个包里③将相互协作、彼此交互的类分组在一个包里。

15.组件:实现一组规定接口功能的可执行部件。组件实现了一组接口。组件类型：①部署组件：描述可执行系统最终可部署部件②工作产品~：描述工程软件有哪些文件组成③执行~：描述可执行软件有哪些可执行部件组成

16.框架和模式是使软件构件可重用的标准。框架：特定领域中类似应用程序的通用功能的模板，增加可重用性和减少应用程序开发时间。其特性：①类或组件的集合，具有执行一些特定或通用的功能②包含一些预定义规范的抽象和具体类接口③可以可通过子类化来扩展和实现这些抽象类和接口④定义一些抽象方法，这些方法接收系统中预定义的消息。模式：

新建的系统能满足可重用的要求，有助于软件组件之间更好的通信。~类型：通用职责分配软件模式（GRASP）、四人组模式(GoF)单例模式：允许创建它自身的唯一一个实例的类。对于有些类只应许创建一个实例对象。用静态数据成员来定义单件模式，以跟踪所创建对象的生命期。设计模式好处：①可让你创建能满足新需求的可重用的解决方案而无需修改现有系统。②有助于软件组件之间更好的通信。③有助于设计的重用、提供最有效的问题解决方案、给类分配职责。

17.实施质量流程的目的是为了在软件开发过程中检查所开发的软件模型和产品的质量。质量流程包括：①用于开发软件系统的软件开发过程的质量②软件开发过程中使用的软件模型的质量③软件开发过程结束时获得的软件产品的质量④质量流程自身的质量。生产质量过硬的产品时需要考虑的维度是：①技术：描述软件开发过程所需的工具以及生成的输出② 方法：描述软件开发过程期间需要执行以生成输出的操作顺序③社会学：描述软件开发过程所需的人力资源、环境条件和技能。质量保证技术检查：语法：确保软件模型使用正确的语法。语义：确保软件模型表达出目标意图并确保软件模型的表示在项目中一致。美观：确保软件模型对称并且完整。UML提供的三种扩展元素为：构造型：扩展 UML 词汇表约束：扩展 UML 构造块的语义关系。标记值：扩展 UML 构造块的属性

18静态建模：它表示软件系统的静态或结构成分。它包括类关系图和对象关系图。它有助于描绘系统成分之间的关联和依赖性。动态建模：它表示软件系统静态成分的行为过程。它包含交互、活动和状态关系图。它有助于表达系统在一段时间内的行为流程。