活动:
|
目的
|
|
角色:软件设计人员 | |
频率:每个迭代(特别是在“精化”阶段)发生一次。 | |
步骤 | |
输入工件: | 生成的工件: |
工具向导: | |
更多信息: |
工作流程明细: |
本活动按照物理节点及其互连定义了系统的部署体系结构。在活动:体系结构分析过程中,定义了初始的部署模型。在本活动中,对该部署模型(特别是部署视图)进行优化,以反映当前设计。
在“精化”阶段早期,部署视图通常相当简略,但到了“精化”晚期,它应当是良好定义的。
目的 | 定义系统分发要求达到什么程度。 |
分发需求是由以下因素驱动的:
对于众多的体系结构问题,这些需求某种程度上可能是互斥的。存在有冲突的需求,至少在初始阶段,并不罕见。根据需求的重要性来排列需求等级将有助于解决冲突。
目的 | 定义网络配置与拓扑。 |
在该步骤中,将对初始部署模型(在活动:体系结构分析中定义)进行优化,以支持在上一步骤中确定的分发需求。
网络拓扑以及网络中处理器和设备的能力和特征将决定系统中可能的分发的性质和程度。
需要捕获以下信息:
示例
下图阐明了 ATM 的部署视图
ATM 的部署视图
该图说明了两个节点(在该示例中作为重点的 ATM 本身)和 ATM 网络服务器,其中,所有至银行间网络的连接都是通过 ATM 网络服务器建立的。尽管 ATM 网络服务器处于 ATM 构造器范围之外,但是在此显示该服务器以说明如何记录网络带宽。该图还显示了在 ATM 节点上执行的进程和线程,将在下一步将系统元素分配给节点中对它们进行讨论。
注意使用注释来记录处理器和网络容量。若图中未显示这样的记录,也可能是在节点(或设备)的文档字段显示它。
目的 | 分配系统的工作负载。 |
在该步骤中,系统元素被分配给在上一步骤中定义的节点。可从逻辑和物理的角度描述部署。
逻辑部署中,逻辑元素(类、子系统或它们的实例)被映射到节点。其中可能包括控制线程。例如,逻辑部署可能声明:将 AuctionManager 子系统部署到应用程序服务器。
物理部署中,文件被映射到节点。例如,物理部署可能声明:将 CloseAuctionTimer.class 文件部署到 server76。
分发区域的总和可以且通常小于各部分的总和。要使分发确实带来好处,需要执行工作并仔细规划。在确定将哪些元素映射到哪些节点时,需要考虑以下因素:
基于使跨网络通信量最小化的目的,将元素分配给节点;应将大量交互的元素分配到相同的节点中;而交互频率较低的元素则可驻留在不同的节点中。至关重要的决策(有时需要迭代)是在何处划定界限。在两个或更多节点上分发进程将要求对系统中进程间通信模式进行周密的检查。通常存在一种天真的观点:处理的分发可从一台机器上卸下工作并转移给另一台机器。实际上,若未仔细考虑进程和节点边界,额外的进程间通信工作负载将轻易地抵消由于工作负载分发而产生的所有好处。
示例
上一示例图 ATM 的部署视图,说明了将进程分配给 ATM 节点。存在单个进程(ATM 主程序),它又由三个独立的控制线程(客户接口、ATM 网络接口和设备控制器)组成。
某些环境提供了自动化和/或简化分发的机制。例如:
应将此类支持性分发机制的应用以及需要如何配置它们并映射到物理节点以满足分发需求作为部署视图的一部分加以记录。
Rational Unified Process
|