Appearance
软件架构的概念
一个程序和计算系统软件体系结构是指系统的一个或者多个结构。结构中包括软件的构件，构件的外部可见属性以及它们之间的相互关系。
体系结构并非可运行软件。确切地说，它是一种表达，使软件工程师能够：
- (1)分析设计在满足所规定的需求方面的有效性；
- (2)在设计变更相对容易的阶段，考虑体系结构可能的选择方案；
- (3)降低与软件构造相关联的风险。
上面的定义强调在任意体系结构的表述中“软件构件”的角色。软件构件简单到可以是程序模块或者面向对象的类，也可以扩充到包含数据库和能够完成客户与服务器网络配置的“中间件”。
软件体系结构的设计两个层次：数据设计和体系结构设计。
- 数据设计体现传统系统中体系结构的数据构件和面向对象系统中类的定义（封装了属性和操作），
- 体系结构设计则主要。
软件架构设计主要关注软件构件的结构、属性和交互作用，并通过多种视图全面描述特定系统的架构。
- 结构：系统的组成构件
- 属性：构件的特征描述
- 交互作用：构件之间的协作关系
- 视图：从不同视角描述架构的不同方面
架构设计
架构设计生命周期
| 阶段 | 主要关注 |
|---|---|
| 需求分析 | 需求获取、场景描述、质量属性定义 |
| 设计阶段 | 架构模型描述、设计分析方法、设计经验总结与复用 |
| 实现阶段 | 从架构向代码的过渡、开发过程支持、测试技术 |
| 构件组装 | 检测并解决架构失配问题 |
| 部署阶段 | 架构到物理硬件的映射、构件部署配置、资源分配、部署描述与环境初始化 |
| 后开发阶段 | 架构演化、运维监控、重构、技术债务管理、架构恢复与评估 |
架构设计概念
从需求分析到软件设计之间的过渡过程称为软件架构。只要软件架构设计好了，整个软件就不会出现坍塌性的错误，即不会崩溃。
架构设计就是需求分配，将满足需求的职责分配到组件上。软件架构为软件系统提供了一个结构、行为和属性的高级抽象，由构件的描述、构件的相互作用(连接件)、指导构件集成的模式以及这些模式的约束组成。
软件架构不仅指定了系统的组织结构和拓扑结构，并且显示了系统需求和构件之间的对应关系，提供了一些设计决策的基本原理。解决好软件的复用、质量和维护问题，是研究软件架构的根本目的。
软件架构设计包括提出架构模型，产生架构设计和进行设计评审等活动，是一个迭代的过程。架构设计主要关注软件组件的结构、属性和交互作用，并通过多种视图全面描述特定系统的架构。
架构设计是一个迭代过程，包括三大活动：
- 提出架构模型 — 选择架构风格，建立初始架构
- 产生架构设计 — 将构件映射到架构，分析构件关系
- 进行设计评审 — 邀请独立外部人员评审
❌ 易错：架构设计活动不包含"设计并实现这些构件"（实现属于后续阶段）
架构设计的主要作用
软件架构能够在设计变更相对容易的阶段，考虑系统结构的可选方案，便于技术人员与非技术人员就软件设计进行交互，能够展现软件的结构、属性与内部交互关系。
软件架构是项目干系人进行交流的手段，明确了对系统实现的约束条件，决定了开发和维护组织的组织结构，制约着系统的质量属性。
软件架构使推理和控制的更改更加简单，有助于循序渐进的原型设计，可以作为培训的基础。
软件架构是可传递和可复用的模型，通过研究软件架构可能预测软件的质量。
- 解决相对复杂的需求分析问题
- 解决非功能属性在系统占据重要位置的设计问题
- 解决生命周期长、扩展性需求高的系统整体结构问题
❌ 注意：架构设计不负责系统代码实现的具体细节
架构设计目标
软件架构设计的主要目标是获得一个同时满足功能性需求和非功能性需求的软件系统框架模型
需求模型 → 架构模型转换 ★
两个核心问题：① 如何构建架构模型 ② 如何保证模型转换的可追踪性
构件
构件是一个独立可交付的功能单元，外界通过接口访问其提供的服务。
构件由一组通常需要同时部署的原子构件组成。一个原子构件是一个模块和一组资源。原子构件是部署、版本控制和替换的基本单位。原子构件通常成组地部署，但是它也能够被单独部署。
构件和原子构件之间的区别在于，大多数原子构件永远都不会被单独部署，尽管它们可以被单独部署。相反，大多数原子构件都属于一个构件家族，一次部署往往涉及整个家族。
一个模块是不带单独资源的原子构件（在这个严格定义下，Java包不是模块一一在Java中部署的原子单元是类文件。一个单独的包被编译成多个单独的类文件一一每个公共类都有一个)。
模块是一组类和可能的非面向对象的结构体，比如过程或者函数。
构件和对象
构件的特性是：
- (1)独立部署单元；
- (2)作为第三方的组装单元；
- (3)没有（外部的）可见状态。
一个构件可以包含多个类元素，但是一个类元素只能属于一个构件。将一个类拆分进行部署通常没什么意义。
对象的特性是：
- (1)一个实例单元，具有唯一的标志。
- (2)可能具有状态，此状态外部可见。
- (3)封装了自己的状态和行为。
构件接口
接口标准化是对接口中消息的格式、模式和协议的标准化。它不是要将接口格式化为参数化操作的集合，而是关注输入输出的消息的标准化，它强调当机器在网络中互连时，标准的消息模式、格式、协议的重要性。
面向构件的编程(COP)
关注于如何支持建立面向构件的解决方案。“面向构件的编程需要下列基本的支持：
一一多态性（可替代性）： 一一模块封装性（高层次信息的隐藏）： 一一后期的绑定和装载（部署独立性）： 一一安全性（类型和模块安全性）。”
构件组装失配类型 ★
| 失配类型 | 原因 |
|---|---|
| 构件级失配 | 对构件基础设施、控制模型、数据模型的假设冲突 |
| 连接子级失配 | 对构件交互协议、构件连接时数据格式的假设冲突 |
❌ 易错：不包括"构件操作不当引起的失配"
其他
非功能性需求四分类 ★
| 分类 | 含义 | 示例 |
|---|---|---|
| 操作性需求 | 系统运行环境与变化 | 支持主流标准协议 |
| 性能需求 | 响应时间、吞吐量 | 响应 ≤ 3s |
| 安全性需求 | 防中断、防数据丢失 | 密码加密、超时重登 |
| 文化需求 | 文化背景相关 | 多语言支持 |
基于架构的软件开发方法 ABSD
见下一个章节
DSSA（特定领域软件架构）三层模型
具体见下一个章节
DSSA就是专用于一类特定类型的任务（领域）的、在整个领域中能有效地使用的、为成功构造应用系统限定了标准的组合结构的软件构件的集合。
DSSA就是一个特定的问题领域中支持一组应用的领域模型、参考需求、参考架构等组成的开发基础，其目标就是支持在一个特定领域中多个应用的生成。
- 垂直域：在一个特定领域中的通用的软件架构，是一个完整的架构。
- 水平域：在多个不同的特定领域之间的相同的部分的小工具（如购物和教育都有收费系统，收费系统即是水平域)。
DSSA 是为一个特定应用领域中一组应用提供组织结构参考的标准软件体系结构
三层模型：
- 领域开发环境 — 顶层，领域设计人员工作环境
- 领域特定应用开发环境 — 中间层，应用开发人员工作环境
- 应用执行环境 — 底层，最终用户运行环境
软件系统四项基本功能
- 数据存储 — 数据持久化存储与检索（data storage/persistence）
- 数据访问逻辑 — 处理数据的逻辑，通常是 SQL 查询
- 应用逻辑（业务逻辑） — DFD、用例、功能需求中记录的逻辑
- 表示逻辑 — 用户界面显示与命令接收
三类主要硬件构件： 客户端、服务器、网络
ES 与 DSS
- 专家系统（ES）：与一般系统的根本区别在于能解释推理过程
- 决策支持系统（DSS）：主要用于解决半结构化问题
设计经验重用技术
用于总结和重用设计经验的主要技术：体系结构风格和DSSA