常见的构件(component，组件)的定义如下：

定义 1:构件是指软件系统中可以明确辨识的构成成分。而可复用构件(reusable component)是指具有相对独立的功能和可复用价值的构件。
定义 2:构件是一个组装单元，它具有约定式规范的接口及明确的依赖环境。
定义 3:构件是软件系统中具有相对独立功能、可以明确辨识、接口由契约指定、和语 境有明显依赖关系、可独立部署的可组装软件实体。

一、商用构件标准规范

1.CORBA

CORBA(Common ObjectRequest Broker Architecture，公共对象请求代理架构)主要分为 3 个层次:对象请求代理、公共对象服务和公共设施。

CORBA CCM(CORBA ComponentModel，CORBA 构件模型)是 OMG 组织制定的一个用 于开发和配置分布式应用的服务器端构件模型规范，它主要包括如下 3 项内容。
(1)抽象构件模型:用以描述服务器端构件结构及构件间互操作的结构。
(2)构件容器结构:用以提供通用的构件运行和管理环境，并支持对安全、事务、持 久状态等系统服务的集成。
(3)构件的配置和打包规范:CCM 使用打包技术来管理构件的二进制、多语言版本的 可执行代码和配置信息，并制定了构件包的具体内容和文档内容标准。

2.J2EE

在分布式互操作协议上，J2EE 同时支持 RMI(Remote Method Invocation，远程方法调用) 和 IIOP(Internet Inter-ORB Protocol，互联网内部对象请求代理协议)，而在服务器端分布式 应用的构造形式，则包括了 Java Servlet、JSP、EJB 等多种形式，以支持不同的业务需求， 而且 Java 应用程序具有跨平台的特性，使得 J2EE 技术在发布计算领域得到了快速发展。

3.DNA 2000

Microsoft DNA 2000 是 Microsoft 在推出 Windows 2000 系列操作系统平台的基础上， 在扩展了分布计算模型，以及改造 Back Office 系列服务器端分布计算产品后发布的新的分 布计算架构和规范。在服务器端，DNA 2000 提供了 ASP、COM、Cluster 等的应用支持。

二、应用系统簇与构件系统

除专门开发构件的企业外，开发应用系统的企业也会发展自己的构件应用体系:通常是 随着企业的不断成熟，逐步从已开发的应用系统中整理出来一些构件，反过来，将这些构件 复用到优化与整合已有应用系统中或复用于开发新的应用系统。

应用系统和构件系统都是系统产品(而不是工作产品)。它们都可以采用模型和结构的 类型定义出来。一般情况下，构件系统只在开发单位内部使用，而应用系统提供给外部客户， 与应用系统相比，构件系统具有通用性，可复用性，这就要求构件系统的开发过程应当实施 更为严格的工程规范。

应用系统可以向构件系统输入构件(构件的需求源于应用系统或应用系统中的模块)，反 过来，构件系统向应用系统输出构件。这就是构件系统如何获得构件和如何提供构件的方式。

三、基于复用开发的组织结构

基于复用的开发组织与传统的开发组织结构不同，它需要有一部分用于开发可复用资产 的资源，这部分资源应同具体应用系统的开发资源分开，以确保不被占用。

一种较平衡的组织结构如图所示，它有三类职能部门:一是构件系统开发部门， 它开发可复用资产;二是应用系统项目开发部(多个)，它复用资产;三是支持部门，这个 部门是可选的，它进一步隔离上述两主体部门，虽然牺牲了一些效率，但保证了构件的规范 性。它的主要职责是对构件开发部门所提供的可复用资产进行确认、对构件库进行分类编目、 向开发应用系统的工程师们发通告和分发可复用资产、提供必要的文档、从复用者处收集反 馈信息和缺陷报告。

一方面，构件开发者应当尽量接近应用开发者，以使其开发出的构件能尽量符合实际需 要;另一方面，构件开发者与应用开发者分属两个并列的部门，使构件开发者能摆脱应用项 目的日常压力，保证可复用资产的开发和持续改进。复用经理应当在构件开发和应用 项目开发利益之间进行权衡，保证长期目标不受近期项目压力的影响。

软件架构评估是在对架构分析、评估的基础上，对架构策略的选取进行决策。它也可以灵活地运用于对软件架构进行评审等工作中。

一、软件架构评估的方法

业界已开发出多种软件架构评估的方法，按基于的技术手段来看，可以分为三类:基于调查问卷或检查表的方式、基于场景的方式和基于度量的方式。

(1)基于调查问卷或检查表的方式

该方式的关键是要设计好问卷或检查表，它充分 利用系统相关人员的经验和知识，获得对架构的评估。其缺点是在很大程度上依赖于评估人 员的主观推断。

(2)基于场景的方式

基于场景的方式由 SEI 首先提出并应用在架构权衡分析法 (Architecture Tradeoff Analysis Method，ATAM)和软件架构分析方法(Software Architecture Analysis Method，SAAM)中。它是通过分析软件架构对场景(也就是对系统的使用或修改 活动)的支持程度，从而判断该架构对这一场景所代表的质量需求的满足程度。

(3)基于度量的方式

它是建立在软件架构度量的基础上的，涉及三个基本活动，首 先需要建立质量属性和度量之间的映射原则，即确定怎样从度量结果推出系统具有什么样的 质量属性;然后从软件架构文档中获取度量信息;最后根据映射原则分析推导出系统的质量 属性。它能提供更为客观和量化的质量评估，但它对评估人员及其使用的技术有较高 的要求。ATAM 中也使用了度量的思想(度量效用)。

二、架构的权衡分析法

从技术角度对软件架构进行评估，旨在通过分析来预见软件的质量;通过分析来创建、 选择、评估与比较不同的架构。

ATAM 方法不但能够揭示架构如何满足特定的质量需求(例如，性能和可修改性)，而且还 提供了分析这些质量需求之间交互作用的方法。使用 ATAM 方法评价一个软件架构的目的 是理解架构设计满足系统质量需求的结果。

ATAM 产生如下结果。
(1)一个简洁的架构表述:ATAM 的一个要求是在一小时内表述架构，这样就得到了 一个简洁、可理解的、面向普通项目关系人的架构表述。它是从架构文档中提炼形成的。
(2)表述清楚的业务目标。
(3)用场景集合捕获质量需求。
(4)架构决策到质量需求的映射。
(5)所确定的敏感点和权衡点集合。
(6)有风险决策和无风险决策。
(7)风险主题的集合。
(8)产生一些附属结果。
(9)还产生一些无形结果，如能够使项目关系人产生“团队感”，提供了一个交流平台和沟通渠道，使大家更好地理解架构(优势及弱点)。

ATAM 的 9 个步骤如下。
(1)ATAM 方法的表述:评估负责人向参加会议的项目代表介绍 ATAM(简要描述 ATAM步骤和评估的结果)。
(2)商业动机的表述。
(3)架构的表述。
(4)对架构方法进行分类。
(5)生成质量属性效用树。
根——质量属性——属性求精(细分)——场景(叶)。修剪这棵树，保留重要场景(不超过 50 个)，再对场景按重要性给定 优先级(用 H/M/L 的形式)，再按场景实现的难易度来确定优先级(用 H/M/L 的形式)， 这样对所选定的每个场景就有一个优先级对(重要度，难易度)，如(H，L)表示该场景重要且易实现。
(6)分析架构方法。
评估小组按优先级对上述效用树的场景进行分析(小组成员提问，设计师回答、解释)，探查实现场景的架构方法。
(7)集体讨论并确定场景的优先级。
(8)分析架构方法。
(9)结果的表述。

结果的表述包括：
已编写了文档的架构方法;
经过讨论得到的场景集合及其优先级;
效用树;
所发现的有风险决策;
已编成文档的无风险决策;
所发现的敏感点和权衡点。

三、成本效益分析法

成本效益分析法(the Cost Benefit Analysis Method，CBAM)是在 ATAM 上构建，用来对架构设计决策的成本和收益进行建模，是优 化此类决策的一种手段。CBAM 的思想就是架构策略影响系统的质量属性，反过来这些质量 属性又会为系统的项目关系人带来一些收益(称为“效用”)，CBAM 协助项目关系人根据其 投资回报(ROI)选择架构策略。CBAM 在 ATAM 结束时开始，它实际上使用了 ATAM 评 估的结果。

CBAM 的步骤如下。

(1)整理场景。

整理 ATAM 中获取的场景，根据商业目标确定这些场景的优先级，并 选取优先级最高的 1/3 的场景进行分析。

(2)对场景进行求精。

为每个场景获取最坏情况、当前情况、期望情况和最好情况的 质量属性响应级别。

(3)确定场景的优先级。

项目关系人对场景进行投票，其投票是基于每个场景“所期 望的”响应值，根据投票结果和票的权值，生成一个分值(场景的权值)。

(4)分配效用。

对场景的响应级别(最坏情况、当前情况、期望情况和最好情况)确 定效用表。

(5)策略—场景—响应级别

架构策略涉及哪些质量属性及响应级别，形成相关的策略—场景—响应级别的对 应关系。

(6)确定“期望的”效用表

使用内插法确定“期望的”质量属性响应级别的效用。即根据第 4 步的效用表以 及第 5 步的对应关系，确定架构策略及其对应场景的效用表。

(7)计算各架构策略的总收益。

根据第 3 步的场景的权值及第 6 步的架构策略效用 表，计算出架构策略的总收益得分。

(8)确定选取策略的优先级

根据受成本限制影响的 ROI(Return On Investment，投资报酬率)选择架构策略。 根据开发经验估算架构策略的成本，结合第 7 步的收益，计算出架构策略的 ROI，按 ROI 排 序，从而确定选取策略的优先级。

软件企业追求长远的发展，通常采用产品线模型及系统演化策略，它实质上是用架构技 术构建产品线，并在此基础上借助复用技术持续演化，不断地推出新产品，满足市场追求产 品升级换代的需求。

一、复用与产品线

软件产品线是指一组软件密集型系统，它们共享一个公共的、可管理的特性集，满足某 个特定市场或任务的具体需要，是以规定的方式用公共的核心资产集成开发出来的。即围绕 核心资产库进行管理、复用、集成新的系统。

核心资产库包括软件架构及其可剪裁的元素， 更广泛地，它还包括设计方案及其文档、用户手册、项目管理的历史记录(如预算和进度)、 软件测试计划和测试用例。

可复用的资 产非常广，包括以下几点。

1
2
3
4
5
6
7
8
9
10

需求
架构设计
元素:元素复用不只是简单的代码复用，它旨在捕获并复用设计中的可取之处，避免(不要 重复)设计失败的地方。
建模与分析
测试：如测试用例、测试数据、测试工具，甚至 测试计划、过程、沟通渠道都可以得到复用。
项目规划：利用经验对项目的成本、预算、进度及开发小组的安排等进行预测，即不必每次 都建立工作分解结构。
过程、方法和工具
人员
样本系统:将已部署(投产)的产品作为高质量的演示原型和工程设计原型。
缺陷消除:产品线开发中积累的缺陷消除活动，可使新系统受益

二、基于产品线的架构

软件产品线架构是针对一系列产品而设计的通用架构，并在此基础上，进一步将系列产 品共用的模块事先实现，供直接重用;将架构用框架的形式予以实现，供定制使用。这就是 通常所说的“平台”。

产品线架构较之单个产品架构，有如下三点特别之处:
(1)产品线架构必须考虑一系列明确许可的变化;
(2)产品线架构一定要文档化;
(3)产品线架构必须提供“产品创建者指南”(开发指南)，描述架构的实例化过程。

产品线的软件架构应将不变的方面提出来，同时， 识别允许的变化，并提供实现它们的机制。通常应考虑三个方面。
(1)确定变化点
(2)支持变化点
(3)对产品线架构的适宜性进行评估。

三、产品线的开发模型

开发(确定)产品线的方法有两种模型:
(1)“前瞻性”产品线:利用在应用领域的经验、对市场和技术发展趋势的了解及商业 判断力等进行产品线设计，它反映了企业的战略决策。通常是自上而下地采用产品线方法。
(2)“反应性”模型:企业根据以前的产品构建产品家族，并随着新产品的开发，扩展
架构和设计方案，它的核心资产库是根据“已经证明”为共有、而非“预先计划”为共有的 元素构建的。通常是自下而上地采用产品线方法。

四、特定领域软件架构

架构的本质在于其抽象性。它包括两个方面的抽象:业务抽象和技术抽象。其中业务抽 象面向特定的应用领域。

特定领域软件架构(Domain Specific Software Architecture，DSSA)可以看做开发产品线 的一个方法(或理论)，它的目标就是支持在一个特定领域中有多个应用的生成。

DSSA 的 必备特征有:
(1)一个严格定义的问题域或解决域;
(2)具有普遍性，使其可以用于领域中某个特定应用的开发;
(3)对整个领域的合适程度的抽象;
(4)具备该领域固定的、典型的在开发过程中的可复用元素。

从功能覆盖的范围角度理解 DSSA 中领域的含义有两种方法:
(1)垂直域。定义了一个特定的系统族，导出在该领域中可作为系统的可行解决方案的一个通用软件架构。
(2)水平域。定义了在多个系统和多个系统族中功能区域的共有部分，在子系统级上涵盖多个系统(族)的特定部分功能。

DSSA 的活动阶段如下。
(1)领域分析:主要目标是获得领域模型。即通过分析领域中系统的需求(领域需求)，确定哪些需求是被领域中的系统广泛共享的，从而建立领域模型。
(2)领域设计:这个阶段的目标是获得 DSSA，它是一个能够适应领域多个系统的需求的一个高层次的设计。由于领域模型中的领域需求具有一定的变化性，DSSA 也要相应地 具有变化性，它可以通过表示多选一的、可选的解决方案等来做到这一点。
(3)领域实现:主要目标是依据领域模型和 DSSA 开发与组织可复用信息。这些复用 信息可以是从现有系统中提取得到的，也可能通过新的开发得到。这个阶段可以看作复用基 础设施的实现阶段。

领域模型的主要作用如下:
(1)领域模型为需求定义了领域知识和领域词汇，这较之单一的项目需求更有较好的 大局观;
(2)软件界面的设计往往和领域模型关系密切;
(3)领域模型的合理性将严重影响软件系统的可扩展性;
(4)在分层架构的指导下，领域模型精化后即成为业务层的骨架;
(5)领域模型也是其数据模型的基础;
(6)领域模型是团队交流的基础，因为它规定了重要的领域词汇表，并且这些词汇的定义是严格的、大家共同认可的。

五、架构及系统演化

架构虽然为系统的变化提供了一定的自由度，但是系统的较大变化必然导致架构的改变。 架构(系统)演化是指向既定的方向、可控地改变。架构(系统)演化可以形成产品线，反 过来，架构(系统)可以在规划的产品线中进行演化。

架构(系统)演化过程包含 7 个步骤：
(1)需求变动归类。首先，必须对用户需求的变化进行归类，使变化的需求与已有构 件对应。对找不到对应构件的变动，也要做好标记，在后续工作中，将创建新的构件，以对 应这部分变化的需求。
(2)制订架构演化计划。在改变原有结构之前，开发组织必须制订一个周密的架构演 化计划，作为后续演化开发工作的指南。
(3)修改、增加或删除构件。在演化计划的基础上，开发人员可根据在第(1)步得到 的需求变动的归类情况，决定是否修改或删除存在的构件、增加新构件。最后，对修改和增 加的构件进行功能性测试。
(4)更新构件的相互作用。随着构件的增加、删除和修改，构件之间的控制流必须得 到更新。
(5)构件组装与测试。通过组装支持工具把这些构件的实现体组装起来，完成整个软 件系统的连接与合成，形成新的架构。然后，对组装后的系统整体功能和性能进行测试。
(6)技术评审。对以上步骤进行确认，进行技术评审。评审组装后的架构是否反映需 求变动，符合用户需求。如果不符合，则需要在第(2)到第(6)步之间进行迭代。
(7)产生演化后的架构。在原来系统上所作的所有修改必须集成到原来的架构中，完 成一次演化过程。

软件架构设计的一个核心问题是能否使用重复的软件架构模式，即能否达到架构级别的 软件重用。

架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。

只要系统是使用常用的、规范的方法来组织，就可使别的设计者很容易地理解系统的架构。

一、软件架构风格分类

架构风格的最关键的四要素内容：

1
2
3
4

提供一个词汇表
定义一套配置规则
定义一套语义解释原则
定义对基于这种风格的系统所进行的分析

二、数据流风格

批处理序列;管道/过滤器。

这样的架构下，所有的数据按照流的形式在执行过程中前进，不存在结构的反复和重构。

在流动过程中，数据经过序列间的数据处理组件进行处理，然后将处理结果向后传送，最后进行输出。

1. 批处理序列

批处理风格的每一步处理都是独立的，并且每一步是顺序执行的。只有当前一步处理完，后一步处理才能开始。数据传送在步与步之间作为一个整体。(组件为一系列固定顺序的计 算单元，组件间只通过数据传递交互。每个处理步骤是一个独立的程序，每一步必 须在前一步结束后才能开始，数据必须是完整的，以整体的方式传递)

批处理的典型应用:
(1)经典数据处理;
(2)程序开发;
(3)Windows 下的 BAT 程序就是这种应用的典型实例。

2. 管道和过滤器

在管道/过滤器风格的软件架构中，每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理，然后产生输出数据流。这个过程通常通过对输入流的变换及增量计算来 完成，所以在输入被完全消费之前，输出便产生了。

管道/过滤器架构的例子:
(1)以 UNIX shell 编写的程序；
(2)传统的编译器。

优点：

(1)使得软构件具有良好的隐蔽性和高内聚、低耦合的特点;
(2)允许设计者将整个系统的输入/输出行为看成是多个过滤器的行为的简单合成;
(3)支持软件重用
(4)系统维护和增强系统性能简单
(5)允许对一些如吞吐量、死锁等属性的分析;
(6)支持并行执行

缺点

(1)通常导致进程成为批处理的结构
(2)不适合处理交互的应用
(3)因为在数据传输上没有通用的标准，每个过滤器都增加了解析和合成数据的工作， 这样就导致了系统性能下降，并增加了编写过滤器的复杂性。

3.批处理序列风格与管道过滤器风格对比

共同点:把任务分成一系列固定顺序的计算单元(组件)。组件间只通过数据传递交互。

区别:批处理是全部的、高潜伏性的，输入时可随机存取，无合作性、无交互性。而管道过滤器是递增的，数据结果延迟小，输入时处理局部化，有反馈、可交互。批处理强调数据传送在步与步之间作为一个整体，而管理过滤器无此要求。

三、调用/返回风格

主程序/子程序;面向对象风格;层次结构。

利用调用-返回实际上是一种分而治之的策略，其主要思想是将一个复杂的大系统分解为一些子系统，以便降低复杂度，并且增加可修改性。

1. 主程序/子程序

主程序/子程序风格是结构化开发时期的经典架构风格。这种风格一般采用单线程控制，把问题划分为若干处理步骤，构件即为主程序和子程序。

2. 面向对象风格

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

这种风格的两个重要特征为:
(1)对象负责维护其表示的完整性;
(2)对象的表示对其他对象而言是隐蔽的。

优点

(1)因为对象对其他对象隐藏它的表示，所以可以改变一个对象的表示，而不影响其他的对象;
(2)设计者可将一些数据存取操作的问题分解成一些交互的代理程序的集合。

缺点

(1)为了使一个对象和另一个对象通过过程调用等进行交互，必须知道对象的标识。只要一个对象的标识改变了，就必须修改所有其他明确调用它的对象;
(2)必须修改所有显式调用它的其他对象，并消除由此带来的一些副作用。例如，如果 A 使用了对象 B，C 也使用了对象 B，那么，C 对 B 的使用所造成的对 A 的影响可能是料想不到的。

3. 层次结构风格

层次系统组织成一个层次结构，每一层为上层服务，并作为下层客户。在一些层次系统中，除了一些精心挑选的输出函数外，内部的层只对相邻的层可见。

这种风格支持基于可增加抽象层的设计。允许将一个复杂问题分解成一个增量步 骤序列的实现。由于每一层最多只影响两层，同时只要给相邻层提供相同的接口，允许每层 用不同的方法实现，同样为软件重用提供了强大的支持。

层次系统最广泛的应用是分层通信协议。

优点

(1)支持基于抽象程度递增的系统设计，使设计者可以把一个复杂系统按递增的步骤进行分解;
(2)支持功能增强，因为每一层至多和相邻的上下层交互，因此功能的改变最多影响相邻的上下层;
(3)支持重用。只要提供的服务接口定义不变，同一层的不同实现可以交换使用。这样，就可以定义一组标准的接口，而允许各种不同的实现方法。

缺点

(1)并不是每个系统都可以很容易地划分为分层的模式，甚至即使一个系统的逻辑结构是层次化的，出于对系统性能的考虑，系统设计师不得不把一些低级或高级的功能综合起来;
(2)很难找到一个合适的、正确的层次抽象方法。

四、独立构件风格

进程通信;事件系统。

独立构件风格主要强调系统中的每个构件都是相对独立的个体，它们之间不直接通信，以降低耦合度，提升灵活性。

1. 进程通信架构风格

构件是独立的过程，连接件是消息传递。这 种风格的特点是构件通常是命名过程，消息传递的方式可以是点到点、异步和同步方式及远 过程调用等。

2. 事件系统风格

基于事件的隐式调用风格的思想是构件不直接调用一个过程，而是触 发或广播一个或多个事件。系统中的其他构件中的过程在一个或多个事件中注册，当一个事 件被触发，系统自动调用在这个事件中注册的所有过程。

基于事件的隐式调用风格的主要特点是事件的触发者并不知道哪些构件会被这些事件影响。

优点

(1)为软件重用提供了强大的支持。当需要将一个构件加入现存系统中时，只需将它注册到系统的事件中。
(2)为改进系统带来了方便。当用一个构件代替另一个构件时，不会影响到其他构件的接口。

缺点

(1)构件放弃了对系统计算的控制。一个构件触发一个事件时，不能确定其他构件是否会响应它。而且即使它知道事件注册了哪些构件的过程，它也不能保证这些过程被调用的顺序。
(2)数据交换的问题。有时数据可被一个事件传递，但另一些情况下，基于事件的系统必须依靠一个共享的仓库进行交互。在这些情况下，全局性能和资源管理便成了问题。
(3)既然过程的语义必须依赖于被触发事件的上下文约束，关于正确性的推理存在问题。

五、虚拟机风格

解释器;基于规则的系统。

虚拟机风格的基本思想是人为构建一个运行环境，在这个环境之上，可以解析与运行自定义的一些语言，这样来增加架构的灵活性。

1.解释器

一个解释器通常包括完成解释工作的解释引擎，一个包含将被解释的代码的存储区，一 个记录解释引擎当前工作状态的数据结构，以及一个记录源代码被解释执行进度的数据结构。

解释器通常被用来建立一种虚拟机以弥合程序语义与硬件语义之间的差异。其缺点是执行效率较低。

2. 规则为中心

基于规则的系统包括规则集、规则解释器、规则/数据选择器及工作内存。

六、仓库风格

数据库系统;超文本系统;黑板系统。

1.数据库系统

数据库架构是库风格最常见的形式。构件主要有两大类，一个是中央共享数据源，保存当前系统的数据状态;另一个是多个独立处理元素，处理元素对数据元素进行操作。

2.超文本系统

超文本系统的典型代表，就是早期的静态网页。

3.黑板系统

黑板系统是一种问题求解模型，是组织推理的步骤、控制状态数据和问题求解之领域知识的概念框架，它将问题的解空间组织成一个或多个应用相关的分级结构。分级结构的每一层信息由一个唯一的词汇来描述，它代表了问题的部分解。

黑板系统主要由三部分组成:
(1)知识源。知识源中包含独立的、与应用程序相关的知识，知识源之间不直接进行 通信，它们之间的交互只通过黑板来完成。
(2)黑板数据结构。黑板数据是按照与应用程序相关的层次来组织的解决问题的数据， 知识源通过不断地改变黑板数据来解决问题。
(3)控制。控制完全由黑板的状态驱动，黑板状态的改变决定使用的特定知识。

架构模式也称为架构风格，它是适当地选取战术的结果，这些固定的结果(模式)在高 层抽象层次上具有普遍实用性和复用性。

通过架构模式，架构设计师可以借鉴和复用他人的经验，看看类似的问题别人是如何解 决的。但不要把模式看成是一个硬性的解决方法，它只是一种解决问题的思路。

“模式和业务构件的区别就在于模式会引发你的思考。”

1.演变交付生命周期

在生命周期模型中，架构设计就是从初步的需求分析开始逐步进行循环迭代。即:一方面在了解系统需求前，不能开始设计架构;另一方 面，刚开始进行设计架构时并不需要等到全部需求都收集到。

架构由少数关键需 求决定并在循环迭代中处于基本稳定状态，它作为演变的基础设施。

2.属性驱动设计法

模型强调先建立软件架构，再把架构作为骨架，在骨架上循环迭代，逐步长出有血 有肉的系统之躯。

属性驱动设计法(Attribute-Driven Design，ADD)就是一种定义软件架构 的方法，该方法将分解过程建立在软件必须满足的质量属性之上。

ADD 的输入为:功能需 求(一般表示为用例)、限制条件和质量需求(一组特定于系统的质量场景)。

ADD 的步骤如下：
(1)选择要分解的模块。
(2)根据如下步骤对模块进行求精:

1
2
3
4
5

从具体的质量场景和功能需求集合中选择架构驱动因素。
选择满足架构驱动因素的架构模式，根据前面的战术创建(或选择)模式。
实例化模块并根据用例分配功能，使用多个视图进行表示。
定义子模块的接口。
验证用例和质量场景，并对其进行求精，使它们成为子模式的限制。

(3)对需要进一步分解的每个模块重复上述步骤。

3.按架构组织开发团队

像软件系统一样，开发小组也应该努力做到松耦合、高内聚。

项目计划在架构确定之后可以结合分工进一步明细化，特别要规划好接口提供的 时间点，保证项目开发的整体协调性。

4.开发骨架系统

演变交付生命周期模型中有两个循环，第一个循环是通过迭代的方式开发出软件架构， 第二个循环是在架构的基础上通过迭代的方式开发出交付的最终版本。开发骨架系统就是第 二个循环的第一步。

5.利用商用构件进行开发

模式本来就是针对特定问题的解，因此，针对需求的特点，也可以选用相应的模式来设 计架构，并利用对应于该模式的商用构件进行软件开发。例如可以使用 J2EE/EJB 进行开发 面向对象的分布式系统。

一、二层及三层 C/S 架构风格

二层架构

C/S 架构是基于资源不对等，且为实现共享而提出来的，是 20 世纪 90 年代成熟起来 的技术，C/S 结构将应用一分为二，服务器(后台)负责数据管理，客户机(前台)完成与 用户的交互任务。

二层架构优点

具有强大的数据操作和事务处理能力，模型思想简单，易于人们理解和接受

二层架构缺点

单一服务器且以局域网为中心
软、硬件的组合及集成能力有限;
服务器的负荷太重，难以管理大量的客户机，系统的性能容易变坏;
数据安全性不好。

三层架构

三层 C/S 结构是 将应用功能分成表示层、功能层和数据层三个部分。

二、B/S架构风格

浏览器/服务器(Browser/Server，简称 B/S)风格就是上述三层应用结构的一种实现方 式，其具体结构为:浏览器/Web 服务器/数据库服务器。

在 B/S 结构中，除了数据库服务器外，应用程序以网页形式存放于 Web 服务器上，用户运行某个应用程序时只需在客户端上的浏览器中键入相应的网址，调用 Web 服务器上 的应用程序并对数据库进行操作完成相应的数据处理工作，最后将结果通过浏览器显示给用 户。可以说，在 B/S 模式的计算机应用系统中，应用(程序)在一定程度上具有集中特征。

B/S架构优点

B/S 架构主要是利用不断成熟的 WWW 浏览器技术，结合浏览器的多种脚本语言，用 通用浏览器就实现了原来需要复杂的专用软件才能实现的强大功能，并节约了开发成本。

B/S架构缺点

与 C/S 架构相比，B/S 架构也有许多不足之处，例如:
(1)B/S 架构缺乏对动态页面的支持能力，没有集成有效的数据库处理功能。
(2)采用 B/S 架构的应用系统，在数据查询等响应速度上，要远远地低于 C/S 架构。
(3)B/S 架构的数据提交一般以页面为单位，数据的动态交互性不强，不利于在线事 务处理(OnLine Transaction Processing，简称 OLTP)应用。

三、MVC 架构风格

MVC 全名是 Model ViewController，是模型(model)-视图(view)-控制器(controller)的 缩写，它是分层架构风格的一种。

MVC 提出的基本思想是进行关注点分 离。一个典型的人机交互应用具有三个主要的关注点:数据在可视化界面上的呈现、UI 处 理逻辑和业务逻辑。

传统的自治视图模式(即将与 UI 相关的逻辑都定义在针对视图 的相关元素的事件上)，将三者混合在一起会带来一下问题：

(1)业务逻辑是与 UI 无关的，应该最大限度地被重用。由于业务逻辑定义在自治视 图中，相当于完全与视图本身绑定在一定，如果我们能够将 UI 的行为抽象出来，基于抽象 化 UI 的处理逻辑也是可以被共享的。但是定义在自治视频中的 UI 处理逻辑完全丧失了重 用的可能。
(2)业务逻辑具有最强的稳定性，UI 处理逻辑次之，而可视化界面上的呈现最差(比如我们经常会为了更好地呈现效果来调整 HTML)。如果将具有不同稳定性的元素融为一体，那么具有最差稳定性的元素决定了整体的稳定性。
(3)任何涉及 UI 的组件都不易测试。UI 是呈现给人看的，并且用于人机交互，用机 器来模拟活生生的人来对组件实施自动化测试不是一件容易的事，自治视图严重损害了组件 的可测试性。

四、MVP 架构风格

MVP 是从经典的模式 MVC 演变而来。

MVC 模式中元素之间“混乱”的交互主要体现在允许 View 和 Model 直接进行“交流”，这在 MVP 模式中是不允许的。

MVP 不仅仅避免了 View 和 Model 之间的耦合，还进一步降低了 Presenter 对 View 的依赖。

MVP 的优点

(1)模型与视图完全分离，我们可以修改视图而不影响模型。 (2)可以更高效地使用模型，因为所有的交互都发生在一个地方—Presenter 内部。
(3)我们可以将一个 Presenter 用于多个视图，而不需要改变 Presenter 的逻辑。这个特性非常的有用，因为视图的变化总是比模型的变化频繁。
(4)如果我们把逻辑放在 Presenter 中，那么我们就可以脱离用户接口来测试这些逻辑(单元测试)。

MVP 的缺点

（1）由于对视图的渲染放在了 Presenter 中，所以视图和 Presenter 的交互会过于频繁。
（2）如果 Presenter 过多地渲染了视图，往往会使得它与特定的视图的联系过 于紧密。一旦视图需要变更，那么 Presenter 也需要变更了。

迄今为止，对于面向服务的架构(Service-Oriented Architecture，SOA)还没有一个公认 的定义。许多组织从不同的角度和不同的侧面对 SOA 进行了描述，较为典型的有以下三个:

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

(2)Service-architecture.com 的定义:服务是精确定义、封装完善、独立于其他服务 所处环境和状态的函数。SOA 本质上是服务的集合，服务之间彼此通信，这种通信可能是 简单的数据传送，也可能是两个或更多的服务协调进行某些活动。服务之间需要某些方法进 行连接。

(3)Gartner 的定义:SOA 是一种 C/S 架构的软件设计方法，应用由服务和服务使用 者组成，SOA 与大多数通用的 C/S 架构模型不同之处，在于它着重强调构件的松散耦合， 并使用独立的标准接口。

一、SOA概述

SOA 是一种在计算环境中设计、开发、部署和管理离散逻辑单元(服务)模型的方法。 SOA 并不是一个新鲜事物，而只是面向对象模型的一种替代。虽然基于 SOA 的系统并不排 除使用 OOD 来构建单个服务，但是其整体设计却是面向服务的。由于 SOA 考虑到了系统 内的对象，所以虽然 SOA 是基于对象的，但是作为一个整体，它却不是面向对象的。

在 SOA 模型中，所有的功能都定义成了独立的服务。服务之间通过交互和协调完成业 务的整体逻辑。所有的服务通过服务总线或流程管理器来连接。这种松散耦合的架构使得各 服务在交互过程中无需考虑双方的内部实现细节，以及部署在什么平台上。

1. 服务的基本结构

服务模型的表示层从逻辑层分离出来，中间增加了服务对外的接 口层。通过服务接口的标准化描述，使得服务可以提供给在任何异构平台和任何用户接口使 用。这允许并支持基于服务的系统成为松散耦合、面向构件和跨技术实现，服务请求者很可 能根本不知道服务在哪里运行、是由哪种语言编写的，以及消息的传输路径，而是只需要提 出服务请求，然后就会得到答案。

2.SOA 设计原则

在 SOA 架构中，继承了来自对象和构件设计的各种原则。

关于服务，一些常见的设计原则如下:

(1)明确定义的接口。

服务请求者依赖于服务规约来调用服务，因此，服务定义必须 长时间稳定，一旦公布，不能随意更改;服务的定义应尽可能明确，减少请求者的不适当使 用;不要让请求者看到服务内部的私有数据。

(2)自包含和模块化。

服务封装了那些在业务上稳定、重复出现的活动和构件，实现 服务的功能实体是完全独立自主的，独立进行部署、版本控制、自我管理和恢复。

(3)粗粒度。

服务数量不应该太多，依靠消息交互而不是远程过程调用，通常消息量 比较大，但是服务之间的交互频度较低。

(4)松耦合。

服务请求者可见的是服务的接口，其位置、实现技术、当前状态和私有 数据等，对服务请求者而言是不可见的。

(5)互操作性、兼容和策略声明。

为了确保服务规约的全面和明确，策略成为一个越 来越重要的方面。

3. 服务构件与传统构件

服务构件架构(Service Component Architecture，SCA)是基于 SOA 的思想描述服务之间组合和协作的规范，它描述用于使用 SOA 构建应用程序和系统的模型。它可简化使用 SOA 进行的应用程序开发和实现工作。SCA 提供了构建粗粒度构件的机制，这些粗粒度构 件由细粒度构件组装而成。SCA 将传统中间件编程从业务逻辑分离出来，从而使程序员免 受其复杂性的困扰。它允许开发人员集中精力编写业务逻辑，而不必将大量的时间花费在更 为底层的技术实现上。

SCA 服务构件与传统构件的主要区别在于，服务构件往往是粗粒度的，而传统构件以 细粒度居多;服务构件的接口是标准的，主要是服务描述语言接口，而传统构件常以具体 API 形式出现;服务构件的实现与语言是无关的，而传统构件常绑定某种特定的语言;服务构件 可以通过构件容器提供 QoS 的服务，而传统构件完全由程序代码直接控制。

二、SOA 的关键技术

SOA 是一种全新的架构，为了支持其各种特性，相关的技 术规范不断推出。与 SOA 紧密相关的技术主要有 UDDI、WSDL、SOAP 和 REST 等，而这 些技术都是以 XML 为基础而发展起来的。

1. UDDI

UDDI(Universal DescriptionDiscovery and Integration，统一描述、发现和集成)提供了 一种服务发布、查找和定位的方法，是服务的信息注册规范，以便被需要该服务的用户发现 和使用它。UDDI 规范描述了服务的概念，同时也定义了一种编程接口。通过 UDDI 提供的 标准接口，企业可以发布自己的服务供其他企业查询和调用，也可以查询特定服务的描述信 息，并动态绑定到该服务上。

UDDI包括：
(1)数据模型。UDDI 数据模型是一个用于描述业务组织和服务的 XML Schema。
(2)API。UDDI API 是一组用于查找或发布 UDDI 数据的方法，UDDI API 基于 SOAP。
(3)注册服务。UDDI 注册服务是 SOA 中的一种基础设施，对应着服务注册中心的角
色。

2.WSDL

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

服务实现定义描述了给定服务提供者如何实现特定的服务接口。服务实现定义中包含服 务和端口描述。一个服务往往会包含多个服务访问入口，而每个访问入口都会使用一个端口 元素来描述，端口描述的是一个服务访问入口的部署细节，例如，通过哪个地址来访问，应 当使用怎样的消息调用模式来访问等。

3.SOAP

SOAP(Simple ObjectAccess Protocol，简单对象访问协议)定义了服务请求者和服务提 供者之间的消息传输规范。SOAP 用 XML 来格式化消息，用 HTTP 来承载消息。通过 SOAP， 应用程序可以在网络中进行数据交换和远程过程调用(Remote Procedure Call， RPC)

SOAP 主要包括以下四个部分:

(1)封装。SOAP 封装定义了一个整体框架，用来表示消息中包含什么内容，谁来处 理这些内容，以及这些内容是可选的还是必需的。
(2)编码规则。SOAP 编码规则定义了一种序列化的机制，用于交换系统所定义的数 据类型的实例。
(3)RPC 表示。SOAP RPC 表示定义了一个用来表示远程过程调用和应答的协议。
(4)绑定。SOAP 绑定定义了一个使用底层传输协议来完成在节点之间交换 SOAP 封 装的约定。

SOAP 消息包括以下三个部分:

(1)封装(信封)。封装的元素名是 Envelope，在表示消息的 XML 文档中，封装是顶 层元素，在 SOAP 消息中必须出现。
(2)SOAP 头。SOAP 头的元素名是 Header，提供了向 SOAP 消息中添加关于这条 SOAP 消息的某些要素的机制。
(3)SOAP 体。SOAP 体的元素名是 Body，是包含消息的最终接收者想要的信息的容 器。

4.REST

REST(RepresentationalState Transfer，表述性状态转移)是一种只使用 HTTP 和 XML 进 行基于 Web 通信的技术，可以降低开发的复杂性，提高系统的可伸缩性。它的简单性和缺 少严格配置文件的特性，使它与 SOAP 很好地隔离开来，REST 从根本上来说只支持几个操 作(POST、GET、PUT 和 DELETE)，这些操作适用于所有的消息。

REST 提出了如下一些设 计概念和准则:
(1)网络上的所有事物都被抽象为资源。
(2)每个资源对应一个唯一的资源标识。
(3)通过通用的连接件接口对资源进行操作。
(4)对资源的各种操作不会改变资源标识。
(5)所有的操作都是无状态的。

三、SOA 的实现方法

SOA 只是一种概念和思想，需要借助于具体的技术和方法来实现它。从本质上来看， SOA 是用本地计算模型来实现一个分布式的计算应用，也有人称这种方法为“本地化设计，分布式工作”模型。CORBA、DCOM 和 EJB 等都属于这种解决方式。

从逻辑上和高层抽象来看，目前，实现 SOA 的方法也比较多，其中主流方式有 Web Service、企业服务总线和服务注册表。

1.Web Service

在 Web Service(Web 服务)的解决方案中，一共有三种工作角色，其中服务提供者和 服务请求者是必需的，服务注册中心是一个可选的角色。

在采用 Web Service 作为 SOA 的实现技术时，应用系统大致可以分为六个层次，分别 是底层传输层、服务通信协议层、服务描述层、 服务层、业务流程层和服务注册层。

(1)底层传输层。

底层传输层主要负责消息的传输机制，HTTP、JMS(Java Messaging Service，Java 消息服务)和 SMTP 都可以作为服务的消息传输协议，其中 HTTP 使用最广。

(2)服务通信协议层。

服务通信协议层的主要功能是描述并定义服务之间进行消息传 递所需的技术标准，常用的标准是 SOAP 和 REST 协议。

(3)服务描述层。

服务描述层主要以一种统一的方式描述服务的接口与消息交换方式， 相关的标准是 WSDL。

(4)服务层。

服务层的主要功能是将遗留系统进行包装，并通过发布的 WSDL 接口描 述被定位和调用。

(5)业务流程层。

业务流程层的主要功能是支持服务发现，服务调用和点到点的服务 调用，并将业务流程从服务的底层调用抽象出来。

(6)服务注册层

服务注册层的主要功能是使服务提供者能够通过 WSDL 发布服务定义，并支持服 务请求者查找所需的服务信息。相关的标准是 UDDI。

2. 服务注册表

服务注册表(service registry)虽然也具有运行时的功能，但主要在 SOA 设计时使用。

服务注册表可以包括有关服务和相关构件的配置、依从性和 约束文件。

大多数商用服务注册产品支持服务注册、服务位置和服务绑定功能。

3. 企业服务总线ESB

ESB 是由中间件技术实现并支持 SOA 的一组基础架构，是传统中间件技术与 XML、 Web Service 等技术结合的产物，是在整个企业集成架构下的面向服务的企业应用集成机制。

ESB 具有以下功能:
(1)支持异构环境中的服务、消息和基于事件的交互，并且具有适当的服务级别和可 管理性。
(2)通过使用 ESB，可以在几乎不更改代码的情况下，以一种无缝的非侵入方式使现 有系统具有全新的服务接口，并能够在部署环境中支持任何标准。
(3)充当缓冲器的 ESB(负责在诸多服务之间转换业务逻辑和数据格式)与服务逻辑 相分离，从而使不同的系统可以同时使用同一个服务，不用在系统或数据发生变化时，改动 服务代码。
(4)在更高的层次，ESB 还提供诸如服务代理和协议转换等功能。允许在多种形式下 通过像 HTTP、SOAP 和 JMS 总线的多种传输方式，主要是以网络服务的形式，为发表、注 册、发现和使用企业服务或界面提供基础设施。
(5)提供可配置的消息转换翻译机制和基于消息内容的消息路由服务，传输消息到不 同的目的地。
(6)提供安全和拥有者机制，以保证消息和服务使用的认证、授权和完整性。

与现存的、专有的集成解决方案相比，ESB 具有以下优势:

(1)扩展的、基于标准的连接。ESB 形成一个基于标准的信息骨架，使得在系统内部
和整个价值链中可以容易地进行异步或同步数据交换。ESB 通过使用 XML、SOAP 和其他标 准，提供了更强大的系统连接性。
(2)灵活的、服务导向的应用组合。基于 SOA，ESB 使复杂的分布式系统(包括跨多 个应用、系统和防火墙的集成方案)能够由以前开发测试过的服务组合而成，使系统具有高 度可扩展性。
(3)提高复用率，降低成本。按照 SOA 方法构建应用，提高了复用率，简化了维护 工作，进而减少了系统总体成本。
(4)减少市场反应时间，提高生产率。ESB 通过构件和服务复用，按照 SOA 的思想 简化应用组合，基于标准的通信、转换和连接来实现这些优点。

四、微服务

它属于面向服务架构的一种。
微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小 的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进 程中，服务与服务间采用轻量级的通信机制互相沟通(通常是基于 HTTP 协议的 RESTful API)。每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环 境等。

另外，应当尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根 据业务上下文，选择合适的语言、工具对其进行构建。

所以总结起来，微服务的核心特点为:小, 且专注于做一件事情、轻量级的通信机制、松耦合、独立部署。

1.微服务的优势

(1)技术异构性

在微服务架构中，每个服务都是一个相对独立的个体，每个服务都可以选择适合于自身 的技术来实现。

同时，在应用新技术时，微服务架构也提供了更好的试验场。

(2)弹性

弹性主要讲的是系统中一部分出现故障会引起多大问题。
微服务架构中，每个服务可以内置可用性的解决方 案 与功能降级方案，所以比单块系统强。

(3)扩展

在微服务架构中，可以针对单个服务进行扩展。

(4)简化部署

在大型单块系统中，即使修改一行代码，也需要重新部署整个应用系统。
微服务架构中，每个服务的部署都是独立的，这样就可以更快地对特定部分的代码进行部署。

(5)与结织结构相匹配

微服务架构可以将架构与组织结构相匹配，避免出现过大的代码库，从而获得 理想的团队大小及生产力。服务的所有权也可以在团队之 间迁移，从而避免异地团队的出 现。

(6)可组合性

在微服务架构中，系统会开放很多接口供外部使用。当情况发生改变时，可以使用不同的方式构建应用，而整体化应用程序只能提供一个非常粗粒度的接口供外部使用。

(7)对可替代性的优化

在微服务架构中，我们可以在需要时轻易地重写服务， 或者删除不再使用的服务。

2. 微服务面临的挑战

(1)分布式系统的复杂度

使用微服务实现分布式系统的复杂度要比单块系统高。

(2)运维成本

在微服务架构下，随着服务数量的增多，每个服务都需要独立的配置、部署、 监控、日志收集等，因此成本呈指数级增长。

(3)部署自动化

传统单块系统手动部署是 可以满足需求的。
对于微服务架构而言，如何有效地构建自 动化部署流水线，降低部署成本、提高部署频率，是微服务架构下需要面临的一个挑战。。

(4)DevOps 与组织结构

传统单块架构中，团队通常是按技能划分，并通过项目的 方式协作，完成系统交付。

在微服务架构的实施过程中，除了如上所述的交付、运维上存 在的挑战，在组织或者团队层面，如何传递 DevOps 文化的价值，让团队理解 DevOps 文化的价值，并构建全功能团队，也是一个不小的挑战。

(5)服务间依赖测试

在服务数量较多的情况下，如何有效地保证服务之间能有效按照接口的约定正常工作， 成为微服务实施过程中必须面临的巨大挑战。

(6)服务间依赖管理

随着微服 务个数的增多，如何清晰有效地展示服务之间的依赖关系，成为了一个挑战。

3.微服务与 SOA

微服务可以讲是 SOA 的一种，但他们也有一些差异。

实现方面的差异：

通俗地讲，软件架构设计就是软件系统的“布局谋篇”。

软件架构的研究内容主要涉及软件架构描述、软件架构设计、软件架构风格、软件架构评价和软件架构的形成方法等。

软件设计人员学习软件架构知识旨在站在较高的层面上整体地解决好软件的设计、复用、质量和维护等方面的实际问题。

软件架构是软件抽象发展到一定阶段的产物，从编程的角度，可以清晰地看到软件抽象 层次和表达工具的发展历史。

20 世纪 60 年代是子程序的年代:出现了原始的软件架构，即子程序，并以程序间的调用为连接关系。

20 世纪 70 年代是模块化的年代:出现了数据流分析、实体—关系图(E-R 图)、信息隐藏等工具和方法，软件的抽象层次发展到了模块级。

20 世纪 80 年代是面向对象的年代:基于模块化的编程语言进一步发展成面向对象的语言，继承性地增加了一种新元素之间的连接关系。

20 世纪 90 年代是框架的年代:标准的基于对象的架构以框架的形式出现了。如电子数据表、文档、图形图像、音频剪辑等可互换的黑箱对象，可以相互嵌入。

当前(最近 10 年来):中间件和 IT 架构作为标准平台出现，用可购买可复用的元素来构建系统，同时，基于架构的开发方法和理论不断成熟。

一、软件架构的定义

软件架构仍在不断发展中，还没有形成一个统一的、公认的定义，这里仅举出几个较权威的定义。

定义 1:软件或计算机系统的软件架构是该系统的一个(或多个)结构，而结构由软件元素、元素的外部可见属性及它们之间的关系组成。

定义 2:软件架构为软件系统提供了一个结构、行为和属性的高级抽象，由构成系统的元素的描述、这些元素的相互作用、指导元素集成的模式及这些模式的约束组成。

定义 3:软件架构是指一个系统的基础组织，它具体体现在:系统的构件，构件之间、构件与环境之间的关系，以及指导其设计和演化的原则上。(IEEE1471- 2000)

(1)架构是对系统的抽象，它通过描述元素、元素的外部可见属性及元素之间的关系来反映这种抽象。因此，仅与内部具体实现有关的细节是不属于架构的，即定义强调元素的 “外部可见”属性。

(2)架构由多个结构组成，结构是从功能角度来描述元素之间的关系的，具体的结构传达了架构某方面的信息，但是个别结构一般不能代表大型软件架构。

(3)任何软件都存在架构，但不一定有对该架构的具体表述文档。即架构可以独立于架构的描述而存在。如文档已过时，则该文档不能反映架构。

(4)元素及其行为的集合构成架构的内容。体现系统由哪些元素组成，这些元素各有哪些功能(外部可见)，以及这些元素间如何连接与互动。即在两个方面进行抽象:在静态方面，关注系统的大粒度(宏观)总体结构(如分层);在动态方面，关注系统内关键行为的共同特征。

(5)架构具有“基础”性:它通常涉及解决各类关键的重复问题的通用方案(复用性)，以及系统设计中影响深远(架构敏感)的各项重要决策(一旦贯彻，更改的代价昂贵)。

(6)架构隐含有“决策”，即架构是由架构设计师根据关键的功能和非功能性需求(质量属性及项目相关的约束)进行设计与决策的结果。不同的架构设计师设计出来的架构是不一样的，为避免架构设计师考虑不周，重大决策应经过评审。特别是架构设计师自身的水平是一种约束，不断学习和积累经验才是摆脱这种约束走向自由王国的必经之路。

在设计软件架构时也必须考虑硬件特性和网络特性，因此，软件架构与系统架构二者间的区别其实不大。但是，在大多情况下，架构设计师在软件方面的选择性较之硬件方面，其自由度大得多。因此，使用“软件架构”这一术语，也表明了一个观点:架构设计师通常将架构的重点放在软件部分。

(1)影响架构的因素。软件系统的项目干系人(客户、用户、项目经理、程序员、测试人员、市场人员等)对软件系统有不同的要求、开发组织(项目组)有不同的人员知识结构、架构设计师的素质与经验、当前的技术环境等方面都是影响架构的因素。这些因素通过功能性需求、非功能性需求、约束条件及相互冲突的要求，影响架构设计师的决策，从而影响架构。

(2)架构对上述诸因素具有反作用，例如，影响开发组织的结构。架构描述了系统的大粒度(宏观)总体结构，因此可以按架构进行分工，将项目组为几个工作组，从而使开发有序;影响开发组织的目标，即成功的架构为开发组织提供了新的商机，这归功于:系统的示范性、架构的可复用性及团队开发经验的提升，同时，成功的系统将影响客户对下一个系统的要求等。这种反馈机制构成了架构的商业周期。

二、软件架构的重要性

(1)项目关系人之间交流的平台。

软件系统的项目关系人分别关注系统的不同特性， 而这些特性都由架构所决定，因此，架构提供了一个共同语言(公共的参考点)，项目关系 人以此作为彼此理解、协商、达成共识或相互沟通的基础。架构分析既依赖于又促进了这个 层次上的交流。

(2)早期设计决策。

从软件生命周期来看，软件架构是所开发系统的最早设计决策的体现。

架构明确了对系统实现的约束条件:架构是架构设计师对系统实现的各方面进行权衡的结果， 是总体设计的体现，因此，在具体实现时必须按架构的设计进行。

架构影响着系统的质量属性:要保证系统的高质量，具有完美的架构是必要的(虽然不充分)。 架构可以用来预测系统的质量，例如，可以根据经验对该架构的质量(如性能)作定性的判 断。

架构为维护的决策提供根据。在架构层次上能为日后的更改决策提供推理、判断的依据。一个富有生命力的架构，应该是在最有可能更改的地方有所考虑(架构的柔性)，使其在此点 最容易进行更改。

架构有助于原型开发。可以按架构构造一个骨架系统(原型)，例如，在早期实现一个可执 行的特例，确定潜在的性能问题。

借助于架构进行成本与进度的估计。

(3)在较高层面上实现软件复用。

软件架构作为系统的抽象模型，可以在多个系统间传递(复用)，特别是比较容易地应用到具有相似质量属性和功能需求的系统中。产品线通 常共享一个架构。产品线的架构是开发组织的核心资产之一，利用架构及其范例进行多系统 的开发，在开发时间、成本、生产率和产品质量方面具有极大的回报。基于架构的开发强调 对各元素的组合或装配。系统开发还可以使用其他组织开发的元素，例如购买商业构件。

(4)架构对开发的指导与规范意义不容忽略。

架构作为系统的总体设计，它指导后续 的详细设计和编码。架构使基于模板的开发成为可能，有利于开发的规范化和一致性，减少 开发与维护成本。架构可以作为培训的基础，有利于培养开发团队和培训相关人员。

三、架构的模型

软件架构作为一个有机的整体，可以分解成多个侧面来认识，每个侧面强调它的不同方 面的特征，从而使架构设计师能整体地把握它的重点。我们可以将软件架构归纳成 5 种模 型:结构模型、框架模型、动态模型、过程模型和功能模型。最常用的是结构模型和动态模 型。

(1)结构模型。

这是一个最直观、最普遍的建模方法。这种方法以架构的构件、连接 件和其他概念来刻画结构，并力图通过结构来反映系统的重要语义内容，包括系统的配置、 约束、隐含的假设条件、风格、性质。研究结构模型的核心是架构描述语言。

(2)框架模型。

框架模型与结构模型类似，但它不太侧重描述结构的细节而更侧重于 整体的结构。框架模型主要以一些特殊的问题为目标建立只针对和适应该问题的结构。

(3)动态模型。

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

(4)过程模型。

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

(5)功能模型。

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

“4+1”的视图模型

4+1” 视 图模型从 5 个不同的视角包括逻辑视图、进程视图、物理视图、开发视图和场景视图来描 述软件架构。每一个视图只关心系统的一个侧面，5 个视图结合在一起才能反映系统的软件 架构的全部内容。

(1)逻辑视图

主要支持系统的功能需求，即系统提供给最终用户的服务。

在面向对象技术中，通过抽象、封装和继承，可以用对象模型来代表逻辑视图，用类图来描述逻辑视图。逻辑视图中使用的风格为面向对象的风格。

(2)开发视图

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

开发视图要考虑软件内部的需求，如软件开发的容易性、软件的重用和软件的通用性，要充分考虑由于具体开发工具的不同而带来的局限性。开发视图通过系统输入输出关系的模型图和子系统图来描述。

(3)进程视图

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

进程视图强调并发性、分布性、系统集成性和容错能力，以及逻辑视图中的 主要抽象的进程结构。它也定义逻辑视图中的各个类的操作具体是在哪一个线程中被执行的。 进程视图可以描述成多层抽象，每个级别分别关注不同的方面。

(4)物理视图

主要考虑如何把软件映射到硬件上，它通常要考虑到解决系统拓扑结 构、系统安装、通信等问题。

当软件运行于不同的节点上时，各视图中的构件都直接或间接 地对应于系统的不同节点上。因此，从软件到节点的映射要有较高的灵活性，当环境改变时， 对系统其他视图的影响最小。

(5)场景

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

在开发架构时，它可以帮助设计者找到架构的构件和它们之间的作用关系。同时，也可以用场景来分析一个特定的视图，或描述不同视图构件间是如何相互作用的。场景可以用文本表示，也可以用图形表示。

架构的基本需求主要是在满足功能属性的前提下，关注软件质量属性，架构设计则是为满足架构需求(质量属性)寻找适当的“战术”。

软件属性包括功能属性和质量属性，但是，软件架构(及软件架构设计师)重点关注的是质量属性。

在大量的可能结构中，可以使用不同的结构来实现同样的功能性，即功 能性在很大程度上是独立于结构的，架构设计师面临着决策(对结构的选择)，而功能性所 关心的是它如何与其他质量属性进行交互，以及它如何限制其他质量属性。

一、软件质量属性

《GB/T16260-1996(idt ISO/IEC9126:1991)信息技术软件产品评价质量特性及其使用指南》中描述的软件质量特性包括功能性、可靠性、易用性、效率、可维护性、可移植性等 6 个方面，每个方面都包含若干个子特性。

1.运行期质量属性

性能

性能是指软件系统及时提供相应服务的能力。包括速度、吞吐量和持续高速性三方面的要求。

安全性

指软件系统同时兼顾向合法用户提供服务，以及阻止非授权使用的能力。

易用性

指软件系统易于被使用的程度。

可伸缩性

指当用户数和数据量增加时，软件系统维持高服务质量的能力。例如，通过增加服务器来提高能力。

互操作性

指本软件系统与其他系统交换数据和相互调用服务的难易程度。

持续可用性

指系统长时间无故障运行的能力。与可靠性相关联，常将其纳入可靠性中。

鲁棒性

是指软件系统在一些非正常情况(如用户进行了非法操作、相关的软硬件系统发生了故障等)下仍能够正常运行的能力。也称健壮性或容错性。

2.开发期质量属性

易理解性

指设计被开发人员理解的难易程度。

可扩展性

软件因适应新需求或需求变化而增加新功能的能力。也称为灵活性。

可重用性

指重用软件系统或某一部分的难易程度。

可测试性

对软件测试以证明其满足需求规范的难易程度。

可维护性

当需要修改缺陷、增加功能、提高质量属性时，定位修改点并实施修改的难易程度;

可移植性

将软件系统从一个运行环境转移到另一个不同的运行环境的难易程度。

二、6 个质量属性及实现

如何描述质量属性需求呢?

1.可用性及其实现战术

(1)可用性的描述。

(2)可用性战术。

可用性战术的目标是阻止错误发展成故障，至少能够把错误的影响 限制在一定范围内，从而使修复成为可能。战术分为:错误检测、错误恢复、错误预防。

①错误检测

命令/响应:一个构件发出一个命令，并希望在预定义的时间内收到一个来自审查构件的响 应，例如远程错误的检测。
心跳(计时器):一个构件定期发出一个心跳消息，另一个构件收听到消息，如果未收到心 跳消息，则假定构件失败，并通知错误纠正构件。
异常:当出现异常时，异常处理程序开发执行。

②错误恢复

表决:通过冗余构件(或处理器)与表决器连接，构件按相同的输入及算法计算输出值交给 表决器，由表决器按表决算法(如多数规则)确定是否有构件出错，表决通常用在控制系统中。

主动冗余(热重启、热备份):所有的冗余构件都以并行的方式对事件做出响应。它们都处 在相同的状态，但仅使用一个构件的响应，丢弃其余构件的响应。错误发生时通过切换的方 式使用另一个构件的响应。

被动冗余(暧重启/双冗余/三冗余):一个构件(主构件)对事件做出响应，并通知其他构 件(备用的)必须进行的状态更新(同步)。当错误发生时，备用构件从最新同步点接替主 构件的工作。

备件:备件是计算平台配置用于更换各种不同的故障构件。

状态再同步:主动和被动冗余战术要求所恢复的构件在重新提供服务前更新其状态。更新方 法取决于可以承受的停机时间、更新的规模及更新的内容多少。

检查点/回滚:检查点就是使状态一致的同步点，它或者是定期进行，或者是对具体事件做 出响应。当在两检查点之间发生故障时，则以这个一致状态的检查点(有快照)和之后发生 的事务日志来恢复系统(数据库中常使用)。

③错误预防

从服务中删除:如删除进程再重新启动，以防止内存泄露导致故障的发生。

事务:使用事务来保证数据的一致性，即几个相关密切的步骤，要么全成功，要么都不成功。

进程监视器:通过监视进程来处理进程的错误。

2.可修改性及其实现战术

(1)可修改性的描述

(2)可修改性战术。

包括局部化修改、防止连锁反应、推迟绑定时间。

①局部化修改

在设计期间为模块分配责任，以便把预期的变更限制在一定的范围内，从而降低修改的成本。

维持语义的一致性:语义的一致性指的是模块中责任之间的关系，使这些责任能够协同工作， 不需要过多地依赖其他模块。耦合和内聚指标反映一致性，应该根据一组预期的变更来度量 语义一致性。使用“抽象通用服务”(如应用框架的使用和其他中间软件的使用)来支持可 修改性是其子战术。

预期期望的变更:通过对变更的预估，进行预设、准备，从而使变更的影响最小。

泛化该模块:使一个模块更通用、更广泛的功能。

限制可能的选择:如在更换某一模块(如处理器)时，限制为相同家族的成员。

②防止连锁反应。

由于模块之间有各种依赖性，因此，修改会产生连锁反应。防止连锁反应的战术如下。

信息隐藏:就是把某个实体的责任分解为更小的部分，并选择哪些信息成为公有的，哪些成 为私有的，通过接口获得公有责任。

维持现有的接口:尽可能维持现有接口的稳定性。例如通过添加接口(通过新的接口提供新 的服务)可以达到这一目的。

限制通信路径:限制与一个给定的模块共享数据的模块。这样可以减少由于数据产生/使用引入的连锁反应。

仲裁者的使用:在具有依赖关系的两个模块之间插入一个仲裁者，以管理与该依赖相关的活 动。仲裁者有很多种类型，例如:桥、调停者、代理等就是可以提供把服务的语法从一种形 式转换为另一种形式的仲裁者。

③推迟绑定时间。

系统具备在运行时进行绑定并允许非开发人员进行修改(配置)。

运行时注册:支持即插即用。

配置文件:在启动时设置参数。

多态:在方法调用的后期绑定。

构件更换:允许载入时绑定。

3.性能及其实现战术

(1)性能的描述。

(2)性能战术。

性能与时间相关，影响事件的响应时间有两个基本因素。

资源消耗:事件到达后进入一系列的处理程序，每一步处理都要占用资源，而且在处理过程 中消息在各构件之间转换，这些转换也需要占用资源。

闭锁时间:指对事件处理时碰到了资源争用、资源不可用或对其他计算的依赖等情况，就产 生了等待时间。

①资源需求

减少处理事件流所需的资源:提高计算效率(如改进算法)、减少计算开销(如在可修改性与性能之间权衡，减少不必要的代理构件)。

减少所处理事件的数量:管理事件率、控制采样频率。

控制资源的使用:限制执行时间(如减少迭代次数)、限制队列大小。

②资源管理

引入并发:引入并发对负载平衡很重要。

维持数据或计算的多个副本:C/S 结构中客户机 C 就是计算的副本，它能减少服务器计算的压力;高速缓存可以存放数据副本(在不同速度的存储库之间的缓冲)。

增加可用资源:在成本允许时，尽量使用速度更快的处理器、内存和网络。

③资源仲裁

通过如下调度策略来实现：

先进/先出(FIFO);

固定优先级调度:先给事件分配特定的优先级，再按优先级高低顺序分配资源;

动态优先级调度:轮转调度、时限时间最早优先;

静态调度:可以离线确定调度。

4.安全性及其实现战术

(1)安全性的描述。

(2)安全性战术

包括抵抗攻击、检测攻击和从攻击中恢复。

①抵抗攻击

对用户进行身份验证:包括动态密码、一次性密码、数字证书及生物识别等;

对用户进行授权:即对用户的访问进行控制管理;

维护数据的机密性:一般通过对数据和通信链路进行加密来实现;

维护完整性:对数据添加校验或哈希值;

限制暴露的信息;

限制访问:如用防火墙、DMZ 策略。

②检测攻击

一般通过“入侵检测”系统进行过滤、比较通信模式与历史基线等方法。

③从攻击中恢复

恢复:与可用性中的战术相同;

识别攻击者:作为审计追踪，用于预防性或惩罚性目的。

5.可测试性及其实现战术

(1)可测试性的描述

(2)可测试性战术

包括输入/输出和内部监控。

①输入/输出

记录/回放:指捕获跨接口的信息，并将其作为测试专用软件的输入;

将接口与实现分离:允许使用实现的替代(模拟器)来支持各种测试目的;

优化访问线路/接口:用测试工具来捕获或赋予构件的变量值。

②内部监控

当监视器处于激活状态时，记录事件(如通过接口的信息)。

6.易用性及其实现战术

(1)易用性的描述

(2)易用性战术

包括运行时战术、设计时战术和支持用户主动操作。

①运行时战术

任务的模型:维护任务的信息，使系统了解用户试图做什么，并提供各种协助;

用户的模型:维护用户的信息，例如使系统以用户可以阅读页面的速度滚动页面;

系统的模型:维护系统的信息，它确定了期望的系统行为，并向用户提供反馈。

②设计时战术

将用户接口与应用的其余部分分离开来，预计用户接口会频繁发生变化，因此，单独维护用户接口代码将实现变更局部化。这与可修改性相关。

③支持用户主动操作

支持用户的主动操作，如支持“取消”、“撤销”、“聚合”和 “显
示多个视图”。

分布式计算背景：
单台计算机的功能仍然十分有限。
升级到更强的服务器的费用常常远远高于购买多台档次稍低的机器。

解决方案：
利用联网的计算机协同工作，共同完成复杂的工作成为相对成本较低的选择，而且可以完成单台计算机所无法完成的任务。

存在问题：
网络本质上并不可靠，特别是远程通信。
分布式系统还带来了并发和同步的问题。

基于实例的协作

所有的实例都处理自己范围内的数据，这些对象实例的地位是相同的，当一个对象实例必须要处理不属于它自己范围的数据时，它必须和数据归宿的对象实例通信，请求另外一个对象实例进行处理。
请求对象实例可以启动对象、调用远程对象的方法，以及停止运行远程实例。

基于实例的协作适用于比较小范围内网络情况良好的环境中，这种环境常常被称为近连接。这种情况下对对象的生存周期管理所带来不寻常的网络流量是可以容忍的。

基于实例的协作常常使用被称为“代理”的方法。

基于服务的协作

只提供远程对象的接口，用户可以调用这些方法，却无法远程创建和销毁远程对象实例。

基于服务的协作适用于跨平台的网络，网络响应较慢的情况，这种环境常称为远连接。这时，简化交互性更为重要，而频繁的网络交换数据会带来难以容忍的延时。

基于服务的协作往往采用分层次的结构，高层次的应用依赖于低层次的对象，而低层次对象实例的实现细节则没有必要暴露给高层次对象。