（计算机应用技术专业论文）基于设计模式的asrs调度系统框架的设计与实现.pdf

中文摘要 a s 瓜s 是计算机技术、自动控制技术以及现代物流观念相结合的产物，是近年来 国内外迅速发展的一种新型仓储设施。w s s 的功能是有效调度各种自动化设备，节 能高效的完成货物的入出库任务。该系统的设计与开发已经在现代仓储业中起到了 举足轻重的作用。因此，本文以建立并实现通用的w s s 框架为主要研究内容。 本文将设计模式的思想运用于软件框架设计中，提出了基于设计模式的软件框 架。该方法对设计模式、设计原则、软件框架等技术进行了系统的研究与分析。设 计模式与应用框架的结合能够很好的优化系统框架，达到高可靠、可复用、可扩展 的目标。 w s s 的开发周期、开发成本以及系统的可复用可维护性直接制约着a s r s 的各 项发展。文章将基于设计模式的软件框架的思想与w s s 的具体实际相结合，提出了 基于设计模式的w s s 框架，并完成了该框架的设计。 在整体框架的指导下，以框架模块内的高内聚，模块间的低耦合为原则，对三层 架构的每一层进行了详细的设计与实现。首先，通过对数据库结构的分析，建立了 w s s 数据结构；通过数据库访问接口层的研究以及基于模式的日志机制的建立，完 成了数据访问层的设计与实现。然后，通对过a s r s 具体业务的分析，在业务逻辑 层设计原则的约束下结合设计模式完成了业务逻辑层的设计与实现。最后，在对 m v c 模式的研究与分析的基础上，结合具体需求，完成了w s s 表示层的设计与实 现。 基于文章所设计框架的通用w s s 已经开发且测试完毕，并运行于多家单位的立 体库之中，整体效果良好，达到了预期目标。 关键词：w s s ；自动化立体仓库；设计模式；设计原则；应用框架；m v c a b s t r a c t a u t o m a t e ds t o r a g e & r e t r i e v a ls y s t e m ( a s r s ) i st h ec o m b i n a t i o no f c o m p u t e rt e c h n o l o g y , a u t o m a t i c c o n t r o lt e c h n o l o g ya n dt h ec o n c e p to f m o d e ml o g i s t i c s i nr e c e n ty e a r s ，a san e wt y p eo fs t o r a g ef a c i l i t i e s ，t h e d e v e l o p m e n to f i ti sv e r yr a p i db o t ha th o m ea n da b r o a d w ssc a ne f f e c t i v e l y s c h e d u l eav a r i e t yo fa u t o m a t i o ne q u i p m e n t ，a n dc o m p l e t et a s k so fg o o d s i n t o o u to fl i b r a r yi ne n e r g y s a v i n ga n de f f i c i e n tw a y t h ed e s i g na n d d e v e l o p m e n t o ft h i s s y s t e m h a s p l a y e d ad e c i s i v er o l ei nm o d e m w a r e h o u s i n gi n d u s t r y t h e r e f o r e ，t h em a i nr e s e a r c hi so nt h ee s t a b l i s h m e n t a n da c h i e v e m e n to ft h ef r a m e w o r ko fc o m m o nw s s i nt h i sp a p e r , d e s i g np a t t e m si sa p p l i e dt os o f t w a r ef r a m e w o r ka n dt h e i d e ao fs o f t w a r ef r a m e w o r kb a s e do nd e s i g np a t t e m si sp r e s e n t e d t h e m e t h o dp u tt h er e s e a r c ha n da n a l y s i so nd e s i g np a t t e r n s ，d e s i g np r i n c i p l ea n d s o f t w a r ef r a m e w o r k t h ec o m b i n a t i o no fd e s i g np a t t e r n sa n da p p l i c a t i o n f r a m e w o r kc a nb eg o o df o rt h eo p t i m i z a t i o no fs y s t e mf r a m e w o r k t h et a r g e t o f h i g hr e l i a b i l i t y , r e u s a b i l i t ya n ds c a l a b i l i t yi sa c h i e v e d t h ed e v e l o p m e n to fw ssi sd i r e c tc o n s t r a i n e db yd e v e l o p m e n tc y c l ea n d d e v e l o p m e n tc o s t sa n dt h er e u s a b i l i t ya n dm a i n t a i n a b i l i t yo fs y s t e m t h ei d e a o fs o f t w a r ef r a m e w o r kb a s e do nd e s i g np a t t e r n sa n dt h ec o n c r e t ep r a c t i c e o fw s sa r ec o m b i n e di nt h i sp a p e r e v e n t u a l l y , w ssf r a m e w o r kb a s e do n d e s i g np a t t e m si sp r e s e n t e da n dt h ed e s i g no f t h ef r a m e w o r ki sa c h i e v e d u n d e rt h eg u i d a n c eo ft h eo v e r a l lf r a m e w o r k ，t h ed e t a i ld e s i g na n d i m p l e m e n t a t i o nh a sb e e nd o n eo ne a c hl a y e ro ft h r e e - t i e rf r a m e w o r ki nt h e p r i n c i p l eo fh i g hc o h e s i o na n dl o wc o u p l i n gb e t w e e nm o d u l e s f i r s to fa l l ， t h r o u g ht h ea n a l y s i s o ft h ed a t a b a s es t r u c t u r e ，w s sd a t as t r u c t u r ei s e s t a b l i s h e d t h r o u g ht h e r e s e a r c ho nd a t a b a s ea c c e s si n t e r f a c ea n dt h e e s t a b l i s h m e n to ft h el o gm e c h a n i s m ，t h ed e s i g na n di m p l e m e n t a t i o no fd a t a a c c e s sl a y e ri sc o m p l e t e d t h e n ，t h r o u g ht h ea n a l y s i so ft h es p e c i f i cb u s i n e s s o fa s r s ，t h ed e s i g na n di m p l e m e n t a t i o no fb u s i n e s sl o g i ct i e ri s t t l c o m p l e t e di nt h ec o n s t r a i n to f t h eb u s i n e s sl o g i ct i e rw i t ht h ec o n n e c t i o no f d e s i g np a t t e r n s f i n a l l y , o nt h eb a s i so ft h er e s e a r c ha n da n a l y s i so fm v c p a t t e r n si nc o n n e c t i o nw i t ht h es p e c i f i cn e e d so fw s sp r e s e n t a t i o nl a y e r , t h e d e s i g na n di m p l e m e n t a t i o no fw s sp r e s e n t a t i o nl a y e ri sc o m p l e t e d t h ec o m m o nw ssb a s e do nt h ef r a m e w o r kd e s i g n e di nt h i sp a p e rh a s b e e nd e v e l o p e da n dt e s t e d ，a n dt h es y s t e mh a sb e e nr u ni nm a n yu n i t s a s r s t h eo v e r a l lr e s u l ti sg o o da n dt h ed e s i r e do b je c t i v ei sa c h i e v e d k e yw o r d s ：w s s ；a s r s ；d e s i g np a t t e m s ；d e s i g np r i n c i p l e ；a p p l i c a t i o n f r a m e w o r k ；m v c i v 声明尸明 本人郑重声明：所呈交的学位论文，是本人在指导教师的指导下， 独立进行研究所取得的成果。除文中已经注明引用的内容外，本论文 不包含其他个人或集体已经发表或撰写过的科研成果。对本文的研究 做出重要贡献的个人和集体，均已在文中以明确方式标明。本声明的 法律责任由本人承担。 作者虢鱼垦! 隰鲨鹭垒旦塑 关于学位论文使用权的说明 本人完全了解太原科技大学有关保管、使用学位论文的规定，其 中包括：学校有权保管、并向有关- 音b f 7 送交学位论文的原件、复印 件与电子版；学校可以采用影印、缩印或其它复制手段复制并保存 学位论文；学校可允许学位论文被查阅或借阅；学校可以学术交 流为目的，复制赠送和交换学位论文；学校可以公布学位论文的全 部或部分内容( 保密学位论文在解密后遵守此规定) 。 作者签名：五询日期： 导师签名：$ z 盎量n 日期：二竺! 乒啦 第一章绪论 第一章绪论 构建企业级计算机系统并非易事，随着计算机技术的不断发展与计算机应用领域 的不断拓宽，企业级应用系统的规模成倍递增、版本升级周期不断缩短、需求变动 日趋频繁，构建相应软件的难度也呈指数增加【1 1 。因此在应用系统的开发过程中既要 保证开发的速度，同时还要保证系统的可扩展性。 在面向对象的软件工程的研究中，软件复用【2 】、软件重构网以及设计模式吲已经 成为该领域的重要研究课题，代码复用通过继承机制和编译技术己成为现实。代码 的重构机制指在不改变代码的外在行为的前提下对代码做出修改，以改进程序的内 部结构更好的支持软件复用技术。随着面向对象技术的不断成熟，单纯的代码复用 已经不能满足大型软件的生产需求。为了提高软件生产过程的复用粒度，软件系统 的架构师们开始进行一种新的尝试来提高软件开发的效率，即复用相似的分析设计 结果和体系结构，以此来减少构造新软件系统的成本，并借助成熟的软件体系结构 来提高软件系统的可靠性。框架跟建筑中的框架式结构是一样的。使用了框架( 钢 筋+ 混凝土) 以后，你所专注的只是业务( 非承重墙构建不同格局) ，当然是在遵守 框架的协议的基础上开发业务。好的框架都是松耦合的，易配置的。框架技术由于 支持大粒度复用而被业界称为有前途的复用技术。 设计模式描述了一个待求解的问题、问题的解决方案以及该方案的工作场景。一 个应用领域内的大型软件系统蕴含着几代研发人的设计经验，一旦这些成熟思路被 发现并抽象成为设计模式，它们则可用于指导同类软件开发并被复用。当这些设计 模式被有机组合后用于特定应用系统时，便形成了“模式系统”( p a t t e r n ss y s t e m ) 。如 果该系统能在应用领域内充分共享，且成为解决领域内特定问题的可积累知识库的 一部分，则模式系统的建立将对该领域软件架构的设计起到提纲挈领的作用。 软件系统的框架设计需要架构师从高屋建瓴的角度来看待系统问题，他们关注的 不再是每一个类的定义，以及各个功能点的具体实现，而是整个系统中有关层次的 划分、模块的关系、系统的性能、数据安全以及数据事务的处理。架构师必须对整 个项目的需求有通盘的考虑，并在领域专家的帮助下，深入理解业务流程与领域逻 辑，构建整个软件的系统体系架构的技术平台和框架。 1 1 课题的研究背景及意义 现代物流是把握竞争优势的有效方式，将为国民经济在高起点上持续发展提供基 础动力。在经济全球化和信息化的推动下，现代物流业已从为社会提供传统运输服 1 基于设计模式的a s r s 调度系统框架的设计与实现 务，扩展到以现代科技、管理和信息技术为支柱的综合物流系统。目前，许多发达 国家已经形成了比较成熟的物流管理理念、先进的物流技术和高效的物流运营系统。 经济腾飞中的中国，必将加快现代物流的发展，以此增强企业的竞争力，优化资源 配置，提高经济运行质量，实现我国经济体制与经济增长方式的两个根本改变，从 而推动我国经济的持续健康发展。 自动化立体仓库( a u t o m a t e ds t o r a g e r e t r i e v a ls y s t e m ，即a s r s ) 作为现代物流 系统的核心组成部分，正为越来越多的行业所应用。a s r s 是现代物流技术，仓储 技术，自动化技术与计算机技术高度集成化的产物，它具有存储容量大，占地面积 小，作业快速准确，节约人力等优点，已成为工厂物流，计算机集成制造系统和商 业流通领域的重要组成部分。目前a s r s 主要用于两大领域：其一是各种自动化生 产线的在线立体仓库系统；其二是各种物资配送中心。 由于a s r s 的规模趋于大型化、多样化、复杂化，a s r s 调度系统( w a r e h o u s e s c h e d u l i n gs y s t e m 即w s s ) 的开发周期和系统的扩展与维护严重影响着该行业的发 展。因此，如何提高调度系统代码的可复用性、可扩展性、可维护性，使其性能达 到最优，开发周期达到最短就成为了一个非常重要的课题。 1 2 国内外现状 到目前为止，研究a s r s 调度的方法很多，国内外对a s r s 的入库调度算法进 行了深入的研究并取得了一定的进展；对软件体系框架设计的研究也有很多，但是 尚不存在对w s s 框架设计的研究，更没有这方面的实现。 1 2 1a s r s 调度算法的研究现状 国外对a s 瓜s 调度方法的研究有，美国学者l i n n r 于1 9 9 0 年提出将专家系统的 思想应用于a s r s 的入出库调度控制中【5 】；本世纪初k i m b y u n g 等提出了一个基于 调度控制系统的混合智能a g e n t 结构并成功的将其应用于a s r s 的货位拣选问趔6 】； 印度的0 v k r i s h n a i a hc h e t t y 于2 0 0 3 年运用遗传算法对a s r s 调度进行了研究【| 7 】； d o n a l d t e p a s 引入一种知识信息系统来辅助决策立体仓库的入出库调度算法。新加 坡南洋技术大学的s g l e e ，r d e s o u z a ，e k o n g 等通过导引小车服务的a s r s 的一个 巷道的模拟仿真。 近年来国内在a s r s 的入出库调度算法的研究上也可以说是卓有成效。山东大 学的田国会等提出了影响仓库运行效益的若干优化调度问题，分别采用p e t r i 网、时 态逻辑、模拟退火、遗传算法、神经网络等方法，并结合计算机仿真技术进行了研 2 第一章绪论 究。山东工业大学的常发亮等研究了物资配送中心的库存管理与布局优化问题，讨 论了库存量的确定方法，提出了货位的布局策略及其优化算法，并对货位的再调整 进行了阐述。同济大学的赵炯，薛劲松提出了基于控制元结构的路由搜索调度算法。 北京邮电大学的甘剑锋、周晓光提出了基于排队论的a g v 调度效率分析。上海理工 大学王恒山介绍了一种基于实时控制的立体仓库出入库算法。北京邮电大学的周晓 燕等提出了基于有限级表的出库调度算法等。 1 2 2 面向对象的软件框架研究现状 早在上世纪6 0 年代，戴克斯特拉就已经提到过软件架构这个概念了。19 世纪9 0 年代以来，由于在r a t i o n a ls o f t w a r ec o r p o r a t i o n 和微软内部的相关活动，软件框架 这个概念开始逐渐被人们所接受。卡内基梅隆大学和加州大学在软件框架这个领域 作了很多研究。卡内基梅隆大学的m a r ys h a w 和d a v i dg a r l a n 于1 9 9 6 年在s o f t w a r e a r c h i t e c t u r e p e r s p e c t i v eo n a l le m e r g i n g d i s c i p l i n e ) ) 一书中提出了软件架构中的很多概 念，诸如组件、复用等等。加州大学的软件研究院所做的工作则主要集中于架构风 格、架构描述语言以及动态架构。 面向对象的软件架构( s o f t w a r ea r c l l i t e c t u r e ) 是把一系列相关的抽象模式，用于 指导大型软件系统各个方面的设计。软件架构就像一个建筑的草图。软件架构描述 的对象是直接用来构成系统的抽象组件。各个组件之间的连接则明确和相对细致地 描述了组件之间的通讯。在系统的具体实现阶段，这些抽象组件被细化为具体的实 际组件，比如具体的某个类或者对象。在面向对象领域中，组件之间的连接通常采 用接口的思想来实现。软件构架是一个容易理解的概念，多数软件工程师会从直觉 上来认识它，但到目前为止并没有精确的定义。设计与架构很难明确地区分。 在软件构架简介一书中，d a v i dg a r l a n 和m a r ys h a w 认为软件构架是有关 如下问题的设计层次【l l 】【1 2 】：在计算的算法和数据结构之外，设计并确定系统整体结 构成为了新的问题。结构问题包括总体组织结构和全局控制结构；通信、同步和数 据访问的协议；设计元素的功能分配与物理分布；设计元素的组成；定标与性能； 备选设计的选择。 设计模式源自建筑学和人类学，c h i r s t o p h e ra l e x a n d e r 在他的书t h et i m e l e s s w a yo fb u i l d i n g 中提出了“质量能够客观评价吗? ”的思想，也就是说人们是否能 够就某些东西达成共识【8 】【9 】。c h i r s t o p h e r a l e x a n d e r 在描述城市和建筑模式时说：“每 一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核 基丁设计模式的a s r s 调度系统框架的设计与实现 心，这样，你就能一次又一次的使用该方案而不必做重复劳动”。受此观点的影响， 由e r i c hg a m m a 、r i c h a r dh e l m 、r a l p hj o h n s o n 和j o h nv l i s s i d e s 也就是我们通常 说的g o f 在19 9 4 年合著的 d e s i g np a t t e r n s ：e l e m e n t so fr e u s a b l eo b j e c t o r i e n t e d s o f t w a r e ) ) 初次向世人展示了设计模式的魅力，也使他们成为设计模式的伟大先驱、 提出者和集大成割10 1 。2 0 0 2 年m a r t i nf o w l e r 的重构：改善既有代码的设计则刮 起了一阵重构与模式的旋风。设计模式代表了传统软件开发的思想：好的设计会产 生好的软件，因此在实际开发之前，值得花时间去做一个全面而细致的设计。重构 则代表了敏捷软件开发的浪潮：软件并不是在一开始就可以设计得完美无缺的，因 此可以先进行实际开发，然后通过对代码不断地进行小幅度的修改来改善其设计。 这两种方式看似格格不入，但它们都在本质上有一个相同的思想，即设计很重要， 只是两者达到良好设计的方法不同。从设计模式和重构第一天与开发人员见面开始， 它们注定就是一对休戚相关的孪生兄弟。目前国内外针对设计模式的研究主要包括 以下三个方面：实际开发经验中新设计模式的发现和总结；设计模式的分析和描述； 具体设计模式在实际开发中的应用。这三者构成一个从特性到共性，再由共性到特 性的循环往复的过程。 1 3 主要研究内容和文章组织结构 1 3 1 主要研究内容 本文针对现代物流业a s r s 入出库全自动化调度系统的具体需求，旨在建立具 有大粒度复用的基于设计模式的w s s 的框架，以求能够更加方便快捷的编写w s s 。 文章对面向对象软件设计的复用技术、设计模式及框架技术进行了详细的研究与分 析【1 3 】。结合现代物流企业w s s 的特点和软件自身结构，对软件开发中通用过程进行 了提炼和封装，提出了一种n e t 平台下的基于设计模式的w s s 应用系统框架并加 以实现。文章提出了该应用框架的设计目标、设计了具体的方案，并给出了具体实 现。根据m i c r o s o f t 推荐的分层架构模式，该框架分为三个组成部分：基于m y c 模 式的w s s 表示层、基于模式的通用的w s s 数据访问层、面向接口的业务逻辑层。 本框架不仅适应于n e t 的w i n d o w s f o r m 系统开发；而且借鉴了j 2 e e 中数据访问的 思想，访问不同公司的数据库时，代码不需要做太大的改变。这样使n e t 环境下开 发的数据库系统具有更好的灵活性和扩展性。 1 3 2 文章的组织结构 本文共8 章： 4 第一章绪论 第一章介绍课题的研究背景、研究现状以及课题研究对象。 第二章从面向应用的角度介绍本论文中涉及到的设计原则与设计模式。 第三章介绍了框架技术的概念、特征、分类、组成、框架的设计原则以及课题涉 及到的n e tf r a m e w o r k 运行机制、反射技术、委托技术。 第四章对w s s 体系结构进行了分析，介绍了基于设计模式的w s s 框架的总体 设计。 第五章介绍了通用的数据访问层的设计与实现。 第六章介绍了面向接口的业务逻辑层的设计与实现。 第七章在对m v c 模式研究的基础上，完成了表示层的设计与实现。 第八章对本文的研究成果进行了总结，指出了下一步工作。 第二章设计原则与设计模式 第二章设计原则与设计模式 对于一个成功的n e t 项目，好的编程习惯和合理的0 0 设计是坚实的基础。如果 我们想尽量避免用中劣质的代码，就必须坚持良好的0 0 设计原则。如果想用最简 单且行之有效的方法解决现实中的问题，就必须引入设计模式。本章将讨论一些常 用的面向对象的设计模式与设计原则【1 4 1 。 设计模式是面向对象技术的最新进展之一，现在面向对象的分析工具、图书以及 各种培训中都加入了设计模式的内容，设计模式学习在各地发展如火如荼。在软件 开发中结构相对良好的软件体系结构中都包含了一定设计模式的成分，无论是在做 业务调查，需求分析、结构设计以及编码，还是做项目管理都可以找到适合的模式 来辅助我们的工作。通过复用已经公认的设计，我们能够在解决问题时取得先发优 势，而且避免重蹈前人覆辙。我们可以从学习他人的经验中获益，用不着为那些总 是会重复出现的问题再次设计解决方案。开发中的交流和协作都需要共同的词汇基 础和对问题的共识。设计模式在项目的分析和设计阶段提供了共同的基准点。模式 还为我们提供了观察问题、设计过程和面向对象的更高层次的视角，这使我们从“过 早处理细节”的桎梏中解放出来。单独的设计模式只是前人对具体开发经验的总结， 只是适合于解决具体领域的具体问题。但是运用面向对象的思想将不同的模式运用 在不同的场合，辅助以设计原则以及框架技术，就能够建立比较简洁、灵活、易于 理解的软件体系结构【l5 1 。在软件架构的设计过程中，有效的利用设计模式可以复用 前人在面向对象设计与开发过程中的有价值的经验，使用最简洁，且可复用的形式 将其表达出来，从而提高了框架的可复用性。目前，软件设计模式己经被证明是一 种行之有效的面向对象的设计和分析方法。 2 1 通用的0 0 设计原则 2 1 1 开闭原则 一个软件模块( 类、函数、代码块等) 在扩展性方面应该是开放的，而在更改性 方面应该是封闭的，这就是开闭原则。简单的说就是软件实体( 类、函数、代码块 等) 应该可以扩展，但是不可修改。要实现该原则，在进行面向对象设计时就要尽 量考虑接口封装机制、抽象机制和多态技术。这里的关键是将这个软件模块的功能 部分和不同的实现细节清晰的分离开来。 我们在做任何系统的时候，都不要指望系统一开始时需求确定就再也不会变化， 基丁没计模式的a s r s 调度系统框架的没计与实现 这是不现实也是不科学的，既然需求是一定要变化的，那么如何在面对需求变化时， 设计的系统能够相对容易修改，不至于一有新的需求，一切必须重头再来，这时我 们可以考虑用开闭原则。 2 1 2 接口分离原则 采用多个与特定客户类有关的接口比采用涵盖多个客户业务方法单一接口要好。 根据客户不同的要求，并定义提供不同的服务。 2 1 3 合成聚合原则 该原则指在实现代码重用时首先考虑类的合成聚合，而不是类的继承。 类的继承是严格的，如果父类实现发生改变，那么子类的实现也要相应发生 变化。 继承破坏类封装性，子类必须和父类关联在一起。 不合理的继承，带来混乱的语义。 2 1 4 依赖倒置原则 高层模块不应该依赖低层模块，二者都应该依赖于抽象。抽象不应该依赖于细节， 而是倒过来，细节依赖于抽象。面向对象方法的出现很大程度上解决了结构化设计 中高层模块过度依赖于低层模块的问题。其工具就是：利用接口或者抽象类来实现 松散耦合，具体实现类依赖于抽象类和接口，要针对接口编程，而不要针对实现去 编程。 2 2 设计模式的定义 模式源自建筑学和人类学，c h i r s t o p h e ra l e x a n d e r 在描述城市和建筑模式时说： “每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案 的核心，这样，你就能一次又一次的使用该方案而不必做重复劳动 。受此观点的影 响由著名的四人组g o f 在1 9 9 4 年初次提出了设计模式的概念。目前模式主要应用 于软件体系结构和设计以及软件开发过程和组织。 2 2 1 什么是设计模式 设计模式描述了一个待求解的问题、问题的解决方案以及该方案的工作场景。一 个应用领域内的大型软件系统蕴含着几代研发人的设计经验，一旦这些成熟思路被 发现并抽象成为设计模式，它们则可用于指导同类软件开发并被复用。当这些设计 模式被有机组合后用于特定应用系统时，便形成了“模式系统”( p a t t e r ns y s t e m ) f 1 6 1 。 r 第二章设计原则与设计模式 如果该系统能在应用领域内充分共享，且成为解决领域内特定问题的可积累知识库 的一部分，则模式系统的建立将对该领域软件架构的设计起提纲挈领的作用。基于 框架的软件开发过程把软件开发看成一种组装过程，在软件框架的指导下寻找可以 复用的构件及开发一些新构件来完成系统的组装，这种开发过程是目前很受重视的 开发方向【1 7 1 。 2 2 2 本课题为什么要引入设计模式 在w s s 的开发过程中有些因素是固定不变的，但是不同的立体仓库又具有自身 的特点。开发环境、设备数量以及用户要求都不尽相同。为了快速、高效并且高可 靠的开发w s s 。本文旨在建立基于设计模式的w s s 的框架。软件框架设计是一系列 重要决策的集合，这些决策与以下内容有关：软件的组织，构成系统的结构元素及 其接口的选择，这些元素在相互协作中明确表现出的行为，这些结构元素和行为元 素进一步组合所构成的更大规模的子系统，以及指导这一组织其中包括这些元素及 其接口、它们的协作和它们的组合。为了建立更好的w s s 框架，解决上述问题，我 们引入设计模式。设计模式具有以下优点： 复用解决方案：通过复用已经公认的设计，我们能够在解决问题时取得先发 优势，而且避免重蹈前人覆辙。我们可以在学习他人的经验中获益，用不着 为那些总是会出现的问题再次设计解决方案。 确立通用术语：开发中的交流和协作都需要共同的词汇基础和对问题的共识。 设计模式在项目的分析和设计阶段提供了共同的基准点。 解放思想：模式还为我们提供了观察问题、设计过程和面向对象的更高层次 的视角，这将使我们从“过早处理细节 的桎梏中解放出来。 技术支持：设计模式为企业级系统的架构设计提供了技术支持。 2 3 基本设计模式 g o f 的设计模式一书中共介绍了2 3 种设计模式，当然设计模式不止2 3 种。 g o f 依据模式的设计目的将设计模式分为创建型模式、结构型模式以及行为型模式 三类【1 9 】。 创建型模式：创建型模式通过将实例化职责委托他方对象的办法，隔离客户 程序与具体类型实例化的依赖关系，保证客户程序( 或者外部系统) 获得期 望具体类型实例的、且同时不必发生直接的引用。如：s i n g l e t o np a t t e r n ；a b s t r a c t f a c t o r yp a t t e m ；b u l i d e rp a t t e r n 等。 9 基丁- 设计模式的a s r s 调度系统框架的设计与实现 结构型模式：结构型模式的重点在于如何通过灵活的体系，组织不同的对象， 并在此基础上完成更为复杂的类型( 或者类型系统) ，而参与组合的各类型之 间始终保持尽量松散的结构关系。如：f a c a d ep a t t e r n ；p r o x yp a t t e r n ；b r i d g e p a t t e r n ；a d a p t e rp a t t e r n 等。 行为型模式：行为型模式关注于应用运行过程中算法的提供和通信关系的梳 理。如：t e m p l a t em e t h o dp a t t e r n ；o b s e r v e rp a t t e r n ；c o m m a n dp a t t e r n ；s t r a t e g y p a t t e r n ；v i s i t o rp a t t e r n 等。 设计模式是“封装变化”思想的最佳阐述。无论是创建型模式、结构型模式还是 行为型模式，归根结底都是寻找软件中可能存在的“变化”，然后利用抽象的方式对 这些变化进行封装。由于抽象没有具体的实现。就代表一种无限的可能性，使得扩 展成为可能。所以在设计之初，我们除了要实现需求所设定的用例外，还需要标定 可能或已经存在的“变化 之处。封装变化，最重要的一点就是发现变化，或者说 是寻找变化。 2 3 1s i n g l e t o n 模式 s i n g l e t o n 是一种很常见的创建型模式，该模式保证一个类仅有一个实例，并提供 一个访问它的全局访问点。通常我们可以使用全局变量使得一个对象被访问，但不 能防止你实例化多个对象，一个最好的方法就是让类自身来保存它的唯一实例，这 个类可以保证没有其他实例被创建，并且它可以提供一个访问该实例的方法。其结 构如图2 1 ： s i n g l e t o n i n s t a n c e ：s i n g l e t o n s i n g l e t o n o + g e t l n s t a n c e 0 s i n g l e t o n 类定义了一个g e t l n s t a n c e 操作，允许 用户访问它的唯一实例。g e t l n s t a n c e 是一个静 态方法，主要负责创建自身的唯一的实例。 图2 i 单例模式类图 f i g 2 1s i n g l e t o np a t t e r nc l a s sd i a g r a m 单例模式有以下特点： 单例类只能有一个实例。 单例类必须自己创建自己的唯一实例。 单例类必须给其他对象提供这一实列。 一般当一种资源需要避免有多于一个对象读取的时候，此时应该使用单例模式。 1 0 第二章设计原则与设计模式 2 3 2a b s t r a c tf a c t o r y 模式 a b s t r a c tf a c t o r y 模式管理的是一系列对象的创建，a b s t r a c tf a c t o r y 模式“提供一 个创建一系列相关或相互依赖对象的接口，而无需指定他们具体类”。如图2 2 ： 图2 2 抽象工厂模式类图 f i g 2 2a b s t r a c tf a c t o r yp a t t e mc l a s sd i a g r a m 2 3 3a d a p t e r 模式 a d a p t e r 模式为了完成两个不同接口之间的转换，将两个接1 2 1 “包装 在一起。 a d a p t e r 模式使得原本由于接口而不能一起工作的那些类可以一起工作。系统数据与 行为正确，但接口不符时，我们应该考虑适配器模式。目的是使控制范围之外的一 个原有对象与某个接口匹配。其结构如图2 3 ： 图2 3 适配器模式类图 f i g 2 3a d a p t e rp a t t e mc l a s sd i a g r a m 基于设计模式的a s r s 调度系统框架的设计与实现 2 3 4c o m p o s i t e 模式 c o m p o s i t e 模式体现了对象间部分与整体之间的关系，因此，c o m p o s i t e 模式的 最佳方式莫过于树形图。从抽象类或接口为根节点开始，然后生枝发芽，形成枝节 点和叶节点。根节点作为一个统一接口，是整个结构的抽象，通过它模糊了枝节点 和叶节点的区别。枝节点下由于可以含叶节点和枝节点，因此代表了复合元素；叶 节点则代表的是单元素，单元素和复合元素因为具备了同样的抽象接口，使得调用 者可以将它们作为相同的对象来看待。组合模式使得用户对单个对象和组合对象的 使用具有一致性。其结构如图2 4 ： + d i s p b y ( d e p t h ：i n t ) c o m p o n e n t 组合中的对象声明接口，在适当的情况下， 实现所有的类共有接口的默认行为，声明 一个接口用于访问和管理c o m p o n e n t 自部件 + a d d ( c ：c o m p o n e n t ) + r e m o v e ( c ：c o m p o n e n t ) + d i s p l a y ( d e p t h ：i n t ) 2 3 5d e c r a t o r 模式 c o m p o s r e + a d d ( c ：c o m p o n e n t ) + r e m o v e ( c ：c o m p o n e n t ) + d i s p l a y ( d e p t h ：i n t ) 定义所有枝节点行为，用来存储子部件， 在c o m p o n e n t 接口中实现子部件有关 的操作，比如增加a d d 和删除r e m o v e 图2 4 组合模式类图 f i g 2 4c o m p o s i t ep a t t e r nc l a s sd i a g r a m d e c o r a t o r 模式的命名独具匠心，以“装饰 的含义生动形象地描绘了“动态地 给一个对象添加一些额外的职责”的意图，d e c o r a t o r 模式是结构型模式中的一种， 它充分利用了继承与聚合的优势，创造出无与伦比的设计美学。其结构如图2 5 ： 1 2 第二章设计原则与设计模式 2 3 6o b s e r v e r 模式 图2 5 装饰模式类图 f i g 2 5d e c r a t o rp a a e m c l a s sd i a g r a m 作为行为型模式的一种，o b s e r v e r 模式的关注中心不是对象的行为，而是两个或 多个相互协作类之间的依赖关系。称它为行为模式，原因是它通过某种行为来控制 这种依赖关系，并产生消息通知进而达到修改依赖的类的行为或状态的目的。 o b s e r v e r 模式的意图是定义对象间的一种一对多的依赖关系，让多个观察者对象同 时监听一个主题对象，当一个对象的状态发生改变时，所有依赖它的对象都能自动 得到通知并被自动更新。其结构如图2 6 ： s u b j e c t 它把所有对观察者对象的引用保存到一个 聚合一面每个主题可以有任何数量的观察者，抽 象主题可以提供一个接口可以注册和注销观察者对象 o b s e r v e r 类抽象观察者。为 所有的观察者定义一个接口 。在得到主题的通知是更新自已 c o n c r e t e s u b j e c t 具体主题，将 有关状态存入具体观察者对象 ；在具体主题内部发生改变时 ，通知所有注册的观察者 c o n c r e t e o b s e r v e r 具体观察者类实 现抽象观察者的接口以便使自 身状态与具体主题状态保持一致 图2 6 观察者模式类图 f i g 2 6o b s e r v e rp a t t e mc l a s sd i a g r a m 基于设计模式的a s r s 调度系统框架的设计与实现 2 4 如何选择设计模式 g o f 的设计模式一书中共介绍了2 3 中设计模式，当然设计模式不止2 3 种， 这些模式都是针对特定问题的前人解决问题的经验，在实际的开发中如何选择适当 的模式来解决我们的问题呢? 主要考虑以下几个方面： 考虑各种设计模式的功能意图。 研究模式的关联。 检查重构的原因。 考虑设计中的变化。 当然，模式并不是万能的，在我们的程序设计中过多或者强行的去搬用某一个 模式可能会起到事倍功半的效果。所以如何让模式发挥应有的效能还需要考虑具体 的情况，并不一定刻意的选用某一模式才是最适合的，多种模式的混合使用或者更 好一些，总之在合适的场景下运用适合的模式才是得当之举。 1 4 第三章软件框架及相关技术分析 第三章软件框架及相关技术分析 如果把软件技术做一个层次划分的话，软件框架及设计属于上层建筑，而像程序 设计语言、技术平台、数据管理技术、网络技术等，均在框架之下，属于基础。近 年来，随着计算机技术的不断发展与互联网技术的突飞猛进，基础尚且在剧烈变化 当中，上层建筑自然会摇摇晃晃，甚至赶不上趟。逐渐进行中的不断变化，不可能 不对软件架构设计产生影响，从而使得很多关于框架设计的思想迅速过时或者必须 调整。如果架构师们不能够充分重视实践，与时俱进，那么就有可能做出不合时宜 的设计。 软件系统的框架设计需要架构师以高屋建瓴的角度来看待问题。他们关注的不再 是每一个具体的类的定义，以及各个功能点的具体实现，而是整个系统中有关层次 的划分、模块的关系、系统的性能、数据安全以及事务处理。架构师必须对整个项 目的需求有通盘的考虑，并在领域专家的帮助下，深入业务流程与领域逻辑。当然， 要设计一个基于n e t 平台“基于设计模式的w s s 框架”还需要各种技术的支持。 3 1 软件框架技术 3 1 1 框架的定义 目前关于框架的定义有很多种，尚不能完全统一。m a r t i nf l o w l e r 给出的评价是： “软件业的人乐于做这样的事一找一些词汇，将它们引申到大量微妙而又相互矛盾 的含义中。一个最大的受害者就是框架这个词。很多人都试图给框架下个 定义，而这些定义本身却很难统一 【1 1 。使用比较多的定义是著名的软件设计大师们 b o o c h ；r u m b a u g h 和j a c o b s o n 教授提出的，框架是一个可实例化的、部分完成的软件 系统或子系统，它为一组系统或子系统定义了架构，并提供了构造系统的基本构造 块，还为实现特定功能定义了可调整点。在面向对象环境中，框架由抽象类和具体 类组成【2 0 】。 3 1 2 框架与架构 框架是一种特殊的软件