软件体系结构总结强烈

第一章：1、软件体系结构的定义

国内普遍看法：

体系结构=构件+连接件+约束

2、软件体系结构涉及哪几种结构：

1、模块结构（Module）

系统如何被构造为一组代码或数据单元的决策

2、构件和连接件结构（Component-And-Connector，C&C）

系统如何被设计为一组具有运行时行为（构件）和交互（连接件）的元素

3、分配结构（Allocation）

展示如何将来自于模块结构或C&C结构的单元映射到非软件结构（硬件、开发组和文件系统）

3、视图视点模型

视点（View point）

ISO/IEC 42010:2007 (IEEE-Std-1471-2000)中规定：视点是一个有关单个视图的规格说明。

视图是基于某一视点对整个系统的一种表达。一个视图可由一个或多个架构模型组成

架构模型

架构意义上的图及其文字描述（如软件架构结构图）

视图模型

一个视图是关于整个系统某一方面的表达，一个视图模型则是指一组用来构建

4、软件体系结构核心原模型

1、构件是具有某种功能的可复用的软件结构单元，表示了系统中主要的计算元素和数据存储。

2.连接件(Connector)：表示构件之间的交互并实现构件

之间的连接

特性：1)方向性2)角色3)激发性4)响应特征

第二章

1、软件功能需求、质量属性需求、约束分别对软件架构产生的影响

功能性需求：系统必须实现的功能，以及系统在运行时接收外部激励时所做出的行为或响应。

质量属性需求：这些需求对功能或整个产品的质量描述。

约束：一种零度自由的设计决策，如使用特定的编程语言。

质量原意是指好的程度，与目标吻合的程度，在软件工程领域，目标自然就是需求。

对任何系统而言，能按照功能需求正确执行应是对其最基本的要求。

正确性是指软件按照需求正确执行任务的能力，这无疑是第一重要的软件质量属性。质量属性的优劣程度反映了设计是否成功以及软件系统的整体质量。

系统或软件架构的相关视图的集合，这样一组从不同视角表达系统的视图组合在一起构成对系统比较完整的表达

2、质量属性

3、系统非功能性需求？包括哪些质量属性

非功能性需求：用户对软件质量属性、运行环境、资源约束、外部接口等方面的要求或期望，包括：

(1) 性能需求：用户在软件响应速度、结果精度、运行时资源消耗量等方面的要求。

(2) 可靠性需求：用户在软件失效的频率、严重程度、易恢复性，以及故障可预测性等方面的要求。

(3) 易用性需求：用户在界面的易用性、美观性，以及对面向用户的文档和培训资料等方面的要求。

(4) 安全性需求：用户在身份认证、授权控制、私密性等方面的要求

(5) 外部接口：用户对待开发软件系统与其他软件系统或硬件设备之间的接口的要求。

(6) 可保障性（supportable）需求：用户在软件可配置性、可扩展性、可维护性、可移植性等方面的要求。

4. 可靠性可用性区别

可靠性通常低于可用性，因为可靠性要求系统在[0,t]的整个时间段内需正常（注意是“连续”!）运行；

可用性大于或等于可靠性，对于可用性，要求就没有那么高，系统可以发生故障，然后在时间段[0,t]内修复。修复以后，只要系统能够正常运行，它仍然计入系统的可用性。

计算：

第三章

1、软件架构风格(是一个面向一类给定环境的架构设计决策的集合，这些通用的设

计决策形成了一种特定的模式，为一族系统提供粗粒度的抽象框架。

每一个软件系统都有其占主导地位的软件架构风格。

“从软件中来，到软件中去”

架构风格通过为常见的问题提供解决方案，增强了对问题的分解能力、提升了设

计重用的水平。

)

1）独立构建风格：（这种风格的主要特点是：事件的触发者并不知道哪些构件会被这些事件影响，相互保持独立。

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

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

）

进程通信体系结构风格：构件是独立的进程，连接件是消息传递。消息传递通常用来实现进程之间的同步和对共享资源的互斥操作

典型例子：客户-服务器架构，其中服务器通常用来为一个或多个客户端提供数据服务，客户端则用来向服务器发出请求，针对这些请求服务器通过同步或异步方式进行请求响应。

基于事件的隐式调用风格

：构件不直接调用一个过程，而是触发或广播一个或多个

事件。

•系统中的其它构件中的过程在一个或多个事件中注册。

•当一个事件被触发/发布，系统自动调用在这个事件中注

册的所有过程。

•这样，一个事件的触发就导致了另一模块中的过程的调

用。

•这种系统，称为基于事件的系统(Event-based system)，

采用隐式调用(Implicit invocation)的方式。

2）层次风格优点：

通过把逻辑层分布到多个物理层中，可以提高可伸缩性、容错性

（fault tolerance）和性能。

可重用性。每一层提供的功能都是独立的和定义良好的。不同层之间有明确的接口，在解决一个新的问题时，使开发人员更容易地重用一个已有的层。

可测试性。由于有了明确定义的接口，以及可以在层接口的不同实现之间实现按需切换，可测试性明显增强了。

标准化。清晰定义并且广泛接受的抽象层次能够促进实现标准化的任务和接口开发，同样接口的不同实现能够互换使用。

缺点：

1)并不是每个系统都可以很容易地划分为分层的模式，甚至即使一个系统的逻辑结构是层次化的，出于对系统性能的考虑，系统设计师不得不把一些低级或高级的功能综合起来；

2)效率的降低：

由分层风格构成的系统，运行效率往往低于整体结构。

在上层中的服务如果有很多依赖于最底层，则相关的数据必须通过一些中间层的若干次转化，才能传到；

3)很难找到合适的、正确的层次抽象方法：

层数太少，分层不能完全发挥这种风格的可复用性、可修改性和可移植性上的潜力。

层数过多，则引入不必要的复杂性和层间隔离冗余以及层间传输开销。

3) 虚拟机风格：

不管何种类别的虚拟机，本质上都是在高层次抽象的

用户与低层次抽象的OS/硬件之间建立一道屏障。

但是，如何把上层应用的请求映射到下层OS/硬件系

统的执行？

•解释器(Interpreter)

•基于规则的系统(Rule-based System)

解释器：是一个用来执行其他程序的程序.

基本构件：

•解释器引擎