uml中的关系

合集下载

UML中的各种关系的表示和箭头指向

UML中的各种关系的表示和箭头指向

1、依赖关系2、继承关系3、聚合关系4、合成(组合)关系5、关联关系6、接口一、依赖:虚线箭头。

有箭头的那一端为被依赖关系。

代码体现:在一个类中,某个方法的参数为另外一个类(或几个类)的类型。

pblicclassA { public int Sales(classBclsB){} REM sales是classA中的一个函数}二、继承:空心三角+实线表示。

有三角的那端为被继承者。

代码体现:一个类在声明的时候后面加“:”和被继承类的类名。

例如:classbird:animal.三、聚合:空心菱形+实线箭头。

箭头那端为被包含的对象。

即对象A可以包含对象B,但是对象B不一定是对象A的一部分。

代码体现:在一个类中有另一个类的对象,而且可以使对象数组。

public class classA { public classB() clsB }四、合成(组合):实心菱形+实线箭头。

箭头那端为被组合的对象。

代码体现:在A类中,初始化时,实例化B类。

它们同时生成。

(如何生成A类?)。

public class classA { private classBclsB { clsB=new classB(); } }五、关联:实线箭头。

箭头那端表示被引用的对象。

一个类要知道另一个类。

代码体现:在一个类中,引用到另一个类。

(如何引用类?)例如: class class1 { private class2 cls1; }六、接口:空心三角+虚线。

三角那端是定义接口类。

代码体现:定义一个类的时候加“:”和接口名。

在类中重写接口中的方法。

UML之用例图箭头方向2009年10月16日星期五09:42 P.M. UML之用例图(use case)箭头方向:老是忘记箭头方向,惹笑话。

1、Association,无箭头,Actor连接UseCase即可;2、DirectedAssocition,Actor连接UseCase,箭头由Actor指向UseCase(角色指向用例);3、Generalization,继承,我把它念成“继承于”,当然是箭头由子指向父啦;4、Dependency,我念成“依赖于”,就知道箭头方向了;5、Include,我念成“包含了”,箭头由包含者指向被包含者;6、Extend,我念成“扩展于”或“扩展自”,箭头由扩展出来的“子”指向它的“父”;总结:除了包含方向外,其它都是“小”的指向“大”的,“子”指向“父”,“一般”指向“抽象”。

UML中的四种关系总结

UML中的四种关系总结

UML中的四种关系总结UML中的关系主要包含四种:关联关系、依赖关系、泛化关系、实现关系。

当中关联关系还包含聚合关系和组合关系。

1、关联关系(Association)关联关系式⼀种结构化的关系,是指⼀种对象和还有⼀种对象有联系。

给定关联的两个类。

能够从当中的⼀个类的对象訪问到还有⼀个类的相关对象。

关联关系⽤⼀条实线表⽰。

演⽰样例1.1、聚合关系(Aggregation)聚合是关联的特例。

聚合是表⽰总体与部分的关系,即has a 关系。

聚合关系中的总体和部分是能够分离的,他们能够具有各⾃的⽣命周期,部分能够数据多个总体对象。

演⽰样例1.2、组合关系(Composition)组合关系式关联关系的⼀种特例。

他体现的是⼀种contains a的关系。

这样的关系⽐聚合更强。

它相同也体现了总体与部分的关系。

此时总体与部分是不可分的,总体的⽣命周期结束也就意味着部分的⽣命周期结束。

演⽰样例`2、依赖关系(Dependency)依赖关系式类与类之间的连接,表⽰⼀个类依赖于还有⼀个类的定义。

当中⼀个类元素是独⽴的,还有⼀个类元素不是独⽴的,它依赖与独⽴的那个类。

假设独⽴的类改变,将影响依赖与它的那个类。

演⽰样例3、泛化关系(Generalization)泛化关系式⼀个类(⼦类、⼦接⼝)继承另外⼀个类(⽗类、⽗接⼝)的功能。

⼦类还能够添加⾃⼰的新功能。

继承是类与类或者接⼝与⼏⼝之间最常见的关系之中的⼀个。

4、实现关系(Realization)实现关系指的是⼀个class类实现interface接⼝(能够是多个)的功能;实现是类与接⼝之间最常见的关系。

演⽰样例:⽐較聚合关系VS组合关系组合跟聚合差点⼉同样,唯⼀差别就是“部分”不能脱离“总体”⽽单独存在。

关联关系VS聚合关系关联关系中两个类是出于同样的层次。

⽽聚合关系中两个类是出于不平等的层次,⼀个表⽰总体,⼀个表⽰部分。

请简述uml中四种基本关系的含义和作用

请简述uml中四种基本关系的含义和作用

请简述uml中四种基本关系的含义和作用UML(Unified Modeling Language)是一种用于软件系统建模的标准语言。

在UML中,有四种基本关系,分别为依赖关系、关联关系、聚合关系和组合关系。

下面将对每种关系的含义和作用进行详细的解释。

1.依赖关系:依赖关系表示一个类的改变会引起另一个类的改变,但是两个类之间的关系不是强依赖的。

在依赖关系中,一个类需要另一个类的一些功能或资源才能完成自己的任务。

依赖关系通常体现在方法参数、方法返回值、方法中的局部变量或静态方法的调用等方面。

作用:-解耦:依赖关系可以降低类之间的依赖程度,提高系统的灵活性和可维护性。

-重用:通过依赖关系,一个类可以复用另一个类的功能,提高代码的重用性。

-扩展:通过依赖关系,一个类可以使用另一个类的功能,使得系统可以更方便地进行扩展和演化。

2.关联关系:关联关系表示类与类之间的连接,用于描述类之间的结构性的、静态的关系。

在关联关系中,一个类对象可以通过引用来使用另一个类对象的功能和资源。

关联关系一般是双向的,可以是单向的、双向的或自反的。

作用:-数据共享:通过关联关系,类可以共享另一个类的数据,实现数据的共享和交流。

-在系统的结构设计中起到桥梁作用:关联关系可以用于描述系统的结构,帮助开发人员对系统进行设计和实现。

3.聚合关系:聚合关系表示整体与部分之间的关系,它是一种弱的关联关系。

在聚合关系中,整体对象可以包含部分对象,但是部分对象的生命周期可以独立于整体对象而存在。

作用:-描述整体与部分之间的关系:聚合关系可以用于描述整体与部分之间的关系,帮助开发人员更好地理解系统的结构。

-组织和结构化数据:通过聚合关系,可以将对象进行组织和结构化,使得数据的管理更加便捷。

4.组合关系:组合关系也表示整体与部分之间的关系,但是它是一种强的关联关系。

在组合关系中,整体对象包含了部分对象,同时部分对象的生命周期与整体对象的生命周期相同。

10 UML类目关系

10  UML类目关系

2泛化(generalization) 泛化( ) 定义: 定义: 泛化是一般性事物(称为超类或父类) 泛化是一般性事物(称为超类或父类)和它的较为特殊种类 (称为子类)之间的一种关系,有时称为“is-a-kind-of”关 称为子类)之间的一种关系,有时称为“is- kind-of 关 系。 4点说明: 点说明: 点说明 子类可继承父类的属性和操作,并可有更多的属性和操作; 子类可继承父类的属性和操作,并可有更多的属性和操作; 子类可以替换父类的声明; 子类可以替换父类的声明; 若子类的一个操作的实现覆盖了父类同一个操作的实现, 若子类的一个操作的实现覆盖了父类同一个操作的实现, 这种情况被成为多态性, 这种情况被成为多态性,但两个操作必须具有相同的名字 和参数。 和参数。
注:在大多数情况中,用类和接口之间的泛化来表明继承关系。在UML 在大多数情况中,用类和接口之间的泛化来表明继承关系。 中,也可在其他类目之间创建泛化,例如在结点之间。 也可在其他类目之间创建泛化,例如在结点之间。
表示: 表示: 分离表示法
共享表示法
3细化(realization) 细化( ) 定义:细化是类目之间的一种语义关系, 定义:细化是类目之间的一种语义关系,其中一个类目规 约了保证另一个类目执行的契约。 约了保证另一个类目执行的契约。 说明:在以下2个地方会使用实现关系: 说明:在以下2个地方会使用实现关系: •接口与实现它们的类和构件之间; 接口与实现它们的类和构件之间; •用况与实现它们的协作之间。 用况与实现它们的协作之间。 表示: 表示:
左图的限定符有一个属性account#,表明:在一个银行中, 左图的限定符有一个属性account#,表明:在一个银行中, account# 一个帐户对应一个用户,或没有对应人员。 一个帐户对应一个用户,或没有对应人员。 右图的限定符有两个属性,它们与Chessboard Chessboard一起确定了 右图的限定符有两个属性,它们与Chessboard一起确定了 Square, Square是其组成部分 是其组成部分。 Square,且 Square是其组成部分。

UML图中类之间的关系_依赖,泛化,关联,聚合,组合,实现答辩

UML图中类之间的关系_依赖,泛化,关联,聚合,组合,实现答辩

UML图中类之间的关系:依赖,泛化,关联,聚合,组合,实现1.2.3.4.5.6.类与类图1 类(Class封装了数据和行为,是面向对象的重要组成部分,它是具有相同属性、操作、关系的对象集合的总称。

2 在系统中,每个类具有一定的职责,职责指的是类所担任的任务,即类要完成什么样的功能,要承担什么样的义务。

一个类可以有多种职责,设计得好的类一般只有一种职责,在定义类的时候,将类的职责分解成为类的属性和操作(即方法)。

3 类的属性即类的数据职责,类的操作即类的行为职责一、依赖关系(Dependence依赖关系(Dependence):假设A类的变化引起了B 类的变化,则说名B类依赖于A类。

• 依赖关系(Dependency 是一种使用关系,特定事物的改变有可能会影响到使用该事物的其他事物,在需要表示一个事物使用另一个事物时使用依赖关系。

大多数情况下,依赖关系体现在某个类的方法使用另一个类的对象作为参数。

• 在UML中,依赖关系用带箭头的虚线表示,由依赖的一方指向被依赖的一方。

[java] view plaincopyprint?1. public class Driver2. {3. public void drive(Car car4. {5. car.move(;6. }7. ……8. }9. public class Car10. {11. public void move(12. {13. ......14. }15. ……16. }{car.move(;}……}public class Car{public void move({......}……}依赖关系有如下三种情况:1、A类是B类中的(某中方法的)局部变量;2、A类是B类方法当中的一个参数;3、A类向B类发送消息,从而影响B类发生变化;GeneralizationGeneralization A是B和C的父类,B,C具有公共类(父类)A,说明A是B,C的一般化(概括,也称泛化)• 泛化关系(Generalization也就是继承关系,也称为“is-a-kind-of”关系,泛化关系用于描述父类与子类之间的关系,父类又称作基类或超类,子类又称作派生类。

uml函数调用关系

uml函数调用关系

uml函数调用关系
UML函数调用关系指的是在UML类图中,一个函数如何调用其他函数的关系和方式。

在UML类图中,函数之间的调用关系一般用箭头表示,箭头从调用函数指向被调用函数。

通过这种方式,可以清晰地描述函数之间的关系,帮助开发人员更好地理解和设计代码。

在UML类图中,函数的调用关系可以分为以下三种:
1. 组合关系:组合关系是指一个函数调用另一个函数,但是调
用函数的生命周期独立于被调用函数,即调用函数的生命周期并不依赖于被调用函数的生命周期。

在UML类图中,组合关系通常使用实线箭头表示。

2. 聚合关系:聚合关系是一种“部分-整体”的关系,其中一个函数包含另一个函数,并且被包含的函数可以独立于包含函数而存在。

在UML类图中,聚合关系通常使用带空心菱形的实线箭头表示。

3. 继承关系:继承关系是一种面向对象编程中的重要概念,其
中一个函数可以继承另一个函数的属性和方法。

在UML类图中,继承关系通常使用带空心三角形的实线箭头表示。

总之,UML函数调用关系是一个非常重要的概念,它可以帮助开发人员更好地理解和设计代码,从而提高代码的质量和可维护性。

- 1 -。

UML中关系在visio中的表示

UML中关系在visio中的表示

Uml 关系主要有四大类:依赖,关联,泛化,实现。

其中依赖和关联是事物之间语义上的横向关系,泛化和实现是事物之间的纵向关系。

一:依赖Dependency图示:----->定义:关系最为松散的,单向的,暂时产生关系的事物之间使用。

使用图例:在静态图、组件图、部署图中两事物的弱依赖关系用此图示。

二:关联Association图示:此图为visio中画法(在uml静态结构中,拖动复合图例,然后双击此图例,将出现下图,在关联端list中,聚合列都选择无,然后在isNavigable列中选择划箭头的端。

然后点选确定,就出现右侧的关联图例)。

定义:两事物之间的比较密切关系。

实体之间的一个结构化关系表明对象是相互连接的。

箭头是可选的,它用于指定导航能力。

如果没有箭头,暗示是一种双向的导航能力。

关联转换为一个实例作用域的变量。

可为一个关联附加其他修饰符。

多重性(Multiplicity)修饰符暗示着实例之间的关系。

使用图例:在静态图中使用,其他图中也有类似的关联关系,但细化为其他关系。

其中具体细分了两种关系:聚合和组合。

1聚合Aggregation图示:此图为visio中画法(在uml静态结构中,拖动复合图例,然后双击此图例,将出现下图,在关联端list中,在聚合列中在需划箭头端选择共享选项。

然后点选确定,就出现左侧的聚合图例)。

定义:整体和个体之间的关系,个体生命周期的消亡对整体生命周期没有太大的影响。

has a的关系。

聚合是关联的一种形式,代表两个类之间的整体/局部关系。

聚合暗示着整体在概念上处于比局部更高的一个级别,而关联暗示两个类在概念上位于相同的级别。

聚合也转换成一个实例作用域变量。

关联和聚合的区别纯粹是概念上的,而且严格反映在语义上。

聚合还暗示着实例图中不存在回路。

换言之,只能是一种单向关系。

2组合Composition图示:此图为visio中画法(在uml静态结构中,直接拖动复合图例)定义:整体和个体之间的关系,contains a 的关系。

uml课件第3章

uml课件第3章

+executive
Command
+ Execute()
OpenCommand
+ Execute()
PasteCommand
+ Execute()
30
(2) OpenCommand和PasteCommand是什么关系? 组合 泛化(类属)
聚合
④ 没关系
(3) 编辑菜单(EditMenu)是一种菜单,下面哪个图较好的描述 了二者之间的关系?
可以用于用例之间的依赖关系的衍型
可以用于为对象间的交互作用建模的衍型 可以应用于状态机上下文中的衍型
(13)<<become>> (14)<<call>> (15)<<copy>> (16)<<send>> (11)<<extend>> (12)<<include>>
(9)<<access>> (10)<<import>>
Customer
Date
4
StarUML是什么?
适合用户的UML工具 StarUML™是支持UML (Unified Modeling Language(统一模
型语言))的建模平台软件。
基于UML1.4版本,提供11种不同类型的图,采纳了UML2.0的
表示法。
通过支持UML轮廓(profile)的概念积极地支持UMD(Model
1第3章uml的关系2uml的关系?依赖dependency关系?类属generalization关系?关联association关系?实现realization关系3依赖关系?如果一个模型元素的变化会影响另一个模型元素这种影响不必是可逆的那么就说在这两个模型元素之间存在依赖关系
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

uml中的关系1、关联双向关联:C1-C2:指双方都知道对方的存在,都可以调用对方的公共属性和方法。

在GOF的设计模式书上是这样描述的:虽然在分析阶段这种关系是适用的,但我们觉得它对于描述设计模式内的类关系来说显得太抽象了,因为在设计阶段关联关系必须被映射为对象引用或指针。

对象引用本身就是有向的,更适合表达我们所讨论的那种关系。

所以这种关系在设计的时候比较少用到,关联一般都是有向的。

使用ROSE 生成的代码是这样的:class C1...{public:C2* theC2;};class C2...{public:C1* theC1;};双向关联在代码的表现为双方都拥有对方的一个指针,当然也可以是引用或者是值。

单向关联:C3->C4:表示相识关系,指C3知道C4,C3可以调用C4的公共属性和方法。

没有生命期的依赖。

一般是表示为一种引用。

生成代码如下:class C3...{public:C4* theC4;};class C4...{};单向关联的代码就表现为C3有C4的指针,而C4对C3一无所知。

自身关联(反身关联):自己引用自己,带着一个自己的引用。

代码如下:class C14...{public:C14* theC14;};就是在自己的内部有着一个自身的引用。

2、聚合/组合当类之间有整体-部分关系的时候,我们就可以使用组合或者聚合。

聚合:表示C9聚合C10,但是C10可以离开C9而独立存在(独立存在的意思是在某个应用的问题域中这个类的存在有意义。

这句话怎么解,请看下面组合里的解释)。

代码如下:class C9...{public:C10 theC10;};class C10...{};组合(也有人称为包容):一般是实心菱形加实线箭头表示,如上图所示,表示的是C8被C7包容,而且C8不能离开C7而独立存在。

但这是视问题域而定的,例如在关心汽车的领域里,轮胎是一定要组合在汽车类中的,因为它离开了汽车就没有意义了。

但是在卖轮胎的店铺业务里,就算轮胎离开了汽车,它也是有意义的,这就可以用聚合了。

在《敏捷开发》中还说到,A组合B,则A需要知道B的生存周期,即可能A负责生成或者释放B,或者A通过某种途径知道B 的生成和释放。

他们的代码如下:class C7...{public:C8 theC8;};class C8...{};可以看到,代码和聚合是一样的。

具体如何区别,可能就只能用语义来区分了。

3、依赖依赖:指C5可能要用到C6的一些方法,也可以这样说,要完成C5里的所有功能,一定要有C6的方法协助才行。

C5依赖于C6的定义,一般是在C5类的头文件中包含了C6的头文件。

ROSE 对依赖关系不产生属性。

注意,要避免双向依赖。

一般来说,不应该存在双向依赖。

ROSE生成的代码如下:// C5.h#include "C6.h"class C5...{};// C6.h#include "C5.h"class C6...{};虽然ROSE不生成属性,但在形式上一般是A中的某个方法把B的对象作为参数使用(假设A 依赖于B)。

如下:#include "B.h"class A...{void Func(B &b);}那依赖和聚合\组合、关联等有什么不同呢?关联是类之间的一种关系,例如老师教学生,老公和老婆,水壶装水等就是一种关系。

这种关系是非常明显的,在问题领域中通过分析直接就能得出。

依赖是一种弱关联,只要一个类用到另一个类,但是和另一个类的关系不是太明显的时候(可以说是“uses”了那个类),就可以把这种关系看成是依赖,依赖也可说是一种偶然的关系,而不是必然的关系,就是“我在某个方法中偶然用到了它,但在现实中我和它并没多大关系”。

例如我和锤子,我和锤子本来是没关系的,但在有一次要钉钉子的时候,我用到了它,这就是一种依赖,依赖锤子完成钉钉子这件事情。

组合是一种整体-部分的关系,在问题域中这种关系很明显,直接分析就可以得出的。

例如轮胎是车的一部分,树叶是树的一部分,手脚是身体的一部分这种的关系,非常明显的整体-部分关系。

上述的几种关系(关联、聚合/组合、依赖)在代码中可能以指针、引用、值等的方式在另一个类中出现,不拘于形式,但在逻辑上他们就有以上的区别。

这里还要说明一下,所谓的这些关系只是在某个问题域才有效,离开了这个问题域,可能这些关系就不成立了,例如可能在某个问题域中,我是一个木匠,需要拿着锤子去干活,可能整个问题的描述就是我拿着锤子怎么钉桌子,钉椅子,钉柜子;既然整个问题就是描述这个,我和锤子就不仅是偶然的依赖关系了,我和锤子的关系变得非常的紧密,可能就上升为组合关系(让我突然想起武侠小说的剑不离身,剑亡人亡...)。

这个例子可能有点荒谬,但也是为了说明一个道理,就是关系和类一样,它们都是在一个问题领域中才成立的,离开了这个问题域,他们可能就不复存在了。

4、泛化(继承)泛化关系:如果两个类存在泛化的关系时就使用,例如父和子,动物和老虎,植物和花等。

ROSE生成的代码很简单,如下:#include "C11.h"class C12 : public C11...{};5、这里顺便提一下模板上面的图对应的代码如下:template<int>class C13...{};这里再说一下重复度,其实看完了上面的描述之后,我们应该清楚了各个关系间的关系以及具体对应到代码是怎么样的,所谓的重复度,也只不过是上面的扩展,例如A和B有着“1对多”的重复度,那在A中就有一个列表,保存着B对象的N个引用,就是这样而已。

好了,到这里,已经把上面的类图关系说完了,希望你能有所收获了,我也费了不少工夫啊(画图、生成代码、截图、写到BLOG上,唉,一头大汗)。

不过如果能让你彻底理解UML类图的这些关系,也值得了。

:)++++++++++++++++++++++++++++++++++++++++++++++++++ +++在UML建模中,对类图上出现元素的理解是至关重要的。

开发者必须理解如何将类图上出现的元素转换到Java中。

以java为代表结合网上的一些实例,下面是个人一些基本收集与总结:基本元素符号:1. 类(Classes)类包含3个组成部分。

第一个是Java中定义的类名。

第二个是属性(attributes)。

第三个是该类提供的方法。

属性和操作之前可附加一个可见性修饰符。

加号(+)表示具有公共可见性。

减号(-)表示私有可见性。

#号表示受保护的可见性。

省略这些修饰符表示具有package(包)级别的可见性。

如果属性或操作具有下划线,表明它是静态的。

在操作中,可同时列出它接受的参数,以及返回类型,如下图所示:2. 包(Package)包是一种常规用途的组合机制。

UML中的一个包直接对应于Java中的一个包。

在Java中,一个包可能含有其他包、类或者同时含有这两者。

进行建模时,你通常拥有逻辑性的包,它主要用于对你的模型进行组织。

你还会拥有物理性的包,它直接转换成系统中的Java包。

每个包的名称对这个包进行了惟一性的标识。

3. 接口(Interface)接口是一系列操作的集合,它指定了一个类所提供的服务。

它直接对应于Java中的一个接口类型。

接口既可用下面的那个图标来表示(上面一个圆圈符号,圆圈符号下面是接口名,中间是直线,直线下面是方法名),也可由附加了<<interface>>的一个标准类来表示。

通常,根据接口在类图上的样子,就能知道与其他类的关系。

关系:1. 依赖(Dependency)实体之间一个“使用”关系暗示一个实体的规范发生变化后,可能影响依赖于它的其他实例。

更具体地说,它可转换为对不在实例作用域内的一个类或对象的任何类型的引用。

其中包括一个局部变量,对通过方法调用而获得的一个对象的引用(如下例所示),或者对一个类的静态方法的引用(同时不存在那个类的一个实例)。

也可利用“依赖”来表示包和包之间的关系。

由于包中含有类,所以你可根据那些包中的各个类之间的关系,表示出包和包的关系。

2. 关联(Association)实体之间的一个结构化关系表明对象是相互连接的。

箭头是可选的,它用于指定导航能力。

如果没有箭头,暗示是一种双向的导航能力。

在Java中,关联转换为一个实例作用域的变量,就像图E的“Java”区域所展示的代码那样。

可为一个关联附加其他修饰符。

多重性(Multiplicity)修饰符暗示着实例之间的关系。

在示范代码中,Employee可以有0个或更多的TimeCard对象。

但是,每个TimeCard只从属于单独一个Employee。

3. 聚合(Aggregation)聚合是关联的一种形式,代表两个类之间的整体/局部关系。

聚合暗示着整体在概念上处于比局部更高的一个级别,而关联暗示两个类在概念上位于相同的级别。

聚合也转换成Java中的一个实例作用域变量。

关联和聚合的区别纯粹是概念上的,而且严格反映在语义上。

聚合还暗示着实例图中不存在回路。

换言之,只能是一种单向关系。

4. 合成(Composition)合成是聚合的一种特殊形式,暗示“局部”在“整体”内部的生存期职责。

合成也是非共享的。

所以,虽然局部不一定要随整体的销毁而被销毁,但整体要么负责保持局部的存活状态,要么负责将其销毁。

局部不可与其他整体共享。

但是,整体可将所有权转交给另一个对象,后者随即将承担生存期职责。

Employee和TimeCard的关系或许更适合表示成“合成”,而不是表示成“关联”。

5. 泛化(Generalization)泛化表示一个更泛化的元素和一个更具体的元素之间的关系。

泛化是用于对继承进行建模的UML元素。

在Java中,用extends关键字来直接表示这种关系。

6. 实现(Realization)实例关系指定两个实体之间的一个合同。

换言之,一个实体定义一个合同,而另一个实体保证履行该合同。

对Java应用程序进行建模时,实现关系可直接用implements关键字来表示。

像聚合还分为:非共享聚合、共享聚合、复合聚合等。

以及其它内容,下次再补充。

概要:UML共9个标准图形。

可分为静态视图(StaticViews)和动态视图(DynamicViews)静态视图:1.使用案例图(Use Case Diagram)可以将特定的用例(Use Case)与角色间的关系表现出来。

2.类图(Class Diagram)表现系统中类和逻辑在视图上的关系,但不描述其行为。

3.对象图(Object Diagram)描述在特定时刻系统的静态结构。

4.组件图(Component Diagram)可以看出系统中组件与组件间的组织依赖关系。

相关文档
最新文档