??一个UML部署图（对象管理组织2001）描述了一个运行时的硬件结点，以及在这些结点上运行的软件组件的静态视图。 部署图显示了系统的硬件，安装在硬件上的软件，以及用于连接异构的机器之间的中间件。 创建一个部署模型的目的包括∶

1. 探究系统投产的相关问题．
2. 探究你的系统和生产环境中的其它系统的依赖关系，这些系统可能是已经存在，或是将要引入的。
3. 描述一个商业应用主要的部署结构。
4. 设计一个嵌入系统的硬件和软件结构。
5. 描述一个组织的硬件/网络基础结构。

指南∶

通用准则

在特定的项目图上注明软件组件

集中在企业级图上的结点和通信关联

结点和组件

用描述性术语命名结点

仅仅建模重要的软件组件

为组件一致地应用一致版型

把可视化的版型应用到结点

依赖和通信关联

用版型来注明通信协议

仅仅建模组件间的关键性依赖

一、通用准则

1.在特定的项目图上注明软件组件

??图1是一个大学管理系统的UML部署图描述． 该图描述了那些包含单一应用程序的主要软件组件是怎样配置到生产环境中的，这使得项目团队能够确定他们的部署策略。

图1.一个特定项目的UML部署图。

2.集中在企业级图上的结点和通信关联

??UML部署图经常被认为是一个网络图或技术架构图，图２是该风格的一个例子，它描述了一个简单组织的技术基础结构。 注意图２是一个非常简单的例子，像这样的图，许多组织将会有几十甚至几百个结点。

??虽然在图的有限范围内注明组件的部署情况是可以顶用的，例如图1，但图很快地就变得笨重起来。 图2则关注于企业的那些高阶部署，因此配置在硬件结点之上的软件组件的精细的、细节的东西就不需要显示出来，你可以在你的CASE工具中处理这些信息，但这并不意味着你需要在图上显示它们。

图2.一个组织的UML部署图。

二、结点和组件

??一个结点，通常描述成一个立体的盒子，表示一个计算设备，一般是一个单独的硬件设备，例如一台电脑，网络路由器，主机，传感器，或个人数字助理(PDA)。 组件，描述为矩形，左侧面还伸出两个较小矩形，这和UML组件图上使用的符号是相同的，它表示软件的中间产物，例如文件、框架、或领域组件。

1.用描述性术语命名结点

??在图１中，你可以看到结点都有名称，例如client、Application Server、Database Server、和Mainframe。 所有的这些术语都需要即刻为组织内的开发人员所认可，因为这些条款都是他们日常使用的。 保持它的简单性。

2.仅仅建模重要的软件组件

??虽然图１包含软件组件，但它没有描述每一个软件组件。 例如，客户机上很可能还安装有其他的软件组件，如操作系统和应用软件，但那些组件没有显示出来，因为它们已经离题了。 事实是每个结点也许有几十甚至几百的软件组件配置于其上，你的目标并不是描述所有的软件组件，而是只需要描述那些对系统的列节至关重要的组件。如果你需要探究软件组件间的关系，你应该创建一个UML组件图作为替代，遵循敏捷建模( AM) ( Ambler 2002)的应用"合适的Artifact"的实践。

3.为组件一致地应用一致版型

??在UML部署图上为组件应用和UML组件图中的相同的版型。

4.把可视化的版型应用到结点

??图２使用可视化的版型来描述结点描述结点，例如mobile PC是显示为一个笔记本，而databases则使用传统的数据库的圆筒符号来表示。 为UML部署图上应用可视化版型制定标准是不可能的，一般的经验法则是使用你看得到的适当的剪贴画。

三、依赖和通信关联

??通信关联，经常称为连接，被描述为连接结点间的线条。组件间的依赖则被建模成虚线箭头，这和其他UML图上使用的符号是一样的。

1.用版型来注明通信协议

??通信关联支持一个或多个通信协议，每一个都应该使用一个UML版型来描述。 图１中你可以看到HTTP、JDBC、和web services协议，他们就是使用了这个方法。表1提供了一个典型的通信关联的版型列表，你的组织也许会想开发自己的特定标准。

表1.通用的版型为通信关联

版型????????含意

异步????????一个异步连接，也许经由一个消息总线或消息队列。

HTTP????????超文本传输协议，一个网际协议。

JDBC????????Java数据库连接，一套为数据库存取编写的Java API。

ODBC????????开放式数据库连接，一套微软的数据库存取应用编程接口。

RMI???????? 远程方法调用，一个Java的通信协议。

RPC???????? 经由远程过程调用的通信。

同步????????一个同步连接，发送器等待从接收器回来的反应。

web services????经由诸如SOAP和UDDI的Web Services协议的通信。

2.仅仅建模组件间的关键性依赖

??图１中配置在应用服务器上的领域组件间的依赖并没有被建模出来，因为它们和图并没有什么关系（而且它们最好是在UML组件图上建模具体的细节）。 然而，在数据库服务器上的组件间的依赖则被建模出来，因为它有助于展示数据库的访问。领域组件对数据库的方位是间接的，他们需要通过一个持久性框架，这是通用的架构最佳实践( Ambler 2001)。 遵循AM的实践，简单的描述建模。仅仅建模和手头的任务相关的信息。