2.概要设计阶段
如果细分为总体设计、概要设计、详细设计，这里的概要设计包括总体设计+概要设计。与需求分析只讨论业务需求分析类似，本文的设计阶段也只考虑针对业务需求的设计，不考虑网络等集成架构方面的设计。
概要设计阶段一般首先确定要用的技术架构（系统技术架构同时包含了系统模块的划分以及模块间的关系)、系统模块部署、对外接口等关键信息，然后会根据需求文档的User Case与Sequence图 将业务流程细化到系统层面，此时应该包括在系统内的模块间怎么流转。技术架构一般用框图就够了，而系统模块部署可以使用Deployment图，对外接口可以使用Component图，细化的业务流程仍然是Sequence图.
2.1 Deployment图
部署图用于静态建模，是表示运行时过程节点结构、构件实例及其对象结构的图。
如果含有依赖关系的构件实例放置在不同节点上，部署视图可以展示出执行过程中的瓶颈。
部署图的两种表现形式：实例层部署图和描述层部署图
实例层部署图描述各节点和它们之间的连接。如果每个节点都是一台主机，那么这种图可以逻辑的表达主机之间的通信关系（此时不考虑物理的网络架构，不考虑中间的防火墙、交换机、路由器）：
描述层部署图表示了系统中的各节点、每个节点包含的构件、对外提供的接口、对外的依赖关系：
图中包括的各种关系如下：
通信链关系(不带箭头的直线):TicketServer票服务器与Kiosk信息厅之间存在一对多的通信关联；与SalesTerminal售票终端也存在一对多的通信关联；依赖关系(带箭头的虚线):TicketSeller售票构件依赖CreditCardCharges信用卡付款构件和TicketDB票数据库构件提供的服务。
图中顾客购票的情景如下(下面的描述是需要拿Sequence图和部署图结合着看的）：
顾客通过位于Kiosk节点的顾客接口控件进行购票的操作，该顾客接口构件的购票操作依赖于处于TicketServer节点上的售票构件提供的服务，售票构件要完成售票操作，又要依赖统一节点上信用卡付款构件提供的付款服务和票数据库构件
2.2 Component图
构件图用于静态建模，是表示构件类型的组织以及各种构件之间依赖关系的图。
构件图通过对构件间依赖关系的描述来估计对系统构件的修改给系统可能带来的影响。
可替换的物理部分包括软件代码、脚本或命令行文件，也可以表示运行时的对象，文档，数据库等(这句话表明component的粒度
可粗可细，运用之妙，在乎一心)。
部署图与构件图的关系：
部署图表现构件实例；
构件图表现构件类型的定义。
部署图偏向于描述构件在节点中运行时的状态，描述了构件运行的环境；
构件图偏向于描述构件之间相互依赖支持的基本关系。
例子:
我们可以看到他们不体现部署图的”部署“特性，因为节点消失了，然而有了更多的接口细节。
那么我们是先有部署图后有构件图，还是先有构件图，后有部署图？本文的思路是top down，所以是从部署图到构件图，实际上也应该如此，因为我们在需求确定后，一般就会确定大体的技术架构、程序模块划分。而此时一般系统集成的工作也要相应的启动：要买主机、网络设备，所以要提供给系统集成人员相应的资料，那么就需要先把部署图做出来，然后再细化构件图。
2.3 Sequence图
描述同UML在项目实施中的使用心得(需求分析阶段),此时会在更细的粒度（比如系统的模块级）画流程图。
2.4 State Machine图(状态图或者状态机图)
有些较为复杂的、需要重点说明的，且有actor参与的流程（在sequence图中可能只是一条线)，可以使用state Machine图再详见阐述。
状态图：说明对象在它的生命期中响应事件所经历的状态序列，以及它们对那些事件的响应。状态图用于揭示Actor、类、子系统和组件的复杂特性。
如下是个网上银行登录系统的例子：
登陆要求提交个人社会保险号(SSN)和密码(PIN)经验证有效后登陆成功。
2.5 Activity图(活动图)
活动图比状态机图好玩的地方在于有”泳道图“，泳道图可以在展现逻辑执行过程的同时展现出每个活动的负责者，所以实际上比状态机图用起来更受客户的欢迎。
活动图可以方便的表述多线程、多进程：
一般的活动图：
带泳道的活动图：
2.6 关于Communication图
Communication图是Sequence图的另外一种表示形式，主要作用是显示某个组件/对象是否有过多的交互，是否应该继续分拆。Rational的RUP可以直接根据Sequence图生成通信图（也叫协作图），所以我把他单做是一个辅助的形式。
UML在项目实施中的使用心得(概要设计阶段),布布扣,bubuko.com
原文：http://blog.csdn.net/davidwang9527/article/details/23325359
