Robustness Diagram是一种很特殊的图形，介于Class Diagram与Activity Diagram之间，最早由 Ivar Jacobson 于1992年所提出，台湾这边翻成强韧图、稳健图，对岸则采译音翻成鲁棒图。在需求分析领域，UML的Use Case Diagram已经被视为需求捕获的重要工具，藉由Use Case及Use Case叙述文件，可以很清楚的将需求分解展开，但接下来该如何将Use Case的需求描述转化成设计架构呢?以中小型的软体系统来说，通常使用Use Case Diagram+ Class Diagram+ Sequence Diagram就能进行分析设计，而Use Case Diagram是站在使用者的角度来看系统全貌，Class Diagram及Sequence Diagram则分别代表了系统静态结构及动态的交互关系，过去我使用这3个图型进行开发就大致满足所需 了，也许会再依实际情况使用其他UML图形，但随着经验累积及学习，渐渐感觉从分析跨越到设计之间存在着一道槛，领域模型的提炼，我们可以采用四色原型分析法或交易样式，但系统架构的设计，要考虑到更多方方面面，Robustness Analysis Diagram正好可以帮助我们设计出一个基于需求且能继续进行细部设计的初始架构。
如上图，主要的图形就只有3种，Boundary(边界)、Control(控制)及Entity(实体)，这3个图形分别代表了不同的职责。
Boundary : 边界物件，Use Case的主要元素之一就是Actor(参与者)，Boundary的职责就是与Actor互动，它代表着一种外部元素与系统互动的关系。
Control : 控制物件，代表系统的动态行为，描述Use Case中系统应具有的规则与处理逻辑。
Entity : 实体物件，泛指系统会存取的资料，基本上是可以对应到领域物件。
这3个元素之间有着基本的 限制关系 :
Boundary及Entity必须透过Control交谈，Entity与Entity或Boundary与Boundary之间也必须透过Control。而Actor则只能与Bounday进行互动。
接下来用一个简单的例子来说明如何绘制Robustness Diagram，假设今天开发一套汽车检验记录系统，经过需求访谈及分析后，获得如下图的Use Case Diagram。
接下来以验车的Use Case为例，藉由三个元素的特性找出对应的职责，初步绘制出如下的Robustness Diagram
我们进一步思考，验车会去读写客户车籍资料，并且要 写入验车历史记录，因此验车还包含了查询及验证输入的职责，基于OOD的SRP(单一职责原则)，可以再拆分出2个Control物件(如下图)。
继续思考每一个元素所代表的职责之间的关系，初步的将系统拆分为几个部份后，最终获得如下的设计图
初步的架构设计便完成了，顺利的衔接Use Case之后的设计，我们已藉由Robustness Diagram识别出系统在验车这个Use Case的各种职责，这对后续的细部设计非常重要，不论是要绘制Class Diagram、Activity Diagram，或是Sequence Diagram，都比较容易进行，但这不是设计的终点，只是起点而已。
