全文链接：https://www.cnblogs.com/nullering/p/9684820.html
一：架构模型软件架构可归纳为
（1）结构模型：这是一个最直观、最普遍的建模方法。这种方法以架构的构件、连接件（connector）和其他概念来刻画结构，并力图通过结构来反映系统的重要语义内容，包括系统的配置、约束、隐含的假设条件、风格、性质等。研究结构模型的核心是架构描述语言。
（2）框架模型：框架模型与结构模型类似，但它不太侧重描述结构的细节而更侧重于整体的结构。框架模型主要以一些特殊的问题为目标建立只针对和适应该问题的结构。
（3）动态模型：动态模型是对结构或框架模型的补充，研究系统的“大颗粒”的行为性质。例如，描述系统的重新配置或演化。动态可以指系统总体结构的配置、建立或拆除通信通道或计算的过程。这类系统常是激励型的。
（4）过程模型：过程模型研究构造系统的步骤和过程。因而结构是遵循某些过程脚本的结果。
（5）功能模型：该模型认为架构是由一组功能构件按层次组成，下层向上层提供服务。它可以看作是一种特殊的框架模型。
5种，但各有所长，将它们有机统一起来也许更合适，所以有人提出了“4+1”视图模型：
逻辑视图：逻辑视图关注功能，不仅包括用户可见的功能，还包括为实现用户功能而必须提供的"辅助功能模块"；它们可能是逻辑层、功能模块等。
开发视图：开发视图关注程序包，不仅包括要编写的源程序，还包括可以直接使用的第三方SDK和现成框架、类库，以及开发的系统将运行于其上的系统软件或中间件。开发视图和逻辑视图之间可能存在一定的映射关系：比如逻辑层一般会映射到多个程序包等。
处理视图：处理视图关注进程、线程、对象等运行时概念，以及相关的并发、同步、通信等问题。处理视图和开发视图的关系：开发视图一般偏重程序包在编译时期的静态依赖关系，而这些程序运行起来之后会表现为对象、线程、进程，处理视图比较关注的正是这些运行时单元的交互问题。
物理视图：物理视图关注"目标程序及其依赖的运行库和系统软件"最终如何安装或部署到物理机器，以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。物理视图和处理视图的关系：处理视图特别关注目标程序的动态执行情况，而物理视图重视目标程序的静态位置问题；物理视图是综合考虑软件系统和整个IT系统相互影响的架构视图。
场景（scenarios）：可以看作是那些重要系统活动的抽象，它使四个视图有机联系起来，从某种意义上说场景是最重要的需求抽象。在开发架构时，它可以帮助设计者找到架构的构件和它们之间的作用关系。同时，也可以用场景来分析一个特定的视图，或描述不同视图构件间是如何相互作用的。场景可以用文本表示，也可以用图形表示。
二：架构需求与软件质量属性 1：软件质量属性一是可在运行时确定的系统系统质量属性，如性能，安全性，可用性和使用性
二是无法通过观察系统运行确定的：可更改性，可移植性，可重用性，可集成性，可测试性
三是架构直接相关的：概念完整性，正确性，完整性，可构建性。
1、可用性及其实现
故障处置。
1）错误检测
日志 心跳 异常捕捉
2）错误恢复
冗余，备件，回滚，事务，降级
3）错误预防
事务等
2、可修改性及其实现
1）将修改限制在局部
高内聚低耦合，降低对其他模块的依赖；提高模块的通用性；限制变更范围等；
2）防止连锁反应
对扩展开放， 对更改关闭。
3）推迟绑定时间
配置文件，多态，注册
3、性能及其实现
1）减少及控制资源使用
2）资源管理
引入并发，缓存，增加资源
3）资源仲裁
资源调度
4、安全性及其实现
1）防御攻击
2）检测攻击
3）恢复
5、可测试性及其实现
1）输入输出
记录，接口与实现分离，用实现替代用于测试
2）内部监控