2016年系统架构设计师考试考点,重点,难点汇总资料

软件产品线体系机构

什么是软件产品线？软件产品线在软件开发过程中有什么作用？

定义：软件产品线是一个产品的集合，这些产品共享一个公共的、可管理的特征集，这些特征集能够满足选定市场或任务领域的特定需求。这些系统遵循一个预描述的方式，是在公共的核心资源上开发的。

作用：软件产品线是一个是非适合专业软件开发组织的软件开发方法，能有效提高软件生产率和质量、缩短软件开发时间、降低总开发成本；

主要组成部分：核心资源和产品集合。

核心资源：包括产品线中所有产品共享的产品线体系结构，新设计开发的或通过现有系统再工程得到的、需要在整个产品线中系统化重用的软件构件。

产品线开发的 4 个技术特点：过程驱动、特定领域、技术支持及体系结构为中心。

软件产品线包括哪些过程？如何实现软件产品线创建与演化？软件产品线演化是指什么？如何实现演化？

过程模型：双生命周期模型（领域工程 +应用工程）；SEI模型（核心资源开发+产品开发+管理）和三生命周期（企业工程+领域工程 +应用工程）模型；

4 种建立方式：用演化方式还是革命方式 +基于现有产品还是开发全新产品线

（ 1）将现有产品演化为产品线

（ 2）用软件产品线替代现有产品集

（ 3）全新软件产品线演化

（ 4）全新软件产品线开发

演化:指的是由于各种原因引起产品线所进行的改动而变成新的产品线；

产品线的演化包括：核心资源的演化、产品的演化和产品的版本升级；

框架的定义及特征

定义：框架是由开发人员定制的应用系统的骨架，是整个系统或子系统的可重用设计，由一组抽象构件和构建实例间的交互方式组成；

特征：反向控制；可重用性；扩展性；模块化或构件化；

软件产品线体系结构定义、特点及个性实现机制

定义：软件产品线体系结构是只一个软件开发组织为一组相关应用或产品建立的公共体系结构。

特点：同领域模型一样，软件产品线体系结构中也可分为共性部分和个性部分；共性部分是产品线中所有产品在体系结构上的共享部分，是不可改变的。个性部分是指产品线体系结构可以变化的部分；产品线体系结构设计的目的尽量扩展产品线中所有产品共享的部分，同时提供一个尽量灵活的体系结构变化机制；个性实现机制：继承；扩展和扩展点；参数化；配置和模块互连语言；自动生成；编译时不同实现的选择；

例题：希赛公司各种网络安全防火墙系统，引入产品线开发方法，问题如下：

1.公司是否适合使用软件产品线方法，并说明理由适合软件产品线开发方法；公司的产品特点为：各种防火墙系统属于

一种产品集合，具有很多共性，同时，每种不同的防火墙又具有自己本身的个性特点；

2.在原有产品的基础上建立软件产品线的方式，并简要评价

（1）将现有产品演化为产品线：在基于现有产品体系结构设计产品线体系结构的基础上，将特定产品的构件逐步地、越来越多地转化为产品线的公用构件，从基于产品的方法“慢慢地”转化为基于产品线的软件开发。

主要优点是通过对投资回收期的分解，对现有系统演化的维持使产品线方法的实施风险降到了最低，完成产品线核心资源的总周期和总投资都比使用革命方式要大；

（2）用软件产品线替代现有产品集：基本停止现有产品的开发，所有努力直接针对软件产品线核心资源开发。需求变化会导致初始投资报废的风险加大

3.成功实施软件产品线的主要因素

（1）对该领域的产品开发已具备长期积累的经验；

（2）一个用于构建产品的好的核心资源库；

（3）好的产品线体系结构；

（ 4）好的管理（软件资源、人员组织、过程）支持基于体系结构软件开发

MVC 模式：对于界面可变性设计的要求， MVC 把交互式系统的组成分解成模型、视图和控制器三种构件模型构件：独立于外在显示内容和形式，是软件所处理问题逻辑的内在抽象，它封装了问题的核心数据、逻辑和功能计算关系，独立于具体的界面表达和输入/ 输出操作；

视图构件：把模型数据及逻辑关系和状态信息以特定的形式展示给用户，它从模型获得显示信息，对于相同的信息可以有多个不同的显示视图；

控制器构件：处理用户与软件的交互操作，决定软件的控制流程，确保用户界面和模型间的对应联系，它接收用户的输入，将输入反馈给模型，进而实现对模型的计算控制，它是模型和视图协调工作的部件。设计模式的分类

5 种创建型模式：工厂方法，抽象工厂，建造者，原型及单件；

7 种结构型模式：适配器，桥，组合，外观，装饰，代理，享元模式；

11 种行为型模式：职责链，中介者，对象状态，策略，命令，备忘录，访问者，迭代器，解释器，观察者，模板方法；

MVC 与MVP 的比较

MVC 模式是创建软件很好的途径，它所提倡的一些原则，如，内容和显示分离、隔离模型、视图和控制器的构件等，会使应用程序的体系结构更健壮，更具有扩展性，也会是软件在代码重用和体系结构方面上一

个新的台阶；

MPV : Presenter (呈现器)负责逻辑的处理，模型提供数据，视图负责显示；MVP与MVC的一个重大区

别就是： MVP 不直接使用模型，他们之间的通行时通过呈现器来进行的，所有的交互都发生在呈现器内部，而在 MVC 中视图会直接读取模型数据而不是通过控制器。

中间件技术中间件是一种独立的系统软件或服务程序，分布式应用软件借助这种软件在不同的技术之间共享资源，中间件

位于操作系统之上，管理计算机资源和网络通信，实现应用之间的互操作。主要有下面 6 个基本功能: ( 1) 负责客服机和服务器之间的连接和通信

( 2) 提供应用层不同服务之间的互操作机制

( 3) 提供一个多层体系结构的应用开发和运行平台

( 4) 屏蔽硬件、操作系统、网络和数据库的差异

( 5) 提供应用的负载均衡、高可用、安全机制和管理功能，保证交易的一致性

( 6) 提供一组通用的服务去执行不同的功能中间件的类别

远程过程调用(RPC):客服进程和服务进程通过网络进行通信，相应的存根( Stub)过程和运行支持提供

数据转换和通行服务，从而屏蔽不同的操作系统和网络协议；存根过程用来解码请求消息中的参数，调用相应的服务过程和编码应答消息的返回值。

对象请求代理(ORB)： ORB是CORBA模型的核心组件，它的作用在于提供一个通信框架，透明地在异构的分布式计算环境中传递对象请求； CORBA 对象之间不直接进行通信，对象通过远程存根对运行在本地计算机上的 ORB 发出请求，本地 ORB 使用 IIOP 将该请求传递给其他计算机上的 ORB。

RMI : Java的远程方法调用。

面向消息的中间件： MOM 利用高效可靠的消息传递机制进行平台无关数据交换，并基于数据通信来进行分布式系统的集成，具有 3 个特点:

( 1) 通信程序可以在不同的时间运行 (2) 对应用程序的结构没有约束 (3) 程序与网络复杂性相隔离

事务处理监控器 :交易中间件什么是基于体系机构的设计方法？简要说明基于体系结构的设计方法的生命周期模型及设计步骤？

ABSD 方法为产生软件系统的概念体系结构提供基础，概念体系结构代表了在开发过程中做出的第一个选择，相应地，它是达到系统质量和业务目标的关键，为达到预定功能提供了一个基础。由业务、质量和功能需求的组合驱动 ABSD ， ABSD 设计活动在体系结构驱动已决定就可开始，这意味着需求获取和分析活动还没有完成，就开始了软件设计，分析与设计活动并行；

ABSD 的三个基础：功能的分解；通过体系结构风格来实现质量和业务需求；软件模板的使用； 在ABSD 方法中，必须记录所有做出的决策以及这些决策的原理，这有利于决策的跟踪和决策评审; 功能需求

抽象、用例

质量需求

抽象、质量 因素、体系 结构选项

（1） 标识构件；（生成类图、对类进行分组、把类打包成构件） （2） 提出软件体系结构模型

（3）把构件映射到体系结构中 （4）分析构件之间的相互作用

（5）产生软件体系结构 （6）软件体系结构正交化

体系结构演化过程：

(1) 需求变动归类

(2) 体系结构演化计划 (3) 修改、增加或删除构件 (4) 更新构件的相互作用 (5) 构件组装与测试 (6) 技术评审 (7) 演化后的体系结构

基于体系结构的软件开发模型:

例题：B/S 结构选用.Net 平台还是Java 企业版平台，最终选用 Java 企业版平台。问题如下: 1. 给出两个平台各自具备的优势及两个平台的共有特点（从下面选项中选择） （1） 良好跨平台可移植性支持 （2） 易于部署与配置 （3） 多程序设计语言支持

（4） 良好的 Web 多层应用开发支持 （5） 丰富的多厂商外部支持

（6） 良好的O/R （对象/关系）映射支持 （7） 针对特定平台的优化支持 （8） 良好的源代码以外的可定制性支持 （9） 良好的Web 服务支持

第4页共15页

.Net 平台特点：(2) (3) (7) Java 企业版平台特点：(1) (5) (8) 共有特点：(4) (6) (9)

业务用例

架构师的经验

遗留系统

］需求

----- ? 分析

体系结构需求体系结构设计

体系结构文档化 体系结构复审 体系结构实现体系结构演化

ABSD 方法与生命周期:

体系结构设计过程:

2.分别针对基于EJB的重量级框架和基于 Struts等轻量级框架，说明 MVC模式中的各组件应采用何种构件实现

在基于 EJB 的重量级框架中 ,实现的构件分别为：

模型(Model):由EJB构件实现视图(View):由JSP构件实现控制器(Co ntroller):由Servlet实现

在基于Struts等的轻量级框架中,实现的构件分别为：

模型(Model):由Java Bea n构件实现视图(View):由JSP构件实现控制器(Controller):由Servlet构件实现

3.从组件耦合度、组件分工及开发工程化支持等 3个方面说明 MVP 与 MVC 模式的主要区别

(1)在组件耦合度方面：在 MVP模式中，视图并不直接使用模型，它们之间的通信通过 Presenter进行, 从而实现了视图与模型的分离 ,而在 MVC 模式中 ,视图直接与模型交互。

(2)在组件分工方面:在 MVP 模式中,视图需要处理鼠标及键盘等触发的界面事件 ,而在 MVC 模式中这通常是由控制器完成的工作；在 MVP模式中，系统核心业务逻辑组织集中在 Presenter中，而在MVC模式中 ,相应的控制器通常只完成事件的分发。

(3)在开发工程化支持方面: MVP 模式可更好地支持单元测试 ,而在 MVC 模式中 ,由于模型与视图绑定因此难以实施相应的单元测试；在 MVP模式中,Presenter基于约定接口与视图和模型交互,可更好地支持组件的重用。

4.说明事务的基本特征，并简单描述EJB规范中提供的两种事务控制的方法；

事务的基本特征包括:

原子性:一个事务中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚到事务开始前的状态，就像这个事务从来没有执行过一样。一致性:在事务开始之前和事务结束以后，数据的完整性限制没有被破坏。

隔离性:两个事务的执行是互不干扰的，两个事务时间不会互相影响。持久性:在事务完成以后，该事务对数据所作的更改便持久地保存在数据库之中，并且是完全的。

EJB 规范支持的两种事务控制方法为:

容器维护的事务(Con tai ner Ma naged Tran sactio n, CMT):由EJB容器根据部署描述符或 EJB构件注释中指定的事务属性自动控制事务的边界，容器维护的事务是方法级的，即默认将一个方法当作一个事务执行，当方法执行的过程中发生系统级异常,容器会自动将事务回滚,从而将方法前面执行的结果恢复。

Bean 维护的事务( Bean Managed Transaction， BMT )：由程序员在 EJB 的源代码中控制事务执行的边界，事务的边界通过 Java事务接口( Java Transaction AP, JTA)进行控制，Bean维护的事务可以跨越方法的边界。

软件体系结构评估: 各种软件质量属性

性能 :指系统的响应能力，即要经过多长时间才能对某个事件作出响应或在某段时间系统所处理的事件个数；可靠性：软件系统在应用或错误面前，在意外或错误使用的情况下维持软件系统的功能特性的基本能力。常用的设计方法是：容错、检错、降低系统复杂度；

可用性：系统能够正常运行的时间比例；常用两次故障之间的时间间隔或系统恢复正常的速度来表示；安全性：系统向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力；安全性又可分为：机密性、完整性、不可否认性及可控性等；

可修改性：能够快速地以较高的性能价格比对系统进行变更的能力；

功能性：系统所能完成所期望工作的能力；

可变性：指体系结构经扩充或变更而成为新体系结构的能够；

集成性：指系统与其它系统协作的程度；

互操作性：指系统与其它系统或者自身环境相互作用的能力；如软件体系结构必须为外部可见的功能特性和数据结构提供精心设计的软件入口；

风险点/架构风险：指架构设计中潜在的、存在问题的架构设计决策所带来的隐患；

敏感点：为了实现某个特定的质量属性，一个或多个组件所具有的特性；

权衡点：影响多个质量属性的特性，是多个质量属性的敏感点；

体系结构评估的 3 种方式：

(1)基于调查问卷或检查表的方式(2)基于场景的评估方式(3)基于度量的评估方式ATAM 评估的结果：

(1)已文档化了的体系结构方法或风格 (2)场景及优先级 (3)基于属性的问题 (4) 效用树

(5)所发现的风险决策 (6) 已文档化了的无风险决策 (7) 所发现的敏感点和权衡点

SAAM 评估的步骤：

(1)形成场景(2)描述体系结构； (1) 和( 2)重复进行 (3) 对场景进行分类和确定优先级

(4)对间接场景的单个评估 (5) 评估场景的相互作用 (6) 形成总体评价传统的Web 应用程序存在以下几个缺点：操作复杂性数据复杂性交互复杂性

AJAX 是由几种蓬勃发展的技术以新的方式组合而成的，包含基于 XHTML 和 CSS 标准的表示；使用 DOM 进行动态显示和交互；使用XMLHttpRequest与服务器进行异步通信；使用JavaScript绑定一切；使用AJAX 的最大优点就是能在不更新整个页面的前提下维护数据，这使得Web 系统更为讯接地回应用户动作，并避

免在网络上发送那些没有改变过的信息；

基于服务的体系结构

W3C的定义：SOA是一种应用程序体系结构，在这种体系结构中，所有的功能都定义为独立的服务，这些服务带有定义明确的可调用接口，能够以定义好的顺序这些服务来形成业务流程；

SOA特征：SOA是一种粗粒度、松耦合的服务体系结构，其服务之间通过简单、精确定义接口进行通信，不涉及底层编程接口和通信协议；

SOA服务构件与传统构件的区别：

(1)服务构件往往是粗粒度的，而传统构件以细粒度居多；

(2)服务构件的接口是标准的，主要是服务描述语言接口，而传统构件常以具体API形式出现；

(3)服务构件实现与语言无关，而传统构件常绑定某种特定语言；

(4)服务构件可以通过构件容器提供QoS服务，而传统构件完全由程序控制；

SOA 服务常见设计原则：

(1)明确定义的接口 (2) 自包含和模块化 (3) 粗粒度 (4) 松耦合 (5) 互操作性、兼容和策略声明

SOA 有 3 个主要的抽象级别：操作、服务和业务流程；层次从底向上排列；

SOA 的关键技术

(1)发现服务层：帮助客服端应用程序解析远程服务的位置，同过 UDDI 来实现；通过 UDDI 提供的标准接口，企业可

以发布自己的服务供其他企业查询和调用，也可以查询特定服务的描述信息，并动态绑定到该服务上；

(2)描述服务层：为客服端应用程序提供正确的与远程服务交互的描述信息，主要通过WSDL 来实现；

(3)消息格式层：保证客服端应用程序和服务器端的格式保持一致，一般通过SOAP 来实现；

(4)编码格式层：为客服端和服务器之间提供一个标准的、独立于平台的数据交换编码格式，一般用 XML 来实现；

(5)传输协议层：为客服端和服务器之间提供两者交互的网络通信协议，一般通过HTTP和SMTP来实

现；

SOA 的实现方式一般有：Web Service，企业服务总线和服务注册表;

Web Service的解决方案中，有3中工作角色，分别为：服务提供者，服务请求者及服务注册中心；主要的操作包括：发布、查找和绑定；

服务注册表一般支持：服务注册、服务位置和服务绑定功能；

企业服务总线：ESB是由中间件技术实现并支持 SOA的一组基础体系结构，是传统中间件技术与XML、

Web Service等技术结合的产物，是在整个企业集成体系结构下的面向服务的企业应用集成机制；ESB的主

要功能如下：

(1)服务位置透明性 (2) 传输协议转换 (3) 消息格式转换 (4) 消息路由 (5) 消息增强 (6)安全性 (7)监控和管理

WSDL ：是对服务进行描述的语言，它有一套基于 XML 的语法定义。 WSDL 描述的重点是服务，它包含服务接口定义和服务实现定义；

UDDI :是一种用于描述、发现、集成Web服务的技术，它是Web服务协议栈的一个重要部分；通过UDDI，企业可以根据自己的需要动态查找并使用服务，也可以将自己的Web服务动态地发布到 UDDI注册中心，

供其它用户使用；

SOAP :以XMI形式提供一个简单、轻量的用于在分散或分布环境中交换结构化和类型信息的机制；可以将 SOAP 简单理解为： SOAP=HTTP+RPC+XML ，也就是采用 HTTP 作为底层通信协议， RPC 作为通用的调用途径， XML 作为数据打包的格式，提供了一个能够穿越防火墙的通信交互能力；

REST ( Representational State Transfe，表述性状态转移)是一种只是用 HTTP和XML进行基于 Web通信的技术，可以降低开发的复杂性，提高系统的可伸缩性。

数据库是以单一数据资源为中心，其目的是及时、安全将当前事务所产生的记录保存下来；而数据仓库是

指一个面向主题的、稳定的、集成的、随时间变化的数据集合，用以支持经营管理中的决策制定过程，数据在进入数据仓库之前，经过加工和集成，以实现将原始数据从面向应用到面向主题的转变；

动态软件体系结构由于系统需求、技术、环境、和分布等因素的变化而最终导致软件体系结构变动，成为软件体系结构演化；

动态软件系统的形式化描述包括：软件体系结构的描述、体系结构的重新配置和系统行为描述。对动态软件体系结构的形式化描述，通常可以采用图形化方法、进程代数方法、逻辑方法等；

XML 是一套定义语义标记的规则，这些标记将文档分成许多部件并对这些部件加以标识。它也是元标记语言，用于定义其它特定领域有关的、语义的、结构化的标记语言的句法语言；

UML 是用于系统的可视化建模语言，而不是一种方法；其中并不包括过程的概念，其本身是独立于过程的，可以在任何过程中使用它。不过与 XML 结合最好的是用例驱动的、以体系结构为中心的、迭代的、增量的开发过程。

UML 中的 3 中基本构造块：事物、关系和图；

UML 中的事物也称建模元素，包括：结构事物、行为事物、分组事物、注释事物；

UML 中的主要 4 中关系：依赖、关联(聚合、组合) 、泛化和实现；

顺序图强调消息的时间次序；通信图强调收发消息的对象或者角色的结构组织 (即：消息流经的数据结构) 二者都表达的类似的概念；定时图强调消息跨越不同对象或角色的时间时间；交互概览图是活动图和顺序图的混合物；状态图描述一个状态机，由状态、转移、事件和活动组成；活动图专注于系统的动态视图，强调对象间的控制流程。适合用于表述在不同用例之间的(单个)对象行为。

ADL 是这样一种形式化语言，它在底层语言模型的支持下，为软件系统的概念体系结构建模提供了具体语法和概念框架。 3 个基本元素为：构件、连接件和体系结构配置；

软件体系结构风格软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。体系结构风格定义了一系统家族，即一个体系结构定义一个词汇表和一组约束。词汇表中包含了一些构件和连接件类型，而约束指出系统如何将这些构件和连接件组合起来的。体系结构风格反映了领域中众多系统共有的结构和语义特性，并指导如何将各个模块和子系统有效组织成一个完整的系统。

体系结构风格 4 要素内容：一个词汇表、一套配置规则、定义一套语义解释原则和定义对基于这种风格的系统所进行的分析。常见 5 个风格分类：

(1)数据流风格：批处理序列、管道与过滤器；

(2)调用/返回风格：主程序与子程序、面向对象风格、层次风格；

(3)独立构件风格：进程通信、事件系统；

(4)虚拟机风格：解释器、基于规则的系统；

(5)仓库风格：数据库系统、超文本系统、黑板系统

常见具体风格解析：

管道与过滤器：每个构件(过滤器)都有一组输入和输出，构件读输入的数据流，进过内部处理，然后产生输出数据流；输出数据流输入管道(连接件) ，作为下一个过滤器的输入；过滤器必须是独立的实体，在

输入数据流没输入完之前，可能输出数据流已经产生了；常见例子：器；

UNIX Shell 编写的程序、传统的编译

特点：

(1)使得软构件具有良好的隐蔽性和高内聚、低耦合的特点；

(2)可将整个系统看成多个过滤器行为的简单合成；

(3)支持软件(过滤器)重用；

(4)系统维护和增强系统性能简单；

(5)支持并行执行；

缺点：

(1)导致进程成为批处理结构；

(2)不适合处理交互应用；

(3)过滤器增加了解析和合成数据的工作，导致系统性能下降；

面向对象风格：数据的表示方法和它们相应的操作封装在一个抽象数据类型或对象中，这种风格的构件是对象，或者说是抽象数据类型的实例；

基于事件的隐式调用风格的主要特点是：事件的触发者并不知道哪些构件会被这些事件影响。这样不能假定构件的处理顺序，甚至不知道哪些过程会被调用，因此，许多隐式调用的系统也包含显式调用作为构件交互的补充形式。常见的例子是：在编程环境中用于集成各种工具，在数据库系统中确保数据的一致性约束，在用户界面中的管理数据，以及在编辑器中支持语法检查；

优点：

(1)为软件重用提供了强大支持；(2) 为改进系统带来了方便；

缺点：

(1)构件放弃了对计算构件的控制；(2) 数据交换的问题； (3)正确性的的推理存在问

题；

分层系统

层次系统组织成一个层次结构，每一层为上层服务，并作为下层的客户。每一次最多影响相邻的两层，只要给相邻两层提供相同的接口，便允许每层用不同的方法实现，同样为软件重用提供了强大的支持。

特点：

(1)支持基于抽象程度递增的系统设计；(2)功能的改变最多影响相邻两层；

(3)支持重用；

不足：

(1)并不是每个系统都能够很容易的划分为多层模式；(2)很难找到一个合适的、正确的抽象层次方法；仓库系统及知识库在仓库风格中，有两种不同的构件：中央数据结构说明当前状态，独立构件在中央数据存储上执行，仓库与外构件间的相互作用在系统中会有大的变化；。

黑板系统的传统应用是信号处理领域，如语音和模式识别，另一应用是松耦合数据共享存取；黑板系统的 3 个组成部分：

(1)知识源；

(2)黑板数据结构；

(3)控制；控制完全由黑板的状态驱动，黑板状态的改变决定使用特定的知识源；

C2 风格

C2 体系结构风格可以概括为：通过连接件绑定在一起的按照一组规则运作的并行构件网络；组织规则如下：

(1)构件和连接件都有一个顶部和底部；

(2)构件的顶部连接到某连接件的底部，构件的底部则应连接都某连接件顶部；构件之间不允许之间连

接；

(3)一个连接件可连接任意数目的构件和连接件；

(4)当两个构件直接连接时，必须是其中一个的底部到另一个的顶部；

特点：

(1)系统的构件能够实现应用需求，并能将任意复杂度的功能封装在一起；

(2)构件通信通过以连接件为中介的异步消息交换来实现；

(3)构件相对独立，构件之间依赖少；

C/S 与B/S 体系结构

C/S 体系结构的优点在于系统的客户应用程序和服务器构件分别运行在不同的计算机上，系统中每台服务器

都可以适应各构件的要求，这对于硬件和软件的变化显示出极大的适应性和灵活性，易于对系统进行扩充

或缩小；C/S结构具有强大的数据操作和事物处理能力，模型思想简单，易于人们理解和接收；由于软件复

杂度的不断提高， C/S 结构也暴露出下列缺点：

(1)开发成本高。客户端软硬件配置要求高

(2)客户端程序设计复杂；

(3)信息内容和形式单一；

(4)用于界面风格不一，不利于推广；

(5)软件移植困难；

(6)软件维护和升级困难；

(7)新技术不能轻易应用；

两层C/S结构局限：难以扩展至大型企业广域网或In ternet;软硬件的组合及集成能力有限；客服机负荷太

重；数据安全性不好；因此三层 C/S 结构应运而生；

与两层C/S结构相比，三层C/S结构增加了一个应用服务器。可以将整个应用逻辑驻留在服务器上，而只有表示层存在于客户机上；

表示层：应用的用户接口部分，它担负卓用户和应用间的对话功能；功能层：相当于应用的本体，它将具体的业务逻辑编入程序中；数据层：就是数据库管理系统，负责管理对数据库数据的读写；在三层 C/S 体系结构中，中间件事最重要的构件。所谓中间件是一个用 API 定义的软件层，是具有强大通信能力和良好可扩展性的分布式软件管理框架。它的功能是在客服机和服务器或服务器之间出送数据，实现客服机群和服务器群之间的通信。

目前已有的3中分布式构件标准： Microsoft的DCOM，OMG的CORBA和SUN公司的EJB;

三层 C/S 结构特点：

(1)允许合理地划分三层结构的功能，使之在逻辑上保持相对独立性，是整个系统逻辑结构更为清晰，提高了系统的可

维护性和可扩展性;

(2)允许灵活选用相应的平台和硬件系统，且各组成部分具有良好的可升级性和开放性；

(3)应用的各层可并行开发，提高效率；

(4)充分利用功能层有效地隔离表示层和数据层，提高了系统安全；

B/S 体系结构利用不断成熟的 WWW 浏览器技术，结合浏览器的多种脚本语言，用通用浏览器就实现了原

来需要复杂的专用软件才能实现的强大功能，节约了开发成本；B/S结构是一种全新的软件体系结构；系统

的安装、修改和维护全在服务器端解决；用户仅用一个浏览器就可以运行全部的模块，达到了“零客服端的目的，容易升级。同时，B/S结构还提供了异种机、已种网、已种应用服务的联机、联网、统一服务的最现实开放性基础。

与 C/S 相比， B/S 的不足：

(1)没有有效集成数据库的处理能力；

(2)系统扩展性差，安全性难以控制；

(3)数据查询相应速度远低于 C/S 结构；

(4)数据动态交互性不强，不利于在线事物处理 (OLTP) ；

公共对象请求代理体系结构

CORBA 是由 OMG 制定的一个工业标准，其主要目标是提供一种机制，使得对象可以透明地发出请求和获得应答，从而建立起

一个异质的分布式应用环境。其中的 ORB 是一个关键的通信机制，它以实现互操作性为主要目标，处理对象之间的消息发布。

CORBA技术规范主要包括：接口定义语言IDL，接口池IR,动态调用接口DII和对象适配器OA。

CORBA 定义了一种面向对象的软甲构造方法，是不同的应用可以共享由此构造出来的软件构件。每个对象将其内部操作细节封装起来，同时向外界提供精确定义的接口，从而降低了应用系统的复杂性，也降低了软件开发费用。 CORAB 的平台无关性实现了对象跨平台引用，开发人员可以在更大范围内选择最实用的对象加入到自己的应用系统中。 CORBA 的语言无关性使开发人员可以在更大范围内相互利用别人的编程技能和成果。

CORBA 特点

(1)引入中间件作为事务代理，完成客服机想服务对象方提出的业务请求；

(2)实现客服和服务对象的完全分离；

(3)提供软总线机制，使得在任何环境下、采用任何语言开发的软件只要符合接口规范的定义，均能集成到分布式系统

中；

(4)采用棉线对象的软件方法开发应用系统；

CORBA 主要作用：提供运行环境；提供通信机制；提供通用服务；

层次消息总线 ( HMB ： Hierarchy Message Bus) 消息总线是系统的连接件，负责消息的分派、传递、和过滤以及处理结果的返回。各个构件挂接在消息总线上，向总线登记感兴趣的消息类型。

遗留系统：指基本上不能进行修改和演化以满足新的变化了的业务需求的信息系统；特点如下：

(1)系统虽然能够完成企业中许多重要的业务管理工作，但已经不能完全满足要求；

(2)系统在性能上已经落后，采用的技术过时；

(3)通常是大型的软件系统，融入了企业的业务运行和管理决策机制中，维护困难；

(4)没用使用现代软件工程方法进行管理和开发，基本上没问题，很难理解；

特定领域软件体系结构

DSSA :在一个特定应用领域中，为一组应用提供组织结构参考的标准体系结构。

DSSA 的基本活动：领域分析、设计及实现。领域分析的主要目标是获得领域模型，其描述的是领域中系统

之间的共同需求；领域设计的目的是为了 DSSA ,表示模型在中需求的解决方案；领域实现的主要目标是依

据领域模型和 DSSA 开发和组织可重用信息。

DSSA的人员：领域专家提供领域中系统的需求规约和实现知识；领域分析人员控制整个领域分析过程，把获取的知识组织到领域模型中；领域设计人员控制软件设计过程开发出DSSA ；领域实现人员主要开发可重

用构件；

DSSA 的建立过程：

(1)定义领域范围；

(2)定义领域特定元素；

(3)定义领域特定的设计和实现需求约束；

(4)定义领域模型和体系结构；

(5)产生、搜集可重用产品单元；

DSSA的建立过程是并发的、递归和反复进行的。该过程的目的是将用户的需要反射为基于实现约束集合的软件需求，这些需求定义了 DSSA;

DSSA的三层系统模型

(1)领域开发环境，对应领域架构师；

(2)领域特定应用开发环境，对应应用工程师;

(3)应用执行环境，对应操作员；

软件危机的表现: (1)软件成本日益增加；(2)开发进度难以控制；(3)软件质量差；(4)软件维护困难；

原因：

⑴用户需求不明确；(2 )缺乏正确的理论指导；(3)软件规模越来越大；⑷软件复杂度越来越高;

构件是指语义完整、语法正确和有可重用价值的软件单元

构件获取方法：

(1)从现有构件中获取符合要求的构件，直接使用或作适应性修改，得到重用构件;

(2)通过遗留工程将具有潜在重用价值的构件提取出来；

(3)商业构件(COTS: Commercial Off-The-Shell )

(4)新开发符合要求的构件；

构件管理的内容包括：构件描述、构件分类、构件库组织、人员及权限管理和用户意见反馈; 构件分类方法：关键字分类法、刻面分类法、超文本组织方法；

构件重用的工作：检索和提取构件，理解和评价构件，修改构件，将构件组装到软件产品中构件的组装可分为：基于功能(程序调用和参数传递)的组装；基于数据(核心数据结构设计出一个框架) 的组装和面向对象(封装、继承和多态特性)的组装技术；

软件体系结构定义：为软件系统提供一个结构、行为和属性的高级抽象；由构成系统的元素的描述、元素

的相互作用、指导元素集成的模式及这些模式的约束组成。软件体系结构不仅指定了系统的组织结构和拓扑结构，并显示了系统需求和构成系统元素之间的对应关系，提供了一下设计决策的基本原理。作用如下：

(1)风险承担进行交流的手段；

(2)早期设计决策的体现；

(3)是可传递的和可重用的模型；

软件体系结构在软件开发中为不同的人员提供了共同的交流语言，体现并尝试了系统早期的设计决策，并作为系统设计的抽象，为实现框架和构件的共享和重用、基于体系结构的软件开发提供了有力的支持；

“ 4+1” 视图模型

逻辑视图 ( logic view )：主要支持系统的功能需求；在面向对象技术中，通过抽象、封装和继承，可以用对

象模型来代表逻辑视图，用类图来描述逻辑视图；

开发视图 ( development view )：也称模块视图，侧重于软件模块的组织和管理；

进程视图(process view)：也称并发视图，侧重于系统运行时特性，主要关注一些非功能性的要求，如系统的性能和可用性；

物理视图 ( physical view )：考虑如何把软件映射到硬件上，通常考虑系统的性能、规模和可靠性等；解决系统拓扑结构、系统安装、通信等问题；

场景/用例视图 (scenarios) ：系统中重要活动的抽象，它使其它 4 个视图有机联系起来；

逻辑视图和开发视图描述系统的静态结构，而进程视图和物理视图描述系统的动态结构。

体系结构的核心模型由 5 种元素组成：构件、连接件、配置(构件和连接件的拓扑逻辑和约束) 、端口和角色；主要为前 3 种元素；

需求是指用户对目标软件系统在功能、性能、行为和设计约束等方面的期望，需求过程主要是获取用户需求，确定系统中要用到的构件；

体系结构需求包括：需求获取、生成类图、对类分组、把类打包成构件和需求评审等过程；