第六章 数据库设计基础知识
数据库概念
DBS(DataBase System): 数据库系统
DBMS(DataBase Management System)：数据库管理系统
DB(DataBase)：数据库
DDL(Data Definition Language):数据定义语言
DML(Data Manipulation Language):数据操纵语言
数据库的基础结构是数据模型，是用来描述数据的一组概念和定义，数据模型的三要素：数据结构、数据操作和约束条件
数据库三级模式
数据库三级模式：视图层、逻辑层和物理层
1.视图层(View Level)描述整个数据库的某个部分的数据
2.逻辑层(Logical Level)描述数据库中存储的数据以及这些数据间存在的关系
3.物理层(Physical Level)描述数据在存储器中是如何存储的
从DBMS(数据库管理系统)的角度，数据库也分为三级模式，分别是外模式，概念模式和内模式，和数据库三级模式对应
1.外模式也成用户模式或子模式，是用户与数据库系统的接口，
2.概念模式也成模式，是全部数据的逻辑结构和特征的描述，表现为表
3.内模式也称为存储模式，是数据物理结构和存储方式的描述，表现为磁盘中存储的文件
数据库范式
1NF：每个属性不可再分
2NF：在满足1NF的基础上，有主键能唯一的区分每行数据
3NF：在满足2NF的基础上，不能包含其他表的非主属性，比如员工表有部门表的id，不允许存在部门名称和部门简介等
BCNF(Boyer-Codd Normal Form)：是3NF的子集，满足3NF的基础上，非主属性不能对主键子集依赖
4NF：在满足BCNF的基础上，限制关系模式的属性间不允许有非平凡且费函数依赖的多值依赖
其他
概念结构设计
E-R(Entity-Relationship Approach)：用E-R模型将现实世界的信息结构统一由实体、属性，以及实体之间的联系来描述
反规范化
在关系模式的规范化过程中，往往设计多表关联查询，导致性能下降，因此需要反规范化来进行修正，常见的反规范化操作有冗余列、派生列、表重组和表分割，其中表分割又分为水平分割和垂直分割
第七章 系统架构设计基础知识
软件架构的重要性：架构设计的过程使得不同的受益人达成一致的目标，体系架构的设计过程需要确保架构设计 被清楚地表达与理解。一个被有效传达的架构
基于架构的软件开发方法
ABSD概述
基于体系结构的软件设计(Architecture-Based Sofware Design，ABSD)方法。ABSD方法是由体系结构驱动的，即指由构成体系结构的商业、质量和功能需求的组合驱动的。使用ABSD方法，设计活动可以从项目总体功能框架明确就开始，这意味着需求抽取和分析还没有完成(甚至远远没有完成)，就开始了软件设计。设计活动的开始并不意味着需求抽取和分析活动就可以终止，而是应该与设计活动并行。特别是在不可能预先决定所有需求时(例如，产品线系统或长期运行的系统)，快速开始设计是至关重要的。
ABSD方法有3个基础。第1个基础是功能的分解。在功能分解中，ABSD方法使用已有的基于模块的内聚和耦合技术。第2个基础是通过选择体系结构风格来实现质量和商业需求第3个基础是软件模板的使用，软件模板利用了一些软件系统的结构。
ABSD方法是递归的，且迭代的每一个步骤都是清晰定义的。因此，不管设计是否完成，体系结构总是清晰的，这有助于降低体系结构设计的随意性。
设计元素：ABSD方法是一个（自顶向下，递归细化）的方法，通过该方法得到细化，直到能产生（软件构件和类）
视角与视图
视角与视图：考虑体系结构时，要从不同的视角(Perspective)来观察对架构的描述，这需要软件设计师考虑体系结构的不同属性。例如：展示功能组织的静态视角能判断质量特性，展示并发行为的动态视角能判断系统行为特性，使用逻辑视图来记录设计元素的功能和概念接口，设计元素的功能定义了它本身在系统中的角色，这些角色包括功能、性能等。
用例和质量场景
用例和质量场景：用例是系统的一个给予用户一个结果值的功能点，用来捕获功能需求。人们使用质量场景捕获变更、性能、可靠性和交互性，分别称之为变更场景、性能场景、可靠性场景和交互性场景。质量场景必须包括预期的和非预期的场景
基于体系结构的开发模型
传统的软件开发过程可以划分为：问题定义、需求分析、软件设计、软件实现及软件测试等。如果采用传统的软件开发模型，软件体系结构的建立应位于需求分析之后，概要设计之前。传统软件开发模型存在开发效率不高，不能很好地支持软件重用等缺点。ABSD模型把整个基于体系结构的软件过程划分为体系结构需求、设计、文档化、复审、实现和演化6个子过程
体系结构需求
需求获取：体系结构需求一般来自3个方面，分别是系统的质量目标、系统的商业目标和系统开发人员的商业目标
标识构件3步曲：1.生成类图 2.对类进行分组 3.把类打包成构件
架构需求评审：审查的主要内容包括需求是否真实地反映了用户的要求，类的分组是否合理，构件合并是否合理等
体系结构设计
体系结构需求用来激发和调整设计决策，不同的视图用来表达与质量目标有关的信息。
设计体系设计过程如下：
1.题出软件体系结构模型
2.把已标识的构件映射到软件体系结构中
3.分析构件之间的相互作用
4.产生软件体系结构
5.设计评审
体系结构文档化
体系结构文档化过程的主要输出结果是：（体系结构规格说明）和（测试体系结构需求的质量设计说明书）
文档要从使用者的角度进行编写，必须分发给所有与系统有关的开发人员，且必须保证开发者手上的文档是最新的
体系结构复审
体系结构设计、文档化和复审是一个迭代过程，在一个主版本的软件体系结构分析之后，要安排一次由外部人员（用户代表和领域专家）参加的复审。鉴于体系结构文档标准化以及风险识别的现实情况，通常人们根据架构设计，搭建一个可运行的最小化系统用于评估和测试体系架构是否满足需要，是否存在可识别的技术和协作风险。复审的目的是标识潜在的风险，及早发现体系结构设计中的缺陷和错误，包括体系结构能否满足需求、质量需求是否在设计中得到体现、层次是否清晰、构件的划分是否合理、文档表达是否明确、构件的设计是否满足功能与性能的要求等
体系结构实现
整个实现过程是以复审后的文档化的体系结构说明书为基础的，每个构件必须满足软件体系结构中说明的对其他构件的责任。这些决定即实现的约束是在系统级或项目范围内给出的，每个构件上工作的实现者是看不见的。
在体系结构说明书中，已经定义系统中的构件与构件之间的关系。因为在体系结构层次上，构件接口约束对外唯一地代表了构件，所以可以从构件库中查找符合接口约束的构件，必要时开发新的满足要求的构件。然后，按照设计提供的结构，通过组装支持工具把这些构件的实现体组装起来，完成整个软件系统的连接与合成。
最后一步是测试，包括单个构件的功能性测试和被组装的应用的整体功能和性能测试。
体系结构的演化
主要包括6个步骤
1.需求变化归类
首先必须对用户需求的变化进行归类，使变化的需求与已有构件对应。对找不到对应构件的变动，也要做好标记，在后续工作中，将创建新的构件，以对应这部分变化的需求。
2.制订体系结构演化计划
在改变原有结构之前，开发组织必须制订一个周密的体系结构演化计划，作为后续演化开发工作的指南。
3.修改、增加或删除构件
在演化计划的基础上，开发人员可根据在第1步得到的需求变动的归类情况，决定是否修改或删除存在的构件、增加新构件。最后，对修改和增加的构件进行功能性测试。
4.更新构件的相互作用
随着构件的增加、删除和修改，构件之间的控制流必须得到更新。
5.构件组装与测试
通过组装支持工具把这些构件的实现体组装起来，完成整个软件系统的连接与合成，形成新的体系结构。然后对组装后的系统整体功能和性能进行测试。
6.技术评审
对以上步骤进行确认，进行技术评审。评审组装后的体系结构是否反映需求变动、符合用户需求。如果不符合，则需要在第2到第6步之间进行迭代。
在原来系统上所做的所有修改必须集成到原来的体系结构中，完成一次演化过程
软件架构风格
数据流体系结构风格
(1)批处理体系结构风格: 每个处理步骤是一个独立的程序,每一步必须在前一步结束后才能开始,且数据必须完整,以整体的方式传递.
(2)管道和过滤器: 把系统分为几个序贯的处理步骤,每个步骤之间通过数据流连接,一个步骤的输出是另一个步骤的输入,每个处理步骤都有输入和输出.
开始
A
B
C
D
结束
调用/返回体系结构风格
(1)主程序/子程序风格: 采用单线程控制,把问题划分为若干处理步骤,构件即为主程序和子程序
(2)面向对象体系结构风格: 构件是对象,即抽象数据类型的实例
对象1
对象2
对象3
(3)层次体系结构风格: 每一层为上层服务,并作为下层的接口.仅相邻层间具有接口
(4)客户端/服务器体系结构风格:
-
二层C/S模式.主要组成部分:数据库服务器,客客户应用程序和网络
- 优点: 客户应用和服务器构建分别运行在不同的计算机上
- 缺点: 开发成本高,客户端设计复杂,信息内容和形式单一,不利于推广,软件移植困难,软件维护和升级困难
-
三层C/S模式: 瘦客户端模式.应用概念功能分为表示层,功能层和数据层
- 表示层:用户接口与应用逻辑层的交互,不影响业务逻辑,通常使用图形用户界面
- 功能层:实现具体的业务处理逻辑
- 数据层:数据库管理系统
(5)浏览器/服务器风格
- B/S风格: 是三层应用结构的实现方式,其三层结构分别为:浏览器,Web服务器,数据库服务器.
- 相比于C/S的不足之处:动态页面的支持能力弱,系统拓展能力差,安全性难以控制,响应速度不足,数据交互性不强.
以数据为中心的体系结构风格
(1)仓库体系结构风格: 出存储和维护数据的中心场所.由中央数据结构和一组独立构件组成.
(2)黑板体系结构分割: 是一种问题求解模型,是组织推理步骤,控制状态数据和问题求解之领域知识的概念框架.可通过选取各种黑板,知识源和控制模块的构件来设计,应用于信号处理领域,如育婴识别和模式识别
虚拟机体系结构风格
(1)解释器体系结构风格: 通常被用来建立一种虚拟机以弥合程序语义与硬件语义之间的差异,缺点是执行效率较低,典型例子是专家系统
(2)规则系统体系结构风格: 包括知识库,规则解释器,规则/数据选择器及工作内存
独立构件体系结构风格
(1)进程通信体系结构风格: 构件是独立的过程,连接件是消息传递
(2)时间系统体系结构风格: 构件不直接调用一个过程,而是触发或广播一个或多个事件
C2风格
C2风格通过连接件连接构件或某个构建组,构件与构件之间无连接
1.软件体系结构是特定软件系统组织方式的惯用模式.组织方式描述了系统的构件和构件的组织方式,惯用模式反映了众多系统共有的结构和语义
2.调用/返回风格在系统中采用了调用与返回机制.利用调用/返回实际上是一种分而治之的策略,主要思想是将一个复杂的大系统分解为若干个子系统,降低复杂度,增加可修改性
3.虚拟机体系结构风格基本思想是人为构件一个运行环境,可以解析与运行自定义的一些语言,增加架构的灵活性
[4] 独立构件体系结构风格强调系统中的每个构件都是相对独立的各题,它们之间不直接通信,以降低耦合度,提升灵活性
软件架构复用
软件产品线定义
软件产品线是指一组软件密集型系统，它们共享一个公共的、可管理的特性集，满足某个特定市场或任务的具体需要，是以规定的方式用公共的核心资产集成开发出来的，即围绕核心资产库进行管理、复用、集成新的系统。核心资产库包括软件架构及其可剪裁的元素，更广泛地，它还包括设计方案及其文档、用户手册、项目管理的历史记录（如预算和进度）、软件测试计划和测试用例。复用核心资产（特别是软件架构），更进一步采用产品线将会惊人地提高生产效率、降低生产成本和缩短上市时间。
软件架构复用定义
软件复用是指系统化的软件开发过程：开发一组基本的软件构造模块，以覆盖不同的需求/体系结构之间的相似性，从而提高系统开发的效率、质量和性能。软件父用是一种系统化的软件开发过程，通过事别、开发、分类、获取和修改软件实体，以便在不同的软件开发过程中重复的使用它们。
软件架构复用类型
软件架构复用的类型包括（机会复用）和（系统复用）：
机会复用是指开发过程中，只要有可复用的资产，就对其进行复用
系统复用是指在开发之前，就要进行规划，以决定哪些需要复用
软件架构复用原因
软件架构复用可以减少开发工作、减少开发时间以及降低开发成本，提高生产力。不仅如此，它还可以提高产品质量使其具有更好的互操作性。同时，软件架构复用会使产品维护变得更加简单
软件复用对象及形势
软件架构复用的对象及形式，包括以下几个方面：
(1)需求。许多需求与早期开发的系统相同或部分相同，如网上银行交易与银行柜面交易。
(2)架构设计。原系统在架构设计方面花费了大量的时间与精力，系统成功验证了架构的合理性，如果新产品能复用已有的架构，将会取得很好的效益。
(3)元素。元素复用不只是简单的代码复用，它旨在捕获并复用设计中的可取之处，避免(不要重复)设计失败的地方。
(4)建模与分析。各类分析方法(如性能分析)及各类方案模型(如容错方案、负载均衡方案)都可以在产品中得到复用。
(5)测试。采用产品线可积累大量的测试资源，即在考虑测试时不是以项目为单位，而是以产品线为单位。这样整个测试环境都可以得到复用，如测试用例、测试数据、测试工具，甚至测试计划、过程、沟通渠道都可以得到复用。
(6)项目规划。利用经验对项目的成本、预算、进度及开发小组的安排等进行预测，即不必每次都建立工作分解结构。
(7)过程、方法和工具。有了产品线这面旗帜，企业就可以建立产品线级的工作流程、规范、标准、方法和工具环境，供产品线中所有产品复用。如编码标准就是一例。
(8)人员。以产品线来培训的人员，适应于整个系列的各个产品的开发。
(9)样本系统。将已部署(投产)的产品作为高质量的演示原型和工程设计原型。
(10)缺陷消除。产品线开发中积累的缺陷消除活动，可使新系统受益，特别是整个产品家族中的性能、可靠性等问题的一次性解决，能取得很高的回报。同时也使得开发人员和客户心中有“底”。
一般形式的复用主要包括函数的复用，库的复用(比如在C、C++语言中)，以及在面向对象开发中的类、接口和包的复用。可以看出，在当前的趋势下，复用体由小粒度向大粒度的方向发展。
软件架构复用的基本过程
主要包括3个阶段：（构造/获取）可复用的软件资产、（管理）资产、（复用）资产
1.复用的前提:获取可复用的软件资产
首先需要构造恰当的、可复用的资产，并且这些资产必须是可靠的、可被广泛使用的、易于理解和修改的。
2.管理可复用资产
该阶段最重要的是:构件库(ComponentLibrary)，由于对可复用构件进行存储和管理，它是支持软件复用的必要设施。构件库中必须有足量的可复用构件才有意义。构件库应提供的主要功能包括构件的存储、管理、检索以及库的浏览与维护等，以及支持使用者有效地、准确地发现所需的可复用构件。
在这个过程中，存在两个关键问题:一是构件分类，构件分类是指将数量众多的构件按照某种特定方式组织起来;二是构件检索，构件检索是指给定几个查询需求，能够快速准确地找到相关构件。
3.使用可复用资产
在最后阶段，通过获取需求，检索复用资产库，获取可复用资产，并定制这些可复用资产:修改、扩展、配置等，最后将它们组装与集成，形成最终系统。
特定领域软件体系结构
DSSA的定义
DSSA（Domain Specific Software Architecture）是在一个特定应用领域中为一组应用提供组织结构参考的标准软件体系结构
DSSA的必备特征如下：
1.一个严格定义的问题域和问题解域
2.具有普遍性，使其可以用于领域中某个特定应用的开发
3.对整个领域的构件组织模型的恰当抽象
4.具备该领域固定的、典型的在开发过程中可重用元素
一般的DSSA的定义并没有对领域的确定和划分给出明确说明。从功能覆盖的范围的角度有两种理解DSSA中领域的含义的方式：
（1）垂直域：定义了一个特定的系统族，包含整个系统族内的多个系统，结果是在该领域中可作为系统的可行解决方案的一个通用软件体系结构
（2）水平域：定义了在多个系统和多个系统族中功能区域的共有部分。在子系统上涵盖多个系统族的特定部分功能
DSSA的基本活动
3个阶段：
1.领域分析
主要目标是获得（领域模型）。领域模型描述领域中系统之间的共同需求，即领域模型所描述的需求为领域需求
2.领域设计
主要目标是获得（DSSA，特定领域软件体系结构）。DSSA描述在领域模型中表示的需求的解决方案，它不是单个系统的表示，而是能够适应领域中多个系统的需求的一个高层次的设计。建立了领域模型之后，就可以派生出满足这些被建模的领域需求的DSSA
3.领域实现
主要目标是依据领域模型和DSSA（开发和组织可重用信息）。这些可重用信息可能是从现有系统中提取得到，也可能需要通过新的开发得到。
以上过程是一个反复的、逐渐求精的过程
DSSA的建立过程
DSSA的建立过程分为5个阶段，每个阶段可以进一步划分为一些步骤或子阶段。每个阶段包括一组需要回答的问题，一组需要的输入，一组将产生的输出和验证标准。本过程是并发的(Concurrent)、递归的(Recursive)、反复的(Iterative)。或者可以说，它是螺旋模型(Spiral)。完成本过程可能需要对每个阶段经历几遍，每次增加更多的细节。
(1)定义领域范围。本阶段的重点是确定什么在感兴趣的领域中以及本过程到何时结束。这个阶段的一个主要输出是领域中的应用需要满足一系列用户的需求。
(2)定义领域特定的元素。本阶段的目标是编译领域字典和领域术语的同义词词典。在领域工程过程的前一个阶段产生的高层块圈将被增加更多的细节，特别是识别领域中应用间的共同性和差异性。
(3)定义领域特定的设计和实现需求约束。本阶段的目标是描述解空间中有差别的特性。不仅要识别出约束，并且要记录约束对设计和实现决定造成的后果，还要记录对处理这些问题时产生的所有问题的讨论。
(4)定义领域模型和体系结构。本阶段的目标是产生一般的体系结构，并说明构成它们的模块或构件的语法和语义。
(5)产生、搜集可重用的产品单元。本阶段的目标是为DSSA增加构件，使它可以被用来产生问题域中的新应用。
DSSA 的建立过程是并发的、递归的和反复进行的。该过程的目的是将用户的需求映射为基于实现限制集合的软件需求，这些需求定义了DSSA。在此之前的领域工程和领域分析过程
第八章 系统质量属性与架构评估
软件系统质量属性
软件系统属性包括功能属性和质量属性，软件架构重点关注的是质量属性。为了精确、定量地表达系统的质量属性，通常会采用质量属性场景的方式进行描述
质量属性概念
软件系统质量是软件与开发标准等特征相一致的程度，根据GB/T 16260.1定义，从管理角度对软件系统质量进行度量，可将影响软件质量的主要因素划分为6种维度特性：（功能性、可靠性、易用性、效率、维护性和可移植性）。
其中功能性包括：适应性、准确性、互操作性、依从性、安全性；
可靠性包括：容错性、易恢复性、成熟性；
易用性包括：易学性、易理解性、易操作性；
效率包括：资源特性和时间特性；
维护性包括：可测试性、可修改性、稳定性和易分析性；
可移植性包括：适应性、易安装性、一致性和可替换性
软件系统质量属性（Quality Attribute）是一个系统的可测量或者可测试的属性，用来描述系统满足利益相关者（Stakeholders）需求的程度。基于软件系统的生命周期，可以将软件系统的质量属性分为开发期主梁属性和运行期质量属性2个部分
1.开发期质量属性
开发期质量属性主要指在软件开发阶段所关注的质量属性，主要包含6个方面。
(1)易理解性:指设计被开发人员理解的难易程度。
(2)可扩展性:软件因适应新需求或需求变化而增加新功能的能力，也称为灵活性。
(3)可重用性:指重用软件系统或某一部分的难易程度。
(4)可测试性:对软件测试以证明其满足需求规范的难易程度，
(5)可维护性:当需要修改缺陷、增加功能、提高质量属性时，识别修改点并实施修改的难易程度。
(6)可移植性:将软件系统从一个运行环境转移到另一个不同的运行环境的难易程度
2.运行期质量属性
运行期质量属性主要指在软件运行阶段所关注的质量属性，主要包含7个方面。
(1)性能:性能是指软件系统及时提供相应服务的能力，如速度、吞吐量和容量等的要求。
(2)安全性:指软件系统同时兼顾向合法用户提供服务，以及阻止非授权使用的能力。
(3)可伸缩性:指当用户数和数据量增加时，软件系统维持高服务质量的能力。例如，通过增加服务器来提高能力。
(4)互操作性:指本软件系统与其他系统交换数据和相互调用服务的难易程度。
(5)可靠性:软件系统在一定的时间内持续无故障运行的能力。
(6)可用性:指系统在一定时间内正常工作的时间所占的比例。可用性会受到系统错误恶意攻击，高负载等问题的影响。
(7)鲁棒性:是指软件系统在非正常情况(如用户进行了非法操作、相关的软硬件系统发生了故障等)下仍能够正常运行的能力，也称健壮性或容错性。
面向架构评估的质量属性
1.性能
性能(Performance)是指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段事件内系统所能处理的事件的个数。经常用单位时间内所处理事务的数量或系统完成某个事务处理所需的时间来对性能进行定量表示。性能测试经常要使用基准测试程序。
2.可靠性
可靠性(Reliability)是软件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统的功能特性的基本能力。可靠性是最重要的软件特性，通常用来衡量在规定的条件和时间内，软件完成规定功能的能力。可靠性通常用平均失效等待时间(MeanTime To Failure,MTTF)和平均失效间隔时间(MeanTime Between Failure，MTBF)来衡量。在失效率为常数和修复时间很短的情况下，MTTF和MTBF几乎相等。可靠性可以分为两个方面。
(1)容错。容错的目的是在错误发生时确保系统正确的行为，并进行内部“修复”。例如在一个分布式软件系统中失去了一个与远程构件的连接，接下来恢复了连接。在修复这样的错误之后，软件系统可以重新或重复执行进程间的操作，直到错误再次发生。
(2)健壮性。这里说的是保护应用程序不受错误使用和错误输入的影响，在发生意外错误事件时确保应用系统处于预先定义好的状态。值得注意的是，和容错相比，健壮性并不是说在错误发生时软件可以继续运行，它只能保证软件按照某种已经定义好的方式终止执行。软件架构对软件系统的可靠性有巨大的影响。例如，软件架构设计上通过在应用程序内部采用冗余机制，或集成监控构件和异常处理，以提升系统可靠性。
3.可用性
可用性(Availability)是系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。
4.安全性
安全性(Security)是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。安全性可根据系统可能受到的安全威胁类型来分类。安全性又可划分为机密性、完整性、不可否认性及可控性等特性。其中，机密性保证信息不泄露给未授权的用户、实体或过程;完整性保证信息的完整和准确，防止信息被非法修改;不可否认性是指信息交换的双方不能否认其在交换过程中发送信息或接收信息的行为:可控性保证对信息的传播及内容具有控制的能力，防止为非法者所用。
5.可修改性
可修改性(Modifability)是指能够快速地以较高的性价比对系统进行变更的能力。通常以某些具体的变更为基准，通过考查这些变更的代价来衡量可修改性。可修改性包含以下4个方面。
(1)可维护性(Maintainability)。这主要体现在问题的修复上，在错误发生后“修复”软件系统。可维护性好的软件架构往往能做局部性的修改并能使对其他构件的负面影响最小化。
(2)可扩展性(Extendibility)。这一点关注的是使用新特性来扩展软件系统，以及使用改进版本方式替换构件并删除不需要或不必要的特性和构件。为了实现可扩展性，软件系统需要松散耦合的构件。其目标是实现一种架构，能使开发人员在不影响构件客户的情况下替换构件。支持把新构件集成到现有的架构中也是必要的。
(3)结构重组(Reassemble)。这一点处理的是重新组织软件系统的构件及构件间的关系，例如通过将构件移动到一个不同的子系统而改变它的位置。为了支持结构重组，软件系统需要精心设计构件之间的关系。理想情况下，它们允许开发人员在不影响实现的主体部分的情况下灵活地配置构件。
(4)可移植性(Portability)。可移植性使软件系统适用于多种硬件平台、用户界面、操作系统、编程语言或编译器。为了实现可移植，需要按照硬件、软件无关的方式组织软件系统。可移植性是系统能够在不同计算环境下运行的能力，这些环境可能是硬件、软件，也可能是两者的结合。如果移植到新的系统需要做适当更改，则该可移植性就是一种特殊的可修改性。
6.功能性
功能性(Functionality)是系统能完成所期望的工作的能力。一项任务的完成需要系统中许多或大多数构件的相互协作。
7.可变性
可变性(Changeability)是指架构经扩充或变更而成为新架构的能力。这种新架构应该符合预先定义的规则，在某些具体方面不同于原有的架构。当要将某个架构作为一系列相关产品(例如，软件产品线)的基础时，可变性是很重要的。
8.互操作性
作为系统组成部分的软件不是独立存在的，通常与其他系统或自身环境相互作用。为了支持互操作性，软件架构必须为外部可视的功能特性和数据结构提供精心设计的软件入口。程序和用其他编程语言编写的软件系统的交互作用就是互操作性的问题，这种互操作性也影响应用的软件架构。
质量属性场景描述
为了精确描述软件系统的质量属性，通常采用质量属性场景(QualityAttribute Scenario)作为描述质量属性的手段。质量属性场景是一个具体的质量属性需求，是利益相关者与系统的交互的简短陈述。
质量属性场景是一种面向特定质量属性的需求。它由6部分组成:
刺激源(Soumce):这是某个生成该刺激的实体(人、计算机系统或者任何其他刺激器)。
刺激(Stimulus):该刺激是当刺激到达系统时需要考虑的条件。
环境(Environment):该刺激在某些条件内发生。当激励发生时，系统可能处于过载运行或者其他情况。
制品(Artifact):某个制品被激励。这可能是整个系统，也可能是系统的一部分。
响应(Response):该响应是在激励到达后所采取的行动。
响应度量(Measurement):当响应发生时，应当能够以某种方式对其进行度量，以对需求进行测试。
系统架构评估
系统架构评估方法
系统架构评估是在对架构分析、评估的基础上，对架构策略的选取进行决策。它利用数学或逻辑分析技术，针对系统的一致性、正确性、质量属性、规划结果等不同方面，提供描述性、预测性和指令性的分析结果。
系统架构评估的方法通常可以分为3类:基于调查问卷或检查表的方式、基于场景的方式和基于度量的方式。
(1)基于调查问卷或检查表的方法。该方法的关键是要设计好问卷或检查表，充分利用系统相关人员的经验和知识，获得对架构的评估。该方法的缺点是在很大程度上依赖于评估人员的主观推断。
(2)基于场景的评估方法。它是通过分析软件架构对场景(也就是对系统的使用或修改活动)的支持程度，从而判断该架构对这一场景所代表的质量需求的满足程度。
(3)基于度量的评估方法。它是建立在软件架构度量的基础上的，涉及3个基本活动，首先需要建立质量属性和度量之间的映射原则，然后从软件架构文档中获取度量信息，最后根据映射原则分析推导出系统的质量属性。
系统架构评估中的重要概念
（1）敏感点（Sensitivity Point）和权衡点（Tradeoff Point）。敏感点是一个或多个构件的特性，研究敏感点可使设计人员或分析员明确在搞清楚如何实现质量属性目标时应注意什么。权衡点是影响多个质量属性的特性，是多个质量属性的敏感点。例如，改变加密级别可能会对安全性和性能产生非常重要的影响。提高加密级别可以提高安全性，但可能要耗费更多的处理时间，影响系统性能。如果某个机密消息的处理有严格的时间延迟要求，则加密级别可能就会成为一个权衡点。
（2）风险承担者（Stakeholders）或称为利益相关人
（3）场景（Scenarios）。在进行架构评估时，一般首先要精确地得出具体的质量目标，并以之作为判定该架构优劣的标准。为得出这些目标而采用的机制称之为场景。场景是从风险承担者的角度对与系统的交互的简短描述。在架构评估中，一般采用刺激（Stimulus）、环境（Environment）和响应（Response）三方面来对场景进行描述
SAAM方法
SAAM（Scenarios-based/Software Architecture Analysis Method）体系结构分析方法
SAAM分析评估架构的过程包括5个步骤，即场景开发、架构描述、单个场景评估、场景交互和总体评估
用一种易于理解的、合乎语法规则的架构描述软件架构，体现系统的计算构件、数据构件以及构件之间的关系(数据和控制)。对场景(直接场景和间接场景)生成一个关于特定架构的场景描述列表。通过对场景交互的分析，能得出系统中所有场景对系统中的构件所产生影响的列表。最后，对场景和场景间的交互作一个总体的权衡和评价。
ATAM方法
架构权衡分析方法（Architecture Tradeoff Analysis Method，ATAM）是再SAAM的基础上发展起来的，主要针对性能、实用性、安全性和可修改性，在系统开发之前，对这些质量属性进行评价和折中
方法的活动。ATAM被分为4个主要的活动领域，分别是场景和需求收集、架构视图和场景实现、属性模型构造和分析、折中
ATAM方法采用效用树（Utility tree）这一工具来对质量属性进行分类和优先级排序。效用树的结构包括：树根-质量属性-属性分类-质量属性场景（叶子节点）。ATAM最关注的4个质量属性：性能、安全性、可修改性和可用性
CBAM方法
成本效益分析法（the Cost Benefit Analysis Method，CBAM）是在ATAM桑构件，对构架设计决策的成本和收益进行建模，优化此类决策的一种手段。CBAM的思想就是架构策略影响系统的质量属性，反过来这些质量属性又会为系统的项目干系人带来一些收益(称为“效用”)，CBAM 协助项目干系人根据其投资回报(Return On Investment，ROI)选择架构策略。CBAM在 ATAM 结束时开始，它实际上使用了 ATAM 评估的结果。
ATAM方法架构评估实践
没什么好说的
第九章 软件可靠性基础知识
软件可靠性基本概念
MTBF（Mean Time Between Failures，平均故障间隔时间）定义为：失效或维护中所需的平均时间，包括故障时间以及检测和维护设备的时间
可靠性测试的意义
1.软件失效可能造成灾难性的后果
2.软件的失效在震哥哥计算机系统失效中的比例较高
3.相比硬件可靠性技术，软件可靠性技术很不成熟
4.与硬件元器件成本急剧下降形成鲜明对比的是，软件费用有增无减
5.系统对软件依赖性越来越强，对生产活动和社会活动的影响越来越大，从而增加了软件可靠性在整个计算机工程领域的重要性
软件可靠性问题的重要性凸显了发展以发现软件可靠性缺陷为目的的可靠性设计与测试技术的迫切性
广义的可靠性测试与侠义的可靠性测试
广义的软件可靠性测试是指为了最终评价软件系统的可靠性而云用建模、统计、试验、分析和评价等一系列手段对软件系统实施的一种测试
狭义的软件可靠性测试是指为了获取可靠性数据，按预先确定的测试用例，在软件的预期使用环境中，对软件实施的一种测试
可靠性测试的目的
(1)发现软件系统在需求、设计、编码、测试和实施等方面的各种缺陷
(2)为软件的使用和维护提供而可靠性数据
(3)确认软件是否达到可靠性的定量要求
软件可靠性建模
软件可靠性模型
软件可靠性模型（Software Reliability Model）是指为预计或估算软件的可靠性所建立的可靠性框图和数学模型。建立可靠性模型是为了将复杂系统的可靠性逐级分解为简单系统的可靠性，以便于定量预计、分配、估算和评价复杂系统的可靠性。
影响软件可靠性的因素
影响软件可靠性的因素是纷杂而众多的，也包括非技术的因素。影响软件可靠性的主要因素有：缺陷的引入、发现和清除。缺陷的引入主要取决于软件产品的特性和软件的开发过程特性。软件产品的特点行指软件本身的性质，开发过程特性包括开发技术、技术工具、开发人员的水平、需求的变化频度等，缺陷的发现依靠用户对软件的操作方式、运行环境等，也就是运行剖面。缺陷的清除依赖于失效的发现和修复活动及可靠性方面的投入。
从技术的角度来看，影响软件可靠性的主要因素如下：
(1)运行剖面(环境)。软件可靠性的定义是相对运行环境而言的，一样的软件在不同的运行剖面下，其可靠性的表现是不一样的。
(2)软件规模。软件规模也就是软件的大小，一个只有数十行代码的软件和几千、几万行代码的软件是不能相提并论的。
(3)软件内部结构。结构对软件可靠性的影响主要取决于软件结构的复杂程度，一般来说，内部结构越复杂的软件，所包含的软件缺陷数就可能越多。
(4)软件的开发方法和开发环境。软件工程表明，软件的开发方法对软件的可靠性有显著影响。例如，与非结构方法相比，结构化方法可以明显减少软件的缺陷数。
(5)软件的可靠性投入。软件在生命周期中可靠性的投入包括开发者在可靠性设计、可靠性管理、可靠性测试和可靠性评价等方面投入的人力、资金、资源和时间等。经验表明，在早期重视软件可靠性并采取措施开发出来的软件，可靠性有明显的提高。
总之，有许许多多的因素影响着软件的可靠性，有些至今也无法确定它们与软件可靠性之间的定量关系，甚至定性关系也不甚清楚。
软件可靠性的建模方法
一个软件可靠性模型通常(但不是绝对)由以下几部分组成。
(1)模型假设。模型是实际情况的简化或规范化，总要包含若干假设，例如测试的选取代表实际运行剖面，不同软件失效独立发生等。
(2)性能度量。软件可靠性模型的输出量就是性能度量，如失效强度、残留缺陷数等。在软件可靠性模型中性能度量通常以数学表达式给出。
(3)参数估计方法。某些可靠性度量的实际值无法直接获得，例如残留缺陷数，这时需通过一定的方法估计参数的值，从而间接确定可靠性度量的值。当然，对于可直接获得实际值的可靠性度量，就无须参数估计了
(4)数据要求。一个软件可靠性模型要求一定的输入数据，即软件可靠性数据。不同类型的软件可靠性模型可能要求不同类型的软件可靠性数据。
绝大多数的模型包含3个共同假设。这些假设至今主宰着软件可靠性建模的研究发展，人们尚未找到克服这些假设局限性的有效方法。
(1)代表性假设。此假设认为软件测试用例的选取代表软件实际的运行剖面，甚至认为测试用例是独立随机地选取。此假设实质上是指可以用测试产生的软件可靠性数据预测运行阶段的软件可靠性行为。
(2)独立性假设。此假设认为软件失效是独立发生于不同时刻，一个软件失效的发生不影响另一个软件失效的发生。例如在概率范畴，假设相邻软件失效间隔构成一组独立随机变量，或假设一定时间内软件失效次数构成一个独立增量过程。在模糊数学范畴，则相邻软件失效间隔构成一组不相关的模糊变量。
(3)相同性假设。此假设认为所有软件失效的后果(等级)相同，即建模过程只考虑软件
失效的具体发生时刻，不区分软件的失效严重等级。软件可靠性模型要描述失效过程对上一节所分析因素的一般依赖形式。由于这些因素大多数在本质上是概率性的，并且表现与时间相关联，所以通过失效数据的概率分布和随机过程随时间的变化的特性来整体区分软件可靠性模型。
大多数模型都会对如下的内容进行解析表达：
（1）任何时间点所经历的平均失效数
（2）一段时间间隔内的平均失效数
（3）任何时间点的失效强度
（4）失效区间的概率分布
软件可靠性模型应该具有如下重要特性：
（1）基于可靠的假设
（2）简单
（3）计算一些有用的量
（4）给出未来失效行为的好的映射
（5）可广泛应用
软件的可靠性模型分类
大致有如下10类：
1.种子法模型
2.失效率类模型
3.曲线拟合类模型
4.可靠性增长模型
5.程序结构分析模型
6.输入域分类模型
7.执行路径分析方法模型
8.非齐次泊松过程模型
9.马尔可夫过程模型
10.贝叶斯分析模型
软件可靠性管理
为了进一步提高软件可靠性，人们又提出了软件可靠性管理的概念，把软件可靠性活动贯穿于软件开发的全过程。
软件可靠性管理是软件工程管理的一部分，它以全面提高和保证软件可靠性为目标，以软件可靠性活动为主要对象，是把现代管理理论用于软件生命周期中的可靠性保证活动的一种管理形式
软件可靠性管理的内容包括软件工程各个阶段的可靠性活动的目标、计划、进度、任务和修正措施等
软件工程各个阶段可能进行的主要软件可靠性活动如下所述。由于软件之间的差异较大，并且人们对可靠性的期望不同，对可靠性的投入不同，所以下面的每项活动并不是每一个软件系统的可靠性管理的必须内容，也不是软件可靠性管理的全部内容。
1.需求分析阶段
(1)确定软件的可靠性目标。
(2)分析可能影响可靠性的因素。
(3)确定可靠性的验收标准。
(4)制定可靠性管理框架。
(5)制定可靠性文档编写规范)
(6)制订可靠性活动初步计划。
(7)确定可靠性数据收集规范。
2.概要设计阶段
(1)确定可靠性度量。
(2)制定详细的可靠性验收方案。
(3)可靠性设计。
(4)收集可靠性数据。
(5)调整可靠性活动计划。
(6)明确后续阶段的可靠性活动的详细计划。
(7)编制可靠性文档。
3.详细设计阶段
(1)可靠性设计。
(2)可靠性预测(确定可靠性度量估计值)。
(3)调整可靠性活动计划。
(4)收集可靠性数据。
(5)明确后续阶段的可靠性活动的详细计划。
(6)编制可靠性文档
4.编码阶段
(1)可靠性测试(含于单元测试)。
(2)排错。
(3)调整可靠性活动计划。
(4)收集可靠性数据。
(5)明确后续阶段的可靠性活动的详细计划。
(6)编制可靠性文档。
5.测试阶段
(1)可靠性测试(含于集成测试、系统测试)。
(2)排错。
(3)可靠性建模
(4)可靠性评价。
(5)调整可靠性活动计划。
(6)收集可靠性数据。
(7)明确后续阶段的可靠性活动的详细计划。
(8)编制可靠性文档。
6.实施阶段
(1)可靠性测试(含于验收测试)
(2)排错。
(3)收集可靠性数据
(4)调整可靠性模型。
(5)可靠性评价。
(6)编制可靠性文档
软件可靠性设计
相比于可靠性测试活动通过差错和排错活动改善软件可靠性，软件可靠性设计是最有效、最经济、最终的手段
载软件工程中已有很多较成熟的设计技术，如结构化设计、模块化设计、自顶向下设计及自底向上设计等，这些技术是为了软件的整体质量而采用的。为了进一步提高软件的可靠性，通常会采用一些特殊设计技术。
容错设计技术
常用的软件容错技术主要有恢复快设计、N版本程序设计和冗余设计3种方法
（1）恢复块设计：一个恢复块包含若干个功能相同、设计差异的程序块文本，一旦正在运行的文本出现故障，则用备份文本替换，从而构成“动态冗余”
（2）N版本程序设计：对相同需求由不同设计人员设计出不同模块或版本，实行多数表决，防止其中某一软件模块/版本的故障提供错误的服务
（3）冗余设计：在主运行的系统之外备用额外的元件或系统，如果运行元件或系统出现故障，立刻更换到冗余的元件或系统
检错技术
采用检错设计技术要着重考虑几个要素:检测对象、检测延时、实现方式和处理方式。
(1)检测对象:包含两个层次的含义，即检测点和检测内容。在设计时应考虑把检测点放在容易出错的地方和出错对软件系统影响较大的地方:检测内容选取那些有代表性的、易于判断的指标。
(2)检测延时:从软件发生故障到被自检出来是有一定延时的，这段延时的长短对故障的处理是非常重要的。因此，在软件检错设计时要充分考虑到检测延时。如果延时长到影响故障的及时报警，则需要更换检测对象或检测方式。
(3)实现方式:最直接的一种实现方式是判断返回结果，如果返回结果超出正常范围，则进行异常处理。计算运行时间也是一种常用的技术，如果某个模块或函数运行超过预期的时间，可以判断出现故障。另外，还有置状态标志位等多种方法，自检的实现方式要根据实际情况来选用。
(4)处理方式:大多数检错采用“查出故障一停止软件系统运行一报警”的处理方式，但也有采用不停止或部分停止软件系统运行的情况，这一般由故障是否需要实时处理来决定。
降低复杂度设计
软件复杂性常分为模块复杂性和结构复杂性
系统配置技术
(1)双机热备技术
(2)服务集群技术
软件可靠性测试
不知道总结什么
软件可靠性评价
不知道总结什么
第十章 软件架构的演化和维护
软件架构演化和定义的关系
演化的重要性
为了适应用户的新需求、业务环境和运行环境的变化等，软件架构需要不断地进行自身的演化，也就是说软件架构的演化就是为了维持软件架构自身的有用性
演化的定义
软件架构的定义非常多，但如果软件架构的定义包括足检（Components）、连接件（Connectors）、约束（constraints）三大要素，这类软件架构演化主要关注的就是足检、连接件和约束的添加、修改与删除等
面向对象软件架构演化过程
不知道总结什么
软件架构演化方式的分类
目前，软件架构演化方式没有一种公认的分类法，分类方法很多，以下举例说明3种较典型的分类方法:
(1)按照软件架构的实现方式和实施粒度分类:基于过程和函数的演化、面向对象的演化、基于组件的演化和基于架构的演化。
(2)按照研究方法将软件架构演化方式分为4类(JereyM.Barmes等人的分类方法):
第1类是对演化的支持，如代码模块化的准则、可维护性的指示(如内聚和耦合)、代码重构等
第2类是版本和工程的管理工具，如CVS和COCOMO
第3类是架构变换的形式方法，包括系统结构和行为变换的模型，以及架构演化的重现风格等
第4类是架构演化的成本收益分析，决定如何增加系统的弹性。
(3)针对软件架构的演化过程是否处于系统运行时期，可以将软件架构演化分为静态演化(Static Evolution)和动态演化(Dynamic Evolution)，前者发生在软件架构的设计、实现和维护过程中，软件系统还未运行或者处在运行停止状态:后者发生在软件系统运行过程中。
本章重点介绍软件架构的静态演化和动态演化。
软件架构演化时期
1.设计时演化
设计时演化(Design-Time Evolution)是指发生在体系结构模型和与之相关的代码编译之前的软件架构演化。
2.运行前演化
运行前演化(Pre-Execution Evolution)是指发生在执行之前、编译之后的软件架构演化，这时由于应用程序并未执行，修改时可以不考虑应用程序的状态，但需要考虑系统的体系结构，且系统需要具有添加和删除组件的机制。
3.有限制运行时演化
有限制运行时演化(Constrained Runtime Evolution)是指系统在设计时就规定了演化的具体条件，将系统置于“安全”模式下，演化只发生在某些特定约束满足时，可以进行一些规定好的演化操作。
4.运行时演化
运行时演化(RuntimeEvolution)是指系统的体系结构在运行时不能满足要求时发生的软件架构演化，包括添加组件、删除组件、升级替换组件、改变体系结构的拓扑结构等。此时的演化是最难实现的。
静态演化需求
(1)设计时演化需求。在架构开发和实现过程中对原有架构进行调整，保证软件实现与架
构的一致性以及软件开发过程的顺利进行。
(2)运行前演化需求。软件发布之后由于运行环境的变化，需要对软件进行修改升级，在此期间软件的架构同样要进行演化。
静态演化的一般过程
软件静态演化是系统静止运行期间的修改和更新，即一般意义上的软件修复和升级。与此相对应的维护方法有3类：更正性维护、适应性维护和完善性维护
软件的静态演化一般包括5个步骤：软件理解、需求变更分析、演化计划、系统重构和系统测试
在系统未运行的情况下，软件功能的变更或环境变化可能会带来架构中组件元素的增加、替换、删除、组合和拆分操作。架构静态演化需要对这些操作给其他组件和系统本身带来的影响进行分析
静态演化实例：正交软件架构
正交软件架构（Orthogonal Software Architecture）的演化过程概括如下：
1.需求变动归类，使需求的变化和现有组件及线索相对应，判断重用情况；
2.制订架构演化计划
3.修改、增加或删除组件
4.更新组件之间的相互作用
5.产生烟花后的软件架构，作为系统更新的详细设计方案和实现基础
软件架构演化原则
1.演化成本控制原则
原则名称:演化成本控制(Evolution Cost Control，ECC)原则。
原则解释:演化成本要控制在预期的范围之内，也就是演化成本要明显小于重新开发成本。
原则用途:用于判断架构演化的成本是否在可控范围内，以及用户是否可接受。
度量方案:CoE<<CoRD。
方案说明:CoE为演化成本，CoRD为重新开发成本，CoE远小于CoRD最佳。
2.进度可控原则
原则名称:进度可控(ScheduleControl)原则。
原则解释:架构演化要在预期时间内完成，也就是时间成本可控。
原则用途:根据该原则可以规划每个演化过程的任务量;体现一种迭代、递增(持续演化)的演化思想。
度量方案:ttask=Ttask-T'task|。
方案说明:某个演化任务的实际完成时间(Ttask)和预期完成时间(Ttask)的时间差，时间差ttask越小越好。
3.风险可控原则
原则名称:风险可控(Risk Control)原则。
原则解释:架构演化过程中的经济风险、时间风险、人力风险、技术风险和环境风险等必须在可控范围内。
原则用途:用于判断架构演化过程中各种风险是否易于控制。
度量方案:分别检验。
方案说明:时间风险、经济风险、人力风险、技术风险都不存在。
4.主体维持原则
原则名称:主体维持原则。
原则解释:对称稳定增长(theAverage Incremental Growth，AIG)原则所有其他因素必须与软件演化协调，开发人员、销售人员、用户必须熟悉软件演化的内容，从而达到令人满意的演化。因此，软件演化的平均增量的增长须保持平稳，保证软件系统主体行为稳定。
原则用途:用于判断架构演化是否导致系统主体行为不稳定。
度量方案:计算AIG即可，AIG=主体规模的变更量/主体的规模。
方案说明:根据度量动态变更信息(类型、总量、范围)来计算。
5.系统总体结构优化原则
原则名称:系统总体结构优化(OptimizationofWholeStructure)原则原则解释:架构演化要遵循系统总体结构优化原则，使得演化之后的软件系统整体结构(布局)更加合理。
原则用途:用于判断系统整体结构是否合理，是否最优。
度量方案:检查系统的整体可靠性和性能指标。
方案说明:判断整体结构优劣的主要指标是系统的可靠性和性能
6.平滑演化原则
原则名称:平滑演化(Invariant WorkRate，IWR)原则。
原则解释:在软件系统的生命周期里，软件的演化速率趋于稳定，如相邻版本的更新率相对固定。
原则用途:用于判断是否存在剧烈架构演化。
度量方案:计算IWR即可，IWR=变更总量/项目规模。
方案说明:根据度量动态变更信息(类型、总量、范围等)来计算。
7.目标一致原则
原则名称:目标一致(Objective Conformance)原则。
原则解释:架构演化的阶段目标和最终目标要一致。
原则用途:用于判断每个演化过程是否达到阶段目标，所有演化过程结束是否能达到最终目标。
度量方案:otask=Otask-O'task|。
方案说明:阶段目标的实际达成情况(Otask)和预期目标(Otask)的差，Otask越小越好
8.模块独立演化原则
原则名称:模块独立演化原则，或称为修改局部化原则(LocalChange)原则解释:软件中各模块(相同制品的模块，如Java的某个类或包)自身的演化最好相互独立，或者至少保证对其他模块的影响比较小或影响范围比较小。
原则用途:用于判断每个模块自身的演化是否相互独立。
度量方案:检查模块的修改是否是局部的。
方案说明:可以通过计算修改的影响范围来进行度量。
9.影响可控原则
原则名称:影响可控(ImpactLimitation)原则。
原则解释:软件中一个模块如果发生变更，其给其他模块带来的影响要在可控范围内，也就是影响范围可预测。
原则用途:用于判断是否存在对某个模块的修改导致大量其他修改的情况。
度量方案:检查影响的范围是否可控。
方案说明:可以通过计算修改的影响范围来进行度量。
10.复杂性可控原则
原则名称:复杂性可控(ComplexityControllability)原则。
原则解释:架构演化必须要控制架构的复杂性，从而进一步保障软件的复杂性在可控范围内。
原则用途:用于判断演化之后的架构是否易维护、易扩展、易分析、易测试等
度量方案:CC<某个值;方案说明:CC增长可控。
11.有利于重构原则
原则名称:有利于重构(UsefulforRefactoring)原则。
原则解释:架构演化要遵循有利于重构原则，使得演化之后的软件架构更便于重构。
原则用途:用于判断架构易重构性是否得到提高。
度量方案:检查系统的复杂度指标。
方案说明:系统越复杂越不容易重构。
12.有利于重用原则
原则名称:有利于重用(UsefulforReuse)原则。
原则解释:架构演化最好能维持，甚至提高整体架构的可重用性。
原则用途:用于判断整体架构可重用性是否遭到破坏。
度量方案:检查模块自身的内聚度、模块之间的耦合度。
方案说明:模块的内聚度越高，该模块与其他模块之间的耦合度越低，越容易重用
13.设计原则遵从性原则
原则名称:设计原则遵从性(DesignPrinciples Conformance)原则。
原则解释:架构演化最好不能与架构设计原则冲突。
原则用途:用于判断架构设计原则是否遭到破坏(架构设计原则是好的设计经验总结，要保障其得到充分使用)。
度量方案:RCP=CDPI/DP。
方案说明:冲突的设计原则集合(CDP)和总的设计原则集合(DP)的比较，RCP越小越好。
14.适应新技术原则
原则名称:适应新技术(TechnologyIndependence，TI)原则。
原则解释:软件要独立于特定的技术手段，这样才能够让软件运行于不同平台。
原则用途:用于判断架构演化是否存在对某种技术依赖过强的情况。
度量方案:TI=1-DDT，其中DDT=依赖的技术集合/用到的技术合集|。
方案说明:根据演化系统对关键技术的依赖程度进行度量。
15.环境适应性原则
原则名称:环境适应性(PlatformAdaptability)原则。
原则解释:架构演化后的软件版本能够比较容易适应新的硬件环境与软件环境。
原则用途:用于判断架构在不同环境下是否仍然可使用，或者容易进行环境配置。
度量方案:硬件/软件兼容性。
方案说明:结合软件质量中兼容性指标进行度量。
16.标准依从性原则
原则名称:标准依从性(Standard Conformance)原则。
原则解释:架构演化不会违背相关质量标准(国际标准、国家标准、行业标准、企业标准等)。
原则用途:用于判断架构演化是否具有规范性，是否有章可循;而不是胡乱或随意地演化。
度量方案:需要人工判定。
17.质量向好原则
原则名称:质量向好(QualityImprovement，Ql)原则。
原则解释:通过演化使得所关注的某个质量指标或某些质量指标的综合效果变得更好或者更满意，例如可靠性提高了。
原则用途:用于判断架构演化是否导致某些质量指标变得很差。
度量方案:EQI≥Q。
方案说明:演化之后的质量(EQI)比原来的质量(SQ)要好。
18.适应新需求原则
原则名称:适应新需求(NewRequirementAdaptability)原则。
原则解释:架构演化要很容易适应新的需求变更;架构演化不能降低原有架构适应新需求的能力;架构演化最好可以提高适应新需求的能力。
原则用途:用于判断演化之后的架构是否降低了架构适应新需求的能力。
度量方案:RNR=ANRI/INRI。
方案说明:适应的新需求集合(ANR)和实际新需求集合(NR)的比较，RNR越小越好。
软件架构演化评估方法
分为演化过程已知和演化过程未知
大型网站系统架构演化实例
第一阶段：单体架构
第二阶段：垂直架构
第三阶段：使用缓存改善网站性能
第四阶段：使用服务集群改善网站并发处理能力
第五阶段：数据库读写分离
第六阶段：使用反向代理和CDN加速网站响应
第七阶段：使用分布式文件系统和分布式数据库系统
第八阶段：使用NoSQL和搜索引擎
第九阶段：业务拆分
第十阶段：分布式服务
软件架构维护
不知道总结什么
