七、架构权衡分析法：ATAM（Architecture Tradeoff Analysis Method）
评价软件架构的一种综合全面的方法。这种方法不仅可以揭示出构架满足特定质量目标的情况，而且（因为它认识到了构架决策会影响多个质量属性）可以使我们更清楚地认识到质量目标之间的联系——即如何权衡诸多质量目标。
1、ATAM参与人员
评估小组、项目决策者、构架涉众
2、ATAM的结果
ATAM评估将产生至少如下结果：一个简洁的构架表述；表述清楚的业务目标；用场景集合捕获的质量需求；构架决策到质量需求的映射；所确定的敏感点和权衡点集合；有风险决策和无风险决策；风险主题的集合。
3、ATAM的目标
分析多个质量属性间的关系，属性间可能存在冲突，需要权衡取舍。按照质量属性需求，评价体系结构设计。
4、ATAM的阶段
关系和准备：参与人员为评估小组负责人和主要的项目决策者，根据要求进行，大概需要几周的时间。
评估：参与人员为评估小组和项目决策者，一般需要1周，还有2~3周的中断时间。包括以下步骤：ATAM方法的表述；商业动机的表述；构架的表述；对构架方法进行分类；生成质量属性效用树；分析构架方法。
评估（继续）：参与人员为评估小组、项目决策者以及涉众，一般需要2天。包括以下步骤：集体讨论并确定场景的优先级；分析构架方法；结果的表述；
后续工作：参与人员为评估小组和评估客户，一般需要一周。
八、DSSA(Domain Specific Software Architecture)特定领域软件架构
特定领域软件架构师在一个特定应用领域为一组应用提供组织结构参考的标准软件架构。实施DSSA的过程包括一系列基本活动，其中领域设计活动的主要目的是获得DSSA，该活动参与人员中，领域专家的主要任务是提供关于领域中系统的需求规约和实现的知识。
DSSA与软件体系结构风格是从不同角度出发研究问题的两种结果，前者从问题域出发，后者从解决域出发。
DSSA只对某个领域进行专家知识的提取、存储、组织，但可以同时使用多种软件体系结构风格；而在某个软件体系结构风格中进行专家知识组织时，可以将提取的公共结构和设计方法扩展到多个应用领域。
DSSA通常选用一个或多个适合所研究的领域的体系结构风格，并设计一个该领域专用的体系结构分析设计工具。但该方法提取的专家知识只能应用于一个较小的范围－－所在领域。一个领域的
DSSA及其工具在另一个领域中是不适应的，或不可以重用的。
体系结构风格避免设计到特定的应用领域或背景，所提取的知识比DSSA提取的知识应用范围要广。但在一个特定领域中，正是由于体系结构风格对领域知识、领域背景的忽略，使其在一个具体领域的开发中的作用并不比DSSA要大。
DSSA与体系结构风格是互为补充的两种技术。
九、常见算法
1、对称算法：DES（Data Encryption Standard，数据加密标准）、IDEA（International Data Encryption Algorithm国际数据加密算法）
2、不对称算法：RSA、ECC
3、散列函数（摘要算法）：MD5（Message Digest 5）
4、数字签名：RSA、ElGamal、Fiat-Shamir、DSS/DSA、椭圆曲线
5、数字水印：空域算法、变换域算法、压缩域算法、NEC算法、生理模型算法等
6、安全协议：Ipsec（跨越网络边界的通信）、Secure Socket Layer：SL协议（计算机之间的整个会话进行加密）、RGP（Pretty Good Privacy 电子邮件在Internet上的通信安全）
十、数据备份
1. 完全备份，所需时间最长，但恢复时间最短，操作最方便可靠。
2. 差异备份，备份上一次的完全备份后发生变化的所有文件。备份时间较长，占用空间较多，恢复时间
较短。
3. 增量备份，上一次备份后，所有发生变化的文件。备份时间较短，占用空间较少，恢复时间较长。
4. 按需备份。有很好的选择性。
十一、测试方法
1、恢复测试：检测系统的容错能力。
2、安全性测试：检测系统的安全机制。
3、强度测试：系统在异常情况下的承受能力的测试，是检测系统在极限状态下运行，性能下降的幅度是都在允许的范围内。
4、性能测试：检测系统是否满足系统设计方案说明书对性能的要求。
5、可靠性测试：平均失效间隔时间（mean time between failures）是否超过了规定的时限、因故障而停机时间MTTR（mean time to repairs）在一年中不应超过多少时间。
6、安装测试：检测在安装过程中是否有误、是否容易操作。
7、确认测试：α测试（开发阶段）和β测试（实际使用阶段）
十二、ABSD（Architecture Based Sofaware Development）基于软件架构的设计
强调由商业、质量和功能需求的组合驱动软件架构设计。强调采用视角和试图来描述软件架构，采用用例和质量属性场景来描述需求。
十三、RUP软件开发
RUP软件开发生命周期是一个二维的软件开发模型，其中有9个核心工作流，分别是：业务建模、需求、分析与设计、实现、测试部署、配置与变更管理、项目管理以及环境。
RUP把软件开发生存周期划分为多个循环，每个循环生成产品的一个新的版本，每个循环依次由4个连续的阶段组成，每个阶段完成确定的任务。这4个阶段分别为：
1、初始阶段：定义最终产品试图和业务结构，并确定系统范围；
2、细化阶段：设计及确定系统的体系结构，制定工作计划及资源要求；
3、构造阶段：构造产品并继续演进需求、体系结构、计划直至产品提交；
4、移交阶段：把产品提交各用户使用。
十四、数据流图和流程图
数据流图作为一种图形化工具，用来说明业务处理过程、系统边界内所包含的功能和系统中的数据流。
流程图以图形化的方式展示应用程序从数据输入开始到获得输出为止的逻辑过程，描述处理过程的控制流。
两者的区别：
1、数据流图中的处理过程可并行；流程图在某个时间点只能处于一个处理过程。
2、数据流图展示系统的数据流；流程图展示系统的控制流；
3、数据流图展现全局的处理过程，过程之间遵循不同是计时标准；流程图中处理过程遵循一直的计时标准；
4、数据流图适用于系统分析中的逻辑建模阶段；流程图适用于系统设计中的物理建模阶段。
高质量数据流图设计时考虑的三个原则：
1、复杂性最小化原则。DFD分层结构就是把信息划分为小的且相对独立的一大批子集例子，这样就可以单独考察每一个DFD。如果要了解某个过程更加详细的信息，可以跳转到该过程的下一层；如果要知道一个DFD如何与其他DFD相关联，可以跳转到上一层的DFD记性考查。
2、接口最小化原则。接口最小化是复杂性最小化的一种具体规则，在设计模型时，应使得模型中各个元素之间的接口数或连接数最小化。
3、数据流一致性原则。一个过程和它的过程分解在数据流内容中是否有差别？是否存在有数据流出但没有相应的数据流入的加工？是否存在有数据流入但没有相应的数据流出的加工？