对uml建模动态方面的认识
　

---

uml观点
1、序列图
2、协作图
3、状态图
4、活动图
第一个问题：
图为现象的描述还是分析结果
分析以上图背后的认识论
一致调度机制的形成

1、序列图认识论
有一个边界对象，接受外界激励，按照预设的规则，将任务分配给各个对象完成职责，并产生结果
结果可能为一些实例生死，或一些对象的状态改变
行为为有序的，依照规定去完成，很象我国的计划经济呀
2、协作图
看看足球场的场景，球（执行权）被不断传递，为了一个共同的目的射门获破坏射门
若有一个激励，对象如何配合去完成任务
预定义的配合关系为协作图的重点，贪官们的攻守同盟可算一个好的场景
4、状态图
冷眼旁观，着眼点在系统或重要的对象
1、状态为如何演化的（有几种状态，有价值的演化次序
2、状态演化的原因
状态图首先确定几种状态
从状态演化的原因我们就分析透彻了系统的动态行为
好的用例一个贪官的堕落

5、活动图

活动图原来与oo思想不兼容较大，如何理解呢
模型中的活动怎样理解
活动与行为的关系

如果我们用模型的规则论来认识，活动图其实表达为各项活动的产生规则。
那么活动抽象了什么呢，活动将系统运动过程分割，并进一步分割为对象行为
从这个观点其实就是状态图，但更符合思维习惯。
比如
结婚--生子
若理解为进入结婚状态，生子状态就较为难受

另一个问题设计模式中行为模式和这些图的关系
从图出发研究因为图时明确定义了的，没有统一的方法，但认识的加深有助于我们解决问题,我式小人物，希望抛砖引玉

　

图是一种符号化的表达，既可以表达对现象的观察，也可以表达对本质的认识。UML的图本质上就是一种语言写出来的文章，本身并不代表现象或者现象的本质，文章中的含义可以是现象，也可以是本质。
模型应完整地刻画感兴趣的现实世界的过程，而且，从现象到本质是多个层次的。从场景的描述到逻辑模型是深入本质的层次递进过程，从逻辑模型到物理模型是重归现象的层次过程。
整个模型是彻底的动态模型，静态模型是对象间得以传递消息的稳定的经络，正如你对关联的理解，静态模型的存在只是为了表达动态交互的基础，并为实现找到基元。但最终目的，还是为了实现那个过程。所以强化过程的概念是必要的，尤其在理解动态建模的时候。
先忘记UML,看看现实世界的过程是如何才能完整清晰地表达的，然后，就会知道UML各种图的用意。

一个目标接着一个目标实现，于是，我们就看到了一个过程。
一个活动接着一个活动进行，于是，我们就看到了一个过程。
一个动作接着一个动作做出，于是，我们就看到了一个活动。
一个变化接着一个变化出现，于是，我们就看到了一个过程。

我们可以这样从外到内、从面到线到点、从现象到本质去观察和描述过程，把一个过程的全景完全刻画出来。这就是动态模型。
从目标到活动是从过程外到过程内描述；将过程按照目标来划分就是用例，用活动来阐释用例是开始进入过程内部进行探索。
从活动到动作意味着在过程内部进行线和点的离散化，动作必须由对象发出，动作的连接必须靠对象的消息传递。对象的动作能力构成对象的方法，动作中用到和得到的信息靠对象的属性提供。于是得到所谓静态模型。对象是点，事件流是线，协作是面。
这样表达一个用例的内部活动细节的部分模型就是一个用例实现。由于用例代表用户所需的过程目标或目标过程，因此，每个用例得到实现，系统就得到实现。
从一个对象考察它的状态变化是实现这个对象和测试这个对象的需要。对象在全过程中会参与众多的活动，在其所有活动中他的全部的属性值可能会存在相对稳定的集合的一些状态，每个集合标识了对象的一个状态。

建模中时刻要想着的是：“他们（哪、那些对象）是怎么去实现用户需要的那些过程的。

谢谢指点
在做静态建模时有ER作指导，到动态感觉好像理论基础不足
您的离散的观点是独创的吗

你所指的ER图的静态模型和面向对象中的静态模型有本质不同，不知道你注意到了没有。许多人把实体关系和对象关联认为是可类比和转换的，这实际上是为了弥补一个蹩脚的技术层面的缺陷，在认识论的层面完全属于不同的脉络，这种转换极易造成对面向对象思想理解的污染。

 回复: 关联类如何发现
　

---

您的点线面的教导很有用。
我在做系统时确实经常用ER思考，很大一个问题为关联类的问题
用ER容易理解，OO就想不通，请指教
　

由于我们有共同的哲学爱好，所以，我觉得这个问题先从哲学层面找到答案会更有益于我们来理解它。

我们从ER图和类关联图对比谈起。

ER图认识问题的出发点是从信息系统主体角度出发的，目的是直接得到现实世界从信息角度分解的结果。着重于如何直接用数据关系来转述现实世界实物之间的关系。
因为ER模型是一个直接的数据关系模型，所以，从ER图看来，一切都是静态的，动态的东西也要静态化来处理，就像用线性化方法处理非线性问题。

作为面向对象的静态模型之一的“类-关联”图，认识问题的出发点是现实世界存在的活的事物，目的是先从本质上理解现实世界事物运动变化发展的规律，再考虑如何在计算机中模拟出这种本质规律的机制。
类-关联图之所以被称为静态模型，是因为其反映了事物本身和事物之间的相互关系的相对稳定性，这种稳定性是我们通过对事物运动变化过程离散采样，然后进行分析发现的相对不变的部分。我们的目的并不是得到这个相对稳定的对象和对象关系模型，而是根据这部分的认识，再重新拟合出新的现实世界过程模型，新的过程有计算机的参与。

以前，由于在技术标准上尚未找到对对象和对象关系信息的持久存储问题的答案，所以需要用关系型数据库来保存这些信息，于是出现两个模型混用的局面。这造成了两种思路的相互干扰。
如今，XML已经成为分布式的对象和对象关系信息的持久存储和交换的标准，但平台工具层面尚未有成熟的OO数据库得到广泛应用，因此，这个蹩脚的技术问题还会困扰我们一段时间，我们必须清楚地认识到，这只是技术手段，而不是思想。

我们试图用ER模型方法得到面向对象静态模型和用面向对象方法得到ER的实体关系模型，至少在思想上的不连贯的，尽管二者存在某种形式上的同态。

寻找关联类的方法应该来自纯粹的面向对象模式的思考。
我们起初建立面向对象的静态模型时，考虑的原则有两点：
1.所有的事必须要有对象来完成；
2.所有的对象必须做适当的事。
顺便提一句题外话：这两个原则实际上也是企业管理的原则，所以，我称现在企业管理思想还处于结构化时代，是进化到面向对象时代的时候了。

所谓关联，只是对象做事时，不同对象之间进行沟通的管道关系。当你发现某处这些管道关系很复杂，需要维护，又能够划归到某个独立的职责范围的时候，你觉得如果有一个对象专门处理这些关系就好了，就可以定义一个关联类。

当你开始考虑实现所有用例的时候，你暂时不需要考虑关联类的存在，只要满足以上两条原则就行了，随着被实现的用例越来越多，你需要把各个用例实现的对象模型合并成一个总的对象模型，你的总体的对象关联图也越来越复杂，这时候，你就可以考虑使用关联类，抽象类等高级一点的手段。这时，一定要保证总的用例模型和每一个用例实现的一致性。

 回复: 精辟，管道关系，您真厉害
　

---

利用管道关系理解就有了进一步抽象的可能性
您出过书吗，如果没有我觉得应该写一本从认识论角度讲OOAD的东西，我一定会买