类图表（class diagram）的目的是显示应用程序的结构标示。应用程序结构由类协作（class collaboration）的动态特性来控制。在UML里，我们通常使用流程图（sequence
diagram）来表示类协作的动态特性。现在让我们来探讨一下流程图的元素。行为造型（behavioral modeling）是给组成你系统的类分配职责的过程。虽然对此还有一些争议，但是这是开发生命周期里你需要进行的最重要的活动，因为这一行为将决定你系统的结构。不幸的是，很多开发人员都倾向于直接将需求转变到结构造型，而跳过了行为造型的阶段。这种方法是错误的，因为你没有有意识地去确定类的职责。
虽然你最终能够得到想要的类及其相关联的职责，但是行为造型会将这一确定的过程变成一项明确的活动。其结果是获得一组更加健壮的类及其相关联的行为，如果你没有有意识地进行行为造型，那么这一结果是不会发生的。
你应用程序的弹性最终要以你能够处理类之间依赖性的程度为基础。
这些灵活的依赖性是获得一个灵活系统的关键。但是，当你不知道对象是如何相互交谈的时候，要确定这些依赖性是极其困难的。如果一个对象和另一个对象交谈，那么类就必须有一个结构关系。所以通过行为造型，你不仅仅能够确定类要做什么，还能够看到在被初始化的时候，它会如何同其它的对象进行交互操作。
虽然行为造型强调职责的分配，但是这并不意味着你只能够使用行为图表。事实上，行为和结构造型在同编码活动一起被执行的时候是最有效的。将这些活动进行分离所需要的时间是以小时来计算的，如果不是以分钟的话。
软件静态观察的作用可能还不到整体规范的作用的一半。软件就是关于行为的；因此，动态观察要比静态观察更有价值。不幸的是，很少有开发人员能够意识到这一点，而更少有人能够真正地建立系统动态特性的模型。
