软件设计与体系结构第七章软件体系结构分隔与设计模课件.ppt
,软件体系结构风格与设计模式,前言,1、软件体系结构是软件工程的一个重要研究内容2、软件体系结构的设计是软件开发中的一个关键环节，是软件质量的重要保证。3、软件体系结构已经成为一个重要的研究方向和独立的 学科分支。4、软件体系结构对软件的总体结构进行清晰的描述和分析、并用它指导软件的后续开发。5、模式的本质：可解决一类问题并能重复使用的解决方案,基本概念,软件设计模式：广义定义：可解决一类软件问题并能重复使用的软件设计方案狭义定义：设计模式是对被用来在特定场景下解决一般设计问题的类和相互通信的对象的描述。是在类和对象的层次描述的可重复使用的软件设计问题解决方案。,基本概念,软件体系结构风格：是在构件和连接子的层次所描述的可重复使用的软件设计问题解决方案。,基本概念,二者的共性和区别：区别： 1、设计模式是在类和对象的层次描述问题， 粒度较小；2、体系结构风格是在构件和连接子的层次描 述问题，粒度较大。体系结构风格是广义 上的设计模式。,共性：都是可重复使用的软件设计问题解决方案,软件体系结构描述语言,软件体系结构描述语言Architectural Description Language，简称ADL是用来描述软件密集型系统的总体结构的语言，说明系统众多部件之间的结构关系。代表性的体系结构描述语言,WrightRapideDarwinUnicon,ACMEABC/ADLXYZ/ADLXADL,大部分结构描述语言都有构件、连接子、配置等概念,软件体系结构描述语言,Wright ADL构件（Component） 连接子（Connector） 端口（Ports） 构件规范（Component-spec） 计算（Computation） 配置（Configuration） 角色（Roles） 粘连（Glue） 实例（Instances） 联接（Attachments）,软件体系结构描述语言-Wright ADL,过程调用实例： 一个Caller类型的构件c通过D-C-connector类型的 连接子dc调用Definer类型的构件d,软件体系结构描述语言,调用实例的Wright体系结构描述,软件体系结构描述语言,GADL的元模型,图形化的体系结构描述语言GADL,软件体系结构描述语言,图形化的体系结构描述语言GADL,调用实例的GADL体系结构描述构件图,构件连接子端口角色,软件体系结构描述语言,调用实例的GADL体系结构描述类图,软件体系结构描述语言,一个图形化的体系结构描述语言GADL调用实例的GADL体系结构描述协议类图和顺序图,软件体系结构描述语言,GADL语言用构件图、类图、顺序图等方式描述系统的软件体系结构，对行为的描述GADL用顺序图，而Wright用进行代数CSP。,软件体系结构风格,在构件和连接子的层次上描述的可重复使用的软件设计问题解决方案。管道/过滤器风格层次风格客户/服务器风格,核心特征、应用场景、注意的问题,软件体系结构风格-管道/过滤器风格,实例剖析： 统计a.txt中单词的个数并打印出来：shell命令：“cat a.txt | wc -w | lpr”,1、cat命令输出a.txt的内容2、通过管道传给命令wc，统计输入流中单词的 个数并输出3、输出的单词数通过管道传给命令lpr，lpr将其 打印出来,软件体系结构风格-管道/过滤器风格,实例剖析：shell命令：“cat a.txt | wc -w | lpr”,软件体系结构风格-管道/过滤器风格,实例剖析：shell命令：“cat a.txt | wc -w | lpr”,WriteData协议类图和顺序图,软件体系结构风格-管道/过滤器风格,实例剖析：shell命令：“cat a.txt | wc -w | lpr”,ReadData协议类图和顺序图,软件体系结构风格-管道/过滤器风格,实例剖析： 打印a.txt中soft的个数“cat a.txt | grep -o soft | wc -w | lpr”,构件图,软件体系结构风格-管道/过滤器风格,特征：系统中构件之间通过数据流松散耦合。也就是说，构件之间的依赖仅仅是数据流，而不是通常的接口函数调用或消息传递。其他典型应用：编译器、信号处理等。其他说明：本模式在实现上可以有许多不同的变化，如主动与被动、多出口管道等。,软件体系结构风格-层次风格,实例剖析：数据库系统,软件体系结构风格-层次风格,实例剖析：数据库系统,数据库服务端口db,软件体系结构风格-层次风格,特征：从向外提供服务的构件出发，沿着连接关系递次搜索各构件和连接子，如果形成的拓扑结构是一个有向无圈图（典型情况下是一个线性结构），那么这个系统的体系结构风格就是层次式的。这种设计风格便于将复杂的系统进行分解；同时也便于构件替换：只要保持接口一致，就可以将某一层的软件替换掉，而不会影响到系统的其他部分。,软件体系结构风格-层次风格,其他典型应用：开放系统互联（OSI）七层网络模型、Windows NT操作系统的内核结构。,软件体系结构风格-层次风格,软件体系结构风格-层次风格,其他说明：优点是结构清晰、可替换性好、便于控制复杂性；但也有它的缺点，如效率低：分层结构中高层的数据要经过层层传递和转发，从而降低系统效率。,软件体系结构风格-客户/服务器风格,实例剖析：FTP系统,软件体系结构风格-客户/服务器风格,特征：从向外提供服务的构件出发，沿着连接关系递次搜索各构件和连接子，如果形成的拓扑结构是一棵倒置的树，那么这个系统的体系结构就是客户/服务器风格的。这种风格使得服务功能的实现很集中，便于系统实现，因而得到广泛使用。,软件体系结构风格-客户/服务器风格,其他典型应用：电子邮件系统、WWW系统、TELNET系统、CVS版本控制系统等,软件体系结构风格-客户/服务器风格,数据库服务器可以向多个浏览器实例提供服务、还可以向CVS系统提供服务。,软件体系结构风格-客户/服务器风格,其他说明：在客户/服务器风格的系统中，服务器是资源和计算的集中地，因此容易成为存储和计算瓶颈，实际应用中为了提高服务器的性能，可能要采用集群处理等办法。同时，这个特点也使得这类系统容易遭受拒绝服务（Deny Of Service）攻击，因此在设计和应用中要作针对性考虑。此外，在这种风格的系统中，服务器中往往要存储更多客户的状态信息，因此大量使用并发执行技术，如多进程、多线程等，这也就涉及到进程、线程的动态创建、调度、删除等问题。这些问题处理得好坏直接影响到服务器的性能。,设计模式,文献7-2中描述了23个设计模式，并将它们分为三种类型：创建型设计模式、结构型设计模式和行为型设计模式。,设计模式,Factory Method（工厂方法）Abstract Factory（抽象工厂）Singleton（单件）Composite（组合）Proxy（代理）Iterator（迭代器）Observer （观察者）,动机和实例、应用场合、结构、核心思想,设计模式-Factory Method,动机与实例：“龙珠”游戏,魔力管道： 弹球（pop） 制造球（Enchant）球,设计模式-Factory Method,动机与实例：“龙珠”游戏-设计1,球有多种，如皮球、钢球Ball抽象父类Ball无法被实例化？,设计模式-Factory Method,动机与实例：“龙珠”游戏-设计2,new Ball动作包装成虚函数MakeBallFactoryMethod在子类（描述各种魔力管道）中重新定义该虚函数,设计模式-Factory Method,适用场合：有一些实体（各种魔力管道），它们的结构和行为是相似的，且都包含一些相似的更小实体（各类球），但一个大实体内部的这些小实体都是同一类的（一种魔力管道内只有一种球）。此时，如果各类小实体的描述构成一个类层次，那么可使用Factory Method模式，将各类大实体也描述为一个类层次。,设计模式-Factory Method,结构：,设计模式-Factory Method,核心思想归纳：在父类中，将创建对象的操作包装为一个虚函数，在描述公共行为的过程中调用该函数；在子类中重定义该虚函数来定制创建的对象，从而间接定制公共行为。利用虚函数的多态机制，Factory Method模式使得父类可集中描述公共行为，而将特别行为（不同对象的创建）抽放于子类。,设计模式-Abstract Factory,动机与实例：魔力管道。 在前面的设计中，三个MakeBallFactoryMethod工厂方法散放在三个MagicPipe类中。为了降低复杂性，可以把所有的创建动作拆分出来单独考虑。 即：创建球的动作单独形成一个工厂类，专门创建对象。,设计模式-Abstract Factory,动机与实例：设计3,设计模式-Abstract Factory,动机与实例：设计4,不仅有球、还有盒子等小实体，抽象工厂类专门创建各种小实体,设计模式-Abstract Factory,动机与实例：设计5,混合管道和小实体,设计模式-Abstract Factory,适用场合：当需要创建一组多种风格的小实体、且具体创建方式又要灵活可调整时，可使用Abstract Factory模式，将公共的创建行为描述为一个抽象类，而将具体的创建方式用该抽象类的子类来描述。,设计模式-Abstract Factory,结构：,设计模式-Abstract Factory,核心思想归纳：为了提供灵活性，将需要创建的同一风格的一组小实体的一般特征提取出来，用一组抽象产品类来描述，同时将创建行为封装为一个抽象工厂类，提供通用的创建接口，而将各种具体的产品和具体的创建行为用抽象产品类和抽象工厂类的子类来描述。从而使得BigEntity和具体的产品特性和具体的创建行为隔离开来，既降低了耦合度，也使得灵活调整创建行为成为可能。,设计模式-Singleton,动机与实例：日志功能，在一个应用程序内部一般只需要一个日志实例即可。实现方案1,设计模式-Singleton,实现方案1,设计模式-Singleton,实现方案1,设计模式-Singleton,实现方案1：两个缺陷一般情况下（如果只有一个日志文件）只需要一个Log实例即可，但上述做法不能保证Log的实例只有一个，当多个实例设置相同的日志文件的时候，还可能引起冲突；这种做法使得g_log无论用到与否都要被创建。,设计模式-Singleton,实现方案2：使用Singleton模式,设计模式-Singleton,实现方案2：使用Singleton模式,设计模式-Singleton,实现方案2：使用Singleton模式,设计模式-Singleton,适用场合：当需要确保一个类最多只有一个实例时，使用本模式。,设计模式-Singleton,结构：设需要保证只有一个实例的类为Singleton，则类Singleton的定义为：,设计模式-Singleton,结构：类Singleton的实现为：,设计模式-Singleton,核心思想归纳：通过将一个类的构造函数设置为protected或private，可有效阻止从外部直接创建该类的实例；同时设置一个静态成员函数，以负责创建唯一的实例并向外提供访问接口。,设计模式-Composite,动机与实例：幻灯片制作软件。一张幻灯片上可以有各种图元对象：文本框、图形、图像、影片、声音等等。图元具有“递归组合”特性。,设计模式-Composite,适用场合：当需要描述的对象具有“递归组合”特征、且希望用户忽略基本对象与组合对象的区别时，适用本模式。结构：,设计模式-Composite,核心思想归纳：为基本对象和组合对象提供一个公共的抽象父类，以表示所有对象，并建立起从该抽象父类到组合对象类的聚集关联，从而间接建立起“递归组合”特性。,设计模式-Proxy,动机与实例：网络中间件。在这类程序中，实际工作的对象可能运行在远程的主机上，与客户端应用分别处于不同的地址空间。为了编程方便，在其中大量地使用了Proxy模式。建立一个Proxy对象：它与Server对象的接口是一样的，而且与Client对象位于同一台机器、同一地址空间中，所有发给它的操作请求最终都转发Server对象。给使Client对象的设计开发变得简单，就像本地编程一样，网络交互的许多细节则集中到Proxy对象的实现中。,设计模式-Proxy,适用场合：前面的例子中使用Proxy模式是为了屏蔽网络交互细节、透明进行远程访问，因此属于“远程代理”；还有一些场合是为了提高性能、降低开销，而设置一个“虚代理”，如文档文件中的图像代理，它只描述图像的位置、大小等基本信息，具体图像文件细节仅在需要时再创建一个真正的图像对象来描述；另外，当被访问对象的内部结构很复杂且需要进行智能的分析、决策和协调时，可使用“智能代理”来屏蔽这些智能决策的细节，如一个“订票”代理就是如此：它可根据多家航空公司的订票服务，智能选择一种符合用户要求的订票方案。,设计模式-Proxy,结构,设计模式-Proxy,核心思想归纳：构造一个具有相同接口的代理对象，然后将操作请求转发给真实对象，其目的是向客户隐藏“转发过程”的细节（如远程网络交互、智能决策、选择性转发等），提供对真实对象的透明访问。,设计模式-Iterator,动机与实例：支持遍历的列表设计。设计方案1,设计模式-Iterator,动机与实例：支持遍历的列表设计。设计方案1的问题：其一，这种设计只能描述一种遍历方式，如向前遍历或向后遍历，但不能同时描述多种遍历方式。或许，大家觉得只需要再向List里面增加一些表示遍历的接口函数和表示位置的成员变量即可，但这样一来众多关系不紧密的功能混放在一个类里，会使得内聚程度变低，容易导致类膨胀，同时也给函数命名等带来不便。其二，这种设计不支持在一个列表上同时进行多个相同类型的遍历（如都是向后遍历，只是对元素的处理方式不同），而这种情况可能出现在并行程序中。,设计模式-Iterator,设计方案2： 在一个列表上同时进行多个相同类型的遍历。 使用Iterator模式，将负责遍历的部分功能从List中分离出来，单独形成一个类ListIterator,设计模式-Iterator,设计方案2：在一个列表上同时进行多个相同类型的遍历,Class ListIteratorPrivate:const List *list;,ListIterator增加指向原列表的指针。因此，一个ListIterator实例记录了与列表的一次遍历相关的所有信息，通过定义ListIterator的多个实例变量，就可以在一个列表上同时进行多个相同类型的遍历。,设计模式-Iterator,设计方案3： 以多种方式遍历一个列表，再定义一个迭代器类型,设计模式-Iterator,适用场合：当需要以多种方式灵活地遍历一个聚合对象中的各个元素时，适用本模式。结构：,设计模式-Iterator,核心思想归纳：通过将与遍历有关的部分从聚合对象的描述中分离出来、单独成类，能够将遍历的状态信息用一个独立对象记录，从而可有效处理多种遍历和并发遍历。另外，本模式可与Factory Method模式配合使用，支持从聚合对象直接创建相应的聚合器。,设计模式-Observer,动机与实例：Word软件的“窗口拆分”功能。,设计模式-Observer,动机与实例：Word软件的“窗口拆分”功能。,设计模式-Observer,动机与实例：Word软件的“窗口拆分”功能。,设计模式-Observer,动机与实例：Word软件的“窗口拆分”功能。,设计模式-Observer,适用场合：如果对象之间存在一对多的数据依赖关系、且当被依赖对象的数据改变时所有依赖于它的对象都应得到通知并自动更新，那么可使用本模式。被依赖的对象称为发布者，负责发布数据并通知所有的订阅者（即依赖于该发布者的对象），以便订阅者与发布者的状态保持一致。前面的例子中，Document对象为发布者，而Window对象为订阅者。因此，本模式也称为发布-订阅（Publish-Subscribe）模式。订阅者也可称为观察者（Observer），它似乎在时刻观察发布者的状态，并及时更新自己。,设计模式-Observer,结构：,设计模式-总结、分类,总体来说设计模式分为三大类：创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。,设计模式-总结、原则,1、开闭原则（Open Close Principle）开闭原则就是说对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。所以一句话概括就是：为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类，后面的具体设计中我们会提到这点。2、里氏代换原则（Liskov Substitution Principle）里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。 里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。 LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。 From Baidu 百科3、依赖倒转原则（Dependence Inversion Principle）这个是开闭原则的基础，具体内容：真对接口编程，依赖于抽象而不依赖于具体。,设计模式-总结、原则,4、接口隔离原则（Interface Segregation Principle）这个原则的意思是：使用多个隔离的接口，比使用单个接口要好。还是一个降低类之间的耦合度的意思，从这儿我们看出，其实设计模式就是一个软件的设计思想，从大型软件架构出发，为了升级和维护方便。所以上文中多次出现：降低依赖，降低耦合。5、迪米特法则（最少知道原则）（Demeter Principle）为什么叫最少知道原则，就是说：一个实体应当尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立。6、合成复用原则（Composite Reuse Principle）原则是尽量使用合成/聚合的方式，而不是使用继承。,
