十三 系统架构设计(考点篇)

1 软件架构的概念

一个程序和计算系统软件体系结构是指系统的一个或者多个结构。结构中包括软件的构件，构件
的外部可见属性以及它们之间的相互关系。
体系结构并非可运行软件。确切地说，它是一种表达，使软件工程师能够：

• (1)分析设计在满足所规定的需求方面的有效性：
• (2)在设计变更相对容易的阶段，考虑体系结构可能的选择方案；
• (3)降低与软件构造相关联的风险。

上面的定义强调在任意体系结构的表述中"软件构件"的角色。软件构件简单到可以是程序模块或者面向对象的类，也可以扩充到包含数据库和能够完成客户与服务器网络配置的"中间件"。
软件体系结构的设计两个层次 ：数据设计和体系结构设计。

• 数据设计 ‌主要关注于系统中数据的组织和存储方式，包括数据库、数据文件和全局数据结构的定义。数据设计体现 传统系统中体系结构的数据构件和面向对象系统中类的定义(封装了属性和操作)。数据设计是软件体系结构设计中非常重要的一部分，因为它直接影响到系统的数据处理能力和效率
• 体系结构设计 则主要关注软件构件的结构、属性和交互作用。确定各子系统模块间的数据传递与调用关系，以及模块间、系统与外部系统的接口关系。体系结构设计是软件架构的核心，它决定了软件系统的整体结构和行为，对系统的性能、可靠性、安全性和易维护性等方面有着直接的影响

软件架构设计与生命周期

1.需求分析阶段。

需求分析 和SA设计 (系统设计)面临的是不同的对象：一个是问题空间 ；另一个是解空间。
从软件需求模型向SA模型的转换 主要关注两个问题：如何根据需求模型 构建SA模型 。如何保证模型转换的 可追踪性 。

2.设计阶段。

是SA 研究关注的最早和最多的阶段，这一阶段的SA研究主要包括：

• SA 模型 的描述、
• SA 模型 的设计与分析方法，
• 以及对 SA设计经验 的总结与复用等。

有关SA 模型描述的研究分为3个层次：

• SA的基本概念(构件和连接子)------- 这++一层次主要涉及SA模型由哪些元素组成，以及这些组成元素之间按照何种原则组织。SA模型的基本构成元素包括构件和连接子，这些元素是构建系统架构的基础。++
• 体系结构描述语言ADL****------- ++ADL是一种支持构件、连接子及其配置的描述语言。它提供了标准化和形式化的方式来描述系统架构，使得不同背景的开发者能够更容易地理解和交流。常见的ADL包括UniCon、Rapide、Darwin、Wright、C2 SADL、Acme、xADL、XYZ/ADL和ABC/ADL等++
• SA模型的多视图表示****------- ++从不同的视角描述特定系统的体系结构，从而得到多个视角，并将这些视图组织起来用来描述整体的SA模型。这种多视图表示方法能够全面地反映系统的各个方面，确保在设计过程中不会遗漏任何重要的信息或功能++

3.实现阶段。

最初 SA 研究往往只关注较高层次的系统设计、描述和验证。为了有效实现 SA设计向实现的转换 ，实现阶段的体系结构研究表现在以下几个方面。

• (1)研究基于SA 的开发过程支持 ，如项目组织结构、配置管理等。
• (2)寻求从 SA 向实现过渡的途径 ，如将程序设计语言元素引入 SA 阶段、模型映射、构件组装、复用中间件平台等。
• (3)研究基于 SA 的测试技术。

4.构件组装阶段。

在SA设计模型的指导下 ，可复用构件的组装可以在较高层次上实现系统 ，并能够提高 系统实现 的效率 。在构件组装的过程中，SA 设计模型起到了系统蓝图的作用。研究内容包括如下两个方面。

• (1)如何支持可复用构件的互联 ，即对 SA 设计模型中规约的连接子的实现提供支持。
• (2)在组装过程中，如何检测并消除 体系结构失配问题。

在构件组装阶段的失配问题主要包括：
由构件引起 的失配、由连接子引起 的失配、由于系统成分对全局体系结构的假设存在冲突引起的失配等。

5.部署阶段。

SA 对软件部署作用如下。

• (1)提供高层的体系结构视图 来描述部署阶段的软硬件模型。
• (2)基于SA 模型可以分析部署方案的质量属性 ，从而选择合理的部署方案。

6.后开发阶段。

是指软件部署安装之后 的阶段。这一阶段的 SA 研究主要围绕维护、演化、复用 等方面来进行。典型的研究方向包括动态软件体系结构 、体系结构恢复与重建等。
(1)动态软件体系结构。现实中的软件具有动态性，体系结构会在运行时发生改变。
运行时变化包括两类 ：软件内部执行所导致的体系结构改变 ；软件系统外部的请求对软件进行的
重配置。
包括两个部分的研究：体系结构设计阶段的支持 、运行时刻基础设施的支持。
(2)体系结构恢复与重建。对于现有系统在开发时候没有考虑 SA 的情况，从 这些系统中恢复或重购体系结构 。从已有的系统中获取体系结构的重建方法分为4类：手工体系结构重建 、工具支持的手工重建 、通过查询语言 来自动建立聚集、使用其他技术(如数据挖掘等)。

架构设计概述

从需求分析到软件设计之间的过渡过程称为软件架构 。只要软件架构设计好了，整个软件就不会出现坍塌性的错误，即不会崩溃。
架构设计就是需求分配，将满足需求的职责分配到组件上 。
软件架构为软件系统提供了一个 结构、行为和属性的高级抽象 ，由 构件 的 描述 、构件的 相互作用 (连接件)、指导构件 集成的模式 以及这些模式的 约束 组成。
软件架构不仅指定了系统的 组织结构和拓扑结构 ，并且显示了系统 需求和构件 之间的 对应关系 ，提供了一些 设计决策的基本原理 。
解决好软件的复用、质量和维护问题，是研究软件架构的根本目的。
软件架构设计包括 提出 架构 模型 ， 产生 架构 设计 和进行 设计评审 等活动，是一个迭代 的过程。架构设计主要关注软件组件的结构、属性和交互作用 ，并通过多种视图全面描述特定系统的架构。

补充 ：

迭代和‌演化的定义‌‌

‌迭代 ‌是一种软件开发过程，它通过一系列的迭代周期来逐步构建软件。每个迭代周期包括需求分析、设计、实现、测试和集成等阶段，通过反馈和调整来不断完善软件。‌演化 ‌模型也是一种全局的软件生存周期模型，属于迭代开发方法的一种。它通过快速分析构造出软件的初始版本，根据用户反馈进行改进，最终得到满意的软件产品。

‌迭代和演化的区别‌

迭代和演化在软件开发过程中有所不同。迭代更注重每个阶段的逐步完善 ，通过多次迭代来达到最终目标 。而演化则更注重从用户反馈中不断改进 ，通过快速原型构建和使用反馈来逐步完善软件。

‌实例说明‌

例如，在一个软件开发项目中，如果需求不明确，可以使用‌演化模型来快速构建原型，通过用户反馈来逐步明确需求并进行调整。如果需求已经明确，但需要逐步完善功能，则可以使用迭代模型，通过多次迭代来逐步实现每个功能模块。

迭代**和‌递归**是两种常见的解决问题的方法，它们在实现和思维方式上有一些区别。以下是迭代和递归的主要区别：

1. ‌定义和结构‌：

   • ‌迭代 ‌：通过循环结构重复执行一段代码 ，每次迭代的结果会作为下一次迭代的初始值，直到满足结束条件 。迭代是环结构，从初始状态开始，每次迭代都遍历这个环，并更新状态，多次迭代直到到达结束状态。‌
   • ‌递归 ‌：函数直接或间接调用函数自身，直到满足终止条件再逐层回归 。递归是树结构，从字面可以理解为重复"递推"和"回归"的过程，当"递推"到达底部时就会开始"回归"，其过程相当于树的深度优先遍历。‌

2. ‌时间复杂度‌：

   • ‌迭代‌：迭代的时间复杂度可以通过查找循环内重复的周期数来发现。在实际应用中，迭代的效率通常高于递归，尤其是在循环次数较大时。‌
   • ‌递归‌：递归的时间复杂度可以通过根据前面的调用查找第n个递归调用的值来查找。递归的时间复杂度可能会呈指数级增长，尤其是在有大量递归调用时。‌

3. ‌效率‌：

   • ‌迭代 ‌：通常在循环次数较大时，迭代的效率明显高于递归，因为递归涉及函数调用的开销。‌
   • ‌递归‌：虽然代码长度较小，但由于函数调用的开销，当递归调用次数较多时，效率较低。

4. ‌应用场景‌：

   • ‌迭代 ‌：适用于当问题可以通过简单的循环结构解决的情况，如数组遍历、累加等。
   • ‌递归 ‌：适用于问题可以分解为多个相似子问题的情况，如树的遍历、图的搜索等。

5. ‌无限重复的后果‌：

   • ‌迭代‌：如果终止条件设置不当，可能导致无限循环。
   • ‌递归‌：如果基本情况设置不当，可能导致无限递归调用，最终可能导致系统崩溃。

综上所述，选择迭代还是递归取决于具体问题的性质和需求。迭代通常适用于简单的循环任务，而递归适用于可以分解为多个相似子问题的任务。在实际应用中，应根据问题的特点和需求来选择合适的方法

架构设计作用

软件架构能够在设计变更相对容易的阶段 ，考虑 系统结构的可选方案 ，便于 技术人员与非技术人员就软件设计进行交互 ，能够展现软件的结构、属性与内部交互关系。
软件架构是项目干系人进行交流的手段，明确了对系统实现的约束条件，决定了开发和维护组织的组织结构，制约着系统的质量属性。
软件架构使推理和控制的更改更加简单 ，有助于 循序渐进的原型设计 ，可以作为培训的基础。
软件架构是可传递和可复用的模型 ，通过研究软件架构可能预测软件的质量。

构件

构件是一个独立可交付的功能单元，外界通过接口访问其提供的服务。
构件由一组通常需要同时部署的原子构件组成 。一个原子构件是一个模块和一组资源 。原子构件是部署、版本控制和替换的基本单位。原子构件通常成组地部署 ，但是它也能够被单独部署。
构件和原子构件之间的区别在于，大多数原子构件永远都不会被单独部署，尽管它们可以被单独部署。相反，大多数原子构件都属于一个构件家族，一次部署往往涉及整个家族。
一个模块是不带单独资源的原子构件(在这个严格定义下，Java 包不是模块------在 Java 中部署的原子单元是类文件。一个单独的包被编译成多个单独的类文件------每个公共类都有一个)。
模块是一组类和可能的非面向对象的结构体 ，比如过程或者函数。

构件和对象

构件的特性是：

• (1)独立部署单元；
• (2)作为第三方的组装单元；
• (3)没有(外部的)可见状态 。一个构件可以包含多个类元素，但是一个类元素只能属于一个构件。将一个类拆分进行部署通常没什么意义。

对象的特性是：

• (1)一个实例单元 ，具有唯一的标志。
• (2)可能具有状态 ，此状态外部可见。
• (3)封装了自己的状态和行为。

构件接口

接口标准化 是对接口中消息的格式、模式和协议的标准化 。它不是要将接口格式化为参数化操作的 集合，而是关注输入输出的消息的标准化，它强调当机器在网络中互连时，标准的消息模式、格式、协议的重要性。

面向构件的编程(COP)

关注于如何支持建立面向构件的解决方案。面向构件的编程需要下列基本的支持：

• ------**多态性(**可替代性);
• ------模块封装性(高层次信息的隐藏);
• ------后期的绑定和装载(部署独立性);
• ------安全性(类型和模块安全性)。

2 基于架构的软件开发方法

ABSD 方法是架构驱动 ，强调由业务、质量和功能需求的组合驱动架构设计 。它强调采用视角和
视图来描述软件架构 ，采用用例和质量属性场景来描述需求 。进一步来说，用例描述 的是功能需求 ，质量属性场景描述 的是质量需求(或侧重于非功能需求)。

总结：
-- ABSD就叫基于架构的软件开发方法，当然是架构驱动的，架构设计呢在这里又是由业务、质量和功能需求的组合来驱动的。
-- 用视角和视图来描述软件的架构，用用例和质量属性场景来描述需求。
-- 用例描述功能，质量属性场景描述质量。
使用 ABSD方法，设计活动可 以从项目总体功能框架明确就开始 ，这意味着需求获取和分析还没
有完成，就开始了软件设计。-- 意味着需求分析还没完成就可以开始了，提前到需求分析了。
ABSD 方法有三个基础。

• 第一个基础是功能的分解 ，使用 已有的基于模块的内聚和耦合技术；
• 第二个基础是通过选择架构风格 来实现质量和业务需求；
• 第三个基础是软件模板的使用 ，软件模板利用 了一些软件系统的结构。

ABSD的实现需要由3个基础/前提：
使用内聚和耦合技术进行功能的分解，功能模块化；选择合适的架构风格，要照顾到业务(功能)需求和质量(性能)需求；利用一些现成的软件模板，里面有现成的系统的结构可利用。
ABSD 方法是 递归的 ，且迭代的每一个步骤都是清晰定义的 。因此， 不管设计是否完成，架构总
是清晰的 ，有助于降低架构设计的随意性。

开发过程

架构设计是在需求分析之后，概要设计之前，是为了解决需求分析和软件设计之间的鸿沟问题。
基于架构的软件开发过程可分为下列六步：

基于ABSD的开发过程：

• 需求是第一步，获取、整理、分析需求，得把需求确定了；
• 第二步是设计，提出模型，设计各功能模块(构件)及相互联系(连接件)等等；
• 第三步是文档化，前面的设计的功能模块(构件、连接件)毕竟不是真正实现的代码，只是文档上的内容，所以要把这些东西以及架构相关的所有信息文档化；
• 第四步复审：文档化后还要拉一群人来开会，一起讨论这些设计是否合理和存在不足等等。复审不合格的打回去重新设计，修改文档，再复审，直到大家意见一致。
• 第五步实现：复审都通过那就着手实现吧，根据文档来分析设计构件以及他们之间的调用关系，有现成的就用，没现成的就开发，测试。

• 第六步演化：上一步已经实现了并测试完成了，但是后期需要维护的，比如提出新需求，环境变化，业务改变，这就需要演化来满足这些变化。++演化是从需求开始重新走一遍++。

架构需求：重在掌握标识构件的三步，如下左图。

架构需求过程详细步骤：

1.获取需求：从库里获取还是用户获取都可以，整理合并，分类、形成文档(SRS)。

---------------------------------------------标识构件过程---------------------------------------------------------

2.生成类图：根据整理后的需求文档，用一些CASE工具生成类图，ABSD使用类图来描述系统结构。

3.对类进行分组：生成了类图，根据耦合和内聚程度还需要把类分组，这样简化类图结构，使其更加清晰可读。

4.把类打包成构件 ：把类簇打包成构件，这些构件可以分组合并。这一过程实现了构件级的重用，构件和构件又可以打包成更大的构件。

---------------------------------------------标识构件过程---------------------------------------------------------

5.需求评审：需求也是要拉一批人开会讨论需求是否合理有效的，不符合打回去重新获取再走一遍。

架构设计：将需求阶段的标识构件映射成构件，进行分析，如下右图。

架构设计过程详细步骤：
1.提出架构模型：选择一个合适的架构风格(没有就自己造)，该模型为将来的实现和演化建立了目标。
2.映射构件：把已标识的构件映射到架构中，将产生一个中间结构，它只包含适合架构模型的构件。
3.分析构件相互作用：研究构件之间的交互方式，确保它们能够正确地协同工作，满足系统的功能和性能要求。
4.产生架构：当决定了关键构件之间的相互作用后，就可以在中间结构的基础上进行精化，得到软件架构
5.设计评审：拉一人开会讨论产生的这个架构是否有不合理的地方，有就打回去重新选择构件映射再走一遍，直到大家意见一致。

架构(体系结构)文档化：

主要产出两种文档，即 架构(体系结构)规格说明 ， 测试架构(体系结构)需求的质量设计说明书 。文档是至关重要的，是所有人员通信的手段 ，关系开发的成败。
文档的完整性 和质量是软件架构成功的关键因素。

关于文档的三大注意事项：

（1）文档要从使用者的角度进行编写。

（2）必须分发给所有与系统有关的开发人员 。

（3）且必须保证开发者手上的文档是最新的。

架构复审：

由**外部人员(**独立于开发组织之外的人，如用户代表和领域专家等)参加的复审，复审架构是否满足需求，质量问题，构件划分合理性等。若复审不过，则返回架构设计阶段进行重新设计、文档化，再复审。
架构复审【架构评估】的目的是 标识潜在的风险，及早发现架构设计中的缺陷和错。

架构实现：用实体来显示出架构。实现构件，构件组装成系统，如下左图：

架构实现过程：

1.分析与设计：根据文档(架构规格说明、测试架构需求的质量设计说明数)来实现， 在架构说明书中，已经定义了系统中构件与构件之间的关系，构件接口约束对外唯一代表了构件，所以可以从构件库中直接查找符合接口约束的构件。

2.构件实现：必要时开发新的满足要求的构件。

3.构件组装：按照设计文档的要求进行组装，形成系统的基本结构

4.系统测试：包括单个构件的功能性测试和被组装应用的整体功能和性能测试。

架构演化：对架构进行改变，按需求增删构件，使架构可复用，如下右图：

架构演化详细过程：
**1.需求变化归类：**既然是演化那么肯定是需求发生了变化或者提出了新的，那么这些需求首先要分类，比如有些需求修改构件就行，有些需要需要重新开发构件，有些需要删除构件等等。
**2.演化计划：**演化的是一个完整的实现了架构的系统了，甚至在使用当中，这就需要做一个计划来操作演化，不能盲目的进行。
**3.构件变动：**修改，增加或删除构件，要对修改和增加的构件进行功能性测试。
**4.更新构件间相互作用：**构件变化了，受影响的构件及它们间作用也跟着修改，比如调用关系的改变，顺序调整，新增删除等等。
**5.构件组装与测试：**对修改后的构件进行重新组装，并进行测试，以确保系统的功能和性能满足要求。
6.技术评审： 检查架构演化后的系统是否满足所有需求，以及是否存在潜在的问题或缺陷。 如果哟问题打回去重新修改演化计划，再走一遍。
7.得到演化后架构。

3 软件架构风格

软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式 。架构风格定义一个系统家族 ，即一个架构定义一个词汇表和一组约束 。词汇表中包含一些构件和连接件类型 ，而这组约束指
出系统是如何将这些构件和连接件组合起来的。
架构风格反映了领域中众多系统所共有的结构和语义特性 ，并指导如何将各个模块和子系统有效地组织成一个完整的系统。对软件架构风格的研究和实践促进对设计的重用，一些经过实践证实的解
决方案也可以可靠地用于解决新的问题。
架构设计的一个核心问题是能否达到架构级的软件复用。
架构风格定义了用于描述系统的术语表和一组指导构建系统的规则。

3.1 基本架构风格

• 数据流风格： 面向数据流，按照一定的顺序从前向后执行程序，代表的风格有 批处理序列、管道-过滤器。

• 调用/返回风格： 构件之间存在互相调用的关系，一般是显式的调用，代表的风格有 主程序/子程序、面向对象、层次结构(C/s 架构风格本质属于层次风格)。

• 独立构件风格： 构件之间是互相独立的，不存在显式的调用关系，而是通过某个事件触发、异步的方式来执行，代表的风格有 进程通信、事件驱动系统(隐式调用)。

• 虚拟机风格： 自定义了一套规则供使用者使用，使用者基于这个规则来开发构件，能够跨平台适配，代表的风格有 解释器、基于规则的系统。

• 仓库风格： 以数据位中心，所有的操作都是围绕建立的数据中心进行的，代表的风格有数据库系统、超文本系统、黑板系统。

数据流风格

批处理序列： 构件为一系列固定顺序的计算单元，构件之间只通过数据传递交互。每个处理步骤是一个独立的程序，每一步必须在其前一步结束后才能开始，数据必须是完整的 ，以整体的方式传递。
管道-过滤器：每个构件都有一组输入和输出，构件读取输入的数据流，经过内部处理，产生输出数据流。前一个构件的输出作为后一个构件的输入，前后数据流关联。过滤器就是构件，连接件就是管道。
早期编译器就是采用的这种架构，要一步一步处理的，均可考虑此架构风格。
二者区别 在于批处理前后构件不一定有关联 ，并且是作为整体传递，即必须前一个执行完才能执行下一个。管道-过滤器是前一个输出作为后一个输入，前面执行到部分可以开始下一个的执行。

调用/返回风格

主程序/子程序 ：单线程控制，把问题划分为若干个处理步骤，构件即为主程序和子程序，子程序通常可合成为模块。过程调用作 为交互机制，充当连接件 的绝色。调用关系具有层次性 ，其语义逻辑表现为主程序的正确性取决于它调用的子程序的正确性。
面向对象 ：构件是对象 ，对象是抽象数据类型的实例。在抽象数据类型中，数据的表示和它们的相应操作被封装起来，对象的行为体现在其接受和请求的动作。连接件即使对象间交互的方式，对象是通过函数和过程的调用来交互的。
层次结构 ：构件 组成一个层次结构 ，连接件 通过决定层间 如何交互 的协议来定义。每层为上一层
提供服务，使用下一层的服务，只能见到与自己邻接的层。通过层次结构，可以将大的问题分解为若干个渐进的小问题逐步解决，可以隐藏问题的复杂度。修改某一层，最多影响其相邻的两层(通常只能影响上层)。

• 层次结构优点：

1. 支持基于可增加抽象层的设计，允许将一个复杂问题分解 成一个增量步骤序列的实现。
2. 不同的层次处于不同的抽象级别，越靠近底层，抽象级别越高；越靠近顶层，抽象级别越低。
3. 由于每一层最多只影响两层，同时只要给相邻层提供相同的接口，允许每层用不同的方法实****现 ，同样为软件复用提供了强大的支持。

• 缺点：

1. 并不是每个系统都可以很容易的划分为分层的模式。
2. 很难找到一个合适的、正确的层次抽象方法。

独立构件风格

进程通信 ：构件是独立的进程 ，连接件是消息传递 。构件通常是命名过程，消息传递的方式可以是点对点、异步或同步方式，以及远程过程(方法)调用等。
事件驱动系统(隐式调用): 构件不直接调用 一个过程，而是触发或广播 一个或多个事件。构件中的过程在一个或多个事件中注册，当某个事件被触发时，系统自动调用在这个事件中注册的所有过程。一个事件的触发就导致了另一个模块中的过程调用。这种风格中的构件是匿名的 过程，它们之间交互的连接件往往是以过程之间的隐式调用来实现的。
主要优点 是为软件复用 提供了强大的支持，为构件 的维护和演化 带来了方便 ；缺点 是构件放弃了
对系统计算的控制。

虚拟机风格

解释器： 通常包括一个完成解释工作的解释引擎、一个包含将被解释的代码的存储区、一个记录解释引擎当前工作状态的数据结构，以及一个记录源代码被解释执行的进度的数据结构。具有解释器风格的软件中含有一个虚拟机 ，可以仿真硬件的执行过程和一些关键应用 ，缺点是执行效率低。

解释器风格的一般组成：

• 解释引擎：解释工作
• 存储区：存要解析代码
• 数据结构：记录解释引擎当前工作状态

• 数据结构：记录代码被解释执行的进度
  基于规则的系统： 包括规则集、规则解释器、规则/数据选择器和工作内存，一般用在人工智能
  领域和 DSS、专家系统中。

基于规则风格的一般组成：

• **规则集：**可多个，规则的集合
• **规则解释器：**负责解析和执行这些规则，确保系统能够根据预定义的规则进行操作。
• **规则/数据选择器：**扮演着关键角色，它决定了哪些数据应该被应用到哪些规则上。

• **工作内存：**用来存储当前状态和中间结果的地方。

仓库风格(数据共享风格，以数据为中心)

数据库系统：构件 主要有两大类，一类是中央共享数据源， 保存当前系统的数据状态 ；另一类是多个独立处理单元，处理单元 对数据元素进行操作 。
个人理解：这两大类构件一个是数据库服务端，另一个是类似客户端；连接件就是它们之间的互联的方式、协议等等这些。
黑板系统： 包括知识源、黑板和控制 三部分。知识源包括若干独立计算的不同单元，提供解决问题的知识。知识源响应黑板的变化，也只修改黑板；黑板是一个全局数据库，包含问题域解空间的全部状态，是知识源相互作用的唯一媒介；知识源响应式通过黑板状态的变化来控制的。黑板系统通常应用在对于解决问题没有确定性算法的软件中(信号处理、问题规划和编译器优化等)。

黑板系统：

• 知识源： 包含若干独立计算 的不同单元 ，以及独立的、与应用程序相关的知识 ，知识源之间不直接进行通讯，它们之间的交互只通过黑板来完成。--独立计算单元和知识。
• 黑板：全局数据库 ，包含问题域解空间的全部状态 ，按照与应用程序相关的层次 来组织并解决问题的数据，知识源通过不断地改变黑板数据来解决问题。-- 全局数据库，问题域和解空间全部状态，根据与应用程序相关的层次来解决问题。
• 控制： 完全由黑板的状态驱动，黑板状态的改变决定了需要使用的特定知识。--黑板状态驱动

与数据库系统相比，黑板相当于中央共享数据源（服务端，中央数据结构），知识源相当于独立处理单元（客户端，独立构件）
超文本系统：构件 以网状链接方式相互连接 ，用户可以在构件之间进行按照人类的联想思维方式任意跳转到相关构件。是一种非线性的网状信息组织方法 ，它以节点为基本单位 ，链作为节点之间的联想式关联 。通常应用在互联网领域。
现代编译器的集成开发环境一般采用数据仓储(即以数据为中心的架构风格)架构风格进行开发，
其中心数据就是程序的语法树。

闭环控制架构(过程控制)

当软件被用来操作一个物理系统时，软件与硬件之间可以粗略的表示为一个反馈循环，这个反馈
循环通过接受一定的输入，确定一系列的输出，最终使环境达到一个新的状态，适合于嵌入式系统，涉及连续的动作与状态。

C2 架构风格

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

• (1)系统中的构件和连接件都有一个顶部和一个底部；
• (2)构件的顶部应连接到某连接件的底部，构件的底部则应连接到某连接件的顶部，而构件与构****件之 间的直接连接是不允许的；
• (3)一个连接件可以和任意数目的其它构件和连接件连接；
• (4)当两个连接件进行直接连接时 ，必须 由其中一个的底部 到另一个的顶部。

必背：

3.2 层次结构风格

两层C/S 架构

客户端和服务器都有处理功能 ，相比较于传统的集中式软件架构，还是有不少优点的，但是现在已经不常用，原因有：开发成本较高 、客户端程序设计复杂 、信息内容和形式单一 、用户界面风格不一 、软件移植困难 、软件维护和升级困难 、新技术不能轻易应用、安全性 问题、服务器端压力大难以复用。

三层 C/S 架构

将处理功能独立出来，表示层和数据层都变得简单。表示层在客户机上，功能层在应用服务器上，数据层在数据库服务器上。即将两层 C/S 架构中的数据从服务器中独立出来了。其优点下面四点：

• 各层在逻辑上保持相对独立 ，整个系统的逻辑结构更为清晰 ，能提高 系统和软件的可维护性和可****扩展性；
• 允许灵活 有效的选用 相应的平台和硬件 系统，具有良好的可升级性和开放性；
• 各层 可以并行开发 ，各层也可 以选 择各自最适合的开发语言；
• 功能层有效的隔离表示层与数据层，为严格的安全管理奠定了坚实的基础，整个系统的管理层次****也更加合理和可控制。

三层 C/S 架构设计的关键在于各层之间的通信效率，要慎重考虑三层间的通信方法、通信频度和
数据量，否则即使分配给各层的硬件能力很强，性能也不高。

三层 B/S 架构

是三层C/S 架构的变种，将客户端变为用户客户端上的浏览器，将应用服务器变为网络上的 WEB服务器，又称为0客户端架构，虽然不用开发客户端，但有很多缺点，主要是数据处理能力差：

• B/S架构缺乏对动态页面的支持能力，没有集成有效的数据库处理功能；
• 安全性难以控制；
• 在数据查询等响应速度 上，要远远低于C/S架构；
• 数据提交一般以页面为单位，数据的动态交互性不强 ，不利于 OLTP应用。

混合架构风格

内外有别模型：企业内部使用C/S,外部人员访问使用 B/S。
查改有别模型：采用 B/S 查询，采用 C/s修改。
混合架构实现困难，且成本高。

富互联网应用 RIA

弥补三层 B/S架构存在的问题，RIA是一种用户接口，比用HTML实现的接口更加健壮，且有可
视化内容，本质还是网站模式 ，其优点如下：

• RIA结合 了C/S 架构反应速度快 、交互性强的优点与B/S 架构传播范围广 及容易传播的特性；
• RIA 简化并改进了B/S架构的用户交互；
• 数据能够被缓存在客户端，从而可以实现一个比基于 HTML的响应速度更快且数据往返于服务器的次数更少的用户界面。

本质还是0客户端，借助于高速网速实现必要插件在本地的快速缓存，增强页面对动态页面的支
持能力，典型的如小程序。--- 其实是利用高速的网络在现搭建一个客户端。

MVC

用户操作->View(负责接收用户的输入操作 )->Controller(业务逻辑处理 )->Model(数据持久化 )->View(将结果反馈给View)。经典 MVC架构如下图所示：

MVP

MVP是把 MVC中的 Controller换成了 Presenter(呈现),目的就是为了完全切断 View跟Model 之间的联系，由 Presenter 充当桥梁，做到 View-Model之间通信的完全隔离。

MVVM

如果说MVP是对 MVC的进一步改进，那么 MVVM 则是思想的完全变革。它是将"数据模型数据双向绑定 "的思想作为核心，因此在 View和 Model之间没有联系，通过ViewModel 进行交互，而且 Model 和 ViewModel 之间的交互是双向的，因此视图的数据的变化会同时修改数据源，而数据源数据的变化也会立即反应到View上。-- View和Model之间不直接联系，通过ViewModel来交互，ViewModel和Model双向交互。

3.3 面向服务的架构 SOA

概念

SOA是一种粗粒度、松耦合服务架构 ，服务之间通过简单、精确定义接口进行通信，不涉及底层编程接口和通信模型。
在 SOA 中，服务是一种为了满足某项业务需求的操作、规则等的逻辑组合，它包含一系列有序活动的交互，为实现用户目标提供支持。
SOA并不仅仅是一种开发方法，还具有管理上的优点，管理员可直接管理开发人员所构建的相同
服务。多个服务通过企业服务总线提出服务请求，由应用管理来进行处理，如下：

实施 SOA的关键目标是实现企业IT资产重用的最大化。
在实施 SOA过程中要牢记以下特征：

• 可从企业外部访问 、随时可用 (服务请求能被及时响应)、
• 粗粒度接口(粗粒度提供一项特定的业务功能，而细粒度服务代表了技术构件方法)、
• 服务分级、
• 松散耦合 (服务提供者 和服务使用者分离)、
• 可重用的服务及服务接口设计管理、
• 标准化的接口(WSDL、SOAP、XML是核心)、
• 支持各种消息模式、
• 精确定义的服务接口。

总结：

外部访问、可用及时、粗粒度、服务分级、松耦合(提/使)、可重用、标准化、消息模式多，接口精确定义

XML是一种描述语言，WSDL是基于XML的描述服务的，SOAP是 简单对象访问协议，用于交换数据的
从基于对象到基于构件再到基于服务，架构越来越松散耦合，粒度越来越粗，接口越来越标准。
基于服务的构件与传统构件的区别有四点：

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

总结：

服务构件粗粒度，传统细粒度；服务构件接口标准，传统API；服务构件实现语言无关，传统正相反；服务构件有容器QoS，传统代码保证。

关键技术

SOA 中应用的关键技术如下表。

发现服务

UDDI: 用于 Web服务注册 和服务查找，描述了服务的概念，定义了编程的接口，供其他企业来
调用。
DISCO:发现公开服务的功能及交互协议。

描述服务

WSDL(WEB服务描述语言)协议 ：用于描述 Web服务的接口和操作功能 ，描述网络服务。

消息格式层

SOAP 为建立 Web服务和服务请求之间 的通信 提供支持。
REST (Representational State Transfer,表述性状态转移 )是一种只使用HTTP和 XML进行基于 Web 通信的技术，可以降低开发的复杂性，提高系统的可伸缩性。

编码格式层

扩展标记语言 (Extensible Markup Language, XML),用于标记电子文件使其具有结构性的标记语言，可以用来标记数据、定义数据类型，是一种允许用户对自己的标记语言进行定义的源语言。

SOA的实现方式

WEB Service

服务提供者、服务注册中心 (中介，提供交易平台，可有可无)、服务请求者。服务提供者将服务描述发布到服务注册中心，供服务请求者查找，查找到后，服务请求者将绑定查找结果。如下图：

分为六层：

• 底层传输层： 负责底层消息的传输 ，采用HTTP、JMS、SMTP协议
• 服务通信协议层 ：描述并定义服务间通信的技术标准 ，采用 SOAP和 REST协议
• 服务描述层 ：采用WSDL协议
• 服务层： 对企业应用系统进行包装 ，通过WSDL 定义的标准 进行调用
• 业务流程层： 支持服务发现 服务调用 和点到点的服务调用 ，采用WSDPEL标准
• 服务注册层 ：采用UDDI协议

补充：

JMS是Java消息服务**，Java中**面向消息中间件API

底层是传输层，消息传输模块；通信层用一些SOAP和REST协议来封装一下底层消息；描述层采用WSDL协议描述服务；服务层是包装各系统，并采用WSDL标准调用；业务流程层，来提供发现、调用的方式、标准；注册层，用UDDI协议，用于注册。

服务注册表

• 服务注册：应用开发者(服务提供者)在注册表中公布服务的功能。
• 服务位置：服务使用者(服务应用开发者),帮助他们查询注册服务，寻找符合自身要求的服务。
• 服务绑定：服务使用者利用检索到的服务接口来编写代码，所编写的代码将与注册的服务绑定，调用注册的服务，以及与它们实现互动。

本质与WEB Service类似，只是使用一个注册表来代替服务注册中心。

企业服务总线 ESB

客户端(服务请求者)、基础架构服务(中间件)、核心集成服务(提供服务)。本质也是通过网络，有下列六点功能：

• 提供位置透明性 的消息路由和寻址服务；
• 提供服务注册 和命名的管理功能；
• 支持多种 的消息传递范型；
• 支持多种 可以广泛使用的传输协议；
• 支持多种数据格式及其相互转换；
• 提供日志和监控功能。

4 软件架构复用

软件产品线是指一组软件密集型系统，它们共享一个公共的、可管理的特性集，满足某个特定市场或任务的具体需要，是以规定的方式用公共的核心资产集成开发出来的 。即围绕核心资产库进行管理、复用、集成新的系统。
软件架构复用 的类型包括机会复用和系统复用 。机会复用是指开发过程中，只要发现有可复用的资产，就对其进行复用 。系统复用是指在开发之前，就要进行规划，以决定哪些需要复用。
可复用的资产包括：需求、架构设计、元素、建模与分析、测试、项目规划、过程方法和工具、人员、样本系统、缺陷消除。
复用的基本过程主要包括3个阶段 ：首先 构造/获取可复用的软件资产，其次 管理这些资产(构件库),最后针对特定的需求，从这些资产中选择可复用的部分，以开发满足需求的应用系统。

5 特定领域软件架构 DSSA

DSSA 就是专用于一类特定类型的任务(领域)的、在整个领域中能有效地使用的、为成功构造应用 系统限定了标准的组合结构的软件构件的集合。
-- 它是一个构件集合，只是这个集合的构件都是适应于特定的领域，在这个领域中比较通用，或者比较标准。
DSSA 就是一个特定的问题领域中支持一组应用的领域模型、参考需求、参考架构 等组成的开发基础，其目标就是支持在一个特定领域中多个应用的生成。
垂直域： 在一个特定领域中 的通用的软件架构，是一个完整的架构。
水平域： 在多个不同的特定领域之间的相同的部分的小工具(如购物和教育都有收费系统，收费
系统即是水平域)。

DSSA的三个基本活动

领域分析： 这个阶段的主要目标是获得领域模型(领域需求) 。识别信息源，即整个领域工程过程中信息的来源，可能的信息源包括现存系统、技术文献、问题域和系统开发的专家、用户调查和市场分析、领域演化的历史记录等，在此基础上就可以分析领域中系统的需求，确定哪些需求是领域中的系统广泛共享的，从而建立领域模型。
领域设计 ：这个阶段的目标是获得 DSSA 。DSSA描述在领域模型中表示的需求的解决方案 ，它不是单个系统的表示，而是能够适应领域中多个系统的需求的一个高层次的设计。建立了领域模型之后，就可以派生出满足这些被建模的领域需求 DSSA。
领域实现 ：这个阶段的主要目标是依据领域模型和 DSSA开发和组织可重用信息。这些可重用信息可能是从现有系统中提取得到，也可能需要通过新的开发得到。
以上过程是一个反复的、逐渐求精的过程。在实施领域工程的每个阶段中，都可能返回到以前的步骤，对以前的步骤得到的结果进行修改和完善，再回到当前步骤，在新的基础上进行本阶段的活动。

参与 DSSA的四种角色人员

领域专家 ：包括该领域中系统的有经验的用户 、从事该领域中系统的需求分析、设计、实现以及项目管理的有经验的软件工程师 等。提供 关于领域中 系统的需求规约和实现的知识 ，帮助组织规范 的、一致的领域字典 ，帮助选择样本 系统作为领域工程的依据，复审领域模型、DSSA等领域工程产品，等等。
领域分析人员 ：由具有知识工程背景的有经验的系统分析员 来担任。控制 整个领域分析过程 ，进行知识获取 ，将获取的知识组织到领域模型中。
领域设计人员 ：由有经验的软件设计人员 来担任。根据领域模型和现有系统开发出DSSA ,并对DSSA的准确性和一致性进行验证。
领域实现人员 ：由有经验的程序设计人员来担任。根据领域模型和 DSSA,开发构件。

建立 DSSA的过程

(1)定义领域范围：领域中的应用要满足用户一系列的需求。
(2)定义领域特定的元素 ：建立领域的字典 ，归纳领域中的术语 ，识别 出领域中相同和不相同的元素。
(3)定义领域特定的设计和实现需求的约束 ：识别 领域中的所有约束，这些约束对领域的设计和实现会造成什么后果。
(4)定义领域模型和架构 ：产生 一般的架构，并描述其构件说明。
(5)产生、搜集可复用的产品单元 ：为 DSSA增加复用构件，使可用于新的系统。
以上过程是并发的、递归的、反复的、螺旋型的 。该过程的目的是将用户的需求映射为基于实现限制集合的软件需求，这些需求定义了 DSSA。
定范围-->定元素-->识别约束-->产生架构-->产生构件。 这些过程并发、递归、反复、螺旋的

DSSA的三层次系统模型

领域开发环境 ：领域架构师决定核心架构，产出参考结构、参考需求、架构、领域模型、开发工具。
领域特定的应用开发环境 ：应用工程师根据具体环境来将核心架构实例化。
应用执行环境 ：操作员实现实例化后的架构。

6 系统质量属性与架构评估

6.1 软件系统质量属性

软件系统的质量就是"软件系统与明确地和隐含地定义的需求相一致的程度"。
-- 明确提出的(SRS)，以及隐含的期望，这些都是需求，软件系统表现与这些需求一致的程度就用软件系统的质量来表达。

可以将软件系统的质量属性分为开发期质量属性和运行期质量属性2个部分。

1.开发期质量属性主要指在软件开发阶段所关注的质量属性，主要包含6个方面。

• (1)易理解性：指设计被开发人员理解的难易程度。
• (2)可扩展性：软件因适应新需求或需求变化而增加新功能的能力，也称为灵活性。
• (3)可重用性：指重用软件系统或某一部分的难易程度。
• (4)可测试性：对软件测试以证明其满足需求规范的难易程度。
• (5)可维护性：当需要修改缺陷、增加功能、提高质量属性时，识别修改点并实施修改的难易程度。
• (6)可移植性：将软件系统从一个运行环境转移到另一个不同的运行环境的难易程度。

理解、扩展、重用、测试、维护、移植的难易程度。
2.运行期质量属性主要指在软件运行阶段所关注的质量属性，主要包含7个方面。

• (1)性能：性能是指软件系统及时提供相应服务的能力，如速度、吞吐量和容量等的要求。
• (2)安全性：指软件系统同时兼顾向合法用户提供服务，以及阻止非授权使用的能力。
• (3)可伸缩性：指当用户数和数据量增加时，软件系统维持高服务质量的能力。例如，通过增加服务器来提高能力。
• (4)互操作性：指本软件系统与其他系统交换数据和相互调用服务的难易程度。
• (5)可靠性：软件系统在一定的时间内持续无故障运行的能力。
• (6)可用性：指系统在一定时间内正常工作的时间所占的比例。可用性会受到系统错误，恶意攻击，高负载等问题的影响。
• (7)鲁棒性：是指软件系统在非正常情况(如用户进行了非法操作、相关的软硬件系统发生了故障等)下仍能够正常运行的能力，也称健壮性或容错性。

性能、安全、伸缩、互操作、可靠、可用、鲁棒

伸缩：能屈能伸，用户量访问量上来能及时调整资源保持系统运行快速，质量不打折扣。

互操作：跟其他系统或人、设备打交道的难易程度

可靠：尽量长时间运行不发生故障

可用：不发生故障运行所占比例(要尽量高) -- 可用可靠都出现首选可用

鲁棒：健壮，容错，比如发生非法操作，意外故障能容错，甚至恢复(比如云服务就有容错机制)，这样更健壮。

面向架构评估的质量属性

1、性能：指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件的个数。如响应时间、吞吐量。
设计策略 ：优先级队列、增加计算资源、减少计算开销、引入并发机制、采用资源调度等。
2、可靠性：是软件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统的功能特性的基本能力。如 MTTF、MTBF。
设计策略 ：心跳、Ping/Echo、冗余、选举。包括容错和健壮性。
3、可用性：是系统能够正常运行的时间比例，经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。如故障间隔时间。
设计策略 ：心跳、Ping/Echo、冗余、选举。
4、安全性：是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。如保密性、完整性、不可抵赖性、可控性。
设计策略 ：入侵检测、用户认证、用户授权、追踪审计。
5、可修改性：指能够快速的以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准，通过考察这些变更的代价衡量。包括可维护性、可扩展性、结构重组、可移植性。
设计策略 ：接口-实现分类、抽象、信息隐藏。
6、功能性 ：是系统所能完成所期望的工作的能力。一项任务的完成需要系统中许多或大多数构件的相互协作。
7、可变性 ：指体系结构经扩充或变更而成为新体系结构的能力。这种新体系结构应该符合预先定义的规则，在某些具体方面不同于原有的体系结构。当要将某个体系结构作为一系列相关产品的基础时，可变性是很重要的。
8、互操作性：作为系统组成部分的软件不是独立存在的，经常与其他系统或自身环境相互作用。
为了支持互操作性，软件体系结构必须为外部可视的功能特性和数据结构提供精心设计的软件入口。程序和用其他编程语言编写的软件系统的交互作用就是互操作性的问题，也影响应用的软件体系结构。

前面的开发期属性和运行期属性综合一下，针对架构进行评估的质量属性提炼就是这些： 性能、可靠、可用、安全、可修改、功能、可变、互操作。
重点记忆钱5个及设计策略。
针对每个质量属性构造质量属性场景，来衡量这个属性对架构的影响程度，就是以下质量属性场景的应用。

质量属性场景是一种面向特定质量属性的需求。它由6 部分组成：

· 刺激源(Source):这是某个生成该刺激的实体(人、计算机系统或者任何其他刺激器)。
· 刺激(Stimulus):该刺激是当刺激到达系统时需要考虑的条件。
·环境(Environment):该刺激在某些条件内发生。当激励发生时，系统可能处于过载、运行或者其他情况。
· 制品(Artifact):某个制品被激励。这可能是整个系统，也可能是系统的一部分。
· 响应(Response):该响应是在激励到达后所采取的行动。
· 响应度量(Measurement):当响应发生时，应当能够以某种方式对其进行度量，以对需求进行测试。
可修改性质量属性场景描述实例：

6.2 系统架构评估

<系统架构评估>是在对架构分析、评估的基础上，对架构策略的选取进行决策 。-- 系统架构评估是 在架构分析和架构评估基础上(可理解为分析之后内部评估分析结果)，再对架构选取的策略评估。
<软件架构评估>在架构设计之后 ，系统设计之前 ，因此与设计、实现、测试都没有关系。评估的目的 是为了评估所采用的架构是否能解决软件系统需求，但不是单纯的确定是否满足需求。

三种常用的评估方式

基于调查问卷(检查表)的方式：类似于需求获取中的问卷调查方式，只不过是架构方面的问卷，要求评估人员对领域熟悉。
基于度量的方式 ：制定一些定量来度量架构，如代码行数等。要制定质量属性和度量结果之间的映射，要求评估人员对架构熟悉。涉及3个基本活动，首先 需要建立质量属性和度量之间的映射 原则，然后 从软件架构文档中获取度量信息 ，最后 根据映射原则分析推导出系统的质量属性。
基于场景的方式 ：主要方法。首先 要确定应用领域的功能和软件架构的结构之间的映射 ，然后 要设计用于体现待评估质量属性的场景 (即 4+1视图中的场景 ),最后分析 软件架构对场景的支持程度。
要求评估人员即对领域熟悉，也对架构熟悉。
三种评估方式的比较：

由上表可知，场景最不通用，度量要求对构架精确了解，调查问卷实施阶段最早，度量最客观。
其中，基于场景的方式是主流。

架构评估中的重要概念

敏感点：是指为了实现某种特定的质量属性，一个或多个构件所具有的特性。
权衡点：是影响多个质量属性的特性，是多个质量属性的敏感点。
风险点与非风险点不是以标准专业术语形式出现的，只是一个常规概念，即可能引起风险的因素，
可称为风险点。某个做法如果有隐患，有可能导致一些问题，则为风险点；而如果某件事是可行的 可接受的，则为非风险点。
从三个方面对场景进行设计：

• 刺激(事件)
• 环境(事件发生的环境)
• 响应(架构响应刺激的过程)。

6.3 基于场景的评估方法

基于场景的架构分析方法SAAM

SAAM是 一种非功能质量属性的架构分析方法 ，是最早形成文档并得到广泛应用的软件架构分析方法。
特定目标。SAAM的 目标 是对描述应用程序属性的文档，验证基本的架构假设和原则。
质量属性。这一方法的 基本特点 是把任何形式的质量属性都具体化为场景 ，但可修改性是 SAAM
分析的主要质量属性。
架构描述 。SAAM用于架构的最后版本，但早于详细设计。架构的描述形式应当被所有参与者理解。
功能、结构和分配被定义为描述架构的3个主要方面 。
方法活动。SAAM的 主要输入 是问题描述、需求说明和架构描述。下图描绘了SAAM分析活动的相关输入及评估过程。
包括5个步骤，即场景开发、架构描述、单个场景评估、场景交互 和总体评估。
开发场景，架构描述，先单个场景，然后多个场景交互，最后总体评估。

架构权衡分析法 ATAM

让架构师明确如何权衡多个质量目标，参与者有评估小组、项目决策者和其他项目相关人。
ATAM被分为四个主要的活动领域，分别是场景和需求收集 、体系结构视图和场景实现 、属性模
型构造和分析 、折中 。整个评估过程强调以属性作为架构评估的核心概念 。主要针对性能、可用性、安全性和可修改性 ，在系统开发之前，对这些质量属性进行评价和折中。
ATAM方法采用效用树 (Utility tree)这一工具来对质量属性进行分类和优先级排序 。效用树的结构包括：树根-质量属性-属性分类-质量属性场景(叶子节点)。需要注意的是，ATAM/主要关注 4 类质量属性：性能、安全性、可修改性和可用性，这是因为这4个质量属性是利益相关者最为关心的。

ATAM方法架构评估实践

注意：这个内容选择案例不会考。但是可用于写论文的步骤，建议写这个主题论文的，重点看
一下第二版教材第8.3节，第289 页，书上给出了胡佛事件架构、银行事件架构这两个具体架构的详细描述，可作为大家写论文时的素材参考，不过书上写的比较多比较复杂，大家也要有选择性的参考。当然也可以直接听文老师论文直播里这块的讲解来构思。

成本效益分析法 CBAM

用来对架构建立的成本来进行设计和建模 ，让决策者根据投资收益率来选择合适的架构，++可以看++
++做对 ATAM的补充++ ，在 ATAM确定质量合理的基础上，再对效益进行分析。有下列步骤：

• (1)整理场景 (确定场景，并确定优先级，选择三分之一优先级最高的场景进行分析);
• (2)对场景进行细化(对每个场景详细分析，确定最好、最坏的情况);
• (3)确定场景的优先级(项目干系人对场景投票，根据投票结果确定优先级);
• (4)分配效用(对场景响应级别确定效用表，建立策略、场景、响应级别的表格);
• (5)形成"策略-场景-响应级别的对应关系";
• (6)确定期望的质量属性响应级别的效用(根据效用表确定所对应的具体场景的效用表);
• (7)计算各架构策略的总收益；
• (8)根据受成本限制影响的投资报酬率选择架构策略(估算成本，用上一步的收益减去成本，得出收益，并选择收益最高的架构策略)。

其他评估方法(仅了解)

1.SAEM 方法。将软件架构看作一个最终产品以及设计过程中的一个中间产品，从外部质量属性
和内部质量属性两个角度来阐述它的评估模型，旨在为软件架构的质量评估创建一个基础框架。
外部属性指用户定义的质量属性，而内部属性指开发者决定的质量属性。该软件架构评估模型包
含以下几个流程。

• (1)对待评估的质量属性进行规约建模。

• (2)为外部和内部的质量属性创建度量准则，先从评估目的(如软件架构比较、最终产品的质量预测),评估角度(如开发者、用户、维护者),评估环境(架构作为最终产品或设计中间产品)出发来定义架构评估的目标，再根据目标相关的属性来提出问题，然后回答每个问题并提出相应的度量准则。

• (3)评估质量属性，包括数据收集、度量和结果分析3个活动。

2.SAABNet方法。是一种用来表达和使用定性知识以辅助架构的定性评估。该方法来源于人工智
能，允许不确定、不完整知识的推理。该方法使用 BBN 来表示和使用开发过程中的知识，包含定性和定量的描述，其中定性的描述是所有结点的图，定量的描述是每个结点状态相关的条件概率。
其中的变量可分为3 类，即架构质量属性变量(如可维护性、灵活性等)、质量属性的度量准则
变量(如容错性、响应性等)和架构特征变量(如继承深度、编程语言等),高层抽象的质量属性变
量分解为低层抽象的度量准则变量，度量准则变量则分解为更低层抽象的架构特征变量。
3.SACMM方法。是一种软件架构修改的度量方法。
4.SASAM方法。通过对预期架构(架构设计阶段的相关描述材料)和实际架构(源代码中执行的
架构)进行映射和比较来静态地评估软件架构。
5.ALRRA方法。是一种软件架构可靠性风险评估方法，该方法使用动态复杂度准则和动态耦合度
准则来定义组件和连接件的复杂性因素，其中，动态复杂度准则在某个场景的执行中分析组件的动态行为来度量组件的复杂性，动态耦合度准则在某个场景的执行中分析连接件的消息传递协议来度量连接件的复杂性。利用失效模式和影响分析(FMEA)技术。
6.AHP(层次分析法)方法。是对定性问题进行定量分析的一种简便、灵活而又实用的多准则决
策方法。AHP方法的特点是把复杂问题中的各种因素通过划分为相联系的有序层次使之条理化，并在一般情况下通过两两对比，根据一定客观现实的主观判断结构，把专家意见和分析者的客观判断结果直接、有效地结合起来，将一定层次上元素的某些重要性进行定量描述，之后利用数学方法计算反映每一层次元素的相对重要性次序的权值，井最后通过所有层次之间的总排序计算所有元素的相对权重及对权重进行排序。
7.COSMIC+UML方法。基于度量模型来评估软件架构可维护性的方法。针对不同表达方式的软件
架构，采用统一的软件度量 COSMIC 方法来进行度量和评估。该方法主要是为了辅助分析软件架构的演化方案是否可行，并在开源软件 DCMMS 的软件架构 UML 组件图上得以验证。

7 中间件技术

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

中间件特点

• 负责客户机与服务器之间的连接和通信，以及客户机与应用层之间的高效率通信机制。
• 提供应用层不同服务之间的互操作机制，以及应用层与数据库之间的连接和控制机制。
• 提供多层架构的应用开发和运行的平台，以及应用开发框架，支持模块化的应用开发。
• 屏蔽硬件、操作系统、网络和数据库的差异。
• 提供应用的负载均衡和高可用性、安全机制与管理功能，以及交易管理机制，保证交易的一致性。
• 提供一组通用的服务去执行不同的功能，避免重复的工作和使应用之间可以协作。

按照中间件在分布式系统中承担的职责不同，可以划分以下几类中间件产品。

1)通信处理(消息)中间件
在分布式系统中，要建网和制定出通信协议，以保证系统能在不同平台之间通信，实现分布式系统中可靠的、高效的、实时的跨平台数据传输，这类中间件称为消息中间件，也是市面上销售额最大的中间件产品。
2)事务处理(交易)中间件
在分布式事务处理系统中，经常要处理大量事务，特别是OLTP 中，每项事务常常要多台服务器上的程序按顺序协调完成，一旦中间发生某种故障，不但要完成恢复工作，而且要自动切换系统保证系统永不停机，实现高可靠性运行。要使大量事务在多台应用服务器上能实时并发运行，并进行负载平衡的调度，实现与昂贵的可靠性机和大型计算机系统的同等功能，为了实现这个目标，要求中间件系统具有监视和调度整个系统的功能。
3)数据存取管理中间件
在分布式系统中，重要的数据都集中存放在数据服务器中，它们可以是关系型的、复合文档型、具有各种存放格式的多媒体型，或者是经过加密或压缩存放的，该中间件将为在网络上虚拟缓冲存取、格式转换、解压等带来方便。
4) Web 服务器中间件
浏览器图形用户界面己成为公认规范，然而它的会话能力差，不擅长做数据的写入任务，受HTTP
协议的限制多等，就必须对其进行修改和扩充，因此出现了Web 服务器中间件。
5)安全中间件
一些军事、政府和商务部门上网的最大障碍是安全保密问题，而且不能使用国外提供的安全措施(如防火墙、加密和认证等),必须用国产产品。产生不安全因素是由操作系统引起的，但必须要用中间件去解决，以适应灵活多变的要求。
6)跨平台和架构的中间件
当前开发大型应用软件通常采用基于架构和构件技术，在分布式系统中，还需要集成各结点上的不同系统平台上的构件或新老版本的构件，由此产生了架构中间件。功能最强的是CORBA ,可以跨
任意平台，但是其过于庞大； JavaBeans 较灵活简单，很适合用于浏览器，但运行效率有待改善；COM十模型主要适合Windows 平台，已在桌面系统广泛使用。由于国内新建系统多基于 UNIX(包括 Linux)和 Windows ,因此，针对这两个平台建立相应的中间件市场相对要大得多。
7)专用平台中间件
专用平台中间件为特定应用领域设计领域参考模式，建立相应架构，配置相应的构件库和中间件，为应用服务器开发和运行特定领域的关键任务(如电子商务、网站等)。
8)网络中间件
它包括网管、接入、网络测试、虚拟社区和虚拟缓冲等，也是当前最热门的研发项目。

软件构件

软件构件构件又称为组件，是一个自包容、可复用的程序集。构件是一个程序集，或者说是一组程序的集合。构件的两个最重要的特性是自包容与可重用。
构件组装模型的一般开发过程：设计构件组装、建立构件库、构建应用软件、测试与发布。

商用构件标准规范-CORBA(公共对象请求代理体系结构)

公共对象请求代理架构(CORBA)主要分为3 个层次：对象请求代理、公共对象服务和公共设施。
最底层的对象请求代理(ORB)规定了分布对象的定义(接口)和语言映射，实现对象间的通信和互操作，是分布对象系统中的"软总线";
在 ORB 之上定义了很多公共服务，可以提供诸如并发服务、名字服务、事务(交易)服务、安全服务等各种各样的服务；
最上层的公共设施则定义了构件框架，提供可直接为业务对象使用的服务，规定业务对象有效协作所需的协定规则。
COREA CCM 构件模型是OMG 组织制定的一个用于开发和配置分布式应用的服务器端构件模型规范，它主要包括如下3 项内容。
(1)抽象构件模型：用以描述服务器端构件结构及构件间互操作的结构。
(2)构件容器结构：用以提供通用的构件运行和管理环境，并支持对安全、事务、持久状态等系统服务的集成。
(3)构件的配置和打包规范：CCM 使用打包技术来管理构件的二进制、多语言版本的可执行代码和配置信息，井制定了构件包的具体内容和文档内容标准。
对象管理组织(OMG)基于 CORBA基础设施定义了四种构件标准。
实体(Entity)构件需要长期持久化并主要用于事务性行为，由容器管理其持久化。
加工(Process)构件同样需要容器管理其持久化，但没有客户端可访问的主键。
会话(Session)构件不需要容器管理其持久化，其状态信息必须由构件自己管理。
服务(Service)构件是无状态的。
CORBA对象可看作是一个具有对象标识、对象接口及对象实现的抽象实体。之所以称为抽象的， 是因为并没有硬性规定 CORBA 对象的实现机制一个 CORBA 对象的引用又称可互操作的对象引用
(Interoperable Object Reference)。从客户程序的角度看，IOR 中包含了对象的标识、接口类型及其他信息以查找对象实现。
对象标识(Object ID)是一个用于在POA中标识一个CORBA对象的字符串。它既可由程序员指派，也可由对象适配器自动分配，这两种方式都要求对象标识在创建它的对象适配器中必须具有唯一
性。
POA(便携式对象适配器)是对象实现与 ORB其它组件之间的中介，支持由 Object Id 标识的对象的名称空间，它将客户请求传送到伺服对象，按需创建子 POA,提供管理伺服对象的策略。
伺服对象(servant)是指具体程序设计语言的对象或实体，通常存在于一个服务程序进程之中。
客户程序通过对象引用发出的请求经过 ORB 担当中介角色，转换为对特定的伺服对象的调用。在一个 CORBA 对象的生命期中，它可能与多个伺服对象相关联，因而对该对象的请求可能被发送到不同的伺服对象。

7.1 典型的应用架构-J2EE

分布式多层应用程序

客户层(客户应用或 WEB浏览器动态网页)对应客户机；
WEB层(可省略，是WEB浏览器)和业务层(业务处理逻辑，包括会话 Bean,实体 Bean和消息驱动 Bean)对应J2EE 服务器；
企业信息系统层对应数据存储服务器。

JAVA企业应用框架

Structs 框架：是一个基于 J2EE 平台的 MVC(模型、视图、控制器)框架，采用 Servelet和 JSP技术实现。M 由实现业务逻辑的 javaBean构成，C由 ActionServlet和 Action来实现，V由一组JSP文件构成。
Spring 框架：通过RMI或 Web Servic远程访问业务逻辑，允许自由选择和组装各部分功能，还提供和其他软件集成的接口。Spring 本身是个容器，管理构件的生命周期、构件的组态、依赖注入等，并可以控制构件在创建时是以原型或单例模式来创建。
Hibernate 框架：是一个对象关系映射框架，提供了java 对象到数据库表之间的直接映射，它对JDBC 进行了非常轻量级的对象封装，使得 java 程序员可以使用对象编程思维来操作数据库。在
Hibernate 中，ORM机制的核心是一个XML文件，该文件描述了数据库模式是怎么与一组 java类绑定在一起的。

表示层由 Structs 实现，管理用户请求；业务层由 Spring实现，处理业务逻辑中的业务处理情况，提供一个控制器的代码；数据库层由 Hibernate 实现，通过面向对象的查询语言 HQL来实现数据的增删改查。这样组合可以搭建一个轻量级的J2EE 架构。

重量级与轻量级之争

重量级与轻量级之争重量级框架占用资源过多，在开发的过程中效率很低；大部分时间花在配置、运行的过程上，修改复杂；单元测试也比较麻烦。但在大量运行过程中会表现出优异的效果，也即开发麻烦，运行性能高。
轻量级框架提高了开发的速度；立即可以看到结果；做单元测试非常简单；大量线程可供参考的开源代码。开发简单，但运行性能低。

7.2 典型的应用架构-.NET

.NET框架处于操作系统和.NET应用语言之间，只适用于微软系统，而J2EE 支持跨平台，任何安
装了JVM的平台。

.NET和J2EE 之争

JVM(将所有 JAVA代码都编译为字节码，由 JVM 解释执行)和 CLR(.NET 核心技术，类似于JVM,生成中间代码 CLR,编译执行)。
对多层分布式应用的支持，二者都支持多层分布式应用程序的开发：在表示层的平台支持上， J2EE 客户端支持多个平台，.NET 只能在微软系统上运行，也正是因此，.NET 会对微软系统上的应用进行优化；在业务层，J2EE 占优势，因为有许多开源的项目和代码供参考，开发就变得简单；在数据层，二者都支持多种数据库，都非常优秀。
安全性，由于 JAVA在.NET之后出来，借鉴了.NET优点，JAVA在运行时动态验证，.NET是静态全面验证，二者都非常优秀，不分上下。
应用程序的部署，J2EE 的部署相对来说较复杂，针对不同的系统要特别布置。
可移植性，显然 J2EE 占优势，一次开发，到处运行。
外部支持：J2EE 占优势，得到了很多厂家的支持，.NET只是微软一家。