UML的一个硬伤

[chnking]

看了高展先生的“UML的三大硬伤”，也看了网上诸位软件工程的爱好者，实践者的热烈讨论，结合自己实践中的一些经验，想谈一下自己的看法，可能很不成熟，也可能自己理解的有问题，讲出来请大家给我解惑。
高先生提出了UML的三大硬伤，正如《非程序员》回应中说的，其实《UML的三大硬伤》重点在第一点，即“UML上不着天——与用户/领域专家无法沟通获得真正的需求”，虽然我对它提出的论据很多表示不赞同，不过对其结论有同感，就是uml很难捕获和描述用户需求。
我对对uml的需求分析一直存在疑问，就凭use case那简单的图怎么能清楚的描述复杂的用户需求呢，都说use case是需求的最好表达方式，可是问题领域的业务需求是很复杂的，千变万化的，就凭use case几个小人，几根箭头，还有几个椭圆，怎么能行呢。看了很多use case的文章，还是觉得太单薄，use case不足以完整的表达业务需求。真不知这个UML怎么想的，还说什么整个系统分析要以use case驱动呢，真不知如何个驱动法。
use case还留了一手，可以有其相关的文档关联来补充说明use case，可是我觉得最后还是要靠文档了来说明问题了。

[jimconrad]

to elkel:
活动图如何关注某个对象在一个系统中的轨迹？不行吧？按上面的例子，如何关注电视信号变成数字节目到用户桌面文件这一流程？不能吧。活动图关注的是对象内部的处理过程和对象之间的在处理过程中的交互，而不是关注某个对象在整个系统中的轨迹。

[jimconrad]

to elkel:
你画画图看看，我觉得用uml表达不出一个对象在系统中流动这一情景。uml画出来的对象都是静止的：
1.顺序图这样的，先把对象(用矩形表示的那个图元)画好，再画它们之间的消息传递，重点考察的对象是在系统的空间分布上是静止的吧？！
2.协作图也是这样，先把对象(用矩形表示的那个图元)画好，再画它们之间的消息传递，重点考察的对象是静止的。
3.类图更是这样，对象静止。
4.用况图没有对象。
5.概念模型也是一样，概念是静止的。
6.包图也是一样，包是静止的。
7.状态图，重点从内部描述对象的状态变迁，对象在时间上是变化的；但没有对象流动这一概念，所以对象在空间上是静止的。
所以我想uml是不是缺乏对对象空间上流动的这一情况的描述呢？当然交互图中的消息是流动的，但是消息不是关注的重点，关注的重点是对象本身如何和其它对象的通信。我要的是直接的描述。

[Elkel]

to jimconrad:
活动图可以做到，需要使用泳道（swimlane）。

[Elkel]

还有Action-Object Flow

[Elkel]

还有Action-Object Flow

[mach]

to jimconrad(jimmy)
活动图的确能描述你说的那种逻辑，而且在需求阶段的早期，没必要也不应该言必称“对象”，你的那个电视节目的例子只是涉及到一个流程罢了，这正是活动图的功能所在，如果你要在活动图中描述对象流也是可以作到的。

[jimconrad]

能是能够，但是活动图要表达的重点是对象内部的活动的流程和相互之间活动的配合关系，而不是突出要表达“对象流”。如果用活动图表达“对象流”显然有背活动图的设计目的。如果要重点表达“对象流”，数据流图的表现力最佳，清清楚楚，一目了然。或许这时不能叫“数据流图”了，并且需要稍稍改进完善一下，叫它“对象流图”。反正就是类似数据流图那种形式和功能的“图”。

适合使用数据流图并有这种表达力的项目是有条件的。比如遇到《uml和模式应用》中“掷骰子游戏”这一类 单个或多个角色（游戏玩家）以某一种活动或事件（玩游戏）为中心在组成星型关系的系统时用数据流图就不适合；但是涉及到“物流”的系统却是再适合不过了。这种系统的特点是多个对象对单个对象流水线似的处理；而且这条流水线可以发生较大的变化，采取完全不同的处理算法或排列组合。这类系统比如上面的数字产品的发、internet上分组交换和路由问题、营销系统的渠道问题，都必须关注“物流对象”的来龙去脉，用活动图未免太缺乏表现力了吧?!

[jimconrad]

最后一段有些文字缺漏，改正如下：
适合使用数据流图并有这种表现力的项目是有条件的。比如：《uml和模式应用》中“掷骰子游戏”这一类 单个或多个角色（游戏玩家）以某一种活动或事件（玩游戏）为中心，对象关联是星型关系的系统，用数据流图就没必要；但是对于涉及到“物流”的系统，数据流图却是再适合不过了。这种系统的特点是：多个对象对单个对象进行流水线似的处理，而且这条流水线可能或者可以发生较大的变化，采取完全不同的处理算法或排列组合。这类系统比如上面的网上数字产品的发布、internet上分组交换和路由问题、营销系统的渠道问题，都必须关注“物流对象”的来龙去脉，用活动图未免太缺乏表现力了吧?!

[jimconrad]

数据流图不关注某个“加工”内部的活动流程，我们把“加工”换成拥有特定职责的对象来看，这样就没有了活动图中最碍眼的、或者说活动图本来想要表达的主要内容，当然对“物流”表现力要强。

不要以为把“加工”换成“特定职责的对像”此路不通，以为这就是走结构化设计的老路。我举微软的windows media services的例子就很清楚了。windows media service要广播一个视频文件，整个流程是这样的：
使用encoder(编码器)将一个视频文件变成流式文件，再通过windows media server将文件广播到用户桌面。您不能说encoder,server不可以划分为类或者对象吧?! 所以如果我画出数据流图的顶层图(或者1层图)之后，不按照结构化设计的思路继续细化数据流图以至于将功能分解到“支离破碎”的程度以至于无法正确重建(抽象出)对象和类，那么就不能说借鉴“数据流图”是不符合“面向对象”的。

如果我说的有误，请指教!感激不尽！

[Elkel]

To jimconrad(jimmy):
你的例子需要借助活动图才能完整的表示，并非UML不足。当然我不是说UML是完美的

[Elkel]

我不太赞成mach(照虎画猫)的看法，相反，我认为面向对象的分析是从对象开始的，对象是分析的目标。

to jimconrad(jimmy)
正如你所说的那样，数据流图继续细化下去就很难抽象出对象和类。从一开始，数据流图就已经把对象破坏了，数据流中的数据本来是一个对象，经过抽象后成了数据，而活动图中，对象流描述的就是对象。其次，数据流图中的数据加工并不能描述数据加工是由谁来加工的，而在活动图中数据加工直接表现为一个对象的职责。无论如何，数据流图确实不适合作“面向对象的分析”，一旦它细化下去，就会如你所说的那样，对象会变得“支离破碎”。
此外，活动图需要和用例图、协作图和时序图一起使用才能表现出强大威力，单独对比活动图和数据流图是没有意义的。

[Elkel]

to jimconrad(jimmy)
我还是不明白为什么你会认为活动图缺乏表现力，你能解释一下吗？

[jimconrad]

to elkel:
我已经说明原因了啊：“活动图要表达的重点是对象内部的活动的流程和相互之间活动的配合关系，而不是突出要表达“对象流”。如果用活动图表达“对象流”显然有背活动图的设计目的。”。不然活动图叫“活动图”干嘛？活动图在表现活动流程的时候很完美，但是表达“对象流”的时候鞭长莫及。

[jimconrad]

从一开始，数据流图就已经把对象破坏了，
// 关于这个我举的微软的那个media service的例子说明高层的数据流图不会破坏对象，至少在物流系统中不会被破坏。

数据流中的数据本来是一个对象，经过抽象后成了数据，而活动图中，对象流描述的就是对象。
// 在上面的物流系统中，被运输的“货物”(即:节目文件)在概念上从来就没有被分解过，我是以对象的概念来看待它们。

其次，数据流图中的数据加工并不能描述数据加工是由谁来加工的，而在活动图中数据加工直接表现为一个对象的职责。无论如何，数据流图确实不适合作“面向对象的分析”。
// 一个加工就是一个“职责”，面向对象分析的目的就是找出对象，把这些“职责”分派给它们。所以数据流图的任务是辅助分析人员找出负责该“职责”的对象，而不是先找到对象，再去发现“职责”。如果没有这些“职责”，请问如何寻找对象?!让我们看看《uml和模式应用》中的顺序是先描述需求、定义需求，给出需求规格说明，然后再定义用况，用况是从需求中归纳出来的；即使到了用况阶段，写在纸面上的(就是画在分析图纸上的)对象还没产生。所以为了辅助找出对象，我们可以借助数据流图。特别是物流系统，这种系统的被运输者(对象)和运输者(对象)几乎都可以从数据流图中找到，就像上面的windows media service。所以您的结论似乎下得太早了。

[Elkel]

to jimconrad:
活动图是被设计成可以描述对象流的，你可以参考文档UML1.4
http://www.omg.org/cgi-bin/doc?formal/01-09-67.pdf
3.90对活动图描述对象流作了详细说明。

我不认为使用活动图描述对象流有背活动图的设计目标。无论是什么图，只要是对描述系统有用的，就可以拿来就用（包括数据流图）。无论是什么图，我认为其设计目标都是用来描述系统。

“让我们看看《uml和模式应用》中的顺序是先描述需求、定义需求，给出需求规格说明，然后再定义用况，用况是从需求中归纳出来的；”
用例不是从需求中归纳出来的，而是需求借助用例图等工具逐渐明确的。

“如果没有这些“职责”，请问如何寻找对象?!”
需求分析中，大部分对象已经在用例图中明确，如你所说的encoder,server，被运输者和运输者。只用少部分对象需要在活动图中明确，如你所说的节目文件。对象不是从“职责”导出的，相反，我认为职责是分析对象时确定的。

[mach]

“活动图要表达的重点是对象内部的活动的流程和相互之间活动的配合关系，而不是突出要表达“对象流”。
活动图可以用于多种不同的场合，即可以用来描述全系统的流程，也可以是某个对象内部的过程，不存在上述这种说法，而且在需求阶段，由于还没有识别类/对象，因此更不可能用活动图表达对象内部的活动了。
活动图的概念是对数据流图、流程图的综合，在活动图中可以同时表示控制流和数据流，加上泳道的概念，活动图可以清晰、完整地描述整个业务过程的工作流，从这点来说，它是当前用于进行需求分析的最好的工具（优与数据流图）
要注意的是，无论活动图也好，别的什么图也好，不要妄自揣测其目的，而要关注其能力。

[老吴子]

我觉得初学者经常把需求和需求分析混淆，用例方法与用例图混淆。用例分析方法早在用例图出现以前就出现了。你完全可以不用用例图进行用例分析。用例分析的本质在于利用客户熟悉的语言、环境对典型的需求进行描述。另外，用例分析与OO并没有直接的联系，用例分析本身就不是OO的。

[Define_2002]

jimconrad(jimmy)

冒昧说两句，uml的意图，更多的是试图解决oo风格的设计的问题，
如果你的系统中某些子系统不能oo，确实会有某些麻烦。
不过oo是比较方法论的东西，并不一定要涉及的具体语言明说自己是oo的，你才可以用oo的概念。

你举的那个例子，我想可以把节目看作类，把一个节目看作对象，
注意这个对象并不是只有节目内容这样一个数据成员，
他的很多状态，都应当是成员变量，
然后这个对象在你的系统里流动，
沿途的各个对象都会对他进行某些操作，
操作的结果是数据成员的改变，也就是节目状态的改变。
我觉得状态图可以描述你的例子。

另外，我觉得Elkel说得对，你进入分析以后很快就离开对象这个概念了。
养成oo的习惯是一个很痛苦的过程，肯定会走回头路的。
你说“状态图...对象在时间上是变化的；但没有对象流动这一概念，所以对象在空间上是静止的。”
其实你想差了，你所关心的那个对象“流动”不“流动”，是没关系的，比如说c++里面，你把一个对象进行某些操作，然后拷贝一份到另一个机器上，然后继续对他操作，最终你把拷贝的那个对象当作结果，第一个对象干脆丢掉不要了，对结果是没影响的。
说了很多，不知道有没有说清我的意思，
不过我的态度应该说清了吧，呵呵，我觉得你的这个看法不对，:)

[ozzzzzz]

哦 其实需求是用户提出了 但是我现在看不到什么用户可以用usecase表示自己的需求 而我对XP使用user story的办法感到要好一些 当然你可以在这以后也使用usecase

[jimconrad]

多谢各位指点。
有没有人把上面的观点归纳一下……