UML类图与组件图间的关系与应用场景解析

UML组件图在软件设计中的作用与应用软件设计是一个复杂而关键的过程，它决定了软件系统的结构和功能。

在软件设计中，UML（统一建模语言）组件图是一种重要的工具，它可以帮助开发人员更好地理解和管理软件系统的组件和关系。

本文将探讨UML组件图在软件设计中的作用与应用。

1. 组件图的概述UML组件图是一种描述软件系统中组件及其关系的图形表示法。

组件是软件系统中的独立模块，可以是一个类、一个函数、一个库等。

组件图通过图形化的方式展示了系统的组件结构、依赖关系和交互方式，帮助开发人员更好地理解和分析系统的整体架构。

2. 作用一：系统架构的可视化UML组件图可以将软件系统的组件和关系可视化，帮助开发人员更清晰地了解系统的整体架构。

通过组件图，开发人员可以快速定位系统中的关键组件，并理解它们之间的依赖关系。

这有助于开发人员更好地进行系统设计和优化，提高系统的可维护性和可扩展性。

3. 作用二：模块化设计的支持UML组件图可以帮助开发人员进行模块化设计，将系统拆分为独立的组件。

每个组件都有明确的功能和接口，可以独立开发和测试。

通过组件图，开发人员可以清晰地了解每个组件的职责和作用，避免功能重叠和耦合度过高的问题。

这有助于提高系统的可维护性和可测试性。

4. 作用三：接口定义和协作的规范UML组件图可以明确定义组件间的接口和协作方式。

每个组件都有一组输入和输出接口，通过接口可以实现组件之间的数据传递和协作。

通过组件图，开发人员可以清晰地了解每个组件的输入输出要求，从而更好地进行组件间的集成和协作。

这有助于提高系统的可扩展性和可重用性。

5. 应用一：系统重构与优化UML组件图可以帮助开发人员进行系统重构和优化。

通过分析组件图，开发人员可以发现系统中的瓶颈和性能问题，并针对性地进行优化。

例如，可以将某个功能复杂的组件拆分为多个简单的组件，以提高系统的响应速度和可维护性。

组件图为系统重构和优化提供了指导和依据。

6. 应用二：系统集成与测试UML组件图可以帮助开发人员进行系统集成和测试。

浅谈UML中常用的几种图1 UML简介2 UML常见图分类3 用况图（用例）4 类图简单类图使用举例5 其他辅助用图●时序图(顺序图)●协作图（Collaboration Diagram/communication Diagram）/通信图●状态图●活动图(Activity Diagram)6 组件图(ComponentDiagram)、配置图(Deployment Diagram)1 UML简介统一建模语言（Unified Modeling Language，UML）又称标准建模语言，是始于1997年的一个OMG标准，它是一个支持模型化和软件系统开发的图形化语言，为软件开发的所有阶段提供模型化和可视化支持，包括由需求分析到规格，到构造和配置。

‘UML感兴趣的可以阅读UML 1规范，包含了UML 的所有知识内容。

注：OMG, Object Management Group 对象管理组织2 UML常见图分类UML从考虑系统的不同角度出发，定义了用况图、类图、对象图、包图、状态图、活动图、序列图、通信图、构件图、部署图等10种图。

分类：面向对象动态建模，用于建立行为的实体间行为交互的四种图：状态图(Stage Diagram)，序列图(Sequence Diagram)，协作图(Communication Diagram)，活动图(Activity Diagram) 。

“序列图”与“协作图”表述的是相似的消息，“活动图”是“状态图”的一种。

•静态结构图Static Structure Diagram•类图Class Diagram•对象图Object Diagram•用况图Use Case Diagram•交互图Interaction Diagram•顺序图Sequence Diagram•协作图Collaboration Diagram•状态图State chart Diagrams•活动图Activity Diagrams•实现图Implementation Diagrams•构件图Component Diagram•部署图Deployment Diagram3 用况图（用例）用例图，展现了一组用例、参与者（actor）以及它们之间的关系。

UML各种图例面向对象的问题的处理的关键是建模问题.建模可以把在复杂世界的许多重要的细节给抽象出.许多建模工具封装了UML（也就是Unified Modeling Language ™），这篇课程的目的是展示出UML的精彩之处.UML中有九种建模的图标，即：∙用例图∙类图∙对象图∙顺序图∙协作图∙状态图∙活动图∙组件图∙配置图本课程中的某些部分包含了这些图的细节信息的页面链接.而且每个部分都有一个小问题，测试一下你对这个部分的理解.为什么UML很重要?为了回答这个问题，我们看看建筑行业.设计师设计出房子.施工人员使用这个设计来建造房子.建筑越复杂，设计师和施工人员之间的交流就越重要.蓝图就成标准文档为了这个行业中的设计师和施工人员的必修课.写软件就好像建造建筑物一样.系统越复杂，参与编写与配置软件的人员之间的交流也就越重要.在过去十年里UML就成为分析师，设计师和程序员之间的“建筑蓝图”.现在它已经成为了软件行业的一部分了.UML提供了分析师，设计师和程序员之间在软件设计时的通用语言.UML被应用到面向对象的问题的解决上.想要学习UML必须熟悉面向对象解决问题的根本原则――都是从模型的建造开始的.一个模型model就是根本问题的抽象.域domain就是问题所处的真实世界.模型是由对象objects组成的，它们之间通过相互发送消息messages来相互作用的.记住把一个对象想象成“活着的”.对象有他们知道的事（属性attributes）和他们可以做的事（行为或操作behaviors or operations）.对象的属性的值决定了它的状态state.类Classes是对象的“蓝图”.一个类在一个单独的实体中封装了属性（数据）和行为（方法或函数）.对象是类的实例instances.用例图用例图Use case diagrams描述了作为一个外部的观察者的视角对系统的印象.强调这个系统是什么而不是这个系统怎么工作.用例图与情节紧紧相关的.情节scenario是指当某个人与系统进行互动时发生的情况.下面是一个医院门诊部的情节.“一个病人打电话给门诊部预约一年一次的身体检查.接待员找出在预约记录本上找出最近的没有预约过的时间，并记上那个时间的预约记录.”用例Use case是为了完成一个工作或者达到一个目的的一系列情节的总和.角色actor是发动与这个工作有关的事件的人或者事情.角色简单的扮演着人或者对象的作用.下面的图是一个门诊部Make Appointment用例.角色是病人.角色与用例的联系是通讯联系communication association（或简称通讯communication）标准文档角色是人状的图标，用例是一个椭圆，通讯是连接角色和用例的线.一个用例图是角色，用例，和它们之间的联系的集合.我们已经把Make Appointment作为一个含有四个角色和四个用例的图的一部分.注意一个单独的用例可以有多个角色.用例图在三个领域很有作用.决定特征（需求）.当系统已经分析好并且设计成型时，新的用例产生新的需求标准文档∙客户通讯.使用用例图很容易表示开发者与客户之间的联系.∙产生测试用例.一个用例的情节可能产生这些情节的一批测试用例.类图类图Class diagram通过显示出系统的类以及这些类之间的关系来表示系统.类图是静态的－它们显示出什么可以产生影响但不会告诉你什么时候产生影响.下面是一个顾客从零售商处预定商品的模型的类图.中心的类是Order.连接它的是购买货物的Customer和Payment.Payment有三种形式：Cash，Check，或者Credit.订单包括OrderDetails（line item），每个这种类都连着Item.标准文档UML类的符号是一个被划分成三块的方框：类名，属性，和操作.抽象类的名字，像Payment是斜体的.类之间的关系是连接线.类图有三种关系.关联association－表示两种类的实例间的关系.如果一个类的实例必须要用另一个类的实例才能完成工作时就要用关联.在图中，关联用两个类之间的连线表示.标准文档标准文档为了简单地表示出复杂的类图，可以把类组合成包packages.一个包是UML上有逻辑关系的元件的集合.下面这个图是是一个把类组合成包的一个商业模型.dependencies关系.如果另一个的包B改变可能会导致一个包A改变，则包A依赖包B.包是用一个在上方带有小标签的矩形表示的.包名写在标签上或者在矩形里面.点化线箭头表示依赖对象图Object diagrams用来表示类的实例.他们在解释复杂关系的细小问题时（特别是递归关系时）很有用.这个类图示一个大学的Department可以包括其他很多的Departments.标准文档这个对象图示上面类图的实例.用了很多具体的例子.UML中实例名带有下划线.只要意思清楚，类或实例名可以在对象图中被省略.标准文档每个类图的矩形对应了一个单独的实例.实例名称中所强调的UML图表.类或实例的名称可能是省略对象图表只要图的意义仍然是明确的.顺序图类图和对象图是静态模型的视图.交互图是动态的.他们描述了对象间的交互作用.顺序图将交互关系表示为一个二维图.纵向是时间轴，时间沿竖线向下延伸.横向轴代表了在协作中各独立对象的类元角色.类元角色用生命线表示.当对象存在时，角色用一条虚线表示，当对象的过程处于激活状态时，生命线是一个双道线.消息用从一个对象的生命线到另一个对象生命线的箭头表示.箭头以时间顺序在图中从上到下排列.标准文档协作图协作图也是互动的图表.他们像序列图一样也传递相同的信息，但他们不关心什么时候消息被传递，只关心对象的角色.在序列图中，对象的角色放在上面而消息则是连接线.标准文档对象角色矩形上标有类或对象名（或者都有）.类名前面有个冒号（：）.协作图的每个消息都有一个序列号.顶层消息的数字是1.同一个等级的消息（也就是同一个调用中的消息）有同样的数字前缀，再根据他们出现的顺序增加一个后缀1，2等等.状态图对象拥有行为和状态.对象的状态是由对象当前的行动和条件决定的.状态图statechart diagram显示出了对象可能的状态以及由状态改变而导致的转移.标准文档我们的模型例图建立了一个银行的在线登录系统.登录过程包括输入合法的密码和个人账号，再提交给系统验证信息.登录系统可以被划分为四种不重叠的状态：Getting SSN, Getting PIN, Validating, 以及 Rejecting.每个状态都有一套完整的转移transitions来决定状态的顺序.标准文档状态是用圆角矩形来表示的.转移则是使用带箭头的连线表示.触发转移的事件或者条件写在箭头的旁边.我们的图上有两个自转移.一个是在Getting SSN，另一个则在上Getting PIN.初始状态（黑色圆圈）是开始动作的虚拟开始.结束状态也是动作的虚拟结束.事件或条件触发动作时用（/动作）表示.当进入Validating状态时，对象并不等外部事件触发转移.取而代之，它产生一个动作.动作的结果决定了下一步的状态.活动图活动图activity diagram是一个很特别的流程图.活动图和状态图之间是有关系的.状态图把焦点集中在过程中的对象身上，而活动图则集中在一个单独过程动作流程.活动图告诉了我们活动之间的依赖关系.对我们的例子来说，我们使用如下的过程.“通过ATM来取钱.”这个活动有三个类Customer, ATM和 Bank.整个过程从黑色圆圈开始到黑白的同心圆结束.活动用圆角矩形表示.标准文档标准文档标准文档。

UML中的组合关系详解UML（Unified Modeling Language）是一种用于软件开发的建模语言，它提供了一套标准的符号和规则，用于描述软件系统的结构、行为和交互。

在UML中，组合关系（Composition）是一种非常重要的关系类型，用于描述类之间的整体与部分的关系。

本文将详细解析UML中的组合关系，包括其定义、特点以及在实际应用中的使用。

一、组合关系的定义组合关系是一种强关联的关系，它表示一个类（整体）由另外一个或多个类（部分）组成。

在组合关系中，整体对象负责管理和控制部分对象的生命周期，部分对象不能独立存在，只能作为整体对象的一部分存在。

组合关系通常用一个实心的菱形箭头表示，箭头指向整体对象。

二、组合关系的特点1. 强关联性：组合关系是一种强关联的关系，整体对象和部分对象之间具有很强的依赖关系。

整体对象的创建、销毁和生命周期管理都会影响到部分对象。

2. 独占性：部分对象只能属于一个整体对象，不能同时属于多个整体对象。

这意味着部分对象的复用性较低，它们的存在完全依赖于整体对象。

3. 寿命一致性：整体对象的生命周期决定了部分对象的生命周期。

当整体对象被销毁时，部分对象也会随之被销毁。

4. 约束性：组合关系还可以定义一些约束条件，限制整体对象和部分对象之间的关系。

例如，可以定义整体对象最多包含多少个部分对象，或者部分对象的类型必须满足某些条件等。

三、组合关系的实际应用组合关系在实际应用中有着广泛的应用场景，下面以一个汽车的例子来说明。

在汽车系统中，汽车是整体对象，而发动机、轮胎、座椅等是部分对象。

汽车由发动机、轮胎、座椅等部分对象组成，整体对象的生命周期决定了部分对象的生命周期。

当汽车被销毁时，发动机、轮胎、座椅等部分对象也会随之被销毁。

另外，组合关系还可以定义一些约束条件。

例如，汽车的座位数量必须大于0且小于等于乘客数量，发动机的类型必须符合汽车的设计要求等。

这些约束条件可以在类图中进行明确的表示，帮助开发人员更好地理解系统的结构和约束。

UML中的泳道图和组件图的区别与实践应用在软件开发过程中，UML（统一建模语言）是一种常用的工具，它可以帮助开发人员更好地理解和设计软件系统。

在UML中，泳道图和组件图是两种常见的图形表示方式，它们具有不同的特点和应用场景。

1. 泳道图泳道图是一种用于展示系统中不同参与者之间交互的图形表示方式。

它通过将系统中的参与者划分为不同的泳道（也称为池）来展示系统中的交互过程。

每个泳道代表一个参与者，可以是一个角色、一个部门或一个系统。

泳道图的主要特点是强调参与者之间的交互和协作。

通过在泳道图中绘制泳道和消息流，开发人员可以清晰地了解系统中各个参与者之间的通信过程。

泳道图还可以展示参与者的职责和角色，帮助开发人员更好地理解系统的结构和功能。

在实践应用中，泳道图常用于描述系统中不同参与者之间的业务流程、系统架构和交互过程。

它可以帮助开发人员在系统设计阶段更好地理解业务需求和系统功能，并与业务人员进行有效的沟通和协作。

同时，泳道图也可以作为系统文档的一部分，帮助开发人员更好地维护和管理系统。

2. 组件图组件图是一种用于展示系统中各个组件之间关系的图形表示方式。

它通过将系统中的组件和它们之间的依赖关系绘制为图形来展示系统的结构和功能。

组件可以是一个模块、一个类、一个库或一个服务等。

组件图的主要特点是强调组件之间的依赖和关系。

通过在组件图中绘制组件和它们之间的连接线，开发人员可以清晰地了解系统中各个组件之间的调用和协作关系。

组件图还可以展示组件的接口和功能，帮助开发人员更好地理解系统的结构和实现。

在实践应用中，组件图常用于描述系统中各个组件之间的关系和依赖。

它可以帮助开发人员在系统设计阶段更好地组织和管理系统的组件，并确保组件之间的协作和通信正常。

同时，组件图也可以作为系统文档的一部分，帮助开发人员更好地理解和维护系统。

3. 区别与实践应用泳道图和组件图在UML中的主要区别在于它们的关注点和应用场景不同。

泳道图主要关注系统中不同参与者之间的交互和协作，适用于描述系统的业务流程和交互过程。

UML用例图与活动图的关联关系与应用场景解析在软件开发过程中，UML（Unified Modeling Language）是一种常用的建模语言，用于描述软件系统的结构和行为。

其中，用例图和活动图是UML中常用的两种图表，它们之间存在着紧密的关联关系，并且在不同的应用场景中有着各自的作用。

一、用例图和活动图的概述用例图是一种用于描述系统功能和用户之间交互的图表。

它通过用例（Use Case）和参与者（Actor）之间的关系来展示系统的功能需求。

用例图主要包括用例、参与者和它们之间的关系。

活动图是一种描述系统行为的图表。

它通过活动（Activity）、控制流（Control Flow）和决策节点（Decision Node）等元素来展示系统的流程和交互。

活动图主要用于描述系统的业务流程、用例场景和算法等。

二、用例图和活动图的关联关系用例图和活动图之间存在着紧密的关联关系。

用例图主要描述系统的功能需求，而活动图则描述了这些功能的实现过程。

在用例图中，一个用例可以对应多个活动图，而一个活动图通常对应一个用例。

具体而言，在用例图中，每个用例表示一个系统功能，而参与者则表示与系统交互的用户或外部系统。

用例图展示了用例和参与者之间的关系，以及用例之间的关系。

而在活动图中，每个活动表示一个具体的操作或业务流程，控制流表示活动之间的顺序和条件，决策节点表示根据不同情况做出的决策。

活动图可以作为用例图的补充，用于更详细地描述用例的执行过程。

通过活动图，可以清晰地展示用例中的各个步骤和流程，帮助开发人员更好地理解和设计系统。

三、用例图和活动图的应用场景用例图和活动图在软件开发中有着广泛的应用场景。

首先，用例图和活动图可以帮助开发人员更好地理解和分析系统需求。

通过用例图，可以明确系统的功能需求，梳理各个用例之间的关系，从而为后续的设计和开发工作提供指导。

而活动图则可以更详细地描述用例的执行过程，帮助开发人员更好地理解和分析系统的业务流程。

UML中数据流图，⽤例图，类图，对象图，⾓⾊图，活动图，序列图详细讲述保存供参考这个⽂章，是我在急需的情况下在园⼦⾥搜索到的，原创作者是：DO-websoftware,为了⾃⼰看⽅便，所以复制到我的空间，希望原创者不要介意哦~~~~很详细的介绍，对我的帮助很⼤，谢谢哦。

类图，对象图，⾓⾊图：⼀、UML中基本的图范畴：在 UML 2 中有⼆种基本的图范畴：结构图和⾏为图。

每个 UML 图都属于这⼆个图范畴。

结构图的⽬的是显⽰建模系统的静态结构。

它们包括类，组件和（或）对象图。

另⼀⽅⾯，⾏为图显⽰系统中的对象的动态⾏为，包括如对象的⽅法，协作和活动之类的内容。

⾏为图的实例是活动图，⽤例图和序列图。

⼆、UML中的类图：1.类图的表⽰：类的 UML 表⽰是⼀个长⽅形，垂直地分为三个区，如图 1 所⽰。

顶部区域显⽰类的名字。

中间的区域列出类的属性。

底部的区域列出类的操作。

在⼀个类图上画⼀个类元素时，你必须要有顶端的区域，下⾯的⼆个区域是可选择的（当图描述仅仅⽤于显⽰分类器间关系的⾼层细节时，下⾯的两个区域是不必要的）。

描述：顶部区域显⽰类的名字。

中间的区域列出类的属性。

底部的区域列出类的操作。

当在⼀个类图上画⼀个类元素时，你必须要有顶端的区域，下⾯的⼆个区域是可选择的（当图描述仅仅⽤于显⽰分类器间关系的⾼层细节时，下⾯的两个区域是不必要的）。

·类名：如果是抽象类，则采⽤斜体·类属性列表：name : attribute type 如 flightNumber : Integer，这是最常见的表达形式name : attribute type = default value 如 balance : Dollars = 0，这是带有默认值的表达形式·类⽅法列表：name(parameter list) : type of value returned注意：在业务类图中，属性类型通常与单位相符，这对于图的可能读者是有意义的（例如，分钟，美元，等等）。

UML组件图中的组件和接口定义与应用范围详细解读UML（统一建模语言）是一种常用的软件工程工具，用于描述和设计软件系统的结构和行为。

其中，UML组件图是一种用于表示系统中各个组件及其之间关系的图形表示方法。

本文将详细解读UML组件图中的组件和接口的定义以及它们的应用范围。

一、组件的定义与应用范围在UML组件图中，组件是指系统中的一个模块或部分，它可以是一个独立的、可替换的实体，也可以是一个更大的系统的一部分。

组件可以是软件组件，如类、模块、库等，也可以是硬件组件，如处理器、传感器等。

组件可以具有自己的内部结构和行为，并且可以与其他组件进行交互。

组件在UML组件图中以一个长方形表示，其中包含组件的名称和可选的属性。

组件之间的关系通过连接线表示，常见的关系有依赖关系、关联关系、组合关系等。

组件的应用范围非常广泛。

在软件开发中，组件可以用于模块化系统，使得系统更易于理解、维护和复用。

组件还可以用于构建分布式系统，其中各个组件可以在不同的计算机上运行，并通过网络进行通信。

此外，组件还可以用于构建嵌入式系统、云计算平台等。

二、接口的定义与应用范围在UML组件图中，接口是组件之间进行通信和交互的约定。

接口定义了组件对外提供的服务或功能，以及组件与其他组件之间的通信方式和协议。

接口可以是一组操作、方法或消息的集合，用于定义组件的行为。

接口在UML组件图中以一个圆形表示，其中包含接口的名称和可选的操作。

接口可以与组件关联，表示组件实现了该接口，也可以与其他接口关联，表示接口之间的依赖关系。

接口的应用范围也非常广泛。

在软件开发中，接口用于实现组件之间的解耦，使得组件可以独立开发和测试。

接口还可以用于实现组件的替换和升级，只需保持接口不变，即可替换底层实现。

此外，接口还可以用于实现系统的插件机制，使得系统可以动态加载和卸载插件。

三、组件和接口的应用案例为了更好地理解组件和接口的应用，以下是一个简单的案例。

假设我们正在开发一个电子商务系统，其中包含商品管理、订单管理和用户管理三个模块。

UML各种图例——用例图、类图、状态图、包图、协作图、顺序图面向对象的问题的处理的关键是建模问题.建模可以把在复杂世界的许多重要的细节给抽象出.许多建模工具封装了UML（也就是Unified Modeling Language™），这篇课程的目的是展示出UML的精彩之处.UML中有九种建模的图标，即：∙用例图∙类图∙对象图∙顺序图∙协作图∙状态图∙活动图∙组件图∙配置图本课程中的某些部分包含了这些图的细节信息的页面链接.而且每个部分都有一个小问题，测试一下你对这个部分的理解.为什么UML很重要?为了回答这个问题，我们看看建筑行业.设计师设计出房子.施工人员使用这个设计来建造房子.建筑越复杂，设计师和施工人员之间的交流就越重要.蓝图就成为了这个行业中的设计师和施工人员的必修课.写软件就好像建造建筑物一样.系统越复杂，参与编写与配置软件的人员之间的交流也就越重要.在过去十年里UML就成为分析师，设计师和程序员之间的“建筑蓝图”.现在它已经成为了软件行业的一部分了.UML提供了分析师，设计师和程序员之间在软件设计时的通用语言.UML被应用到面向对象的问题的解决上.想要学习UML必须熟悉面向对象解决问题的根本原则――都是从模型的建造开始的.一个模型model就是根本问题的抽象.域domain就是问题所处的真实世界.模型是由对象objects组成的，它们之间通过相互发送消息messages来相互作用的.记住把一个对象想象成“活着的”.对象有他们知道的事（属性attributes）和他们可以做的事（行为或操作behaviors or operations）.对象的属性的值决定了它的状态state.类Classes是对象的“蓝图”.一个类在一个单独的实体中封装了属性（数据）和行为（方法或函数）.对象是类的实例instances.用例图用例图Use case diagrams描述了作为一个外部的观察者的视角对系统的印象.强调这个系统是什么而不是这个系统怎么工作.用例图与情节紧紧相关的.情节scenario是指当某个人与系统进行互动时发生的情况.下面是一个医院门诊部的情节.“一个病人打电话给门诊部预约一年一次的身体检查.接待员找出在预约记录本上找出最近的没有预约过的时间，并记上那个时间的预约记录.”用例Use case是为了完成一个工作或者达到一个目的的一系列情节的总和.角色actor是发动与这个工作有关的事件的人或者事情.角色简单的扮演着人或者对象的作用.下面的图是一个门诊部Make Appointment用例.角色是病人.角色与用例的联系是通讯联系communication association（或简称通讯communication）角色是人状的图标，用例是一个椭圆，通讯是连接角色和用例的线.一个用例图是角色，用例，和它们之间的联系的集合.我们已经把Make Appointment作为一个含有四个角色和四个用例的图的一部分.注意一个单独的用例可以有多个角色.用例图在三个领域很有作用.∙决定特征（需求）.当系统已经分析好并且设计成型时，新的用例产生新的需求∙客户通讯.使用用例图很容易表示开发者与客户之间的联系.∙产生测试用例.一个用例的情节可能产生这些情节的一批测试用例.类图类图Class diagram通过显示出系统的类以及这些类之间的关系来表示系统.类图是静态的－它们显示出什么可以产生影响但不会告诉你什么时候产生影响.下面是一个顾客从零售商处预定商品的模型的类图.中心的类是Order.连接它的是购买货物的Customer和Payment.Payment有三种形式：Cash，Check，或者Credit.订单包括OrderDetails（line item），每个这种类都连着Item.每个类图包括类，关联和多样性表示.方向性和角色是为了使图示得更清楚时可选的项目.包和对象图为了简单地表示出复杂的类图，可以把类组合成包packages.一个包是UML上有逻辑关系的元件的集合.下面这个图是是一个把类组合成包的一个商业模型. dependencies关系.如果另一个的包B改变可能会导致一个包A改变，则包A依赖包B.包是用一个在上方带有小标签的矩形表示的.包名写在标签上或者在矩形里面.点化线箭头表示依赖对象图Object diagrams用来表示类的实例.他们在解释复杂关系的细小问题时（特别是递归关系时）很有用.这个类图示一个大学的Department可以包括其他很多的Departments.这个对象图示上面类图的实例.用了很多具体的例子.UML中实例名带有下划线.只要意思清楚，类或实例名可以在对象图中被省略.每个类图的矩形对应了一个单独的实例.实例名称中所强调的UML图表.类或实例的名称可能是省略对象图表只要图的意义仍然是明确的.顺序图类图和对象图是静态模型的视图.交互图是动态的.他们描述了对象间的交互作用.顺序图将交互关系表示为一个二维图.纵向是时间轴，时间沿竖线向下延伸.横向轴代表了在协作中各独立对象的类元角色.类元角色用生命线表示.当对象存在时，角色用一条虚线表示，当对象的过程处于激活状态时，生命线是一个双道线.消息用从一个对象的生命线到另一个对象生命线的箭头表示.箭头以时间顺序在图中从上到下排列.协作图协作图也是互动的图表.他们像序列图一样也传递相同的信息，但他们不关心什么时候消息被传递，只关心对象的角色.在序列图中，对象的角色放在上面而消息则是连接线.对象角色矩形上标有类或对象名（或者都有）.类名前面有个冒号（：）.协作图的每个消息都有一个序列号.顶层消息的数字是1.同一个等级的消息（也就是同一个调用中的消息）有同样的数字前缀，再根据他们出现的顺序增加一个后缀1，2等等.状态图对象拥有行为和状态.对象的状态是由对象当前的行动和条件决定的.状态图statechart diagram显示出了对象可能的状态以及由状态改变而导致的转移.我们的模型例图建立了一个银行的在线登录系统.登录过程包括输入合法的密码和个人账号，再提交给系统验证信息.登录系统可以被划分为四种不重叠的状态：Getting SSN, Getting PIN, Validating, 以及Rejecting.每个状态都有一套完整的转移transitions来决定状态的顺序.状态是用圆角矩形来表示的.转移则是使用带箭头的连线表示.触发转移的事件或者条件写在箭头的旁边.我们的图上有两个自转移.一个是在Getting SSN，另一个则在上Getting PIN.初始状态（黑色圆圈）是开始动作的虚拟开始.结束状态也是动作的虚拟结束.事件或条件触发动作时用（/动作）表示.当进入Validating状态时，对象并不等外部事件触发转移.取而代之，它产生一个动作.动作的结果决定了下一步的状态.活动图活动图activity diagram是一个很特别的流程图.活动图和状态图之间是有关系的.状态图把焦点集中在过程中的对象身上，而活动图则集中在一个单独过程动作流程.活动图告诉了我们活动之间的依赖关系.对我们的例子来说，我们使用如下的过程.“通过ATM来取钱.”这个活动有三个类Customer, ATM和Bank.整个过程从黑色圆圈开始到黑白的同心圆结束.活动用圆角矩形表示.。

UML：图的分类及作⽤（共5类图,有9种图形）第⼀类：⽤例图：从⽤户⾓度描述系统功能,并指出各功能的操作者。

第⼆类：静态图：包括类图、对象图和包图。

1、类图：表⽰类之间的联系如关联、依赖、聚合等，包括类的内部结构（类的属性和操作）。

在系统的整个⽣命周期都是有效的 2、对象图：表⽰类图的⼀个实例，对象图只能在系统某⼀时间段存在。

3、包图：表⽰包与包之间的关系。

包图⽤于描述系统的分层结构。

第三类：⾏为图：状态图、活动图。

描述系统的动态模型和组成对象间的交互关系。

1、状态图：是对类图的补充，描述类的对象所有可能的状态以及事件发⽣时状态的转移条件。

在实⽤上并不需要为所有的类画状态图,仅为那些有多个状态其⾏为受外界环境的影响并且发⽣改变的类画状态图。

2、描述满⾜⽤例要求所要进⾏的活动以及活动间的约束关系,有利于识别并⾏活动。

第四类：交互图：包括顺序图 ,协作图（即合作图） 1、顺序图:强调的是时间和顺序的关系 2、协作图:强调的是上下级关系第五类：实现图：构件图，描述代码部件的物理结构及各部件之间的依赖关系。

从应⽤的⾓度看,当采⽤⾯向对象技术设计系统时,⾸先是描述需求;其次根据需求建⽴系统的静态模型,以构造系统的结构;第三步是描述系统的⾏为。

其中在第⼀步与第⼆步中所建⽴的模型都是静态的,包括⽤例图、类图(包含包)、对象图、组件图和配置图等五个图形,是标准建模语⾔UML的静态建模机制。

其中第三步中所建⽴的模型或者可以执⾏,或者表⽰执⾏时的时序状态或交互关系。

它包括状态图、活动图、顺序图和合作图等四个图形,是标准建模语⾔UML的动态建模机制。

因此,标准建模语⾔UML的主要内容也可以归纳为静态建模机制和动态建模机制两⼤类。

总结：1、静态图：包括⽤例图、类图(包含包)、对象图、组件图和配置图等五个图形，⾸先是描述需求;其次根据需求建⽴系统的静态模型,以构造系统的结构; 2、动态图：包括状态图、活动图、顺序图和合作图等四个图形，是描述系统的⾏为；。