软件体系结构笔记

软件体系结构 笔记

绪论

软件体系结构风格

1. 数据流体系结构风格
2. 调用/返回体系结构风格
3. 以数据为中心体系结构风格
4. 虚拟机体系结构风格
5. 事件系统体系结构风格

软件体系结构建模和文档化

质量属性及质量属性策略

1. 可用性
2. 性能
3. 可修改性
4. 安全性
5. 可测试性
6. 易用性

软件体系结构评估

一、绪论

软件体系结构的定义：

​ 软件体系结构是具有一定形式的结构化元素。

​ 软件体系结构分为component(组件)、connector(连接件)、constraint(约束)。

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

二、 各种软件体系结构风格

1、数据流体系结构风格 Data Flow Style

​ 数据到达即被激活，无数据时不工作

​ Component：数据处理

​ Connector：数据流

​

适用于数据 近线性数据流、在限度内的循环数据流。

不适用于数据自由流动 杂乱无章的情况。

批处理体系结构风格

1. 每个处理步骤是一个独立的程序
2. 每一步必须在前一步结束后才能开始
3. 数据必须完整，以整体的的方式传递

实例：基于Eclipse的代码重复检测工具

管道-过滤器体系结构风格

自来水处理

场景：数据源源不断产生，系统需要对这些数据进行若干处理

每个处理步骤（过滤器）都有一组输入和输出，过滤器从管道中读取输入数据流，经过内部处理，然后产生输出数据流并写入管道中。

component：filter过滤器——处理数据流

connector：pipe管道——连接一个源和一个目的过滤器

数据到来时便被处理，不是收集然后处理，即在输入被完全消费之前，输出便产生了。（与批处理不同）

实例：compiler（编译器）、Unix pipes（Unix管道）、Image processing（图像处理）、Signal processing（信号处理）

优点：构件具有良好的隐蔽性和高内聚、低耦合的特点。

​ 支持软件复用。

​ 系统维护和增强系统性能简单

​ 允许对吞吐量、死锁的分析

​ 支持并行执行

缺点：不适合处理交互的应用

​ 系统性能不高

2、调用/返回风格

特点：主程序/子程序风格 功能分解

​ 抽象数据类型（ADT）

​ 面向对象 封装、交互、多态、继承、复用和维护

​ 组件

主程序/子程序风格

模块分解

封装/信息隐藏

数据抽象/面向对象

风格变种：Client-server、Tiered(分层)、component

案例：操作系统、计算机网络

3、以数据为中心的体系结构风格 Data-centered Style

注册表(Windows Registry)

注册表中存在着系统的所有硬件和软件配置信息。

共享仓库

剪切板(Clipboard)

一个用来进行短时间的数据存储 并可以进行数据传递和交换的软件程序

仓库体系结构风格

仓库是存储和维护数据的中心场所

component：中心数据结构、若干对中心数据进行操作的独立构件

connector：仓库与独立构件之间的交互

两种交互机制：数据库方式、黑板结构

案例：数据处理、软件开发环境、数据库、编译器（符号表）

黑板体系结构风格

黑板、知识源、控制器

全局数据库 不同领域的知识

知识源：独立的求解程序

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

黑板：保存求解状态

案例：人工智能、自然语言处理、语音识别、模式识别、图像处理

4、虚拟机风格

Interpreter(解释器) rule-based system(规则系统)

优势：可测试、灵活性高、功能

劣势：效率低、软件测试多一层

案例：解释型语言、通信协议、用户输入

Drools体系结构

5、事件系统

event(事件)

隐式调用

特点：事件相互保持独立

​ 不能假定构件的处理顺序

​ 构件之间独立存在，通过对事件的发布和注册实现关联

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

支持异步

一个事件可以影响到多个订阅者

事件源、事件处理器、事件管理器

案例：调试点断点处理、美团用户点单

事件系统派遣机制：有无独立调度派遣模块的事件管理器

无独立调度模块的事件系统：被观察者/观察者

有独立事件派遣模块的事件系统：The dispatcher module事件派遣模块

全广播式（all broadcasting） 选择广播式（selected broadcasting）：点对点、发布-订阅

案例：“股票交易平台”的事件调度机制设计

三、软件体系结构描述方法

1、软件体系结构描述

软件体系结构描述文档原则：

1. 从读者角度写
2. 避免不必要的重复
3. 避免歧义
4. 使用标准组织结构
5. 记录理由
6. 保持文档时效性但不是频繁更新（有限的稳定性）
7. 审查文档是否符合需求

2、软件体系结构建模

视图：一组架构元素及其关联关系的表示

分解视图、使用视图、分层视图、类/泛化视图、进程视图、并发视图、共享数据视图、客户端-服务端视图、部署视图、实施视图、工作分配视图

软件应用程序体系结构的规范称为体系结构描述

4+1视图

逻辑视图、进程视图、物理视图、开发试图、场景视图

场景(用例)视图：从外部世界的角度描述正在建模的系统的功能，通常包含用例图，描述和概述图

逻辑视图：描述系统各部分的抽象描述，通常包括类图、对象图、状态图和协作图

过程视图：描述系统的进程 活动图

开发视图：描述系统的各部分如何被组织为模块和组件 包图、组件图

物理视图：描述如何将前三个视图中所述的系统设计实现为一组现实世界的实体。 部署图

用例图(Use Case)

用于表示若干角色以及这些角色与系统提供的用例之间的连接关系，代表了系统的外部视图

类图(Class Diagram)

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

对象图(Object Diagram)

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

状态图(State Diagram)

描述类的对象所有可能的状态以及事件发生时状态的转移条件。 类图的补充

协作（通信）图(Communication Diagram)

一种交互图，强调发送和接受消息的对象之间的组织结构

序列图(Sequence Diagram)

序列图是对象交互的一种表现方式 按照交互的发生的顺序，显示对象之间的这些交互

活动图(Activity Diagram)

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

包图(Package Diagram)

包是在UML中用类似文件夹的符号表示的模型元素的组合 包可用于UML的任何部分

组件图(Component Diagram)

组件图描述代码构建的物理结构及各构件之间的依赖关系

部署图(Deployment Diagram)

部署图定义系统中软硬件的物理体系结构

复合结构(Composite Structure)

UML2新增功能 分层的将类分解为内部结构 将一个复杂的对象分解为多个部分

交互概述图(Interaction Diagram)

活动图和序列图的结合

时序图(Timing Diagram)

交互图的另一种形式 重点在于时序约束

四、质量属性及质量属性策略

质量属性 (Quality Attribute)QA

属于非功能性需求，并不被功能所决定

不同的软件项目关注不同的质量属性

质量属性之间可能互相抑制

必须结合设计、实现、部署3方面才能满足

质量属性场景

描述系统如何对刺激做出反应

组成：刺激源(source)、刺激(stimulus)、制品(artifact)、环境(environment)、响应(response)、相应衡量指标(response measure)

1、可用性(Availability)

在要求的外部资源得到保证的前提下，产品在规定的条件下和规定的时刻或时间区间内处于可执行规定功能状态的能力。是产品可靠性、维修性和维修保障性的综合反映

关注点：是否发生故障 故障的后果

衡量指标：可用时间百分比、修复故障所需的时间、平均无故障时间

场景：

• 刺激源：故障
• 刺激：系统出错、系统崩溃、给出结果不准时、给出错误结果
• 制品：计算、存储、网络传输
• 环境：正常状态、亚健康状态
• 响应：记录日志、通知管理员、关闭系统
• 相应衡量指标：故障时间百分比、修复故障所需时间、平均无故障时间

策略 Tactics：

目标：降低故障造成的影响

1. 故障检测 Ping/echo、heartbeat、exception
2. 故障恢复 投票、主动冗余、被动冗余、内测、检查点/回滚
3. 故障避免 服务下线、事务(transaction)、进程监控、

2、可修改性 (Modifiability)

关注点：

1. 修改的成本
2. 系统的哪些部分被修改
3. 修改发生的时间
4. 修改由谁进行

衡量指标：

1. 修改完成的时间
2. 修改所花的人力成本
3. 修改所花的经济成本

场景：

• 刺激源：谁进行的修改
• 刺激：要进行的具体修改
• 制品：修改系统的功能、UI、交互的其它系统
• 环境：什么时候进行的修改
• 响应：操作人员要理解如何修改、进行修改操作、测试、部署
• 响应衡量指标：时间、成本

策略：

目标：降低修改的时间和成本

1. 限制修改范围
   1. 模块高内聚、低耦合
   2. 考虑到可能会发生的修改
   3. 让模块通用
   4. 隐藏信息
   5. 维持接口不变
   6. 限制通信路径
   7. 使用中介
   8. 命名服务器
   9. 按需创建实例
2. 延迟绑定时间
   1. 配置文件
   2. 发布-订阅模式
   3. 多态

3、性能 (Performance)

关注点：响应事件的速度、和事件的数量和到达模式有关

事件的来源：用户的请求、系统内部或者外部

到达模式：随机、在特定时间尺度有规律

场景：

1. 刺激源：来自系统内部或外部
2. 刺激：事件到来
3. 制品：系统所提供的服务
4. 环境：系统可能处于不同的模式（正常、紧急、超载）
5. 响应：系统处理
6. 响应衡量指标：处理时间所花事件、单位时间处理事件的数目、处理的错误率/丢失率

策略：

目标：限定时间内响应事件、获取资源+使用资源

1. 资源的需求
   1. 提高计算效率 （使用高效算法、减少处理事件对资源的占用）
   2. 减少处理的数据总量
   3. 限制执行时间
   4. 限制待处理事件队列长度
2. 资源的管理
   1. 利用并发机制
   2. 增加可用资源
3. 资源的仲裁
   1. 先来先服务FCFS
   2. 固定优先级调度
   3. 动态优先级

4、安全性 (Security)

**关注点：**抵抗对系统的攻击

场景：

• 刺激源：人或着系统
• 刺激：对系统的攻击(窃取信息、获取超权限服务、降低系统可用性)
• 制品：系统提供的服务或系统中的数据
• 环境：联网、未联网、在线、下线、有防火墙、无防火墙
• 响应：合法用户正常使用，拒绝非法用户使用、威慑
• 响应衡量指标：发起攻击的难度、从攻击中恢复的难度

策略：

1. 抵抗攻击
   1. 用户证实（密码、验证码）
   2. 用户授权
   3. 维持数据的保密性
   4. 维持数据完整性
   5. 减少暴露
   6. 限制访问
2. 检测攻击
   1. 软件和人结合（入侵检测系统、安全专家）
3. 从攻击中恢复
   1. 恢复状态（可用性）
   2. 攻击者的识别

5、可测试性 (Testability)

为了发现错误

关注点：

1. 让软件的bug容易被检测出来
2. 验证软件产品与他的需求规格是否匹配
3. 使用最小的成本和工作量来验证软件的质量

场景：

• 刺激源：不同角色发起
• 刺激：系统开发到了里程碑、分析、设计、编码、集成阶段的结束，或系统完成开发
• 制品：一个设计、一段代码、整个系统
• 环境：设计阶段、开发阶段、部署阶段、正常运行时
• 响应：可以进行测试并可以观察到结果
• 响应衡量标准：白盒测试中的覆盖率、未来继续发现bug的概率

策略：

目标：让测试更轻松

1. 黑盒测试
   1. 记录/回放
   2. 把接口和实现分离开
   3. 提供专用的测试路径
2. 白盒测试
   1. 内部监控（调试工具）

**测试工具：**Appium（App UI测试） Selenium（Web UI测试）JMeter（接口测试、性能测试）

6、易用性 (Usability)

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

场景：

• 刺激源：终端用户
• 刺激：终端用户希望学习系统的使用、提高系统的使用效率、减少出错
• 制品：整个系统
• 环境：运行时或者配置时
• 响应：系统响应用户的要求
• 相应衡量指标：用户完成任务的时间、用户出错的次数、用户满意度、用户操作的成功率

策略：

目标：让用户轻松

1. 运行时策略

   1. 系统猜测用户要完成的任务
   2. 系统给用户适当的反馈
   3. 系统给用户提供一致的体验
   4. 支持撤销操作

2. 设计时策略

   1. 把用户界面和系统其他部分隔离开

      MVC模式

五、软件体系结构评估

1、体系结构评估

…

2、ATAM

参与人员：评估小组、项目决策者、构架涉众

四个阶段：Phase0~3

Utility Tree 效用树 自顶向下

Risk Tradeoff Sensitivitity Non-Risk