软件体系结构复习要点

软件体系结构的定义： 软件体系结构 = 组件 + 连接件 + 约束

➢组件：具有某种功能的可重用的软件模块单元，表示了系统中主要的计算单元和数据存储。

➢连接件：表示了组件之间的交互，简单的连接件有：管道（pipe）、过程调用 （procedure-call）、事件广播（event broadcast）等。复杂的连接件有：客户－服务器（client-server）通信协议，数据库和应用之间SQL连接等。

➢约束：表示了组件和连接件的拓扑逻辑和约束（constraint）

软件体系结构风格定义：描述特定领域中软件系统家族的组织方式的惯用模式，反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。

数据流体系结构风格-基本构件：数据处理；连接件：数据流

数据流体系结构风格：1、数据自由流动；2、近似线性数据流；3、在限度内的循环数据流

典型数据流风格：

1、批处理体系结构风格（每个处 理步骤是一个独立的程序、每一步必须在前一步结束后才能开始、数据必须是完整的，以整体的方式传递）

2、管道-过滤器体系结构风格（每个处理步骤(过滤器)都有一组输入和输出，过滤器从管道中读取输入的数据流，经过内部处理，然后产生输出数据流并写入管道中）

(构件：过滤器，处理数据流；连接件：管道，连接一个源和一个目的过滤器)

注意：递增的读取和消费数据流，数据到来时便被处理，不是收集然后处理，即在输入被完全消费之前，输出便产生了。

过滤器对数据流的五种变换类型：

[if !supportLists]l  [endif]通过计算和增加信息来丰富数据

[if !supportLists]l  [endif]通过浓缩和删减来精炼数据

[if !supportLists]l  [endif]通过改变数据表现方式来转化数据

[if !supportLists]l  [endif]将一个数据流分解为多个数据

[if !supportLists]l  [endif]将多个数据流合并为一个数据流

不同的管道中流动的数据流，可能具有不同的数据格式，数据在流过每一个过滤器时，被过滤器进行了丰富、精练、转换、融合、分解等操作，因而发生了变化。

对比：

批处理管道-过滤器

整体传递数据增量

构件粒度较大构件粒度较小

延迟高，实时性差实时性好

无并发可并发

面向对象体系结构的元素：

[if !supportLists]1、[endif]封装：限制对某些信息的访问

[if !supportLists]2、[endif]交互：通过过程调用或类似的协议

[if !supportLists]3、[endif]多态：在运行时选择具体的操作

[if !supportLists]4、[endif]继承：对共享的功能保持唯一的接口

[if !supportLists]5、[endif]复用和维护：利用封装和聚合提高生产力

软件体系结构层次风格特点：

[if !supportLists]1、[endif]每层为上一层提供服务，使用下一层的服务，只能见到与自己邻接的层（适当时候(必不得已的时候)，可以允许一定的越层操作）

[if !supportLists]2、[endif]大的问题分解为若干个渐进的小问题，逐步解决，隐藏了很多复杂度、

[if !supportLists]3、[endif]修改一层，最多影响两层，而通常只能影响上层。接口稳固，则谁都不影响

[if !supportLists]4、[endif]上层必须知道下层的身份，不能调整层次之间的顺序

[if !supportLists]5、[endif]层层相调，影响性能

客户端/服务器风格：

• 两层C/S结构

C/S软件体系结构是基于资源不对等，且为实现共享而提出的

C/S体系结构有三个主要组成部分：数据库服务器、客户应用程序和网络

服务器（后台）负责数据管理，客户机（前台）完成与用户的交互任务。“胖 客户机，瘦服务器”

• 三层C/S结构

       增加了一个应用服务器。

       整个应用逻辑驻留在应用服务器上，只有表示层存在于客 户机上：“瘦客户机”

       应用功能分为表示层、功能层、数据层三层

[if !supportLists]1、[endif]表示层是应用的用户接口部分。通常使用图形用户界面（通常只有表示层配置在客户机中）

[if !supportLists]2、[endif]功能层是应用的主体，实现具体的业务处理逻辑

[if !supportLists]3、[endif]数据层是数据库管理系统

• B/S结构（浏览器/服务器风格）

B/S体系结构是三层C/S体系结构的特例，使用标准http/https协议，客户端有http浏览器即可

调用/返回风格总结：

• 主程序/子程序风格

单线程控制，划分为若干处理步骤

功能模块：把步骤集成至模块中

• 抽象数据类型（ADT）

操作和数据绑定在一起，隐藏实现和其他秘密

• 面向对象

方法（动态绑定），多态（子类），重用（继承）

对象活动于不同的进程/线程（分布式对象）

• CS结构、分层风格

• 组件

多个接口，二进制兼容，高级中间件

数据为中心的体系结构风格：以数据为中心的样式体系结构涉及一种共享数据源的信息传递方法。

[if !supportLists]1、[endif]注册表：存在着系统的所有硬件和软件配置信息，注册表信息影响或控制系统/应用软件的行为，将所有.ini文件集中起来，形成共享仓库，为系统运行起到了集中的资源配置管理和控制调度的作用。

[if !supportLists]2、[endif]剪贴板：一个用来进行短时间的数据存储并在文档/应用之间进行数据传递和交换的软件程序。

仓库体系结构风格：仓库是存储和维护数据的中心场所

典型应用场合：数据库

仓库风格实例：Eclipse

传统编译器结构：批处理/管道-过滤器

传统带符号表编译器结构：被多次使用的信息提取出来，形成共享的符号表

现代的规范编译器结构：出现了带符号表与语法树的编译器。

黑板体系结构风格：

黑板结构：中心数据结构的当前状态触发并选择需要执行的过程

黑板：保存求解状态

[if !vml]

[endif]

黑板数据结构：

[if !supportLists]l  [endif]全局数据库，用来存储数据、传递信息，包含解域的全部状态

知识源是描述某个独立领域问题的知识及其处理方法的知识库，其分别存放且相互独立的，他们通过黑板进行通讯，合作求出问题的解，通常知识源具有“条件-动作”的形式。当条件满足时，知识源被触发，其动作部分增加或修改黑板上得内容。

➢待解决的问题被分为若干个子问题，每个子问题由一个独立的知识源加以计算。

➢知识源包含独立的领域知识。

➢知识源执行计算后会更新黑板里的数据状态。

➢多个知识源之间只能通过黑板交换知识（通过对黑板的读写操作来完成交换）。

控制器：根据当前状态 决定知识源的执行次序

应用：人工智能、自然语言处理、语音处理、模式识别、图像处 理等；

解释型语言：

VB、Javascript、VBScript、HTML、Java字节码、Matlab

脚本、配置文件

事件系统

隐式调用： 

主要特点

✓事件的触发者并不知道哪些构件会被这些事件影响，相互保持独立。

✓不能假定构件的处理顺序，甚至不知道哪些过程会被调用。

✓各个构件之间彼此之间无连接关系，各自独立存在，通过对事件的发布和注册实现关联。

[if !vml]

[endif]

特点描述

分离的交互事件发布者不会意识到事件订阅者的存在

一对多通信采用发布/订阅消息传递，一个特定事件可以影响多个订阅者

基于事件的触发器由事件触发过程调用

异步支持异步操作

事件系统派遣机制——调度机制

[if !supportLists]l  [endif]无独立调度模块的事件系统（被观察者/观察者）

每一个模块都允许其他模块向自己 所能发送的某些消息表明兴趣，当某一模块发出某一事件时，它自动将这些事件发布给那些曾经向自己 注册过此事件的模块

[if !supportLists]l  [endif]有独立事件派遣模块的事件系统

[if !supportLists]Ø  [endif]事件派遣模块是负责接收到来的事件并派遣它们到其它模块。

[if !supportLists]Ø  [endif]怎样派遣？

➢全广播式：派遣模块将事件广播到所有的模块，但只有感兴趣的模块才去取出事件并触发自身的行为；

➢选择广播式：派遣模块将事件送到那些已经注册的模块中。

选择广播式的两种策略：基于事件被执行的方式

[if !supportLists]²  [endif]点对点模式：基于消息队列（消息只能够被唯一的消费者所消费，消费之后即从队列中删除）

[if !supportLists]²  [endif]发布-订阅模式（一个事件可以被多个订阅者消费）

[if !vml]

[endif]

软件体系结构由一定形式的结构化元素组成，即是构件的集合。包括处理构件、数据构件和连接构件。处理构件负责加工数据，数据构件代表被加工的信息，连接构件则负责组合连接不同的构件。

作用：描述软件体系结构是理解体系结构设计思想、交流如何使用体系结构指导系统构建的基础。

建立描述文档的基本原则：

◆ 1.从读者的角度写。

◆ 2.避免不必要的重复。

◆ 3.避免歧义。

◆ 4.使用标准组织结构。

◆ 5.记录理由。

◆ 6.保持文档时效性但不是频繁更新 （有限的稳定性）。

◆ 7.审查文档是否符合需求

视图：

基于视图的体系结构建模规范：

◆ 架构描述选择一个或多个视点。 ◆ 每个视点包含了一个或多个相关的视图 ◆ 视图由一个或多个模型组成，并集中一个视点。 ◆ 架构描述由一个或多个视图组成。

4+1模型（uml）

◼ 逻辑视图：支持行为要求。关键抽象，是对象或对象类。

             通常包括类图，对象图，状态图和协作图。

◼ 过程视图：解决并发和分发。将线程映射到对象。

            通常包含活动图。

◼ 开发视图：组织软件模块，库，子系统，开发单元。

            通常包含包图和组件图。

◼ 物理视图：将其他元素映射到处理和通信节点。

             通常包含部署图。

◼ 用例视图：将其他视图映射到重要的用例（场景）对体系结构加以说明

             通常包含用例图，描述和概述图。

用例图：用于显示若干角色以及这些角色与系统提供的用例之间的连接关系。

类图：表示系统中的类和类与类之间的关系，它是对系统静态结构的描述。

对象图：是某个时间点系统中对象的快照，因为它显示的是实例而不是类，所以通常称为实例图。

状态图：是描述类的对象所有可能的状态以及事件发生时状态的转移条件。通常，状态图是对类图的补充。（一个对象）

协作图（通信图）：是一种交互图，强调的是发送和接收消息的对象之间的组织结构。一个协作图显示了一系列的对象及对象之间的联系以及对象间发送和接收的消息。（多个对象）

序列图：是对象交互的一种表现方式。主要用于按照交互发生的一系列顺序，显示对象之间的这些交互。（多个对象）

活动图：描述满足用例要求所要进行的活动以及活动间的约束关系，有利于识别并行活动。

包图：包是在UML中用类似于文件夹的符号表示的模型元素的组合，允许从UML 中获取任何结构，并将其元素分组到更高级别的单元中。

组件图：描述代码构件的物理结构及各构件之间的依赖关系。将系统划分为组件并希望通过接口或组件细分为较低级别的结构来显示其相互关系。

部署图：定义系统中软硬件的物理体系结构。描述了一个运行时的硬件结点，以及在这些结点上运行的软件组件的静态视图。显示了系统的硬件，安装在硬件上的软件，以及用于连接异构的机器之间的中间件。

复合结构：是UML 2的新增功能。即能够分层地将类分解为内部结构。这可以将一个复杂的对象分解为多个部分。

交互概述图：是活动图和序列图的结合。可以将其视为活动图，其中将活动替换为小的顺序图，或者将其视为用活动图表示法分解以显示控制流的顺序图。

时序图：是交互图的另一种形式，其中重点在于时序约束。一般针对单个对象或多个对象描述。对显示不同对象的状态变化之间的时序约束很有用。

质量属性：

➢可用性

➢可修改性

➢性能

➢安全性

➢可测试性

➢易用性

质量属性场景的6个组成部分：

➢刺激源：谁造成的刺激

➢刺激：一个影响系统的情况

➢制品：系统被影响的部分

➢环境：刺激发生时系统所处的状态

➢响应：刺激所产生的结果

➢响应衡量指标：如何评估响应

[if !supportLists]1、[endif]可用性：当用户使用系统时，系统可用的概率（提前确定的停机维护不计入）

可用性的关注点 ➢故障

提升可用性的策略：故障检测、故障恢复、故障避免

[if !supportLists]2、[endif]可修改性：

可修改性的关注点 ➢修改的成本

提升可修改性的策略：限制修改范围、延迟绑定时间

[if !supportLists]3、[endif]性能：

性能的关注点 ➢处理响应的速度

提升性能的策略：资源的需求、资源的管理、资源的仲裁

[if !supportLists]4、[endif]安全性：（✓不可否认性✓私密性✓完整性✓保证性✓可用性✓审计（为了重建））

安全性的关注点 ➢尽量避免攻击对系统的影响

提升安全性的策略：抵抗攻击、检测攻击、从攻击中恢复

[if !supportLists]5、[endif]可测试性：

可测试性的关注点 ➢让bug容易被测试出来

提升可测试性的策略：黑盒、白盒

[if !supportLists]6、[endif]易用性：

关注点 ✓让用户使用软件的难度降低

提升易用性的策略：运行时策略、设计时策略

KWIC：上下文关键字

ATAM：软件体系结构评估方法

ATAM通过理解体系结构方法来分析体系结构，评估过程分9个步骤：

1、描述ATAM方法：即评估小组负责人向参加会议的风险承担者介绍ATAM评估方法，让大家清楚接下来要做什么，每个人的角色和任务。

2、描述业务动机：项目经理从业务角度介绍系统的概况，一般包括业务环境，背景，业务约束条件，技术约束，质量属性需求等内容。

3、描述体系结构：首席设计师或设计小组对体系结构进行详略适当的介绍。包括技术约束，与本统交互的其他系统，用以满足质量属性要求的体系结构方法（功能，模块，进程，硬件）。4、确定体系结构方法：由设计师确定体系结构方法，由分析小组捕获，但不进行分析。

5、生成质量属性效用树：评估小组，设计小组，管理人员和客户代表一起确定系统最重要的质量属性目标，并对这些目标设置优先级和细化。

6、分析体系结构方法

7、讨论分级场景

8、分析体系结构方法

9、描述评估结果

24种设计模式

[if !supportLists]1、          [endif]创建型模式：封装对象创建的变化

[if !supportLists]l  [endif]简单工厂模式（静态工厂方法模式）：通过专门定义一个类来负责创建其他类的实例，被创建的实例通常都具有共同的父类。

模式中包含的角色及其职责：工厂角色（简单工厂模式的核心，它负责实现创建所有实例的内部逻辑。工厂类可以被外界直接调用，创建所需的产品对象）；抽象角色（简单工厂模式所创建的所有对象的父类，它负责描述所有实例所共有的公共接口）；具体产品角色（简单工厂模式所创建的具体实例对象）

[if !supportLists]l  [endif]工厂方法模式（多态工厂模式）：定义一个创建产品对象的工厂接口，将实际创建工作推迟到子类当中

模式中包含的角色及其职责：抽象工厂模式（工厂方法模式的核心，任何工厂类都必须实现这个接口）；具体工厂角色（具体工厂类是抽象工厂的一个实现，负责实例化产品对象）；抽象角色（工厂方法模式所创建的所有对象的父类，它负责描述所有实例所共有的公共接口）；具体产品角色（工厂方法模式所创建的具体实例对象）

[if !supportLists]l  [endif]抽象工厂模式：抽象工厂模式可以向客户端提供一个接口，使得客户端在不必指定产品的具体类型的情况下，能够创建多个产品族的产品对象。

模式中包含的角色及其职责：抽象工厂模式（抽象工厂模式的核心，包含对多个产品结构的声明，任何工厂类都必须实现这个接口）；具体工厂角色（具体工厂类是抽象工厂的一个实现，负责实例化某个产品族中的产品对象）；抽象角色（抽象模式所创建的所有对象的父类，它负责描述所有实例所共有的公共接口）；具体产品角色（抽象模式所创建的具体实例对象）

[if !supportLists]l  [endif]单例模式：保证一个类只有一个实例存在，同时提供能对该实例加以访问的全局访问方法

实现：1.饿汉式。2.懒汉式。3.双重检查。

[if !supportLists]l  [endif]原型模式：由原型对象自身创建目标对象，目标对象是原型对象的一个克隆。

[if !supportLists]2、          [endif]结构型模式：关注的是对象之间组合的方式

[if !supportLists]l  [endif]装饰模式(包装模式)：通过一种对客户端透明的方式来扩展对象的功能

模式中包含的角色及其职责：抽象组件角色（一个抽象接口，是被装饰类和装饰类的父接口）；具体组件角色（为抽象组件的实现类）；抽象装饰角色（包含一个组件的引用，并定义了与抽象组件一致的接口）；具体装饰角色（为抽象装饰角色的实现类。负责具体的装饰）

[if !supportLists]l  [endif]代理模式：为其他对象提供一种代理（Proxy）以控制对这个对象的访问

模式中包含的角色及其职责：subject（真实主题与代理主题的共同接口）；RealSubject（定义了代理角色所代表的真实对象）；Proxy（含有对真实主题角色的引用，代理角色通常在将客户端调用传递给真是主题对象之前或者之后执行某些操作，而不是单纯返回真实的对象）

[if !supportLists]l  [endif]外观模式：

模式中包含的角色及其职责：Façade（为调用方定义简单的调用接口）；Clients（调用者。通过Facade接口调用提供某功能的内部类群）；Packages（功能提供者。指提供功能的类群（模块或子系统））

[if !supportLists]l  [endif]组合模式：通过递归手段来构造树形的对象结构，并可以通过一个对象来访问整个对象树

模式中包含的角色及其职责：Component（为所有的对象定义统一的接口（公共属性，行为等的定义）提供管理子节点对象的接口方法）；Leaf（树形结构的叶节点）；Component的实现子类；Composite（树形结构的枝节点）；Component的实现子类

[if !supportLists]l  [endif]桥接模式：基于类的最小设计原则，通过使用封装，聚合以及继承等行为来让不同的类承担不同的责任。它的主要特点是把抽象与行为实现分离开来，从而可以保持各部分的独立性以及应对它们的功能扩展

    模式中包含的角色及其职责：Client（Bridge模式的使用者）；Abstraction（抽象类接口（接口或抽象类）维护对行为实现（Implementor）的引用）；Refined Abstraction（Abstraction子类）；Implementor（行为实现类接口 (Abstraction接口定义了基于Implementor接口的更高层次的操作)）；ConcreteImplementor（Implementor子类）

[if !supportLists]l  [endif]适配器模式：通过Adapter模式可以改变已有类（或外部类）的接口形式。

通过继承实现Adapter和通过委让实现Adapter

[if !supportLists]3、          [endif]行动模式：关注的是对象的行为

[if !supportLists]l  [endif]策略模式：对一系列的算法加以封装，为所有算法定义一个抽象的算法接口，并通过继承该抽象算法接口对所有的算法加以封装和实现

模式中包含的角色及其职责：Strategy（策略（算法）抽象）；ConcreteStrategy（各种策略（算法）的具体实现）；Context（策略的外部封装类，或者说策略的容器类。根据不同策略执行不同的行为。策略由外部环境决定）

[if !supportLists]l  [endif]观察者模式：当一个对象的状态发生变化时，能够自动通知其他关联对象，自动刷新对象状态

模式中包含的角色及其职责：Subject（被观察的对象。当需要被观察的状态发生变化时，需要通知队列中所有观察者对象。Subject需要维持（添加，删除，通知）一个观察者对象的队列列表）；ConcreteSubject（被观察者的具体实现。包含一些基本的属性状态及其他操作）；Observer（接口或抽象类。当Subject的状态发生变化时，Observer对象将通过一个callback函数得到通知）；ConcreteObserver（观察者的具体实现。得到通知后将完成一些具体的业务逻辑处理）

[if !supportLists]l  [endif]迭代模式：它把对容器中包含的内部对象的访问委让给外部类，使用Iterator（遍历）按顺序进行遍历访问的设计模式

使用条件：访问容器中包含的内部对象、按顺序访问

模式中包含的角色及其职责：Iterator（该接口必须定义实现迭代功能的最小定义方法集比如提供hasNext()和next()方法）；ConcreteIterator（迭代器接口Iterator的实现类）；Aggregate容器接口（定义基本功能以及提供类似Iterator

iterator()的方法）；concreteAggregate（容器接口的实现类。必须实现Iterator

iterator()方法）

[if !supportLists]l  [endif]模板方法模式：把具有特定步骤算法中的某些必要的处理委让给抽象方法，通过子类继承对抽象方法的不同实现改变整个算法的行为

模式中包含的角色及其职责：AbstractClass（抽象类的父类）；ConcreteClass（具体的实现子类）；templateMethod()（模板方法）；method1()与method2()（具体步骤方法） 

[if !supportLists]l  [endif]状态模式：允许通过改变对象的内部状态而改变对象的行为，这个对象表现得就好像修改了它的类一样

模式中包含的角色及其职责：Context（用户对象，拥有一个State类型的成员，以标识对象的当前状态）；State（接口或基类封装与Context的特定状态相关的行为）；ConcreteState（接口实现类或子类实现了一个与Context某个状态相关的行为）

[if !supportLists]l  [endif]命令模式：封装了对目标对象的调用行为以及调用参数

模式中包含的角色及其职责：Command（Command抽象类）；ConcreteCommand（Command的具体实现类）；Receiver（需要被调用的目标对象）；Invorker（通过Invorker 执行Command对象）

OO设计原则：

[if !supportLists]•    [endif]单一职责原则（SRP）

[if !supportLists]•    [endif]开放封闭原则（OCP）：类应该对修改关闭，对扩展打开

[if !supportLists]•    [endif]里氏替换原则（LSP）：子类必须能够替换基类

[if !supportLists]•    [endif]依赖倒置原则（DIP）：高层模块不应该依赖于底层模块，二者都应该依赖于抽象

[if !supportLists]•    [endif]接口隔离原则（ISP）：不应该强迫客户程序依赖它们不需要使用的方法

设计模式是“封装变化”方法的最佳阐释。无论是创建型模式、结构型模式还是行为型模式，归根结底都是寻找软件中可能存在的“变化”，然后利用抽象的方式对这些变化进行封装。