软件架构设计
软件架构风格
定义：
软件架构风格 是描述某一特定领域中系统组织方式的惯用手段。架构定义一个词汇表 和一组约束 ，词汇表中包括一些构件 和连接件类型 ，而这组约束指出系统如何将这些构件和连接件组合起来。
软件架构为软件系统提供了一个结构、行为和属性 的高级抽象，由构成系统的元素描述 、这些元素的相互作用 、指导这些元素的集成的模式 以及这些模式的约束组成。
软件风格反映了领域中众多系统所共有的的结构和语义特性 ，并指导如何将各个构件进行有效的组织成一个完整的系统。
作用：
- 软件架构是项目干系人进行交流 的手段，明确了对系统实现的约束条件 ，决定了开发和维护组织的组织结构 ，制约着系统的质量属性。
- 软件架构使推理和控制的更改更加简单，有助于循序渐进的原型设计，可以作为培训的基础
- 软件架构是可传递 和可复用的模型，通过研究软件架构可能预测软件的质量
分类：
| 名称 | 子风格 |
|---|---|
| 数据流风格 | 批处理、管道过滤器 |
| 调用/返回风格 | 主程序/子程序、层次架构、面向对象、 |
| 独立构件风格 | 进程通信、事件驱动系统（隐式调用） |
| 虚拟机风格 | 解释器、规则系统 |
| 仓库风格 | 数据库仓库、黑板系统、超文本系统 |
数据流风格
批处理
构件为一系列的固定顺序 的计算单元，构件之间只能通过数据传递交互 。每个处理步骤是一个独立的程序 ，每一步必须在前一步结束后 才能开始，数据必须完整 ，以整体的方式传递。
管道过滤器
每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理，然后产生输出数据流。
早期编译器就是采用的这种架构。要一步一步处理的，均可考虑采用此架构风格。
调用/返回风格
主程序/子程序
单线程控制，把问题划分成若干个处理步骤，构件即为主程序和子程序，子程序通常可以合称为模块。过程调用作为交互机制，即充当连接件的角色。调用关系具有层次性，其语义逻辑表现为主程序的正确性取决于调用的子程序的准确性。
面向对象
构件即对象，对象是抽象数据类型的实例，连接件即是对象间的交互方式，对象是通过函数和过程调用进行交互。
层次结构
构件组织成一个层次结构，连接件通过决定层间如何交互的协议来定义。
独立构件风格
进程通信
构件是独立过程，连接件是消息传递。
事件驱动系统（隐式调用）
构件不直接调用一个过程，而是触发或广播一个或多个事件。
虚拟机风格
解释器
解释器通常包括一个完成解释工作的解释引擎 、一个包含将被解释的代码的存储区 、一个记录解释引擎当前工作状态的数据结构 ，以及一个记录源代码被解释器执行进度的数据结构。
适用于需要"自定义规则"的场景
基于规则的系统
基于规则的系统包括规则集、规则解释器、规则/数据选择器和工作内存。
适用于专家系统。
仓库风格
数据库系统
以数据为中心
黑板风格
语音识别、模式识别、图像处理、知识推理
C2风格
基本规则：
构件和连接件都有一个顶部和一个底部
构件的顶部要连接连接件的底部，构件的底部要连接连接件的顶部，构件直接不允许直连
一个连接件可以和任意数目的其它构件和连接件连接
当两个连接件进行连接时，必须由其中一个的底部到另一个顶部。
特定领域软件架构（DSSA）
基于架构的软件设计（ABSD）
定义：
ABSD的方法是架构驱动，强调由业务（商业）、质量和功能需求的组合驱动架构设计。
特点：
支持软件重用 、自顶向下 、递归细化 、直到能产出构件和类
基础：
- 功能分解
- 软件风格选择
- 使用软件模板
**视角与视图：**从不同的视角来检查，所以会有不同的视图。
需求的捕获：
- 功能需求： 【通过用例捕获】
- 质量需求：【通过**特定场景（刺激、环境、响应）**捕获】
开发过程
架构需求、结构设计、架构文档化（输出：规格说明书、测试架构需求的质量说明书）、架构复审、架构实现、架构演化
文档的注意事项（文档的完整系和质量是软件架构成功的关键因素）
从使用者的角度编写
分发给所有与系统有关的人员
保证开发者手上的文档是最新版本
软件架构评估
性能
性能是指系统的响应能力，即经过多长时间才能对某个事件做出响应，或者在某个时间段内系统所能处理事件的个数。
代表参数：响应时间、吞吐量
设计策略：优先级队列、资源调度
可靠性
可靠性是软件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统的功能特性的基本能力。
代表参数：MTTF（平均故障间隔时间）、MTBF（平均无故障工作时间）
设计策略：冗余、心跳
可用性
可用性是系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。
可靠性与可用性意义相近，一般选择优先选择可用性。可靠性要求比可用性更高。可靠则必可用，而可用不一定可靠。可用性是可靠性的一个指标。
安全性
安全性是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。
安全性又可划分为机密性、完整性、不可否认性及可控性等特性。
设计策略：追踪审计
可修改性
可修改性是指能够快速以较高的性能价格比对系统进行变更能力。
功能性
功能性是指系统所能完成所期望的工作的能力。一项任务的完成需要系统许多或大多构件的相互协作
可变性
可变性是指体系结构经扩充或变更而成为新体系结构的能力。
互操作性
软件体系结构必须为外部可视的功能特性和数据结构提供精心设计的软件入口。程序和用其他编程语言编写的软件系统的交互作用就是互操作性的问题
易用性
易用性关注的是对用户来说完成某个期望任务的容易程度和系统所提供的用户支持的种类。
可测试性
软件可测试性是指通过测试揭示软件缺陷的容易程度。例如：提供远程调试接口，支持远程调试。
软件架构评估方法
相关概念
- 风险点：系统架构风险是指系统架构设计中潜在的、存在问题的架构决策所带来的隐患
- 非风险点：是指不会带来隐患，一般以"xxx要求是可以接受或实现"的方式表达
- 敏感点：指为了实现某种特定的质量属性，一个或多个构件所具有的特性
- 权衡点：影响多个质量属性的特性，是多个质量属性的权衡点
- 场景：用例描述功能需求，场景描述非功能需求（一般由业务人员提出来）
软件架构分析法（SAAM）
最初针对分析架构可修改性，后扩展到其他质量属性。
SAAM分析评估体系结构的过程包括五个步骤，即场景开发、体系结构描述、单个场景评估、场景交互、总体评估。
SAAM主要输入的问题是问题描述、需求声明、体系结构
形成"策略-场景-响应级别"的对应关系
架构权衡分析法（ATAM）
针对性能、实用性、安全性和可修改性，在系统开发之前，对这些质量属性进行评价和折中。
软件开发方法
结构化方法
定义：
用户至上，自顶向下，逐步分解，严格区分工作阶段，每阶段都有任务与成果，强调系统开发过程中的整体性和全局性，开发过程工程化，文档资料标准化。
优点：
理论基础严密，它的指导思想是用户需求在系统建立之前得到充分了解和理解
缺点：
开发周期长；文档、设计说明繁琐，工作效率低；阶段固化，适用于需求明确
原型化方法
定义：
适用于需求不明确的开发，按功能分-水平原型（界面）、垂直原型（复杂算法），按最终结果分抛弃式原型、演化式原型。
原型方法的特点在于原型法对用户的需求是动态响应、逐步纳入的，系统分析、设计与实现都是随着一个工作模型的不断修改而同时完成的，相互之间并无明显界限，也无明确分工。
面向对象方法
面向对象的方法开发软件，通常需要建立三种形式的模型：对象模型（描述系统数据结构）、动态模型（描述系统控制结构）、功能模型（描述系统功能）
面向服务方法
以粗粒度、松散耦合的系统功能为核心，强调系统功能的标准化和构件化，加强了系统的灵活性、可复用性和可演化性。
其他方法
形式化方法（净室软件工程【受控污染级别的环境】；数学模型化；所有东西均可证明/验证，而不是测试）
统一过程方法
敏捷方法
基于架构的开发方法（ABSD）
软件开发模型
原型模型
典型的原型开发方法模型，适用于需求不明确的场景，可以帮助用户明确需求。
瀑布模型
瀑布模型是将软件生存周期中的各个活动规定为依线性顺序连接的若干阶段的模型，包括需求分析、设计、编码、运行与维护。
特点：容易理解，管理成本低，每个阶段都有对应的产物，各个阶段有明显的界限划分和顺序要求，一旦发生错误，整个项目将推倒重新开始。
适用于需求明确的项目，一般表述为需求明确或二次开发，或者对于数据处理类型的项目
增量模型
融合了瀑布模型基本成分和原型实现的迭代特征，可以有多个可用的版本发布，核心功能往往最先完成，在此基础，每轮迭代会有新的增量发布，核心功能可以得到充分测试。每一个增量发布均为一个可操作的产品。
螺旋模型
引入了风险分析，结合瀑布模型和演化模型。它是由指定计划、风险分析、实施工程、客户评估这一循环组成。
V模型
强调测试贯穿整个项目始终，而不是集中在测试阶段。
是一种测试的开发模型
喷泉模型
典型的面向对象的模型。特点是迭代、无间隙。会将软件开发分为多个阶段，各个阶段无明显界限，可以迭代交叉。
快速应用开发RAD
RAD是瀑布模型的一个高速变种，开发周期短，通常适用于基于构件的开发方法。
过程：
业务建模，数据建模，过程建模，应用生成，测试与交付
构件组装模型
统一过程
典型特点是用例驱动、以架构为中心、迭代和增量。
构思阶段（初始阶段）：包括用户沟通和计划活动，强调定义和细化用例，并将其作为主要模型。
细化阶段：包括用户沟通和建模活动，重点是创建分析和设计模型，强调类的定义和体系结构的表示。
构建阶段：将设计转为实现，并进行集成和测试。
移交阶段：将产品发布给用户进行测试评价。收集用户意见，迭代更新。
敏捷开发
敏捷开发是一种以人为核心、迭代、循序渐进的开发方法，适合小型项目。
极限编程（XP）
一些对费用控制严格的公司使用。四大价值观（沟通【加强面对面沟通】、简单【不过度设计】、反馈【及时反馈】、勇气【接受变更的勇气】）十二大最佳实践（简单设计、测试驱动、代码重构、结对编程、持续集成、现场客户、发行版本小型化、系统隐喻、代码集体所有制、规划策略、规范代码、40小时工作机制）。
水晶方法
探索了用最少纪律约束而仍能成功的方法，从而在产出效率与易于运作上达到一种平衡。
开放式源码
程序开发人员在地域上分布很广
SCRUM
明确定义了可重复的方法过程