UML组件图详解
浅谈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各种图例面向对象的问题的处理的关键是建模问题.建模可以把在复杂世界的许多重要的细节给抽象出.许多建模工具封装了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－表示两种类的实例间的关系.如果一个类的实例必须要用另一个类的实例才能完成工作时就要用关联.在图中，关联用两个类之间的连线表示.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科普文，一篇文章掌握14种UML图
UML科普⽂，⼀篇⽂章掌握14种UML图前⾔上⼀篇⽂章写了⼀篇建造者模式，其中有⼏个UML类图，有的读者反馈看不懂了，我们今天就来解决⼀哈。
什么是UML？UML是Unified Model Language的缩写，中⽂是统⼀建模语⾔，是由⼀整套图表组成的标准化建模语⾔。
为什么要⽤UML？通过使⽤UML使得在软件开发之前，对整个软件设计有更好的可读性，可理解性，从⽽降低开发风险。
同时，也能⽅便各个开发⼈员之间的交流。
UML提供了极富表达能⼒的建模语⾔，可以让软件开发过程中的不同⼈员分别得到⾃⼰感兴趣的信息。
Page-Jones 在《Fundamental Object-Oriented Design in UML》⼀书中总结了UML的主要⽬的，如下：1. 为⽤户提供现成的、有表现⼒的可视化建模语⾔，以便他们开发和交换有意义的模型。
2. 为核⼼概念提供可扩展性 (Extensibility) 和特殊化 (Specialization) 机制。
3. 独⽴于特定的编程语⾔和开发过程。
4. 为了解建模语⾔提供⼀个正式的基础。
5. ⿎励⾯向对象⼯具市场的发展。
6. ⽀持更⾼层次的开发概念，如协作，框架，模式和组件。
7. 整合最佳的⼯作⽅法 (Best Practices)。
UML图有哪些？UML图分为结构图和⾏为图。
结构图分为类图、轮廓图、组件图、组合结构图、对象图、部署图、包图。
⾏为图⼜分活动图、⽤例图、状态机图和交互图。
交互图⼜分为序列图、时序图、通讯图、交互概览图。
UML图概览什么是类图？【概念】类图是⼀切⾯向对象⽅法的核⼼建模⼯具。
类图描述了系统中对象的类型以及它们之间存在的各种静态关系。
【⽬的】⽤来表⽰类、接⼝以及它们之间的静态结构和关系。
在类图中，常见的有以下⼏种关系。
泛化（Generalization）【泛化关系】是⼀种继承关系，表⽰⼦类继承⽗类的所有特征和⾏为。
【箭头指向】带三⾓箭头的实线，箭头指向⽗类。
跟我学UML建模工具StarUML(第8部分)——应用StarUML创建组件图的创建示例
1.1跟我学UML建模工具StarUML（第8部分）——应用StarUML创建组件图的创建示例1.1.1UML中的组件图1、UML中的组件图（1）UML中的组件组件一般表示实际存在的、物理的物件，它是软件系统的一个物理单元，代表系统的一个物理实现块。
（2）组件图的作用1)描述软件组件以及组件之间的关系2)每个组件图只是系统实现视图的一个图形表示，只有各个组件组合起来，才能表示系统完整的实现视图（3）组件图中的三大组件从MVC的角度来看，在一个组件图中应该包括有边界组件、控制组件和实体组件三大部分。
下面为一个系统中的三大组件的关系图示。
（4）组件图的作用1)能够帮助客户理解最终的系统结构2)使开发实现工作有一个明确的目标3)组件图有利于帮助开发组中的其他人员（如帮助文档人员）理解系统（5）组件在UML中的图示组件图由组件、接口和组件之间的联系构成，其中的组件可以是源程序代码、二进制代码或可执行程序。
组件的图示为一个大矩形左嵌两个小矩形，在框内标注组件名字。
如图：注意：1)在组件图中，组件是通用类型而非实例。
要显示组件实例，请使用部署图。
2)组件一般提供对某一接口的实现，如上右图所示。
2、组件类型（1）各种主要类型的组件1）配置组件配置组件是可执行系统的基础，它是一个可执行系统必须的组件。
如在J2EE系统中的各种*.xml配置文件、文挡等。
2）工作产品组件工作产品组件是在软件开发阶段使用的组件，是配置组件的来源。
如数据文件和数据库表、源程序文件等。
它们并不直接构成可执行系统，而是系统开发过程中的产品。
3）执行组件执行组件是可运行系统产生的运行结果，如DLL、*.exe、Jar包文件等COM+、JavaBeans、DLL、ActiveX等都是执行组件。
（2）在Rose中的几种特殊的组件3、组件的联系----组件之间可以有依赖联系（1）含义1)一个组件的模型元素使用另一个组件的模型元素；2)通过接口实现依赖联系。
组件图和配置图
显示对话框组件（DisplayDialog.java）
BorrowDialog.java
ReturnDialog.java
MainWindow.java
QueryDialog.java
ModifyDialog.java
DisplayDialog.java
管理员用户界面组件图包括：
书目管理对话框组件（TitleDialog.java） 图书管理对话框组件（BookDialog.java）
驻留结点上的组件图
带有依赖关系的配置图
2.关系
在配置图中，使用关联关系（Association）表示结 点之间的通信路径。 配置图中的关联关系与类图中的关联关系采用相同 的表示方法，都是一条实线。
在连接硬件要考虑结点之间的连接方式和通信方式， 因此结点之间的关联关系一般不使用名称标识，而 是使用构造型来描述，如：<<TCP/IP>>、 <<HTTP>>、<<USB>>等。
Keyboard Database Server Mouse
<<LAN>>
Application Server
Web Server
<<Internet>>
ClientPC Monitor
<<USB>>
Printer
关联关系示例
10. 3
配置图建模及应用
1. 配置图的应用 通常可用配置图建模的系统有：
客户机/服务器（C/S）系统 浏览器/服务器（B/S）系统
分布式系统
嵌入式系统
UML构件图常用符号及含义图文详解
UML构件图常用符号及含义图文详解UML组件图(又叫构件图)，是用来描述在软件系统中遵从并实现一组接口的物力的、可替换的软件模块。
它所表现的是一种系统静态实现的结构，能够帮助开发人员对系统组成达成一致的认识。
组件图的构成：1、组件：是用来表示系统中可替换的物理部件，是定义良好接口的物理实现单元。
2、接口：组件的接口分为两种，即导入接口和导出接口。
其中导入接口供访问操作的组件使用，导出接口供提供操作的组件使用。
3、实现：组件与接口元之间的连线，代表谁实现了这个接口。
4、依赖：是表示组件使用了另一个组件的接口，依赖于另一个接口而存在。
组件的类型：1、配置组件：该组件是构成一个可执行系统必要和充分的构件。
例如操作系统、Java虚拟机或者数据库管理系统等。
2、工作产品组件：模是指包括模型、源代码和用于创建配置组件的数据库文件，是配置组件的来源。
比如说UML图、Java类、数据库表以及动态链接库等。
3、执行组件：该组件是运行时创建的组件，是最终可运行的系统产生的允许结果。
比如说Servlet、HTML和XML文档等等。
组件的要素：1、规格说明：一个组件所提供服务的抽象描述。
(每个组件都必须提供特定的服务)2、一个或多个实现：组件是一种物理概念，它必须被一个或多个实现所支持。
3、受约束的构造标准：每一个组件在实现时必须遵从某种构造标准。
4、封装方法：组件遵从的封装方法。
5、部署方法：组件要运行，必须先部署，一个组件可以有多个部署。
组件和类图之间的差别：1、组件表示物理上的模块;2、组件可以是一个或几个类在文件中的存在;3、类是逻辑上的抽象，组件是客观上存在的物理抽象。
其表现为组件是可以部署的，而类是不可以被部署的，因此组件可以存在于节点上而类不能;4、一般组件只有操作，外界只能通过接口接触它们，但是类可以直接有属性和操作。
5、类图侧重于系统的逻辑设计，而组件图侧重于系统的物理设计及实现。
UML组件图中的组件和接口定义与应用范围详细解读
UML组件图中的组件和接口定义与应用范围详细解读UML（统一建模语言）是一种常用的软件工程工具，用于描述和设计软件系统的结构和行为。
其中，UML组件图是一种用于表示系统中各个组件及其之间关系的图形表示方法。
本文将详细解读UML组件图中的组件和接口的定义以及它们的应用范围。
一、组件的定义与应用范围在UML组件图中，组件是指系统中的一个模块或部分，它可以是一个独立的、可替换的实体，也可以是一个更大的系统的一部分。
组件可以是软件组件，如类、模块、库等，也可以是硬件组件，如处理器、传感器等。
组件可以具有自己的内部结构和行为，并且可以与其他组件进行交互。
组件在UML组件图中以一个长方形表示，其中包含组件的名称和可选的属性。
组件之间的关系通过连接线表示，常见的关系有依赖关系、关联关系、组合关系等。
组件的应用范围非常广泛。
在软件开发中，组件可以用于模块化系统，使得系统更易于理解、维护和复用。
组件还可以用于构建分布式系统，其中各个组件可以在不同的计算机上运行，并通过网络进行通信。
此外，组件还可以用于构建嵌入式系统、云计算平台等。
二、接口的定义与应用范围在UML组件图中，接口是组件之间进行通信和交互的约定。
接口定义了组件对外提供的服务或功能，以及组件与其他组件之间的通信方式和协议。
接口可以是一组操作、方法或消息的集合，用于定义组件的行为。
接口在UML组件图中以一个圆形表示，其中包含接口的名称和可选的操作。
接口可以与组件关联，表示组件实现了该接口，也可以与其他接口关联，表示接口之间的依赖关系。
接口的应用范围也非常广泛。
在软件开发中，接口用于实现组件之间的解耦，使得组件可以独立开发和测试。
接口还可以用于实现组件的替换和升级，只需保持接口不变，即可替换底层实现。
此外，接口还可以用于实现系统的插件机制，使得系统可以动态加载和卸载插件。
三、组件和接口的应用案例为了更好地理解组件和接口的应用，以下是一个简单的案例。
假设我们正在开发一个电子商务系统，其中包含商品管理、订单管理和用户管理三个模块。
UML之组件图
UML之组件图基本概念：组件图即是⽤来描述组件与组件之间关系的⼀种UML图。
组件图在宏观层⾯上显⽰了构成系统某⼀个特定⽅⾯的实现结构。
组件图中主要包含三种元素，即组件、接⼝和关系。
组件图通过这些元素描述了系统的各个组件及之间的依赖关系，还有组件的接⼝及调⽤关系。
此外，组件图还可以使⽤包来进⾏组织，使⽤注解与约束来进⾏解释和限定。
组件图在⾯向对象设计过程中起着⾮常重要的作⽤：它明确了系统设计，降低了沟通成本，⽽且按照⾯向对象⽅法进⾏设计的系统和⼦系统通常保证了低耦合度，提⾼了可重⽤性。
组件图的组成元素：组件、接⼝、组件图中的关系、组件的内部结构。
组件 组件，是系统设计的⼀个模块化部分，它隐藏了内部的实现，对外提供了⼀组接⼝。
组件是⼀个封装完好的物理实现单元，它具有⾃⼰的⾝份标⽰和定义明确的接⼝。
并且由于它对接⼝的实现过程与外部元素独⽴，所以组件具有可替换性。
组件在系统中⼀般存在三种类型，分别为部署组件、⼯作产品组件和执⾏组件。
a．配置组件是构成系统所必要的组件，是运⾏系统时需要配置的组件。
b.⼯作产品组件主要是开发过程的产物，是形成配置组件和可执⾏⽂件之前必要的⼯作产品，是部署组件的来源。
⼯作产品组件并不直接参与到可执⾏系统中，⽽是⽤来产⽣系统的中间产品。
c．执⾏组件代表可运⾏的系统最终运⾏产⽣的运⾏结果，并不⼗分常见。
⼀个ATM机的组件：系统设计的⼀个模块化部分显⽰界⾯读卡机业务操作----查询、取款、转账、挂失学校教务系统的组件：系统设计的⼀个模块化部分登录界⾯、业务动作、层业务实现层学⽣管理、教师管理、成绩维护、选课接⼝ 对于⼀个组件⽽⾔，它有两类接⼝，提供接⼝与需求接⼝。
a.提供接⼝：⼜被称为导出接⼝或供给接⼝，是组件为其他组件提供服务的操作的集合。
b.需求接⼝：⼜被称为引⼊接⼝，是组件向其他组件请求相应服务时要遵循的接⼝。
端⼝ 端⼝（port）是⼀个被封装的组件的对外窗⼝。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
UML组件图详解作者：不详来源：blueski推荐2006年6月10日发表评论进入社区图的目的组件图的主要目的是显示系统组件间的结构关系。
在UML 1.1 中，一个组件表现了实施项目，如文件和可运行的程序。
不幸地，这与组件这个术语更为普遍的用法、指象COM组件这样的东西相冲突。
随着时间的推移及UML的连续版本发布，UML 组件已经失去了最初的绝大部分含义。
UML 2 正式改变了组件概念的本质意思；在UML 2 中，组件被认为是独立的，在一个系统或子系统中的封装单位，提供一个或多个接口。
虽然UML 2 规范没有严格地声明它，但是组件是呈现事物的更大的设计单元，这些事物一般将使用可更换的组件来实现。
但是，并不象在UML 1. x中，现在，组件必须有严格的逻辑，设计时构造。
主要思想是，你能容易地在你的设计中重用及/或替换一个不同的组件实现，因为一个组件封装了行为，实现了特定接口。
1在以组件为基础的开发（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 中，一个组件仅仅是类概念的一个特殊版本。
这意味着适用于类分类器的符号规则也适用于组件分类器。
（如果你已经读了并理解了我以前的关于大体上的结构图和类图细节的文章[http:// www./developerworks/cn/rational/rationaledge/content/feb05/bell/index.shtml]，你就会很易理解组件图）。
在UML 2 中，一个组件被画成堆积着可选择小块的一个立着的长方形。
UML 2 中，组件的一个高层次的抽象视图，可以用一个长方形建模，包括组件的名字和组件原型的文字和/或图标。
组件原型的文本是“?component?”，而组件原型图标是在左边有两个凸出的小长方形的一个大长方形（UML 1.4 中组件的符号元素）。
图 2 显示，组件可以用UML 2规范中的三种不同方法表示。
图2：画组件名字区的不同方法当在图上画一个组件时，重要的是，你总要包括组件原型文本（在双重尖括号中的那个component，如图 2 所示）和/或图标。
理由呢？在UML 中，没有任何原型分类器的一个长方形被解释为一个类组件。
组件原型和/或图标用来区别作为组件元素的长方形。
为组件提供/要求接口建模在图 2 中所画的Order组件表现了所有有效的符号元素；然而，一个典型的组件图包括更多的信息。
一个组件元素可以在名字区下面附加额外的区。
如前面所提到的，一个组件是提供一个或更多公共接口的独立单元。
提供的接口代表了组件提供给它的用户/客户的服务的正式契约。
图 3 显示了Order组件有第二个区，用来表示Order组件提供和要求的接口。
2图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与方法论相互独立，这在软件开发中将帮助保持它的普遍可使用。
超越基础组件图是比较容易理解的图之一，因此没有很多超越基础的内容。
然而，有一个方面你可匀衔?锹晕⒗?训摹?/FONT>显示组件的内部结构有时候显示组件的内部结构是有意义的。
在关于类图的我的前面的文章中，我显示了该如何为类的内部结构建模；这里，当它由其他组件组成的时候，我将会关注如何为组件的内部结构建模。
为了显示组件的内部结构，你只需把组件画得比平常大一些并在名字区内放置内部的部分。
图7 显示Store组件的内部结构。
图7: 这个组件的内部结构由其他组件组成。
使用在图7 中显示的例子，Store组件提供了OrderEntry 接口并要求Account接口。
Store组件由三个组件组成：Order，Customer和Product组件。
注意Store的OrderEntry 和Account接口符号在组件的边缘上为何有一个方块。
这一个方块被称为一个端口。
单纯感觉来说，端口提供一种方法，它显示建模组件所提供/要求的接口如何与它里面的部分相关联。
4 通过使用端口，我们可以从外部实例中分离出Store 组件的内部部件。
在图7 中，对于过程而言，OrderEntry 端口代表Order组件的OrderEntry 接口。
同时，内部的Customer组件要求的Account接口被分配到Store组件的必需的Account端口。
通过连接Account 端口，Store组件内部部件（例如Customer组件）可以有代表执行端口接口的未知外部实体的本地特征。
必需的Account接口将会由Store组件的外部组件实现。
5在图7 中，你可能也注意到了，在内部的组件之间的内部连接与图 5 中显示的那些不同。
这是因为内部结构的这些描绘事实是嵌套在分类器（在我们的例子中是一个组件)里的协作图，因为协作图显示分类器中的实体或角色。
在内部的组件之间建模的关系以UML 称为的一个组合连接器表示。
一个组合连接器绑定一个组件提供的接口到另外的一个组件的必需接口。
组合连接器用紧紧相连的棒棒糖和插座符号表示。
以这种方式画这些组合连接器使棒棒糖和插座成为很容易理解的符号。
结论组件图经常是一个架构师在项目的初期就建立的非常重要的图。
然而，组件图的有用性跨越了系统的寿命。
组件图是无价的，因为它们模型化和文档化了一个系统的架构。
因为组件图文档化了系统的架构，开发者和系统可能的系统管理员会发现这一工作的关键产品有助于他们理解系统。
组件图也视为软件系统配置图的输入，这将会是本系列后面的文章主题。
脚注1在UML1.x 中称为组件的实际项目，在UML 2 中称为产物。
一个产物是一个物理单位，象一个文件，可运行的程序，脚本，数据库等等。
只有一种产物依赖于实际的节点；类和组件没有“位置”。
然而，一个产物可能显示组件和其他的分类器（例如类）。
一个单一的组件可能通过多重产物显示，它们可能是在相同的或不同的节点上，因此，一个单一的组件可以间接地在多重节点上被实现。