新增软件体系结构笔记

_navbar.md

@@ -9,4 +9,5 @@
     * [✍ 大数据](src/BigData/README)
     * [✍ DevOps](src/DevOps/README)
     * [✍ 解决方案](src/Solution/README)
+    * [✍ 科班学习](src/university/README)
     * [✍ 其它](src/Others/README)

_sidebar.md

@@ -9,4 +9,5 @@
     * [✍ 大数据](src/BigData/README)
     * [✍ DevOps](src/DevOps/README)
     * [✍ 解决方案](src/Solution/README)
+    * [✍ 科班学习](src/university/README)
     * [✍ 其它](src/Others/README)

src/university/1.md

@@ -0,0 +1,399 @@
+> 为什么要学习软件体系结构
+
+**随着软件系统规模越来越大、越来越复杂，整个系统的结构和规格说明显得越来越重要。对于软件项目的开发来说，具有清晰的软件体系结构是非常重要的。软件体系结构 在软件需求和设计之间架起了一座桥梁，着重解决软件系统的结构和需求向实现平坦地过渡的问题。**
+
+![image-20211123103437918](概述.assets\image-20211123103437918.png)
+
+> 软件工程教育的定位
+
+![image-20211123103645580](概述.assets\image-20211123103645580.png)
+
+## 软件危机
+
+> 软件危机的表现
+
+- 软件成本日益增长
+- 开发进度难以控制
+- 软件质量差
+- 软件维护困难
+
+> 软件危机的原因
+
+- 用户需求不明确
+- 缺乏正确的理论指导
+- 软件规模越来越大
+- 软件复杂度越来越高
+
+要提高软件开发效率，提高软件产品质量，必须**采用工程化的开发方法与工业化的生产技术。**
+
+- 在技术上，应该采用基于重用的软件开发技术
+
+- 在管理上，应该采用多维的工程管理模式。
+
+## 构件与软件重用
+
+### 构件
+
+> 构件的定义
+
+构件是一个物理的、可替换的系统组成部分，它包装了实现体且提供了对一组接口的实现方法。
+
+> 构件模型
+
+构件模型是关于开发可重用软件构件和实现构件之间相互通信的一组标准的概述。
+
+> 构件模型的三个主要流派
+
+- OMG（对象管理集团）
+- EJB（Sun公司的企业开发构件）
+- DCOM（微软的分布式构件对象模型）
+
+> 构件获取
+
+- 从现有构件中获得符合要求的构件，直接使用或作适应性修改，得到可重用的构件（Java 类库）
+- 通过遗留工程，将具有潜在重用价值的构件提取出来，得到可重用的构件
+- 从市场上购买现成的商业构件，即COTS（Commercial Off-The-Shell）构件
+- 开发出新的符合要求的构件
+
+> 构件管理
+
+- 构件描述
+- 构件分类与组织
+- 人员及权限管理
+
+> 关键词分类法
+
+将应用领域的概念按照从抽象到具体的顺序逐次分解为树状图
+
+![image-20211123110318892](概述.assets\image-20211123110318892.png)
+
+> 刻面分类法
+
+定义若干个用于刻画构件特征的“面（facet）”，刻面的集合称为刻面描述符。
+
+```
+例如：使用下列构件描述符的模式：
+         { function,  object type,  system type  }
+     刻面的典型值可能是：
+         function={ copy ,from} or { copy,replace,all }
+```
+
+> 超文本组织法
+
+是一种非线性的网状信息组织方法，以节点为单位，链作为节点之间的联想式关联。
+
+![image-20211123110702665](概述.assets\image-20211123110702665-16376368250511.png)
+
+### 构件重用
+
+#### 检索与提取构件
+
+- 基于关键词的检索
+- 刻面检索法
+- 超文本检索法
+
+#### 理解与评价构件
+
+为了准确理解在库中需要使用的构件，要求构件的开发过程遵循公共软件工程规范，并在component文档中，准确说明以下内容：
+
+- 构件的功能和行为
+- 相关的领域知识
+- 可适应性约束条件与例外情形
+- 可以预见的修改部分及修改方法
+
+#### 修改构件
+
+构件理想的情形是对库中的构件不做修改而直接用于新的软件项目
+
+但是大多数情况下，必须构件进行或多或少的修改，以适应新的需求
+
+为了减少构件修改的工作量，要求**开发人员尽量使构件的功能、行为和接口设计更为抽象化、通用化和参数化**
+
+#### 构件组装
+
+将库中的构件经适当修改后相互连接，或者将它们与当前开发项目的软件元素连接，最终构成新的目标构件。
+
+> 基于功能的组装技术
+
+要求库中的构件以子程序/过程/函数的形式出现，并且接口说明必须清晰（如：C中的库函数），基于功能的组装技术采用了子程序调用和参数传递的方式将构件组装起来。
+
+**当使用这种组装技术进行软件开发时，开发人员首先应对目标软件系统进行功能分解，将系统分解为强内聚、松耦合的功能模块。然后根据各模块的功能需求提取构件，对它进行适应性修改后再挂接在上述功能分解框架中。**
+
+> 基于数据的组装技术
+
+这种组装技术也**要求库中构件以子程序形式出现**
+
+  首先根据当前软件问题的核心数据结构设计出一个框架（利用数据结构—>软件结构），然后根据框架中各结点的需求提取构件并进行适应性修改，再将构件逐个分配至框架中的适当位置。
+
+  此后，**构件的组装方式它所依赖的软件设计方法不再是功能分解，而是面向数据的设计方法**，例如Jackson系统开发方法。
+
+> 面向对象的组装技术
+
+**构造法**
+
+  在子类中引进基类的对象作为子类的成员变量，然后在子类中通过成员变量重用基类的属性和方法。 
+
+**子类法**
+
+  将新子类直接说明为库中基类的子类，通过继承和修改基类的属性与行为完成新子类的定义。
+
+## 体系结构的兴起和发展
+
+### 简介
+
+起源于建筑学的“体系结构”
+
+>计算机硬件系统的“体系结构”
+
+![image-20211123130321861](概述.assets\image-20211123130321861.png)
+
+**包含两个因素：**
+
+- 基本的硬件模块：控制器、运算器、内存储器、外存储器、输入设备、输出设备、…
+- 硬件模块之间的连接关系：总线
+
+**计算机体系结构的风格：**
+
+- 以存储程序原理为基础的冯·诺依曼结构
+- 存储系统的层次结构
+- 并行处理机结构
+- 流水线结构
+- 多核CPU
+- ……
+
+>“体系结构”的共性
+
+- 一组基本的构成要素——**构件**
+- 这些要素之间的连接关系——**连接件**
+- 这些要素连接之后形成的拓扑结构——**物理分布**
+- 作用于这些要素或连接关系上的限制条件——**约束**
+- 质量——**性能**
+
+> 软件体系结构
+
+软件体系结构(Software Architecture, SA)：
+
+- 构件：各种基本的软件构造模块(函数、对象、模式等)；
+- 连接件：将它们组合起来形成完整的软件系统；
+- 物理分布
+- 约束
+- 性能
+
+### SA的定义
+
+> SA的定义 (1) 1994年(D. Garlan and M. Shaw)
+
+**软件体系结构是设计过程的一个层次，它处理那些超越算法和数据结构的设计，研究整体结构设计和描述方法。**
+
+**SA={components, connectors, constrains}**
+
+- 构件(component)可以是一组代码，如程序的模块，也可以是一个独立的程序，如数据库的SQL 服务器。
+- 连接器(connector)表示构件之间的相互作用，它可以是过程调用、管道、远程过程调用等。
+- 一个软件体系结构还包括某些限制(constrain)。
+
+**该模型视角是程序设计语言，构件主要是代码模块。**
+
+
+
+>SA的定义 (2) 1994年(CFRP模型)
+
+**SA={elements, interfaces, connections, connection semantics}**
+
+- 软件系统由一组元素构成(elements)，这组元素分成处理元素和数据元素，每个元素有一个接口(interface)。
+- 一组元素的互连(connection)构成系统的拓扑。
+- 元素互连的语义是：静态互连语义(如数据元素的互连)、描述动态连接的信息转换的协议(如过程调用,管道等)。
+
+
+
+> SA的定义 (3) 1994年(S. Vestal)
+
+**SA={component, idioms/styles, common patterns of interaction}.**
+
+- 软件由构件(component)组成；
+- 构件之间通过通用的互操作模式相连；
+- 体系结构风格(style)描述了一种通用的设计模式，可满足特定系列的应用需求。
+
+
+
+> SA的定义 (4) 1998年(IEEE 610.12-1990)
+
+**Architecture={component, connector, environment, principle}.**
+
+- 体系结构是以构件、构件之间的关系、构件与环境之间的关系为内容的某一系统的基本组织结构，以及指导上述内容设计与演化的原理。
+
+
+
+> SA的定义 (5) 1992年(D. Perry and A. Wolf)
+
+**SA={elements, form, rational}**
+
+- 软件体系结构是由一组具有一定形式的元素(elements)构成：
+  - 这组元素分成3 类：处理元素(processing elements) 、数据元素(data elements)和连接元素(connecting elements)；
+  - 处理元素负责对数据进行加工，数据元素是被加工的信息，连接元素把体系结构的不同部分组合连接起来。
+
+- 软件体系结构形式(form) 是由专有特性(properties)和关系(relationship)组成。专有特性用于限制软件体系结构元素的选择，关系用于限制软件体系结构元素组合的拓扑结构。
+- 在多个体系结构方案中选择合适的体系结构方案往往基于一组准则(rational)。
+
+
+
+>SA的定义 (6) 1995年(Boehm模型)
+
+**SA={components,** **connections, constraints, stakeholders’ needs, rationale}**
+
+- 系统构件、连接件、约束的集合；
+- 反映不同人员需求的集合；
+- 能够展示由构件、连接件和约束所定义的系统在实现时如何满足系统不同人员需求的原理的集合
+
+
+
+> 归纳：SA的定义
+
+**软件体系结构(SA)：**
+
+- 提供了一个结构、行为和属性的高级抽象
+
+- 从一个较高的层次来考虑组成系统的构件、构件之间的连接，以及由构件与构件交互形成的拓扑结构
+
+- 这些要素应该满足一定的限制，遵循一定的设计规则，能够在一定的环境下进行演化。
+
+- 反映系统开发中具有重要影响的设计决策，便于各种人员的交流，反映多种关注，据此开发的系统能完成系统既定的功能和性能需求。
+
+**体系结构** **=** **构件** **+** **连接件** **+** **拓扑结构** **+** **约束** **+** **质量**
+
+Architecture = Components + Connectors + Topology + Constraints + Performance
+
+
+
+## 总结
+
+> 体系结构是风险承担者进行交流的手段
+
+- **软件体系结构代表了系统的公共的高层次的抽象。这样，系统的大部分有关人员（用户 、客户、开发者、管理者等）能把它作为建立一个互相理解的基础，形成统一认识，互相交流。** 
+
+- **体系结构提供了一种共同语言来表达各种关注和协商，进而对大型复杂系统能进行理智的管理。这对项目最终的质量和使用有极大的影响。**
+
+> 体系结构是早期设计决策的体现
+
+- 软件体系结构明确了对系统实现的约束条件
+- 软件体系结构决定了开发和维护组织的组织结构
+- 软件体系结构制约着系统的质量属性
+- 通过研究软件体系结构可能预测软件的质量
+- 软件体系结构使控制更改更简单，局部的修改不会破坏整体的完整与一致性。
+- 软件体系结构有助于循序渐进的原型设计
+- 软件体系结构可以作为培训的基础
+
+> 可传递的、可复用的模型：
+
+对一些经过实践证明的体系结构进行复用，从而提高设计的效率和可靠性，降低设计的复杂度。
+
+## 讨论题
+
+> 请分析软件危机的主要表现和原因
+
+表现︰
+
+- 软件成本日益增加∶开发、部署与应用成本高
+- 开发进度难以拄制:不能按期完成
+- 软件质量差:错误率高，不能满足用户的需求，没有生命力
+- 软件维护困难:成本高，维护效果不理想，可能带来潜在的错误
+
+原因∶
+
+- 用户需求不明确
+- 缺乏正确的理论指导
+- 软件规模越来越大
+- 软件复杂度越来越高
+
+> 什么是软件构件？
+
+构件是面向软件体系架构的可复用软件模块。
+
+构件（component）是可复用的软件组成成份，可被用来构造其他软件。
+
+构件是一个物理的、可替换的系统组成部分，它包装了实现体且提供了对一组接口的实现方法。
+
+> 请简述软件重用的含义和意义。可重用元素包括哪些种类？
+
+- (1)含义:软件重用是指在多次不同的软件开发过程中重复使用相同或相近软件元素的过程。
+
+- (2)意义:软件重用是软件产业工业化、工程化的重要手段。软件重用对提高生产率，降低开发成本，缩短开发周期，改善软件质量以及提高灵活性和标准化程度大有帮助。
+
+- (3)种类:可重用的元素包括程序代码、测试用例、设计文档、需求分析文档甚至领域知识。可重用的元素越大，我们就说重用的粒度越大。
+
+> 如何重用软件构件？
+
+- 从现有构件中获得符合要求的构件，直接使用或作适应性修改，得到可重用的构件；（Microsoft MFC、Sun Java类库）
+- 通过遗留工程，将具有潜在重用价值的构件提取出来，得到可重用的构件；
+- 从市场上购买现成的商业构件，即COTS（Commercial Off-The-Shell）构件；
+- 开发新的符合要求的构件。 
+
+> 软件重用有什么好处？
+
+使用软件重用技术**可以减少软件开发活动中大量的重复性工作，这样就能提高软件生产率，降低开发成本，缩短开发周期。 同时，由于软构件大都经过严格的质量认证，并在实际运行环境中得到校验，因此，重用软构件有助于改善 软件质量 。 此外，大量使用软构件，软件的灵活性和标准化程度也可望得到提高。** 
+
+> 软件重用有哪些类型？
+
+对软件复用的划分，大致将它分成四种类型：
+
+- **代码级复用**：就是通过编写大量的公共类，公共函数等等，供开发人员直接使用。
+- **组件级复用**：通过将功能的组件化封装，对外提供一组或多组的API接口。
+- **模块级复用**：在我们开发的项目或者产品中，会发现大量重复的功能模块，比如用户管理，机构管理等等，如果我们在这些模块设计的时候，注重一下扩展性，那么可以应用到有其它类似功能的项目中。在这个级别需要一定的项目的积累，否则在模块功能上以及实用性上会遭遇风险。
+- **构架级复用**：构架级在设计概念上最为高级的一种。它相当于一个平台或者思想，在这个平台上，可以开发出根据此平台思想稳定而又高效的软件产品。
+
+> 基于构件的软件开发有何优势？
+
+- 可重用 
+- 易于维护，构件的封装性好，不用知道具体实现内容，只知道构件的接口就可以使用
+
+> 什么是软件体系结构，由哪三个部分组成?
+
+软件体系结构为软件系统提供了一个结构、属性和行为的高级抽象。它不仅指定了系统的组织结构和拓扑结构，并且显示了系统需求和构成系统的元素之间的对应关系，提供了一些设计决策的基本原理。
+
+体系结构由**构件、连接件、约束组成**
+
+> 软件体系结构有何意义？
+
+- 体系结构是风险承担者进行交流的手段 
+  - 软件体系结构代表了系统的公共的高层次的抽象。这样，系统的大部分有关人员（用户 、客户、开发者、管理者等）能把它作为建立一个互相理解的基础，形成统一认识，互相交流。 
+  - 体系结构提供了一种共同语言来表达各种关注和协商，进而对大型复杂系统能进行理智的管理。这对项目最终的质量和使用有极大的影响。
+- 体系结构是早期设计决策的体现 
+  - 软件体系结构明确了对系统实现的约束条件
+  - 软件体系结构决定了开发和维护组织的组织结构
+  - 软件体系结构制约着系统的质量属性
+  - 通过研究软件体系结构可能预测软件的质量
+  - 软件体系结构使控制更改更简单，局部的修改不会破坏整体的完整与一致性
+  - 软件体系结构有助于循序渐进的原型设计
+  - 软件体系结构可以作为培训的基础
+
+>纵观软件体系结构技术的发展过程，从最初的“无结构"设计到现行的基于体系结构的软件开发，可以认为经历了哪四个阶段?
+
+- (1)“无体系结构”设计阶段。以汇编语言进行小规模应用程序开发为特征
+- (2)萌芽阶段。出现了程序结构设计主题，以控制流图和数据流图构成软件结构为特
+  征
+- (3）初期阶段。出现了从不同侧面描述系统的结构模型，以UML为典型代表
+- (4）高级阶段。以描述系统的高层抽象结构为中心，不关心集体的建模细节，划分了体系结构模型与软件结构的界限，该阶段以Kruchten，提出了“4+1”模型为标志，由于概念尚不统一，描述规范也不能达成一致认识，因此在软件开发实践中软件体系结构上布恩那个发挥重要作用。
+
+>请说明软件规模与复杂度对软件过程的影响及解决方法。
+
+软件规模与复杂度增加后
+
+- 软件开发和维护成本增加
+- 开发进度难以控制，
+- 软件质量差
+- 软件维护变得困难。
+
+应更多地采用科学的分析、设计和实现方法以及辅助工具，增强软件分析和设计的力度，并通过构件化提高软件的重用能力。
+
+> 请简述常用的构件实现模型及其意义
+
+实现模型：
+
+- (1)CORBA
+
+- (2)EJB
+
+- (3)COM / DCOM / COM+
+
+意义：
+
+这些模型通常都定义了构件的实现方式、接口定义、访问方法等。符合这些标准的任何构件都有很高的重用能力。

src/university/2.md

@@ -0,0 +1,478 @@
+## 体系结构描述
+
+### 体系结构描述方式标准
+
+- 语义丰富性
+
+- 语义精确性
+
+- 形式化程度
+
+### 主要描述方式
+
+- 非标准的图形符号
+
+- UML
+
+- 模块接口语言MIL
+
+- ADL
+
+### 非标准化图形符号描述
+
+用由矩形框和有向线段组合而成的图形表达工具。其中，矩形框代表抽象构件，有向线段代表辅助各构件进行通讯、控制或关联的连接件。 
+
+> 特点：
+
+- 语义丰富
+
+- 语义极不精确
+
+- 没有形式化基础
+
+> 用途：
+
+- 商业展示
+
+- 设计草图
+
+> 优点：
+
+- 直观形象
+
+- 简单易用
+
+> 缺点：
+
+- 由于其术语和表达语义上存在着一些不规范和不精确，从而使得以矩形为基础的传统图形表达方法在不同系统和不同文档之间存在着许多不一致甚至矛盾。
+
+> 示例图：
+
+Enterprise Java Beans Architecture
+
+![image-20211124100804135](建模.assets\image-20211124100804135.png)
+
+Microsoft .Net Framework Architecture
+
+![image-20211124100922322](建模.assets\image-20211124100922322.png)DC-LMP – Link Management Protocol Software用于光纤网物理介质连接器的软件
+
+![image-20211124100946327](建模.assets\image-20211124100946327.png)
+
+### UML
+
+本质上UML是侧重于面向对象（OO, Object Oriented)软件系统设计的语言
+
+> 特点：
+
+- 语义极其丰富
+
+- 语义相对精确
+
+- 有少量的形式化基础
+
+> 用途：
+
+- 需求分析
+
+- OO类设计
+
+- 行为设计和分析
+
+- 代码自动生成
+
+### 模块接口语言MIL
+
+是将一种或多种传统程序设计语言模块连接起来描述软件的体系结构的方法。
+
+> 特点：
+
+- 语义比较丰富，但局限在实现级别，层次较低
+
+- 语义精确，有编译器作保证
+
+- 没有或极少有形式化基础
+
+> 实例：
+
+- Microsoft COM IDL 
+
+- OMG CORBA IDL
+
+> 优点：
+
+- 具有严格的语义基础，能够支持对较大的软件单元进行诸如：定义/使用（Definition/Use）、接口定义（Interface Definition）和导入/导出（Import/Export）等操作。
+
+- 一般来讲，MIL与实际的实现语言无关，只关注构件的对外表现协议以及构件之间的通讯关系
+
+> 缺点：
+
+- 这些语言处理和描述的软件设计开发层次过于依赖程序设计语言，限制了它们处理和描述比程序设计语言元素更为抽象的高层次软件构架元素的能力。
+
+### ADL
+
+> 基本元素
+
+- 组件—— 计算或数据存储单元；
+
+- 连接件—— 用于模型化构件间的交互，以及指导这些交互的规则
+
+- 配置—— 描述体系结构的构件与连接件的连接图。
+
+> 典型的ADL
+
+- 目前，广泛使用的体系结构描述语言有：ACME、Unicon、Wright、Darwin、Aesop、SADL、MetaH、Rapide和C2。
+
+- 由于这些语言大都是研究者在某些特殊应用中的设计产物，因此，它们都有各自的侧重点。
+
+> 不同的ADL对软件的理解不同
+
+- WRIGHT将软件理解为构件、连接器、端口、角色，以及这些元素之间的联系和约束。CSP的描述使其有利分析复杂行为。
+
+- C2将软件理解为构件、端口和连接器。不过构件有且只有Top和Bottom两个端口。同时构件和构件之间仅通过Request和Notification两种信息进行通讯。适合描述交互式系统。
+
+- ACME将软件理解为具有属性的构件和连接器。具有大多数ADL的共性元素。善于在不同ADL之间进行转换。
+
+## SA的核心概念
+
+### SA的定义
+
+> 软件体系结构(SA)：
+
+- 提供了一个结构、行为和属性的高级抽象
+
+- 从一个较高的层次来考虑组成系统的构件、构件之间的连接，以及由构件与构件交互形成的拓扑结构
+
+- 这些要素应该满足一定的限制，遵循一定的设计规则，能够在一定的环境下进行演化。
+
+- 反映系统开发中具有重要影响的设计决策，便于各种人员的交流，反映多种关注，据此开发的系统能完成系统既定的功能和性能需求。
+
+**体系结构** **=** **构件** **+** **连接件** **+** **拓扑结构** **+** **约束** **+** **质量**
+
+Architecture = Components + Connectors + Topology + Constraints + Performance
+
+> 图例
+
+![image-20211124102114540](建模.assets\image-20211124102114540.png)
+
+### 构件
+
+- 构件是**具有某种功能的可复用的软件结构单元，是为组装服务的，**表示了系统中主要的计算元素和数据存储。
+
+- 逻辑上，任何在系统运行中承担一定功能、发挥一定作用的软件体都可看作是构件
+  - 程序函数、模块
+  - 对象、类
+  - 数据库
+  - 文件
+  - ….
+- 严格意义上讲，**构件是一种可部署单元，它具有规范的接口规约和显式的语境依赖。**更严格地讲，构件可以被独立部署，并由第三方组装。
+- 由构件组装出的软件称为构件化软件。
+
+> 构件的粒度
+
+- 构件的粒度:构件的相对大小、规模、细节程度或关注程度的一个属性
+- 原子构件(Atomic component)：不可再分解。
+  - 集成电路、芯片
+  - 数据结构、函数
+- 复合构件composite component)：由其他原子构件与复合构件通过连接而成。
+  - 存储器、运算器、控制器
+  - 对象、模块、子系统
+
+> 粒度对构件的影响
+
+- 恰当的粒度是很重要的
+
+- 小粒度构件：灵活性高，复用度高，但交互复杂，使用效率低下
+
+- 大粒度构件正好相反
+
+### 接口(Interface)与服务(Service)
+
+- 构件作为一个封装的实体，只能通过其**接口(Interface)**与外部环境交互，表示了构件和外部环境的**交互点**；
+- **内部结构则被隐藏起来**(Black-box)；
+- 一个构件至少有一个接口
+- 一个构件可以提供**多重接口**
+- **构件接口与其内部实现应严格分开**
+- 构件内部所实现的功能以**服务(Service)**的形式体现出来，并通过接口向外发布，进而产生与其它构件之间的关联
+
+### 连接(Connection)
+
+- 连接(Connection)：构件间建立和维护行为关联与信息传递的途径；
+
+- 连接需要两方面的支持：
+  - 连接发生和维持的机制——实现连接的物质基础(**连接的机制**)；
+  - 连接能够正确、无二义、无冲突进行的保证——连接正确有效的进行信息交换的规则(**连接的协议**)。
+  - 简称**“机制”(mechanism)和“协议”(protocol)**。
+- 计算机硬件提供了一切连接的物理基础：
+  - 过程调用、中断、存储、堆栈、串行I/O、并行I/O等；
+- 基础控制描述层：
+  - 过程调用、动态约束、中断/事件、流、文件、网络等；
+- 资源及管理调度层：
+  - 进程、线程、共享、同步、并行、分时并发、事件、消息、异常、远程调用、注册表、剪贴板、动态连接、API等；
+- 系统结构模式层：
+  - 管道、解释器、编译器、转换器、浏览器、中间件、ODBC等。
+
+> 连接的协议
+
+- **协议(Protocol)是连接的规约(Specification)；**
+
+- 连接的规约是建立在物理层之上的有意义信息形式的表达规定
+  - 对过程调用来说：参数的个数和类型、参数排列次序；
+  - 对消息传送来说：消息的格式；
+  - 对ODBC数据库连接来说：SQL语言；
+  - 对Web Service连接而言：SOAP或REST协议；
+- 目的：使双方能够互相理解对方所发来的信息的语义。
+
+> 连接的种类
+
+- 从连接目的看：
+  - 操作/过程调用；
+  - 控制/事件/消息发送；
+  - 数据传输；
+  - …其他目的？
+
+- 除了连接机制/协议的实现难易之外，影响连接实现复杂性的因素之一是“**有无连接的返回信息和返回的时间**”，分为：
+  - 同步 (Synchronous)
+  - 异步 (Asynchronous)
+
+> 连接的特性
+
+- 方向性
+- 角色：连接的双方所处的不同地位的表达
+- 激发性：定义为“引起连接行为的方式”，分为主动方和被动方的激发性：
+- 响应特性：包括连接的被动方对连接请求的处理实时性、时间、方式、并发处理能力等
+
+### 连接件(Connector)
+
+- 连接件(Connector)：表示构件之间的交互并实现构件之间的连接，如：
+  - 管道(pipe)
+  - 中间件(Middleware)
+    - 数据库连接
+    - 应用服务器
+    - WEB服务器
+    - 消息中间件
+    - ......
+- 连接件也可看作一类**特殊的构件**，区别在于：
+  - 一般构件是软件功能设计和实现的承载体；
+  - 连接件是负责完成构件之间信息交换和行为联系的专用构件。
+
+## 软件体系结构模型
+
+>建立模型的目的
+
+提供一个理想的论证框架，应用逻辑和数学工具，评估性能，并在多个类似的场景下进行推理。
+
+### 建立SA模型
+
+> 为什么要建立SA模型
+
+- 针对某一具体的软件系统研发项目，需要以某种**可视化/形式化**的形式将SA的设计结果加以显式的表达出来，进而支持：
+  - 用户、软件架构师、开发者等各方人员之间的交流；
+  - 分析、验证SA设计的优劣；
+  - 指导软件开发组进行系统研发；
+  - 为日后的软件维护提供基本文档。
+
+>SA建模的三个层次
+
+- **图形化模型：SA模型的多视图表示 (Multi-view graphical model)**
+  - 从不同的视角描述特定系统的体系结构，从而得到多个视图，并将这些视图组织起来以描述整体的SA模型；
+- **形式化模型：SA描述语言(Formal architecture description language, ADL)**
+  - 在SA基本概念的基础上，选取适当的形式化或半形式化的方法来描述一个特定的体系结构；
+- **文档化模型：SA文档化(Documentation)**
+  - 记录和整理软件体系结构设计方案的各类细节。
+
+> 使用“多视图模型”进行SA建模的原因
+
+- 考虑建筑体系结构的描述：
+  - 房间布局图、电路图、管道图、等等；
+- **软件体系结构非常复杂，无法用简单的一维模型加以描述**
+- 多视图SA模型：**从多个不同角度建立SA的模型，分别刻画SA某一方面的性质。**
+  - 系统的每一个不同的视图反映了一组系统相关人员所关注的系统的特定方面；
+  - 多视图体现了“关注点分离”(separation of concerns)的思想，使系统更易于理解，方便系统相关人员之间进行交流，并且有利于系统的一致性检测以及系统质量属性的评估。
+
+### (Kruchten)4+1视图模型
+
+- 一个架构视图是对于从某一视角或某一点上看到的系统所做的简化描述，描述中涵盖了系统的某一特定方面，而省略了与此方面无关的实体。
+- “4+1”视图模型从5个不同的视角**(逻辑视图、进程视图、物理视图、开发视图和用例视图)**来描述软件体系结构。
+- 每一个视图只关心系统的一个侧面，5个视图结合在一起才能反映系统的软件体系结构的全部内容。
+- 该模型已被广泛应用于UML(Unified Modeling Language)和RUP(Rational Unified Process)中。
+
+> 4+1视图模型结构
+
+![image-20211124105113697](建模.assets\image-20211124105113697.png)
+
+#### 用例视图(Use Case View)
+
+- **用例视图用来捕获最终用户所需求的功能性，即“系统应该做什么”；**
+- 用例视图使其他四个视图有机的联系起来。
+- 用例视图也称为场景(Scenario)。
+- **在UML中，用例视图主要包括用例图，然后使用若干个交互图来展示每个用例内部的细节**
+
+> UML图表示
+
+![image-20211124105521861](建模.assets\image-20211124105521861.png)
+
+![image-20211124144105800](建模.assets/image-20211124144105800.png)
+
+#### 逻辑视图(Logical View)
+
+- **逻辑视图主要支持系统的功能性需求，即系统提供给最终用户的服务。**
+  - 形成了问题及对问题解决方案的术语词汇
+  - 在逻辑视图中，系统分解成一系列的功能抽象(classes, interfaces, and patterns)，这些抽象主要来自用户需求所在的问题领域，同时也表达了软件领域的相应概念。
+  - 这种分解不但可以用来进行功能分析，而且可用作标识在整个系统的各个不同部分的通用机制和设计元素。
+- **逻辑视图通常并不描述软件系统是如何被实现或执行**
+- **在UML中，逻辑视图通常使用以下的图形表达形式**
+  - Class diagrams (类图)
+  - Activity diagrams (活动图)
+  - Sequence diagrams (顺序图)
+  - Composite structure diagrams (组合结构图)
+
+> UML图表示
+
+![image-20211124144128770](建模.assets/image-20211124144128770.png)
+
+#### 开发视图(Module View)
+
+- 开发视图也称模块视图(Module View)，**主要侧重于软件模块的组织和管理。**
+  - 系统-子系统-模块(构件、文件、资源等)，并组织成层次结构
+- 开发视图的另一个焦点在于：**描述各模块之间的依存关系。**
+  - 例如：一个构件的实现依赖于哪些其他构件、哪些源文件实现了哪些类，等等。
+- 开发视图要**考虑软件内部的实现需求**，如软件开发的容易性、软件的复用和软件的通用性，要充分考虑由于具体开发工具的不同而带来的局限性。
+- **在UML中，开发视图通常使用Component diagrams (构件图)**
+
+> UML图表示
+
+![image-20211124144235294](建模.assets/image-20211124144235294.png)
+
+
+
+![image-20211124144217788](建模.assets/image-20211124144217788.png)
+
+![image-20211124144250066](建模.assets/image-20211124144250066.png)
+
+#### 进程视图(Process View)
+
+- 进程视图侧重于系统的**运行特性**，主要关注一些**非功能性的需求。**
+  - 并发性、分布性、系统集成性和容错能力；
+  - 逻辑视图中的各个抽象概念如何在进程中被执行；
+  - 逻辑视图中的各个类的操作具体是在进程中的哪一个线程中被执行的。
+- **在UML中，进程视图通常使用以下UML图来描述一个系统的运行时行为**
+  - Activity diagrams (活动图) 
+  - Interaction diagrams (交互图)
+    - Sequence diagrams (次序图)
+    - Communication diagrams (通讯图)
+    - Interaction overview diagrams (交互预览图)
+    - Timing diagrams (时间图)
+
+> UML图表示
+
+![image-20211124144407434](建模.assets/image-20211124144407434.png)
+
+#### 物理视图(Physical View)
+
+物理视图主要考虑如何把软件部署到硬件上；
+
+- 它通常要考虑系统性能、规模、可靠性等；
+- 解决软件系统配置、安装、系统部署后的物理拓扑结构、系统执行过程中的通讯问题等。
+- 在UML中，物理视图通常包括
+  - Deployment diagrams (部署图)
+  - Package diagrams (包图)
+  - Interaction diagrams (交互图)
+
+> UML图表示
+
+![image-20211124144430510](建模.assets/image-20211124144430510.png)
+
+![image-20211124144437805](建模.assets/image-20211124144437805.png)
+
+#### 总结
+
+- **用例视图**：描述系统的典型场景与功能，主要图形包括use case diagram等。
+
+- **逻辑视图**：描述系统的抽象概念与功能(类、对象、接口、模式等)，主要图形包括class diagrams, sequence diagrams, and collaboration diagrams等；
+- **开发视图**：描述系统中的子系统、模块、文件、资源及其之间的关系，主要图形包括component diagrams等；
+- **进程视图**：描述系统的进程及其之间的通信协作关系，主要图形包括activity diagram,interaction diagram等；
+- **物理视图**：描述系统如何被安装、部署与配置在分布式的物理环境下，主要图形包括deployment diagram等。
+- **4+1视图模型是一种已经被标准化(UML, RUP)的方法，用来描述和文档化软件系统的体系结构。**
+- **每个视图从不同的角度刻画了系统的结构属性，将它们综合在一起就形成了系统的整体架构。**
+  - 逻辑视图和开发视图描述系统的静态结构，而进程视图和物理视图描述系统的动态结构。
+  - 对于不同类型的软件系统来说，侧重的角度也有所不同。
+    - 例如，对于管理信息系统来说，比较侧重于从逻辑视图和开发视图来描述系统，而对于实时控制系统来说，则比较注重于从进程视图和物理视图来描述系统。
+- 不是所有的软件体系结构都需要完整的“4十1”视图。没有用的视图在体系结构描述中可以被省略。例如对于非常小的系统，逻辑视图和开发视图有可能非常相似以至于没有必要把它们分开描述。场景视图在各种环境下都是有用的。
+
+## 软件体系结构的生命周期
+
+> 软件研发过程
+
+![image-20211124144455983](建模.assets/image-20211124144455983.png)
+
+> 软件体系结构的生命周期
+
+- 非形式化描述
+- 规范描述
+- 求精及验证
+- 实施
+- 演化和扩展（修改体系结构）
+- 评价和度量（重用体系结构）
+- 总结
+
+## 讨论题
+
+>软件体系结构的描述有哪几种方式？各有何特点？
+
+- （1）非标准图形符号描述：语义丰富、不精确、没有形式化基础；
+- （2）统一建模语言UML：语义丰富、相对精确、有少量的形式化基础；
+- （3）模块接口语言：语义比较丰富，但局限在实现级别，层次较低，语义精确，有编译器作保证，没有或极少有形式化基础；
+- （4）体系结构描述语言ADL：语义不够丰富，语义精确，有形式化基础。
+
+>建立软件体系结构模型的作用是什么？
+
+- （1）用户、软件架构师、开发者等各方人员之间的交流；
+- （2）分析、验证SA设计的优劣；
+- （3）指导软件开发组进行软件开发；
+- （4）为日后的软件维护提供基本文档。
+
+>请简述SA建模的三个层次。
+
+- （1）图形化模型： 
+  - 从不同的视角描述特定系统的体系结构，从而得到多个视图，并将这些视图组织起来以描述整体的SA模型；
+
+- （2）形式化模型：
+  - ​	在SA基本概念的基础上，选取适当的形式化或半形式化的方法来描述一个特定的体系结构；
+
+- （3）文档化模型：
+  - 记录和整理软件体系结构设计方案的各类细节。
+
+> 请简述使用“多视图模型”进行SA建模的原因。
+
+- 软件体系结构非常复杂，无法用简单的一维模型加以描述。
+- 从多个不同角度建立SA的模型，分别刻画SA某一方面的性质，系统的每一个不同的视图反映一组系统相关人员所关注的系统的特定方面；
+- 多视图体现了“关注点分离”的思想，使系统更易于理解，方便系统相关人员之间进行交流，并且有利于系统的一致性检测以及系统质量属性的评估。
+
+> 软件体系结构生命周期主要包括哪些阶段？
+
+- 非形式化描述
+
+- 规范描述
+
+- 求精及验证
+
+- 实施
+
+- 演化和扩展（修改体系结构）
+
+- 评价和度量（重用体系结构）
+
+- 终结
+
+>软件体系结构建模的“4+1视图模型”中包括哪些视图，各视图分别关注软件的哪些特征，常采用UML的何种图形描述？
+
+（1）**逻辑视图**：着重考虑功能需求，主要关注行为或指责的划分，并将不同的职责分配给逻辑层、功能模块或类等不同粒度的逻辑单元。可以用**包图、类图、对象图（静态部分）或序列图、协作图、状态图和活动图（动态内容）来描述**。
+
+（2）**开发视图**：主要考虑开发期质量属性，如可扩展性、可重用性、可移植性、易理解性、易测试性等等，其关注点是软件模块的实际组织方式。可以用**包图、类图、构件图表述**。 
+
+（3）**进程视图**：着重考虑运行期质量属性，如性能、可伸缩性、持续可用性等，主要关注进程、线程、对象等运行期概念，以及相应的并发、同步、通信等问题，可以**用包图、类图、对象图（静态部分）或序列图、协作图（动态部分）表述**。 
+
+（4）**物理视图**：主要考虑安装和部署需求，描述运行环境的计算机、网络、硬件设施等情况。同时，物理视图还必须关注如何配置硬件环境来配合软件的特殊质量属性。一般**用部署图和构件图描述**。 
+
+（5）**用例视图：是系统重要活动的抽象，描述系统的需求。一般用用例图、活动图、顺序图描述。**
+

src/university/3.md

@@ -0,0 +1,218 @@
+## 概述
+
+> 定义
+
+描述**特定领域中**软件系统家族的组织结构方式的惯用模式**，**反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。
+
+> 经典体系结构风格的分类
+
+![image-20211124121847033](风格.assets\image-20211124121847033.png)
+
+## 数据流体系结构风格
+
+> 基本特征
+
+处理：**数据到达即被激活，无数据时不工作**
+
+![image-20211124122008414](风格.assets\image-20211124122008414.png)
+
+- **数据的可用性决定着处理(计算单元)是否执行**
+- **系统结构：数据在各处理之间的有序移动**
+- **在纯数据流系统中，处理之间除了数据交换，没有任何其他的交互**
+
+> 数据流风格的基本构件(Component)
+
+- **基本构件：数据处理**
+  - 构件接口：输入端口和输出端口
+  - 从输入端口读取数据，向输出端口写入数据
+  - 计算模型：从输入端口读数，经过计算/处理，然后写到输出端口
+
+![image-20211124122303131](风格.assets\image-20211124122303131.png)
+
+> 数据流风格的连接件(Connector)
+
+- **连接件：数据流**
+  - 单向、通常是异步、有缓冲
+  - 接口角色：reader和writer
+  - 计算模型: 把数据从一个处理的输出端口传送到另一个处理的输入端口
+
+![image-20211124122452644](风格.assets\image-20211124122452644.png)
+
+> 数据流风格的拓扑结构(Topology)
+
+![image-20211124122526863](风格.assets\image-20211124122526863.png)
+
+> 三种典型的数据流风格
+
+- Batch Sequential (**批处理**)
+
+- Pipe-and-Filter (**管道-过滤器**)
+
+- Process Control(**过程控制**)
+
+### 顺序批处理风格
+
+![image-20211124122910850](风格.assets\image-20211124122910850.png)
+
+![image-20211124122931219](风格.assets\image-20211124122931219.png)
+
+> 基本定义
+
+- **每个处理步骤是一个独立的程序**
+
+- **每一步必须在前一步结束后才能开始**
+
+- **数据必须是完整的，以整体的方式传递**
+
+- 典型应用:
+  - 传统的数据处理
+  - 程序编译(**1.预处理(Preprocessing), 2.编译(Compilation), 3.汇编(Assemble), 4.链接(Linking)。**)
+
+> 基本构成
+
+- **基本构件：独立的应用程序**
+
+- **连接件：某种类型的媒质**
+
+- **连接件定义了相应的数据流图，表达拓扑结构**
+
+- **每一步骤必须在前一步骤完全结束之后方能开始**
+
+>批处理风格示例：重复代码检测工具
+
+![image-20211124123424235](风格.assets\image-20211124123424235.png)
+
+### 管道与过滤器风格
+
+![image-20211124123517514](风格.assets\image-20211124123517514.png)
+
+> 基本定义
+
+- 语境：**数据源源不断的产生，系统需要对这些数据进行若干处理(分析、计算、转换等)。**
+
+- 解决方案：
+  - 把系统分解为几个序贯的处理步骤，这些步骤之间通过数据流连接，一个步骤的输出是另一个步骤的输入；
+  - 每个处理步骤由一个过滤器构件(Filter)实现；
+  - 处理步骤之间的数据传输由管道(Pipe)负责。
+
+- 每个处理步骤(过滤器)都有一组输入和输出，过滤器从管道中读取输入的数据流，经过内部处理，然后产生输出数据流并写入管道中。
+
+> 基本构成
+
+- 构件：过滤器，处理数据流
+  - 一个过滤器封装了一个处理步骤
+  - 数据源点和数据终止点可以看作是特殊的过滤器
+
+- 连接件：管道，连接一个源和一个目的过滤器
+  - 转发数据流:将一个过滤器的输出传到另 一过滤器的输入
+
+- 连接器定义了数据流图，形成拓扑结构
+
+#### 过滤器
+
+- **目标：将源数据变换成目标数据** 
+
+- **5种变换**
+  - 通过计算和增加信息来丰富数据
+  - 通过浓缩和删减来精炼数据
+  - 通过改变数据表现方式来转化数据
+  - 将一个数据流分解为多个数据流
+  - 将多个数据流合并为一个数据流
+
+> 过滤器读取与处理数据流的方式
+
+- **递增的读取和消费数据流**
+  - 数据到来时便被处理，不是收集然后处理，即在输入被完全消费之前，输出便产生了。
+
+![image-20211124124429298](风格.assets\image-20211124124429298.png)
+
+>过滤器的状态
+
+- **停止状态：**表示过滤器处于待启动状态，当外部启动过滤器后，过滤器处于处理状态。
+
+- **处理状态**：表示过滤器正处理输入数据队列中的数据。
+
+- **等待状态**：表示过滤器的输入数据队列为空，此时过滤器等待，当有新的数据输入时，过滤器处于处理状态。
+
+####  管道
+
+- **作用：在过滤器之间传送数据)**
+
+  - 单向流
+
+  - 可能具有缓冲区
+
+  - 管道形成传输图
+
+- **不同的管道中流动的数据流，具有不同的数据格式(Data format)。**
+  - 原因：数据在流过每一个过滤器时，被过滤器进行了**丰富、精练、转换、融合、分解等操作**，因而发生了变化。
+
+### 批处理与管道-过滤器的比较
+
+> 相似点
+
+- 把任务分解成为一系列固定顺序的计算单元 
+- 彼此间只通过数据传递交互
+
+![image-20211124125017301](风格.assets\image-20211124125017301.png)
+
+> 不同点
+
+| 批处理           | 管道-过滤器  |
+| :--------------- | :----------- |
+| 整体传递数据     | 增量         |
+| 构件粒度较大     | 构件粒度较小 |
+| 延迟高，实时性差 | 实时性好     |
+| 无并发           | 可并发       |
+
+> 管道-过滤器风格的典型应用
+
+- **Complier (scan, parse, generate code, ..) (编译器)** 
+
+- **Unix pipes (Unix管道)**
+
+- **Image processing (图像处理)**
+
+- **Signal processing (信号处理)**
+- **Voice and video streaming (声音与图像处理)**
+
+> 例子—媒体播放器
+
+- 输入：AVI文件，包括音频和视频数据。
+
+- 分离器：把音频和视频数据分离成两个流，音频数据传递给音频解码器，视频数据传递给视频解码器。
+
+- 音频解码器：把压缩的音频数据解码成原始的音频数据。
+
+- 视频解码器：把压缩的视频数据解码成原始的图像数据。
+
+- 输出：音频数据传递给声卡，图像数据传递给显示器。
+
+![image-20211124125602466](风格.assets\image-20211124125602466.png)
+
+> 管道-过滤器风格的优点
+
+- 使得系统中的构件具有良好的**隐蔽性和高内聚、低耦合**的特点；
+
+- 允许设计者将整个系统的输入/输出行为看成是多个过滤器的行为的**简单合成**；
+
+- **支持软件复用：**
+  - 只要提供适合在两个过滤器之间传送的数据，任何两个过滤器都可被连接起来；
+
+- **系统维护和增强系统性能简单**：
+  - 新的过滤器可以添加到现有系统中来，旧的可以被改进的过滤器替换掉；
+
+- **允许对一些如吞吐量、死锁等属性的分析**；
+- **支持并行执行：**
+  - 每个过滤器是作为一个单独的任务完成，因此可与其它任务并行执行。
+
+> 管道-过滤器风格的缺点
+
+- **通常导致进程成为批处理的结构**
+  - 这是因为虽然过滤器可增量式地处理数据，但它们是独立的，所以设计者必须将每个过滤器看成一个完整的从输入到输出的转换；
+
+- **不适合处理交互的应用**
+  - 当需要增量地显示改变时，这个问题尤为严重；
+
+- 因为在数据传输上没有通用的标准，每个过滤器都增加了解析和合成数据的工作，这样就**导致了系统性能下降，并增加了编写过滤器的复杂性。**
+  - 绝大部分处理时间消耗在格式转换上

src/university/4.md

@@ -0,0 +1,249 @@
+## 层次体系结构概述
+
+**层次化早已经成为一种复杂系统设计的普遍性原则；**
+
+> 层次系统
+
+- 在层次系统中，系统被组织成若干个层次，每个层次由一系列构件组成
+- 下层构件向上层构件提供服务,上层构件被看作是下层构件的客户端
+
+![image-20211124144720587](层次体系结构.assets/image-20211124144720587.png)
+
+> 层次系统的基本组成
+
+- **构件**：各层次内部包含的构件
+- **连接件**：层间的交互协议
+- **拓扑结构**：分层
+- **拓扑约束**：对相邻层间交互的约束
+
+> 层次系统的特点
+
+- 优点
+  - 支持基于**抽象程度递增的系统设计**，使设计者可以把一个复杂系统按递增的步骤进行分解；
+  - 支持**功能增强**，因为每一层至多和相邻的上下层交互，因此功能的改变最多影响相邻的上下层；
+  - 支持**重用**。只要提供的服务接口定义不变，同一层的不同实现可以交换使用。这样，就可以定义一组标准的接口，而允许各种不同的实现方法。
+- 缺点
+  - **并不是每个系统都可以很容易地划分为分层的模式**，甚至即使一个系统的逻辑结构是层次化的，出于对系统性能的考虑，系统设计师不得不把一些低级或高级的功能综合起来；
+  - **很难找到一个合适的、正确的层次抽象方法。**
+
+## 分层模式
+
+- **某一层中的构件一般只与同一级别中的对等实体或较低级别中的构件交互**，这有助于减少不同级别中的构件之间的依赖性
+- 有两种通用的分层方法：
+  - **严格分层**(Strict System Layering)
+  - **松散分层**(Loosely System Layering)
+
+> 严格分层
+
+- 严格分层系统要求严格遵循分层原则
+- 第 N 层只能与第 N-1 和N+1层中的构件进行交互，第 N-1 层只能与第 N和N-2 层进行交互，依次类推（**不能跨越多层进行交互**）
+- **优点：修改简单性**
+- **缺点：效率低**
+
+> 松散分层
+
+- **允许构件与位于它下面的任意层中的组件进行交互**
+  - 第N 层不仅可以与第 N-1 层交互，而且可以与第 N-2 层和第 N-3 层交互。
+- **优点：松散方法可以改善效率**，因为系统不必将简单调用从一层转发到下一层。
+- **缺点：松散方法在层之间不提供相同的隔离级别**，这使得在不影响较高层的情况下换出较低层变得更困难。
+
+> J2EE中层次体系结构
+
+![image-20211124145531444](层次体系结构.assets/image-20211124145531444.png)
+
+## 分层模式的交互模式
+
+那么，针对分层系统中层间交互的“激发性”（谁发起调用Call），分为以下两种基本的交互模式：
+
+- **由上而下的交互模式** (top-down triggering)
+- **由下而上的交互模式** (bottom-up triggering)
+
+> 由上而下模式
+
+- 在由上而下模式中，**外部实体与系统中的最高层交互。**
+- 最高层使用较低级别层的一个或多个服务。
+- 反过来，每个较低级别都使用它下面的层，直到到达最低层。
+
+- **一个传入调用可能导致多个传出调用。**当较高级别服务聚合几个较低级别服务的结果，或协调多个必须按特定的顺序执行的较低级服务的执行时，通常会发生这种情况。
+- 可能会使用**松散的分层方法。**
+- **顶层服务的调用并不一定会到达(调用)所有层。**例如，WEB应用程序中，用户发送用户注册请求，服务器端进行校验，**如果校验不合格，不调用数据访问层将该用户加入系统。**
+
+>由下而上模式
+
+- 在由下而上模式中，**外部实体与系统中的最底层交互**，通常用来监视某些底层系统的状态变化。
+- 当被监控对象状态发生改变时，触发系统最底层的某些服务；
+  每个较低级别回调它上面的层的服务，直到到达最顶层；
+- 在此方案中，**客户端只能使用最底层的一组服务，**而无法直接了解任何较高的层。
+
+> 二者的区别
+
+- 在由上而下方案中，**较高层直接调用较低层**，因此高层依赖于低层。
+- 在由下而上方案中，**较低层通过事件(event)、回调(callback)和委派(delegate)来与较高层通信。**
+- 由上而下的信息和控制通常被描述成**请求(request)**；
+- 由下而上的方式被描述为**通知(notify)**。
+
+## 分层系统的几个例子
+
+> DBMS中的“三级模式-两层映像”
+
+![image-20211124150837698](层次体系结构.assets/image-20211124150837698.png)
+
+> ISO/OSI网络的分层模型
+
+![image-20211124150916503](层次体系结构.assets/image-20211124150916503.png)
+
+> 计算机操作系统(OS)的层次结构
+
+![image-20211124151059669](层次体系结构.assets/image-20211124151059669.png)
+
+> C/S (Client/Server)
+
+![image-20211124151117808](层次体系结构.assets/image-20211124151117808.png)
+
+> B/S (Browser/Server)
+
+![image-20211124151224676](层次体系结构.assets/image-20211124151224676.png)
+
+> 信息系统的典型分层结构
+
+![image-20211124151333763](层次体系结构.assets/image-20211124151333763.png)
+
+## 分层系统设计的过程
+
+- Step 1: 为把任务进行分层而定义抽象准则
+- Step 2: 根据抽象准则定义抽象层数 
+- Step 3: 给每个层命名并指定它们的任务 
+- Step 4: 设计层次内部的构件
+- Step 5: 为每个层次定义接口并指定相邻层间的通信
+- Step 6: 弱化相邻层之间的耦合
+- Step 7: 设计错误处理策略
+
+> 分层准则
+
+- **松散耦合**：提高系统的可维护性。
+- 依赖关系：特定层中的构件**只应与同一层及其下一层的构件存在依赖关系(即采用严格分层的方式)。**
+  - 如果子系统需要直接访问低层服务(即采用松散分层的方式)，务必需要慎重使用。
+- 易变性：
+  - 最上层放置随用户需求的改变而改变的元素；
+  - 最底层放置随实施平台(硬件、语言、操作系统、数据库等)的改变而改变的元素；
+  - 中间层放置广泛适用于各种系统和实施环境的元素；
+  - 如果在这些大类中进一步划分有助于对模型进行组织，则添加更多的层；
+- 通用性：
+  - 将抽象的模型元素放置在低层；
+  - 将具体的模型元素放置在高层；
+
+> 确定层数
+
+- **层数：**
+  - 对于小型系统，3层就足够
+  - 对于复杂系统，通常需要 5-7 层
+  - 如果超过 10 层，就需要慎重考虑
+- **层数越多，越需慎重：导致不必要的系统开销；**
+- **层数太少：导致系统结构混乱不清。**
+
+> 给各层分配任务
+
+- 将整个系统所需要实现的任务，分配到某一特定的层次，即定义系统中每一层所能提供的服务：
+  - 最顶层的任务就是整个系统从用户出发的任务；
+  - 较高层次的任务建立在较低层次任务之上；
+- 分配任务的标准：“倒金字塔式”复用
+  - 较高的层次应定义较多的服务数目，可避免开发者了解过多的底层细节(这些细节在开发过程中可能会频繁改变)；
+  - 高层应具有扩展性以覆盖更大的可用范围；
+  - 底层应设法保持“瘦小”和“稳定”：内核。
+
+> 设计层次内部结构
+
+- 如果某一层内部的构件/服务比较多，那么可能使系统处于混乱状态；
+- 因此，需要对每个层次内部服务的聚类和模块化，使之清晰和有组织性。
+
+> 为每个层次定义接口并指定相邻层间的通信
+
+- 定义每一级别之间的接口以及它们彼此通信所需的协议。
+- 选择层间的交互协议：
+  - 自上而下模式
+  - 自下而上模式
+  - 双向模式
+
+> 弱化相邻层之间的耦合
+
+- **单向耦合：**改变层N不需要考虑对层N+1的影响，只要保证层N的接口保持不变即可；
+- 如果第N 层中的构件可直接访问第N-1层中的构件的实现，这使得较高级别依赖于较低级别的实现细节，也是不可取的。
+- 引入外观模式Facade 等设计模式以及其他“去耦合”技术，以便将这种类型的耦合控制在最小。 
+
+> 设计错误处理策略
+
+- 考虑如何处理错误：必须定义对于所有级别而言一致的错误处理策略。
+- 当设计错误处理策略时，应考虑下列因素：
+  - 尽可能在错误发生的层次对错误进行处理；
+  - 避免通过异常处理机制将较低级别抽象公开给较高级别；
+  - 如果必须使异常沿层次上移，那么应将较低级别异常转化为对于处理层而言有一定意义的异常；
+  - 尽可能把错误消灭在低层，可避免高层陷入过多的错误处理细节。
+
+## 讨论题
+
+> 什么是软件体系结构的风格？它在软件开发过程中具有何种意义？
+
+风格：
+
+- 软件体系结构风格是指设计、组织和实现软件体系结构的各种惯用模式和习惯用法，是
+  对一系列体系结构设计的抽象。
+
+意义：
+
+- 利用软件体系结构风格，可以在不同的软件体系结构设计过程中重复使用同一个体系结
+  构。这样可以将软件复用粒度提高到软件体系结构一级。
+- 通过学习软件体系结构风格，可以在软件体系结构设计过程中，采用成熟的体系结构风
+  格，使得所设计的软件体系结构有良好的组织结构和通用性。
+
+> 常见的软件体系结构风格主要有哪些种类？
+
+- 数据流风格:批处理序列，管道′过滤器
+- 调用/返回风格:主程序/子程序，面向对象风格，层次结构
+- 独立构件风格:进程通信，事件系统
+- 虚拟机风格:解释器，基于规则的系统
+- 仓库风格:数据库系统，超文本系统，黑板系统
+
+> 简述管道-过滤器的组成。
+
+- 构件：过滤器，处理数据流
+  - 一个过滤器封装了一个处理步骤
+  - 数据源点和数据终止点可以看作是特殊的过滤器
+- 连接件：管道，连接一个源和一个目的过滤器
+  - 转发数据流:将一个过滤器的输出传到另 一过滤器的输入
+
+连接器定义了数据流图，形成拓扑结构
+
+>简述管道-过滤器风格的优缺点。
+
+优点：
+
+- （1）良好的隐蔽性和高内聚、低耦合的特点；
+- （2）允许设计者将整个系统的输入/输出行为看成是多个过滤器的行为的简单合成；
+- （3）支持软件复用：
+- （4）系统维护和增强系统性能简单：
+- （5）支持过滤器的并行执行：
+
+缺点：
+
+- （1）不适合处理交互的应用；
+- （2）因为在数据传输上没有通用的标准，每个过滤器都增加了解析和合成数据的工作，这样就导致了系统性能下降，并增加了编写过滤器的复杂性。
+
+> 何谓层次体系结构中的“严格分层”和“松散分层”?
+
+严格分层：
+
+- 严格分层系统要求严格遵循分层原则
+- 第 N 层只能与第 N-1 和N+1层中的构件进行交互，第 N-1 层只能与第 N和N-2 层进行交互，依次类推
+
+松散分层：
+
+- 允许构件与位于它下面的任意层中的组件进行交互
+- 第N 层不仅可以与第 N-1 层交互，而且可以与第 N-2 层和第 N-3 层交互。
+
+> 何谓层次体系结构风格的松散分层？有何特点？
+
+允许构件与位于它下面的任意层中的组件进行交互的分层模式称为松散分层。
+
+优点：松散方法可以改善效率，因为系统不必将简单调用从一层转发到下一层。
+
+缺点：松散方法在层之间不提供相同的隔离级别，这使得在不影响较高层的情况下换出较低层变得更困难。

src/university/5.md

@@ -0,0 +1,277 @@
+## 计算机模式的演化
+
+- 计算模式经历了以下六代：
+  - 1965-1985：以大型机为核心的集中式处理模式；
+  - 1986-1990：以PC/文件服务器为核心的文件共享计算模式；
+  - 1990-1996：以C/S结构为主流的分布式计算模式；
+  - 1996- ：以Web为核心、B/S结构为主流的分布式计算模式；
+  - 2000- ：以各类移动设备为核心的普适计算模式(无所不在的计算，无所不在的通讯)；
+  - 2005- ：以Grid、P2P、Web2.0等技术为核心的分布式计算模式；
+
+## 客户机/服务器模式
+
+- 文件共享结构的缺陷导致了C/S架构的出现
+  - 数据库服务器代替了文件服务器
+  - 服务器使用DBMS，快速应答用户请求
+  - RPC或SQL是客户机和服务器之间的典型通讯模式
+- 优点:
+  - C/S降低了网络通讯量：提供请求/应答模式，而非文件传输
+  - 多用户通过GUI访问共享数据库
+
+![image-20211124162422729](CS和BS体系结构.assets/image-20211124162422729.png)
+
+- 客户机/服务器：一个应用系统被分为两个逻辑上分离的部分，每一部分充当不同的角色、完成不同的功能，多台计算机共同完成统一的任务。
+  - 客户机(前端，front-end)：业务逻辑、与服务器通讯的接口；
+  - 服务器(后端：back-end)：与客户机通讯的接口、业务逻辑、数据管理。
+- 一般的
+  - 客户机为完成特定的工作向服务器发出请求；
+  - 服务器处理客户机的请求并返回结果。
+- C/S结构的发展历程：
+  - 两层C/S
+  - 三层C/S
+  - 多层C/S
+
+![image-20211124162719095](CS和BS体系结构.assets/image-20211124162719095.png)
+
+- 在三层和多层C/S中，**每两层之间形成C/S关系；**
+  - 例如，在三层C/S中，应用服务器既可以看作是客户机的“服务器”，同时也是数据库服务器的“客户机”；
+  - 每个服务器充当不同的角色，完成不同的任务；
+    - 终结服务器：不再是其他服务器的“客户端”；
+    - 非终结服务器：需要得到其他服务器的支持；
+- 服务器的分类：
+  - 信息/数据库服务器：存储和处理数据；
+  - 应用服务器：提供业务逻辑服务；
+  - 管理类服务器：DNS服务器、路由服务器、消息服务器等；
+- 连接的接口：
+  - 基于过程：同步响应
+  - 基于消息：异步响应
+
+### 二层C/S体系结构
+
+- 用户界面处于客户机
+- 数据库管理服务处于服务器端，通常是存储过程/触发器的形式
+- 业务处理过程（即业务逻辑）被分解为客户机与服务器两部分
+
+> 组成
+
+- **数据库服务器**：存放数据的数据库、负责数据处理的业务逻辑；
+- **客户机应用程序**：
+  - GUI：用户界面
+  - 业务逻辑：利用客户机上的应用程序对数据进行处理；
+- **连接件**：经由网络的调用-返回机制或事件机制。
+  - 客户机服务器：客户机向服务器发送请求，并接收返回结果。
+
+> 胖客户端和瘦客户端
+
+- 业务逻辑的划分比重：在客户端多一些还是在服务器端多一些？
+  - **胖客户端：客户端执行大部分的数据处理操作**
+  - **瘦客户端：客户端具有很少或没有业务逻辑**
+
+> 局限
+
+- 系统伸缩性差：当用户数超过100，性能急剧恶化
+  - **服务器成为系统的瓶颈。**
+- 互操作性差：使用DBMS所提供的私有的数据编程语言来开发业务逻辑，降低了DBMS选择的灵活性 ——**导致：软件移植困难，新技术无法轻易使用**
+  - 例如：Oracle DB提供的若干存储过程函数，在SQL Server上就不能执行。
+- 数据安全性较差
+- 系统管理与配置成本高：当系统升级时，每个客户端都需要随之改变 ——**导致：维护和升级困难**
+
+> 应用
+
+- 两层C/S架构通常被用在那些**管理与操作不太复杂的非实时的信息处理系统**
+- 适合于轻量级事务 ——**客户机对服务器的请求少，数据传输量少**
+- 当业务逻辑较少变化以及用户数少于100时，两层C/S架构的性能较好
+
+### 三层C/S体系结构
+
+- 三层C/S体系结构的出现克服了两层C/S的缺陷
+- 在客户端与数据库服务器之间增加了一个中间层
+  - 中间层可能为：事务处理监控服务器、消息服务器、应用服务器等
+  - 中间层负责消息排队、业务逻辑执行、数据传输等功能
+
+> 结构
+
+- **第1层：用户界面—表示层**
+- **第2层：业务逻辑—功能层**
+- **第3层：数据库—数据层**
+
+> 表示层
+
+- 用户接口部分，担负着用户与应用之间的对话功能；
+- 检查用户的输入，显示应用的输出；
+- 通常使用GUI；
+- 在变更时，只需要改写显示控制和数据检查程序，而不影响其他层；
+- 不包含或包含一部分业务逻辑。
+
+> 功能层
+
+- 应用系统的主体，包括大部分业务处理逻辑 (通常以业务构件的形式存在，如JavaBean/EJB/COM等)；
+- 从表示层获取用户的输入数据并加以处理；
+- 处理过程中需要从数据层获取数据或向数据层更新数据；
+- 处理结果返回给表示层。
+
+> 数据层
+
+- DMBS；
+- 接受功能层的数据查询请求，执行请求，并将查询结果返回给功能层；
+- 从功能层接受数据存取请求，并将数据写入数据库；
+- 请求的执行结果也要返回给功能层。
+
+> 基于集群的物理分布
+
+- 事实上，功能层通常不是只驻留在同一台服务器上，数据层也是如此；
+- 如果**功能层(或数据层)分布在多台服务器上**，那么就形成了**基于集群(Cluster)的C/S物理分布模式。**
+
+> 集群
+
+- 一组松散耦合的服务器，共同协作，可被看作是一台服务器
+- 用来改善速度、提高可靠性与可用性，降低成本
+- 负载平衡是集群里的一个关键要素
+- 集群内**各服务器上的内容保持一致(通过冗余提高可靠性与可用性)**
+- 集群内各服务器上的内容之和构成系统完整的功能/数据，是**对系统功能集合/数据集合的一个划分(通过分布式提高速度与并发性)**
+
+>三层C/S结构的优缺点
+
+- 优点：
+  - **性能与灵活性**：允许更灵活有效地选用相应的平台和硬件系统，三层C/S结构将极大改善性能与灵活性(通常可支持数百并发用户，通过集群可达数万并发用户)；
+  - **可维护性和可扩展性**：允许合理地划分三层结构的功能，使之在逻辑上保持相对独立性，能提高系统和软件的可维护性和可扩展性。
+  - **并行开发**：应用的各层可以并行开发，可以选择各自最适合的开发语言。
+  - **安全性**：利用功能层有效地隔离开表示层与数据层，未授权的用户难以绕过功能层而利用数据库工具或黑客手段去非法地访问数据层，为严格的安全管理奠定了坚实的基础；
+- 缺点：
+  - **三层C/S结构各层间的通信效率若不高，即使分配给各层的硬件能力很强，其作为整体来说也达不到所要求的性能。**
+  - 设计时必须**慎重考虑三层间的通信方法、通信频度及数据量**，这和提高各层的独立性一样是三层C/S结构的关键问题。——**分层风格的固有缺点**
+
+## 浏览器/服务器
+
+- 浏览器/服务器(B/S)是三层C/S风格的一种实现方式。
+  - 表现层：浏览器
+  - 逻辑层：
+    - Web服务器
+    - 应用服务器
+  - 数据层：数据库服务器
+
+>B/S结构的优缺点
+
+**优点：**
+
+- **基于B/S体系结构的软件，系统安装、修改和维护全在服务器端解决，系统维护成本低：**
+  - 客户端无任何业务逻辑，用户在使用系统时，仅仅需要一个浏览器就可运行全部的模块，真正达到了“零客户端”的功能，很容易在运行时自动升级。
+  - 良好的灵活性和可扩展性：对于环境和应用条件经常变动的情况，只要对业务逻辑层实施相应的改变，就能够达到目的。
+- 三层模式成为真正意义上的**“瘦客户端”**，从而具备了很高的稳定性、延展性和执行效率。
+- 三层模式可以将服务集中在一起管理，统一服务于客户端，从而具备了**良好的容错能力和负载平衡能力**。
+
+**缺点：**
+
+- 安全性难以控制。
+- 数据查询等响应速度上，要远远地低于C/S体系结构。
+- 数据提交一般以页面为单位，数据的动态交互性不强，不利于在线事务处理(OLTP)应用；
+- 受限于HTML的表达能力，**难以支持复杂GUI** (如报表等)。
+
+## C/S+B/S混合体系结构
+
+为了克服C/S与B/S各自的缺点，发挥各自的优点，在实际应用中，通常**将二者结合起来**；
+
+> 混合原则一：“内外有别”的原则：
+
+- **企业内部用户通过局域网直接访问数据库服务器**
+  - C/S结构；
+  - 交互性增强；
+  - 数据查询与修改的响应速度高；
+- **企业外部用户通过Internet访问Web服务器/应用服务器**
+  - B/S结构；
+  - 用户不直接访问数据，数据安全；
+
+> 混合原则二：“查改有别”的原则：
+
+- 不管用户处于企业内外什么位置(局域网或Internet)，凡是需要对数据进行更新操作的(Add, Delete, Update)，都需要使用C/S结构；
+- 如果只是执行一般的查询与浏览操作(Read/Query)，则使用B/S结构。
+
+## 讨论题
+
+> 文件共享体系结构的主要缺点是什么？
+
+- 客户端和服务器之间需要移动大量不必要的数据，降低了应用性能；
+- 客户端必须相当健壮，它要完成几乎所有的功能，同时必须有足够的磁盘空间来存储下载的文件和表；
+- 容易破坏数据完整性(多个用户共同访问同一个文件)。
+
+> 与文件共享体系结构相比，C/S体系结构有何优势？
+
+- 数据库服务器代替了文件服务器
+- 服务器使用DBMS，快速应答用户请求
+- C/S降低了网络通讯量：提供请求/应答模式，而非文件传输
+- 多用户通过GUI访问共享数据库
+
+> 请简述隐式调用系统的优缺点
+
+优点：（1）为软件重用提供了强大的支持。（2）为改进系统带来了方便。
+
+缺点：（1）构件放弃了对系统计算的控制。（2）数据交换的问题。（3）既然过程的语义必须依赖于被触发事件的上下文约束，关于正确性的推理就存在问题。
+
+> 两层C/S体系结构中客户端应用程序有哪些主要任务？
+
+- 1、提供用户与数据库的交互界面 
+- 2、向数据库服务器提交用户请求并接受来自数据库服务器的信息 
+- 3、利用客户端应用程序对存在于客户端的数据执行应用逻辑要求。
+
+> 在C/S体系结构中，何谓“胖客户端”？何谓“零客户端”？
+
+业务逻辑的划分比重：在客户端多一些还是在服务器端多一些
+
+- 胖客户端：客户端执行大部分的数据处理操作
+- 瘦客户端：客户端具有很少或没有业务逻辑
+
+> 三层C/S结构的优缺点
+
+功能层、表示层、数据层
+
+优点：
+
+- **性能与灵活性**：允许合理的划分三层结构的功能，使之在逻辑上保持相对独立性，从而使整个系统的逻辑结构更为合理清晰，能提高系统和软件的可维护性和可扩展性。
+- **可维护性和可扩展性**：允许更灵活的选用相应的平台和硬件系统使之在处理负荷能力上与处理特性上分别适应于结构清晰的三层，并且具有可升级性和开放性
+- **并行开发**：应用的各层可以并行开发，可以选择各自最适合的开发语言，从而达到较高的性价比.
+- **安全性**：允许利用功能层有效的隔离开表示层 和数据层，未授权的用户难以通过如黑客手段访问数据层，同时也更加合理和有效的控制
+
+缺点：
+
+- 三层C/S结构**各层间的通信效率**若不高，即使分配给各层的硬件能力很强，其作为整体来说也达不到所要求的性能。
+- 设计时必须**慎重考虑三层间的通信方法、通信频度及数据量**，这和提高各层的独立性一样是三层C/S结构的关键问题。——分层风格的固有缺点
+
+> B/S体系结构的优缺点
+
+- 基于B/S体系结构的软件，系统安装、修改和维护全在服务器端解决，**系统维护成本低**：
+  - **客户端无任何业务逻辑**，用户在使用系统时，仅仅需要一个浏览器就可运行全部的模块，真正达到了“零客户端”的功能，很容易在运行时自动升级。
+  - **良好的灵活性和可扩展性**：对于环境和应用条件经常变动的情况，只要对业务逻辑层实施相应的改变，就能够达到目的。
+- 三层模式成为真正意义上的**“瘦客户端”**，从而具备了很高的稳定性、延展性和执行效率。
+- 三层模式可以将服务集中在一起管理，统一服务于客户端，从而具备了良好的**容错能力和负载平衡能力。**
+
+>请设计一个具有B/S结构(或三层C/S结构)登录模块的体系结构，并说明每层的作用。
+
+**B/S结构:**
+
+- (1)第一层∶客户层(或表现层、界面层），第二层:业务逻辑层(或应用层、功能
+  层、应用服务器层)，第三层∶数据层
+- (2)第一层只有浏览器，通过访问第二层的网页实现用户界面，即接受用户的名称
+  密码的输入，并向第二层传送用户名和密码，最后将登录结果显示出来。
+- (3）第二层接受第一层的用户名和密码，并通过访问第三层判断用户合法性，最后将
+  登陆结果以网页形式返回给第一层。
+- (4）第三层在数据库或文件中存储用户名和密码，并为第二层提供数据访问服务。
+
+**三层C/S结构:**
+
+- (1)第一层∶客户层（或表现层、界面层），第二层:业务逻辑层（或应用层、功能
+  层、应用服务器层)，第三层∶数据层
+- (2)第一层实现用户界面，并通过网络连接或进程通信形式向第二层提出服务请求，
+  最后将登录结果显示出来。
+- (3)第二层实现业务逻辑，即接受第一层的服务请求，并执行相应功能业务)代码，
+  最后将处理结果返回给第一层;业务功能需要访问数据时向第三层提出数据访问请求。
+- (4）第三层在数据库或文件中存储用户名和密码，并为第二层提供数据访问服务。
+
+> 请设计一个具有B/S结构"登录模块"的体系结构，并说明每层的作用。
+
+（1）第一层：客户层（或表现层、界面层），第二层：业务逻辑层（或应用层、功能层、应用服务器层），第三层：数据层
+
+（2）第一层只有浏览器，通过访问第二层的网页实现用户界面，即接受用户的名称、密码的输入，并向第二层传送用户名和密码，最后将登录结果显示出来。
+
+（3）第二层接受第一层的用户名和密码，并通过访问第三层判断用户合法性，最后将登陆结果以网页形式返回给第一层。
+
+（4）第三层在数据库或文件中存储用户名和密码，并为第二层提供数据访问服务。

src/university/6.md

@@ -0,0 +1,69 @@
+## MVC风格
+
+> 基本概念
+
+- **MVC是一种设计模式（体系结构模式）。** 
+- **MVC（Model-View-Controller）将一个交互式应用程序分成3个组件**
+  - **模型：包含核心功能和数据 （核心业务逻辑）**
+  - **视图：向用户显示信息**
+  - **控制器：处理用户输入**
+- **变更-传播机制保证了模型和用户界面之间的一致性**
+- **目的**
+  - 将人机交互从核心功能中分离出来(M) 
+  - 模型对用户来说是透明的，用户只需要观察视图(V)
+  - 用户与模型的交互通过控制器提供的安全方法来实现(C)
+
+> 各层的功能
+
+- Model（模型）
+  - 从数据库取出数据，并且赋予数据变量 
+  - 负责业务逻辑实现 
+  - 负责数据验证，然后将数据存入数据库
+- View（视图）
+  - 获取用户输入
+  - 向controller发送处理请求 
+  - 接收来自Controller的反馈并将model的处理结果显示给用户
+-  Controller（控制器）
+  - 接收来自客户的请求
+  - 调用model业务逻辑方法
+  - 调用View显示执行结果
+
+> MVC优点
+
+- 容易增加或者改变视图
+  - 事务逻辑被封装在Model中，所以在新增加一个视图的时候，不必要改动模型，而是因为业务逻辑都是一样的，所以只需要新增加一个视图类即可。
+- 容易独立地更新每个独立的软件模块
+  - 由于一个应用被分离为三个软件模块，因此，我们可以独立地改变其中的一个模块，而不影响其它两个模块。例如，一个应用的业务流程或者业务规则的改变只需改动MVC的模型层。
+- 代码易开发易维护
+- 业务逻辑更易测试 
+
+> MVC不足之处
+
+- 不适合小型，中等规模的应用程序，花费大量时间将MVC应用到规模并不是很大的应用程序通常会得不偿失；
+- 增加了系统结构和实现的复杂性。对于简单的界面，严格遵循MVC，使模型、视图与控制器分离，会增加结构的复杂性，并可能产生过多的更新操作，降低运行效率。 
+- 视图与控制器间的过于紧密的连接。视图与控制器是相互分离，但确实联系紧密的部件，视图没有控制器的存在，其应用是很有限的，反之亦然，这样就妨碍了他们的独立重用。 
+- 视图对模型数据的低效率访问。依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问，也将损害操作性能。 
+
+> MVC框架
+
+- 框架是体系结构风格实现，是半成品可进行二次开发
+- 应用于基于MVC架构模式的框架
+  - 常见的服务器端MVC框架有：Struts、Spring MVC、ASP.NET MVC、Zend Framework、JSF；
+  - 常见前端MVC框架：angularjs、reactjs、backbone；
+  - 由MVC演化出了另外一些模式如：MVP、MVVM。
+
+## 讨论题
+
+> 简述MVC风格的含义。  
+
+MVC风格将各个构件划分成各自独立的三个部分：模型、视图和控制器，分别对应商务逻辑、外观呈现和请求处理。
+
+> 简述事件系统风格的思想。
+
+构件不直接调用一个过程，而是触发或广播一个或多个事件。系统中的其它构件中的过程在一个或多个事件中注册，当一个事件被触发，系统自动调用在这个事件中注册的所有过程，这样，一个事件的触发就导致了另一模块中的过程的调用。
+
+> 什么是软件的性能质量属性，常用什么指标来衡量？
+
+- 指系统的响应能力，即要经过多长时间才能对某个事件做出响应,或在某段时间内系统所能处理的事件个数。
+
+- 通常用单位时间内所处理的事务数量或完成某个事务处理所需要的时间来衡量性能。

src/university/7.md

@@ -0,0 +1,265 @@
+
+
+
+
+## 为什么要引入SOA
+
+- 需求拉动
+- 技术推动
+
+> Internet环境下的企业交互
+
+- 现代企业已经不再是封闭的企业，市场分工的日益专业化使得**企业之间可能存在大量频繁的交互行为**，以发挥各自的竞争优势：
+  - 供应链：供应商-制造商；
+  - 客户关系管理：制造商-物流商-客户
+  - 服务：顾客、中介、服务提供者
+- 这种业务上的交互体现**为企业业务流程的交互/互操作**，同时一定需要企业信息系统的支持，因此体现为**软件系统之间的集成与互操作。**
+  互操作(Interoperability)：能够在异构的、分布式的系统之间交换和使用信息的能力；
+  不仅是不同企业之间，甚至一个企业内部的各个部门之间都有可能存在大量的交互。
+
+>异构系统的集成与互操作
+
+- 不同企业甚至是同一企业的不同部门所应用的软件系统可能是**异构的**：
+  - **技术平台（编程语言）不同**：J2EE-based、.Net-based
+  - **软件体系结构不同**：message-based、file-based、process-based
+  - **数据格式不同**：同样的“订单”对象，不同的属性集合
+- **集成这些分布式的软件系统，在它们之间传递数据和消息，是一件非常困难的事情。**
+
+>频繁变化的互操作与集成需求
+
+- 企业业务流程是**频繁变化的**；
+- 企业间的集成需求也不是固定的，随着业务流程的变化而随之变化；
+- 企业间应用系统的集成要能够**快速适应这种变化的需求**。
+
+>归纳：SOA所要解决的问题
+
+- 分布式企业间业务的协同。
+- 通过Internet连接在一起的异构企业应用软件系统的集成、交互与互操作。
+- 当业务过程发生变化时，软件系统能够快速响应。
+
+> 技术推动
+
+- 软件技术发展过程中，一直在寻求解决四个基本问题的方法：**质量问题、效率问题、互操作问题、柔性构造问题**
+- 通过**复用、松耦合、互操作**(标准)等机制来提高软件质量、加快软件研发效率、使研发出来的产品能够相互集成并灵活适应变化。
+
+## 什么是SOA
+
+**SOA=Service(服务)+体系结构(Architecture)**
+
+![image-20211124172500395](面向服务的体系结构.assets/image-20211124172500395.png)
+
+> SOA的核心要素
+
+SOA通过三个途径来达到灵活性：
+
+- 标准化封装
+- 复用
+- 松耦合可编排
+
+> 标准化封装
+
+- 传统软件架构，因为封装的技术和平台依赖性，一直没有彻底解决互操作问题。**互联网前所未有的开放性意味着各节点可能采用不同的组件、平台技术，构件模型和架构没有统一标准，从而呈现出巨大的异构性。**结果是软件系统跨互联网进行交互变得困难重重，最终导致了跨企业/部门的业务集成和重组难以灵活快速的进行。
+- 而SOA通过标准的、支持Internet、与操作系统无关的SOAP协议实现了连接互操作。
+
+> 软件复用
+
+- 软件**复用**，即软件的重用，也叫再用，是指同一事物不作修改或稍加改动就多次重复使用。从软件复用技术的发展来看，就是不断提升抽象级别，扩大复用范围。
+
+![image-20211124172753984](面向服务的体系结构.assets/image-20211124172753984.png)
+
+> 耦合关系
+
+- 传统软件将软件之中核心三部分**网络连接、数据转换、业务逻辑**全部耦合在一个整体之中，形成“铁板一块”的软件，“牵一发而动全身”，软件就难以适应变化。
+- **分布式对象技术将连接逻辑进行分离**，消息中间件将连接逻辑进行异步处理，增加了更大的灵活性。消息代理和一些分布式对象中间件将数据转换也进行了分离。
+- 而**SOA架构**，通过服务的封装，实现了业务逻辑与网络连接、数据转换等进行完全的解耦。
+
+![image-20211124172820419](面向服务的体系结构.assets/image-20211124172820419.png)
+
+## SOA的基本构件和连接件
+
+### SOA基本构件类型：服务
+
+- SOA中可用的基本构件是“服务”；
+  - 从外特性上看，**一个服务被定义为显式的、独立于服务具体实现技术细节的接口。**
+  - 从内特性上看，**服务封装了可复用的业务功能，**这些功能通常是**大粒度业务，**如业务过程、业务活动等。服务的实现可采用任何技术平台，如J2EE、.Net等。
+
+> 服务之间的“连接件”
+
+- 通过接口，采用位置透明的、可互操作的协议进行调用，与客户端以“松散耦合”(loosely coupling)的方式绑定在一起。
+- SOA中所有协议均是基于XML的文本文件。
+
+## SOA的典型特征
+
+> 分布式异构系统的集成与互操作
+
+![image-20211124173623513](面向服务的体系结构.assets/image-20211124173623513.png)
+
+
+
+![image-20211124173642611](面向服务的体系结构.assets/image-20211124173642611.png)
+
+
+
+![image-20211124173704681](面向服务的体系结构.assets/image-20211124173704681.png)
+
+虽然目前已经存在成熟的远程方法调用机制以实现异构系统的集成与互操作，**但在Internet这样的分布式环境下，SOA才能实现这一目标。**
+
+> 松散耦合
+
+- **传统的软件体系结构中的各构件，**通常都是紧密耦合在一起的。
+  - **通过函数调用的方式实现互操作；**
+  - **客户端需要了解被调用构件的位置和技术细节；**
+  - 缺陷：构件的维护和重复使用变得非常困难，因为一个构件中的修改就自动意味着其他构件中的修改。
+- **SOA**则实现了完全的松散耦合：
+  - **位置透明**
+  - **与具体的实现细节无关（通过接口调用）**
+  - **标准化的通讯协议（XML-based）**
+
+> 大数据量低频率访问
+
+- 对于.NET、EJB或者RPC这些传统的分布式计算模型而言，它们的服务提供都是通过函数调用的方式进行的，一个功能的完成往往需要通过客户端和服务器来回**很多次函数调用**才能完成
+  - 在局域网的环境下，这些调用给**系统的响应速度和稳定性带来的影响都可以忽略不计**，但是在Internet环境下这些因素往往是决定整个系统是否能正常工作的一个关键决定因素。
+- SOA采用**大数据量的方式一次性进行数据交换。**
+
+> 基于文本的消息传递
+
+- 在COM、CORBA这些传统的组件模型中，从服务器端传往客户端的是一个**二进制编码的对象**，在客户端通过调用这个对象的方法来完成某些功能。
+  - 在Internet环境下，不同语言，不同平台对数据、甚至是一些基本数据类型定义不同，给**不同的服务之间传递对象带来很大困难。**
+- 由于基于文本的消息本身不包含任何处理逻辑和数据类型，**因此服务间只传递文本**，双方不存在兼容性问题。
+
+> 与上下文无关
+
+- 传统的软件体系结构，在设计阶段就要考虑各构件之间如何进行交互，也就是说，一个构件的设计模型可能依赖于其他构件的设计模型，即“**上下文相关**”。
+- 在SOA中，在设计阶段，服务不需要了解它们将来可能被复用的环境，即**独立于服务使用者的上下文。**
+
+>大粒度复用
+
+- **传统的软件体系结构中，被复用的软件体通常都是小粒度的，**如函数、对象、构件等。
+- 在企业级应用环境下，这种**小粒度软件体的复用效率过低。**
+- SOA中的服务是**大粒度复用体**，它更多的关注诸如业务过程/业务活动级别的复用，**复用效率更高。**
+- 另外，采用粗粒度服务接口的优点在于使用者和服务层之间不必再进行多次的信息交换。 
+
+## SOA实现
+
+- SOA只是一种概念和思想，需要借助具体的技术和方法来实现。
+- 实现SOA的方法
+  - Web服务（Web Service）
+  - 企业服务总线
+
+### Web服务
+
+- Web Services是建立于SOA（Service-Oriented Architecture，面向服务的体系结构）基础之上的分布式计算技术，可以将软件组件（包括来自不同系统的对象、函数等）发布为服务。
+- Web Services建立在XML标准上，可以使用任何编程语言、协议或平台开发出松散耦合的应用，以方便任何人能够在任何时候间通过任何平台访问该业务程序 。
+- Web Services的目标是消除**语言差异、平台差异、协议差异和数据结构差异**，成为不同构件模型和异构系统之间的集成技术。
+
+>Web Services举例
+
+- 网上商城服务提供商通过提供来自不同购物业务（商户系统、订单系统、物流系统、信用卡系统、公共信息系统）的业务应用程序部署其Web服务 
+- 服务提供商使用公共（或私有）的注册表（服务器）注册其业务服务（服务描述）。注册表中包含服务提供商提供的服务信息 
+- 客户可使用各种平台或设备（手机、电脑、各种终端、家电设备等），通过Internet或其他网络途径查找服务注册表来找到相应的Web服务，然后调用该服务的功能 
+
+![image-20211124200957259](面向服务的体系结构.assets/image-20211124200957259.png)
+
+> Web Services的特点
+
+- 封装性：Web Services是一种部署在Web上的对象，具备对象的良好封装性，而对于使用者而言，仅能看到该对象提供的功能列表  
+- 松散耦合：只要Web Services的调用接口不变，Web Services的内部变更对调用者来说都是透明的 
+  使用标准协议规范：Web服务基于XML消息交换，其所有公共的协约完全需要使用开放的标准协议进行描述、传输和交换。相比一般对象而言，其界面调用更加规范化，更易于机器理解  
+- 高度可集成性：由于Web Services采取简单的、易理解的标准协议作为组件描述，所以完全屏蔽了不同软件、平台的差异，无论是CORBA、DCOM还是J2EE都可以通过这种标准的协议进行互操作 
+- 易构建：要构建Web服务，开发人员可以使用任何常用编程语言（如Java、C#、C/C++或Perl等）及其现有的应用程序组件  
+
+>Web Services模型
+
+**典型的Web Services体系结构基于三种逻辑角色组成：**
+
+- 服务提供者（Service Provider）
+  - 从企业的角度看，这是服务的所有者。从体系结构的角度看，这是托管访问服务的平台。 
+- 服务请求者（Service Requestor）
+  - 从企业的角度看，这是要求满足特定功能的企业。从体系结构的角度看，这是寻找并调用服务，或启动与服务的交互的应用程序。
+- 服务注册中心（Service Registry）
+  - 对于静态绑定的服务请求者，服务注册中心是体系结构中的可选角色
+
+![image-20211124201225578](面向服务的体系结构.assets/image-20211124201225578.png)
+
+**角色之间的三个操作 ：**
+
+- **发布操作** ：使服务提供者可以向服务注册中心注册自己的功能及访问接口，以使服务请求者可以查找它，发布服务描述的位置可以根据应用程序的要求而变化。 
+- **查找操作** ：使服务请求者可以通过服务注册中心查找特定种类的服务。 
+- **绑定操作** ：使服务请求者能够真正使用服务提供者提供的服务。
+
+**Web 服务的构件:**
+
+- 服务
+  - 服务是一个软件模块，它部署在由服务提供者提供的可以通过网络访问的平台上。
+  - 当服务的实现中利用到其它 的Web 服务时，它也可以作为请求者。 
+- 服务描述
+  - 包括服务的数据类型、操作、绑定信息和网络位置。
+  - 服务描述可以被发布给服务请求者或服务注册中心。
+
+>Web Services协议 
+
+- Web Services支持一种标准的协议栈模型，以支持发布、发现和绑定的互操作。
+
+![image-20211124201631391](面向服务的体系结构.assets/image-20211124201631391.png)
+
+- 最简单的协议栈包括传输层的HTTP，基于XML的消息传递层的SOAP协议以及服务描述层的WSDL ： 
+
+![image-20211124201649067](面向服务的体系结构.assets/image-20211124201649067.png)
+
+- **Web Services体系结构的基础是XML消息传递，XML消息传递的行业标准是SOAP。**SOAP是一种简单的、轻量级的基于XML的机制，用于在网络应用程序之间进行结构化数据交换，它包括三部分：
+  - 一个定义描述消息内容的框架的信封
+  - 一组表示应用程序定义的数据类型实例的编码规则 
+  - 表示远程过程调用和响应的约定 
+- **XML**可扩展标记语言(eXtensible Markup Language)是Web Services进行数据交换时所采用的标准，同时也是Web Services技术的全部规范和技术基础。
+- **SOAP**简单对象访问协议是以XML为基础，独立于编程语言和操作平台，交换结构化信息的轻量级协议。  
+- **WSDL**网络服务描述语言(Web Services Description Language)是一种使用 XML 编写的文档。这种文档可描述某个 Web service。它可规定服务的位置，以及此服务提供的操作（或方法） 。 
+- **UDDI**统一描述、发现与集成服务是一种目录服务，企业可以使用它对 Web services 进行注册和搜索。 
+
+> 实现Web Services
+
+- 服务提供方将Web服务创建为基于SOAP协议的服务接口，然后将这些服务部署到服务容器中，以便其他用户调用。
+- 服务提供方使用服务代理注册基于WSDL的服务描述，服务代理方通常是UDDI注册表。
+- UDDI注册表将服务描述存储为绑定模板和到服务提供方环境中WSDL的URL。
+- 服务请求方通过查询UDDI注册表找到所需服务并获取绑定信息和URL，以确定服务提供方。
+- 服务请求方使用绑定信息激活服务提供器，并检索已注册服务的WSDL服务描述，通过创建客户代理应用程序，建立与服务器间的通信。
+- 最后，服务请求方与服务提供方通信，并通过调用服务容器中的服务进行信息交换。
+
+>Web Services开发平台
+
+- Sun的产品 
+  - Sun公司发布了基于Java和XML技术的APl及其实现方案JAX Pack，用于开发、测试基于Java和开放式标准的Web Services解决方案。另外，Sun公司还发布了一组全面的、专用于Web Services的技术开发工具包JWSDP（Java Web Services Developer Pack）。 
+- IBM Web Services 
+  - IBM提供的产品基于Java/J2EE、SOAP、WSDL和UDDI等Web服务标准，全面反映了Web服务技术在动态电子商务中的应用。 
+- Microsoft.NET 
+  - Microsoft.NET提供了用于开发、部署基于标准的Web服务和所有类型的应用程序的.NET平台的框架和编程模型。这一框架定义了三个层：Microsoft操作系统、企业服务器和使用Visual Studio的.NET构件块。
+
+## 企业服务总线
+
+- ESB全称为Enterprise Service Bus，即企业服务总线。
+- 一个ESB是一个预先组装的SOA实现，它包含了实现SOA分层目标所必需的基础功能部件。
+- ESB是传统中间件技术与XML、Web服务等技术相互结合的产物，用于实现企业应用不同消息和信息的准确、高效和安全传递。
+
+![image-20211124202427148](面向服务的体系结构.assets/image-20211124202427148.png)
+
+> 企业服务总线的功能
+
+-  服务统一管理
+  - 为整个系统提供一个统一的、标准的、可靠的、可扩展的服务管理平台。
+- 集成服务
+  - 提供基础的服务与定制的服务;支持集成服务模式;支持服务的分解，服务调度和路由，服务封装，服务组合。
+- 公用服务
+  - 提供内置的各种公用服务。例如，认证服务，日志服务等。
+- 服务协议转换
+  - 通过把不同的通信协议转换成标准的报文，屏蔽异构系统的底层技术差异。
+- 服务监控
+  - 提供服务等级管理及流量管理。提供多角度的服务实时监控、报警与交易分析报表。
+- 安全体系
+  - 提供多种安全机制并支持和第三方安全系统的有效集成，提供有效的安全监控机制。
+
+## 讨论题
+
+> 什么是ESB？
+
+- ESB全称为Enterprise Service Bus，即企业服务总线。
+- 一个ESB是一个预先组装的SOA实现，它包含了实现SOA分层目标所必需的基础功能部件。
+- ESB是传统中间件技术与XML、Web服务等技术相互结合的产物，用于实现企业应用不同消息和信息的准确、高效和安全传递。

src/university/8.md

@@ -0,0 +1,267 @@
+
+
+
+
+## 中间件
+
+> 现代应用系统的基本特征
+
+- 分布   
+  - **任务已不只是在单机上运行，而是由网络中多台计算机上的相关应用共同协作完成，需考虑网络传输、数据安全、数据一致性、同步等诸多问题；**
+- 异构 
+  - 计算机硬件、操作系统、网络协议、数据库系统以及开发工具种类繁多，**需考虑数据表示、调用接口、处理方式等诸多问题；**
+- 动态协作 
+  - 参与协作的应用允许**位置透明性、迁移透明性、负载平衡性等需求。**
+
+![image-20211124202944204](中间件与框架.assets/image-20211124202944204.png)
+
+
+
+![image-20211124202953926](中间件与框架.assets/image-20211124202953926.png)
+
+> 已经接触了许多的中间件
+
+- JDBC、ODBC；
+- 应用服务器；
+- JMS消息服务器；
+
+共同的特征：
+
+- **它们独立存在是没有意义的；**
+- **目标：通过不同的方式来连接多个应用系统；**
+
+> 中间件的定义
+
+- **(SEI)中间件**：一种连接类软件，由一组服务构成，这些服务可使得运行在一台或多台机器上的进程通过网络进行交互
+- **(ObjectWeb)中间件**：分布式计算环境中一种处于操作系统和应用系统之间的软件层
+- **(Wikipedia) 中间件**：一种软件，用来连接不同的软构件或应用系统
+
+![image-20211124203326252](中间件与框架.assets/image-20211124203326252.png)
+
+> 中间件的理解
+
+- **中间件(Middleware)是一种软件，处于系统软件（操作系统和网络软件）与应用软件之间，它能使处于应用层中的各应用成分之间实现跨网络的协同工作（也就是互操作），**这时允许各应用软件之下所涉及的“系统结构、操作系统、通信协议、数据库和其它应用服务”各不相同。
+
+> 中间件组成
+
+- 执行环境（Execution Environment）软件 
+  - 如果一个网络的各个节点上安装了EE软件，各节点上的应用软件之间就可以实现相互合作。EE软件使各节点的下层设备对应用软件透明化了，EE软件是中间件中的主体部分。
+- 应用开发(Application Development)工具
+  - AD工具用来帮助开发“透明调用对方”成分的应用软件，或改造原有的无透明调用能力的应用软件。AD工具是中间件中的必备部分。
+
+> 中间件的功能
+
+- 负责客户机与服务器之间的连接和通信，以及客户机与应用层之间的高效率通信机制。 
+- 提供应用层不同服务之间的互操作机制，以及应用层与数据库之间的连接和控制机制。
+- 提供一个多层体系结构的应用开发和运行的平台，以及一个应用开发框架，支持模块化的应用开发。
+- 屏蔽硬件、操作系统、网络和数据库的差异。
+- 提供应用的负载均衡和高可用性、安全机制与管理功能，以及交易管理机制，保证交易的一致性。
+- 提供一组通用的服务去执行不同的功能，避免重复的工作和使应用之间可以协作。
+
+> 中间件的分类
+
+- 远程过程调用中间件（RPC）
+- 消息中间件（MO）
+- 对象请求代理中间件（ORB）
+- 数据访问中间件（DA）
+- 交易中间件 （DTP）
+- 应用服务器和企业服务总线
+
+### RPC
+
+- **Remote Procedure Call (RPCs, 远程过程调用)** 
+  - 客户端可调用运行在远程系统上的功能/函数 
+  - 远程系统上的程序逻辑可以简单的看作本地函数而加以执行
+  - 可能是异步/同步
+
+![image-20211124203831857](中间件与框架.assets/image-20211124203831857.png)
+
+### MOM
+
+- **Message Oriented Middleware (MOM, 面向消息的中间件)**
+
+
+
+![image-20211124204024836](中间件与框架.assets/image-20211124204024836.png)
+
+
+
+![image-20211124204032053](中间件与框架.assets/image-20211124204032053.png)
+
+### ORB
+
+- **Object Request Broker (ORB, 对象请求代理)**
+  - 是对象之间建立客户端/服务端(Client/Server)关系的中间件。
+  - 使用ORB，客户可以透明地调用一个服务对象上的方法，这个服务对象可以在本地，也可以在通过网络连接的其他机器上。
+  - ORB截获这一调用，同时负责查找实现服务的对象并向其传递参数、调用方法并返回最终结果。
+- **CORBA**
+  - 公共对象请求代理体系结构
+  - 对象管理组织(OMG)提出
+  - CORBA规范使得面向对象的软件在分布、异构环境下实现可重用、可移植和互操作。
+- RMI
+  - 远程方法调用
+  - 支持JAVA 平台
+- COM/DCOM
+  - (分布式)组件对象模型
+  - 支持Windows 平台
+
+![image-20211124204402692](中间件与框架.assets/image-20211124204402692.png)
+
+### SQL
+
+- 面向SQL的数据访问中间件)
+  - 应用系统<——>数据库服务器
+- ODBC
+  - Open Data Base Connectivity开放数据库互连
+- JDBC
+  - Java Data Base Connectivity
+  - Java数据库互连
+
+![image-20211124204529573](中间件与框架.assets/image-20211124204529573.png)
+
+### TP Monitor
+
+- Transaction processing (TP) monitors (**事务处理监控器**)
+  - 负责控制事务性应用系统以事务的方式执行业务逻辑或数据更新
+
+![image-20211124204625635](中间件与框架.assets/image-20211124204625635.png)
+
+### 应用服务器和企业服务总线
+
+- Application servers (应用服务器)
+  - Software installed on a computer to facilitate the serving (running) of other applications.  (对其他应用系统提供支持的软件)
+- Enterprise Service Bus (企业服务总线)
+  - An abstraction layer on top of an Enterprise Messaging System.  (SOA的基础设施)
+
+### 优点和缺陷
+
+> 优点
+
+- 应用之间的连接
+- 隐藏分布性
+- 隐藏异构性
+
+>缺陷
+
+- 导致各应用系统依赖于特定的中间件厂
+- 分层导致性能下降
+
+## 应用服务器
+
+> 三层C/S结构中的应用服务器
+
+![image-20211124204920308](中间件与框架.assets/image-20211124204920308.png)
+
+
+
+> 应用服务器是一种中间件
+
+应用服务器：用于运行特定软件应用的服务器
+
+- 是一种软件引擎，向客户端提供可运行的应用程序
+- 负责执行这些应用的大部分业务逻辑和数据访问逻辑 
+
+> 应用服务器的功能
+
+- 基本功能：作为3层C/S或B/S结构中的功能性中间件层
+  - 负责驻留应用程序业务逻辑
+
+![image-20211124205108347](中间件与框架.assets/image-20211124205108347.png)
+
+- **其他功能：作为复杂应用系统中的非功能性中间件——提供系统运行时的性能保障**
+  - Data and code integrity (数据和代码的完整性) 
+  - Centralized configuration  (中心化配置)
+  - Location Transparency (位置透明性)
+  - Security  (安全性)
+  - Transaction (事务管理)
+  - Messaging (消息管理)
+  - Naming (命名管理)
+  - Reliable and Scalability  (可靠性和伸缩性) : e.g., pooling (池) , cluster (集群)、
+  - Availability (可用性)
+  - Interoperability (互操作性)
+
+## 软件框架(Framework)
+
+> 框架是什么？
+
+- **框架(Framework)**：可实例化的、部分完成的软件系统或子系统，它为一组系统或子系统定义了统一的**体系结构(architecture)**，并提供了构造系统的基本构造块(building blocks)，还为实现具体功能定义了扩展点(extending points)。
+- 框架实现了体系结构级别的复用。 
+
+![image-20211124205315182](中间件与框架.assets/image-20211124205315182.png)
+
+### Struts：J2EE MVC Model 2的一种典型实现
+
+- Struts：Apache/Jakarta项目组的一个Open Source项目，它采用MVC模式，使用JSP+Servlet实现，能够很好地帮助java开发者利用J2EE开发面向对象的Web应用。
+- 应用Structs，开发人员不用再自己编码实现全套MVC模式，极大的节省了开发时间，也提高了开发质量。
+- web.xml：配置所有web应用程序，Web容器在启动的时候从该文件中读取配置信息，根据它来装载和配置web应用。
+  - 配置ActionServlet，指定action及其url-pattern，声明ActionServlet的初始化参数
+  - 配置欢迎使用清单 
+  - 配置错误处理 
+  - 配置Struts标签库
+- struts-config.xml：struts专用配置文件，struts应用启动的时候会把信息读取到内存中；
+  - ＜data-sources＞：用来配置应用所需要的数据源 
+  - ＜form-beans＞：用来配置多个ActionForm 
+  - ＜global-exception＞：用于配置异常处理 
+  - ＜global-forwards＞：用来声明全局转发，用于把一个逻辑名映射到特定的URL 
+  - ＜action-mapping＞：包含一个或者N个＜action＞元素,描述了从特定的请求路径到响应的Action的映射 
+
+> Structs的优缺点
+
+优点
+
+- 诞生时间早，用户多
+- 开放源码
+- 标记库(tag lib)
+- MVC实现样例
+
+缺点
+
+- 对开发者来说，需要自己书写MVC中的“C”，需要自己将多个JavaBean中包含的基本object的操集成在一起，形成复杂的服务。
+- 开发者自行书写的代码，不得不依赖于structs框架本身的API(例如你的controller不得不从structs的ActionServlet继承)。
+
+### Spring：J2EE + AOP + IOC + DAO + ORM +MVC
+
+- Spring：基于MVC的开源J2EE框架
+- 三大优势特征：
+  - 依赖反转(Dependency Injection or Inversion of Control, IOC)
+  - 面向方面编程(Aspect-Oriented Programming, AOP)
+  - 与J2EE第三方开放标准的集成(例如Structs, Hibernate等)
+
+#### Spring之依赖反转(IOC)
+
+- IOC的基本思想：不创建对象，但是描述创建它们的方式。在代码中不直接与对象和服务连接，但在配置文件中描述哪一个组件需要哪一项服务，Spring容器负责将这些联系在一起。 
+- IOC是工厂模式的升华，可以把IOC看作是一个大工厂，只不过这个大工厂里要生成的对象都是在XML文件中给出定义的，然后利用Java的“反射”编程，根据XML中给出的类名生成相应的对象。
+- 从实现来看，IOC是把以前在工厂方法里写死的对象生成代码，改变为由XML文件来定义，也就是把工厂和对象生成这两者独立分隔开来，目的就是提高灵活性和可维护性。
+
+#### Spring之面向方面的编程(AOP)
+
+- 面向方面的编程(AOP)：允许程序员对横切关注点(即大量应用程序所需要的通用功能，例如日志和事务管理)进行模块化。
+- AOP的核心构造是“方面”(aspect)，它将那些影响多个类的行为封装到可重用的模块中。
+- 例如：
+  - 在传统编程模式中，要将日志记录语句放在所有Java类中才能实现日志功能。
+  - 在AOP方式中，可以将日志服务模块化，并以声明的方式将它们应用到需要日志的组件上。优势就是 Java 类不需要知道日志服务的存在，也不需要考虑相关的代码。
+- 所以，用Spring AOP编写的应用程序代码是松散耦合的。
+
+#### Hibernate：Object-Relation Mapping in J2EE
+
+- Hibernate是一个开放源代码的对象关系映射框架，它对JDBC进行了非常轻量级的对象封装，使得 Java程序员可以随心所欲的使用对象编程思维来操纵数据库。
+- 开发J2EE程序的时候，无需考虑后台的关系数据存储，Hibernate通过配置完成Java class与JDBC之间的连接。
+- Hibernate通过基于XML的配置文件来定义映射关系：
+
+![image-20211124210214190](中间件与框架.assets/image-20211124210214190.png)
+
+## 讨论题
+
+> 什么是中间件？主要有哪些类型的中间件？
+
+是一种应用于分布式系统的基础软件，位于应用与操作系统、数据库之间，为上层应用软件提供开发、运行和集成的平台。中间件解决了异构网络环境下软件互联和互操作等共性问题。
+
+主要的中间件有：
+
+- 远程过程调用中间件（RPC）
+- 消息中间件（MO）
+- 对象请求代理中间件（ORB）
+- 数据访问中间件（DA）
+- 交易中间件 （DTP）
+- 应用服务器
+- 企业服务总线

src/university/README.md

@@ -0,0 +1,5 @@
+<div style="color:#16b0ff;font-size:50px;font-weight: 900;text-shadow: 5px 5px 10px var(--theme-color);font-family: 'Comic Sans MS';">University</div>
+
+<span style="color:#16b0ff;font-size:20px;font-weight: 900;font-family: 'Comic Sans MS';">Introduction</span>：大学课程笔记！
+
+## 🚀点击左侧菜单栏开始吧！

src/university/_sidebar.md

@@ -0,0 +1,9 @@
+* 🏁 软件体系结构
+    * [✍ 概述](src/university/1 "概述")  
+    * [✍ 建模](src/university/2 "建模")
+    * [✍ 风格](src/university/3 "风格")
+    * [✍ 层次体系结构](src/university/4 "层次体系结构")
+    * [✍ CS和BS体系结构](src/university/5 "CS和BS体系结构")
+    * [✍ 其它体系结构](src/university/6 "其它体系结构")
+    * [✍ 面向服务体系结构](src/university/7 "面向服务体系结构")
+    * [✍ 中间件和框架](src/university/8 "中间件和框架")