面向模式构建系统架构
关键字 模式、系统架构
出处 http://www-900.ibm.com/developerWorks/cn/java/l-ArchUseDP/index.shtml
邓辉、孙鸣
架构是
个软件Software系统中
核心元素
是系统中最难改变部分也是构建软件Software系统中其他部分所依赖基础因此系统架构好坏会从根本上决定基于这个架构所构建软件Software系统质量
系统架构构建直是软件Software开发过程中项重要工作同时也是项很困难工作即便对于很有经验系统架构师也是如此但是模式以及模式语言提出给出了条构建系统架构有效途径本文将对此进行深入论述并以个著名单元测试工具JUnit为例进行介绍说明概念分析
首先
对架构(architecture)和模式(pattern)这两个概念进行简单介绍前面已经讲过架构是个系统中核心元素是该系统中最本质部分系统各个组成部分正是通过架构所描绘方式协同工作共同完成系统功能从而表现出个完整系统由于系统本质是不容易变化所以如果个架构构建正确也就是说能够真实反映出系统本质那么就可以使基于该架构构建系统具有比较长生命力否则该系统质量就会逐渐降级直至崩溃如果以建筑领域来作类比可能会比较好理解些试想如果个建筑物构建在个在结构上有问题混凝土骨架上那么该建筑寿命可想而知是不会长久什么是模式呢？模式是在某种特定
场景(context)下某个不断重复出现问题解决方案模式本身并没有任何创新性它仅仅是对于些已经被证明为优秀解决思路方法归类、整理总结目是为了重用该解决方案而又不用做重复劳动其中\"特定场景\"和\"重复\"两个限定词非常关键\"特定场景\"给出了什么时候以及为什么使用个模式\"重复\"介绍说明了模式可重复性从而可以被重用参考文献〔4〕中整理总结了23个经典模式非常值得读者朋友细心研读架构搭建
难点既然架构是
个系统中最核心、最本质部分要想构建个正确架构当然不会容易为什么呢？下面将从几个方面进行分析首先
由于架构是个系统中本质反映因此架构般是由系统中不容易改变部分组成这些不容易改变部分往往是系统中些抽象概念但是我们在构建系统架构前仅仅有些用户需求以及对于用户业务流程用例(use 
)如果缺乏有效指导原则很难从这些信息中提取出反映问题领域本质概念来有关这点参考文献〔3〕中给出了个很有效思路方法:Commonality/Variability(公共性/可变性)分析它核心思想是针对问题领域中概念进行分类把那些看上去区别但本质上属于类概念用个抽象概念来表示然后基于这些抽象概念构建架构Commonality/Variability分析思路方法在发现系统中抽象概念方面确实很有效但是前面已经说过系统架构不仅仅是些系统中抽象概念而且还描绘了这些抽象概念间关系仅仅使用Commonality/Variability分析思路方法不能十分有效发现抽象概念间关系其次
即使确定了抽象概念间关系构建起了个系统架构在这个架构指引下我们还是很有可能陷入困境为什么呢？
该架构可能会缺乏对于我们进步工作指引缺乏后续发现对象有效手段也就是说架构可能过于空泛缺乏延伸性最后
个经验丰富系统架构师可能成功构建了个系统架构成功基于该架构完成了系统但是他经验、心得体会体会可能会很难为其他系统架构师所理解从而在解决同类问题时可以有效被重用这些心得体会体会如果表现过于抽象可能会显空泛从而指导意义不大；如果表现过于具体有可能陷入细节从而失去通用性正是由于上述原因使得系统架构
构建非常困难往往必须由资深系统架构师来完成但是随着模式提出以及对模式研究深入这种局面正在逐步改变下面让我们先来对模式进行番深入认识深入认识模式
读者对于模式
认识大都是从
设计模式
(由参考文献[4]翻译而来)书出版开始该书中描绘了23个经典模式每个模式都给出了个精制优雅解决方案为每个
员所沉迷、拍案叫绝但是由于经验不足往往会造成对于模式误解设计模式书作者John Vlissides为此专门写了片文章进行阐述详见:http://www.research.ibm.com/designpatterns/pubs/top10misc.pdf本人在对模式进行深入研究以及实战基础上把对于模式认识划分为 3种境界下面进行介绍说明第
层境界:认为模式就是种解决方案般刚刚接触模式人都处于这个认识层面确实是这样刚刚见到模式时很容易被它所提供精制解决方案所吸引由于缺少经验反而容易忽略模式其它重要方面这样做非常容易造成对于模式误解、误用比如:为了使用模式而使用模式以及过分使用模式等这种境界仅仅认识到模式怎样(How)去解决个问题第 2层境界:除了解模式提供
解决方案以外还能够认识到模式背后些指导原则设计模式书第章对于模式背后些指导原则进行了详细论述比如:针对接口编程；优先使用组合而不是继承；发现变化、封装变化等不过缺乏经验人可能对此理解不会深刻甚至忽略了这些原则需要不断实战、体会方能理解不过体会到这些原则的后就会对面向对象思想理解提升个层次提高自己面向对象分析、设计能力参考文献[2]中对于这些原则有深入细致讲解相信会对读者有非常大帮助第 3层境界:认识到模式其实是
些关系用来舒缓系统内部\"冲突力\"这点仅仅从模式提供解决方案例子中就可以看出其实不管你如何去做最终解决方案肯定是些模块通过彼此交互、建立种关系来完成所需功能为什么模式提出思路方法就是好呢？就是模式给出关系舒缓了系统内部\"冲突力\"使人感受上去舒服些另外模式并不是简单给出了些概念间关系它进步为我们提供了个场景提供了进步工作指导是不是太抽象了我们来举个例子来介绍说明下:面向对象设计中有个著名原则:SRP(Single Responsibility Principle)即个类仅仅需要个职责如果个类有多于个职责有问题吗？实现起来当然没有问题但是经验丰富者马上就会感觉到职责间关系这种\"冲突力\"从而感觉到不舒服反映到实现层面上就是本来毫无关系模块间依赖过于强导致代码僵化牵发而动全身\"高内聚松耦合\"堪称软件Software领域处理模块间关系首要指导原则但是它没有告诉我们对于个问题具体该如何去做模式出现填充了这个空白如果我们知道个模式可以解决我们手头问题那么我们就可以非常感性认识到如何达到\"高内聚松耦合\"模式已经给出了这些关系这层境界非常抽象很难达到有兴趣读者可以阅读参考文献[1]相信会有更进步认识更加深入理解
下面我们就来谈谈模式为什么能够为系统架构
构建带来有效帮助面向模式构建系统架构
前面介绍了构建系统架构时
难点本小节将讲述下模式如何能够有效解决这些难题使得系统架构构建变得有章可循前面曾经提到过
Commonality/Variability分析思路方法可以有效发现反映问题领域本质概念但是不能十分有效发现抽象概念间关系如果Commonality/Variability分析思路方法和模式结合起来就能够有效解决这个问题上小节也说过模式其实就是些关系如果我们有些需求并且我们知道有针对该需求模式那么我们就可以通过Commonality/Variability分析思路方法发现反映问题领域本质概念然后根据可用模式去建立这些概念的间关系来实现我们需求这样我们就可以通过模式有效克服不能有效确定概念间关系难点模式本身并不仅仅简单是
些关系它还具有深刻内涵它具有自身意图、动机、适用性以及核心解决方案等众多内容旦我们确定使用了个模式那么这个模式就为我们搭建了个内容丰富场景这个场景可以非常有效指导我们进步工作启发我们发现新对象这样基于模式构建系统架构就变得抽象(模式本身就是些抽象关系)而不空泛并且具有很好延伸性模式也提供了
套公认非常有效记录思路方法可以把自己经过反复验证解决方案记录下来传授给其他人重用即模式具有可传授性这样有经验系统架构师就可以把自己些心得体会体会通过模式思路方法记录下来就可以克服经验无法有效传授问题其实很多模式本身就是针对系统架构提出
比如:MVC(Model-View-Controller)它是专门针对交互系统提出所以如果我们要构建个交互系统那么我们就可以直接应用MVC模式然后在该模式所搭建场景启发下去发现Model、View以及Controller在这个大场景指导下根据其它需求(模式)构建些小场景对系统进行有效分化细心读者会发现模式和系统架构有很大相似性都是处理些抽象概念间关系但是 2者还是有很大区别模式是领域无关它是解决些抽象问题但是系统架构是针对我们要解决实际问题是领域相关我们可以通过对问题领域分析、分解找到和我们要解决问题匹配模式对该模式进行定制应用到我们系统中来把模式结合在起构建起整个系统架构来面向模式构建
系统架构在需求发生变化时还会使我们处于个非常有利位置为什么呢？模式是针对个反复出现问题优秀解决方案它思路方法就是发现变化、封装变化它本身已经充分考虑了变化情况模式采用了种区别对待变化思路方法它不是预先考虑会如何变化而是考虑哪里可能会变化然后隔离所以当变化发生时我们就处于个有利位置上最后让我们来看看模式论坛研究、探讨
个焦点论题:模式生成性模式生成能力是指模式创建最终行为能力有人认为模式系统可以形成种语言即模式语言模式既是模式语言要素同时又是模式语言规则象数学证明样可以通过模式推导、演绎生成系统架构当然目前模式语言远远还不完备还不具有如此强大生成能力不过至少为我们软件Software开发永恒解决思路方法提出了个美好希望让我们大家共同来为此努力有兴趣读者可以到hillside.net获得更多有关模式语言信息JUnit架构
览前面讲了这么多
本小节我们将结合个例子进行介绍说明我所选择是JUnit个很著名单元测试工具选择它作为例子主要有两个原因:其是JUnit相对比较简单这样我可以集中于要论述主题；其 2是JUnit中大量使用了模式这样大家可以对于上面论述有个感性认识下面对于JUnit介绍说明会比较粗略读者可以到http://www.junit.org/去了解有关JUnit更加详细信息JUnit是
个单元测试工具所以它就要满足使用者对于单元测试工具需求让我们来进行介绍说明首先测试用例书写必须要容易只有这样大家才可能会使用该测试工具要迎合这点我们可以通过把测试用例表示为对象方式来完成对象概念和人思维中概念最为贴近表示起来也最为自然Command非常符合我们要求看看它意图:将个请求封装成个对象从而对请求进行排队或者记录日志…另外测试工具要为使用者做它能够做最多事情尽量减少使用者工作量我们必须对测试般流程进行分析归纳出个模板流程这样就可以使使用者仅仅关注自己所需要具体步骤而不用考虑如何去组织这些步骤(般测试都分为测试准备即
Up运行测试即runTest以及结束清除即tearDown阶段)Template Method模式正好能够帮上忙另外测试工具应该能够统处理单独用例以及多个用例组合这样也可以大大减少使用者工作量是不是马上就想到了Composite模式不错就是它下面根据上面
论述在我们所得出模式场景指导下给出JUnit系统架构UML图表示:Junit本身提供了源代码
有兴趣读者朋友可以参阅不过如果了解了系统架构后在去看源代码话相信会有区别感受结论
本文从宏观上探讨了系统架构、模式以及模式在构建系统架构方面
有效性限于篇幅其中有很多重要内容没有做十分深入论述有关这些内容准备在后续文章中作为独立主题来讲解希望本文能为读者朋友带来些启发最后我就以模式提出者Christopher Alexander段具有深刻内涵话作为结束:\"以种松散方式把些模式串接起来建造建筑是可能这样建筑仅仅是些模式堆砌而不紧凑这不够深刻然而另有种组合模式方式许多模式重叠在个物理空间里这样建筑非常紧凑在小块空间里集成了许多内涵由于这种紧凑它变得深刻\"参考文献
The Timeless Way of Building, Christopher Alexander
Design Patterns Explained: A New Perspective _disibledevent=>
Multi-Paradigm Design for C
, James O. CoplienDesign Patterns, Gamma, et. al.,
最新评论