免费智能真题库 > 历年试卷 > 信息系统项目管理师 > 2021年下半年 信息系统项目管理师 上午试卷 综合知识
  第9题      
  知识点:   典型体系结构模式   架构设计   软件架构   软件架构设计
  章/节:   信息系统及其技术和开发方法       

 
图中的软件架构设计属于()风格。
 
 
  A.  虚拟机风格
 
  B.  调用返回风格
 
  C.  独立构件风格
 
  D.  数据流风格
 
 
 

 
  第7题    2017年下半年  
   52%
研究软件架构的根本目的是解决软件的复用、质量和维护问题,软件架构设计师是软件开发过程中关键的一步,因此需要对其进行评估,..
  第7题    2017年上半年  
   33%
软件设计过程是定义一个系统或组件(7)的过程,其中描述软件的结构和组织,标识各种不同组件的设计是(8)。
  第25题    2010年下半年  
   62%
下图是某架构师在J2EE 平台上设计的一个信息系统集成方案架构图,图中的(1)、(2)和(3)分别表示(25)。
   知识点讲解    
   · 典型体系结构模式    · 架构设计    · 软件架构    · 软件架构设计
 
       典型体系结构模式
        软件体系结构模式是经过实践证明的、可重复使用的软件架构设计策略,为粗粒度的软件重用提供了可能。它描述了某一特定应用领域中系统的组织方式,反映了领域中众多系统所共有的结构和语义特性。常见的体系结构模式有:
        1.管道/过滤器模式
        每个构件都有一组输入输出,构件读取输入的数据流,经过内部处理后,产生输出的数据流,该过程主要完成输入流的变换及增量计算。构件称为过滤器,连接器称为数据流传输的管道。管道/过滤器输出的正确性并不依赖于过滤器进行增量计算过程的顺序。管道/过滤器模式如下图所示。
        
        管道/过滤器模式
        优点:
        .体现了各功能模块的“黑盒”特性及高内聚、低耦合的特点。
        .可将整个系统的输入输出行为看成是多个过滤器行为的简单合成。
        .支持软件功能模块的重用。
        .便于系统维护。新的过滤器可以加到现有系统中,旧的可以由改进的过滤器替换。
        .支持某些特定的分析,如吞吐量计算、死锁检测等。
        .支持并行操作,每个过滤器可以作为一个单独的任务完成。
        缺点:
        .通常导致系统处理过程的成批操作。
        .需要设计者协调两个相对独立但又存在关系的数据流。
        .可能需要每个过滤器自己完成数据解析和合成工作(如加密和解密),从而导致系统性能下降,并增加了过滤器具体实现的复杂性。
        2.面向对象模式
        面向对象模式建立在数据抽象和面向对象的基础上,将数据的表示方法及其相应操作封装在一个抽象数据类型或对象中。
        面向对象模式的典型应用是基于构件的软件开发(CBD)。面向对象模式如下图所示。
        
        面向对象模式
        优点:
        .高度模块化。
        .封装功能实现了数据隐蔽。
        .继承性提供了一种实现代码共享的手段。
        .提供了系统的灵活性,便于维护及扩充。
        缺点:
        .对象之间的调用需要知道所调用对象的标识。如果对象的标识发生改变,就必须通知所有调用该对象的对象,否则系统可能无法正常运行。
        3.事件驱动模式
        事件驱动模式的基本原理是构件并不直接调用过程,而是触发一个或多个事件。系统中的其他构件可以注册相关的事件,触发一个事件时,系统会自动调用注册了该事件的构件过程,即触发事件会导致另一构件中过程的调用。
        使用事件驱动模式的典型系统包括各种图形界面工具。
        优点:
        .支持软件重用,容易实现并发处理。
        .具有良好的可扩展性,通过注册可引入新的构件,而不影响现有构件。
        .可以简化客户代码。
        缺点:
        .构件削弱了自身对系统的控制能力。一个构件触发事件时,并不能确定响应该事件的其他构件及各构件的执行顺序。
        .不能很好地解决数据交换问题。
        .使系统中各构件的逻辑关系变得更加复杂。
        4.分层模式
        分层模式采用层次化的组织方式,每一层都是为上一层提供服务,并使用下一层提供的功能。这种模式允许将一个复杂问题逐步分层实现。层次模式中每一层最多只影响两层,只要给相邻层提供相同的接口,就允许每层用不同的方法实现,可以充分支持软件复用。
        分层模式的典型应用是分层通信协议,如ISO/OSI的七层网络模型。
        分层模式如下图所示。
        
        分层模式
        优点:
        .有助于把复杂的问题按功能分解,使整体设计更为清晰。
        .支持系统设计的逐级抽象。
        .具有较好的可扩展性。
        .支持复用。
        缺点:
        .层次的划分没有统一的、正确的抽象方法,并且有些系统不容易划分层次。
        .层次的个数过多,系统性能可能会下降。
        5.知识库模式
        知识库模式采用两种不同的构件:中央数据结构构件说明当前状态,独立构件在中央数据存储上执行,中央数据构件与独立的外部构件间相互作用。
        两种不同的控制策略:
        .基于传统数据库型的知识库模式:输入流触发进程执行的选择。
        .基于黑板系统的知识库模式:中央数据结构的当前状态触发进程执行的选择。
        黑板系统的典型应用是信号处理领域,如语音和模式识别。如下图所示。
        
        基于黑板系统的知识库模式
        黑板系统主要由三部分组成:
        .知识源:包含独立的、与应用程序相关的知识,知识源之间不直接进行通信,它们之间的通信通过黑板来完成。
        .黑板数据结构:按照与应用程序相关的层次来组织并解决问题的数据,知识源通过不断地改变黑板数据来解决问题。
        .控制:完全由黑板的状态驱动,黑板状态的改变决定了需要使用的特定知识。
        6.客户端/服务器模式
        客户端/服务器(C/S)模式是基于资源不对等,为实现共享而提出的。C/S模式将应用一分为二,服务器(后台)负责数据管理,客户端(前台)完成与用户的交互任务。C/S模式具有强大的数据操作和事务处理能力,易于理解和接受。
        C/S模式如下图所示。
        
        C/S模式
        优点:
        .客户端和服务器分离,允许网络分步操作;二者的开发也可分开同时进行。
        .一个服务器可以服务于多个客户端。
        缺点:
        .客户端与服务器的通信依赖于网络,可能成为整个系统运作的瓶颈;客户端的负荷过重,难以管理大量的客户端,系统的性能受到很大影响。
        .如果服务器及其界面定义有改变,则客户端也要做相应改变。
        .二层C/S模式采用单一服务器,以局域网为中心,难以扩展至广域网或Internet。
        .数据安全性不好。
        发展:
        C/S模式适用于分布式系统,得到了广泛应用。为了解决客户端的访问问题,发展形成了浏览器/服务器(B/S)模式;为了解决服务器端的问题,发展形成了三层(多层)C/S模式,即多层应用架构。
 
       架构设计
        WebApp描述了使WebApp达到其业务目标的基础结构,典型使用多层架构来构造,包括用户界面或展示层、基于一组业务规则来指导与客户端浏览器进行信息交互的控制器,以及可以包含WebApp的业务规则的内容层或模型层,描述将以什么方式来管理用户交互、操作内部处理任务、实现导航及展示内容。模型-视图-控制器(Model-View-Controller,MVC)结构是WebApp基础结构模型之一,它将WebApp功能及信息内容分离。
 
       软件架构
        随着嵌入式技术的发展,特别是在后PC时代,嵌入式软件系统得到了极大的丰富和发展,形成了一个完整的软件体系,如下图所示。这个体系自底向上由3部分组成,分别是嵌入式操作系统、支撑软件和应用软件。
        
        嵌入式系统的软件架构
        嵌入式操作系统(Embedded Operating System,EOS)由操作系统内核、应用程序接口、设备驱动程序接口等几部分组成。嵌入式操作一般采用微内核结构。操作系统只负责进程的调度、进程间的通信、内存分配及异常与中断管理最基本的任务,其他大部分的功能则由支撑软件完成。
        嵌入式系统中的支撑软件由窗口系统、网络系统、数据库管理系统及Java虚拟机等几部分组成。对于嵌入式系统来讲,软件的开发环境大部分在通用台式计算机和工作站上运行,但从逻辑上讲,它仍然被认为是嵌入式系统支撑软件的一部分。支撑软件一般用于一些浅度嵌入的系统中,如智能手机、个人数字助理等。
        嵌入式系统中的应用软件是系统整体功能的集中体现。系统的能力总是通过应用软件表现出来的。
 
       软件架构设计
        软件架构也称为软件体系结构,需要考虑如何对系统进行分解,对分解后的组件及其之间的关系进行设计,满足系统的功能和非功能需求。软件架构形成过程如下图所示。
        
        架构的形成过程概要
        软件架构设计需要从用户业务需求、未来应用环境、需求分析、硬件基础、接口输入、数据处理、运算或控制规律、用户使用等方面进行综合、权衡和分析基础上产生。面向某种问题的架构一旦确定就很难改变,随后的架构设计需要通过一系列的迭代开发完善,使得软件架构日趋成熟、稳定。
        软件架构的重要作用也在于控制一个软件系统的使用、成本和风险。好的架构要求是和谐的软件架构,包括与上一级系统架构相互和谐、与系统中同一级的其他组件架构互相和谐,确保系统满足性能、可靠性、安全性、信息安全性和互操作性等方面的关键要求,也具有可扩展、可移植性,从而为一个软件带来长久的生命力。
        在大量开发实践中,有很多广泛使用并被普遍接受的软件架构设计原则,这些原则独立于具体的软件开发方法,主要包括抽象、信息隐藏、强内聚和松耦合、关注点分离等。
        (1)抽象:这是软件架构的核心原则,也是人们认识复杂客观世界的基本方法。抽象的实质是提取主要特征和属性,从具体的事务中通过封装来忽略细节,并且运用这些特征和属性,描述一个具有普遍意义的客观世界。软件架构设计中需要对流程、数据、行为等进行抽象。复杂系统含有多层抽象,从而有多个不同层次架构。
        (2)信息隐藏:包括局部化设计和封装设计。局部化设计就是将一个处理所涉及到的信息和操作尽可能地限制在局部的一个组件中,减少与其他组件的接口。而封装设计是将组件的外部访问形式尽可能简单、统一。
        (3)强内聚和松耦合:强内聚是指软件组件内的特性,即组件内所有处理都高度相关,所有处理组合在一起才能组成一个相对完整的功能。而松耦合是指软件组件之间的特性,软件组件之间应尽量做到没有或极少的直接关系,使其保持相对独立,这样使得未来的修改、复用简单,修改之后带来的影响最小。
        (4)关注点分离:所谓关注点是软件系统中可能会遇到的多变的部分。如为适应不同运行接口条件,需要进行适应性的参数调整和驱动配置。关注点分离设计是将这部分组件设计成为相对独立的部分,使未来的系统容易配置和修改。而核心的部分可以保持一个相对独立的稳定状态。如果功能分配使得单独的关注点组件足够简单,那么就更容易理解和实现。但“展示某些关注点得到满足时,可能会影响到其他方面的关注点,但架构师必须能够说明所有关注点都已得到满足”。
        以上的原则中,删除需求细节或对细节进行抽象是最重要的工作,为用户的需求创建抽象模型,通过抽象将特殊问题映射为更普遍的问题类别,并识别各种模式。
        软件架构设计使用纵向分解和横向分解两种方式。纵向分解就是分层,横向分解就是将每一个层面分成相对独立的部分。经过分解之后,可以将一个完整的问题分解成多个模块来解决。模块是其中可分解、可组装,功能独立、功能高度内聚、之间低耦合的一个组件。
        类似于建筑架构,软件架构也决定了软件产品的好用、易用、可靠、信息安全、可扩展、可重用等特性,好的软件架构也给人完整、明确、清晰等赏心悦目的感觉,具有较长的生命力。
        架构设计是围绕业务需求带来的问题空间到系统解决空间第一个顶层设计方案。按照抽象原则,在这个阶段进行的架构设计关注软件设计环节抽象出来的重要元素,而不是所有的设计元素。在架构设计时将软件这些要素看作是黑盒,架构设计需要满足黑盒的外部功能和非功能需求的目标。一个软件的架构设计首先为软件产品的后续开发过程提供基础,在此基础上可将一个大规模的软件分解为若干子问题和公共子问题。而一般意义的软件设计是软件的底层设计,开发人员需要关注各子问题或要素的进一步分解和实现,是根据架构设计所定义的每个要素的功能、接口,进一步实现要素组件内部的配置、处理和结构。在遵守组件外部属性前提下,考虑实现组件内部的细节及其实现方法。对于其中的公共子问题,形成公共类和工具类,从而可以达到重用的目的。
        一般的软件构架是根据需求自上而下方式来设计,即首先掌握和研究利益相关方的关键需求,基本思路是首先进行系统级的软件架构设计,需要将软件组件与其外部环境属性绑定在一起,关注软件系统与外部环境的交联设计;其次将一个大的系统划分成各组成部分,这些部分可以按照架构设计的不同方法,分为层次或成为模块;之后再开始研究所涉及到的要素,再实现这些要素以及定义这些要素之间的关系。
        在实际工作中,软件构架也可采用自底向上的方法,前提是已经建立了一个成熟稳定的软件架构,也可以称之为“模式”。模式是组织一级设计某一类具体问题的顶层思路,是为了解决共有问题解的方案模板,但并不是一个问题的设计或设计算法。
        模式常常整合在一起使用,提供解决更大、更复杂问题的解决方案,而组成一个解决问题的通用框架。框架往往提供统一平台和开发工具,而且已经高效地利用了已经经过验证的模式、技术和组件。在新软件系统的设计中指定沿用或重用这种架构框架,这时其他重要元素可以在这个架构基础上针对新的需求进行扩展,有时是针对性地进行参数化设计。所以在架构设计中可以借用模式的概念进行设计,采用成熟的先进的设计框架和工具提高开发的效率,保证设计正确性。
        下图所示是针对架构设计中非功能需求的多维度分析,从中可知任何一个因素的变化都会带来对其他因素的影响。实际上软件架构设计属于软件设计过程的一部分,但超越了系统内部的算法和数据结构的详细设计。
        
        架构的多维度分析
        在架构设计阶段,需要定义边界条件、描述系统组织结构、对系统的定量属性进行约束、帮助对模型进行描述并基本构造早期的原型、更准确地描述费用和时间的评估。
   题号导航      2021年下半年 信息系统项目管理师 上午试卷 综合知识   本试卷我的完整做题情况  
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 /
 
第9题    在手机中做本题