软件设计和结构体系

结构

模块结构 Module

将系统划分为执行单元，是静态结构，支持可修改性

decomposition 结构
分解结构，将模块分成多个子模块
uses 结构
使用结构，显示模块之间的相互使用关系
layer 结构
分层结构，如网络分5层，上层可以使用下层功能，但不能反过来
class 结构
类结构，有实例化，继承等关系
data model 结构
数据模块结构，如ER图（实体-关系图）的结构，可以用在数据库的管理等

C&C 结构 Component-and-connector

运行时互相作用以执行功能，动态结构，可以由UML图的序列图，活动图，状态图表示

service 结构
面向服务的结构
concurrency 结构
并发结构，如线程，进程

分配结构 Allocation

将软件结构映射到系统的环境中，包括硬件，文件，开发团队上

deployment 结构
部署结构，软件映射到硬件，用于软件的部署和迁移
implementation 结构
实现结构，软件映射到文件结构
work assign 结构
工作分配结构，软件的工作内容映射到开发团队上

质量属性

可用性 Availability

定义为系统正常运行的时间占比

前提：故障是“可修复”的
availability = MTBF/(MTBF+MTTR)
MTBF：平均故障间隔时间，全称Mean Time Between Failure
MTTR：故障发生到故障修复完成的时间

质量属性场景 Quality attributes Scenarios

通用场景：

质量属性表：

战术 Tactics

错误检测——用来检测故障的健康监视；
自动恢复——检测到故障时恢复；
错误预防——阻止错误演变为故障。

目的：软件能承受故障，交付的服务始终符合规范

可用性设计 Design

The design for availability include:

1.Allocation of responsibilities
2.Coordination model
3.Data model
4.Mapping among architectural elements
5.Resource management
6.Binding time
7.Choice of technology

总结

可部署性 Deployability

可部署性指在可预测且可接受的时间和精力范围内部署，新部署不符合时可回滚

质量属性场景 Quality attributes Scenarios

通用场景：

质量属性表：

战术 Tactics

1.可部署流水线pipeline：
规模递增(软件使用人数递增)，脚本部署命令(软件部署过程代码化)，回滚(恢复到先前状态)
2.可部署性系统system：
管理服务交互(避免版本不兼容)，打包依赖(在不同环境中保持一致)，切换功能(可以远程开关功能)

目的：减少部署时间，增加部署质量

设计模式 Patterns

1.为部署构建服务
微服务架构 (除了接口外没有其它连接)
服务完全代替 (在不降低服务质量的情况下进行服务代替)
服务部分代替

2.如何部署服务：
all-or-nothing(全部署或不部署) 或 partial(部分部署)

服务完全代替有基于模式的不同规模的两种战术：蓝绿部署，滚动升级
服务部分代替有两种战术：金丝雀测试，A/B测试

蓝绿部署：同时运行两个版本的应用（蓝色环境和绿色环境），并且这两个版本的应用实例规格和数量通常保持一致。
在升级过程中，不停止旧版本（蓝色环境）的服务，而是直接部署新版本（绿色环境）。
等待新版本测试通过后，将流量从旧版本切换到新版本。
如果新版本出现问题，可以快速将流量切回旧版本，实现快速回滚。

滚动升级：在不中断服务的情况下，对应用程序进行逐步升级。
在滚动升级中，不是一次性启动所有新版本的应用实例，而是逐步替换旧版本的应用实例。
每次替换一个或多个旧版本实例，并启动对应数量的新版本实例。
逐步替换直到所有旧版本实例都被新版本实例替换完毕。

金丝雀测试：在软件发布中用于提前发现潜在问题。
在金丝雀测试中，新功能或更新首先被推出到一小部分用户或服务器上（这部分被称为“金丝雀”环境）。
团队监控这部分用户或服务器的反馈和性能指标，以评估新功能或更新的稳定性和性能。
如果发现问题，可以立即停止发布并修复问题，避免影响更广泛的用户。

A/B测试：用于比较两个或多个版本的某个变量（如网站的标题、颜色、布局等），以确定哪个版本对于所测试的目标（如增加销售、提高转化率等）最有效。
在A/B测试中，随机分配的用户组被分为两个或多个组，每个组被展示不同版本的变量。
通过收集和分析每个组的行为和反馈数据（如点击率、转化率等），可以确定哪个版本的变量对实现目标最有效。

总结

可修改性 Modifiability

可修改性成本：引入可修改性的机制（提前布置让用户来修改），每一次修改源码的成本（开发人员来修改）

包含variability可变性（产品相关），Portability可移植性，Scalability可伸缩性（水平伸缩：增加硬件；垂直伸缩：增加软件资源）

对于N种类似的改动，比较改动成本的公式：
N x Cost1 <= Cost2 + (N x Cost3)
Cost1: 在没有机制的情况下进行更改的成本
Cost2: 建立机制的成本
Cost3: 使用机制进行更改的成本

更改的内容包括：
功能（添加/修改/删除），质量（可用性），容量（支持用户数），技术（将系统移植到不同计算机上）

质量属性场景 Quality attributes Scenarios

通用场景：

质量属性表：

战术 Tactics

可修改性涉及的因素：
1.模块的大小
2.耦合 Coupling（越低越好）
3.内聚 Cohesion（越高越好）
4.修改的绑定时间

3类战术：
增加内聚（功能越单纯，内聚越好）
减少耦合（减少功能之间的联系）
推迟绑定时间（早绑定：编译时确定功能，晚绑定：在运行时绑定）

总结

性能 Performance

性能与时间和资源有关
测量响应的值：latency; throughput; miss rate

质量属性场景 Quality attributes Scenarios

通用场景：

质量属性表：

战术 Tactics

影响响应时间的因素：
Processing time
Blocked time

总结

易用性 Usability

易用性体现：容易学习，使用方便，最小化错误影响，系统适应用户，增强用户使用信心

质量属性场景 Quality attributes Scenarios

通用场景：

质量属性表：

战术 Tactics

1.用户优先
取消 Cancel：被取消的命令必须终止，释放被取消命令使用的资源，通知正在与取消命令协作的组件
撤销 Undo
暂停 Pause/Resume
聚合 Aggregate：将较低级别的对象聚合成一个组，一起进行处理
2.系统优先
维持任务模型（系统预测用户将会做的事并提供帮助，如搜索时下方显示可能想搜索的词）
维持用户模型（系统学习用户的习概偏好，如输入法根据用户打字习惯提供字，视频软件根据用户偏好推流视频）
维持系统模型（确定预期的系统行为，以向用户提供反馈，如下载文件显示下载进度和预计花费时间）

总结

虚拟化

目的：共享资源和进行隔离
硬件资源：CPU（轮转分配），内存（分页分配），磁盘（磁盘控制器分配），网络连接（通过IP地址标识区别）

虚拟机

虚拟机镜像：运行虚拟机的代码，传输和启动较慢

type1

Hypervisor：操作系统
管理虚拟机（包括创建，监测，杀死虚拟机，管理虚拟机的生命周期）
管理虚拟机里的应用程序（超过虚拟机的部分，比如网络请求）
VM：虚拟机，即一个操作系统

type2

(方便模拟不同操作系统环境)

容器

相比虚拟机，传输和启动更快
一个容器里只有一个应用程序，程序结束容器停止
（也可见另一篇云和云AI的docker部分）

相关容器pods：之间可以紧密通信，如图容器1和容器2

云

（也可见另一篇云和云AI的云部分）
目的：按需使用资源
云基于虚拟化和分布式计算

云的失效与2种有关：
超时Timeout
长尾延时long tail latency（在网络或系统中，一部分请求需要比平均时间长得多的时间才能完成的现象。这些延迟较长的请求形成了“长尾”，影响了整体系统的响应速度和性能）

构架模式

构架是一组结构，结构由元素和元素之间的关系组成
构架由图来表达
构架模式也分为：模块 Module，C&C Component-and-connector，分配 Allocation

分层模式

分层模式：属于model模式，每层是一组高内聚的服务，自顶向下，分而治之，可以分别进行开发和维护
元素：层
关系：访问权限，高层单向访问低层
限制条件：1.软件全在层内 2.至少有2层 3.访问权限关系不能循环
支持的质量属性：可移植性Portability，可修改性Modifiability，重用性Reuse
缺点：增加层会增加系统成本和复杂性
层桥：较高层软件使用不相邻较低层的模块
例子：网络通信分层

Broker代理模式

代理模式：C&C模式，不关心服务如何实现，由Broker中介把相似的功能集结起来提供服务
元素：客户端，服务端，中介，客户端代理，服务端代理
关系：附着关系，通过中介连接客户端，服务端
限制条件：客户端只通过客户端代理连接中介，服务端只通过服务端代理连接中介
支持的质量属性：可修改性，可用性（背后有大量服务端），性能
缺点：增加复杂性，中介是单一故障点，并且难以测试，可能被攻击或产生延迟
例子：美团，携程

管道-过滤器模式

管道-过滤器模式：属于C&C模式
元素：管道，过滤器
关系：依附关系，过滤器与管道相互依附
限制条件：管道不能分叉，即一个管道只能将过滤器输出端口连接到过滤器输入端口，连接的过滤器必须就通过管道传输的数据达成一致
缺点：不适合交互系统，效率不高
例子：物联网设备（摄像头），影视app

P2P点对点模式

P2P模式：C&C模式，去中心化，每个设备既是服务端也是客户端
两种具体模式：

关系：服务器，客户端的请求/响应关系
缺点：需要有一定的规模
支持的质量属性：可扩展性，可用性，性能
例子：skype

Map-Reduce模式

Map-Reduce模式：映射并处理数据，进行大数据的处理
map：映射，例如分词；reduce：
元素：map, reduce
关系：分配关系
限制：reduce需要比较简单，数据需要处理成简单的词

设计模式

设计模式是软件设计经验的总结，目的是加强软件的重用性
开闭原则：在不改变原有代码的基础上扩展功能

创建型设计模式 creative

目的：分离使用和创建

工场模式 Factory pattern

类图，支持开闭原则

抽象工厂模式

通过增加一个工厂的生产种类，减少工厂数量
类图，不完全支持开闭原则
下面的例子抽象工厂模式只需要2个工厂，工厂模式需要4个工厂

单例模式 Singleton pattern

确保只有一个实例
构造函数是私有的，并增加一个静态方法用来创造第一个实例
（改变判断条件可以设计出只有2个实例，3个实例等等）

结构型设计模式 structrual

目的：把不同的对象结合起来形成更大的结构

组合模式 Composite pattern

leaf：执行者
component：父类
composite：组合，继承于父类，且聚合了父类
同等看待composite于leaf
安全型组合模式

透明型组合模式

适配器模式 Adapter pattern

需要达成Target接口的这些函数，已经有了Adaptee里的函数，于是增加Adapter在Adaptee的基础上增加缺少的函数
类适配器模式

对象适配器模式
需要多个Adaptee里的函数

行为型设计模式 behavioral

目的：构架对象之间的关联

迭代器模式 Iterator pattern

使用场景：使用访问器处理数据
数据是一个类Aggregate，访问器是另一个类Iterator，它们通过ConcreteAggregate与ConcreteIterator进行连接

命令模式 Command pattern

使用场景：在通过中间者Invoker沟通客户与执行者的基础上，使用commmand屏蔽命令的差异
client：消费者
receiver：任务执行者
invoker：中介
command：屏蔽所有命令的差异

流程图：

设计一个架构

设计策略
1.分解：包括功能和质量
2.设计ASR (Architecturally significant requirements 对架构产生重要影响的需求)
3.生成和测试：生成通常从已有软件，框架，构架模式，领域分解开始

ADD (attribute-driven design)方法，基于设计策略
前提 1.找到所有ASR 2.明确系统依附的环境
步骤
1.对项目进行分解，选择系统中一个元素
2.识别ASR，基于商业价值或架构相关等，一般由投票决定
3.生成并测试这个元素
4.把没有设计的部分继续完善

分解战术：1.广度Breadth优先 2.深度depth优先

把质量变成功能才能实现，如通讯加密功能是实现安全性的质量属性

架构评估

评估：自己评估，同行评估（需要呈现出设计），外部评估（需要提供商业目标等文件）
评估方法：ATAM，CBAM

ATAM

敏感点 sensitivity：设计决策，影响一个质量属性
权衡点 tradeoff：设计决策，影响多个质量属性
风险点 risk：可能产生坏的设计决策
无风险点 nonrisk：不会产生坏的设计决策

阶段1：选定人员，场地，评估资料，双方进行了解协商
阶段2：评估人员与决策人员参与
阶段3：评估人员，决策人员，架构人员参与
阶段4：呈现评估结果和商业目标
2，3阶段具体任务：

抽取质量属性场景，构建质量属性效用树，找到重要的质量属性进行评估

CBAM
除了产品本身外，还要考虑成本，收益和风险

效用响应曲线 Utility Response Curves 联系了成本（质量属性）和效益


$B_i$对应第$i$个设计决策的总收益
$b_{i,j}$对应第$i$个决策的第$j$个场景的收益 = 期望的收益 - 当前收益
$W_j$是第$j$个场景的权重
$C_i$对应第$i$个设计决策的成本

步骤