免费智能真题库 > 历年试卷 > 系统架构设计师 > 2012年下半年 系统架构设计师 上午试卷 综合知识
  第51题      
  知识点:   设计模式目录的内容   需求分析   封装   软件需求   设计阶段   设计模式   系统设计阶段   需求分析阶段
  关键词:   分析阶段   封装   架构师   设计阶段   设计模式   算法   图像   系统分析   系统设计   需求分析   照片   需求        章/节:   设计模式       

 
某软件公司欲设计一款图像处理软件,帮助用户对拍摄的照片进行后期处理。在软件需求分析阶段,公司的系统分析师识别出了如下3个关键需求:
图像处理软件需要记录用户在处理照片时所有动作,并能够支持用户动作的撤销与重做等行为。
图像处理软件需要根据当前正在处理的照片的不同特征选择合适的处理操作,处理操作与照片特征之间具有较为复杂的逻辑关系。
图像处理软件需要封装各种图像处理算法,用户能够根据需要灵活选择合适的处理算法;软件还要支持高级用户根据一定的规则添加自定义处理算法。
在系统设计阶段,公司的架构师决定采用设计模式满足上述关键需求中对系统灵活性与扩展性的要求。具体来说,为了支持灵活的撤销与重做等行为,采用(51)最为合适;为了封装图像操作与照片特征之间的复杂逻辑关系,采用(52)最为合适;为了实现图像处理算法的灵活选择与替换,采用(53)最为合适。
 
 
  A.  工厂模式
 
  B.  责任链模式
 
  C.  中介者模式
 
  D.  命令模式
 
 
 

 
  第59题    2010年下半年  
   39%
某公司欲开发一个软件系统的在线文档帮助系统,用户可以在任何一个查询上下文中输入查询关键字,如果当前查询环境下没有相关内容..
  第33题    2011年下半年  
   35%
某公司欲开发一门户网站,将公司的各个分公司及办事处信息进行整合。决定采用Composite设计模式来实现公司的组织结构关系,并设计..
  第52题    2012年下半年  
   58%
某软件公司欲设计一款图像处理软件,帮助用户对拍摄的照片进行后期处理。在软件需求分析阶段,公司的系统分析师识别出了如下3个关..
   知识点讲解    
   · 设计模式目录的内容    · 需求分析    · 封装    · 软件需求    · 设计阶段    · 设计模式    · 系统设计阶段    · 需求分析阶段
 
       设计模式目录的内容
        Erich Gamma在他的博士论文中总结了一系列的设计模式,做出了开创性的工作。他用一种类似分类目录的形式将设计模式记载下来。我们称这些设计模式为设计模式目录。根据模式的目标(所做的事情),可以将它们分成创建性模式(creational)、结构性模式(structural)和行为性模式(behavioral)。创建性模式处理的是对象的创建过程,结构性模式处理的是对象/类的组合,行为性模式处理类和对象间的交互方式和任务分布。根据它们主要的应用对象,又可以分为主要应用于类的和主要应用于对象的。
        下表是Erich Gamma等总结的23种设计模式,这些设计模式通常称为GoF(Gang of Four,四人组)模式。因为这些模式是在“Design Patterns:Elements of Reusable Object-Oriented Software”中正式提出的,而该书的作者是Erich Gamma、Richard Helm、Ralph Johnson和John Vlissides,这几位作者常被称为“四人组”。
        
        设计模式目录的分类
        
        其中带*模式是关于类的,其他模式是关于对象的。
 
       需求分析
        需求分析的方法种类繁多,不过如果按照分解的方式不同,可以很容易地划分出几种大类型:
        (1)结构化分析方法。本节后续内容将详细讨论SA的内容。
        (2)面向对象分析方法。将在9.4节中进行详细介绍。
        (3)面向问题域的分析(Problem Domain Oriented Analysis,PDOA)方法。PDOA更多地强调描述,而少强调建模。它的描述大致分为关注问题域和关注解系统的待求行为这两个方面。问题框架是PDOA的核心元素,是将问题域建模成为一系列相互关联的子域。也可以把问题框架看作是开发上下文图,但不同的是上下文图的建模对象是针对解系统,而问题框架则是针对问题域。也就是说,问题框架的目标就是大量地捕获更多有关问题域的信息。PDOA方法现在还在研究阶段,并未广泛应用。
               业务流程分析
               业务流程分析的目的是了解各个业务流程的过程,明确各个部门之间的业务关系和每个业务处理的意义,为业务流程的合理化改造提供建议,为系统的数据流程变化提供依据。
               业务流程分析的步骤如下:
               (1)通过调查掌握基本情况。
               (2)描述现有业务流程(绘制业务流程图)。
               (3)确认现有业务流程。
               (4)对业务流程进行分析。
               (5)发现问题,提出解决方案。
               (6)提出优化后的业务流程。
               在业务流程图中使用的基本符号如下图所示。
               
               业务流程图符号
               数据流图
               DFD是结构化分析中的重要方法和工具,是表达系统内数据的流动并通过数据流描述系统功能的一种方法。DFD还可被认为是一个系统模型,在信息系统开发中,一般将它作为需求说明书的组成部分。
               DFD从数据传递和加工的角度,利用图形符号通过逐层细分描述系统内各个部件的功能和数据在它们之间传递的情况,来说明系统所完成的功能。具体来说,DFD的主要作用如下:
               (1)DFD是理解和表达用户需求的工具,是系统分析的手段。由于DFD简明易懂,理解它不需要任何计算机专业知识,因此通过它同客户交流很方便。
               (2)DFD概括地描述了系统的内部逻辑过程,是系统分析结果的表达工具,因而也是系统设计的重要参考资料,是系统设计的起点。
               (3)DFD作为一个存档的文字材料,是进一步修改和充实开发计划的依据。
               在DFD中,通常会出现4种基本符号,分别是数据流、加工、数据存储和外部实体(数据源及数据终点)。数据流是具有名字和流向的数据,在DFD中用标有名字的箭头表示。加工是对数据流的变换,一般用圆圈表示。数据存储是可访问的存储信息,一般用直线段表示。外部实体是位于被建模的系统之外的信息生产者或消费者,是不能由计算机处理的成分,它们分别表明数据处理过程的数据来源及数据去向,用标有名字的方框表示。下图是一个典型的DFD示例。
               
               办理取款手续的DFD
               为了表达数据处理过程中的数据加工情况,用一个DFD是不够的。稍微复杂的实际问题,在DFD中常常出现十几个甚至几十个加工。这样的DFD看起来很不清楚。层次结构的DFD能很好地解决这一问题。按照系统的层次结构进行逐步分解,并以分层的DFD反映这种结构关系,能清楚地表达整个系统。
               下图给出分层DFD的示例。数据处理S包括三个子系统1、2、3。顶层下面的第一层DFD为DFD/L1,第二层的DFD/L2.1、DFD/L2.2及DFD/L2.3分别是子系统1、2和3的细化。对任何一层数据流图来说,我们称它的上层图为父图,在它下一层的图则称为子图。
               
               分层数据流图
               概括地说,画DFD的基本步骤,就是“自顶向下,逐层分解”。检查和修改的原则如下:
               (1)DFD中的所有图形符号只限于前述4种基本图形元素。
               (2)顶层DFD必须包括前述4种基本元素,缺一不可。
               (3)顶层DFD中的数据流必须封闭在外部实体之间。
               (4)每个加工至少有一个输入数据流和一个输出数据流。
               (5)在DFD中,需按层给加工框编号。编号表明了该加工处在哪一层,以及上下层的父图与子图的对应关系。
               (6)规定任何一个数据流子图必须与它上一层的一个加工对应,两者的输入数据流和输出数据流必须一致。此即父图与子图的平衡。
               (7)可以在DFD中加入物质流,帮助用户理解DFD。
               (8)图上每个元素都必须有名字。
               (9)DFD中不可夹带控制流。
               数据字典
               数据字典是关于数据的信息的集合,也就是对DFD中包含的所有元素的定义的集合。DFD和数据字典共同构成系统的逻辑模型。没有DFD,数据字典难以发挥作用;没有数据字典,DFD就不严格。只有把DFD和对DFD中每个元素的精确定义放在一起,才能共同构成系统的规格说明。
               数据字典的设计包括:数据流设计、数据元素字典设计、数据处理字典设计、数据结构字典设计和数据存储设计。这些设计涵盖了数据的采集和范围的确定等信息。在数据字典的每一个词条中应包含以下信息名称、别名或编号、分类、描述、何处使用。
               对加工的描述是数据字典的组成内容之一,常用的加工描述方法有结构化语言、判定树及判定表。
               (1)结构化语言:介于自然语言和形式语言之间的一种半形式语言,在自然语言基础之上加了一些限度,使用有限的词汇和有限的语句来描述加工逻辑。结构化语言是受结构化程序设计思想启发而扩展出来的。结构化程序设计只允许3种基本结构。结构化语言也只允许3种基本语句,即简单的祈使语句、判断语句和循环语句。与程序设计语言的差别在于结构化语言没有严格的语法规定,与自然语言的不同在于它只有极其有限的词汇和语句。结构化语言使用三类词汇:祈使句中的动词、数据字典中定义的名词及某些逻辑表达式中的保留字。
               (2)判定树:若一个动作的执行不只依赖一个条件,而与多个条件有关,那么这项策略的表达就比较复杂。如果用结构化语言的判断语句,就有多重嵌套,层次一多,可读性就会下降。用判定树来表示,可以更直观一些。
               (3)判定表:一些条件较多、在每个条件下取值也较多的判定问题,可以用判定表表示。判定表能清晰地表达复杂的条件组合与应做动作之间的对应关系,判定表的优点是能够简洁、无二义性地描述所有的处理规则。但判定表表示的是静态逻辑,是在某种条件取值组合情况下可能的结果,它不能表达加工的顺序,也不能表达循环结构,因此判定表不能成为一种通用的设计工具。
 
       封装
        面向对象系统中的封装单位是对象,对象之间只能通过接口进行信息交流,外部不能对对象中的数据随意地进行访问,这就造成了对象内部数据结构的不可访问性,也使得数据被隐藏在对象中。封装的优点体现在以下三个方面。
        (1)好的封装能减少耦合。
        (2)类内部的实现可以自由改变。
        (3)一个类有更清楚的接口。
 
       软件需求
        在进行需求获取之前,首先要明确需要获取什么,也就是需求包含哪些内容。软件需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。通常,这些需求包括功能需求、性能需求、用户或人的因素、环境需求、界面需求、文档需求、数据需求、资源使用需求、安全保密需求、可靠性需求、软件成本消耗与开发进度需求等,并预先估计以后系统可能达到的目标。此外,还需要注意其他非功能性的需求。具体内容如下。
        (1)功能需求。
        (2)性能需求。
        (3)用户或人的因素。
        (4)环境需求。
        (5)界面需求。
        (6)文档需求。
        (7)数据需求。
        (8)资源使用需求。
        (9)安全保密要求。
        (10)可靠性要求。
        (11)软件成本消耗与开发进度需求。
        (12)其他非功能性要求。
               需求分析的任务
               需求分析主要是确定待开发软件的功能、性能、数据、界面等要求。具体来说有下面几点。
               (1)确定软件系统的综合要求,包括系统界面、功能、性能、安全性、保密性、可靠性、运行等方面的要求。
               (2)分析软件系统的数据要求,包括基本数据元素、数据元素之间的逻辑关系、数据量、峰值等。
               (3)导出系统的逻辑模型,在结构化方法中可用数据流图来描述;在面向对象分析方法中可以用类模型来描述。
               (4)修正项目开发计划。
               (5)如有必要,可开发一个原型系统以验证用户的需求。
               软件需求的分类
               下面介绍软件需求的分类。
               (1)功能需求。所开发的软件必须具备什么样的功能。
               (2)非功能需求。它是指产品必须具备的属性或品质,如可靠性、性能响应时间、容错性和可扩展性等。
               (3)设计约束。其也称为限制条件、补充规约,这通常是对解决方案的一些约束说明。
               软件需求分析方法
               需求分析方法由对软件的数据域和功能域的系统分析过程及其表示方法组成。它定义了表示系统逻辑视图和物理视图的方式。大多数的需求分析方法是由数据驱动的,数据域具有数据流、数据内容和数据结构3种属性。通常一种需求分析方法总要利用其中一种或几种属性。
 
       设计阶段
        设计阶段监理进行质量控制的要点如下。
        (1)了解建设单位的建设需求和对信息系统安全性的要求,协助建设单位制定项目质量目标规划和安全目标规划。
        (2)对各种设计文件提出设计质量标准。
        (3)进行设计过程跟踪,及时发现质量问题,并及时与承建单位协调解决。审查阶段性成果,并提出监理意见。审查承建单位提交的总体设计方案,审查承建单位对关键部位的测试方案。
        (4)协助承建单位建立质量保障体系。
        (5)协助承建单位完善现场质量管理制度。
        (6)组织设计文件及设计方案交底会,制定质量要求标准。
 
       设计模式
        “每一个模式描述了一个在我们周围不断重复发生的问题,以及该问题的解决方案的核心。这样,你就能一次又一次地使用该方案而不必做重复劳动”。设计模式的核心在于提供了相关问题的解决方案。
        设计模式一般有如下4个要素。
        (1)模式名称(pattern name)。模式名称应具有实际的含义,能反映模式的适用性和意图。
        (2)问题(problem)。描述了应该在何时使用模式,解释了设计问题和问题存在的前因后果。可能描述了特定的设计问题,如怎样用对象表示算法等;也可能描述了导致不灵活设计的类或对象结构。有时候,问题部分会包括使用模式必须满足的一系列先决条件。
        (3)解决方案(solution)。描述了设计的组成成分,它们之间的相互关系及各自的职责和协作方式。解决方案并不描述一个特定的具体的设计或实现,而是提供设计问题的抽象描述和怎样用一个具有一般意义的元素组合(类或对象组合)来解决这个问题。
        (4)效果(consequences)。描述了模式应用的效果及使用模式应权衡的问题。因为复用是面向对象设计的要素之一,所以模式效果包括它对系统的灵活性、扩充性或可移植性的影响,显式地列出这些效果对理解和评价这些模式很有帮助。
        设计模式确定了所包含的类和实例,它们的角色、协作方式以及职责分配。每一个设计模式都集中于一个特定的面向对象设计问题或设计要点,描述了什么时候使用它,在另一些设计约束条件下是否还能使用,以及使用的效果和如何取舍。按照设计模式的目的可以分为创建型、结构型和行为型三大类,如下表所示。
        
        设计模式分类
               创建型设计模式
               创建型模式与对象的创建有关,抽象了实例化过程,它们帮助一个系统独立于如何创建、组合和表示它的那些对象。一个类创建型模式使用继承改变被实例化的类,而一个对象创建型模式将实例化委托给另一个对象。
               创建型模式包括面向类和面向对象两种。Factory Method(工厂方法)定义一个用于创建对象的接口,让子类决定实例化哪一个类。Abstract Factory(抽象工厂)提供一个创建一系列相关或相互依赖对象的接口,而无须指定它们具体的类。Builder(生成器)将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示。Factory Method使一个类的实例化延迟到其子类。Prototype(原型)用原型实例指定创建对象的种类,并且通过复制这些原型创建新的对象。Singleton(单例)模式保证一个类仅有一个实例,并提供一个访问它的全局访问点。
               下面以抽象工厂模式和单例模式为例进行说明。
                      Abstract Factory(抽象工厂)
                      (1)意图。提供一个创建一系列相关或相互依赖对象的接口,而无须指定它们具体的类。
                      (2)结构。抽象工厂模式的结构如下图所示。
                      
                      抽象工厂模式结构图
                      其中:
                      .AbstractFactory声明一个创建抽象产品对象的操作接口。
                      .ConcreteFactory实现创建具体产品对象的操作。
                      .AbstractProduct为一类产品对象声明一个接口。
                      .ConcreteProduct定义一个将被相应的具体工厂创建的产品对象,实现AbstractProduct接口。
                      .Client仅使用由AbstractFactory和AbstractProduct类声明的接口。
                      (3)适用性。Abstract Factory模式适用于:
                      .一个系统要独立于它的产品的创建、组合和表示时。
                      .一个系统要由多个产品系列中的一个来配置时。
                      .当要强调一系列相关的产品对象的设计以便进行联合使用时。
                      .当提供一个产品类库,只想显示它们的接口而不是实现时。
                      Singleton(单例)
                      (1)意图。保证一个类仅有一个实例,并提供一个访问它的全局访问点。
                      (2)结构。单例模式的结构如下图所示。
                      
                      单例模式结构图
                      其中:Singleton指定一个Instance操作,允许客户访问它的唯一实例,Instance是一个类操作;可能负责创建它自己的唯一实例。
                      (3)适用性。Singleton模式适用于:
                      .当类只能有一个实例而且客户可以从一个众所周知的访问点访问它时。
                      .当这个唯一实例应该是通过子类化可扩展的,并且客户无须更改代码就能使用一个扩展的实例时。
               结构型设计模式
               结构型模式处理类或对象的组合,涉及如何组合类和对象以获得更大的结构。结构型类模式采用继承机制来组合接口或实现。一个简单的例子是采用多重继承方法将两个以上的类组合成一个类,结果这个类包含了所有父类的性质。这一模式尤其有助于多个独立开发的类库协同工作。其中一个例子是类形式的Adapter(适配器)模式。一般来说,适配器使得一个接口与其他接口兼容,从而给出了多个不同接口的统一抽象。为此,类Adapter对一个adaptee类进行私有继承。这样,适配器就可以用adaptee的接口表示它的接口。对象Adapter依赖于对象组合。
               下面以适配器模式和代理模式为例进行说明。
                      Adapter(适配器)模式
                      (1)意图。将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
                      
                      类适配器结构图
                      (2)结构。类适配器使用多重继承对一个接口与另一个接口进行匹配,其结构如上图所示。对象适配器依赖于对象组合,其结构如下图所示。
                      
                      对象适配器结构图
                      其中:
                      .Target定义Client使用的与特定领域相关的接口。
                      .Client与符合Target接口的对象协同。
                      .Adaptee定义一个已经存在的接口,这个接口需要适配。
                      .Adapter对Adaptee的接口与Target接口进行适配。
                      (3)适用性。Adapter模式适用于:
                      .想使用一个已经存在的类,而它的接口不符合要求。
                      .想创建一个可以服用的类,该类可以与其他不相关的类或不可预见的类(即那些接口可能不一定兼容的类)协同工作。
                      .(仅适用于对象Adapter)想使用一个已经存在的子类,但是不可能对每一个都进行子类化以匹配它们的接口。对象适配器可以适配它的父类接口。
                      Proxy(代理)模式
                      (1)意图。为其他对象提供一种代理以控制对这个对象的访问。
                      (2)结构。代理模式的结构如下图所示。
                      
                      代理模式结构图
                      其中:
                      .Proxy保存一个引用使得代理可以访问实体;提供一个与Subject的接口相同的接口,使代理可以用来代替实体;控制对实体的存取,并可能负责创建和删除它;其他功能依赖于代理的类型:Remote Proxy负责对请求及其参数进行编码,并向不同地址空间中的实体发送已编码的请求;Virtual Proxy可以缓存实体的附加信息,以便延迟对它的访问;Protection Proxy检查调用者是否具有实现一个请求所必需的访问权限。
                      .Subject定义RealSubject和Proxy的共用接口,这样就在任何使用RealSubject的地方都可以使用Proxy。
                      .RealSubject定义Proxy所代表的实体。
                      (3)适用性。Proxy模式适用于在需要比较通用和复杂的对象指针代替简单的指针的时候,常见情况有:
                      .远程代理(Remote Proxy)为一个对象在不同地址空间提供局部代表。
                      .虚代理(Virtual Proxy)根据需要创建开销很大的对象。
                      .保护代理(Protection Proxy)控制对原始对象的访问,用于对象应该有不同的访问权限的时候。
                      .智能引用(Smart Reference)取代了简单的指针,它在访问对象时执行一些附加操作。典型用途包括:对指向实际对象的引用计数,这样当该对象没有引用时,可以被自动释放;当第一次引用一个持久对象时,将它装入内存;在访问一个实际对象前,检查是否已经锁定了它,以确保其他对象不能改变它。
                      结构型对象模式不是对接口和实现进行组合,而是描述了如何对一些对象进行组合,从而实现新功能的一些方法。因为可以在运行时刻改变对象组合关系,所以对象组合方式具有更大的灵活性,而这种机制用静态类组合是不可能实现的。
                      Composite(组合)模式将对象组合成树型结构以表示“部分—整体”的层次结构,使得用户对单个对象和组合对象的使用具有一致性。它描述了如何构造一个类层次式结构,这一结构由两种类型的对象所对应的类构成。其中的组合对象使得用户可以组合基元对象以及其他的组合对象,从而形成任意复杂的结构。proxy(代理)模式为其他对象提供一种代理以控制对这个对象的访问,其中,proxy对象作为其他对象的一个方便的替代或占位符。它的使用可以有多种形式,例如可以在局部空间中代表一个远程地址空间中的对象,也可以表示一个要求被加载的较大的对象,还可以用来保护对敏感对象的访问。proxy模式还提供了对对象的一些特有性质的一定程度上的间接访问,从而可以限制、增强或修改这些性质。Flyweight(享元)模式运用共享技术有效地支持大量细粒度的对象,为了共享对象定义了一个结构。至少有两个原因要求对象共享:效率和一致性。Flyweight的对象共享机制主要强调对象的空间效率。使用很多对象的应用必须考虑每一个对象的开销。使用对象共享而不是进行对象复制,可以节省大量的空间资源。但是,仅当这些对象没有定义与上下文相关的状态时,它们才可以被共享。Flyweight的对象没有这样的状态。任何执行任务时需要的其他一些信息仅当需要时才传递过去。由于不存在与上下文相关的状态,因此Flyweight对象可以被自由地共享。
                      Facade(外观)模式为子系统中的一组接口提供一个一致的界面,定义了一个高层接口,这个接口使得这一子系统更加容易使用。该模式描述了如何用单个对象表示整个子系统。模式中的facade用来表示一组对象,facade的职责是将消息转发给它所表示的对象。Bridge(桥接)模式将对象的抽象和其实现分离,从而可以独立地改变它们。
                      Decorator(装饰)模式描述了如何动态地为对象添加一些额外的职责。该模式采用递归方式组合对象,从而允许添加任意多的对象职责。例如,一个包含用户界面组件的Decorator对象可以将边框或阴影这样的装饰添加到该组件中,或者它可以将窗口滚动和缩放这样的功能添加到组件中。可以将一个Decorator对象嵌套在另外一个对象中,就可以很简单地增加两个装饰,添加其他的装饰也是如此。因此,每个Decorator对象必须与其组件的接口兼容并且保证将消息传递给它。Decorator模式在转发一条信息之前或之后都可以完成它的工作(例如绘制组件的边框)。许多结构型模式在某种程度上具有相关性。
               行为型设计模式
               行为模式对类或对象怎样交互和怎样分配职责进行描述,涉及算法和对象间职责的分配。行为模式不仅描述对象或类的模式,还描述它们之间的通信模式。这些模式刻画了在运行时难以跟踪的复杂的控制流。它们将用户的注意力从控制流转移到对象间的联系方式上来。
               行为类模式使用继承机制在类间分派行为。本章包括两个这样的模式,其中Template Method(模板方法)较为简单和常用。Template Method是一个算法的抽象定义,它逐步地定义该算法,每一步调用一个抽象操作或一个原语操作,子类定义抽象操作以具体实现该算法。另一种行为类模式是Interpreter(解释器)模式,它将一个文法表示为一个类层次,并实现一个解释器作为这些类的实例上的一个操作。
               行为对象模式使用对象复合而不是继承。一些行为对象模式描述了一组对等的对象怎样相互协作以完成其中任一个对象都无法单独完成的任务。这里一个重要的问题是对等的对象。
               如何互相了解对方。对等对象可以保持显式的对对方的引用,但那会增加它们的耦合度。在极端情况下,每一个对象都要了解所有其他的对象。Mediator(中介者)模式用一个中介对象来封装一系列的对象交互,在对等对象间引入一个mediator对象以避免这种情况的出现。mediator提供了松耦合所需的间接性。
               Chain of Responsibility(责任链)使多个对象都有机会处理请求,从而避免请求的发送者和接收者之间的耦合关系,将这些对象连成一条链,并沿着这条链传递该请求,直到有一个对象处理它为止。Chain of Responsibility模式提供更松的耦合,让用户通过一条候选对象链隐式地向一个对象发送请求。根据运行时刻情况任一候选者都可以响应相应的请求。候选者的数目是任意的,可以在运行时刻决定哪些候选者参与到链中。
               Observer(观察者)模式定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并被自动更新。典型的Observer的例子是Smalltalk中的模型/视图/控制器,其中一旦模型的状态发生变化,模型的所有视图都会得到通知。
               其他的行为对象模式常将行为封装在一个对象中并将请求指派给它。Strategy(策略)模式将算法封装在对象中,这样可以方便地指定和改变一个对象所使用的算法。Command(命令)模式将一个请求封装为一个对象,从而使得可以用不同的请求对客户进行参数化;对请求排队或记录请求日志,以及支持可撤销的操作。Memento(备忘录)模式在不破坏封装性的前提下,捕获一个对象的内部状态,并在该对象之外保存这个状态,以便在以后可将该对象恢复到原先保存的状态。State(状态)模式封装一个对象的状态,使得对象在其内部状态改变时可改变它的行为,对象看起来似乎修改了它的类。Visitor(访问者)模式表示一个作用于某对象结构中的各元素的操作,使得在不改变各元素的类的前提下定义作用于这些元素的新操作。Visitor模式封装分布于多个类之间的行为。Iterator(迭代器)模式提供一种方法顺序访问一个聚合对象中的各个元素,且不需要暴露该对象的内部表示。Iterator模式抽象了访问和遍历一个集合中的对象的方式。
               下面以中介者模式和观察者模式为例进行说明。
                      Mediator(中介者)
                      (1)意图。用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用,从而使其耦合松散,而且可以独立地改变它们之间的交互。
                      (2)结构。中介者模式的结构图如下图所示。
                      
                      中介者模式结构图
                      其中:
                      .Mediator(中介者)定义一个接口用于各同事(Colleague)对象通信。
                      .ConcreteMediator(具体中介者)通过协调各同事对象实现协作行为;了解并维护它的各个同事。
                      .Colleague class(同事类)知道它的中介者对象;每一个同事类对象在需要与其他同事通信的时候与它的中介者通信。
                      (3)适用性。Mediator模式适用于:
                      .一组对象以定义良好但是复杂的方式进行通信,产生的相互依赖关系结构混乱且难以理解。
                      .一个对象引用其他很多对象并且直接与这些对象通信,导致难以复用该对象。
                      .想定制一个分布在多个类中的行为,而又不想生成太多的子类。
                      Observer(观察者)
                      (1)意图。定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并被自动更新。
                      (2)结构。观察者模式的结构图如下图所示。
                      
                      观察者模式结构图
                      其中:
                      .Subject(目标)知道它的观察者,可以有任意多个观察者观察同一个目标;提供注册和删除观察者对象的接口。
                      .Observer(观察者)为那些在目标发生改变时需获得通知的对象定义一个更新接口。
                      .ConcreteSubject(具体目标)将有关状态存入各ConcreteObserver对象;当它的状态发生改变时,向它的各个观察者发出通知。
                      .ConcreteObserver(具体观察者)维护一个指向ConcreteSubject对象的引用;存储有关状态,这些状态应与目标的状态保持一致;实现Observer的更新接口,以使自身状态与目标的状态保持一致。
                      (3)适用性。Observer模式适用于:
                      .当一个抽象模型有两个方面,其中一个方面依赖于另一个方面,将这两者封装在独立的对象中以使它们可以各自独立地改变和复用。
                      .当对一个对象的改变需要同时改变其他对象,而不知道具体有多少对象有待改变时。
                      .当一个对象必须通知其他对象,而它又不能假定其他对象是谁,即不希望这些对象是紧耦合的。
 
       系统设计阶段
        系统设计工作应该自顶向下地进行。首先设计总体结构,然后再逐层深入,直至进行每一个模块的设计。总体设计主要是指在系统分析的基础上,对整个系统的划分(子系统)、设备(包括软、硬设备)的配置、数据的存储规律以及整个系统实现规划等方面进行合理的安排。
 
       需求分析阶段
        . 确定软件的可靠性目标;
        . 分析可能影响可靠性的因素;
        . 确定可靠性的验收标准;
        . 制定可靠性管理框架;
        . 制定可靠性文档编写规范;
        . 制定可靠性活动初步计划;
        . 确定可靠性数据收集规范。
   题号导航      2012年下半年 系统架构设计师 上午试卷 综合知识   本试卷我的完整做题情况  
1 /
2 /
3 /
4 /
5 /
6 /
7 /
8 /
9 /
10 /
11 /
12 /
13 /
14 /
15 /
 
16 /
17 /
18 /
19 /
20 /
21 /
22 /
23 /
24 /
25 /
26 /
27 /
28 /
29 /
30 /
 
31 /
32 /
33 /
34 /
35 /
36 /
37 /
38 /
39 /
40 /
41 /
42 /
43 /
44 /
45 /
 
46 /
47 /
48 /
49 /
50 /
51 /
52 /
53 /
54 /
55 /
56 /
57 /
58 /
59 /
60 /
 
61 /
62 /
63 /
64 /
65 /
66 /
67 /
68 /
69 /
70 /
71 /
72 /
73 /
74 /
75 /
 
第51题    在手机中做本题