软件架构与设计模式

软件架构与设计模式第一页，共一百三十四页，编辑于2023年，星期四1.软件架构软件架构定义架构设计方法与过程软件架构的设计要点2.模式简介模式的定义模式的分类3.常用模式从混沌到结构分布式基础设施事件多路分离和分派接口分割组件分割4.典型面向服务的架构SOA目录2第二页，共一百三十四页，编辑于2023年，星期四1.软件架构第三页，共一百三十四页，编辑于2023年，星期四1.1架构定义软件体系结构通常被称为架构，指可以预制和可重构的软件框架结构，Garlan&Shaw模型的基本思想是：软件体系结构={构件(component)、连接件(connector)和约束(constrain)}：构件可以是一组代码，如程序的模块；也可以是一个独立的程序；连接件可以是过程调用、管道、远程过程调用(RPC)等，用于表示构件之间的相互作用；约束一般为对象连接时的规则，或指明构件连接的形式和条件，例如，上层构件可要求下层构件的服务，反之不行；两对象不得递规地发送消息；代码复制迁移的一致性约束；什么条件下此种连接无效等。4第四页，共一百三十四页，编辑于2023年，星期四架构定义软件架构不仅仅注重软件本身的结构和行为,还注重其他特性:使用,功能性,性能,弹性,重用,可理解性,经济和技术的限制及权衡。5第五页，共一百三十四页，编辑于2023年，星期四例:ACE的分层架构6第六页，共一百三十四页，编辑于2023年，星期四架构的范围软件架构—本门课程的主关注点。硬件架构—包括CPU,内存，硬盘，周边设备例如打印机，与连接这些元素的部分。组织架构—是一些关于商业进程，组织结构，规则和职责，与组织核心能力的部分。信息架构—包含组织好的信息结构。软件架构、硬件架构、组织架构和信息架构是全部系统架构的子结构。企业架构与系统架构很相似，包括硬件，软件，人员等。7第七页，共一百三十四页，编辑于2023年，星期四

企业架构师EA(EnterpriseArchitect)

的职责是决定整个公司的技术路线和技术发展方向。盖茨给自己的Title是首席软件架构师，实际上就是EA角色;

基础结构架构师IA(InfrastructureArchitect)

的工作是提炼和优化技术方面积累和沉淀形成的基础性的、公共的、可复用的框架和组件，这些是技术型公司传承下来的最宝贵的财富;

特定技术架构师TSA(Technology-SpecificArchitect)主要从事类似安全架构、存储架构等专项技术的规划和设计工作;

解决方案架构师SA(SolutionArchitect)的工作则专于解决方案的规划和设计，所谓解决方案，就是把产品、技术或理论，不断地进行组合，来创造出满足用户需求的选择。

软件架构师基本上是EA+TSA+IA,是程序员向上发展的道路,系统架构师实际上是SA+TSA，更着力于综合运用已有的产品和技术，来实现客户期望的需求。架构师分类8第八页，共一百三十四页，编辑于2023年，星期四1.2架构设计基本过程概念化阶段分析阶段架构设计阶段并行开发和测试阶段验收与交互阶段愿景需求架构可执行系统交付的系统9第九页，共一百三十四页，编辑于2023年，星期四架构设计基本过程分析阶段需求分析领域建模确定关键需求概念性架构设计细化架构验证架构架构设计阶段10第十页，共一百三十四页，编辑于2023年，星期四软件需求需求系统必须满足的情况或提供的能力.可以直接来自客户需要,也可以来自合同,标准,规范或其他有正规约束力的文档软件需求功能需求非功能需求质量属性约束运行期质量属性开发期质量属性11第十一页，共一百三十四页，编辑于2023年，星期四软件系统架构要素它是一个软件系统从整体到部分的最高层次的划分。一个系统通常是由组件组成的，而这些组件如何形成、相互之间如何发生作用，则是关于这个系统本身结构的重要信息。系统包括架构组件、连接器、任务流。架构组件是组成系统的核心“砖瓦”，而连接器则描述这些组件之间通讯的路径、通讯的机制、通讯的预期结果，任务流则描述系统如何使用这些组件和连接器完成某一项需求。它是建造一个系统所作出的最高层次的、以后难以更改的，商业的和技术的决定。这样的决定必定是有关系统设计成败的最重要决定，必须经过非常慎重的研究和考察。在决定时，要考虑独特的架构风格和恰当的架构模式。1.3软件架构的设计要素12第十二页，共一百三十四页，编辑于2023年，星期四软件架构的目标

可靠性（Reliable）。软件系统对于用户的商业经营和管理来说极为重要，因此软件系统必须非常可靠。

安全性（Secure）。软件系统所承担的交易的商业价值极高，系统的安全性非

常重要。

可扩展性（Scalable）。软件必须能够在用户的使用率、用户的数目增加很快的情况下，保持合理的性能，才能适应用户的市场扩展得可能性。

可定制化（Customizable）。同样的一套软件，可以根据客户群的不同和市场需求的变化进行调整。13第十三页，共一百三十四页，编辑于2023年，星期四软件架构的目标

可延伸性（Extensible）。在新技术出现的时候，一个软件系统应当允许导入新技术，从而对现有系统进行功能和性能的扩展；

可维护性（Maintainable）。软件系统的维护包括两方面：1。排除现有的错

误，2。将新的软件需求反映到现有系统中去。一个易于维护的系统可以有效

地降低技术支持的花费

客户体验（CustomerExperience）。软件系统必须易于使用。

市场时机（TimetoMarket）。软件用户要面临同业竞争，软件提供商也要面

临同业竞争。以最快的速度争夺市场先机非常重要。14第十四页，共一百三十四页，编辑于2023年，星期四软件架构的种类软件系统的逻辑架构图逻辑架构：软件系统中元件之间的关系，比如用户界面，数据库，外部系统接口，商业逻辑元件，等等15第十五页，共一百三十四页，编辑于2023年，星期四软件架构的种类物理架构：软件元件是怎样放到硬件上的软件系统的物理架构图16第十六页，共一百三十四页，编辑于2023年，星期四软件架构的种类系统架构：系统的非功能性特征，如可扩展性、可靠性、强壮性、灵活性、

性能等。系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识，是架

构设计工作中最为困难的工作。架构的两要素：元件划分和设计决定。元件划分

一个软件系统中的元件首先是逻辑元件。这些逻辑元件如何放到硬件上，以

及这些元件如何为整个系统的可扩展性、可靠性、强壮性、灵活性、性能等

做出贡献，是非常重要的信息。设计决定

进行软件设计需要做出的决定中，必然会包括逻辑结构、物理结构，以及它

们如何影响到系统的所有非功能性特征。这些决定中会有很多是一旦作出，

就很难更改的。17第十七页，共一百三十四页，编辑于2023年，星期四视图可以表示系统的整体设计，但构架与以下几个具体方面相关：

模型的结构，即组织模式，例如分层。

基本元素，即关键用例、主类、常用机制等，它们与模型中的各元素相对。几个关键场景，它们表示了整个系统的主要控制流程。

记录模块度、可选特征、产品线状况的服务。

构架视图在本质上是整体设计的抽象或简化，它们通过舍弃具体细节来突

出重要的特征。在考虑以下方面时，这些特征非常重要：

系统演进，即进入下一个开发周期。

在产品线环境下复用构架或构架的一部分。

评估补充质量，例如性能、可用性、可移植性和安全性。

向团队或分包商分配开发工作。

决定是否包括市售构件。

插入范围更广的系统。

构架重点

18第十八页，共一百三十四页，编辑于2023年，星期四2.模式Pattern19第十九页，共一百三十四页，编辑于2023年，星期四模式简介要素背景context问题problem作用力(约束)force解决方案solution20第二十页，共一百三十四页，编辑于2023年，星期四2.1模式定义POSA1的定义:Apatternforsoftwarearchitecturedescribesaparticularrecurringdesignproblemthatariseinspecificdesigncontexts,andpresentsawell-provengenericschemeforitssolution.Thesolutionschemeisspecifiedbyitsconstituentcomponents,theirrelationships,andthewaysinwhichtheycollaborate.21第二十一页，共一百三十四页，编辑于2023年，星期四模式的特性最佳实践的记录更高一级的抽象设计的公共词汇表记录软件架构的工具支持具有良好属性的软件构建与项目细节,实现方法,编程语言无关22第二十二页，共一百三十四页，编辑于2023年，星期四例子：简单的模式ExplicitInterface(显式接口)背景软件架构工作的主要关注点之一:有效恰当地表述组件接口问题一个组件代表一个自含的功能单位及其发布的使用契约.客户可以使用它来建立自己的功能,但是直接访问组件的完全实现,则会导致客户依赖组件的内部表示,最终增加了应用程序内部的耦合度作用力(force)客户只能依赖组件发布的接口,对实现的修改不能影响客户客户不倚赖组件的地理位置组件提供的方法对客户有意义,能有效正确使用将组件接口的声明与实现分离,只对客户曝露组件接口,同时隐藏实现和位置23第二十三页，共一百三十四页，编辑于2023年，星期四Method_Bmethod_AExplicitInterface

(显式接口)method_B_impmethod_A_imp客户接口实现多态分派组件24第二十四页，共一百三十四页，编辑于2023年，星期四误解与陷阱企图将所有软件开发活动和工件变成模式企图将每个新颖的和复杂的设计贴上模式的标签将模式看成一些固定不变的事物:如特定的类配置将模式看作编码指南有限或误解的模式词汇导致对给定问题使用了错误的模式企望机械应用模式就可以得到精致的架构25第二十五页，共一百三十四页，编辑于2023年，星期四误解与陷阱企图在需要新思想的软件开发中使用现成模式对模式如何起作用以及怎样起作用企望过高企图完全基于自动化工具使用模式将模式当作组件的简单集合认为基于模式的设计排斥或替代重构26第二十六页，共一百三十四页，编辑于2023年，星期四2.2模式分类按粒度分类架构,设计,惯用法按效果好坏分类模式,反模式按问题域(使用目的)分类(以分布式计算为例)从混沌到结构分布式基础设施事件多路分离和分派接口分割组件分割应用程序控制并发同步对象交互适配与扩展模态(modal)行为资源管理(对象生命周期管理)数据库访问27第二十七页，共一百三十四页，编辑于2023年，星期四3.常用模式28第二十八页，共一百三十四页，编辑于2023年，星期四常用模式从混沌到结构分布式基础设施事件多路分离和分派接口分割组件分割应用程序控制并发同步对象交互适配与扩展模态(modal)行为资源管理数据库访问29第二十九页，共一百三十四页，编辑于2023年，星期四3.1从混沌到结构30第三十页，共一百三十四页，编辑于2023年，星期四3.1从混沌到结构从混沌到结构将需求和约束转换为粗粒度的软件结构各部分定义清晰,可操作抽象与划分,忽略细节关注性能,持续可用性可扩展性,可维护性支持变化31第三十一页，共一百三十四页，编辑于2023年，星期四3.1从混沌到结构

领域建模满足应用领域的功能性需求,同时适应变化功能属性业务流程业务算法选择Domain

Model32第三十二页，共一百三十四页，编辑于2023年，星期四DomainModel(领域模型)背景为应用建立初始结构问题需求和约束只是隐含了功能,但还不能为应用提供直接具体的开发结构对系统范围和应用领域缺乏精确和合理的洞见,会使实现成为一团烂泥,难于理解,难于开发,不易交付作用力(force)需求列表只是应用的问题域,而不是解域,需要映射为软件实体建立一个模型,定义系统的业务职责范围以及可能的变化:模型元素是对应用领域的概念抽象,它们的角色和交互反映了应用领域的工作流33第三十三页，共一百三十四页，编辑于2023年，星期四从混沌到结构分解领域模型应用与环境怎样交互?应用怎样处理数据?应用支持什么变化?应用的预期生命周期如何?34第三十四页，共一百三十四页，编辑于2023年，星期四DomainModel(领域模型)内部划分数据流处理数据驱动处理系统演进用户界面变化功能变化远程通信DomainModelDomainObjectPipesandFiltersSharedRepositoryBlackboardLayersDatabaseAccessLayerModel-View-ControllerPresentationAbstraction-ControlMicrokernelReflectionBrokerMessagingPublisher-Subscriber35第三十五页，共一百三十四页，编辑于2023年，星期四Layers(分层)背景必须支持系统的不同部分独立开发和演进问题由于受系统大小,上市时间等需求约束,需要考虑系统不同部分的独立开发和演进如果系统架构不能清晰合理分离关注点,则各部分的交互得不到很好的支持,也不能独立开发作用力(force)如何寻求平衡,能够合理划分系统,使各部分可以独立开发和部署不陷于细节的泥淖对开发中的系统定义一个或多个层级,每一层都具有清晰特定的职责36第三十六页，共一百三十四页，编辑于2023年，星期四Layers(分层)Function1Function1Function1FunctionAFunctionBFunctionCFunctionXFunctionYFunctionZ接口实现Layer3Layer2Layer1典型应用:TCP/IP等通信协议37第三十七页，共一百三十四页，编辑于2023年，星期四Layers(分层)可沿不同维度指定分层的准则抽象,粒度,硬件距离,变化速度层数适当注意层中每个内聚的职责层内如何隔离变化控制和数据流可以在层间双向流动层间依赖关系是单向向下的:下层不能依赖上层的功能38第三十八页，共一百三十四页，编辑于2023年，星期四Layers:问题层内分解接口和实现分离

连接借口和实现自底向上层间通信Layers????什么模式可以提供解决方案?39第三十九页，共一百三十四页，编辑于2023年，星期四Model-View-Controller(MVC)背景要考虑应用的用户界面比领域功能变化快问题用户界面比应用的核心功能变化快,但界面的变化不能对核心功能造成不良影响作用力用户界面的改变应该容易,并局限于系统界面部分界面显示的内容要与内部状态一致，能立即响应内部状态的变化对支持多种skin外观的系统，每种skin的变化快慢不一样将交互式系统划分为解耦的三部分：处理，输入和输出．通过某种变化传播机制保证三部分状态的一致40第四十页，共一百三十四页，编辑于2023年，星期四Model-View-Controller(MVC)displayupdatedosomethingupdategetdatafunction2function1data1data2data3notifyUserInterfaceModelViewController1.invoke2.modify3.startchangenotification4.notify5.updatestateApplicationFunctionality41第四十一页，共一百三十四页，编辑于2023年，星期四Presentation-Abstraction-Control(PAC)背景有时要考虑应用的不同功能职责需要不同范式的用户界面问题通过一种界面如表单,菜单,对话框等,应用程序就可以提供人机交互,但是有时候某些应用程序需要对不同的功能提供不同范式的界面,以达到最佳的操作性作用力(force)比如在机器人控制系统中,定义某项任务和控制机器人完成该任务需要不同的用户界面,但是必须保证所有的功能及其对应的用户界面内聚一致某一界面的改变不能影响其对应的功能和其他功能-界面某一功能实现的改变也不能影响其对应的界面和其他的功能-界面将交互式应用划分为解耦的代理agents层级结构:一个顶层根代理,几个中间级代理,以及许多底层代理.每个代理完成应用的某项功能,并提供对应的用户界面42第四十二页，共一百三十四页，编辑于2023年，星期四Presentation-Abstraction-Control(PAC)dosomethingdisplaymediatefunction_2function_1PresentationControlAbstractiondosomethingdisplaymediatefunction_2function_1dosomethingdisplaymediatefunction_2function_1dosomethingdisplaymediatefunction_2function_1dosomethingdisplaymediatefunction_2function_1协调协调协调协调顶层PACAgent中间层PACAgent底层PACAgent43第四十三页，共一百三十四页，编辑于2023年，星期四MVCandPAC:问题用户界面分离视图种类控制器种类请求处理用户界面分离变化传播模型划分数据交换OS/库独立变化传播代理划分数据交换请求路由控制设计子系统设计Model-ViewControllerPresentationAbstractionControlDomainModel??????什么模式可以提供解决方案?44第四十四页，共一百三十四页，编辑于2023年，星期四Microkernel(微内核)背景设计支持不同部署环境下功能的可伸缩性和的适应性问题某些系统有多个版本,每个版本或者提供不同的功能集,或者在某一方面与前一版本不同.但是所有的版本应该基于共同的架构和核心功能作用力(force)避免架构在不同版本间产生漂移,使共享功能的开发和维护代价降到最小应用的版本升级不需要修改系统,或使修改降到最小方便地提供针对不同界面,不同平台的版本,以满足客户的环境提供一个公用的最小的核心架构.应用的不同版本通过一种即插即用的基础设施,在此架构上进行扩展.45第四十五页，共一百三十四页，编辑于2023年，星期四Microkernel(微内核)routerequestregister_svrunregister_svrfunction_1function_2function_3displaydosomethingfunction_2function_1function_3ExternalServer(GUI)ExternalServer(API)MicrokernelInternalServerSystemUser46第四十六页，共一百三十四页，编辑于2023年，星期四Microkernel:问题标准和可选功能分离微内核以及内部服务器划分微内核以及内部服务器划分数据交换外部服务器设计微内核配置请求路由MicrokernelLayers?????什么模式可以提供解决方案?47第四十七页，共一百三十四页，编辑于2023年，星期四Reflection(反射)背景提供一种设计,为预期之外变化的演进和集成做准备问题对长生命周期应用,支持变化是可持续演进架构的关键.但是通常很难预测什么会变化以及什么时候发生变化.作用力(force)变化可能在任何时候发生变化可能在任何尺度上发生对维护者隐藏变化的复杂性,提供统一的机制支持各种变化将属性,应用的结构、行为以及状态等的易变方面抽象为一组元对象.使用两层架构分离元对象和核心应用逻辑:元层次包含元对象,基本层包含应用逻辑.48第四十八页，共一百三十四页，编辑于2023年，星期四Reflection(反射)Userconfigureaspectconfigurepropertyproperty_1MetalobjectProtocolMaintaineraspect_2Metalobjectsdosomethingfunction_1UserInterfacefunction_1CoreApplicationLogicusesusesMetalLevelBaseLevel49第四十九页，共一百三十四页，编辑于2023年，星期四Reflection:问题监管控制与应用功能分离基本层以及元层的划分元层访问元对象生命周期管理ReflectionDomainModel???什么模式可以提供解决方案?50第五十页，共一百三十四页，编辑于2023年，星期四PipesandFilters(管道-过滤器)背景提供一种设计,使应用适合处理数据流问题某些应用需要处理数据流:输入数据逐级变换为输出数据流．使用通常的请求／应答式结构不可行，为此要建立一种数据流模型.作用力(force)系统的各部分对数据流执行明确的不同的动作有些时候需要显式访问中间数据结果数据流模型应该支持增量式读写和处理持续时间长的处理不应成为性能瓶颈将应用任务划分为几个自含的数据处理步骤,这些步骤通过其间的数据缓冲区连接成一个数据处理管道.51第五十一页，共一百三十四页，编辑于2023年，星期四inputPipesandFilters(管道-过滤器)bufferinputbufferinputInputDeviceOutputDeviceFilter1Pipe1Filter2Filter2PipeN-1FilterN52第五十二页，共一百三十四页，编辑于2023年，星期四PipesandFilters:问题层间通过数据流交互管道以及过滤器的划分远程通信数据交换PipesandFiltersDomainModel???什么模式可以提供解决方案?53第五十三页，共一百三十四页，编辑于2023年，星期四SharedRepository(共享仓库)背景提供一种设计,使应用的各部分操作一组共享数据,并通过共享数据进行协调问题某些应用本质上使数据驱动的:组件之间的交互不是通过特定的业务流程,而是依赖其所处理的数据.即便如此,仍然需要一种机制来控制这种交互.作用力(force)比如网络管理和控制系统,它们需要操作大量现场数据.其核心职责如监控,报警,汇报等相互独立,是数据状态决定了任务流程及其交互.将这些任务直接联系起来会导致硬编码的业务流程为所有数据维持一个中心仓库,以供各功能组件共享.数据的可用性,质量以及状态等触发和协调应用的控制流.54第五十四页，共一百三十四页，编辑于2023年，星期四SharedRepository(共享仓库)ApplicationComponentsfunction_1function_2function_3function_4SharedRepositoryOperateson55第五十五页，共一百三十四页，编辑于2023年，星期四Blackboard(黑板)背景提供一种设计,使应用在没有确定性解决方案的时候可以完成任务问题某些任务没有确定性算法,但是试误技术足够胜任,因此需要开发针对这种任务的软件产品.作用力(force)输入的数据模糊不精确需要探索各种方案路径,每个中间步骤都可能产生可选结果,通常不知道最佳解在合理的时间内,计算出有价值的解决方案运用启发式计算,通过多个具有确定性算法的组件,对假定的中间解决方案逐步改进.56第五十六页，共一百三十四页，编辑于2023年，星期四Blackboard(黑板)checkactivatecheckactivatecheckactivateIntermediateSolutionHypothesis1------------IntermediateSolutionHypothesis2----------IntermediateSolutionHypothesis3KnowledgeSourcesBlackboardrunControl1.1.2.1.1.确定最佳的知识源,以修改黑板中的数据2.激活选中的知识源,使之修改黑板中的数据57第五十七页，共一百三十四页，编辑于2023年，星期四Blackboard,SharedRepository:问题分离数据与功能分离数据与功能传播变化线程安全数据访问功能划分数据访问数据交换数据交换数据访问功能划分SharedRepositoryBlackboardDomainModel???什么模式可以提供解决方案?58第五十八页，共一百三十四页，编辑于2023年，星期四DomainObject(领域对象)背景所有设计的关键:分离应用职责,每个职责应自我包含,内聚问题组成软件的各部分具有复杂的相互作用,未经仔细设计会导致系统结构极其复杂作用力(force)关注点分离,适当合理的划分系统不同部分的实现和交互必须有效且高效,特别是关键属性如性能,错误处理以及安全性等将每个不同的功能封装进一个自我包含的构成块—DomainObject(领域对象)中59第五十九页，共一百三十四页，编辑于2023年，星期四DomainObject(领域对象)FunctionAFunctionBFunctionCFunctionZDomainObject1FunctionXFunctionYDomainObject2DomainObject3DomainObject4DomainObjectInterfaceDomainObjectImplementation60第六十页，共一百三十四页，编辑于2023年，星期四DomainObject(领域对象)分离接口和实现内部划分内部划分通用领域对象连接接口和实现生命周期控制领域对象配置DomainObjectDomainModelLayersModel-View-ControllerPresentationAbstractionControlMicrokernelReflectionPipesandFiltersSharedRepositoryBlackboard?????什么模式可以提供解决方案?61第六十一页，共一百三十四页，编辑于2023年，星期四3.2分布式基础设施62第六十二页，共一百三十四页，编辑于2023年，星期四分布式基础设施分布式基础设施软件是一种中间件(middleware)应用程序之下,操作系统和网络之上屏蔽来自不同操作系统和网络的固有复杂性和偶发复杂性固有复杂性:选择合适的通信机制,并设计良好的协议来有效使用这些机制设计合理的网络服务,以有效利用现有计算资源,并降低将来的维护成本有效使用并发机制,使系统获得可预计的,可靠的高性能管理和配置服务,以获得最大程度的系统可用性和灵活性63第六十三页，共一百三十四页，编辑于2023年，星期四偶发复杂性:缺乏类型安全,可移植,可扩充的原始OSAPI算法分解的广泛使用,无谓造成网络应用程序在维护和扩充上的困难网络应用中,核心概念和功能的不断发现和创造,造成软件生命周期的成本无谓地居高不下有各种中间件可供选择CORBA,.NetRemoting,theMicrosoftCommunicationFramework,JMS……了解这些中间件使用的设计模式,有助于选择正确的中间件这些中间件使用了三种基本的通信方式:messaging,publish/subscribe,remotemethodinvocation,基本上对应三种模式分布式基础设施64第六十四页，共一百三十四页，编辑于2023年，星期四分布式基础设施模式通信方式通信关系组件依赖性Broker(代理者)远程方法调用一对一组件接口Messaging(消息传递)消息多对一通讯终点,消息格式Publisher-Subscriber(发布者-订阅者)事件一对多事件格式65第六十五页，共一百三十四页，编辑于2023年，星期四Messaging(消息传递)背景需要一个通信的基础设施,将独立开发的服务组成一个统一的系统问题某些分布式系统是由独立开发的服务组成,这些服务必须可靠地交互,但又不能导致过紧的依赖关系作用力(force)集成现有的、独立的特定服务以构成企业级解决方案被集成的服务需要可靠地协调工作,但这些服务是独立开发的,并不知道彼此的功能接口每个服务可能要被多个集成环境使用,服务对不同的集成环境不能具有排他性将服务通过一个消息总线连接起来,并通过它异步传输数据消息.对消息编码,使发送者和接受者能够可靠地通信,而不需要知道数据的所有静态类型信息.66第六十六页，共一百三十四页，编辑于2023年，星期四Messaging(消息传递)MessageBusService1Service2Service3Service4datamsg1datamsg2datamsg3datamsg4关键应用:EnterpriseApplicationIntegration,ServiceOrientedArchitecture67第六十七页，共一百三十四页，编辑于2023年，星期四Messaging(消息传递)

Publisher-Subscriber(发布者-订阅者):问题进程间通信进程间通信数据转移数据封装数据格式转换数据路由错误通知MessagingPublisher-SubscriberDomainModel组件连接数据格式转换数据路由错误通知事件封装事件转移组件连接事件过滤???什么模式可以提供解决方案?68第六十八页，共一百三十四页，编辑于2023年，星期四Publisher-Subscriber(发布者-订阅者)背景需要一种通信基础设施,当某事件发生时,系统中感兴趣的组件可以彼此通告问题某些分布式系统是由松散耦合,基本独立的组件构成.如果这种系统需要在各组件间传播信息,则需要某种机制来通知各组件有关系统状态的变化,或其他事件,这些事件会影响各组件本身的计算或组件间的协调工作作用力(force)通告机制不能造成各组件的耦合过于紧密接收事件的那些组件只知道系统中有某个组件处于特定状态,但不关心具体是哪个组件处于该状态散布事件的组件也不关心哪个组件会接收它各组件不知道彼此的位置定义一种变化传播基础设施,发布者(publisher)通过它发布事件,其他发布者可能对该事件包含的信息感兴趣.事件发生时要告知对该事件感兴趣的订阅者(subscriber).69第六十九页，共一百三十四页，编辑于2023年，星期四ChangePropagationInfrastructurePublisher1Subscriber2Subscriber3Publisher2StatechangeStatechangeStatechangeStatechangePublisher-Subscriber(发布者-订阅者)应用:CORBANotificationService70第七十页，共一百三十四页，编辑于2023年，星期四Messaging(消息传递)

Publisher-Subscriber(发布者-订阅者):问题进程间通信进程间通信数据转移数据封装数据格式转换数据路由错误通知MessagingPublisher-SubscriberDomainModel组件连接数据格式转换数据路由错误通知事件封装事件转移组件连接事件过滤???什么模式可以提供解决方案?71第七十一页，共一百三十四页，编辑于2023年，星期四Broker(代理者)背景需要一种通信基础设施,以之屏蔽组件位置和进程间通信的复杂性问题分布式应用要面对许多单进程应用未有的挑战,但是应用不应该自己直接去处理这些挑战.应用应该使用模块化的编程模型,力求简化,以屏蔽网络连接和空间位置等细节作用力(force)将不同语言写的各类服务移植到不同的操作系统平台,是一项极其复杂的任务在何处以什么方式部署服务,也是一项复杂费力的事情服务之间通过方法调用的协作应该以一种与位置无关的方式进行使用代理者(broker)联盟封装分布式系统通信基础设施的细节,并与应用系统的功能分离.要定义一种基于组件的编程模型,以使客户应用调用远程服务的方法时就象在本地调用一样.72第七十二页，共一百三十四页，编辑于2023年，星期四method_1method_2Broker(代理者)sendreceiverequestdiscoverreceivesendinvokeregistermethod_1method_2clientClientProxyClient-sideBrokerServer-sideBrokerApplicationComponentDiscoverclientproxyRegistercomponentNetwork73第七十三页，共一百三十四页，编辑于2023年，星期四Broker(代理者):问题进程间通信BrokerDomainObject请求分派请求分派代理者访问组件访问组件访问发布-订阅通信组件创建内部划分OS抽象发出请求接收请求封装请求错误通知代理者配置组件发现??什么模式可以提供解决方案?74第七十四页，共一百三十四页，编辑于2023年，星期四3.3事件多路分离和分派分布式计算的核心:响应和处理来自网络的事件事件处理的复杂性:事件异步到达多个事件同时到达事件到达顺序不确定多种类型的事件隐藏事件多路分离和分派的复杂性事件处理软件通常采用Layers架构模式

事件源:

sockets事件多路分离器:WaitForMultipleObjects,select,etal事件处理器+应用程序75第七十五页，共一百三十四页，编辑于2023年，星期四事件多路分离和分派模式提供高效，可扩展，可复用解决方案Reactor(反应器)模式对事件执行同步多路分离并分派给应用程序Proactor(前摄器)模式对事件执行异步多路分离和分派,可获得并发处理的好处并规避其缺点Acceptor-Connector(接收器-连接器)模式将连接和初始化工作与其后的一般事件处理分离AsynchronousCompletionToken(异步完成令牌)模式对异步服务请求的响应提供高效的多路分离和处理76第七十六页，共一百三十四页，编辑于2023年，星期四Reactor(反应器)背景开发事件驱动应用时,需要将事件的检测,多路分离和分派等与处理时间短的服务分离问题事件驱动软件接受来自多个源的服务请求事件,并对之实行多路分离,分派给事件处理器做进一步处理.多个事件可能同时到达,但是为简化软件开发,这些事件需要顺序处理,并同步返回处理结果.作用力(force)高效灵活处理多个源的并发事件容易集成新的或改进的事件处理器提供一种事件处理基础设施,它可以同时等待多个源的服务请求事件,但是每次只分离一个事件,并将该事件分派给相应的事件处理器去执行对应的服务77第七十七页，共一百三十四页，编辑于2023年，星期四eventloopReactor(反应器)Aclientdemuxeventevent_loop()begin##runaninfiniteeventloopfor(ever)##blockwaitingforeventstooccurevent=demux_events();##dispatchtheeventhandler=identify_handler(event);handler.handle_event(event);rofendhandleeventhandleeventhandleeventEventhandlersStarteventprocessingReactorOperatingSystemSendservicerequestevent132478第七十八页，共一百三十四页，编辑于2023年，星期四Proactor(前摄器)背景开发事件驱动应用时,需要将事件的检测,多路分离和分派等与处理时间长的服务分离问题为获得高性能和高吞吐量,事件驱动软件需要同时处理多个事件,但是又不希望使用多线程作用力(force)对服务请求的处理不能延迟太久性能和吞吐量要最大化容易集成新的和改进的组件将应用程序功能分为异步操作和完成处理器两部分.异步操作针对事件源执行某些活动,而完成处理器使用异步操作的结果.异步操作和完成处理器共同实现应用的服务逻辑.异步操作由操作系统执行,而完成处理器在应用的控制线程中执行79第七十九页，共一百三十四页，编辑于2023年，星期四eventloopProactor(前摄器)Aclientdemuxeventhandle_event(Eventevent)begin##Processthereceivedeventif(event.type==Request)##readrequestasynchronously##andreturncontrolasync_read();

elseif(event.Type==READ_COMPLETE)##Processevent,deliverresults##asynchronously,andreturncontrolprocess_data();async_write();fiendhandleeventhandleeventCompletionhandlersStarteventprocessingProactorOperatingSystemSendservicerequestevent1324asyncwriteasyncread80第八十页，共一百三十四页，编辑于2023年，星期四Reactor(反应器),Proactor(前摄器):问题ReactorProactorServerRequestHandlerClientRequestHandler同步事件处理异步事件处理异步事件处理同步事件处理实现的变化实现的变化事件处理器类型事件处理器类型事件源封装事件源封装并发事件处理并发事件处理并发事件处理事件处理器分派完成处理器分派???什么模式可以提供解决方案?81第八十一页，共一百三十四页，编辑于2023年，星期四Acceptor-Connector(接受器-连接器)背景在面向连接的网络系统中实现事件处理器时,建立连接以及初始化事件处理器等基本活动需要与处理应用特定服务的功能分离问题网络系统中对等的事件处理器在执行其服务功能前需要先建立连接并初始化,建立连接以及初始化代码与其服务功能基本无关作用力(force)事件处理器服务的变化比连接建立和初始化策略的变化快事件处理器可能动态改变其在连接中的角色在网络系统中,将对等事件处理器的连接和初始化与之后执行的服务解耦82第八十二页，共一百三十四页，编辑于2023年，星期四connect134serviceinitAcceptor-Connector(接受器-连接器)acceptserviceinitconnectoracceptorServicehandlerConnect‘me’Passconnection3PassconnectionPerformwork2AcceptconnectionServicehandlerApeercomponentAnotherpeercomponent83第八十三页，共一百三十四页，编辑于2023年，星期四Acceptor-Connector(接受器-连接器):问题Acceptor-ConnectorServerRequestHandlerClientRequestHandlerProactor事件处理器类型Reactor事件处理器类型完成处理器类型创建服务处理器封装IPC机制管理事件处理器连接管理的变化并发服务处理器??84第八十四页，共一百三十四页，编辑于2023年，星期四AsynchronousCompletionToken

(异步完成令牌)背景在使用异步通信的系统中,需要高效地多路分离和处理对异步服务请求的响应问题客户端异步调用服务,其响应通过完成事件返回,并在客户端处理.客户端调用服务后不能被阻塞,客户端在完成事件到达时的状态与调用服务时的状态不同作用力(force)客户需要在合适的背景下处理异步响应客户判断如何处理异步响应的时间要尽可能短异步响应到达的顺序与请求发起的顺序可能不同客户在发起每个异步服务请求的同时,传输一个异步完成令牌,该令牌包含足够的信息,可以让客户知道如何处理服务完成后的返回结果85第八十五页，共一百三十四页，编辑于2023年，星期四dispatch134dispatchserviceAsynchronousCompletionToken

(异步完成令牌)Client2processresultasync_operationSendrequestReturnresponseDispatchresultProcessresultACTService86第八十六页，共一百三十四页，编辑于2023年，星期四AsynchronousCompletionToken

(异步完成令牌):问题AsynchronousCompletionTokenFuture未来通告完成处理器通告ProactorACT管理?87第八十七页，共一百三十四页，编辑于2023年，星期四3.4接口分割组件接口要告知客户其职责,提供的服务,以及使用契约利于客户正确有效地与之合作设计高质量的组件接口,需要解决的问题组件的职责与契约规范质量属性描述性和简单性松耦合和稳定性组件的分布性组件及其客户的异质性88第八十八页，共一百三十四页，编辑于2023年，星期四接口分割相关模式ExplicitInterface(显式接口)ExtensionInterface(扩展接口)IntrospectiveInterface(内省接口)DynamicInvocationInterface(动态调用接口)BusinessDelegate(业务代理)Proxy(代理)Façade(外观)CombinedMethod(组合方法)Iterator(迭代器)EnumerationMethod(枚举方法)BatchMethod(批处理方法)89第八十九页，共一百三十四页，编辑于2023年，星期四ExplicitInterface(显式接口)背景软件架构工作的主要关注点之一:有效恰当地表述组件接口问题一个组件代表一个自含的功能单位及其发布的使用契约.客户可以使用它来建立自己的功能,但是直接访问组件的完全实现,则会导致客户依赖组件的内部表示,最终增加了应用程序内部的耦合度作用力(force)客户只能依赖组件发布的接口,对实现的修改不能影响客户客户不倚赖组件的地理位置组件提供的方法对客户有意义,能有效正确使用将组件接口的声明与实现分离,只对客户曝露组件接口,同时隐藏实现和位置90第九十页，共一百三十四页，编辑于2023年，星期四Method_Bmethod_AExplicitInterface(显式接口)method_B_impmethod_A_impClientInterfaceImplementationPolymorphicdispatchComponent91第九十一页，共一百三十四页，编辑于2023年，星期四ExplicitInterface(显式接口):问题ExplicitInterfaceDomainObjectReactorProactorCommandInterceptorChainofResponsibilityIteratorBridgeCompositeObjectAdapterLayersDecoratorStrategyObserverCommandContainerActiveObjectVisitor接口设计接口类型参数封装同步访问安全访问执行方法序列生命周期管理聚合遍历???92第九十二页，共一百三十四页，编辑于2023年，星期四Proxy(代理)背景避免直接访问组件服务的实现问题客户组件访问并使用其他组件提供的服务.直接访问服务不实际或不可能:如要检查客户的访问权限，或者服务的实现位于远程服务器上作用力(force)组件的功能与任何“簿记”工作应该分离客户也不应该做这些“簿记”工作将组件所有簿记功能封装进一个代理中，客户通过代理而不是直接与组件通信93第九十三页，共一百三十四页，编辑于2023年，星期四method_AProxy(代理)method_A()begin##dopre-processing

comp:=load_comp_from_DB(compID)##callthemethodonthecomponent

comp.method_A_imp();##dopost-processingunload_comp_from_user_space(compID)endmethod_Bmethod_A_impmethod_B_impClientProxyComponentImplementation94第九十四页，共一百三十四页，编辑于2023年，星期四Proxy(代理)

RealSubject+Request()Subject+Request()

Proxy+Request()realSubjectRequest(){realSubject.Request()}

Client95第九十五页，共一百三十四页，编辑于2023年，星期四Proxy(代理):问题ProxyExplicitInterface接口类型接口适配代理类型??96第九十六页，共一百三十四页，编辑于2023年，星期四Facade(外观)背景访问一组组件,这些组件提供范围比较宽的服务问题复杂的服务通常由一组组件提供,其中每个组件都有自含的服务,如果客户为了获得复杂的服务必须显式保持各组件的相互关系,则客户会依赖于这些组件的内部结构作用力(force)客户通过单一的访问点访问一组相关组件,简化一般任务的调用和执行客户也可能只访问组中某个特定的组件客户还可能执行更复杂的任务,这些任务需要直接访问各个组件为一组组件指定一个单一访问点(facade),它对一般的服务请求起协调者的作用.客户也可以绕过它，执行特定的更复杂的服务请求97第九十七页，共一百三十四页，编辑于2023年，星期四method_Bmethod_AFaçade(外观)method_C_impmethod_A_impClient1Componentsmethod_CClient2Facade98第九十八页，共一百三十四页，编辑于2023年，星期四Facade(外观)

Facade99第九十九页，共一百三十四页，编辑于2023年，星期四Facade(外观):问题Facade接口类型整体实现外观类型ExplicitInterfaceBrokerComponentConfiguratorWhole-Part接口类型?100第一百页，共一百三十四页，编辑于2023年，星期四Iterator(迭代器)背景需要顺序访问组合对象的各元素,而不曝露对象的内部结构问题客户通常需要遍历聚合体中封装的每个元素.但是客户可能不希望依赖聚合体的内部结构,聚合体也不希望曝露其内部结构作用力(force)客户以最能满足其需要的特定顺序遍历聚合体并发访问:多个客户可能同时访问聚合体,单个客户的多个线程也可能同时访问将访问和遍历聚合体元素的策略对象化,建立迭代器对象.客户只能通过迭代器访问元素,迭代器必要时可以访问聚合体内部表示101第一百零一页，共一百三十四页，编辑于2023年，星期四nextcurrentIterator(迭代器)Clientemptyfindcreate_iteratorinsertAggregateinterfaceremovetraversalstateIteratorElementElement12Accesselement34513Obtainiterator2Requestelement4Returnelement5Returnelement102第一百零二页，共一百三十四页，编辑于2023年，星期四Iterator(迭代器)Aggregate+CreateIterator():IteratorIterator+First():Object+Next():Object+IsDone():boolean+CurrentItem():ObjectCreateIterator(){returnnewConcreteIterator(this)}ConcreteAggregate+CreateIterator():IteratorConcreteIterator+First():Object+Next():Object+IsDone():boolean+CurrentItem():Objectcreates

ClientIC,IP,IQ卡,统统告诉我密码!----天下无贼103第一百零三页，共一百三十四页，编辑于2023年，星期四Iterator(迭代器):问题Iterator聚合体遍历块访问生命周期管理CompositeEnumerationMethodExplicitInterfaceObjectManager健壮性???104第一百零四页，共一百三十四页，编辑于2023年，星期四3.5组件分割软件由定义良好的组件构成,每个组件通过接口提供特定的,内聚的的服务组件封装实现细节组件划分组件质量组件灵活性组件功能的分布单个组件的并发性良好封装面临的挑战105第一百零五页，共一百三十四页，编辑于2023年，星期四3.5组件分割相关模式EncapsulatedImplementation(封装实现)Whole-Part(部分-整体)Composite(组成)Master-Slave(主从)Half-ObjectPlusProtocol(半对象协议)ReplicatedComponentGroup(复制组件组)Flyweight(享元)106第一百零六页，共一百三十四页，编辑于2023年，星期四EncapsulatedImplementation(封装实现)背景实现组件接口问题组件通过接口提供服务,但是接口只是承诺,组件必须实现此承诺.组件的实现受许多假设,顾虑以及约束等接口不能反映的因素的影响作用力(force)组件实现受许多约束和需求影响,而组件使用者并不关心这些支持演化,并屏蔽对客户的影响确保所有组件的实现细节隐藏在接口后面,从而使客户与不同的实现或实现的特定部署解耦107第一百零七页，共一百三十四页，编辑于2023年，星期四Method_Bmethod_Amethod_B_impmethod_A_impClientInterfaceImplementationPolymorphicdispatchComponentEncapsulatedImplementation(封装实现)108第一百零八页，共一百三十四页，编辑于2023年，星期四组件实现适配与扩展EncapsulatedImplementationEncapsulatedImplementation(封装实现):问题DomainObjectLayersBridge同步访问组件表示分布式部署并发实现?????109第一百零九页，共一百三十四页，编辑于2023年，星期四Composite(组成)背景需要将部分-整体层级结构中的聚合对象与原子对象一致对待问题有时部分-整体层级结构由对象递归组合而成,这些对象支持相同的接口,但是客户对结构的具体布局和递归特性不感兴趣,而是统一对待各层对象作用力(force)需要在部分-整体布局中保持递归层级结构对象的重新布局不能影响客户增加新对象对原来类型的影响要最小声明一个组件接口,该接口的功能对部分-整体层级结构中的所有对象都适用.子类化该接口,以实现特定的对象以及它们的递归组合110第一百一十页，共一百三十四页，编辑于2023年，星期四methodComposite(组成)methodmethodClientCompositeObjectComponentInterfaceLeafObjectImplementsInterfaceMaintainspartsthatimplementtheinterface111第一百一十一页，共一百三十四页，编辑于2023年，星期四Composite(组成)

Leaf+Operation()Component+Add(component:Component):void+Remove(component:Component):boolean+GetChild(index:int):Component+Operation()

Composite+Add(component:Component):void+Remove(component:Component):boolean+GetChild(index:int):Component+Operation()children*

ClientOperation(){forallginchildreng.Operation()}112第一百一十二页，共一百三十四页，编辑于2023年，星期四Composite(组成):问题CompositeEncapsulatedImplementation内部结构DecoratorInterpreter元素访问组件表示?113第一百一十三页，共一百三十四页，编辑于2023年，星期四Flyweight(享元)背景需要有效支持大量细粒度对象问题应用程序使用了大量对象,造成很大的存储开销作用力(force)区分内部和外部状态应用程序不倚赖于对象标识应用共享技术支持大量细粒度的对象.内部状态存储于享元对象中,外部状态则由客户存储或计算114第一百一十四页，共一百三十四页，编辑于2023年，星期四Flyweight(享元)

ConcreteFlyweight+Operation(extrinsicState:)Flyweight+Operation(extrinsicState:)

FlyweightFactory+GetFlyweight(key:):FlyweightGetFlyweight(key){ifflyweights[key]exist{returnflyweights[key]}flyweights[key]=newFlyweightreturnflyweights[key]}

Client

UnsharedConcreteFlyweight+Operation(extrinsicState:)flyweights[key]1115第一百一十五页，共一百三十四页，编辑于2023年，星期四Flyweight(享元):问题Flyweight细粒度共享组件共享对象创建EncapsulatedImplementationCompositeStrategyState?116第一百一十六页，共一百三十四页，编辑于2023年，星期四4.典型面向服务的架构SOA117第一百一十七页，共一百三十四页，编辑于2023年，星期四服务包含