部署图(deployment diagram,配置图)是用来显示系统中软体和硬体的物理架构。从部署图中,您可以了解到软体和硬体组件之间的物理关係以及处理节点的组件分布情况。使用部署图可以显示运行时系统的结构,同时还传达构成应用程式的硬体和软体元素的配置和部署方式。
基本介绍
- 中文名:部署图
- 外文名:Deployment diagram
- 用途:显示系统中软体和硬体的物理架构
- 含义:部署方式
部署图简介
一个UML部署图(对象管理组织2001)描述了一个运行时的硬体结点,以及在这些结点上运行的软体组件的静态视图。 部署图显示了系统的硬体,安装在硬体上的软体,以及用于连线异构的机器之间的中间件。

创建目的
· 探究系统投产的相关问题.
· 探究你的系统和生产环境中的其它系统的依赖关係,这些系统可能是已经存在,或是将要引入的。
· 描述一个商业套用主要的部署结构。
· 设计一个嵌入系统的硬体和软体结构。
· 描述一个组织的硬体/网路基础结构。
指南
简介
在特定的项目图上注明软体组件;集中在企业级图上的结点和通信关联
结点和组件
用描述性术语命名结点;仅仅建模重要的软体组件;为组件一致地套用一致版型;把可视化的版型套用到结点
依赖和通信关联
用版型来注明通信协定;仅仅建模组件间的关键性依赖
通用準则
在特定的项目图上注明软体组件图1是一个大学管理系统的UML部署图描述. 该图描述了那些包含单一应用程式的主要软体组件是怎样配置到生产环境中的,这使得项目团队能够确定他们的部署策略。2.集中在企业级图上的结点和通信关联

UML部署图经常被认为是一个网路图或技术架构图,图2是该风格的一个例子,它描述了一个简单组织的技术基础结构。 注意图2是一个非常简单的例子,像这样的图,许多组织将会有几十甚至几百个结点。
虽然在图的有限範围内注明组件的部署情况是可以显示它的作用的,例如图1,但图很快地就变得笨重起来。 图2则关注于企业的那些高阶部署,因此配置在硬体结点之上的软体组件的精细的、细节的东西就不需要显示出来,你可以在你的CASE工具中处理这些信息,但这并不意味着你需要在图上显示它们。
结点组件
简介
一个结点,通常描述成一个立体的盒子,表示一个计算设备,一般是一个单独的硬体设备,例如一台电脑,网路路由器,主机,感测器,或个人数字助理(PDA)。 组件,描述为矩形,左侧面还伸出两个较小矩形,这和UML组件图上使用的符号是相同的,它表示软体的中间产物,例如档案、框架、或领域组件。
术语命名结
在图1中,你可以看到结点都有名称,例如client、Application Server、Database Server、和Mainframe。 所有的这些术语都需要即刻为组织内的开发人员所认可,因为这些条款都是他们日常使用的。 保持它的简单性。
软体组件
虽然图1包含软体组件,但它没有描述每一个软体组件。 例如,客户机上很可能还安装有其他的软体组件,如作业系统和套用软体,但那些组件没有显示出来,因为它们已经离题了。 事实是每个结点也许有几十甚至几百的软体组件配置于其上,你的目标并不是描述所有的软体组件,而是只需要描述那些对系统的列节至关重要的组件。如果你需要探究软体组件间的关係,你应该创建一个UML组件图作为替代,遵循敏捷建模( AM) ( Ambler 2002)的套用"合适的Artifact"的实践。
一致版型
在UML部署图上为组件套用和UML组件图中的相同的版型。
把可视化的版型套用到结点
图2使用可视化的版型来描述结点描述结点,例如mobile PC是显示为一个笔记本,而databases则使用传统的资料库的圆筒符号来表示。 为UML部署图上套用可视化版型制定标準是不可能的,一般的经验法则是使用你看得到的适当的剪贴画。
通信关联
简介
通信关联,经常称为连线,被描述为连线结点间的线条。组件间的依赖则被建模成虚线箭头,这和其他UML图上使用的符号是一样的。
用版型来注明通信协定
通信关联支持一个或多个通信协定,每一个都应该使用一个UML版型来描述。 图1中你可以看到HTTP、JDBC、和web services协定,他们就是使用了这个方法。
表1提供了一个典型的通信关联的版型列表,你的组织也许会想开发自己的特定标準。
表1.通用的版型为通信关联
版型 含意。
异步 一个异步连线,也许经由一个讯息汇流排或讯息伫列。
HTTP 超文本传输协定,一个网际协定。
JDBC Java资料库连线,一套为资料库存取编写的Java API。
ODBC开放式资料库连线,一套微软的资料库存取套用编程接口。
RMI 远程方法调用,一个Java的通信协定。
RPC 经由远程过程调用的通信。
同步 一个同步连线,传送器等待从接收器回来的反应。
web services 经由诸如SOAP和UDDI的Web Services协定的通信。
仅仅建模组件间的关键性依赖
图1中配置在??来,因为它们和图并没有什幺关係(而且它们最好是在UML组件图上建模具体的细节)。 然而,在资料库伺服器上的组件间的依赖则被建模出来,因为它有助于展示资料库的访问。领域组件对资料库的方位是间接的,他们需要通过一个持久性框架,这是通用的架构最佳实践( Ambler 2001)。 遵循AM的实践,简单的描述建模。仅仅建模和手头的任务相关的信息。