本文和大家重点讨论一下UML各种图形的表达焦点和语言特点，用例图的目的并不是表达流程，而是系统对外服务的门，而状态图的焦点在一个对象上，每种图形都有各自的特点。下面请看本文的详细介绍吧。
分辨UML各种图形的表达焦点和语言特点
用例图：
正像嘉文所说，用例图的目的并不是表达流程，而是系统对外服务的门。是系统存在的真正价值所在。所以，它的焦点是用户和它的意图（价值目标）。但是，为什么在用例场景中有时要表达那些系统内部的并不外现的内容呢？说到底，那是表达了用户在实现这个目标的过程中涉及到了其它相关利益者。虽然它们不在场，但是它们的互交契约仍在起作用。所以，用例图进一步表达了人物之间的契约关系，可以视为是静态关系，而不是流程（不含真正的时间序列）。
状态图：
焦点在一个对象上，一个对象响应多个动词（消息），可以表达实时性。
协作图：
UML各种图形中协作图的焦点在一个动词（脚本），多个对象围绕一个动词，即可表达静态协作关系，也可以更进一步表达各个角色的协作顺序关系。
顺序图：
多个对象之间的交互关系。多个对象，多个动词。提供最完整的对象模型：刺激响应等待模型，无头无尾，是一个全局表达模式。
刺激响应模型是在表达顺序呢还是在表达间断呢？我看更在表达等待中的间断状态。
所以说是个等待响应的模型。正是在这里，它与流程方法关注的不同，它不是自动执行到底的，或者说凡是可以自动执行到底的活动脚本并不是我们表达的重点，那是DFD流程图的重点。我们可以反过来问，为什么不继续执行活动了呢？因为我们在等待信号。这也是个对象适应环境刺激的模型。
DFD数据流图：
表达了一个动词的内在含义，即定义了传递函数：将输入转换为输出的算法。
活动图：
以一个完整业务中多个动词之间的起始终止关系为焦点，是真正意义上的业务流程图。因为它可以表达活动的转移条件，并行活动。特别重视一个活动的起始与终止。与DFD数据流程图相比，它关注的是单个活动外部之间的逻辑关系，而不是这个活动的内部含义。所以它适合作为工作流的描述模型。特别是活动图同时也画出活动的发起者，即所谓的泳道图，这正是工作流的元语言模型所要求的。
健壮图：
UML各种图形中健壮图在反映业务需求的用例图和系统实现的顺序图之间。也就是把每个用例落实为所谓三层结构：边界对象，控制对象和实体对象（数据库）。
这就是嘉文所说的软件对象。软件对象与业务对象是两个不同的概念，软件对象中有许多不符合自然语言的东西。比如，一个表单是个对象，它常把对它的操作动作定义为它的行为方法，比如所谓的CUDI等，这是颠倒了主语与宾语，混淆了主动与被动，特别让业务人员别扭，是要去对象化的重要原因。真正的业务需求分析语言，应该去掉这些中间对象，留下外部对象，如人物，还原实体对象的被动性。现在的工作流模型元语言就区分为：动作提供者，动作活动，输入输出数据（被处理对象），动作控制信息四个部分。
比较系统论的状态方程
UML各种图形中如果把对象主动发出的控制信息（消息）与对象被动状态相联系，同时关注多个对象的状态转移图，从而形成封闭的面向对象的刺激反应模型，把状态图，顺序图和DFD数据流程图表达的有机融为一体。
这个模型就是有限自动机模型，也就是系统论中大名鼎鼎的状态方程。在这里，状态转移函数既表达了DFD的传递函数，也表达了对象的状态图，而多个对象之间的刺激响应的封闭关系，则表达了顺序图面向对象的总体模型。
附录：
有限自动机的数学定义（就是状态方程的离散形式）：
一个有限自动机Ｍ是指一个五元组：Ｍ＝(Q,I,O,δ,F),
其中Ｑ表示状态，Ｉ是输入，Ｏ为输出，δ是状态转移函数，
Ｆ是状态到输出Ｏ的映射函数。
则有：
Ｑn+1=δ(Qn,In),即下一时刻的状态值Ｑn+1由前一时刻的状态Ｑn与前一时刻的
输入Ｉn共同决定。
比如一般可用矩阵来表达δ转移函数：Qn+1=Qn×In。
Ｏn=F(Qn),即此刻的输出值是由此刻的状态值惟一决定，注意与当前的输入值并无直接关系。
【编辑推荐】
