uml组件图例子，UML用例图类图

本文目录一览

1，UML用例图类图
2，面向对象中包括哪些UML图及每件图的作用
3，组件图的作用

1，UML用例图类图

首先需要先了解一下对象之间的关系，以及它们对应的符号通常对象之间的关系可以分为以下几类： 1、泛化/继承（Generalization）：实线+三角形空心相当于类继承，父参与者可以是抽象的，即不能创建一个父参与者的直接实例，这就要求属于抽象父参与者的外部对象一定能够属于其子参与者之一。 2、关联关系（association）：实线箭头关联关系：指的是类与类之间的联接，它使一个类知道另一个类的属性和方法（实例变量体现）。A类依赖于B对象,并且把B作为A的一个成员变量, 则A和B存在关联关系. 关联可以是双向的，也可以是单向的。两个类之前是一个层次的，不存在部分跟整体之间的关系。单向：只能从A通过属性导航到B，B不能导航到A。双向：A可以通过属性导航到B，B也可以通过属性导航到（双向即为嵌套） 3、聚合关系（aggregtion）棱形空心+实线聚合(aggregation)关系是关联关系的一种,是强关联关系,是整合和部分的关系,是has-a的关系. 聚合关系也是通过成员对象来实现,其中成员对象是整体对象的一部分,但是成员对象可以脱离整体对象单独存在.(可替换) 4、依赖(Dependency) 虚线+箭头依赖关系：指的是类与类之间的联接。依赖关系表示一个类依赖于另一个类的定义。动物依赖氧气和水。调用新陈代谢方法需要氧气类与水类的实例作为参数 5、实现关系（realization）虚线三角形空心实现关系：指的是一个class类实现 interface接口（可以实现多个接口）的功能；实现是类与接口之间最常见的关系；在Java中此关系通过关键字implements明确标识。 6，组合关系（composition）组合是一种强的拥有关系，是一种contains-a的关系，体现了严格的部分和整体关系，部分和整体的生命周期一样。示例：鸟和翅膀就是组合关系，因为它们是部分和整体的关系，并且翅膀和鸟的生命周期是相同的。一张完整的类图：参考： UML用例图， UML类图， UML中的类图及常见类图关系

UML用例图类图

2，面向对象中包括哪些UML图及每件图的作用

UML面向对象分析及其包括的图、建模步骤一、叙述基于UML的面向对象分析设计过程1）识别系统的用例和角色首先对项目进行需求调研，依据项目的业务流程图和数据流程图以及项目中涉及的各级操作人员，通过分析，识别出系统中的所有用例和角色；接着分析系统中各角色和用例间的联系，再使用UML建模工具画出系统的用例图，同时，勾画系统的概念层模型，借助UML建模工具描述概念层类图和活动图。2）进行系统分析，并抽象出类系统分析的任务是找出系统中所有需求并加以描述，同时建立特定领域模型。建立域模型有助于开发人员考察用例，从中抽取出类，并描述类之间的关系。3）设计系统和系统中的类及其行为设计阶段由结构设计和详细设计组成。①结构设计是高层设计，其任务是定义包（子系统），包括包间的依赖关系和主要通信机制。包有利于描述系统的逻辑组成部分以及各部分之间的依赖关系。②详细设计就是要细化包的内容，清晰描述所有的类，同时使用UML的动态模型描述在特定环境下这些类的实例的行为。二、面向对象中包括哪些UML图及每件图的作用UML图包括九种：用例图、类图、对象图、状态图、时序图、协作图、活动图、组件图、配置图。1）用例图（UseCaseDiagram）它是UML中最简单也是最复杂的一种UML图。说它简单是因为它采用了面向对象的思想，又是基于用户视角的，绘制非常容易，简单的图形表示让人一看就懂。说它复杂是因为用例图往往不容易控制，要么过于复杂，要么过于简单。用例图表示了角色和用例以及它们之间的关系。2）类图（ClassDiagram）是最常用的一种图，类图可以帮助我们更直观的了解一个系统的体系结构。通过关系和类表示的类图，可以图形化的方式描述一个系统的设计部分。3）对象图UML面向对象中对象图是类图的实例，几乎使用与类图完全相同的标识。它们的不同点在于对象图显示类的多个对象实例，而不是实例的类。一个对象图是类图的一个实例。由于对象存在生命周期，因此对象图只能在系统某一时间段存在。4）状态图UML图中状态图用来描述一个实体基于事件反应的动态行为，显示了该实体如何根据当前所处的状态对不同的时间做出反应的。通常创建一个UML状态图是为了以下的研究目的：研究类、角色、子系统、或组件的复杂行为。5）时序图又称顺序图，描述了对象之间动态的交互关系，着重体现对象间消息传递的时间顺序。顺序图由一组对象构成，每个对象分别带有一条竖线，称作对象的生命线，它代表时间轴，时间沿竖线向下延伸。顺序图描述了这些对象随着时间的推移相互之间交换消息的过程。消息用从一务垂直的对象生命线指向另一个对象的生命线的水平箭头表示。图中还可以根据需要增加有关时间的说明和其他注释。6）协作图UML面向对象中协作图用于显示组件及其交互关系的空间组织结构，它并不侧重于交互的顺序。协作图显示了交互中各个对象之间的组织交互关系以及对象彼此之间的链接。与序列图不同，协作图显示的是对象之间的关系。另一方面，协作图没有将时间作为一个单独的维度，因此序列号就决定了消息及并发线程的顺序。协作图是一个介于符号图和序列图之间的交叉产物，它用带有编号的箭头来描述特定的方案，以显示在整个方案过程中消息的移动情况。UML图中协作图用途：通过描绘对象之间消息的移动情况来反映具体的方案。显示对象及其交互关系的空间组织结构，而非交互的顺序。7）活动图（ActivityDiagram）UML面向对象中UML活动图记录了单个操作或方法的逻辑，单个用户案例，或者单个业务流程的逻辑。描述系统中各种活动的执行顺序，通常用于描述一个操作中所要进行的各项活动的执行流程。同时，它也常被用来描述一个用例的处理流程，或者某种交互流程。活动图由一些活动组成，图中同时包括了对这些活动的说明。当一个活动执行完毕之后，控制将沿着控制转移箭头转向下一个活动。活动图中还可以方便地描述控制转移的条件以及并行执行等要求。8）组件图（ComponentDiagram）UML图的组件图是用来反映代码的物理结构。从组件图中，可以了解各软件组件（如源代码文件或动态链接库）之间的编译器和运行时依赖关系。使用组件图可以将系统划分为内聚组件并显示代码自身的结构。组件图的主要目的是显示系统组件间的结构关系。9）配置图UML面向对象中配置图描述系统中硬件和软件的物理配置情况和系统体系结构。在UML图的配置图中，用结点表示实际的物理设备，如计算机和各种外部设备等，并根据它们之间的连接关系，将相应的结点连接起来，并说明其连接方式。在结点里面，说明分配给该结点上运行的可执行构件或对象，从而说明哪些软件单元被分配在哪些结点上运行。

面向对象中包括哪些UML图及每件图的作用

3，组件图的作用

组件图的主要目的是显示系统组件间的结构关系。在 UML 1.1 中，一个组件表现了实施项目，如文件和可运行的程序。不幸地，这与组件这个术语更为普遍的用法、指象COM组件这样的东西相冲突。随着时间的推移及UML的连续版本发布， UML 组件已经失去了最初的绝大部分含义。UML 2 正式改变了组件概念的本质意思；在 UML 2 中，组件被认为是独立的，在一个系统或子系统中的封装单位，提供一个或多个接口。虽然 UML 2 规范没有严格地声明它，但是组件是呈现事物的更大的设计单元，这些事物一般将使用可更换的组件来实现。但是，并不象在 UML 1. x中，组件必须有严格的逻辑，设计时构造。主要思想是，你能容易地在你的设计中重用及/或替换一个不同的组件实现，因为一个组件封装了行为，实现了特定接口。在以组件为基础的开发（CBD）中，组件图为架构师提供一个开始为解决方案建模的自然形式。组件图允许一个架构师验证系统的必需功能是由组件实现的，这样确保了最终系统将会被接受。除此之外，组件图对于不同的小组是有用的交流工具。图可以呈现给关键项目发起人及实现人员。通常，当组件图将系统的实现人员连接起来的时候，组件图通常可以使项目发起人感到轻松，因为图展示了对将要被建立的整个系统的早期理解。开发者发现组件图是有用的，因为组件图给他们提供了将要建立的系统的高层次的架构视图，这将帮助开发者开始建立实现的路标，并决定关于任务分配及（或）增进需求技能。系统管理员发现组件图是有用的，因为他们可以获得将运行于他们系统上的逻辑软件组件的早期视图。虽然系统管理员将无法从图上确定物理设备或物理的可执行程序，但是，他们仍然欢迎组件图，因为它较早地提供了关于组件及其关系的信息（这允许系统管理员轻松地计划后面的工作）。组件图符号集使它成为最容易画的 UML 图之一。图 1 显示了一个使用前 UML 1.4 符号的简单的组件图；这个例子显示两个组件之间的关系：一个使用了Inventory System组件的Order System组件。正如你所能见到的，在UML 1.4 中，用一个大方块，并且在它的左边有两个凸出的小方块，来表示组件。图 1：这个简单的组件图使用 UML 1.4 符号显示Order System的一般性依赖关系上述的 UML 1.4 符号在 UML 2 中仍然被支持。然而，UML 1.4 符号集在较大的系统中不能很好地调节。关于这一点的理由是，如同我们在这篇文章的其余部分将会见到一样，UML 2 显著地增强了组件图的符号集。在维持它易于理解的条件下，UML 2 符号能够调节得更好，并且符号集也具有更多的信息。让我们依照 UML 2 规范一步步建立组件图。在 UML 2 中画一个组件很类似于在一个类图上画一个类。事实上，在 UML 2 中，一个组件仅仅是类概念的一个特殊版本。这意味着适用于类分类器的符号规则也适用于组件分类器。你就会很易理解组件图）。在 UML 2 中，一个组件被画成堆积着可选择小块的一个立着的长方形。UML 2 中，组件的一个高层次的抽象视图，可以用一个长方形建模，包括组件的名字和组件原型的文字和/或图标。组件原型的文本是“<<component>>”，而组件原型图标是在左边有两个凸出的小长方形的一个大长方形（UML 1.4 中组件的符号元素）。图 2 显示，组件可以用UML 2规范中的三种不同方法表示。图 2：画组件名字区的不同方法当在图上画一个组件时，重要的是，你总要包括组件原型文本（在双重尖括号中的那个component，如图 2 所示）和/或图标。理由呢？在 UML 中，没有任何原型分类器的一个长方形被解释为一个类组件。组件原型和/或图标用来区别作为组件元素的长方形。在图 2 中所画的Order组件表现了所有有效的符号元素；然而，一个典型的组件图包括更多的信息。一个组件元素可以在名字区下面附加额外的区。如前面所提到的，一个组件是提供一个或更多公共接口的独立单元。提供的接口代表了组件提供给它的用户/客户的服务的正式契约。图 3 显示了Order组件有第二个区，用来表示Order组件提供和要求的接口。图 3：这里额外的区显示Order组件提供和要求的接口。在图 3 中的Order组件例子中，组件提供了名为 OrderEntry 和 AccountPayable 的接口。此外，组件也要求另外一个组件提供Person接口。3 UML 2 也引入另外一种方法来显示组件提供并要求的接口。这个方法是建立一个里面有组件名的大长方形，并在长方形的外面放置在 UML 2 规范中称为接口符号的东西。这第二种方法在图 4 中举例说明。图 4: 一种可选择的方法（与图3相比）：使用接口符号显示组件提供/要求的接口在这第二种方法中，在末端有一个完整的圆周的接口符号代表组件提供的接口 -- “棒棒糖”是这个接口分类器实现关系符号的速记法。在末端只有半个圆的接口（又称插座）符号代表组件要求的接口（在两种情况下，接口的名字被放置在接口符号本身的附近）。即使图 4 看起来与图 3 有很大的不同，但两个图都提供了相同的信息 -- 例如，Order组件提供两个接口：OrderEntry 和 AccountPayable，而且Order组件要求 Person接口。当表现组件与其他的组件的关系时，棒棒糖和插座符号也必须包括一支依存箭头（如类图中所用的）。在有棒棒糖和插座的组件图上，注意，依存箭从强烈的（要求的）插座引出，并且它的箭头指向供应者的棒棒糖，如图 5 所示。图 5：显示Order系统组件如何依赖于其他组件的组件图图 5 显示，Order系统组件依赖于客户资源库和库存系统组件。注意在图 5 中复制出的接口名 CustomerLookup 和 ProductAccessor。在这个例子中，这看起来可能是不必要的重复，不过符号确实允许在每个依赖于实现差别的组件中有不同的接口（和不同的名字）（举例来说，一个组件提供一个较小的必需的接口子类）。在 UML 2 中，子系统分类器是组件分类器的一个特别版本。因为这一点，子系统符号元素象组件符号元素一样继承所有的组件符号集规则。唯一的差别是，一个子系统符号元素由subsystem关键字代替了component，如图 6 所示。图 6：子系统元素的一个例子UML 2 规范在如何区别子系统与组件方面相当含糊。从建模的观点，规范并不认为组件与子系统有任何区别。与 UML 1. x 相比较，这个 UML 2 模型歧义是新的。但是有一个理由。在 UML 1. x 中，一个子系统被认为是一个软件包，而且这个软件包符号正对许多 UML 实践者造成困惑；因此，UML 2中把子系统作为特殊的组件，因为这是最多的 UML 1. x 使用者了解它的方式。这一改变确实把模糊引入图中，但是这一模糊更多的是 UML 2 规范中对抗错误的一个现实反射。到这里，你可能正在抓着头皮并感到疑惑，什么时候该用组件元素，什么时候又该用子系统元素。相当坦率地说，我没有一个直接的答案给你。我可以告诉你，UML 2 规范中说，何时该使用组件或子系统决定于建模者的方法论。我个人很喜欢这个答案，因为它帮助确保UML与方法论相互独立，这在软件开发中将帮助保持它的普遍可使用。

组件图的作用