系统架构设计

alex_zsc

贡献于2017-06-13

字数:0 关键词: 软件架构

系统架构:面向模式构建系统架构 疯狂代码 http://www.crazycoder.cn/ ĵ: http:/www.crazycoder.cn/SoftwareEngineering/Article34145.html 面向模式构建系统架构 关键字 模式、系统架构 出处 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]相信会有更进 步认识更加深入理解 2008-12-13 21:07:54 疯狂代码 http://www.crazycoder.cn/

下载文档,方便阅读与编辑

文档的实际排版效果,会与网站的显示效果略有不同!!

需要 10 金币 [ 分享文档获得金币 ] 0 人已下载

下载文档

相关文档