软件体系结构期末复习(快速入门考试)

软件体系结构汇总总结 篇幅较长 耐心食用~~ 

第一章 基本概念

1.发展史

2.软件架构三要素(组成派)：组件 连接体 约束

3.软件架构是一系列重要决策的集合(决策派)

3.软件架构是科学和艺术(其他观点)等等

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

软件架构：

软件生命周期：项目规划，需求分析，软件设计，软件实现，测试和评估，维护与升级

瀑布式开发推迟风险的规避

迭代式开发促进风险规避

RUP以体系结构为核心

敏捷开发Scrum

迭代 循序渐进的方法进行软件开发。

项目规划 需求分析 软件设计 软件实现 软件测试和评估 运行，维护和升级

构件也叫组件

粒度是描述构件相对大小，规模，细节程度或关注程度的属性

原子构件：不再分解 eg：函数，数据结构

复合构件：对象  模块  原子＋其他复合构件

连接件单独独立存在的原因：

1.连接件可能要表达相当复杂的关系语义

2.复杂连接件的定义应当局部化 保证系统具有良好的结构

3.构件之间的关系会动态改变 需要封装在连接件中

4.分开的时候  就可以 构件只定义它的能力  而交互全权让连接件来做 独立和分工明确

视图和视点的区别

视图是某一视角或某一点看到了系统的某一测定方面 省略了与此方面无关的元素

(就是观测对象)

视点是有关单个视图的规格说明(观测点)

 

第二章 软件的质量属性(可度量 可测试的属性)

可靠性定义：产品在规定的条件下和规定的时间内，完成规定的功能的能力

QA （Quality Assurance）是非功能性需求

软件质量属性=设计design+实现+部署deploy

功能正确性是最基本的要求(第一重要软件质量属性)

设计时的质量属性(围绕7中场景元素 刺激源 制品 响应度量等  实例：超车)

概念完整性：开发的时候根据生命周期规划好 别乱整 及时沟通

可维护性：言简意赅

可重用性：言简意赅

运行时质量属性：

可用性：为解决  bug多  网络故障 升级太多 资源不正确使用

互操作性：为连接 外部系统(不同架构)和遗留系统

可管理性：

1. 系统配置：软件方便安装，部署，配置和集成
2. 系统优化：通过调整自身参数，属性等 适应外界变化
3. 系统诊断：定位问题 及时补救
4. 系统防护：应对攻击 修复恢复

性能(例如玩游戏的体验)：为解决客户端响应时间慢(ms高) 内存占比大(闪退) 服务器吞吐慢  网络负载大 资源管理不当

可靠性：软件缺陷(bug)->软件错误->软件故障

可伸缩性：随着软件投入使用 适应系统规模的增长能力

安全性：保护和防止恶意行为

系统质量属性：

可支持性：系统在不正常工作的情况下提供信息以确定和解决问题的能力

可测试性：言简意赅

用户质量属性：

易用性：用户体验为核心 用户期望啥 尽力实现 且做到易学习 易操作 易理解

例：我期望我一个大秒5个人 而且只点一下技能 

其他质量属性：

服务设计——用户体验设计的新趋势(内测)

第三章 风格

1.何为风格？

长时间实践 发现其具有良好的工艺可行性 性能 和实用性 可以拿来遵循和模仿(服用) 类似于开发中使用框架

2.软件架构风格

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

通过为常见问题提供解决方案

增强了对问题的分解能力 提升了设计重用的水平

3.数据流风格(数据到达就被激活 无数据的时候不工作)

基本构件：数据处理(输入端口读取数据 向输出端口写入数据)

连接件：数据流

拓扑结构：线性

单向 异步 有缓冲

  1.管道过滤器风格：

自来水处理 pipe-and-Filter结构

构件：过滤器 负责 处理步骤(源数据变换为目标数据)

连接件：管道 负责 数据传输(不同管道中流动的数据流，具有不同的数据格式)

(边收集边处理，伴随着收集，处理已经开始了)

   2.批处理风格：(下一步必须等上一步结束后才能开始  必须传送整体的数据)

构件：独立的应用程序

连接件：某种类型的媒介

3.二者异同

same：把任务分解成一系列固定顺序的计算单元，彼此只通过数据传递交互

different：

数据流风格优缺点：

4.过程调用风格

   1.主程序子程序风格

  

优点：很成功，可以用于大程序

缺点：程序太大，开发慢，维护测试难

   2.面向对象风格：

   系统被作为一堆对象来看待，每个对象(封装了数据和具体函数作用)都有自己的具体功能。

优点：易于维护，贴近生活，质量高，效率高，易于扩展

缺点：需要确立和管理大量的对象

          必须知道对象的身份

          继承复杂度很高

5.独立构件风格

   1.进程通信体系结构风格

管道，套接字socket，信号，信号量，共享内存

   2.基于事件的隐式调用风格

连接件：事件-事件绑定

事件：例：就是鼠标或键盘对窗口的组件进行交互发生的事情

事件源：能产生事件的对象：鼠标 键盘 按钮 文本框等

事件监听者：监听事件并处理(监听者是一个又一个对象，其中的类需要有实现相应功能的监听者接口或继承相应的适配类)

事件处理程序：例：Java中的接口和类 用来处理监听者需要处理的事件()

监听者处理方式：

 

关于显式调用和隐式调用：

显式调用：显式调用函数调用，调动过程和次序是固定的，预先设定的

隐式调用：被动的调用，构件持续和环境打交道，但不知道确切的交互次序

 

基于事件的隐式调用：

触发一个或多个事件，然后系统会调用这个事件所关联的所有过程，事件触发导致了过程的调用。

ps：为什么会称为“独立构件”风格？

1. 事件触发者并不知道哪些构件被自己影响了
2. 不知道构件的处理顺序
3. 各个构件之间没有确定的连接关系

事件系统的优缺点：

优点：支持交互，软件复用，事件并发，健壮(一个构件出错不影响其他构件)

缺点：不知道过程调用的顺序，系统的同步，验证和调试很困难，隐式调用增加不必要的消耗，响应速度慢。

6.层次风格

构件：各层次内部包含的构件

连接件：层间的交互协议

拓扑结构：分层

  

1.层次系统(像极了计网)

     下层为上层提供服务

    上层构件被看作下层构件的客户端

 2.和主程序-子程序风格的不同

3.分层模式(静态分层)

严格分层：此一层的构件只能和对等实体以及它紧邻的下面一层进行交互，一般来说只和同一层和低一层交互，为软件复用提供支持。

修改时简单 但是 效率低

松散分层：交互的方向不变，依然是上到下，但是可以跨层交互

优点：可以改善效率

缺点：由于各层之间有联系，因此在换出下层的时候，容易影响上层

4.分层系统中的交互模式(动态交互)

由上而下：

由下而上：

通常用来监视某些底层系统的状态变化

每个较低级别回调它上面的层的服务，直到达到最顶层

二者的区别

5.逻辑分层

软件中相关功能和组件分成独立的逻辑分组(逻辑层)

     用来处理不同类型的任务

逻辑层和物理层的映射(1对1 1对多 多对1)

表现层 业务层 数据层

层次风格的优点：抽象(分层次查看各部分的功能 容易把复杂的事物分解为简单) 隔离 可扩展(层次系统每层最多和上下两层交互 对任一功能的改变 最多影响其他两层) 可管理 性能好 可测试性 标准化

缺点：不好找划分依据 效率低

7.虚拟机风格(JVM)

虚拟机本质上是一种软件

高层次抽象的用户和低层次抽象的OS之间的屏障(用解释器把上层请求映射到下层)

8.客户/服务器风格C/S

基本构件：数据库服务器和客户机应用程序

连接件：经由网络的调用-返回机制或事件机制

上下逻辑分离的两部分

有两层的 有三层的 每两层之间形成一个CS关系

客户机：前端

服务器：后端

胖客户端：客户机业务逻辑多(服务器要求不高 灵活)

瘦客户端：客户端业务逻辑很少(客户端要求不高 服务器一炸全都炸)

2层C/S结构 适合轻量级的事务 小于100用户时 两层的C/S架构性能较好

3层C/S结构

三层！

表示层：GUI 不包含或包含一部分业务逻辑

功能层：接收表示层的数据并处理，处理数据层传来的数据，把结果输出给用户。

数据层：数据库 根据要求增删改查

三层的优点：极大的改善灵活性，支持用户更多，提高系统和软件的可维护性和可扩展性

各层可以并行开发，选择各自最适合的开发平台和语言

安全

三层的缺点：

各层通信效率要把持好，通信方法，通信频度和数据量

B/S浏览器服务器是三层C/S风格的一种实现方式

优点：没客户端 灵活 维护成本低 安全 真正意义的瘦客户端

缺点：相应速度较慢，一般以页面为单位提交数据，难以支持复杂的GUI

结合 发挥各自的优点

内外有别(内部CS 外部BS)

查改有别

更新都用CS

查询都用BS

第四章 UML视图（课本讲的比较详细 建议参考课本）

1.为什么要SA模型

研发的时候需要可视化/形式化

方便人的交流

2.形式化描述方法ADL

用数学的符号把系统分解为构件和连接件

优点：人机可读

缺：不直观 没有普遍的共识

线框描述法：

构件：矩形框

连接件：有向线段

优点：灵活直观

缺点：人好理解 工具不好理解 不完备 异构

逻辑视图：功能需求

开发视图：源文件 构件 代码(内部实现)

进程视图：系统运行的性能

物理视图：如何把软件映射到硬件上

用例视图(场景)：最终用户需要什么功能  系统应该做什么

第五章 软件测试架构

1.软件架构开发的核心过程

• 架构需求
• 架构设计
• 架构编
• 架构分析
• 架构实现
• 架构维护

 

2.几种常见的质量属性设计策略

可用性 可修改性 性能 安全性 易用性

3.模块设计和评估方法

模块的种类

设计的目标：

• 讲系统分解为一组模块
• 描述每一个模块之间的关系
• 识别依赖关系
• 决定模块之间的通讯机制
• 确定模块接口

那么怎么评价好坏呢？

 通过分解降低系统的复杂度 最小化开发成本 避免不良后果

模块化的核心技术在于分解

大化小 直到满足标准位置

优点：老生常谈 可扩展 可复用 可移植 保证分离性 降低复杂度等

4.模块化的五大评价准则

• 可分解性
• 可组合性
• 可理解性
• 可持续性 小的变化只影响一小部分模块 而不影响整个体系结构
• 出现异常之后的保护

5.模块化的五大规则

直接映射 模块结构尽量贴近现实世界的结构

少的接口 接口尽可能少的和其他模块通信

小的接口 接口交换的信息尽可能的少

显式接口 AB通讯时 应明显发生在A与B接口之间 让大家都知道 是你俩在说话

6.模块化设计的基本原则

7.软件体系结构评估(选择与折中)

SA评审：

(1)基于调查问卷的评审方式

专家打分

（2）基于场景的评审方式(考虑所有相关人员的质量要求)

ATAM(体系结构权衡分析方法)和SAAM(软件体系结构分析方法)

（3）基于度量的评审方式

从软件体系结构文档中获取度量信息并计算结果

优点：客观准确

缺点：很多质量属性没有具体的计算公式

☆ATAM评审方法

体系结构权衡分析方法 按照质量需求 评价体系结构

目标:按照质量需求评价体系结构设计

ATAM输入

1. 场景

1. 质量属性

性能 可修改性等等

1. 待评价的SA设计方案

中间结果：

1. 效用树

ATAM输出 

1. 风险 SA设计中存在潜在问题的决策
2. 非风险(可以提高质量) 在一个可信的假设之下被认为是“好”的决策
3. 关键点

SA中对实现特定的质量属性起到关键作用的

    构件或构件间连接关系

1. 折中点(加密级别)

影响到多个质量属性，是多个质量属性的关键点，而且是矛盾的

ATAM步骤

(总体上是两个阶段)

• 描述ATAM方法
• 描述商业动机
• 描述体系结构
• 确定体系结构方法
• 生成质量属性效用树
• 分析体系结构方法
• 讨论和分级场景
• 分析体系结构方法（是第六步的重复)
• 描述评估结果