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）是⼀个被封装的组件的对外窗⼝。
UML中包括九种图
UML中包括九种图：用例图、类图、对象图、状态图、时序图、协作图、活动图、组件图、配置图。
１）用例图（Use Case Diagram）它是UML中最简单也是最复杂的一种图。
说它简单是因为它采用了面向对象的思想，又是基于用户视角的，绘制非常容易，简单的图形表示让人一看就懂。
说它复杂是因为用例图往往不容易控制，要么过于复杂，要么过于简单。
用例图表示了角色和用例以及它们之间的关系。
２）类图（Class Diagram）是最常用的一种图，类图可以帮助我们更直观的了解一个系统的体系结构。
通过关系和类表示的类图，可以图形化的方式描述一个系统的设计部分。
３）对象图（）对象图是类图的实例，几乎使用与类图完全相同的标识。
它们的不同点在于对象图显示类的多个对象实例，而不是实例的类。
一个对象图是类图的一个实例。
由于对象存在生命周期，因此对象图只能在系统某一时间段存在。
４）状态图描述一个实体基于事件反应的动态行为，显示了该实体如何根据当前所处的状态对不同的时间做出反应的。
通常创建一个UML状态图是为了以下的研究目的：研究类、角色、子系统、或组件的复杂行为。
５）时序图又称顺序图，描述了对象之间动态的交互关系，着重体现对象间消息传递的时间顺序。
顺序图由一组对象构成，每个对象分别带有一条竖线，称作对象的生命线，它代表时间轴，时间沿竖线向下延伸。
顺序图描述了这些对象随着时间的推移相互之间交换消息的过程。
消息用从一务垂直的对象生命线指向另一个对象的生命线的水平箭头表示。
图中还可以根据需要增加有关时间的说明和其他注释。
６）协作图协作图用于显示组件及其交互关系的空间组织结构，它并不侧重于交互的顺序。
协作图显示了交互中各个对象之间的组织交互关系以及对象彼此之间的链接。
与序列图不同，协作图显示的是对象之间的关系。
另一方面，协作图没有将时间作为一个单独的维度，因此序列号就决定了消息及并发线程的顺序。
协作图是一个介于符号图和序列图之间的交叉产物，它用带有编号的箭头来描述特定的方案，以显示在整个方案过程中消息的移动情况。
UML九种图作用简介
UML九种图作用简介UML（统一建模语言）：是面向对象的可视化建模语言。
UML中有3种构造块：事物、关系和图，事物是对模型中最具有代表性的成分的抽象，关系是把事物结合在一起，图聚集了相关的事物UML中有九种图如下：1、用例图描述角色以及角色与用例之间的连接关系。
说明的是谁要使用系统，以及他们使用该系统可以做些什么。
2、类图类图是描述系统中的类，以及各个类之间的关系的静态视图。
能够让我们在正确编写代码以前对系统有一个全面的认识。
类图是一种模型类型，确切的说，是一种静态模型类型。
3、对象图与类图极为相似，它是类图的实例，对象图显示类的多个对象实例，而不是实际的类。
它描述的不是类之间的关系，而是对象之间的关系。
4、活动图描述用例要求所要进行的活动，以及活动间的约束关系，有利于识别并行活动。
能够演示出系统中哪些地方存在功能5、状态图描述类的对象所有可能的状态，以及事件发生时状态的转移条件。
可以捕获对象、子系统和系统的生命周期。
他们可以告知一个对象可以拥有的状态，并且事件(如消息的接收、时间的流逝、错误、条件变为真等)会怎么随着时间的推移来影响这些状态。
一个状态图应该连接到所有具有清晰的可标识状态和复杂行为的类；该图可以确定类的行为，以及该行为如何根据当前的状态变化，也可以展示哪些事件将会改变类的对象的状态。
状态图是对类图的补充。
6、序列图（顺序图）序列图是用来显示你的参与者如何以一系列顺序的步骤与系统的对象交互的模型。
顺序图可以用来展示对象之间是如何进行交互的。
顺序图将显示的重点放在消息序列上，即强调消息是如何在对象之间被发送和接收的。
7、协作图和序列图相似，显示对象间的动态合作关系。
可以看成是类图和顺序图的交集，协作图建模对象或者角色，以及它们彼此之间是如何通信的。
如果强调时间和顺序，则使用序列图；如果强调上下级关系，则选择协作图；这两种图合称为交互图。
8、构件图（组件图）描述代码构件的物理结构以及各种构建之间的依赖关系。
UML组件图中组件和接口的定义与区别
UML组件图中组件和接口的定义与区别在软件开发过程中，UML（Unified Modeling Language，统一建模语言）是一种常用的建模工具，它可以帮助开发人员更好地理解和设计软件系统。
其中，UML组件图是一种用于表示软件系统组件和它们之间关系的图表。
在UML组件图中，组件和接口是两个重要的概念，它们在软件系统中扮演着不同的角色和功能。
本文将探讨UML组件图中组件和接口的定义与区别。
1. 组件的定义与特点在UML组件图中，组件是指系统中的一个可替换和独立的模块，它可以封装特定的功能，并且可以与其他组件进行交互。
组件可以是软件模块、库、框架等。
组件具有以下特点：1.1 可替换性：组件可以被其他具有相同接口的组件替换，而不会影响系统的其他部分。
这种可替换性使得系统更加灵活和可维护。
1.2 独立性：组件可以独立开发、测试和部署。
它们可以被独立地修改和更新，而不会对系统的其他组件产生影响。
1.3 封装性：组件封装了特定的功能，并且只对外部提供有限的接口。
这种封装性使得组件更容易被理解和使用。
2. 接口的定义与特点在UML组件图中，接口是组件与外部世界之间的约定，它定义了组件对外部提供的服务和功能。
接口具有以下特点：2.1 规范性：接口定义了组件对外部的规范，它描述了组件的输入和输出，以及它们之间的关系和约束。
2.2 可替换性：接口可以被其他具有相同接口的组件实现。
这种可替换性使得系统更加灵活，可以根据需要替换不同的组件实现。
2.3 一致性：接口提供了一种统一的方式来访问组件的功能。
通过遵循接口定义，不同的组件可以实现相同的功能，从而提高了系统的一致性和可维护性。
3. 组件和接口的区别尽管组件和接口在UML组件图中都扮演着重要的角色，但它们之间存在一些区别。
3.1 定义层次不同：组件是一个独立的模块，它封装了特定的功能；而接口是组件与外部世界之间的约定，它定义了组件对外部提供的服务和功能。
3.2 功能不同：组件提供了一系列的功能，可以被其他组件调用和使用；而接口定义了组件对外部的规范，它描述了组件的输入和输出。
UML组件图的使用与案例分析
UML组件图的使用与案例分析UML（Unified Modeling Language）是一种用于软件开发的标准建模语言，可以帮助开发人员更好地理解和设计软件系统。
其中，UML组件图是一种用于表示系统中的组件及其之间的关系的图形表示方法。
本文将介绍UML组件图的使用方法，并通过一个案例分析来说明其实际应用。
一、UML组件图的基本概念在开始介绍UML组件图之前，我们先来了解一些基本概念。
在UML中，组件是指系统中的一个模块或部分，它可以是一个软件包、一个类、一个库或一个独立的可执行文件。
组件之间的关系可以是依赖、关联、聚合或组合等。
二、UML组件图的符号和结构UML组件图使用一些特定的符号来表示组件和它们之间的关系。
常用的符号包括：组件（用矩形表示）、接口（用圆形表示）、依赖关系（用虚线箭头表示）等。
组件图的结构一般分为两个层次：顶层组件和底层组件。
顶层组件是系统中的主要组件，它们直接与外部系统或用户进行交互；底层组件是顶层组件的子组件，它们负责实现底层功能。
三、UML组件图的使用方法使用UML组件图可以帮助开发人员更好地理解和设计系统。
下面是一些使用UML组件图的方法：1. 确定系统的顶层组件：首先要确定系统中的主要组件，这些组件通常与系统的主要功能模块对应。
例如，一个电子商务系统的主要组件可能包括用户界面、订单处理、支付系统等。
2. 定义组件之间的关系：根据系统的需求和功能，确定组件之间的关系。
例如，用户界面组件可能依赖于订单处理组件和支付系统组件，订单处理组件可能关联于数据库组件等。
3. 设计组件接口：为每个组件定义接口，接口定义了组件对外部系统的可见行为。
接口应该清晰明确，以便其他组件可以正确地使用它。
4. 确定组件的实现方式：根据系统的需求和技术要求，确定每个组件的实现方式。
组件的实现方式可以是一个类、一个库或一个独立的可执行文件。
四、案例分析：电子商务系统的UML组件图为了更好地理解UML组件图的使用，我们以一个电子商务系统为例进行分析。
UML的组件图
UML的组件图UML（Unified Modeling Language）是一种用于软件系统设计和开发的标准建模语言。
其中，组件图是UML中一种用于描述软件系统组件结构的图形化工具。
组件图可以用来描述软件系统中的组件以及组件之间的依赖关系，可以提供系统的高层次视图和结构。
组件图中的组件是指软件系统中的可重用单元。
组件图可以帮助开发人员了解软件系统的组成部分，以及这些组成部分之间的交互和依赖关系。
组件图由以下几部分组成：组件、接口、依赖关系、端口等。
1. 组件组件是指软件系统的一部分，它可以独立地被开发和测试，同时它也可以被重用。
组件通常是可以被修饰的，例如可以添加属性、操作等。
在组件图中，组件通常用矩形表示。
2. 接口接口是指组件与其他组件之间的通信方式。
接口定义了组件提供的服务和被请求的服务。
在组件图中，接口通常用圆形表示。
3. 依赖关系依赖关系是指一个组件依赖于另一个组件。
例如，一个组件需要另一个组件提供一项服务。
在组件图中，依赖关系通常用带箭头的虚线表示。
4. 端口端口是指组件与其它组件连接的点。
端口描述了组件与其他组件之间的通信方式。
在组件图中，端口通常用矩形表示。
组件图的使用组件图可以用来描述软件系统的不同层次结构。
例如，软件系统可以被分为多个层次（业务逻辑层、数据访问层等），每个层次是由若干个组件和依赖组成的。
了解软件系统的组成部分和组件之间的依赖关系对于设计和开发高质量的软件系统是非常重要的。
组件图也可以用来描述软件系统的部署结构。
例如，软件系统可以被部署在不同的服务器上，每个服务器上的组件是由不同的开发团队开发和维护的。
了解软件系统的部署结构对于管理和维护软件系统是非常重要的。
总结组件图是UML中用于描述软件系统组件结构的图形化工具。
它可以用来描述软件系统的组成部分和组件之间的依赖关系。
了解软件系统的组成部分和组件之间的依赖关系对于设计和开发高质量的软件系统是非常重要的。
组件图也可以用来描述软件系统的部署结构。
UML组件图中的组件和接口的定义与应用范围
UML组件图中的组件和接口的定义与应用范围在软件开发中，UML（统一建模语言）是一种常用的图形化建模语言，用于描述软件系统的结构和行为。
其中，UML组件图是一种用于展示软件系统中组件和它们之间关系的图形表示方式。
在UML组件图中，组件和接口是两个重要的概念，它们在软件系统的定义和设计中起着重要的作用。
首先，我们来看一下组件的定义和应用范围。
组件是指软件系统中的一个可独立部署和替换的模块，它具有明确的边界和功能。
组件可以是一个库、一个可执行文件、一个插件或者一个独立的子系统。
组件的设计和实现应该是高内聚、低耦合的，即组件内部的元素之间关联紧密，而与其他组件的关联尽可能松散。
这样可以提高系统的可维护性和可扩展性。
在UML组件图中，组件通常用矩形表示，矩形内部包含组件的名称和一些其他的属性信息。
组件之间的关系可以用连接线表示，连接线上可以标注关系的类型，如依赖、关联、聚合和组合等。
组件图可以帮助开发人员更好地理解和设计软件系统的结构，同时也可以用于与团队成员和其他利益相关者进行沟通和交流。
接下来，我们来看一下接口的定义和应用范围。
接口是指组件或者系统对外部提供的一组服务或者功能。
接口定义了组件或者系统与外部世界之间的通信协议，它定义了可以被调用的操作和可以被访问的属性。
接口可以是一种抽象的描述，也可以是一种具体的实现。
接口的设计应该遵循接口隔离原则，即接口应该精简、高内聚、低耦合，避免冗余和不必要的复杂性。
在UML组件图中，接口通常用带有斜线的小圆圈表示，小圆圈上可以标注接口的名称和一些其他的属性信息。
组件可以实现一个或多个接口，表示组件提供了接口所定义的服务或功能。
组件之间的接口关系可以用连接线表示，连接线上可以标注接口的类型，如实现、依赖、使用和扩展等。
接口图可以帮助开发人员更好地理解和设计软件系统的接口，同时也可以用于与团队成员和其他利益相关者进行沟通和交流。
在实际的软件开发中，UML组件图的应用范围非常广泛。
软件工程UML组件图与部署图
软件工程
1．添加节点 第一项任务是确定系统的节点。下图演示了上面需求列表中提
及的所有硬件。
山东农业大学计算机系 费玉奎
软件工程2. 添加通信关联 为确定的节点添加通信关联。从需求列表中可以确定如下所示
通信关联： • 扫描仪通过内部的PCI总线连接到网卡。 • 网卡通过无线电波与无线hub通信。 • 无线hub通过USB连接到名为KONG的服务器实例。 • KONG Web服务器通过HTTP与客户组件通信。
Browser组件依赖于WebServerSoft组件。 ProduciLookupAddln组件依赖于Browser组件。
山东农业大学计算机系 费玉奎
软件工程 山东农业大学计算机系 费玉奎
组件图和部署图可以用来帮助设计系统的整体架构。
山东农业大学计算机系 费玉奎
软件工程
组件图用来建模软件的组件及其相互之间的关系。这些图由组 件和组件之间的关系构成。
Credit
Flight
Reservation
<<DLL>>
FightServer
山东农业大学计算机系 费玉奎
软件工程
1．组件 组件（构件）是系统中可替换的代码模块。例如下面这些软件
山东农业大学计算机系 费玉奎
软件工程
组件与接口
山东农业大学计算机系 费玉奎
软件工程
2．依赖关系 依赖关系演示两个组件之间的依赖特性。依赖关系使用在一端
带有开放箭头的短划线表示。箭头从依赖的对象指向被依赖的对 象。
山东农业大学计算机系 费玉奎
软件工程 山东农业大学计算机系 费玉奎
软件U工M程L本身提供了一些固有的依赖关系定义。其表示如下图所 示。
UML组件图中的接口与服务定义解析
UML组件图中的接口与服务定义解析UML（统一建模语言）是一种用于软件系统设计和建模的标准化语言。
在UML中，组件图是一种常用的图形表示方法，用于描述软件系统中的各个组件及其之间的关系。
在组件图中，接口和服务定义是非常重要的概念，它们有助于实现组件的重用和模块化开发。
本文将对UML组件图中的接口与服务定义进行解析。
一、接口的定义与作用在UML组件图中，接口是组件之间进行通信的约定。
它定义了组件对外提供的功能和服务，并规定了这些功能和服务的输入和输出。
接口可以看作是一个组件的“门户”，其他组件通过接口与该组件进行交互。
接口的作用主要有以下几个方面：1. 实现组件的重用：通过定义统一的接口，不同的组件可以在不改变内部实现的情况下进行替换和重用。
这样可以提高软件系统的灵活性和可维护性。
2. 实现模块化开发：通过将系统功能划分为多个组件，并定义它们之间的接口，可以实现模块化开发。
每个组件只需关注自己的功能实现，而不需要了解其他组件的具体实现细节。
3. 支持并行开发：通过定义接口，可以将系统的开发任务划分为多个独立的子任务，并由不同的开发团队并行进行开发。
这样可以提高开发效率和加快项目进度。
二、接口的定义方式在UML组件图中，接口的定义方式有两种：提供接口和使用接口。
1. 提供接口：当一个组件提供某个功能或服务时，可以在组件的图标上使用一个“<<provide>>”标签来表示。
该标签后跟接口的名称和方法列表，用于说明该组件提供的接口。
2. 使用接口：当一个组件需要使用其他组件的功能或服务时，可以在组件的图标上使用一个“<<use>>”标签来表示。
该标签后跟接口的名称和方法列表，用于说明该组件使用的接口。
通过使用提供接口和使用接口的方式，可以清晰地描述组件之间的依赖关系和通信方式。
三、服务的定义与作用在UML组件图中，服务是接口中定义的具体功能或操作。
它描述了组件对外提供的具体服务，并规定了服务的输入和输出。
UML组件图中的组件和接口定义与应用范围详解
UML组件图中的组件和接口定义与应用范围详解UML（统一建模语言）是一种用于软件开发过程中的图形化建模语言。
其中，组件图是一种用于表示软件系统中组件和它们之间关系的图形工具。
在组件图中，组件和接口是两个重要的概念，它们的定义和应用范围对于软件系统的设计和开发至关重要。
一、组件的定义与应用范围组件是指软件系统中的一个可独立部署和替换的模块，它具有特定的功能和接口。
组件可以是一个类、一个函数、一个库或者一个独立的模块。
在组件图中，组件用矩形框表示，框内标注组件的名称和类型。
组件的应用范围非常广泛。
首先，组件可以用于描述软件系统的模块化结构，帮助开发人员理解系统的架构和组成部分。
其次，组件可以作为软件系统的重用单元，提高开发效率和质量。
开发人员可以将已经开发和测试过的组件直接应用到新的系统中，而不需要重新编写和测试代码。
此外，组件还可以用于系统的部署和配置管理，帮助系统管理员更好地管理和维护软件系统。
二、接口的定义与应用范围接口是组件之间进行交互的约定，它定义了组件之间的通信方式和规则。
在组件图中，接口用带有圆角矩形框的矩形表示，框内标注接口的名称和类型。
接口的定义包括输入输出参数、操作和事件等。
输入输出参数定义了组件之间传递的数据类型和格式。
操作定义了组件对外提供的服务和方法。
事件定义了组件对外发布的消息和通知。
接口的应用范围非常广泛。
首先，接口可以用于描述组件之间的依赖关系和通信方式，帮助开发人员理解系统的运行机制。
其次，接口可以作为组件之间的约束和协议，确保组件之间的互操作性和兼容性。
开发人员可以根据接口的定义编写代码，实现组件之间的数据传递和方法调用。
此外，接口还可以用于系统的测试和验证，帮助开发人员检查组件之间的交互是否符合预期。
三、组件和接口的关系组件和接口是紧密相关的概念，它们之间存在着一种依赖关系。
在组件图中，组件可以通过接口来访问其他组件的功能和数据。
这种依赖关系可以用箭头表示，箭头指向被依赖的组件。
UML组件图介绍
UML组件图介绍目录1、UML组件图概述 (1)2、在哪里使用组件图？ (1)3、UML组件图目的 (2)4、如何绘制组件图？ (3)1、UML组件图概述UML组件图（Component Diagram）又称为构件图，他描述的是在软件系统中遵从并实现一组接口的物理的、可替换的软件模块。
组件图= 构件（Component）+接口（Interface）+关系（Relationship）+端口（Port）+连接器（Connector）UML组件图给提供了将要建立的系统的高层次的架构视图，这将帮助开发者开始建立实现的路标，并决定关于任务分配及（或）增进需求技能。
2、在哪里使用组件图？UML组件图经常是一个架构师在项目的初期就建立的非常重要的图，它是无价的，因为它们模型化和文档化了一个系统的架构。
UML组件图文档化了系统的架构，开发者和系统可能的系统管理员会发现这一工作的关键产品有助于他们理解系统。
我们已经说过组件图可用于可视化系统的静态实现视图，它是特殊类型的UML图，它描述了在一个系统中的组件组织。
组织机构可以进一步描述为在一个系统中的组件的位置。
这些组件是在一个特殊的组织方式，以满足系统要求。
正如我们已经讨论过这些组件库，文件，可执行文件等，现在组织实施这些组件的应用程序。
组件图的使用可以被描述为：2.1.组件建模的一个系统。
2.2.模型的数据库架构。
2.3.模型的应用程序的可执行文件。
2.4.模型系统的源代码。
3、UML组件图目的组件图是一种特殊的UML图。
与我们之前讨论的UML图标的目的都不同。
组件图不描述该系统的功能，但它描述了用于使这些功能的组件。
所以从这一点来说，组件图用于可视化在一个系统中的物理组件。
这些组件包括库，程序包，文件等。
组件图也被描述为一个静态的实施的系统视图，在一个特定的时刻，静态执行代表组织的组成部分。
一个单一的组件图不能代表整个系统，但图的集合可用来代表整个。
组件图的目的概括如下：3.1.可视化系统的组成部分。
UML 10 种图的总结
UML 2.0共有10种图，分别为表示系统静态结构的静态模型（包括类图、组合结构图、部署图），以及表示系统动态结构的动态模型（包括用例图、序列图、对象图、协作图、状态图、活动图、组件图），它们各用以表现不同的视图，如表1-1所示。
用例之间也可以存在包含、扩展和泛化等关系：
（1）包含关系：用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为做为自身行为的一部分，这被称作包含关系。
（2）扩展关系：扩展关系是从扩展用例到基本用例的关系，它说明为扩展用例定义的行为如何插入到为基本用例定义的行为中。
它是以隐含形式插入的，也就是说，扩展用例并不在基本用例中显示。
在以下几种情况下，可使用扩展用例：
a.表明用例的某一部分是可选的系统行为（这样，您就可以将模型中的可选行为和必选行为分开）；
b.表明只在特定条件（如例外条件）下才执行的分支流；
c.表明可能有一组行为段，其中的一个或多个段可以在基本用例中的扩展点处插入。
所插入的行为段和插入的顺序取决于在执行基本用例时与主角进行的交互。
（3）泛化关系：用例可以被特别列举为一个或多个子用例，这被称做用例泛化。
当父用例能够被使用时，任何子用例也可以被使用。
如在图2.4中，订票是电话订票和网上订票的抽象。
- 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 中称为产物。
一个产物是一个物理单位，象一个文件，可运行的程序，脚本，数据库等等。
只有一种产物依赖于实际的节点；类和组件没有“位置”。
然而，一个产物可能显示组件和其他的分类器（例如类）。
一个单一的组件可能通过多重产物显示，它们可能是在相同的或不同的节点上，因此，一个单一的组件可以间接地在多重节点上被实现。