软件架构模式有哪些（基于组件软件开发架构模式一般在 （ ） 软件开发架构模式中使用）

本文目录

• 基于组件软件开发架构模式一般在 （ ） 软件开发架构模式中使用
• 软件架构中，（　　）模式包括主程序 子程序、数据抽象和面向对象，以及层次结构
• 几种常见的软件体系结构及特点分析(简述5种常见的软件体系结构风格)
• 什么是软件架构模式
• 在典型的软件架构模式中， （ ） 模式是基于资源不对等，为实现共享而提出的
• 软件开发有哪些模式

基于组件软件开发架构模式一般在 （ ） 软件开发架构模式中使用

【答案】：B
软件架构模式有：（1）管道——过滤器模式，适用于批处理系统。（2）面向对象模式，其典型应用是基于组件软件开发。（3）事件驱动模式，其典型应用包括各种图形界面应用。（4）分层模式，如ISO/OSI七层网络模型。（5）C/S模式，该模式中客户与服务器分离，允许网络分布操作。

软件架构中，（　　）模式包括主程序 子程序、数据抽象和面向对象，以及层次结构

【答案】：B
参考《信息系统项目管理师教材（第3版）》P45，软件架构风格，Garlan和Shaw对通用软件架构风格进行了分类，他们将软件架构分为数据流风格、调用／返回风格、独立构件风格、虚拟机风格和仓库风格。
（1）数据流风格：数据流风格包括批处理序列和管道／过滤器两种风格。
（2）调用／返回风格：调用／返回风格包括主程序／子程序、数据抽象和面向对象，以及层次结构。
（3）独立构件风格：独立构件风格包括进程通信和事件驱动的系统。
（4）虚拟机风格：虚拟机风格包括解释器和基于规则的系统。
（5）仓库风格：仓库风格包括数据库系统、黑板系统和超文本系统。

几种常见的软件体系结构及特点分析(简述5种常见的软件体系结构风格)

20世纪60年代的软件危机使得人们开始重视软件工程的研究。起初，人们把软件设计的重点放在数据结构和算法的选择上，然而随着软件系统规模越来越大，对总体的系统结构设计和规格说明变得异常重要。随着软件危机程度的加剧，软件体系结构(software)这一概念应运而生。软件体系结构着眼于软件系统的全局组织形式，在较高层次上把握系统各部分之间的内在联系，将软件开发的焦点从成百上千的代码上转移到粒度较大的体系结构元素及其交互的设计上。与传统软件技术相比，软件体系结构理论的提出不仅有利于解决软件系统日益增加的规模和复杂度的问题，有利于构件的重用，也有利于软件生产率的提高。面向方面软件开发(AOSD)认为系统是由核心关注点(cornconcern)和横切关注点(cross-cuttingconcern)有机地交织在一起而形成的。核心关注点是软件要实现的主要功能和目标，横切关注点是那些与核心关注点之间有横切作用的关注点，如系统日志、事务处理和权限验证等。AOSD通过分离系统的横切关注点和核心关注点，使得系统的设计和维护变得容易很多。

Extremara大学的Navasa等人〔1〕在2002年提出了将面向方面软件开发技术引入到软件体系结构的设计中，称之为面向方面软件体系结构(aspectorientedsoftware，AO-SA)，这样能够结合两者的优点，但是并没有给出构建面向方面软件体系结构的详细方法。

尽管目前对于面向方面软件体系结构这个概念尚未形成统一的认识，但是一般认为面向方面软件体系结构在传统软件体系结构基础上增加了方面构件(aspectcomponent)这一新的构成单元，通过方面构件来封装系统的横切关注点。目前国内外对于面向方面软件体系模型的研究还相对较少，对它的构成单元模型的研究更少，通常只关注方面构件这一构成单元。方面构件最早是由Lieberherr等人〔2〕提出的，它是在自适应可插拔构件(adaptiveplugandplaycomponent，APPC)基础之上通过引入面向方面编程(AOP)思想扩展一个可更改的接口而形成的，但它关于请求接口和服务接口的定义很模糊，未能给出一个清晰的方面构件模型。Pawlak等人〔3〕提出了一个面向方面的框架，该框架主要包含了一个方面构件模型———Java方面构件(Javaaspectcomponent，JAC)，但该方面构件模型仅包含了切点(pointcut)，并把AOP中装备(advice)集成到了切点的表达式中，它主要从实现的角度进行了阐述，并没有给出详细的方面构件模型。本文没有只关注面向方面软件体系结构中方面构件这一构成单元模型，还详细分析了它的另外两个构成单元，即构件和连接件，因为面向方面软件体系结构各部分之间是相互关联的。

1面向方面软件体系结构相关概念

面向方面软件体系结构涉及诸多概念，以下将分别介绍。软件体系结构在软件工程领域有着广泛的影响，但当前仍未形成一个统一的、标准的定义。目前国内外普遍认可的看法是软件体系结构包含构件、连接件和约束〔4〕。其中约束描述了体系结构配置和拓扑的要求，确定了体系结构的构件与连接件的连接关系。这样就可以把软件体系结构写成

软件体系结构(software)=构件(components)

连接件(connectors)约束(constraints)

构件是软件体系结构的基本元素之一。一般认为，构件是指具有一定功能、可明确辨识的软件单位，并且具备语义完整、语法正确、有可重用价值的特点，然而目前对于构件的具体结构及构成并没有一个统一的标准〔5〕，而且一些主要的构件技术也没有使用相同的构件类型。另外，当前被广泛接受的构件定义并不包含具体的软件构件模型(softwarecomponentmodel)。例如，Szyperski等人〔6〕给出了软件构件一个很有名的定义:软件构件是一个仅带特定契约接口和显式语境依赖的结构单位，它可以独立部署，易于第三方整合。但是关于软件构件模型有一个被普遍接受的观点是:软件构件是一个具有服务提供和服务请求功能的软件单元〔7〕。

连接件是软件体系结构另一个基本的构成元素，是用来建立构件间交互以及支配这些交互规则的构造模块。连接件最先是由Shaw〔8〕提出来的，她建议把连接件作为软件体系结构中第一类实体，用来表示普通构件之间的交互关系。目前对于连接件尚未形成统一的认识，尽管在软件体系结构中强调了连接件存在的必要性，但是关于连接件模型的研究还很少，连接件的实际应用还不成熟。

面向方面软件体系结构在传统软件体系结构的基础上增加了方面构件单元。通常认为，方面构件是封装了系统横切关注点的一类特殊的构件。目前关于方面构件模型的研究还处于起步阶段。

2面向方面软件体系结构模型

由于传统软件体系结构模型包含构件、连接件和约束，而面向方面软件体系结构是在传统软件体系结构的基础之上扩展了方面构件，所以面向方面软件体系模型结构包含构件、连接件、方面构件和约束。其中约束描述了面向方面体系结构配置和拓扑的要求，确定了体系结构的构件、连接件和方面构件之间的连接关系，而构件、连接件、方面构件是它的三个基本的构成单元。以下对这三个构成单元的模型进行详细的设计。

什么是软件架构模式

软件架构模式有以下几点：(1)管道/过滤器模式:其典型应用包括批处理系统。(2)面向对象模式:其典型应用是基于组件的软件开发CBD。(3)事件驱动模式:其典型应用包括各种图形界面应用。(4)分层模式:其典型应用是分层通信协议，如ISO/OSI的七层网络模型。(5)客户/服务器模式(Client/Server，C/S):为了解决C/S模式中客户端的问题，发展形成了浏览器/服务器(B/S)模式:为了解决C/S模式中服务器端的问题，发展形成了三层(多层)C/S模式，即多层应用架构。软件架构模式有以下几点：(1)管道/过滤器模式:其典型应用包括批处理系统。(2)面向对象模式:其典型应用是基于组件的软件开发CBD。(3)事件驱动模式:其典型应用包括各种图形界面应用。(4)分层模式:其典型应用是分层通信协议，如ISO/OSI的七层网络模型。(5)客户/服务器模式(Client/Server，C/S):为了解决C/S模式中客户端的问题，发展形成了浏览器/服务器(B/S)模式:为了解决C/S模式中服务器端的问题，发展形成了三层(多层)C/S模式，即多层应用架构。

在典型的软件架构模式中， （ ） 模式是基于资源不对等，为实现共享而提出的

【答案】：D
常见的几种典型架构模式：——管道/过滤器模式：此模式中，每个组件（过滤器）都有一组输入/输出，组件读取输入的数据流，经过内部处理后，产生输出的数据流，该过程主要完成输入流的变换及增量计算。其典型应用包括批处理系统。——面向对象模式：在面向对象的基础上，将模块数据的表示方法及其相应操作封装在更高抽象层次的数据类型或对象中。其典型应用是基于组件的软件开发。——事件驱动模式：其基本原理是组件并不直接调用操作，而是触发一个或多个事件。系统中的其他组件可以注册相关的事件，触发一个事件时，系统会自动调用注册了该事件的组件，即触发事件会导致另一组件中操作的调用。其典型应用包括各种图形界面应用。——分层模式：采用层次化的组织方式，每一层都为上一层提供服务，并使用下一层提供的功能。其典型应用是分层通信协议，如ISO/OSI的七层网络模型。——客户/服务器模式（C/S）：基于资源不对等，为实现共享而提出的模式。C/S模式将应用一分为二，服务器（后台）负责数据操作和事务处理，客户（前台）完成与用户的交互任务。

软件开发有哪些模式

快速原型模型：（需要迅速造一个可以运行的软件原型，以便理解和澄清问题）

快速原型模型允许在需求分析阶段对软件的需求进行初步的非完全的分析和定义，快速设计开发出软件系统的原型（展示待开发软件的全部或部分功能和性能

（过程：用户对该原型进行测试评定，给出具体改善的意见以及丰富的细化软件需求，开发人员进行修改完善）

优点：

克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险

缺点：

A、所选用的开发技术和工具不一定符合主流的发展

B、快速建立起来的系统加上连续的修改可能会造成产品质量底下

增量模型：（采用随着日程时间的进展而交错的线性序列，每一个线性徐磊产生软件的一个可发布的“增量”，第一个增量往往就是核心的产品）

与其他模型共同之处：它与原型实现模型和其他演化方法一样，本质都是迭代

与原型实现模型不同之处：它强调每一个增量均发布一个可操作产品，（它不需要等到所有需求都出来，只要摸个需求的增量包出来即可进行开发）

优点：

1、人员分配灵活，一开始不需要投入大量人力资源

2、当配备人员不能在限定的时间内完成产品时，它可以提供一种先推出核心产品的途径，可现发布部分功能给用户（对用户起镇静作用）

3、增量能够有计划的管理技术风险

缺点：

1、如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析

注：

这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程

原型模型：（样品模型，采用逐步求精的方法完善原型）

主要思想：

先借用已有系统作为原型模型，通过“样品”不断改进，使得最后的产品就是用户所需要的。原型模型通过向用户提供原型获取用户的反馈，使开发出的软件能够真正反映用户的需求，采用方法：

原型模型采用逐步求精的方法完善原型，使得原型能够“快速”开发，避免了像瀑布模型一样在冗长的开发过程中难以对用户的反馈作出快速的响应

优点：

(1）开发人员和用户在“原型”上达成一致。这样一来，可以减少设计中的错误和开发中的风险，也减少了对用户培训的时间，而提高了系统的实用、正确性以及用户的满意程度。

（2）缩短了开发周期，加快了工程进度。

（3）降低成本。

缺点：

1、当重新生产该产品时，难以让用户接收，给工程继续开展带来不利因素。

2、不宜利用原型系统作为最终产品。采用原型模型开发系统，用户和开发者必须达成一致：

喷泉模型：（以用户需求为动力，以对象为驱动的模型，主要用于采用对象技术的软件开发项目）

它认为软件开发过程自下而上周期的各阶段是相互迭代和无间隙的特性

相互迭代：软件的摸个部分常常被重复工作多次，相关对象在每次迭代中随之加入渐进的软件成分

无间隙:它在各项活动之间没有明显边界（如分析和设计活动之间《由于对象概念的应用，表达分析，设计，实现等活动只用对象类和关系》）

优点：

1、可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程

不便之处：

1、由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。

2、这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况

螺旋模型：（适合用于需求经常变化的项目《适合于大型复杂的系统》）

它主要是风险分析与评估，沿着螺线进行若干次迭代，过程：

1、制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件

2、风险分析：分析评估所选方案，考虑如何识别和消除风险

3、实施工程：实施软件开发和验证；

4、客户评估：评价开发工作，提出修正建议，制定下一步计划。

优点：

1、它由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发中

缺点：

1、难以让用户确信这种烟花方法的结果是可以控制的

2、建设周期长（而软件技术发展比较快，所以经常会出现软件开发完毕后，和当前的技术水平有很大的差距，无法满足当前用户的需求）

3、除非软件开发人员擅长寻找可能的风险，准确的分析风险，否则将会带来更大的风险

瀑布模型：（从本质来讲，瀑布模型是一个软件开发架构,重复应用）

（核心思想：按工序将问题化简，将功能的实现与设计分开，便于分工协作，采用结构化的分析与设计方法将逻辑实现与物理实现分开，依照软件生命周期自上而下，相互衔接的次序《如同瀑布流水逐级下落》）

缺点：

1、在项目各个阶段之间极少有反馈，各个阶段的划分完全固定，阶段之间产生大量的文档，增加了工作量

2、用户只有在项目生命周期的后期才能看到结果，增加了开发的风险

3、需要过多的强制完成日期和里程碑来跟踪各个项目的阶段

4、在每个阶段都会产生循环反馈

（如果有信息未被覆盖或是发现问题了，必须返回到上一个阶段《甚至更前面的活动》并进行适当的修改,只有当上一阶段都被确认后才进行下一阶段）

5、早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果

优点：

1、为项目提供了按阶段分的检查点

2、当完成一个阶段后，只需要去关注后续阶段

3、可在迭代模型中应用瀑布模型

按照瀑布模型的阶段划分，软件测试可以分为单元测试，集成测试，系统测试

注：由于每个阶段都会产生循环反馈，对于经常变化的项目而言，瀑布模型毫无价值，这种模型的线性过程太理想化，已不适合现代的软件开发模式