1. 软件架构的概念
软件架构，即软件体系结构，为软件系统提供一个结构、行为和属性的高级抽象。
软件架构作用：
1）项目干系人进行交流的手段
2）可传递和复用的模型，通过研究软件架构可预测软件的质量
3）使推理和控制的更改更加简单，有助于循序渐进的原型设计
|--------|----------------------------------------------------------------|
| 阶段 | 作用和意义 |
| 需求分析阶段 | 软件需求模型到软件架构模型转换关注的问题： 1. 如何根据需求模型构建软件架构模型（SA模型） 2. 保证模型转换的可追踪性 |
| 设计阶段 | 软件架构研究关注的最早和最多的阶段。 ADL、4+1视图 |
| 实现阶段 | |
| 构件组装阶段 | 可复用构建组装设计能够提高系统实现的效率 |
| 部署阶段 | 软件架构为部署提供高层架构指导 |
| 后开发阶段 | 维护、演化、复用 |
架构描述语言ADL
形式化语言，在底层语义模型的支持下，为系统软件的概念体系结构建模提供了具体语法和概念框架（如Aesop,MetaH,C2,Rapide,SADL,Unicon）
ADL的三个基本元素：
构件、连接件、架构配置
4+1视图：
|------------------------------|------------|---------------|
| 视图 | 视角 | 描述 |
| 逻辑视图（Logical View） | 最终用户（功能需求） | 类与对象 |
| 实现/开发视图（Implementation View） | 程序员 | 配置、装配 |
| 进程视图（Process View） | 系统集成人员 | 性能、可伸缩、吞吐率、并发 |
| 部署/物理视图（Deployment View） | 系统工程人员 | 发布、安装、拓扑结构 |
| 用例视图/场景（use-case View） | 分析/测试人员 | |
2. 基于架构的软件开发
基于架构的软件开发（ABSD）是架构驱动的，强调由业务【商业】、质量和功能需求的组合驱动架构设计。
ABSD基础：功能分解、通过选择架构风格来实现质量和业务需求、软件模板的使用
视角和视图（描述软件架构）
用例用来捕获功能需求、特定场景【刺激、环境、响应】用来捕获质量需求
开发过程：ABSD能很好的支持软件重用，是一个自顶向下、递归细化的方法，软件系统的体系结构通过该方法得到细化，直到能产生软件构件和类
1）体系结构需求：需求评审的重点是需求是否真实的反映了客户的要求，组的分类是否合理，构件合并是否合理等
2）体系结构设计：设计评审必须邀请独立于系统开发的外部人员
3） 体系结构文档化：主要输出是架构规格说明 和 测试架构需求的质量设计说明书 两个文档
软件架构成功的关键因素：文档的完整性和质量
文档的注意事项：文档要从使用者的角度进行编写、必须分发给所有与系统有关的开发人员、必须保证开发者手上的文档是最新的
4） 体系结构复审：标识潜在的风险，及早发现架构设计中的缺陷和错误
5）体系结构实现：体系结构说明书中定义了系统中构件与构件间的关系。测试包括单个构件的功能性测试及被组装应用的整体功能和性能测试。
6）体系结构演化
3. 软件架构风格
软件架构风格是特定应用领域的惯用模式，架构定义一个词汇表和一组约束
|--------------------------------|---------------------------------------------------------------------------------|
| 五大架构风格 | 子风格 |
| 数据流风格【Data Flow】 | 批处理【Batch Sequential】、管道-过滤器【Pipes and Filters】 |
| 独立/返回风格【Call/Return】 | 主程序/子程序【Main Program and Subroutine】、面向对象【Object-oriented】、分层架构【Layered System】 |
| 独立构件风格【Independent Components】 | 进程通信【Communicating Progress】、事件驱动系统（隐式调用）【Event System】 |
| 虚拟机风格【Virtual Machine】 | 解释器【interpreter】、规则系统【Rule-based System】 |
| 以数据为中心【Data-centered】 | 数据库系统【Database System】、黑板系统【Blackboard System】、超文本系统【Hypertext System】 |
- 数据流风格
前一步处理的结果是后一步的输入内容【数据驱动】
优点：松耦合【高内聚-低耦合】，良好的重用性/可维护性，可扩展性【标准接口适配】，良好的隐蔽性，支持并行
缺点：交互性较差，复杂性较高，性能较差（每个过滤器都需要解析和合成数据）
典型实例：传统编译器、网络报文处理
批处理：大量整体数据，无需用户交互
管道-过滤器：流式数据、弱用户交互
2）调用/返回风格
主程序/子程序：面向过程
面向对象：对象的方法调用
分层：层与层之间的方法调用
分层架构优点：1. 良好的重用性（只要接口不变可用在其他处）；2. 可维护性好；3. 可扩展性好，支持递增设计
分层架构缺点：1. 并不是每个系统都方便分层；2. 很难找到一个正确的、合适的分层方法；3. 不同层次之间耦合度高的系统很难实现
分层架构特点：1. 各个层次的组件形成不同功能级别的虚拟机；2. 多层相互协同工作，而且实现透明
3）独立构件风格
优点：1. 松耦合；2. 良好的重用性/可修改性/可扩展性
缺点：1. 构件放弃了对系统计算的控制；2. 数据交换的问题；3. 过程的语义必须依赖于被触发事件的上下文约束，关于正确性的推理存在问题
特点：系统由若干子系统构成且成为一个整体；系统有统一的目标；子系统有主从之分；每一子系统有自己的事件收集和处理机制
4）虚拟机风格
|-------|-------------|-------|----------------|-----------------|
| 子分类 | 优点 | 缺点 | 特点 | 适合领域 |
| 解释器 | 可以灵活应对自定义场景 | 复杂度较高 | | 适用于需要"自定义规则"的场合 |
| 规则为中心 | 可以灵活应对自定义场景 | 复杂度较高 | 在解释器的基础上增加经验规则 | 使用于专家系统 |
基于规则的系统构成：规则集、规则解释器、规则/数据选择 及 工作内存，一般用在人工智能领域和DSS（决策支持系统）中。