|
这个主题共有 27 回复 ／ 2 页 [
1 2
下一页
]
|
|
|
|
|
|
我们现在没有讨论的但有必要讨论的模式
|
发表: 2005年12月02日 10:09
|
回复
|
|
当前，解决软件开发的效率和质量的问题，复用是重要途径。人们逐渐由原来的代码拷贝粘贴式的复用，转到了基于软构件的复用，也产生了基于构件软件开发CBSD和基于构件软件工程CBSE等概念和研究。尽管如此，人们的复用层次仍停留在代码实现层次。
模式的复用，包括体系结构模式和设计模式的复用，将复用的层次提高到分析和设计层。把复用的重点放在抽象层次上，这将从根本上解决软件开发中的问题。将人们的成功设计经验不断形成模式，并通过建立模式库将这些模式分类和描述，为以后的软件开发设计提供指导。
在浏览了很多讨论设计模式和应用框架的论坛后，发现人们在该类版块主要讨论的东西有：
1、讨论某一具体设计模式。
某人刚学习设计模式不久，然后发布自己对某模式的理解，然后发贴请教高手如何应用该模式。
2、讨论应用框架。
人们热衷与比较各类应用框架，MVC，如讨论Spring, Struts等。比较他们的有缺点，互有支持者。
3、讨论应用框架使用中遇到的问题。
讨论这些框架的具体应用。请教如何解决在应用这些框架时遇到的问题。
人们讨论的问题都比较实际，主要目的还是为了解决实际的日常工作中的项目的问题，这很自然和可以理解。我想即使是设计模式、体系结构、应用框架的讨论社区，能常光顾的还是做编码这一层的人居多做系统分析和架构设计的人少，所以不难理解人们讨论的是以实际编码实际应用为主，而讨论模式采掘、体系结构设计和应用框架开发的几乎没有。
|
|
|
|
|
|
相关定义、概念和理论
|
发表: 2005年12月02日 10:13
|
回复
|
|
在进行下一步讨论之前，需要来点相关定义、概念和理论。
1、模式的定义：
什么是模式？应该没有一个很精确的定义，但我们可以通俗的来说。模式是特定的‘语境’中重复出现的设计‘问题’的‘解决方案’。模式是人们经验的积累，人们利用经验来指导新的软件的设计。
2、模式的分类：
由模式用于解决问题的规模和它的抽象程度高低来划分，由高至低可分为体系结构模式(architectural pattern)、设计模式(design pattern)和惯用法(idiom)。
我们通常讨论的都是设计模式。体系结构模式很容易理解，即如何设计一个应用系统范围的结构特性。在有了整体架构后，就需要用设计模式来解决一些子系统的模块的细化的设计问题。可能大家唯独对惯用法模式比较陌生。体系结构模式和设计模式都是语言无关的，独立与具体语言，抽象度高。而惯用法则是针对某一种具体编程语言的底层模式。描述如何使用给定语言的特性来解决问题。比如在C++中如何编程解决垃圾回收的问题，而显然Java中就不用考虑这个问题。这就是惯用法。代码层次的模式，代码层次的编程经验。
3、模式语言：
通过体系结构模式的指导确定软件的体系结构。设计模式呢则解决某一具体问题的设计问题，如工厂模式，单例模式等解决对象创建问题。由体系结构模式到设计模式，这个跨度十分大，模式语言正好解决这个问题。
模式语言是一组相关模式的组合。通常一些设计模式单独使用意义不大，而通常是一组模式结合着使用的。例如一个分布式J2EE应用的业务层通过值对象来进行数据传递(值对象模式)，通过一个代理来给其它层提供服务(代理模式)，通过封装复杂的调用提供一个简单统一的调用(门面模式)，而在该应用的显示层则采用(装饰器模式)等等模式。这样，这一能解决某一问题的整套模式的集合，就是一个模式语言。它解决问题的粒度更大。
4、模式库(pattern repository)：
就是存放模式的一个仓库，呵呵。是一个存放人们成功设计经验的仓库。将各种模式分类、描述和存储，提供方便的检索和浏览方式，让人们学习模式，学习模式的使用。
5、模式的采掘：
模式既然是人们的经验，显然我们不能够发明模式，而只能够从已进行的设计中总结成功的经验，发现模式。这个过程，就是模式采掘。
以上是一些理论基础。大部分是没有问题的，但有些是自己的理解，所以有不同意见的就赶紧吱一声啊，以便及时更正。
|
|
|
|
|
|
我们有必要讨论的模式相关话题
|
发表: 2005年12月02日 10:14
|
回复
|
|
我就在想，国内的模式社区的同学们，能不能将讨论的层次提升一下，不要总是只专注与代码层和框架应用问题的层次上。以下是我想到的可以讨论的一些方面。有同学有更好想法就赶紧吱一声啊，好让我们的讨论让自己看起来好像“档次更高些”啊。
1、讨论如何更好的描述设计模式，讨论模式之间的关系，如何分类和组织模式，以让后来者系统的学习。
2、讨论模式语言，用多个模式的组合解决更大更复杂的问题。如何描述和分类组织模式语言。
3、讨论软件体系结构模式，提出某一应用领域的软件的体系结构的设计，并讨论如何描述和如何应用之。
4、讨论如何采掘模式，发现新的模式。在已开发的多个系统中采掘成功的设计经验，然后描述并提出。
5、讨论如何构建一个模式库。这个模式库应具有的功能，她如何分类描述各种模式，如何描述模式间的关系。
以上共有五点，其实，最终可归纳为一点，即第五点，前四点都是为第五点而服务的。模式库的研究也就是研究如何对设计模式，模式语言，体系结构模式的分类和描述，如何采掘新模式等等。本人想建立一个体系结构模式库和设计模式模式库，收集、分类、组织和索引模式。或让新手学习过来人的成功经验，或基于这些模式以及结合构件库系统形成半自动的大规模的基于复用开发的软件生产线。
|
|
|
|
|
|
Re: 我们现在没有讨论的但有必要讨论的模式
|
发表: 2005年12月02日 11:30
|
回复
|
|
支持，其实能参与这样的讨论者很少，真希望越来越多的能跳得出来，又能跳得进去（高度和细节同时兼顾）。
之前我们讨论使用Composite+Visitor以及其他模式结合解决应用中经常碰到的树形结构访问这一课题，属于楼主提到的“模式语言”范畴：能解决某一问题的整套模式的集合，就是一个模式语言。
连接地址如下：
Composite模式和树形结构的讨论
|
|
|
|
|
|
Re: 我们现在没有讨论的但有必要讨论的模式
|
发表: 2005年12月02日 12:08
|
回复
|
|
再补充如下：
现在大家水平和意识都不在一个起跑线上，从jdon论坛中看出，很多软件实战高手也没有模式概念，甚至依据自己的实战经验，怀疑模式作用，从以前讨论“一个懂模式又咋样？不还是一个技工吗？”可以明白。
很多人怀疑模式 而不怀疑数据结构，是因为模式没有成为软件基础教育的一部分，所以，深入了解模式的人比较少。
其实数据结构与模式语言的结合可以很好地 重用的解决一类通用问题，下面这个主题就是结合Composite+Visitor模式和二叉树概念解决树形结构通用问题访问这类实际应用中问题，从而形成解决一类问题的框架，这样不是提高我们开发效率和开发质量吗？
目前我们应用中，大量的是树形结构信息，如网站内容 Blog 论坛，商品信息 ERP分类 凡是涉及到树形分类都可以用这套模式语言来考虑，我只是举了一个例子。
关于对模式作用认识不是很清楚的几组讨论：
一个懂模式又咋样？不还是一个技工吗？
http://www.jdon.com/jive/thread.jsp?forum=91&thread=17831
也有人认为：
"通用的框架解决的是通用的问题，但不一定是最佳的解决方案。
做技术也是追求真理的一种方式，不必做某种技术的保皇派吧。
我相信技术方案只有最适合的，没有所谓最好的和最通用的。"
通用框架确实是解决通用问题，通过框架其实是通用模式语言的集合，具体解决方案还需要结合具体模式组合来解决。
其实坚持模式语言，是追求软件的高质量，追求软件的最大可扩展性和重要性，这本身是一种高质量的技术方案，它的采用与否只是由技术以外原因决定：时间和进度以及费用。
关于“我相信技术方案只有最适合的，没有所谓最好的和最通用的。”
技术方案是人做出来的，而模式构成的方案可以提供“没有最好 只有最合适的”实现方案，也就是说：只有使用模式才能真正实现最适合的方案，而不是每个人当事人自己觉得合适就合适了。
相关连接：
http://www.jdon.com/jive/thread.jsp?forum=121&thread=23654
该贴楼主提出的问题，如果从模式角度考虑而提出解决方案将是一个合适的技术方案，从该贴问题的解决方案争辩中，体现了三个不同方向：1.提出以模式架构提出的解决方案; 2.从产品或标准产品的角度提出解决方案；3.从底层多线程角度提出解决方案，而不是面向组件和面向构件基础的解决方案。
三种方案代表三种思维，说明我们现在对解决问题的思考方向还有分歧，那么要统一在以模式为基础的更高层次讨论是多么的难。
|
|
|
|
|
|
Re: 我们有必要讨论的模式相关话题
|
发表: 2005年12月02日 13:51
|
回复
|
|
http://hillside.net/patterns/onlinepatterncatalog.htm
类似的组织和工作已经不少了～～ 楼主的计划有什么不同吗？
作为一个研究话题，“模式采掘”至少存在 10 年以上了。记得在什么地方看见过1996年一篇马里兰大学计算机系的文章，就在讨论模式采掘，描述和模式库。不幸的是，这个东西从来没有从“话题”上升成真正的“课题”。
包含模式库的 MDA 软件，比较有名的有 TOGETHER CONTROL CENTER，RATIONAL，ECLIPSE UML2正在向这个方向发展。楼主的计划是类似的么？
|
|
|
|
|
|
模式库的相关内容
|
发表: 2005年12月02日 14:23
|
回复
|
|
一、
1、模式库研究的意义：
通过模式库积累人们的成功设计经验，为以后的软件开发设计提供指导。提高复用的层次，并通过复用，提高软件的开发效率和质量。废话不想多说，反正意义就是很重大。
2、国内外研究现状：
1995年Ward Cunningham为了方便模式社群的交流建立了一个工具－波特兰模式知识库（Portland Pattern Repository）。在建立这个系统的过程中，Ward Cunningham创造了Wiki的概念和名称，并且实现了支持这些概念的服务系统。Wiki是现在炒的火热的WEB2.0中的其中一个概念，是一个面向社群的协作式写作工具。基于Wiki技术的波特兰模式库为模式社区提供了一个方便的交流场地，Wiki允许每个社区成员都能修改和创建页面的内容，讨论模式相关问题。
在国外，有最大的模式团体hillside，其成员包括Ward Cunningham,Kent Beck,'Gof',Grady Booch,James Coplien等。这个团体是PLoP(Pattern Language of Programs)会议的发起者。
在国内，讨论模式的人分散于各个模式社区，以论坛为主。人们讨论的主题分散，讨论的层次相对较低。大家主要还是以学习他人的模式为主，且主要通过书本的方式学习，模式社区的论坛仅用于讨论各自的理解。
我想，我们有必要建立一个国人自己的中文模式库，其内容通过协作式写作而提供。每个模式社区的人员都可对模式库作出自己的贡献。把模式库建成一个共享的经验库，知识库，for the people, by the people.
我想，模式库主要需要解决的问题就是如何分类和描述模式问题，使得模式的组织结构清晰；提供方便的检索功能，让人们快速找到所需了解的模式；要能够利用Web和超链接的特性更好的表达和呈现模式及模式间的关系，让人们觉得浏览在线模式库比看静态组织的书本强；要提供简便易用的创造工具，让模式社区成员协作写作。
我想，从另外一个角度来看，模式库就是一本由大家努力，集大家智慧和经验于一体的一本在线模式书。这本书不断更正和更新，力保权威和正确；不断有人采掘新的模式并加入，力保完整和全面。权威和全面，我想这是我们的目标系统的主要特性。
|
|
|
|
|
|
Re: 我们现在没有讨论的但有必要讨论的模式
|
发表: 2005年12月02日 14:49
|
回复
|
|
为什么算法和结构被广泛认为属于“科学”的领域，能够登堂入室进入本科教育，而“模式”却远远没有这样的待遇？
不仅如此，关于“模式”的探讨，在本身就十分疲软的“软件工程”学科里，也不是一个受重视的研究方向。“模式”领域的定鼎之作 GOF，1995 年出版。试问，计算机界还有那个学科领域在用十年前的文物作教材？
WHY? WHY? WHY?
原因很简单，模式，或者“软件工程”的通病，软肋，遗传弱势：没有量化的研究语言，习惯和方法。
IEEE对“软件工程”一词的定义（没人指望我背出原话吧？），其中的关键词是“定量的方法和研究”。在科学和工程界，不用公式和数字说话的理论，是无法证明自己的（其实首先不能称其为理论）。这就是工程科学界的起跑线。这就是科学工程界对“理论”水平和意识的基本要求。
这并不是说模式无用。作为 经验抽象 和 实践指导 的模式有很大实用价值，本科教育应该涉及和介绍，虽然远远不应该，也不可能提到与数据结构和算法平级的地位。
归根结底，“模式”不可能成为科学，甚至工程方法论，原因首先在于“模式”对自身的定位：经验抽象、实践指导。 “模式”要成为 XX论 与数据结构、计算机语言、算法、操作系统。。。平起平坐，当务之急是重新定义自身的性质和目的。
如果“模式”，“框架”的演绎和努力方向，是一个可以数学（理论或者数值）证明其正确性、优越性的理论体系，并且成为一个软件设计的“正规方法 formal method”（而不是指导 guideline），那么它才有登堂入室的希望。
否则，“设计模式”就还是一本“高级技工入门指南”尔。不过你的工具是键盘而不是车床罢了。
|
|
|
|
|
|
Re: 模式库的相关内容
|
发表: 2005年12月02日 14:53
|
回复
|
|
我不否认模式和模式库的价值和意义。
我的问题是为什么需要“另一个”模式库。（Yet Another Pattern Library）仅仅因为它将是中文的？
还没有什么科技领域的东西因为这个原因而成功的。
> 我想，我们有必要建立一个国人自己的中文模式库，
|
|
|
|
|
|
Re: 模式库的相关内容
|
发表: 2005年12月02日 14:58
|
回复
|
|
|
我原来还以为你要搞 MDA 工具呢。。。原来是中文模式WIKI。
|
|
|
|
|
|
回复Kyle_Yin：
|
发表: 2005年12月02日 15:34
|
回复
|
|
首先感谢参与讨论！
个人认为，Ward Cunningham等人所创建的波特兰模式库更大的成功在于提出了协作式写作的概念(wiki)。因为既然是模式是经验，那就需要大众的参与，共享每个人的经验，才能达到更好的效果。然而就模式库角度而言，我不认为她是个好的模式库。那里似乎只是一些大牛们发布他们模式相关文章的地方。这些模式文章没有很好的分类组织，模式的表述风格各异。不仅如此，该网站的定位不断演变，历程如下：
http://c2.com/ppr/
1994年 模式社区及其他们的资源和应用；
1996年 普通设计、建筑以及方法；
1997年 从人和组织的角度看待规划设计；
1998年 偏激的规划设计；
2000年 维客本身；
2003年 维客、社会学等。
最后，这里更多的是讨论Wiki本身；还有由于Kent Beck的加入，这里又变成了讨论极限编程(eXtrem Programming)的权威网站。这就是现在的波特兰模式库。
此外，国外最大的模式团体山腰组(hillside)的模式目录，我想这里则正好与前者相反吧。然而，模式的分类描述还有必要进一步改进，才能吸引人们不再买书而上网在线学习模式，间接保护几棵大树。显然山腰组还是做得不够成功，以至没有改变人们的阅读习惯，还是有很多大树被砍掉来出版模式书籍。
还有一个很重要的一点就是，这些东西都是国外的，国人的E文水平你也知道，并不是很多人的E文水平都像我这样顶呱呱:-)。所以有必要弄一个中文的模式社区。而现有的中文模式社区就是我之前分析的现状，人们在论坛里讨论的东西层次也有待提高。
95年至今，已跨了一个世纪，已有十年之久。山腰组里的成员为模式研究做了巨大的贡献。不管她是个“话题”还是“课题”，我想做的就是推动国内模式社区在更高层次上讨论模式的相关“？题”。
你提到的支持模式的MDA软件，我暂时没有想得那么远。模式既然是他人的经验和智慧，人们只有学会了她才能运用好她的，不管你有多么傻瓜的工具支持。就像Rational Rose里的应用某某模式的那些向导,确实很方便，但是如果你连这个模式到底怎么回事都不知道，那么这个功能就成了摆设。所以，现阶段的模式库，主要的工作还是研究如何分类描述所有模式、揭示模式间的关系、支持模式库的自我演化、支持协作式创造，而由模式库直接支持软件系统的构造，这可放在下一步的工作当中。
|
|
|
|
|
|
Re: 我们现在没有讨论的但有必要讨论的模式
|
发表: 2005年12月02日 15:43
|
回复
|
|
Kyle_Yin的问题确实一针见血。
我们现在有必要做好我们这个模式库的定位的问题。她有什么特点？我们为什么离不开她？呵呵
这是我一直在思考的问题。
我想需要有更多的人的想法来加入和实现语我们这个模式库当中。
|
|
|
|
|
|
Re: 我们现在没有讨论的但有必要讨论的模式
|
发表: 2005年12月02日 17:32
|
回复
|
|
Kyle_Yin老师 对OCL有什么看法？（我总觉的MDA铺的面太大了点），所以只想请教Kyle_Yin老师对OCL看法。
对于dmuyy老师，我倒是感觉您自己做WIKI是不是有些难度，也许要是做cluster of WIKI会好一些。
|
|
|
|
|
|
模式分类
|
发表: 2005年12月02日 21:45
|
回复
|
|
在我之前的讨论，最经常用到的词汇就是模式的“分类”和“描述”。我想，这是最重要的两个方面，最需要大家一起研究的两个方面。
我们先讨论一下模式分类吧。现在我知道的有如下一些分类方法：
1、按规模和抽象程度划分：
体系结构模式、设计模式、惯用法。
2、按解决的问题划分：
例如分布式系统、交互式系统、访问控制、通信、资源处理等问题。
3、1＋2，模式类别＋问题类别，形成一个二维的模式分类图式。
随着模式库中模式的不断增多，理解和使用模式库就越困难。一个好的模式分类方法，有助于人们更好的理解模式。好的模式分类图式需具有如下一些特性：
＋简单、易学，而不是复杂、难使用；
＋少而精的分类标准；
＋每个分类标准反应模式的自然属性；
＋根据该分类能让用户找到一组可能适用的模式，而不是找到唯一适用模式；
＋应对新模式的集成开发，而不需要对现有分类进行重构。
参考资料：
Frank Buschmann等，面向模式的软件体系结构 卷1：模式系统，译[M]，机械工业出版社，2003，211~214
至于现有的分类方法的优缺点，我不十分知道，需要大家一起研究；
至于现有的分类方法需改进点，我不十分清楚，需要大家一起讨论。
|
|
|
|
|
|
模式描述
|
发表: 2005年12月02日 21:51
|
回复
|
|
所谓模式的描述，我的定义是如何表达人们的设计经验。好的描述和表达，可以让人家更容易理解你的设计思想。通常我们阅读的一些模式书籍或文章对某一模式的描述都是有如下几部分：
应用这一模式的‘语境’；
这一模式可解决的‘问题’；
模式解决问题的‘解决方案’；
然后，给该模式起个好听的‘名称’。
模式(名称,语境,问题,解决方案),这似乎是基本要素。除了以上的要素之外，可能还有别名，动态特性，变体，使用例子，使用后的效果等。对于模式的描述，有过于复杂和过于简单两个极端。如何做到对模式描述得足够清楚便于人们学习理解，又不用描述得太繁琐复杂？我们是不是可以讨论讨论呢？
对于体系结构模式，很多学者在研究一些形式化的描述语言，叫体系结构描述语言(ADL, Architecture Description Language)。他们提出了若干适用于特定领域的ADL。典型的有: C2 是一种基于构件和消息的ADL,适用于大型频繁交互的层次型图形用户界面的软件的体系结构描述; Darwin和 Wright分别将π演算和 CSP 作为其数学基础,适用于分布、并发类型的体系结构描述; ACME 是一种体系结构互换语言,支持从一种 ADL 向另一种 ADL 规格说明转换。其他比较有影响的 ADL,如 Aesop,Unicon,Rapide,SADL,MetaH,Weaves 等。
按照一定的描述方法,用体系结构描述语言对体系结构进行说明的结果则称为体系结构的表示,而将描述体系结构的过程称为体系结构构造。在体系结构描述方面, Kruchten 提出的“4+1”模型是当前软件体系结构描述的一个经典范例,该模型由逻辑视图、开发视图、过程视图和物理视图组成,并通过场景将这 4 个视图有机地结合起来,比较细致地描述了需求和体系结构之间的关系。
以上似乎表明，体系结构描述的研究欣欣向荣，形式一片大好。但我们可千万别乐观，事实上的情况是ADL 繁多,缺乏统一的 ADL 的支持。尽管 Shaw 等人提出了体系结构互换语言 ACME,但没有统一的体系结构描述语言框架与定义,不同体系结构描述语言所描述的体系结构规格说明难以互换。既然说没有统一的ADL，那么有人说采用业界普遍已认同的UML来描述吧。但我想毕竟UML并不是专门用于描述体系结构模式的，需要做很多扩展，用stereotype，这个过程中，势必又需要做许多标准化工作。
总之，在模式描述的路上，我们还有很长的路要走。同学们，我们赶紧起程吧，呵呵。
参考资料：
Frank Buschmann等，面向模式的软件体系结构 卷1：模式系统，译[M]，机械工业出版社，2003，211~214.
孙昌爱, 金茂忠, 刘超,软件体系结构研究综述,软件学报,2002,13(7):1228~1237.
|
|
|
|
|
|
这个主题有 27 回复 ／ 2 页 [
1 2
下一页
]
|
|
|
注册
登陆
上一主题
下一主题
