一、本章要点

1）信息系统综合知识。包括软件架构的概念、软件架构的风格、特定领域软件架构、基于架构的软件开发方法、软件架构评估、软件产品线；设计模式的概念、设计模式的组成、模式和软件架构、设计模式分类、设计模式的实现。

2）系统架构设计案例分析。包括软件架构技术、XML技术、基于架构的软件开发过程、架构模型（风格）、特定领域软件架构、基于架构的软件开发方法、架构评估、软件产品线、系统演化、设计模式。

3）系统架构设计论文。

二、软件架构概述

1）软件架构是具有一定形式的结构化元素，即构件的集合，包括处理构件、数据构件和连接构件。

2）软件架构是软件设计过程中的一个层次，处理算法与数据结构之上的关于整体系统结构设计和描述方面的一些问题。

3）架构问题包括：总体组织和全局控制、通信协议、同步、数据存取、给设计元素分配特定功能、设计元素的组织、规模和性能、在各设计方案间进行选择等。

4）设计好软件架构是保证软件质量的根本措施，具有以下作用：

  （1）软件架构是项目干系人进行交流的手段。

  （2）软件架构是早期设计决策的体现。

  （3）软件架构是可传递和可重用的模型。

三、软件架构建模

1）首要问题是如何表示软件架构，即如何对软件架构建模，可将软件架构的模型分为5种：

  （1）结构模型。以架构的构件、连接器和其他概念来刻画结构，并力图通过结构来反映系统的配置、约束、隐含的假设条件、风格和性质等。核心是架构描述语言。

  （2）框架模型。侧重于描述整体的结构，主要以一些特殊的问题为目标建立只针对和适应该问题的结构。

  （3）动态模型。对结构或框架模型的补充，研究系统“大颗粒”的行为性质，如系统的重新配置或演化。动态可以值系统总体结构的配置、建立或拆除通信信道或计算的过程。

  （4）过程模型。过程模型研究构造系统的步骤和过程，因而结构是遵循某些过程脚本的结果。

  （5）功能模型。该模型认为架构是由一组功能构件按层次组成，下层向上层提供服务。它可看做是一种特殊的框架模型。

2）Kruchten提出的”4+1″视图模型。

  （1）逻辑视图。主要支持系统的功能需求，即系统提供给最终用户的服务。在面向对象技术中，可以用对象模型来代表逻辑视图。

  （2）开发视图。也称为模块视图，主要侧重于软件模块的组织和管理。

  （3）进程视图。侧重于系统的运行特性，主要关注一些非功能性的需求，例如系统的性能和可用性。

  （4）物理视图。主要考虑如何把软件映射到硬件上，通常要考虑解决系统拓扑结构、系统安装和通信等问题。

  （5）场景。可看作是那些重要系统活动的抽象，它使4个视图有机联系起来，从某种意义上说场景是最重要的需求抽象。

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

3、DSSA与架构风格的比较

1）两者的出发点不同，是互相正交的方法和学科分支：以问题域为出发点的DSSA和一解决域为出发点的软件架构风格。

2）DSSA只对某一个领域进行设计专家知识的提取、存储和组织，但可以同时使用多种架构风格；而在某个架构风格中进行架构设计专家知识的组织时，可以将提取的公共结构和设计方法扩展到多个应用领域。

3）DSSA的特定领域参考架构通常选用一个或多个适合所研究领域的架构风格。不同参考架构之间的基础和概念有较少的共同点。

4）架构风格的定义和该风格应用的领域是正交的，提取的设计知识比用DSSA提取的设计专家知识的应用范围要广。

5）DSSA和架构风格是互为补充的两种技术。

六、架构设计与演化

一个好的软件架构应该可以创建或再创建功能、用户界面和问题域模型，演化原型以满足新的软件需求。不但软件系统以原型方式演化，架构本身也以原型方式演化。

1、设计和演化过程

基于架构的软件开发过程可以分为独立的两个阶段：

1）实验原型阶段。此阶段首要问题是要获得对系统支持的问题域的理解。

2）演化开发阶段。重点在最终产品的开发上。

2、实验原型阶段

1）第一个开发周期没有具体明确的目标，一个小组创建图形用户界面，另一个小组创建一个问题域模型。

2）第二个开发周期任务是设计和建立一个软件架构，此软件架构特征如下：

  （1）必须足够灵活，能包含现有元素且能包含新增功能。

  （2）必须提供一个相当稳定的结构，原型在此实验原型阶段进行演化。

  （3）必须支持一个高效的开发组织，允许所有开发人员并行地在原型的基础上进行开发。

3）第二个开发周期细分为5个小阶段：

  （1）标识构件：生成类图、对类进行分组、把类打包成构件。

  （2）提出软件架构模型。

  （3）把已标识的构件映射到软件架构中。

  （4）分析构件之间的相互作用。

  （5）产生软件架构。

3、演化开发阶段

8个步骤： （1）需求变动归类（2）制订架构演化计划（3）修改、增加或删除构件（4）更新构件的相互作用（5）产生演化后的架构（6）迭代（3）~（5）（7）对以上步骤进行确认（8）对所做的标记进行处理

七、基于架构的软件开发

传统软件开发过程包括问题定义、需求分析、软件设计、软件实现及软件测试等，软件架构的建立应位于需求分析之后，概要设计之前。此模型存在开发效率不高，不能很友好地支持软件重用等缺点，基于架构的软件开发模型可以弥补这个缺点，它有如下几个子过程： 1）架构需求：需求获取、标识构件和需求评审。 2）架构设计：提出软件架构模型、把已标识的构件映射到软件架构中、分析构件之间的相互作用、产生软件架构及设计评审。可迭代。 3）架构文档化：输出架构需求规格说明和测试架构需求的质量设计说明书。 4）架构复审。架构设计、文档化和复审是一个迭代过程。 5）架构实现。 6）架构演化。

八、软件架构评估

在架构评估过程中，评估人员所关注的是系统的质量属性。敏感点和权衡点是关键的架构决策。 敏感点是一个或多个构件（和/或构件之间的关系）的特性。权衡点是影响多个质量属性的特性，是多个质量属性的敏感点。

1、主要的评估方式

1）基于调查问卷或检查表的评估方式。 2）基于场景的评估方式。主要应用在架构权衡分析方法（Architecture Tradeoff Analysis Method，ATAM）和软件架构分析方法（Software Architecture Analysis Method，SAAM）中。采用刺激、环境和响应来描述。刺激时场景中解释或描述项目干系人怎样引发与系统的交互部分，环境描述的是刺激发生时的情况，响应是指系统是如何通过架构对刺激作出反应的。 3）基于度量的评估方式。度量是指为软件产品的某一属性所赋予的数值，如代码行数、方法调用层数和构件个数。首先，建立质量属性和度量之间的映射原则；然后，从软件架构文档中获取度量信息；最后，根据映射原则分析推导出系统的某些质量属性。 4）比较如下：

2、产品线的组织结构

1）软件产品线开发过程分为领域工程和应用工程，相应的软件开发组织结构也应该有两个基本组成部分，即负责核心资源的小组和负责产品的小组。这也是产品线开发与独立系统开发的主要区别。 2）组织模型：开发部门、商务部门、领域工程部门和层次领域工程部门。 3）动态的组织结构，根据产品线的建立方式和发展阶段、成熟程度的变化，有一种组织结构向另一种组织结构演变。

3、产品线的建立方式

划分依据：用演化方式还是革命方式引入产品线开发过程；基于现有产品还是开发全新的产品线。 四种方式的基本特征如下：

3、Web服务架构的优势

1）高度的通用性和易用性。 2）完全的平台、语言独立性。 3）高度的组装性和集成性。 4）容易部署和发布。

十三、面向服务的架构

1、SOA概念

面向服务的架构（Service-Oriented Architecture，SOA）并不仅是一种现成的技术，还是一种架构和组织IT基础结构及业务功能的方法，是一种在计算环境中设计、开发、部署和管理离散逻辑单元（服务）模型的方法。 SOA是一种粗粒度、松耦合的服务架构，其服务之间通过简单、精确定义接口进行通信，不涉及底层编程接口和通信模型，有如下特征： 1）松散耦合 2）粗粒度服务 3）标准化接口

2、面向服务的分析与设计

1）从概念上讲，SOA有三个主要的抽象级别，分别是操作、服务和业务流程。 2）从建模的观点来看，SOA带来的主要挑战是如何描述设计良好的操作、服务和流程抽象的特征以及如何系统地构造它们。 3）OOAD（OOA和OOD）、企业架构（Enterprise Architecture，EA）框架和业务流程建模（Business Process Modeling，BPM）分别从基础设计层、应用结构层和业务组织层三个层次上为SOAD提供了理论支撑。   （1）底层设计层采用OOA和OOD的思想，主要目标是能够进行快速而有效的设计、开发以及执行灵活且可扩展的底层服务构件。   （2）架构层采用EA的理论框架，以努力实现单独的解决方案之间架构的一致性。   （3）业务组织层采用BPM规则，如UML，SOAD的流程建模必须与设计用例保持同步。 4）SOA是一种企业系统架构，它是从企业的业务需求开始的，比其他方法优势在于提供了业务的敏捷性。原则：业务驱动服务，服务驱动技术；业务敏捷是基本的业务需求。

3、Web服务实现SOA

1）底层传输层，HTTP、JMS和SMTP作为Web服务的消息传输协议。 2）服务通信协议层，定义服务之间进行消息传递所需的技术标准，如SOAP协议、REST协议。 3）服务描述层，统一描述服务的接口与消息交换方式，相关标准WSDL。 4）服务层，包装遗留系统，并通过发布WSDL接口描述被定位和调用。 5）业务流程层，支持服务发现，服务调用和点到点服务调用。相关标准WS-BPEL。 6）服务注册层，使服务提供者能通过WSDL发布服务定义，并支持服务请求者查找所需的服务信息，相关标准UDDI。

十四、企业服务总线（Enterprise Service Bus，ESB）

由中间件技术实现并支持SOA的一组基础架构，支持异构环境中的服务、消息以及基于事件的交互，并且具有适当的服务级别和可管理性。 1）使用ESB，可在不改变现有基础结构的情况下让几代技术实现互操作，在几乎不更改代码的情况下以一种无缝的非侵入方式使企业已有的系统具有全新的服务接口，并能够在部署环境中支持任何标准。并且，不同的应用程序可以同时使用同一服务，在应用程序或者数据发生变化时无须改动服务代码。 2）面向服务的企业应用集成机制：   （1）ESB允许在多种形式下通过像HTTP/SOAP和JMS总线的多种传输方式，主要是以网络服务的形式，为发表、注册、发现和使用企业服务或接卖弄提供基础设施。   （2）ESB提供可配置的消息转换翻译机制和基于消息内容的消息路由服务，传输消息道不同的目的地。   （3）ESB挺高安全和拥有者机制以保证消息和服务使用的认证、授权以及完整性。   （4）ESB的服务质量也是可以区分企业集成技术平台优劣的关键标准之一。 3）ESB的优点   （1）扩展的、基于标准的连接。   （2）灵活的、服务导向的应用组合。   （3）提高重用率，降低成本。   （4）减少市场反应时间，提高生产率。

来源：树哥