目的
    描述系统功能在物理节点间是如何分发的。本活动仅适用于分发式系统。
角色:软件设计人员 
频率:每个迭代(特别是在“精化”阶段)发生一次。 
步骤
输入工件:   生成的工件:  
工具向导:  
更多信息: 

工作流程明细:  

本活动按照物理节点及其互连定义了系统的部署体系结构。在活动:体系结构分析过程中,定义了初始的部署模型。在本活动中,对该部署模型(特别是部署视图)进行优化,以反映当前设计。

在“精化”阶段早期,部署视图通常相当简略,但到了“精化”晚期,它应当是良好定义的。

分析分发需求 回到页首

目的 定义系统分发要求达到什么程度。 

分发需求是由以下因素驱动的:

  • 问题领域中的分发需求(功能需求)- 可能存在以下显式需求:系统访问或使用特定的分发式处理器、数据库或旧系统以执行其部分功能。
  • 选择的部署配置 - 特定的部署配置通过定义节点的数目和类型及其互连,将约束施加于系统分发。例如,选择多层部署配置通常表示存在一个客户机节点、一个 Web 服务器节点和一个应用程序服务器节点。通常在活动:体系结构分析过程中选择特定的部署配置,并稍后在本活动中对其进行优化。
  • 所需的资源(非功能需求)- 时间密集功能或计算密集功能可能需要特别装备的特定硬件配置以处理功能需求;例如,快速处理器、大量 RAM 或大量磁盘空间。该需求的一个示例是数字信号处理,它可能需要专门化的、专用的处理器。
  • 容错需求(非功能需求)- 对备份处理器的需求。
  • 可伸缩性和灵活性问题(非功能需求)- 任何单一的处理器都无法支持如此多的并发用户。会存在对系统功能进行负载均衡的需求,从而提供最高的性能和可伸缩性。
  • 经济问题 - 较小、较便宜的处理器的性价比是无法与较大的型号相比的。

对于众多的体系结构问题,这些需求某种程度上可能是互斥的。存在有冲突的需求,至少在初始阶段,并不罕见。根据需求的重要性来排列需求等级将有助于解决冲突。

定义网络配置 回到页首

目的 定义网络配置与拓扑。 

在该步骤中,将对初始部署模型(在活动:体系结构分析中定义)进行优化,以支持在上一步骤中确定的分发需求。

网络拓扑以及网络中处理器和设备的能力和特征将决定系统中可能的分发的性质和程度。

需要捕获以下信息:

  • 网络的物理布局,包括位置
  • 网络中的节点及其配置和能力(配置包括安装在节点上的硬件和软件、处理器的数目、磁盘空间量、内存量、交换量等;其中,安装在节点上的硬件可用设备表示)
  • 网络中每个网段的带宽
  • 网络中任何冗余路径的存在(这将有助于提供容错能力)
  • 节点的主要用途,包括:
    • 最终用户使用的工作站节点
    • 可在其上进行无头处理的服务器节点(为了简化服务器配置,可以将服务器组件压缩为不含用户界面组件的无头映像)
    • 用于开发和测试的特殊配置
    • 其它专门化的处理器
  • 若存在 IP 网络,则包括 IP 设计和设施(例如,DNS、VPN)
  • 因特网在解决方案中扮演的角色

示例

下图阐明了 ATM 的部署视图

ATM 的部署视图

ATM 的部署视图

该图说明了两个节点(在该示例中作为重点的 ATM 本身)和 ATM 网络服务器,其中,所有至银行间网络的连接都是通过 ATM 网络服务器建立的。尽管 ATM 网络服务器处于 ATM 构造器范围之外,但是在此显示该服务器以说明如何记录网络带宽。该图还显示了在 ATM 节点上执行的进程和线程,将在下一步将系统元素分配给节点中对它们进行讨论。

注意使用注释来记录处理器和网络容量。若图中未显示这样的记录,也可能是在节点(或设备)的文档字段显示它。

将系统元素分配到节点 回到页首

目的 分配系统的工作负载。 

在该步骤中,系统元素被分配给在上一步骤中定义的节点。可从逻辑和物理的角度描述部署。

逻辑部署中,逻辑元素(类、子系统或它们的实例)被映射到节点。其中可能包括控制线程。例如,逻辑部署可能声明:将 AuctionManager 子系统部署到应用程序服务器。

物理部署中,文件被映射到节点。例如,物理部署可能声明:将 CloseAuctionTimer.class 文件部署到 server76。

分发区域的总和可以且通常小于各部分的总和。要使分发确实带来好处,需要执行工作并仔细规划。在确定将哪些元素映射到哪些节点时,需要考虑以下因素:

  • 节点容量(根据内存和处理能力)
  • 通信介质带宽(总线、LAN、WAN)
  • 硬件和通信链路的可用性,重新路由
  • 冗余及容错需求
  • 响应时间需求
  • 吞吐量需求
  • 等等

基于使跨网络通信量最小化的目的,将元素分配给节点;应将大量交互的元素分配到相同的节点中;而交互频率较低的元素则可驻留在不同的节点中。至关重要的决策(有时需要迭代)是在何处划定界限。在两个或更多节点上分发进程将要求对系统中进程间通信模式进行周密的检查。通常存在一种天真的观点:处理的分发可从一台机器上卸下工作并转移给另一台机器。实际上,若未仔细考虑进程和节点边界,额外的进程间通信工作负载将轻易地抵消由于工作负载分发而产生的所有好处。

示例

上一示例图 ATM 的部署视图,说明了将进程分配给 ATM 节点。存在单个进程(ATM 主程序),它又由三个独立的控制线程(客户接口、ATM 网络接口和设备控制器)组成。

某些环境提供了自动化和/或简化分发的机制。例如:

  • 群集:群集是一组作为单元的服务器,一般包括诸如故障转移和负载均衡等功能。在此情况下,部署视图应描述是如何将系统元素分配给群集的,以及如何配置群集以将其映射到物理节点。
  • 容器:在组件环境中,例如 J2EE、Microsoft .NET 等,组件将在名为容器的逻辑计算环境中执行。可将容器看作是“逻辑节点”。部署视图应描述是如何将系统元素部署到容器的,接着描述是如何将容器分配给物理节点的。

应将此类支持性分发机制的应用以及需要如何配置它们并映射到物理节点以满足分发需求作为部署视图的一部分加以记录。

Rational Unified Process   2003.06.15