软件体系结构期末复习

1.绪论

1.1 体系结构思想的诞生时间1960s

1.2 体系结构三要素（组成派定义）

• 组件（Component）
  • 组件是系统中的模块或单元，代表着系统中可以独立设计、实现和替换的部分。每个组件都有自己的职责和功能，并通过定义的接口和其它组件进行交互。组件可以包括软件模块、类、对象等，是系统的基本构件块。
• 连接体（Connector）
  • 连接体表示组件之间的通信和协作方式。它描述了组件之间的连接方式，包括消息传递、过程调用、数据流等。连接体定义了组件之间的关系，促使它们之间协同工作以实现系统的整体功能。良好的连接体设计有助于提高系统灵活性和可扩展性。
• 约束（Constraint）
  • 约束是对系统设计和实现的限制和规定。这些限制可以涉及性能、安全性、可维护性等方面。约束帮助定义了系统的边界和规则，确保系统满足特定的需求，并符合一定的标准和规范。约束可以影响组件的选择、连接体的设计以及整个系统的架构。

1.3 软件重用

• 软件重用：指在两次或多次不同的软件开发过程中重复使用相同或者相似的软件元素的过程。

1.4 软件危机，软件危机的表现有哪些？

• 软件危机：指落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现的一系列严重问题的现象。
• 软件危机的表现：软件开发进度难以预测、软件开发成本难以控制、用户对产品功能难以满足、软件产品质量无法保证、软件产品难以维护。

1.5 软件重用是为了解决软件危机。

1.6 软件体系结构在软件生命周期中的作用。

2.软件体系结构风格

2.1 软件体系结构风格不能作为软件分类的标准。

2.2 典型的体系结构风格↓。

2.3 每种体系结构的优缺点↓。

2.4 每种体系结构分割典型应用↓。

2.5 每种体系结构风格的特点（以此为基础为指定的软件需求选择最合适的风格）↓。

---

2.2.1 ⭐管道-过滤器风格

• 概述：在管道-过滤器分割下，每个功能模块都有一组输入和输出。功能模块称作过滤器（Filters）；功能模块间的连接可以看作输入、输出数据流之间的通路，所以称作管道（Pipes）。
• 特点：
  1. 过滤器是独立运行的构件
     • 非临近的过滤器之间不共享状态
     • 过滤器自身无状态
  2. 过滤器对其处理上下连接的过滤器“无知”
     • 对相邻的过滤器不施加任何限制
  3. 结果的正确性不依赖于各个过滤器运行的先后次序
     • 各过滤器在输入具备后完成自己的计算。完整的计算过程包含在过滤器之间的拓扑结构中
• 典型应用：
  • 数据处理系统、编译器和解释器等。
• 优点：
  1. 设计者可以将整个系统的输入，输出特性简单的理解为各个过滤器功能的合成。
  2. 支持功能模块的复用
  3. 支持一些特定的分析，如吞吐量计算和死锁检测等
  4. 具有并发性
• 缺点：
  1. 交互处理能力弱
  2. 管道-过滤器风格往往导致系统处理过程的成批操作。
  3. 设计者也许不得不花费经历协调两个相对独立但又存在某种关系的数据流之间的关系，例如多过滤器并发执行时数据流之间的同步问题等。
  4. 根据实际设计的需要，设计者也需要对数据传输进行特定的处理（如为了防止数据泄露而采取加密等手段），导致过滤器必须对输入、输出管道中的数据流进行解析或反解析，增加了过滤器具体实现的复杂性。

2.2.2 ⭐主程序/子程序风格

• 特点：组件为主程序和子程序，连接件为调用-返回机制，拓扑结构为层次化结构。
• 典型应用：小规模的脚本和简单的命令行工具。这种风格适用于不需要复杂组织结构的小型程序，其中主程序调用子程序以完成任务。
• 优点：
  1. 具有很高的数据访问效率，因为计算共享一个存储区。
  2. 不同的计算功能被划分在不同的模块中。
• 缺点：
  1. 对数据存储格式的变化将会影响几乎所有的模块。
  2. 对处理流程的改变和系统功能的增强也很难适应，依赖于控制模块内部的调用次序。
  3. 这种分解方案难以支持有效的复用。

2.2.3 ⭐事件驱动风格

• 特点：
  1. 系统是由若干子系统或元素所组成的一个整体。
  2. 系统有一定的目标，各子系统在某一种消息机制的控制下，为了这个目标而协调行动。
  3. 在某一种消息机制的控制下，系统作为一个整体与环境相适应和协调。
  4. 在一个系统的若干子系统中，必定有一个子系统起着主导作用，而其他子系统则处于从属地位。
  5. 任一系统和系统内的任一元素，都有一个事件收集机制和一个事件处理机制，通过这种机制与周围环境发生作用和联系。
• 典型应用：基于事件的隐式调用风格常常被用于以下领域
  1. 在程序设计环境中用于集成各种工具。
  2. 在数据库管理系统中用于检查数据库的一致性约束条件。
  3. 在用户界面中分离数据和表示。
  4. 在编辑器中支持语法检查。
• 优点：
  1. 事件驱动风格非常适合用于描述系统族，在属于同一族的任何系统中，系统的高级管理子系统的描述是完全类似的，便于重用；
  2. 由于最高管理子系统牢牢的掌握着控制权，又因为各级子系统一般不直接发生关系，因此容易实现并发处理和多任务操作；
  3. 基于事件驱动风格的系统具有良好的可扩展性，设计者只需要为某个对象注册一个事件处理接口就可以将该对象引入整个系统，同时并不影响其他的系统对象。
  4. 定义了包含执行子系统和管理子系统的类层次结构；
  5. 简化客户代码；
  6. 使整个系统的设计更具有一般化。
• 缺点：
  1. 事件驱动风格最大的不足在于构件削弱了自身对系统计算的控制能力
  2. 事件驱动风格中存在的另一个问题在于数据共享
  3. 系统中各个对象的逻辑关系变得更加复杂

2.2.4 ⭐分层风格

• 特点：一个分层系统采用层次化的组织方式构件，系统中的每一层都要承担两个角色
  • 首先，它要为结构的中上层提供服务；
  • 其次，它要作为结构中下面层次的客户，调用下层提供的功能函数。
• 典型应用：计算机网络的设计、大型企业应用、操作系统等。分层风格适用于需要将系统划分为独立层次，每个层次负责特定功能的应用，以提高系统的模块化和可维护性。
• 优点：
  1. 分层风格支持系统设计过程中的逐级抽象
  2. 基于分层风格的系统具有较好的可扩展性
  3. 分层风格支持软件复用
• 缺点：
  1. 并不是所有的系统都适合用分层风格来描述的
  2. 对应抽象出来的功能具体放在哪一个层次上是一个难题

2.2.5 ⭐面向对象风格

• 典型应用：遥感图像处理平台（ENVI）、软件系统、游戏开发、模拟系统等。面向对象风格通过封装、继承和多态提供了一种灵活的设计方式，适用于数据和功能分离的系统中，同样也适合于问题域模型比较明显，或需要人机交互界面的系统。
• 优点：
  1. 高度模块性：数据与其相关操作被组织为对象，成为模块组织的基本单位
  2. 封装功能：一组功能和其实现细节被封装在一个对象中，具有功能的接口被暴露出来
  3. 代码共享：对象的相对独立性可以被反复重用，通过拼装形成不同软件系统
  4. 灵活性：对象在组织的过程中，相互关系可以任意变化，只要接口兼容
  5. 易维护性：对象接近人对问题和解决方案模型的思维方式，易于理解和修改
• 缺点：
  • 面向对象分割最大的不足在于如果一个对象需要调用另一个对象，它就必须要知道那个对象的标识（对象名或者对象引用），这样就无形中增强了对象之间的依赖关系。如果一个对象改变了自己的标识，就必须通知系统中所有和它有调用关系的对象，否则系统就无法正常运行。

2.2.6 解释器风格

2.2.7 基于规则的系统风格

2.2.8 仓库风格

2.2.9 黑板系统风格

2.2.10 C2风格

2.2.11 ⭐客户机/服务器风格

• 特点：客户机和服务器是两个相互独立的逻辑系统，为了完成特定的任务而形成一种协作关系。
• 典型应用： Web应用、数据库系统等。客户机/服务器风格适用于需要将系统分为客户端和服务器端，实现分布式计算和资源共享的应用。

两层C/S架构

• 两层C/S架构处理流程:

• 优点：

  1. 客户机组件和服务器组件分别运行在不同的计算机上，有利于分布式数据的组织和处理。

  2. 组件之间的位置是相互透明的

  3. 客户机程序和服务器程序可运行在不同的操作系统上，便于实现异构环境和多种不同开发技术的融合。

  4. 软件环境和硬件环境的配置具有极大的灵活性，易于系统功能的扩展。

  5. 将大规模的业务逻辑分布到多个通过网络连接的低成本的计算机上，降低了系统的整体开销。

• 缺点：

  1. 开发成本较高（客户机的软硬件要求高）。

  2. 客户机程序的设计复杂度大，客户机负荷重。

  3. 信息内容和形式单一。

  4. C/S架构升级需要开发人员到现场更新客户机程序，对运行环境进行重新配置，增加了维护费用。

  5. 两层C/S结构采用了单一的服务器，同时以局域网为中心，难以扩展到Intranet和Internet。

  6. 数据安全性不高。

三层C/S架构

• 三层C/S处理流程：

• 三层C/S架构相比于两层C/S架构的优点：
  1. 合理地划分三层结构的功能，可以使系统的逻辑结构更加清晰，提高软件的可维护性和可扩充性。
  2. 在实现三层C/S架构时，可以更有效地选择运行平台和硬件环境，从而使每一层都具有清晰的逻辑结构、良好的负荷处理能力和较好的开放性。
  3. 在C/S架构中，可以分别选择合适的编程语言并行开发。
  4. 系统具有较高的安全性。
• 在使用三层C/S架构时需注意以下两个问题：
  1. 如果各层之间的通信效率不高，即使每一层的硬件配置都很高，系统的整体性能也不会太高。
  2. 必须慎重考虑三层之间的通信方法、通信频率和传输数据量，这和提高各层的独立性一样也是实现三层C/S架构的关键性问题。

2.2.12 ⭐浏览器/服务器风格

• 典型应用： Web应用、在线服务等。这种风格适用于基于浏览器的用户界面，通过HTTP等协议实现客户端和服务器之间的通信。

• 基本思想：浏览器/服务器风格是三层C/S风格的一种实现方式。

  1. 与三层C/S结构的解决方案相比，B/S架构在客户机上采用了WWW浏览器，将Web服务器作为应用服务器。
  2. B/S架构核心是Web服务器，数据请求、网页生成、数据库访问和应用程序执行全部由Web服务器来完成。
  3. 在B/S架构中，系统安装、修改和维护全在服务器端解决，客户端无任何业务逻辑。

• 优点：

  1. 客户端只需要安装浏览器，操作简单，能够发布动态信息和静态信息。

  2. 运用HTTP标准协议和统一客户端软件，能够实现跨平台通信。

  3. 开发成本比较低，只需要维护Web服务器程序和中心数据库。客户端升级可以通过升级浏览器来实现。

• 缺点：

  1. 个性化程度比较低，所有客户端程序的功能都是一样的。

  2. 客户端数据处理能力比较差，加重了Web服务器的工作负担，影响系统的整体性能。

  3. 在B/S架构中，数据提交一般以页面为单位，动态交互性不强，不利于在线事物处理（Online Transaction Processing，OLTP）。

  4. B/S架构的可扩展性比较差，系统安全性难以保障。

  5. B/S架构的应用系统查询中心数据库，其速度要远低于C/S架构。

2.2.13 正交架构风格

2.2.14 ⭐模型-视图-控制器（MVC）风格

• 特点：MVC被广泛的应用于用户交互程序的设计中。

  • 模型(Model, M)：模型是应用程序的核心，它封装了问题的核心数据、逻辑关系和计算功能，提供了处理问题的操作过程。
  • 视图(View, V)：视图是模型的表示，提供了交互界面，为用户显示模型信息。
  • 控制器(Controller, C)：控制器负责处理用户与系统之间的交互，为用户提供操作接口。

• 典型应用： Web应用、桌面应用等。老牌的有Struts，Webwork。新兴的MVC框架有Spring MVC，Tapestry，JSF等。还有，如Dinamica，VRaptor等。MVC风格适用于需要将数据模型、用户界面和控制逻辑分离的应用，以提高系统的可维护性和可测试性。

• 优点：

  1. 多个视图与一个模型相对应
  2. 具有良好的移植性
  3. 系统被分割为三个独立的部分，当功能发生变化时，改变其中的一个部分就能满足要求。

• 缺点：

  1. 增加了系统设计和运行复杂性。
  2. 视图与控制器连接过于紧密，妨碍了二者的独立重用。
  3. 视图访问模型的效率比较低。
  4. 频繁访问未变化的数据，也将降低系统的性能。

2.2.15 基于层次消息总线的架构风格

2.2.16 平台/插件风格

2.2.17 面向服务架构风格

2.2.18 云体系结构风格

2.2.19 网格计算体系结构风格

2.2.20 异构风格的集成

3.软件体系结构描述

3.1 体系结构描述的方式：

1. 非标准的图形符号UML（Unified Modeling Language Diagrams）

   • 特点：
     • 语义丰富
     • 语义极不精确
     • 没有形式化基础

2. 模块内联语言MIL (Module & Interconnection Language)

   • 定义：是将一种或多种传统程序设计语言模块连接起来描述软件的体系结构的方法。

   • 特点：

     • 语义比较丰富，但局限在实现级别，层次较低
     • 语义精确，有编译器作保证
     • 没有或极少有形式化基础

   • 实例：

     • Microsoft COM IDL
     • OMG CORBA IDL

3. 基于软构件的描述语言CDL（Component Descrition Language）

   • 定义：由许多以特定形式相互作用的特殊软件实体构造组成的组织或系统。
   • 特点：
     • 以构件为单位来描述软件
     • 面向的是底层的程序设计语言；

4. 体系结构描述语言ADL(Architecture Description Language)

   • 定义：参照传统程序设计语言和开发经验，针对软件的结构特点，重新设计和开发的描述方式，可以在指定的抽象层次上描述软件体系结构。

   • 特点：

     • 简单易懂；
     • 有严格的语义和表述符号；
     • 提供了很多分析工具

   • 实例

     • WRight
     • C2
     • Darwin

3.2 每种描述方式的优缺点：

1. 非标准的图形符号UML（Unified Modeling Language Diagrams）

   • 优点：
     1. 直观形象
     2. 简单易用
   • 缺点：
     • 由于其术语和表达语义上存在着一些不规范和不精确，从而使得以矩形为基础的传统图形表达方法在不同系统和不同文档之间存在着许多不一致甚至矛盾。

2. 模块内联语言MIL (Module & Interconnection Language)

   • 优点：

     1. 具有严格的语义基础，能够支持对较大的软件单元进行诸如：定义/使用（Definition/Use）、接口定义（Interface Definition）和导入/导出（Import/Export）等操作。
     2. 一般来讲，MIL与实际的实现语言无关，只关注构件的对外表现协议以及构件之间的通讯关系

   • 缺点：

     • 这些语言处理和描述的软件设计开发层次过于依赖程序设计语言，限制了它们处理和描述比程序设计语言元素更为抽象的高层次软件构架元素的能力。

3. 基于软构件的描述语言CDL（Component Descrition Language）

   • 优点：

     1. 可以描述描述组件的安全特性及其特性；
     2. 能够使用时间运算符（如 next 和 Lead-to）描述进度属性。

   • 缺点：

     • 应用范围有局限性，不适合一般的体系结构描述。

4. 体系结构描述语言ADL(Architecture Description Language)

   • 优点：

     1. 语义精确；
     2. 有良好的整体性；
     3. 有良好的抽象性

   • 缺点：

     • 没有普遍一致的意见：ADL应表现什么，特别是架构的行为
       • 目前使用的表现，分析困难且无商业工具支持
       • 大多数ADL倾向于垂直优化特定的分析架构的共同概念

3.3 4 + 1视图，4和1分别是什么，系统内的用户都关心哪些视图。

• 逻辑视图（Logical View）：
  • 也被称为设计视图（Design View），涵盖了类、接口和协作，构成了问题和问题解决方案的术语体系。这个视图主要关注系统的功能需求，即系统向最终用户提供的服务。
• 开发视图（Development View）：
  • 也被称为实现视图（Implementation View），包含了用于组装和发布物理系统的构件和文件。这个视图主要关注系统发布的配置管理，由一些独立的构件和文件组成；这些构件和文件可以通过多种方式组合，生成运行系统。
• 过程视图（Process View）：
  • 也被称为进程视图，包含了形成系统并发和同步机制的线程和进程。该视图主要关注性能、可伸缩性和系统的吞吐量。
• 物理视图（Physical View）：
  • 也被称为部署视图（Deployment View），包含了形成系统硬件拓扑结构的节点（系统在这些节点上运行）。该视图主要描述了组成物理系统部件的分布、交付和安装情况。
• 场景视图（Scenarios）：
  • 也被称为用例视图，由专门描述系统行为的用例组成，这些行为可被最终用户、分析人员和测试人员看到。用例视图实际上并未描述软件系统的组织，而是描述了形成系统体系结构的动力。
• 系统内的用户都关心哪些视图：
  • 用户关心的是系统的功能，因此会侧重于逻辑视图；
  • 程序员关心的是系统的配置、装配等问题，因此会侧重于实现(开发)视图；
  • 系统集成人员关心的是系统的性能、可伸缩性、吞吐率等问题，因此会侧重于进程(处理)视图；
  • 系统工程师关心的是系统的发布、安装、拓扑结构等问题，因此会侧重于部署(物理)视图。
  • 分析人员和测试人员关心的是系统的行为，因此会侧重于用例(场景)视图；

3.4 主要的形式化ADL语言有那些，适用于哪些应用场景。

编号	典型的ADL	应用场景
1	Aesop	特定领域的软件系统
2	C2 SADL	用户界面密集系统
3	MetaH	实时、容错、安全等系统
4	UniCon	大量组件和连接件的管理
5	Rapide	基于事件的、复杂、并发、分布式系统
6	Wright	复杂交互
7	Darwin	基于消息传递的分布式系统
8	XYZ/ADL	架构逐层细化、分析、验证和自动代码的生成
9	ACME	架构在不同ADL之间变换、共享
10	XADL 2.0	实时系统、产品线架构
11	XBA	不同ADL的模型共享与协作开发
12	ABC/ADL	架构建模元素定义

4.软件体系结构评估

4.1 质量属性

​ 在软件工程中，质量属性通常被认为是那些可以说明软件整体性质的特征。

1. 可修改性:

   • 度量软件系统变化的成本，它是由变化范围、变化需要的工作量以及变化带来的商业成本进行度量的。变化包括功能扩展，容量扩展（比如增加并发访问数），特性删减，数据结构更新（比如对数据库的模式增加一个字段），通信协议调整，平台移植等。很多研究关注后部署阶段的修改，通常有代码级，生成级（比方说使用另外的生成选项）和配置级。可修改性有时也被叫做柔性或者可维护性。另外有时可移植性会被看作一个独立的质量属性。

2. 可用性:

   • 指软件在发生错误、异常或者失败时候是如何反应的。
   • 一般来讲，软件的可用性可以用正常工作的概率来度量。大体上公式如下：
     

3. 性能：

   • 表征软件系统的响应速度或者由响应速度决定的其他度量。在军事、控制系统和商务信息系统中这个属性至关重要。

4. 可测试性：

   • 表明软件系统在多大程度上容易被测试检查出缺陷。好的体系结构应该考虑到测试的需要。由于对已经开发完的系统进行测试代价很高昂，如果能在体系结构级别考虑到测试（从而使测试容易进行）就会有相当的回报。

5. 易用性

6. 安全性

7. 兼容性

8. 可移植性

9. 清晰性

10. 健壮性

4.2 评估方法的分类、哪些是更加客观的？

• 评估方法分类：

  1. 基于场景的评估方法：
     • 这种评估方法关注系统在特定使用场景下的性能和行为。它包括模拟用户在实际使用过程中的操作，以及系统在不同条件下的响应和表现。场景可能涵盖各种使用情境，例如正常操作、异常操作和负载情况。通过基于场景的评估，可以更好地了解系统在实际使用中的表现。
     • 包括SAAM、SAEM、ATAM、ARID等。
  2. 基于度量和预测的评估方法：
     • 这种评估方法依赖于度量和模型来评估系统的性能和其他质量属性。度量是通过定量的方式收集系统的相关信息，例如代码行数、执行时间、内存占用等。预测是通过建立数学模型来估算系统未来的性能和行为。这种方法可以在系统实际运行之前提供对系统性能的估算和预测。
     • 包括：SAABNet、QFD
  3. 基于特定软件体系结构描述语言的评估方法：
     • 这种评估方法侧重于使用特定的软件体系结构描述语言（如ADL）来评估系统的结构和设计。这可能涉及对体系结构模型的形式化分析、验证和仿真。使用特定的描述语言可以提供对系统结构的精确和形式化的理解，有助于评估系统在设计阶段的质量属性。
     • 包括AADL、Wright

• 更加客观的评估方法：

  • 在这三种评估方法中，基于度量和预测的评估方法通常被认为是更加客观的，因为它们倾向于使用量化的数据和数学模型来评估系统性能和质量属性。度量提供了对系统的实际度量数据，而预测则基于模型和统计方法进行分析，使得评估更加客观和可量化。基于场景的评估方法可能更偏向主观因素，而基于描述语言的方法可能受到特定语言和工具的影响，其客观性可能相对较低。

4.3 名词解释：SAAM、ATAM、ARID

• SAAM：软件架构分析方法，它试图通过场景来测量软件的质量，而不是泛泛的不精确的质量属性描述。
• ATAM：体系结构权衡分析方法，是一种能够权衡多个相关甚至是不一致的质量需求或者目标的评估方法。
• ARID：积极的中间设计审核方法，用于软件体系结构设计过程之中，针对于未完成的体系结构。

4.4 几种评估方法的比较，有什么不同？

• 大多数体系结构评估方法设计为基于场景的。详细介绍了两个最著名的评估方法——SAAM和ATAM。SAAM本质上是一个寻找受场景影响的体系结构元素的方法，而ATAM建立在SAAM基础上，关注对风险、非风险、敏感点和权衡点的识别。
• SAAM和ATAM表现了大多数基于场景评估方法的共同特性。它们以场景和体系结构描述作为输入，评估判断是否当前体系结构（或候选体系结构）能满足期望质量属性。潜在的缺陷和风险被识别，这是修改工作启动的基础。最后，原始的评估得到的数据被收集起来以备后用，例如用作进一步开发时的提示信息，或者积攒起来作为复用时需要的历史数据。
• QAW是用于创建体系结构之前的系统评估方法；ARID用在体系结构设计过程中的设计过程评估；ATAM和SAAM则通常是在体系结构创建完成后进行的验证性评估；另外，如果注重体系结构的可维护性，可以采用ALPSM方法，它也是在体系结构创建过程中进行的。

5.软件体系结构集成环境

5.1 集成开发环境的的作用；

1. 辅助体系结构建模

   • 建立体系结构模型是体系结构集成开发环境最重要的功能之一。
   • 集成开发环境的出现增加了软件体系结构描述方法的多样性，摒弃了描述能力低的非形式化方法，摆脱了拥有繁杂语法，语义规则的形式化方法。开发者只需经过简单的操作就可以完成以前需耗费大量时间和精力的工作。
   • 集成开发环境提供了一套支持自动建模的机制完成体系结构模型分析、设计、建立、验证等过程。用户根据不同的实际需求，应用环境和体系结构等因素选择不同的开发工具。

2. 支持层次结构的描述

   • 随着软件系统规模越来越大、越来越复杂，简单体系结构风格无法表达结构复杂的系统。这时就需要层次结构的支持，因此开发工具也需要提供层次机制。

3. 提供自动验证机制

   • 几乎所有的体系结构集成开发环境都提供了体系结构验证的功能。体系结构描述语言解析器和编译器是集成开发环境中必不可少的模块。除此以外，不同的集成开发环境根据不同的要求会支持特定的检验机制
   • 集成开发环境的测试方式可分为主动型和被动型两种。
   • (Medvidovic, 2000)主动型是指在错误出现之前采取预防措施，是保证系统不出现错误状态的动态策略。它根据系统当前的状态选择恰当的设计决策保证系统正常运行。被动型是指允许错误暂时存在，但最终要保证系统的正确性。

4. 提供图形和文本操作环境

   • 体系结构集成开发环境是开发者研究体系结构的可视化工具和展示平台，它具有友好的图形用户界面和便捷的操作环境。

5. 支持多视图

   • 多视图体现了关注点分离的思想，把体系结构描述语言和多视图结合起来描述系统的体系结构，能使系统更易于理解，方便系统相关人员之间相互交流，还有利于系统的一致性检测以及系统质量属性的评估。例如Darwin的分层系统视图，ArchStudio的文件管理视图等。

5.2 体系结构IDE原型的组成部分：

1.用户界面层

• 用户界面层是用户和系统交互的唯一渠道，用户需要的操作都被集成到这一层。这些操作可以通过编辑器和视图来实现。

2.模型层

• 模型层是系统的核心层，系统的大部分功能都在这一层定义和实现，它主要的任务是辅助体系结构集成开发环境建立体系结构模型。

3 基础层

• 这一层是系统的基本保障，涵盖了系统运行所需的软硬件支撑环境，它还对系统运行时所用的资源进行管理和调度。通常，普通的简单配置就可以满足系统运行需求，但是有的体系结构集成开发环境需要更多的支持环境。

5.3 主流的体系结构IDE有哪些？

• ArchStudio5
• SysADL Studio
• ACMEStudio

6.软件体系结构技术债、坏味道

6.1 名词解释

• 技术债：技术债是指开发人员为了加速软件开发，或是由于自身经验的缺乏，有意或无意地在应该采用最佳方案时进行了妥协，使用了短期内能加速软件开发的方案，从而在未来给自己带来的额外开发负担。
• 技术破产：随着软件发生持续变化，总的技术债一直增加，当累积的技术债达到无法偿还的地步，使得不得不放弃该软件产品。
• 代码坏味道：如果程序中的某一段代码是不稳定或者有一些潜在问题的，那么该段代码往往会包含一些明显的不太好的痕迹。
• 设计坏味道：软件设计过程中，由于各种原因（人员素质、技术方法、技术债等原因）也会引起坏味道，我们称之为设计坏味道

6.2 技术债都有哪些？

• 代码债：开发时没有守代码规范导致的债务，来源包括静态分析工具的违规行为和不一致的编码风格。

• 设计债：在设计时未采用最优解决方案导致的债务，来源包括设计臭味和违背设计规则的行为。架构技术债也是设计债的一种。

• 测试债：测试环节产生的债务，一般由测试的缺乏、测试覆盖面不充分以及不恰当的测试设计导致

• 文档债：由技术文档问题产生的债务，包括缺少重要技术文档、较差的文档和未及时修改更新的文档。

6.3 产生技术债的根本原因：

• 进度压力：当软件开发者接近项目截止日期时，就会努力尽快完成工作，容易仓促行事；
• 软件设计师缺乏足够的经验和技巧：如果软件设计师缺乏对软件设计基础和原则的理解，项目就很容易出现各种问题；
• 不注重设计原则的应用：开发者如果缺乏根据通用原则设计和编写代码的意识或经验，很容易代码难以扩展或修改，尤其是在团队开发或需要不断更新的项目中；
• 缺乏对设计坏味和重构的意识：很多开发者并不注意设计坏味，而这随着时间的蔓延扩大会导致较差的软件结构质量，产生技术债。
• 开发中有意采用非最优的选择：在某些项目中，有时会有意地做出一些会产生技术债的决定，从而达到某些更重要的目的，同时充分认识到技术债的存在。

6.4 代码债都有哪些表现？怎样去发现它？

• 技术债通常会以写的不好的代码为形式出现，包括：

  • 不必要的代码重复和复杂性
  • 较低的代码可读性的较差的代码风格
  • 使得软件解决方案在未来某个时间点更新时易于中断的组织不当的逻辑

• 发现代码债：

  • 对于代码类型的技术债，在软件开发、管理和运行中往往会出现一些信号，通过这些信号可以及时找出技术债。这些信号包括：
    1. 系统加载时间变长
    2. 特定模块缺陷率不断增加
    3. 同一问题在不同的模块或者组件中出现
    4. 增加新的功能时，新的bug数量持续增加
    5. 修复bug的时间变长
    6. 某个模块或者组件难以被团队理解或测试
    7. 某个模块或组件的源代码被频繁修改。

6.5 面向对象程序中可能出现的代码坏味道有哪些？

• 类级的坏味道：

  1. 过大的类：如果想利用单个类做太多事，类中就会出现太多实例变量。

     • 可以使用extract class 将几个变量一起提炼至新类内。
     • 如果large class是个GUI类，可能需要把数据和行为移到一个独立的领域对象去。

  2. 依恋情结的类： 即一个类的方法过多地使用了另一个的方法。

     • 某个类的函数对另一个类的兴趣高过对自己所处的类，通常的焦点就是数据，某个函数为了计算某个值，从另一个对象那儿
     • 调用几乎半打的取值函数。这时应该运用 Move Method 把它移到自己该去的地方。

  3. 过度亲密类：一个类存在与另一个类的实现细节依赖。

     • 例如：两个类过于亲密，花费太多时间去探究彼此的private成分。
     • 可以采用move method和move field划清界限。
     • 可以通过把双向关联变成单项关联。

  4. 拒绝的馈赠：子类仅仅使用父类中的部分方法和属性，其他来自父类的馈赠成为了累赘。

     • 问题的原因是有些人仅仅是想重用超类中的部分代码而创建了子类。但实际上超类和子类完全不同。
     • 解决方法：如果继承没有意义并且子类和父类之间确实没有共同点，可以消除继承。

6.6 应用级坏味道和方法级坏味道有哪些表现？

• 应用级的坏味道：

  • 重复代码（Duplicated code）：是指在一个以上的地方出现了重复的代码片段。重复的代码结构使程序变得冗长，需要重构。
    例如：一个父类有两个子类，这两个子类中存在相同的表达式。解决方案 : 对两个子类使用 提炼方法， 然后使用 上移方法（Pull Up Method）将提炼出来的代码定义到父类中去。
  • 人为复杂性（Contrived complexity）：在进行简单设计就充分的情况下，强制使用了过于复杂的设计模式。
  • 散弹式修改（Shotgun surgery）：如果每遇到某种变化，你都必须在许多不同的类中做出许多小修改。

• 方法级的坏味道：

  • 过长方法（Long method）：一个方法（或者函数、过程）含有太多行代码。
  • 参数太多（Too many parameters）
  • 超长标识符（Excessively long identifiers）
  • 超短标识符（Excessively short identifiers）
  • 数据过量返回（Excessive return of data）
  • 超长代码行（Excessively long line of code）

6.7 典型的设计坏味道有哪些？（4个）

• 连接件嫉妒（Connector Envy）；
• 过度分散的功能（Scattered Functionality）；
• 模糊接口（Ambiguous Interface）；
• 无关的相邻连接件（Extraneous Adjacent Connector）；

7.软件体系结构脆弱性

7.1 软件脆弱性

• 通常情况下，我们认为软件脆弱性是导致破坏系统安全策略的系统安全规范、系统设计、实现和内部控制等方面的弱点。
• 在软件开发过程中，软件脆弱性包含软件基础模型的脆弱性、软件架构设计的脆弱性、软件模块设计的脆弱性、软件接口设计的脆弱性、软件界面设计的脆弱性、数据库设计的脆弱性、架构模式和设计模式的脆弱性以及实现的脆弱性等等。

7.2 软件脆弱性特点

• 脆弱性是软件系统中隐藏的一个弱点，本身不会引起危害，但被利用后会产生严重的安全后果；
• 在软件开发过程中，自觉或不自觉引入的逻辑错误是大多数脆弱性的根本来源；
• 与具体的系统环境密切相关，系统环境的任何差异都有可能导致不同的脆弱性问题；
• 旧的脆弱性得到修补或纠正的同时可能会引入新的脆弱性
• 因此，脆弱性问题会长期存在。

7.3 软件架构脆弱性

• 软件架构脆弱性属于软件设计脆弱性或软件结构脆弱性的一种。软件架构脆弱性是更高层次的软件结构脆弱性，也是更加重要的软件脆弱性问题
• 软件（系统）架构设计存在一些明显的或者隐含的缺陷，攻击者可以利用这些缺陷攻击系统，或者当受到某个或某些外部刺激时，系统发生性能下降、稳定性下降、可靠性下降、安全性下降等等。如果软件架构具备这类缺陷，我们认为该软件架构是脆弱的，也就是软件架构脆弱性

7.4 特定风格的脆弱性

1. 分层架构脆弱性分析
   • 一旦某个底层发生错误，那么整个程序将会无法正常运行，产生一些数据溢出、空指针、空对象的安全性问题，也有可能会得出错误的结果。
   • 将系统隔离为多个相对独立的层，要求在层与层之间引入通信机制。在使用面向对象方法设计的系统中，通常会存在大量细粒度的对象，以及它们之间的大量的消息交互——对象成员方法的调用。本来直来直去的操作，现在要层层传递，势必造成性能的下降。
2. C/S架构脆弱性分析
   • 客户端需要安装专用的客户端软件，系统软件升级时，每一台客户机需要重新安装，其维护和升级成本非常高。
   • 高昂的维护成本且投资大。
   • 传统的C/S结构的软件需要针对不同的操作系统系统开发不同版本的软件，由于产品的更新换代十分快，代价高和低效率已经不适应工作需要。
3. B/S结构脆弱性分析
   • 相对客户端来说，页面通用化，不突出个性。而且页面需要不断地动态刷新，尤其是当用户增多，网速慢等情况，服务器的压力将会增大，加载时间会变长。由于不需要安装客户端，客户端易扩展，B/S将面对大量的不可知用户。
   • 相对服务器来说，当用户增多时，服务器响应速度慢。功能虽然多样化，但是不能专门化，不能实现复杂的功能。服务器承担着重要的责任，数据负荷较重。一旦发生服务器“崩溃”等问题，后果不堪设想。
4. 事件驱动架构脆弱性分析
   • 组件削弱了自身对系统的控制能力。一个组件触及事件时，并不能确定响应该事件的其他组件及各组件的执行顺序。
   • 不能很好地解决数据交换问题。
   • 使系统中各组件的逻辑关系变得更加复杂。
   • 事件驱动容易进入死循环，这是编程逻辑决定的。
   • 虽然有机会实现有效利用cpu，但也存在高并发事件处理的可能造成系统响应问题, 且易导致系统数据不正确、丢失数据现象。
   • 因为可响应的流程基本都是固定的，如果操作不当，容易引发安全问题。
5. MVC模式脆弱性分析
   • 由于没有明确的定义，完全理解MVC并不是很容易。
   • MVC由于将应用分为三层，意味着代码文件增多。
   • 不适合小型，中等规模的应用程序。
   • 增加系统结构和实现的复杂性。
   • 视图对模型数据的低效率访问。
   • 一般高级的界面工具或构造器不支持模式。改造这些工具以适应MVC需要和建立分离的部件的代价很高
6. 管道/过滤器架构脆弱性分析
   • 每个过滤器的输入输出是独立的，一个过滤器的输出做为另外一个过滤器的输入，耦合度低；
   • 若攻击者知道了某个过滤器的输入输出，有可能得出过滤器的功能，从而对系统的安全性造成威胁。
   • 由于一个过滤器的输出作为另外一个过滤器的输入，若一个过滤器发生错误，使得整个错误在系统中放大，从而威胁系统的稳定性。
7. 黑板模式脆弱性分析

   • 不能确保期望结果 ：因为求解整个问题是通过多个知识源来进行的，而知识源的选择是通过控制机构中调度程序来选择的，如果知识源选择的不够恰当，可能会导致错误或者有误差的结果。

   • 

   • 复杂，效率低下：通过上图我们就能看出，一个问题的求解可能需要多个知识源，并且需要排队，并且需要不停的修改黑板的状态，效率比较低。

   • 不支持并行：首先控制机构中需要将知识源放入调度队列中排队，其次多个知识源共享黑板需要同步，因为它们是通过黑板进行通讯的，每个状态的改变可能会影响下一个状态的改变。