精华内容
下载资源
问答
  • 软件体系结构设计模式笔记

    千次阅读 2012-12-26 22:35:35
    软件体系结构设计模式笔记 第1章软件体系结构概述 ü SEI软件体系结构讨论群定义如下:一个程序/系统构件的结构,它们之间的相互关系,以及在设计交付的整个过程中的原则指导方针。 ü Mary ShawDavid ...

    软件体系结构与设计模式笔记

    第1章软件体系结构概述

    ü  SEI软件体系结构讨论群定义如下:一个程序/系统构件的结构,它们之间的相互关系,以及在设计和交付的整个过程中的原则和指导方针。

    ü  Mary Shaw和David Garlan认为软件体系结构包括构成系统的设计元素的描述,设计元素的交互,设计元素组合的模式,以及在这些模式中的约束。

    ü  软件体系结构包括构件(Component)、连接件(Connector)和约束(Constrain)或配置(Configuration)三大要素。

    ü  国内普遍接受的定义:软件体系结构包括构件、连接件和约束,它是可预制和可重构的软件框架结构。

    ü 构件是可预制和可重用的软件部件,是组成体系结构的基本计算单元或数据存储单元

    ü 连接件也是可预制和可重用的软件部件,是构件之间的连接单元

    ü 构件和连接件之间的关系用约束来描述

    ü  软件体系结构 = 构件 + 连接件 + 约束

    软件体系结构的优势容易理解、重用、控制成本、可分析性

    第2章软件体系结构风格

    w  软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。

    w  体系结构风格定义了一个系统家族,即一个体系结构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型,而这组约束指出系统是如何将这些构件和连接件组合起来的。

    w  体系结构风格反映了领域中众多系统所共有的结构和语义特性,并指导如何将各个模块和子系统有效地组织成一个完整的系统。

    w  数据流风格: 批处理序列; 管道/过滤器。

    w  调用/返回风格:主程序/子程序;面向对象风格;层次结构。

    w  独立构件风格:进程通讯;事件系统。

    w  虚拟机风格:解释器;基于规则的系统。

    w  仓库风格:数据库系统;超文本系统;黑板系统。

    w  过程控制环路

    C/S风格体系结构有三个主要组成部分:数据库服务器、客户应用程序和网络。

    B/S风格浏览器/Web服务器/数据库服务器。

    优点:C/S体系结构具有强大的数据操作和事务处理能力,模型思想简单,易于人们理解和接受。将大的应用处理任务分布到许多通过网络连接的低成本计算机上,以节约大量费用。

    缺点:开发成本较高、客户端程序设计复杂、信息内容和形式单一、用户界面风格不一,使用繁杂不利于推广使用、软件移植困难、软件维护和升级困难、新技术不能轻易应用

    优点:基于B/S体系结构的软件,系统安装、修改和维护全在服务器端解决。

    缺点:B/S体系结构缺乏对动态页面的支持能力,没有集成有效的数据库处理功能。

    B/S体系结构的系统扩展能力差,安全性难以控制。

    采用B/S体系结构的应用系统,在数据查询等响应速度上,要远远低于C/S体系结构。

    B/S体系结构的数据提交一般以页面为单位,数据的动态交互性不强,不利于在线事务处理(OLTP)应用。

    第3章软件需求与架构

    w  需求的基本概念

    ü  IEEE (1997)

    Ø (1)  用户解决问题或达到目标所需的条件或能力

    Ø (2)  系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力

    Ø (3)  一种反映上面(1)或(2)所描述的条件或能力的文档说明

    w  业务需求

    ü  反映组织机构或客户对系统、产品高层次的目标要求,通常问题定义本身就是业务需求

    w  用户需求

    ü  描述用户使用产品必须要完成什么任务,怎么完成的需求,通常是在问题定义的基础上进用户访谈、调查,对用户使用的场景进行整理,从而建立从用户角度的需求。

    w  系统需求

    ü  从系统的角度来说明软件的需求,包括用特性说明的功能需求、质量属性,以及其他非功能需求,还有设计约束等。

    w  非功能需求

    ü  指产品必须具备的属性或品质,如正确性、可靠性、性能、容错性和可扩展性等。

    w  功能需求

    ü  需求的主体,需求的本质

    ü  功能需求定义:系统必须完成的那些事,即为了向它的用户提供有用的功能,产品必须执行的动作

    w  设计约束

    获取需求的方法

    ü  面谈(访谈)

    ü  问卷调查

    ü  会议(需求讨论会、重点问题讨论会、业务专题讨论会、设计专题讨论会)

    ü  文档研究

    ü  任务示范(观察)

    ü  用例与角色扮演

    ü  原型设计(小规模试验)研究类似公司

    需求的层次化

    ü  业务级需求:包含客户或出资者要达到的业务目标、预期投资、工期要求,以及要符合哪些标准、对哪些遗留系统进行整合等约束条件。

    ü  用户级需求:用户使用系统来辅助完成哪些工作?对质量有何要求?用户群及所处的使用环境方面有何特殊要求?

    ü  开发级需求:开发人员需要实现什么?开发期间、维护期间有何质量考虑?开发团队的哪些情况会反过来影响架构?

    需求分类

    ü  功能需求:更多体现各级直接目标要求

    ü  质量属性:运行期质量 + 开发期质量

    ü  约束需求:业务环境因素 +使用环境因素 + 构建环境因素+ 技术环境因素

    ü  功能模型——如UC

    ü  业务流程模型——如DFD

    ü  数据建模模型——如ER

    w  用例建模(Use CaseModeling)是使用用例的方法来描述系统的功能需求的过程,用例建模促进并鼓励了用户参与,这是确保项目成功的关键因素之一。

    粒度原则:

           用例要有路径,路径要有步骤。而这一切都是“可观测”的。

    ü  需求跟踪的目的是建立与维护“需求-设计-编程-测试”之间的一致性,确保所有的工作成果符合用户需求。

    w  外部质量对于用户而言是可见的包括正确性、健壮性、可靠性、性能、安全性、易用性、兼容性等。

    w  内部质量只有开发人员关心它们可以帮助开发人员实现外部质量包括易理解性、可测试性、可维护性、可扩展性、可移植性、可复用性等

    ü  依赖注入

    w 构造注入(Constructor Injection):通过构造函数注入实例变量。

    w 设值注入(Setter Injection):通过Setter方法注入实例变量。

    w 接口注入(Interface Injection):通过接口方法注入实例变量。

    1.        用例文档

    用例编号

    用例名

    执行者

    前置条件

    后置条件

    涉众利益

    基本路径      

    ü  1…..××××

    ü  2……××××

    ü  3…..××××

    2.        需求规格说明书

     

    第1章_统一建模语言基础知识

    a)        视图(View)

                            i.             用户视图:以用户的观点表示系统的目标,它是所有视图的核心,该视图描述系统的需求。

                          ii.             结构视图:表示系统的静态行为,描述系统的静态元素,如包、类与对象,以及它们之间的关系。

                         iii.             行为视图:表示系统的动态行为,描述系统的组成元素如对象在系统运行时的交互关系。

                         iv.             实现视图:表示系统中逻辑元素的分布,描述系统中物理文件以及它们之间的关系。

                          v.             环境视图:表示系统中物理元素的分布,描述系统中硬件设备以及它们之间的关系。

    用例图(Use Case Diagram): 又称为用况图,对应于用户视图。在用例图中,使用用例来表示系统的功能需求,用例图用于表示多个外部执行者与系统用例之间以及用例与用例之间的关系。用例图与用例说明文档(Use Case Specification)是常用的需求建模工具,也称之为用例建模。

    类图(Class Diagram):对应于结构视图。类图使用类来描述系统的静态结构,类图包含类和它们之间的关系,它描述系统内所声明的类,但它没有描述系统运行时类的行为。

    w  类之间的关系

    ü  关联关系

    •      关联关系(Association)是类与类之间最常用的一种关系,它是一种结构化关系,用于表示一类对象与另一类对象之间有联系。

    •      双向关联

    •      单向关联

    •      自关联

    •      重数性关联

    ü  聚合关系

    •      聚合关系(Aggregation)表示一个整体与部分的关系。通常在定义一个整体类后,再去分析这个整体类的组成结构,从而找出一些成员类,该整体类和成员类之间就形成了聚合关系。

    ü  组合关系

    •      组合关系(Composition)也表示类之间整体和部分的关系,但是组合关系中部分和整体具有统一的生存期。一旦整体对象不存在,部分对象也将不存在,部分对象与整体对象之间具有同生共死的关系。

    ü  依赖关系

    •      依赖关系(Dependency)是一种使用关系,特定事物的改变有可能会影响到使用该事物的其他事物,在需要表示一个事物使用另一个事物时使用依赖关系。大多数情况下,依赖关系体现在某个类的方法使用另一个类的对象作为参数。

    ü  泛化关系

    •      泛化关系(Generalization)也就是继承关系,也称为“is-a-kind-of”关系,泛化关系用于描述父类与子类之间的关系,父类又称作基类或超类,子类又称作派生类。在UML中,泛化关系用带空心三角形的直线来表示。

    ü  接口与实现关系

    •      接口之间也可以有与类之间关系类似的继承关系和依赖关系,但是接口和类之间还存在一种实现关系(Realization),在这种关系中,类实现了接口,类中的操作实现了接口中所声明的操作。在UML中,类与接口之间的实现关系用带空心三角形的虚线来表示。

    w  顺序图定义

    ü  顺序图(SequenceDiagram)是一种强调对象间消息传递次序的交互图,又称为时序图或序列图。

    w  状态图定义

    ü  状态图(StatechartDiagram)用来描述一个特定对象的所有可能状态及其引起状态转移的事件。

     

    第2章_面向对象设计原则

    w  单一职责原则要求在软件系统中,一个类只负责一个功能领域中的相应职责。

    w  开闭原则要求一个软件实体应当对扩展开放,对修改关闭,即在不修改源代码的基础上扩展一个系统的行为。

    w  里氏代换原则可以通俗表述为在软件中如果能够使用基类对象,那么一定能够使用其子类对象。

    w  依赖倒转原则要求抽象不应该依赖于细节,细节应该依赖于抽象;要针对接口编程,不要针对实现编程。

    w  接口隔离原则要求客户端不应该依赖那些它不需要的接口,即将一些大的接口细化成一些小的接口供客户端使用。

    w  合成复用原则要求复用时尽量使用对象组合,而不使用继承。

    w  迪米特法则要求一个软件实体应当尽可能少的与其他实体发生相互作用。

    第3章_设计模式概述

    w  设计模式的定义

    ü  设计模式(DesignPattern)是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结,使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。

    ü  设计模式一般有如下几个基本要素:模式名称、问题、目的、解决方案、效果、实例代码和相关设计模式,其中的关键元素包括以下四个方面:

    w 模式名称(Pattern name)

    w 问题(Problem)

    w 解决方案(Solution)

    w 效果(Consequences)

     

    范围\目的

    创建型模式

    结构型模式

    行为型模式

    类模式

    工厂方法模式

    (类)适配器模式

    解释器模式

    模板方法模式

    对象模式

    抽象工厂模式

    建造者模式

    原型模式

    单例模式

    (对象)适配器模式

    桥接模式

    组合模式

    装饰模式

    外观模式

    享元模式

    代理模式

    职责链模式

    命令模式

    迭代器模式

    中介者模式

    备忘录模式

    观察者模式

    状态模式

    策略模式

    访问者模式

     

     

    第4章_简单工厂模式

    ü  简单工厂模式(SimpleFactory Pattern):又称为静态工厂方法(Static Factory Method)模式,它属于类创建型模式。在简单工厂模式中,可以根据参数的不同返回不同类的实例。简单工厂模式专门定义一个类来负责创建其他类的实例,被创建的实例通常都具有共同的父类。

    ü  重构后的代码:

    public abstract class AbstractPay

    {

      public abstract void pay();

    }

    public class CashPay extends AbstractPay

    {

       public void pay()

        {

           //现金支付处理代码

        }

    }

    public class PayMethodFactory

    {

       public static AbstractPay getPayMethod(String type)

        {

           if(type.equalsIgnoreCase("cash"))

           {

               return new CashPay();       //根据参数创建具体产品

            }

            elseif(type.equalsIgnoreCase("creditcard"))

           {

               return new CreditcardPay();   //根据参数创建具体产品

           }

           ……

        }

    }

    ü  简单工厂模式最大的缺点是当有新产品要加入到系统中时,必须修改工厂类,加入必要的处理逻辑,这违背了“开闭原则”。

    ü  简单工厂模式最大的优点在于实现对象的创建和对象的使用分离,将对象的创建交给专门的工厂类负责,但是其最大的缺点在于工厂类不够灵活,增加新的具体产品需要修改工厂类的判断逻辑代码,而且产品较多时,工厂方法代码将会非常复杂。

    ü  简单工厂模式适用情况包括:工厂类负责创建的对象比较少;客户端只知道传入工厂类的参数,对于如何创建对象不关心。

     

    第5章_工厂方法模式

    ü  工厂方法模式(FactoryMethod Pattern)又称为工厂模式,也叫虚拟构造器(Virtual Constructor)模式或者多态工厂(PolymorphicFactory)模式,它属于类创建型模式。在工厂方法模式中,工厂父类负责定义创建产品对象的公共接口,而工厂子类则负责生成具体的产品对象,这样做的目的是将产品类的实例化操作延迟到工厂子类中完成,即通过工厂子类来确定究竟应该实例化哪一个具体产品类。

    ü  抽象工厂类代码:

    public abstract class PayMethodFactory

    {

       public abstract AbstractPay getPayMethod();

    }

    ü  具体工厂类代码:

    public class CashPayFactory extendsPayMethodFactory

    {

       public AbstractPay getPayMethod()

        {

           return new CashPay();

        }

    }

    ü  客户类代码片段:

    PayMethodFactory factory;

    AbstractPay payMethod;

    factory=new CashPayFactory();

    payMethod =factory.getPayMethod();

    payMethod.pay();

    ü  工厂方法模式的主要优点是增加新的产品类时无须修改现有系统,并封装了产品对象的创建细节,系统具有良好的灵活性和可扩展性;其缺点在于增加新产品的同时需要增加新的工厂,导致系统类的个数成对增加,在一定程度上增加了系统的复杂性。符合开闭原则。

    ü  工厂方法模式适用情况包括:一个类不知道它所需要的对象的类;一个类通过其子类来指定创建哪个对象;将创建对象的任务委托给多个工厂子类中的某一个,客户端在使用时可以无须关心是哪一个工厂子类创建产品子类,需要时再动态指定。

     

    第6章_抽象工厂模式

    ü  抽象工厂模式(AbstractFactory Pattern):提供一个创建一系列相关或相互依赖对象的接口,而无须指定它们具体的类。抽象工厂模式又称为Kit模式,属于对象创建型模式。

    ü  具体工厂类的典型代码如下:

    public class ConcreteFactory1 extendsAbstractFactory

    {

       public AbstractProductA createProductA()

        {

           return new ConcreteProductA1();

        }

       public AbstractProductB createProductB()

        {

           return new ConcreteProductB1();

        }

    }

    ü  抽象工厂模式的主要优点是隔离了具体类的生成,使得客户并不需要知道什么被创建,而且每次可以通过具体工厂类创建一个产品族中的多个对象,增加或者替换产品族比较方便,增加新的具体工厂和产品族很方便;主要缺点在于增加新的产品等级结构很复杂,需要修改抽象工厂和所有的具体工厂类,对“开闭原则”的支持呈现倾斜性。

    ü  抽象工厂模式适用情况包括:一个系统不应当依赖于产品类实例如何被创建、组合和表达的细节;系统中有多于一个的产品族,而每次只使用其中某一产品族;属于同一个产品族的产品将在一起使用;系统提供一个产品类的库,所有的产品以同样的接口出现,从而使客户端不依赖于具体实现。

     

    第9章_单例模式

    ü  单例模式(SingletonPattern):单例模式确保某一个类只有一个实例,而且自行实例化并向整个系统提供这个实例,这个类称为单例类,它提供全局访问的方法。

    ü  单例模式的要点有三个:一是某个类只能有一个实例;二是它必须自行创建这个实例;三是它必须自行向整个系统提供这个实例。单例模式是一种对象创建型模式。单例模式又名单件模式或单态模式。

     

    ü  单例模式的实现代码如下所示:

    public class Singleton

    {

             privatestatic Singleton instance=null;  //静态私有成员变量

             //私有构造函数

             privateSingleton()

             {       

             }

            

          //静态公有工厂方法,返回唯一实例

             publicstatic Singleton getInstance()

             {

                       if(instance==null)

                           instance=new Singleton();      

                       returninstance;

             }

    }

    ü  单例模式的主要优点在于提供了对唯一实例的受控访问并可以节约系统资源;其主要缺点在于因为缺少抽象层而难以扩展,且单例类职责过重。

    ü  单例模式适用情况包括:系统只需要一个实例对象;客户调用类的单个实例只允许使用一个公共访问点。

    ü  饿汉式单例与懒汉式单例类比较

    ü 饿汉式单例类在自己被加载时就将自己实例化。单从资源利用效率角度来讲,这个比懒汉式单例类稍差些。从速度和反应时间角度来讲,则比懒汉式单例类稍好些。

    ü 懒汉式单例类在实例化时,必须处理好在多个线程同时首次引用此类时的访问限制问题,特别是当单例类作为资源控制器,在实例化时必然涉及资源初始化,而资源初始化很有可能耗费大量时间,这意味着出现多线程同时首次引用此类的机率变得较大,需要通过同步化机制进行控制。

     

     

    第10章_适配器模式

    ü  适配器模式(AdapterPattern) :将一个接口转换成客户希望的另一个接口,适配器模式使接口不兼容的那些类可以一起工作,其别名为包装器(Wrapper)。适配器模式既可以作为类结构型模式,也可以作为对象结构型模式。

    ü  典型的类适配器代码:

    public class Adapter extendsAdaptee implements Target

    {

             publicvoid request()

             {

                       specificRequest();

             }

    }

    ü  典型的对象适配器代码:

    public class Adapter extends Target

    {

             privateAdaptee adaptee;

            

             publicAdapter(Adaptee adaptee)

             {

                       this.adaptee=adaptee;

             }

            

             publicvoid request()

             {

                       adaptee.specificRequest();

             }

    }

    类适配器

    对象适配器

    ü  适配器模式的主要优点是将目标类和适配者类解耦,增加了类的透明性和复用性,同时系统的灵活性和扩展性都非常好,更换适配器或者增加新的适配器都非常方便,符合“开闭原则”;类适配器模式的缺点是适配器类在很多编程语言中不能同时适配多个适配者类,对象适配器模式的缺点是很难置换适配者类的方法。

    ü  适配器模式适用情况包括:系统需要使用现有的类,而这些类的接口不符合系统的需要;想要建立一个可以重复使用的类,用于与一些彼此之间没有太大关联的一些类一起工作。

     

    第14章_外观模式

    ü  外观模式(FacadePattern):外部与一个子系统的通信必须通过一个统一的外观对象进行,为子系统中的一组接口提供一个一致的界面,外观模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。外观模式又称为门面模式,它是一种对象结构型模式。

    外观模式也是“迪米特法则”

    ü  典型的外观角色代码:

    public class Facade

    {

        private SubSystemA obj1 =new SubSystemA();

        private SubSystemB obj2 =new SubSystemB();

        private SubSystemC obj3 =new SubSystemC();

        public void method()

        {

            obj1.method();

            obj2.method();

            obj3.method();

        }

    }

    w  外观模式主要优点在于对客户屏蔽子系统组件,减少了客户处理的对象数目并使得子系统使用起来更加容易,它实现了子系统与客户之间的松耦合关系,并降低了大型软件系统中的编译依赖性,简化了系统在不同平台之间的移植过程;其缺点在于不能很好地限制客户使用子系统类,而且在不引入抽象外观类的情况下,增加新的子系统可能需要修改外观类或客户端的源代码,违背了“开闭原则”。

    w  外观模式适用情况包括:要为一个复杂子系统提供一个简单接口;客户程序与多个子系统之间存在很大的依赖性;在层次化结构中,需要定义系统中每一层的入口,使得层与层之间不直接产生联系。

     

    第16章_代理模式

    ü  代理模式(ProxyPattern) :给某一个对象提供一个代理,并由代理对象控制对原对象的引用。代理模式的英文叫做Proxy或Surrogate,它是一种对象结构型模式。

     

    ü  典型的代理类实现代码:

    public class Proxy implements Subject

    {

        private RealSubjectrealSubject = new RealSubject();

        public void preRequest()

        {…...}

        public void request()

        {

            preRequest();

            realSubject.request();

            postRequest();

        }

        public void postRequest()

        {……}

    }

    ü  代理模式的优点在于能够协调调用者和被调用者,在一定程度上降低了系统的耦合度;其缺点在于由于在客户端和真实主题之间增加了代理对象,因此有些类型的代理模式可能会造成请求的处理速度变慢,并且实现代理模式需要额外的工作,有些代理模式的实现非常复杂。

    ü  模式适用环境

    ü  根据代理模式的使用目的,代理模式有以下几种类型(续):

    ü 保护(Protect or Access)代理:控制对一个对象的访问,可以给不同的用户提供不同级别的使用权限。

    ü 缓冲(Cache)代理:为某一个目标操作的结果提供临时的存储空间,以便多个客户端可以共享这些结果。

    ü 防火墙(Firewall)代理:保护目标不让恶意用户接近。

    ü 同步化(Synchronization)代理:使几个用户能够同时使用一个对象而没有冲突。

    ü 智能引用(Smart Reference)代理:当一个对象被引用时,提供一些额外的操作,如将此对象被调用的次数记录下来等。

     

    第23章_观察者模式

    ü  观察者模式(ObserverPattern):定义对象间的一种一对多依赖关系,使得每当一个对象状态发生改变时,其相关依赖对象皆得到通知并被自动更新。观察者模式又叫做发布-订阅(Publish/Subscribe)模式、模型-视图(Model/View)模式、源-监听器(Source/Listener)模式或从属者(Dependents)模式。观察者模式是一种对象行为型模式。

     

    ü  典型的抽象目标类代码如下所示:

    import java.util.*;

    public abstract class Subject

    {

        protectedArrayList observers = new ArrayList();

             publicabstract void attach(Observer observer);

             publicabstract void detach(Observer observer);

             publicabstract void notify();

    }

    ü  典型的具体目标类代码如下所示:

    public class ConcreteSubject extendsSubject

    {

             publicvoid attach(Observer observer)

             {

                       observers.add(observer);

             }

            

             publicvoid detach(Observer observer)

             {

                       observers.remove(observer);

             }

            

             publicvoid notify()

             {

                       for(Objectobs:observers)

                       {

                                ((Observer)obs).update();

                       }

             }       

    }

    ü  典型的抽象观察者代码如下所示:

    public interface Observer

    {

             publicvoid update();

    }

    ü  典型的具体观察者代码如下所示:

    public class ConcreteObserver implementsObserver

    {

             publicvoid update()

             {

                       //具体更新代码

             }

    }

    ü  客户端代码片段如下所示:

    Subject subject = new ConcreteSubject();

    Observer observer = new ConcreteObserver();

    subject.attach(observer);

    subject.notify();

    w  观察者模式的主要优点在于可以实现表示层和数据逻辑层的分离,并在观察目标和观察者之间建立一个抽象的耦合,支持广播通信;其主要缺点在于如果一个观察目标对象有很多直接和间接的观察者的话,将所有的观察者都通知到会花费很多时间,而且如果在观察者和观察目标之间有循环依赖的话,观察目标会触发它们之间进行循环调用,可能导致系统崩溃。

    w  观察者模式适用情况包括:一个抽象模型有两个方面,其中一个方面依赖于另一个方面;一个对象的改变将导致其他一个或多个对象也发生改变,而不知道具体有多少对象将发生改变;一个对象必须通知其他对象,而并不知道这些对象是谁;需要在系统中创建一个触发链。

     

     

    ü  组合模式(CompositePattern):组合多个对象形成树形结构以表示“整体-部分”的结构层次。组合模式对单个对象(即叶子对象)和组合对象(即容器对象)的使用具有一致性。

    ü  Composite Pattern: Compose objects into tree structures to representpart-whole hierarchies. Composite lets clients treat individual objects andcompositions of objects uniformly.

    ü  组合模式的主要优点在于可以方便地对层次结构进行控制,客户端调用简单,客户端可以一致的使用组合结构或其中单个对象,用户就不必关心自己处理的是单个对象还是整个组合结构,简化了客户端代码;其缺点在于使设计变得更加抽象,且增加新构件时可能会产生一些问题,而且很难对容器中的构件类型进行限制。

    ü  组合模式适用情况包括:需要表示一个对象整体或部分层次;让客户能够忽略不同对象层次的变化,客户端可以针对抽象构件编程,无须关心对象层次结构的细节;对象的结构是动态的并且复杂程度不一样,但客户需要一致地处理它们。

    ü  命令模式(CommandPattern):将一个请求封装为一个对象,从而使我们可用不同的请求对客户进行参数化;对请求排队或者记录请求日志,以及支持可撤销的操作。命令模式是一种对象行为型模式,其别名为动作(Action)模式或事务(Transaction)模式。

    ü  Command Pattern: Encapsulate a request as an object, thereby lettingyou parameterize clients with different requests, queue or log requests, andsupport undoable operations.

    ü  命令模式的主要优点在于降低系统的耦合度,增加新的命令很方便,而且可以比较容易地设计一个命令队列和宏命令,并方便地实现对请求的撤销和恢复;其主要缺点在于可能会导致某些系统有过多的具体命令类。

    ü  命令模式适用情况包括:需要将请求调用者和请求接收者解耦,使得调用者和接收者不直接交互;需要在不同的时间指定请求、将请求排队和执行请求;需要支持命令的撤销操作和恢复操作;需要将一组操作组合在一起,即支持宏命令。

     

    ü  迭代器模式(IteratorPattern) :提供一种方法来访问聚合对象,而不用暴露这个对象的内部表示,其别名为游标(Cursor)。迭代器模式是一种对象行为型模式。

    ü  Iterator Pattern: Provide a way to access the elements of an aggregateobject sequentially without exposing its underlying representation.

    ü  迭代器模式的主要优点在于它支持以不同的方式遍历一个聚合对象,还简化了聚合类,而且在同一个聚合上可以有多个遍历;其缺点在于增加新的聚合类需要对应增加新的迭代器类,类的个数成对增加,这在一定程度上增加了系统的复杂性。

    ü  迭代器模式适用情况包括:访问一个聚合对象的内容而无须暴露它的内部表示;需要为聚合对象提供多种遍历方式;为遍历不同的聚合结构提供一个统一的接口。

     

    ü  模板方法模式(TemplateMethod Pattern):定义一个操作中算法的骨架,而将一些步骤延迟到子类中,模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。模板方法是一种类行为型模式。

    ü  Template Method Pattern: Define the skeleton of an algorithm in anoperation, deferring some steps to subclasses. Template Method lets subclassesredefine certain steps of an algorithm without changing the algorithm'sstructure.

    ü  模板方法模式的优点在于在子类定义详细的处理算法时不会改变算法的结构,实现了代码的复用,通过对子类的扩展可以增加新的行为,符合“开闭原则”;其缺点在于需要为每个不同的实现都定义一个子类,这会导致类的个数增加,系统更加庞大,设计也更加抽象

    ü  模板方法模式适用情况包括:一次性实现一个算法的不变的部分,并将可变的行为留给子类来实现;各子类中公共的行为应被提取出来并集中到一个公共父类中以避免代码重复;对一些复杂的算法进行分割,将其算法中固定不变的部分设计为模板方法,而一些可以改变的细节由其子类来实现;通过模板方法模式还可以控制子类的扩展。

    ü  桥接模式(BridgePattern):将抽象部分与它的实现部分分离,使它们都可以独立地变化。它是一种对象结构型模式,又称为柄体(Handle and Body)模式或接口(Interface)模式。

    ü  Bridge Pattern: Decouple an abstraction from its implementation sothat the two can vary independently.

    ü  桥接模式的主要优点是分离抽象接口及其实现部分,是比多继承方案更好的解决方法,桥接模式还提高了系统的可扩充性,在两个变化维度中任意扩展一个维度,都不需要修改原有系统,实现细节对客户透明,可以对用户隐藏实现细节;其主要缺点是增加系统的理解与设计难度,且识别出系统中两个独立变化的维度并不是一件容易的事情。

    ü  桥接模式适用情况包括:需要在构件的抽象化角色和具体化角色之间增加更多的灵活性,避免在两个层次之间建立静态的继承联系;抽象化角色和实现化角色可以以继承的方式独立扩展而互不影响;一个类存在两个独立变化的维度,且这两个维度都需要进行扩展;设计要求需要独立管理抽象化角色和具体化角色;不希望使用继承或因为多层次继承导致系统类的个数急剧增加的系统。

     

    展开全文
  • 定义对象间的一种一对多的依赖关系,当一个对象的状态发生变化时,所有依赖于它的对象都得到通知并被自动更新。
  • 第一篇分为8章,介绍了软件体系结构的基础理论,包括软件体系结构的概念及演化、软件建模基础、软件体系结构的形式化、软件体系结构的风格、体系结构的描述语言、软件质量建模、设计模式等内容。第二篇分为4章,首先...
  • 关于软件体系结构设计模式的总结

    千次阅读 2014-05-28 22:27:56
    因为软件体系结构设计模式太多了,如果用的不多,shi

    因为软件体系结构的设计模式太多了,如果用的不多,实践的不多,很难记住原理。当你考软考的时候,当问到这个编程代码用到了什么体系模式,如果思路不清晰或压根不知道那些模式的区别,要做出那道题挺难的,因此我对我觉得比较重要的设计模式做了简短总结:

    1.单例模式:确保一个类仅有一个唯一的实例,并且提供一个全局的访问点。

    2.工厂模式:开闭原则:必须修改工厂类的源代码,所以不支持开闭原则。

    3.生成器模式:将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示。

    4.适配器模式:类适配器模式:继承关系;对象适配器模式:调用。

    5.组合模式:将对象组合成树形结构,以表示“整体-部分”的层次结构,组合模式使得用户对单个对象和组合对象的使用具有一致性。

    6.外观模式:用来隐藏一个软件系统的缩影内部细节,只提供给客户类一个外观类,也叫做接口类。

    7.桥接模式:将抽象部分与它的实现部分分离,使它们可以独立地变化。

    8.迭代器模式:能够提供一种方法按照顺序访问一个聚合对象中的所有元素,而又不需要暴露该对象的内部表示。

    9.访问者模式:指作用于一个对象结构体上的元素的操作。访问者可以使用户在不改变该结构体中的类的基础上定义一个新的操作。

    10.命令模式:解除调用者与接收者类之间的耦合。

    11.中介者模式:将所有对象之间的交互细节抽象到一个独立的类中,这个类叫做中介者类。

    12.策略模式:定义了一系列的算法,将每一个算法封装起来,并且使它们之间可以相互替换。策略模式让算法的变化不会影响到使用算法的客户。

    13.状态模式:允许一个对象在其内部状态改变时改变它的行为。这个对象看起来修改了它的类。

    展开全文
  • 【《软件设计模式体系结构》学习笔记】软件设计模式的概念软件设计模式是对软件设计经验的总结,是对软件设计中反复出现的设计问题的已被验证的成功解决之道。大量的软件设计模式都是之前从事软件设计开发的前人...

    【《软件设计模式与体系结构》学习笔记】

    软件设计模式的概念


    软件设计模式是对软件设计经验的总结,是对软件设计中反复出现的设计问题的已被验证的成功解决之道。大量的软件设计模式都是之前从事软件设计开发的前人经过大量的实践而摸索出来的,用于帮助后来者快速高效且高质从事软件开发的。

    软件设计模式的要素


    软件设计模式一般会包含四个基本要素:

    • 模式名称:此种设计模式的名字;
    • 问题:是设计者所面临的设计场景,也就是此种设计模式所适用的情况;
    • 解决方案:描述设计细节,通常会采取UML等图示的方式来进行设计模式的详细描述;
    • 效果:描述适用此设计模式的优势与劣势,包括面向软件的质量属性等。

    软件设计模式的分层


    软件设计模式根据问题的规模可以分为三个层次
    架构模式 -> 设计模式 -> 习惯用法

    1. 架构模式:描述系统级的结构组成、相互关系及相关约束,如MVC模式;
    2. 设计模式:针对系统局部设计问题给出的解决方案,一般情况下,设计模式指的就是这一层次的;
    3. 习惯用法:与具体编程语言相关的一种底层模式。

    软件设计模式的分类


    《软件设计模式与体系结构》一书中将设计模式归类如下:

    面向对象分布式计算企业应用软件面向服务的体系结构(SOA)
    创建型模式从混沌到结构领域逻辑模式服务设计模式
    结构型模式分布式基础设施数据源结构模式服务库设计模式
    行为型模式事件分离与分发对象——关系行为模式服务组合设计模式
    接口划分对象——关系结构模式
    组件划分对象——关系元数据映射模式
    应用控制Web表现模式
    并发分布模式
    同步离线并发模式
    对象交互会话状态模式
    适配与扩展基本模式
    模态行为
    资源管理
    数据库访问

    感悟

    在我们日常学习中,有些时候不知不觉的应用到某些设计模式,但我们很难意识到这可以抽象为一种思想方法,并且是可以被他人当为一种模式的设计方法。所以,在以后我们又碰到类似问题时,又会重新将以前的思路再来一次,等到脑中的设计思想快成型的时候,才会恍然大悟,一拍脑门道:“哦,这个东西我好像上一次做过。”

    设计模式是前人经过验证的成功的解决方案,我们应该要善于学习,学会运用,别辜负了前辈们的心血。站在巨人的肩膀上,我们会看得更远。

    展开全文
  • 课程:软件结构体系设计模式 章节:第一章第一节 章节名:设计模式的诞生与发展 课程目录: 1. 模式的诞生与发展 2. 什么是模式 3. 软件模式 1. 模式的诞生与发展 模式起源于建筑领域,公认的建筑学领域模式之...
    软件体系结构与设计模式
    第一章 软件设计模式概述

    目录:

    1. 模式的诞生

    模式起源于建筑领域,公认的建筑学领域模式之父,著名建筑学家克里斯托弗 · 亚历山大将模式描述为:

    每个模式都描述了一个在我们的环境中不断出现的的问题,然后描述了该问题的解决方案的核心,通过这种方式,你可以无数次使用那些已有的解决方案,无需再重复相同的工作

    将模式引入软件工程领域的是GoF(Gang of Four),由此诞生了软件模式。
    GoF并不是一种具体的“技术”,它讲述的是思想,它不仅仅展示了接口或抽象类在实际案例中的灵活应用和智慧,让你能够真正掌握接口或抽象类的应用,从而在原来语言基础上跃进一步。更重要的是,GoF的设计模式反复向你强调一个宗旨:要让你的程序尽可能的可重用
    这其实在向一个极限挑战:软件需求变幻无穷,计划没有变化快,但是我们还是要寻找出不变的东西,并将它和变化的东西分离开来,这需要非常的智慧和经验。 而GoF的设计模式是在这方面开始探索的一块里程碑。


    2. 什么是模式
    • 一个围棋下的好的人知道, 好的对于围棋非常重要,就是棋子在棋盘上的几何形状的抽象化

    • 就是模式(Pattern),也是人脑把握和认识外界的关键

    • 我们在处理大量问题时,发现在很多不同的问题中重复出现的一种性质,它使得我们可以使用一种方法来描述问题实质并用本质上相同,但细节永不重复的方法去解决,这种性质就叫模式

    • 模式是由特定环境、问题、解决方案组成的规则,其核心思想就是对设计的复用


    3. 软件模式
    • 软件模式是将模式的一般概念应用于软件开发领域,即软件开发的总体指导思路参照样板

    • 软件模式并非仅限于设计模式,还包括架构模式分析模式过程模式等。实际上,在软件生命周期的每一个阶段都存在着一些被认同的模式

    • 软件模式可以认为是对软件开发这一特定 “ 问题 ” 的 “ 解法 ” 的某种统一表示,即软件模式等于一定条件下出现的问题以及解法

      软件模式 = 环境 + 问题 + 解决方案

    • 软件模式的基础结构由4个部分构成:问题描述前提条件(环境或约束条件)解法效果/优缺点/已知应用

    问题描述
    前提条件
    问题解法
    关联解法
    效果/优缺点/已知应用
    其它关联模式

    4. 设计模式与体系结构模式

    4.1 设计模式

    设计模式:描述了定制化的相互通信的对象与类,以解决特定环境中的通用设计问题

    设计模式同样是用来解决某个特定环境中的一系列问问题,主要面向对象与类,用于解决某一个具体的问题点

    4.2 体系结构模式

    体系结构模式:是对系统的高层设计,从一个较高的层次来考虑组成系统的构件和它们之间的连接关系,以及系统需满足的约束等,用以实现结构体系级的设计复用

    • 体系结构模式通常又被称为架构模式体系结构风格
    • 体系结构模式的层次高于设计模式,它主要面向系统设计
    • 一个体系结构模式可能会包含一个或多个设计模式

    设计模式与体系结构模式的关系:

    pic


    5. 软件体系结构

    5.1 软件结构

    • 在诸如建筑和计算机硬件设计中,体系结构是指整个系统构成的基本和主体形态,在一个发展成熟的领域中,这种结构称为建立和考察系统的总体指导和基本出发点。
    • 软件体系结构是软件在设计构成上的基本,可供选择的形态和总体结构。具体说,就是人们现今已经熟悉的软件概念看,软件设计中可选的结构形态有:

      过程(procedure)、包(package)、对象(object)、客户/服务器(client/server)、分布式(distributed)、可视控件(visual controls)、部件(component)、解释器(interpreter)、浏览器(browser) 等

    5.2 软件的局部和整体

    • 随着计算机硬件技术的飞速发展,软件的复杂性也逐渐增加,在软件设计中,软件的局部和整体系统结构越来越重要,甚至超过了软件算法和数据结构这些常规软件设计的概念
    • 软件体系结构定义了软件的局部和总计算机部件的构成,以及这些部件的相互作用关系。
      • 部件包括诸如客户端、服务器、数据库、过滤器、程序包、子程序等一切软件的组成部分。
      • 相互作用关系包括诸如过程调用、共享变量访问、消息传递等,相互作用也包括具有十分复杂的语义和构成的构成的关系,例如客户/服务器的访问协议。

    5.3 软件的功能和性能

    • 除了描述系统的构成和结构关系外,在系统功能需求方面,体系结构还表达了系统需求和构成之间的关系,这为系统的设计提供了分析和评价的依据。
    • 在系统宏观层面,人们所关心的是系统的非功能性需求方面的内容,例如容量、数据吞吐量、一致性、兼容性、安全性、可靠性等,这些也都在体系结构中表达了出来。

    5.4 软件结构的复合关系

    • 一般来说,体系结构清楚地表达了系统的构成部件以及它们之间的作用关系和语义,这些部件又可以用来构成更大的、更复杂的部件或系统。
    • 在理想的情况下,体系结构描述的各个组成成分都是被独立定义的,因此可以在不同的场合中得到重用
    • 由于系统的每一层次和每一部分的组成结构都是明确规范了的,因此为整个系统的功能和非功能特性的分析提供可全面和具体的依据。

    5.5 软件体系结构的进一步认识

    • 总的来看,软件体系结构是结构和功能各异,相互作用的部件集合,按照层次构成的
    • 它包含了系统基础构成单元、它们之间的作用关系、在构成系统时它们的合成方法以及对合成约束的描述。

    展开全文
  • 一、软件体系结构和框架的定义软件体系结构的英文单词是“architecture”. Architecture的基本词义是建筑、建筑学、建筑风格。 软件体系结构虽然根植于软件工程,但还处于一个研究发展的阶段,迄今为止还没有一个...
  • 软件设计模式体系结构 期末课后题 目录 软件设计模式体系结构 期末课后题 第一题 金鱼缸水质、水温与水位高度的软件系统 第二题 设计一个机场信息系统 第三题 说明设计与其选择原因 第四题 简答 第一题 ...
  • 软件体系结构(架构) 软件体系结构的定义 通常,软件体系结构通常被称为架构,指可以预制和可重构的软件框架结构。架构尚处在发展期,对于其定义,学术界尚未形成一个统一的意见,而不同角度的视点也会造成...
  • 设计模式软件体系结构【期末全整理答案】

    万次阅读 多人点赞 2020-07-13 19:01:19
    若本文对你有帮助,请点赞、关注我呦! 期末试题基本出自这些题,请提前复制黏贴到word文档里,方便考试时直接查找。 单选题汇总 ...2、常用的基本设计模式可分为(A)。 A.创建型、结构行为型 ...
  • 软件体系结构

    2018-09-27 16:57:46
    软件体系结构为软件系统提供了一个结构、行为属性的高级抽象,由构成系统的...软件体系结构不仅指定了系统的组织结构拓扑结构,并且显示了系统需求构成系统的元素之间的对应关系,提供了一些设计决策的基本原理
  • 4、常见设计模式 5、常见JAVA框架 1、软件框架 定义 面向某领域(包括业务领域,如ERP,计算领域,如GUI)的、可复用的“半成品”软件,它实现了该领域的共性部分,并提供一系列定义良好的可变点以保证...
  • 软件体系结构》第三章 软件体系结构风格

    万次阅读 多人点赞 2018-07-01 13:56:42
    1. 软件体系结构设计的一个核心问题是能否使用重复的体系结构模式,即能够达到体系结构级的复用。 2. 软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。体系结构风格定义了一个系统家族,即一个...
  • 软件体系结构基础

    千次阅读 2020-12-27 12:57:33
    体系结构的模式选择设计模式做阐述,风格选择典型的三种体系结构风格做阐述,框架选择MVC、J2EE、PCMEF与PCBMER框架做阐述,同时也对特定领域的软件体系结构的类属模型、参考模型,分布式系统结构的多处理机结构、...
  • 分层体系结构模式是n层模式,其中组件被组织在水平层中。这是设计大多数软件的传统方法,并且具有独立性。这意味着所有组件都是互连的,但彼此之间不依赖。 图1:分层架构 在此体系结构中有四层,其中...
  • 软件体系结构课程

    千次阅读 2012-11-20 17:00:52
    1.4软件体系结构设计的基本原则   1.1 软件体系结构的基本概念 软件体系结构是软件工程的重要研究领域,软件体系结构并没有统一的定义。 90年代开始,很多专家学者对软件体系结构引起广泛关注,综合软件体系...
  • 章二 软件体系结构的构建模式(1)

    千次阅读 2006-12-28 00:20:00
    章二 软件体系结构的构建模式一个设计良好的通用模式往往是这个工程领域技术成熟的标志。1、管道过滤模式1)概述:每个功能模块都有一组输入输出;功能模块对输入数据流进行增量计算得到输出数据流。功能模块称作...
  • 软件体系结构期末考试总结

    千次阅读 多人点赞 2019-12-30 23:19:35
    今天刚考完软件体系结构,把考前的知识点总结发到群里,仅供自己参考,但是里面的内容确实有用也是面试会问到的基础,所以这门课很重要的还是,只可惜我是预习了一两天就参加考试了 对了我们的教材是《软件工程体系...
  • 软件体系结构期末复习总结

    千次阅读 多人点赞 2020-08-18 21:14:41
    软件体系结构是具有一定形式的结构化元素,抽象的讲,软件体系结构包括构成系统的设计元素的描述,设计元素的交互,设计元素组合的模式,以及在这些模式中的约束。具体的讲,体系结构 = 组件+连接件+约束 组件:...
  • 本书介绍了三种模式:体系结构模式、设计模式、惯用法。体系结构模式主要用在系统整体框架设计阶段;设计模式主要用在模块设计阶段;惯用法主要用在实际的编码阶段。体系结构模式又分成8种:分层、管道过滤器、...
  • 软件体系结构和框架的定义

    千次阅读 2011-09-18 13:50:56
    一、软件体系结构和框架的定义 软件体系结构的英文单词是“architecture”. Architecture的基本词义是建筑、建筑学、建筑风格。 软件体系结构虽然根植于软件工程,但还处于一个研究发展的阶段,迄今为止还没有一...
  • 软件体系结构风格介绍

    千次阅读 2020-02-18 12:46:38
    文章目录软件体系结构风格介绍(一)管道过滤器风格(二)数据抽象与面向对象风格(三)基于事件的隐式调用风格(四)层次系统风格(五)仓库风格(六)C2风格(七)基于层次消息总线的架构风格 软件体系结构风格...
  • 软件体系结构为软件系统提供了一个结构、行为属性的高级抽象,由构成系统的...软件体系结构不仅指定了系统的组织结构拓扑结构,并且显示了系统需求构成系统的元素之间的对应关系,提供了一些设计决策的基本原理
  • 软件体系结构风格整理

    万次阅读 多人点赞 2019-01-06 15:17:36
    什么是软件体系结构风格? 软件体系结构风格(Architectural Styles)是描述特定系统组织方式的惯用范例,强调了软件系统中通用的组织结构。 风格这个词是个模糊的概念,不同的人有不同的理解,这有时候就让人很...
  • 软件体系结构教案.rar 软件体系结构建模 ——UML与设计模式 类图,关系,聚集、组成、接口实现 ....
  • 章二 软件体系结构的构建模式(2)

    千次阅读 2006-12-29 23:35:00
    章二 软件体系结构的构建模式(2)三、事件驱动模式1、事件驱动模式事件驱动系统的基本观点是一个系统对外部的表现可以从它对事件的处理表征出来。特点: (1)系统由若干个子系统或元素所组成的一个整体; (2)...
  • 一、设计模式 design paternal 1.MVC model view controller 模型-视图-控制器  MVC把交互系统的组成分解成模型、视图、控制三种构件。  模型:独立于外在显示内容形式,是软件所处理的问题逻辑的内在抽象,...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 87,302
精华内容 34,920
关键字:

软件体系结构和设计模式的关系