呵呵

我对 OCL 没有太多看法，只是 粗浅、感性 地认为它是 UML 有益的补充。这是朝正确的方向（语言的无歧义性）走的一步，无论是多大的一步。WHATAVERY 给大家开导开导，OCL 能不能象编译器那样检验“作品”的正确性？

UML，和 UML 表述的“模式”，问题在于它的消费者是人，而不是一个编译器，或者RUNTIME。这和编程语言，甚至硬件描述语言（比如 VHDL 等）有本质区别。在这一点上，UML 其实还不可以称作为语言。比如，ASSEMBLY/C/JAVA 是可以数学证明正确性的，所以编译器和 RUNTIME 甚至 CPU 可以在“功能等价”的前提下进行优化。VHDL 也可以数学证明其正确性，所以工具可以进行大规模逻辑线路化简。甚至于传统的机械制图，也具有“无歧义”的特征，可以用 CAD 软件数学证明图的正确性。

UML 肯定做不到。OCL + UML 可以么？如果不行，那么 MDA 就还是“艺术”，或者科学“探索”，而不是理论体系。昨天 GOOGLE 出一篇 UNIV. OF HELSINKI 计算机系的文章，关于用CSP 在 UML 架构框图里采掘模式和反模式，目的是在设计期量化预测架构设计质量。我的看法是，在 UML 具备无歧义的语义之前，这样的工作之多只能算是“经验估算”性质。有意义，但是很有限。归根结底，整个“软件工程”学科的软肋还是在于语义的模糊上。

从整体方向上看，OCL 应该是向正确方向迈的一步。但是在最终出现一个有完备数学理论的 UML+ 之前，模式还是只能表述为“经验抽象”，主要功能是“人对人”之间的共同工具，而不是象编程语言那样严格的逻辑表达工具，最多是象 TOGETHER 那样搞一个“代码模板”式的 MDA。但是这样的 MDA，和 VC 里的代码模板，也没什么本质区别，不过多了些没有明确涵义的 UML 框图。

在一定程度上，我开始怀疑（呵呵，本人是天生的怀疑者）“面向对象”的整体方向是问题的根源所在。“面向对象”的哲学根基是建立在人对世界的“感性认识”上。历史证明，“感性认识”往往是靠不住的。尤其是，如果你的问题域足够复杂，即使你的问题本身看似很直观，也必须用数学的“理性抽象”来解决问题。比如，曾几何时，商业数据库的基础数据结构和操作语言都是基于直观而感性的“树”的。但是既不直观又不感性的“关系代数”改变了这一切。再比如，逻辑线路设计问题的理论基础是与电子线路毫不相干的多项式化简算法。再比如，（现学现卖地说：）从代码里反向模式发掘 的理论模型是看似风马牛不相及的有向图抽象和CSP算法。

所以，也许，在基于状态机的编程语言之上，作为软件世界观的更高阶的“抽象”，和作为软件工程方法论的架构“语言”，不该构造在“面向对象”的“模式”上，而应该够在在面向“数学抽象”的“函数语言（功能语言）”上？

本人是数学 FREAK，OCL 和日常工作又完全没有关系。性之所致，信口道来。哪位对 OO, OCL 有理论研究的，给启蒙一把？

Whatavery?
Dmuyy?
Banq?

因为我实战经验等于零（也许大学毕业之后会有不同的看法），但我十分看好OCL，所以特别想知道像您或Banq老师那样有过实践经验的人如何看待OCL。

手工01，ASSEMBLY，C，JAVA，语言的发展还是在远离操作系统。只不过java做的过分了点，加了一层，所以我特别看好模式语言，类似于OCL+UML，会不会有基于JVM的模式语言虚拟机？这样就加了两层。语言叫UML+OCL整成了图形化的BNF。

>>但是这样的 MDA，和 VC 里的代码模板，也没什么本质区别，不过多了些没有明确涵义的 UML 框图。

太对了, TOGETHER, RATIONAL离MDA太远了, 但我觉的这倒是因为MDA走的太快了, MDA太学院气了，这和我每回看SCI的一些paper的感觉一样.

OCL是题外话, 自己的想法也太过浅薄.

回到模式, 从Kyle_Yin老师那里我的到我对模式的想法一些改观, 我所以前关注的模式:
1, 模式在场景自动化的应用. 我希望模式走向语言, 就如用模式表达逻辑(这里的逻辑是场景抽象出的). 但是模式无法做到解决方案的最优, 且场景抽象成逻辑与模式的匹配程度无法量化.所以这里的自动化只能实现逻辑的推荐.

2, 模式是用出来的, 很多大牛在无模式的情况下用出了模式, 一部分就新模式就出来了.如IoC,所以我到觉得模式是在解决方案中抽象出来的, 模式在不断增加, 越来越多的场景会能够有更优的匹配.从场景到方案到模式, 既然场景可以抽象成UML, 用模式匹配逻辑化的UML不知道会不会更好?

3, 我个人是喜欢模式的, 但对我这种没有实践经验的小朋友来说我并不懂模式, 因为模式是用出来的所以还要用回去. 了解模式的适用场景, 用场景去匹配场景, 不知道场景匹配能否自动化一把?

因为模式在增长,我认为模式会有质变, 由于场景的多变使模式无法向formal method靠, HOHO,希望有一种模糊匹配的东西能诞生一下.

希望模式能走向于factoring(自创单词),而不是Refactoring或其他的东西. 叫模式成为一种推荐化的标准.

自己对模式还处于beginer时期, 所以观点过于浅薄.
感谢Kyle_Yin老师的reply.

BTW: 大家有没有搞过 information quality 的?最近看相关的东西头大了几圈.

我一直有一个疑问，就是在我们讨论有关技术方案所选择的技术框架时，比如Spring这种框架，是否非常清晰Spring能够解决问题的使用范围，也就是这种框架能够支持多大的应用，有没有量化的指标？有没有实际使用过呢？所谓己所不欲，勿施于人，单是概念上和逻辑上的理解我想是不足以推荐的。

说到这点，我觉得关于“请教一个多线程的问题”http://www.jdon.com/jive/thread.jsp?forum=121&thread=23654
中，关于具体问题的探究，在还没有分析清楚问题本身的时候，是否就应该套用什么模式呢？就像本贴所讨论的，究竟模式库的定位如何，这是一个关键，也是研究的基础。相比较来说，我觉得Kyle_Yin回答的问题都非常的中肯，而且挺实在的。

所以我有个建议，以后关于发帖提问也可以制定一个发帖格式，一方面迫使发帖人描述清楚自己的问题，说清楚问题的范围和应用需求；另一方面让回帖人能够清晰的掌握问题的内容/主题/范围，不会经常因为理解的差异而跑题；最后，如果发帖人的问题解决了，希望能够将最终的解决方法告知大家，也就是“结案”拉。

其实banq办的是一个挺不错的网站，但就是有时候讨论着讨论着就变了味道,搞的气氛不是很好.所以希望banq也能够兼听则明,多站在别人的角度想想问题，为什么大家"喜欢"和你较真。呵呵。

在这一阶段，我试图在模式社区(论坛的模式版块)引导大家讨论模式相关方面的问题，比如我一再重复的体系结构模式和设计模式的分类描述的问题。我想，OCL，MDA似乎不是在模式所要讨论的严格的范畴之内，所以不希望把讨论的话题发散开。见到MDA这个关键字，就开始讨论OCL，然后又讨论PIM和PSM，最后又到UML，转来转去，最后没有一个中心。现在似乎又冒出个information quality，首先我承认我无知不知道这是什么东西，主要想说的还是但愿大家不要把讨论的方向又转到这东西上来。似乎找个合适的版块专门开个帖子似乎更合适一些哦，呵呵。

我和你一样，学院派，还没工作过。做过很多项目了，失败的教训很多，成功的经验也有。我是想把这个模式库的讨论理论和工程相结合，需要我们把握好这个度。不要太学院化，也不要太低层化。呵呵。

anyway,还是谢谢参与讨论。
what's more,你的关于模式的一些观点我很赞同。继续啊。

首先，还是得回到国内外现状的综述上。

1、Ward Cunningham的波特兰模式库。
http://c2.com/ppr/
这里就是一些模式和模式语言的文章目录。文章里的内容格式没有一定的约束，每个作者根据自己的意愿组织其内容。这个所谓的模式库，似乎是模式和模式语言相关文章的文章库。

2、hillside的模式目录
http://hillside.net/patterns/onlinepatterncatalog.htm
在线模式目录只是将权威的讨论模式和模式研究的相关网站的链接相对较全面的列出来，而并不是对模式本身的分类目录。波特兰模式库的网址是这些网站的链接之一。山腰组的这个网站是对模式相关的书籍、文章、研究、论文、链接和会议的一个罗列。

3、国内Jdon网的设计模式
http://www.jdon.com/designpatterns/
(banq兄不要偷笑啊~)这里将设计模式按创建、结构、行为模式进行比较有条理的分类组织。(将模式清晰的分类组织，这正是我想要的)可是每一模式却没有一个固定的格式进行描述。(这不是我们将来的模式库所希望看到的)

4、或许存在这样的模式系统
这样的模式系统将模式进行分类组织，并采用为大家所普遍接受的(名称，语境，问题，解决方案)进行统一描述。(这已经是很接近我的要求了，至少他已经是一个有组织的经验库知识库，支持人们在线学习)但他没有很好的描述模式间关系，不支持模式语言，不支持模式社区的协作式写作，不支持模式系统的不断演化。

我们的模式库应具有如下一些需求[POSA96]：

1、应该包括足够多的模式
将现有的已知的所有模式(包括体系结构模式和设计模式)通过大家的力量以协作式写作的方式加入到这个模式库中。
2、应该统一描述它所有的模式
将库中的所有模式按照一个简洁但又能描述的足够清楚的统一的方式进行分类描述。
3、应该揭示模式间的各种关系
描述清楚各模式间的关系，哪些模式可通过模式细化得到，哪些模式相结合可形成更大模式和模式语言。
4、应该组织它的组成模式
便于用户找到能帮助他们解决问题的模式。
5、应该可以进行自我演化
随着技术的发展，现有模式可能会改变，描述将改进，有新的模式被发现然后加入，有些模式则可能过时。模式库要支持这些演化，且由大众一起努力完成。
6、应该支持软件系统的构造
首先这个模式库得支持人们对模式的学习和理解，指导人们如何应用模式。更进一步的支持软件系统的构造，需要做更多努力。

显然，按我的标准，现在还没有一个满足我的定义的模式库，或至少是我现在不知道有。满足以上的几点需求，这就是需要我们一起努力来实现的模式库。

最后，
To：Kyle_Yin ，我这样的答复如何？呵呵
To：whatavery，欢迎你继续参加讨论模式相关问题，:)
To: 其他同学，用更猛烈的炮火打过来吧！我十分明白，这个模式库必须得经受得住大家炮火的考验才行。同学们也可以帮助我抵御这些炮火。呵呵

[POSA96] Frank Buschmann等，面向模式的软件体系结构 卷1：模式系统，译[M]，机械工业出版社，2003，210~211

从以上看，第一步是第二步的基础，第一和第二步是第三步的基础。第三步的实现就现在的理论基础而言还有点乌托邦，我们将致力于前两步的实现。

其实，根据[POSA2]的经验，现在不流行弄模式库了，并且建立一个通用的模式库十分困难。随着模式的不断增多，模式库将急剧膨胀，使模式难以分类、描述之间关系、学习和使用。[POSA2]提出的一个解决方案是专注于建立某一特定领域的模式库。他们还认为，将现有模式组织成模式语言比将他们归类成模式系统更有效。我想这也是波特兰模式库现在改型为以罗列和创作模式语言相关的文章为重点的原因。但，我想，模式语言，还是要以模式为基础的，还是要建立在一个全面的模式库的基础之上。总不能说解决某问题可以使用某种模式语言，这个模式语言包括哪些模式，但每个模式具体怎么回事却不继续说了，让人家无法继续下去。所以，包含有足够多模式的模式库是“必须”的，然后“有必要”在这个模式库的基础上进行模式语言的相关工作。

参考文献：
[POSA2] Douglas Schmidt等，面向模式的软件体系结构 卷2：用于并发和网络化对象的模式，译[M]，机械工业出版社，2003，321~331

个人感觉模式库建立不能山头太多，导致定义差异，容易产生歧义，我们可以将更多精力放在模式语言的讨论上，模式语言和框架联系很紧密的，而且实用价值高，在中国这样一个实用至上的文化中，通过模式语言的研究讨论，为一定领域提出一个解决方向，然后逐渐丰富，最后也许模式库就自然而然诞生。

所以我的想法与dmuyy有些不同：
1. 根据问题，在GoF 23模式基础上提出模式语言，也可引入其他模式
2. 某一个问题的彻底解决，必然带来众多模式语言的结合，客观上形成了小规模的模式库。
3. 以领域问题为线索，组成一系列模式语言为基本单元的模式库。

http://sei.dlmu.edu.cn/pattern/

http://sei.dlmu.edu.cn:7000/pattern/

还没什么内容，持续改进中

http://sei.dlmu.edu.cn/pattern/

http://sei.dlmu.edu.cn:7000/pattern/

还没什么内容，持续改进中