设计模式

创建模式（5种）

单例模型 - 一个对象实例全局使用

抽象工厂模型 - 产品族的配套构建

工厂方法模式 - 产品的构建

建造者模式 - 复杂对象按步骤构建

原型模式 - 克隆对象，避免重复初始化

结构模式（七种）

组合模式 Composite - 树状结构，整体和部分一致对待。（文件系统、组织架构、菜单树）

适配器模式 Adapter - 原接口兼容为目标接口，让不能工作的接口通过兼容适配之后能够工作

装饰器模式 Decorator - 不改原有类给对象动态增加职责，功能增强（java io流、给咖啡加料）

代理模式 Proxy - 提供对象的替身，以控制对这个对象的访问。（aop代理、权限代理）

外观模式 Facade - 封装不同类型业务逻辑（子系统），统一简单入口访问。（一套后端支持移动、PC端）

桥接模式 Bridge - 把抽象和实现分离，使两者可以独立变化。（面向接口编程）

享元模式 Flyweight - 共享细粒度对象，减少对象占用。（Redis整数对象池，棋盘棋子）

行为性模式（十一种）

Chain of Responsibility 责任链 - 不同的处理者串在一起，每个块需要判断是否需要处理，并传递给后续的块（权限过滤器、审批流、日志级别）

Command 命令模式 - 把请求封装成命令对象，可以对其进行撤销，排队，参数化（按钮命令、撤销重做）

Interpreter 解释器模式 - 自定义语言语法并支持解析表达式。（规则引擎、正则表达式）

Iterator 迭代器模式 - 提供统一方式遍历集合，不保留内部对象（集合遍历、数据库游标）

Mediator 中介者模式 - 把复杂网状交互集中到中介者，减少耦合（xxljob、分布式事务协调者TC统一管理RM\TM、机场调度）

Memento 备忘录 - 保存对象内部状态，以便恢复，同时不破坏封装（快照、游戏存档、撤销）

Observer 观察者 - 订阅者维护观察者列表，状态/事件变化通知观察者，观察者接收后执行自己的更新逻辑。（消息队列）

State 状态模式 - 对象改变状态同时改变行为，对外像是更换了类。（枚举状态，不同状态行为不一样）

Strategy 策略模式 - 把可替换的算法封装到一起，客户端可按需切换。

Template Method 模板方法 - 在父类定义算法骨架，把某些步骤作为模板方法延迟到子类实现。（框架生命周期、测试基类）

Visitor 访问者 - 在不改变结构的情况下，支持新增不同的操作。（sql ast解析，实现血缘解析可直接新增visitor在不改变原有结构的情况下完成新增操作。操作与结构分离）

数据库设计

数据库三级模式

外模式：用户与数据库的接口，通过不同的视图定义提供给不同用户使用，实现逻辑独立性保障安全。也就是数据库中的视图（View）。

概念模式：维护数据库全局逻辑结构，包括表关系、数据项、完整性约束与实体映射的描述（相当于是数据库的元数据，维护整个库所有表的逻辑结构信息等）。

内模式：定义数据在物理层面的描述，通过概念模式/内模式的映射，实现数据与物理的隔离也就是物理独立性。

软件测试

软件测试方法

测试类型

尽早、不断测试
程序员避免测试自己设计的程序
既要选择有效、合理的设计、也要无效、不合理的数据
修改后应进行回归测试
尚未发现的错误数量与该程序已发现错误数成正比

动态测试（计算机运行）

黑盒测试（功能测试，输入输出）

等价类划分（不同类型选几个，达到全面覆盖）
边界值分析（边界值）
错误推测（经验推测）
因果图

白盒测试（看到内部结构）

基本路径测试
循环覆盖测试
逻辑覆盖测试

灰盒测试

静态测试（纯手工，不依赖计算机）

桌前检查
代码审查
代码走查

测试阶段

单元测试：模块测试，模块功能、性能、接口等。
集成测试：模块间的接口；一次性|增量方式（自顶向下、自低向上、混合式）
确认测试：验证软件与需求的一致性。内部确认测试、Alpha测试、Beta测试，验收测试
系统测试：真实环境下，验证完整的软件配置项能否和系统正确连接
- 恢复测试
- 安全性测试
- 压力测试
- 性能测试
- 负载测试
- 强度测试
- 容量测试
- 可靠性测试
- 可用性测试
- 可维护性测试
- 安装测试
回归测试：测试软件变更后，变更部分的正确性对变更需求的符合性。

面向对象测试

算法层（单元测试）：包括等价划分测试、组合功能测（评定表）、递归函数测和多态消息测
类层（模块测试）：包括不变式边界测试、模态类测试和非模态类测试
模板层/类树层（集成测试）：包括多态服务测试和展平测试
系统层（系统测试）

软件调试

调试方法

蛮力法：通过计算机找，低消耗时
回溯法：出错处人工控制流程往回追踪（反向）
原因排除法：主要是演绎和归纳，用二分法实现（正向）

调试和测试的区别

测试目的为找出错误，调试目的是定位错误并修正错误
调试是测试后的活动，目标方法思路不同
测试已知条件开始，预先定义过程，有预知结果；调试从未知条件开始，结束过程不可预计
测试过程可以事先设计，进度可以确定；调试不能描述过程或持续时间

系统转换计划

遗留系统演化策略

淘汰策略

遗留系统的技术含量较低，具有较低业务价值。

继承策略

遗留系统的技术含量低，已经满足企业运作的功能或性能要求，有较高商业价值，目前业务紧密依赖该系统。开发新系统需完全兼容遗留系统功能模型和数据模型，并且为了保证业务连续性，新老系统需要并行运行一段时间，逐渐切换新系统。

改造策略

遗留系统具有较高业务价值，基本能满足企业业务运作和决策支持的需要。建成时间短，演化策略为改造。改造包括系统功能和数据模型；系统功能指在原系统基础上增加新应用要求，对遗留系统本身不改变；数据模型改造指将遗留系统旧的数据模型向新的数据模型的转化。

集成策略

遗留系统的技术含量较高，但其业务价值较低，可能只完成某个部门（或子公司）的业务管理。这种系统在各自领域工作良好，但对于整个企业，存在多个相似系统，不同系统不同数据不同平台，形成了信息孤岛，策略为集成

新旧系统转换策略

直接转换策略

并行转换策略（蓝绿发布、金丝雀发布）

分段转换策略（按功能|按地市）

数据转换与迁移

ETL: 抽取 -> 转换 -> 装载
旧数据库 -> 切换通过工具/采用手工录入/通过新系统生成 -> 新数据库

系统运行与维护

正确性维护

改正系统开发阶段已发生而系统测试阶段尚未发现错误。

适应性维护

适应信息技术变化和管理需求变化而进行修改。（操作系统、软件运行环境、导致系统不能运行。国产化迁移）

完善性维护

扩充功能和改善性能的修改。

预防性维护

为了改进应用的可靠性和可维护性。

软件架构设计（占20-26分）

架构概念

架构就是需求分配，即将满足需求的职责分配到组件上。

软件体系结构 = 架构

需求分析（业务） -> 架构（鸿沟） -> 软件设计（技术）

1.软件架构风格描述某一特定应用领域中系统组织方式惯用模式。

2.为软件系统提供了一个结构、行为和属性的高级抽象，由构成系统的元素的描述、这些元素相互作用(连接件)、指导元素集成的模式以及这些模式的约束组成。

3.项目干系人进行交流的手段，明确了对系统实现的约束条件，决定了开发和维护组织的组织结构，制约着系统的质量属性。

4.推理和控制更改更加简单，有助于循序渐进的原型设计，可以作为培训基础

5.可传递和可复用的模型，通过研究软件架构可能预测软件的质量。

构件

架构本质是连接件与构件组成。

构件是一个独立可交付的功能单元，外界通过接口访问其提供服务。
构件由一组通常需要同时部署的原子构件组成。一个原子构件是一个模块和一组资源。原子构件是部署、版本控制和替换的基本单位。原子构件通常成组地部署，但是也能单独部署。
构件与原子构件区别是，多数原子构件不会独立部署，尽管可以独立部署。相反多数原子构件都属于一个构件家族，一次部署往往涉及整个家族。
一个模块是不带单独资源的原子构件
一个单独包被编译成多个单独的类文件-每个公共类都有一个
模块是一组类和可能的非面向对象的结构体，比如过程或者函数。

特性：

独立部署单元
作为第三方组装单元
没有（外部的）可见状态

一个构件可以包含多个类元素，但是一个类元素只能属于一个构件。

构件 -> 原子构件*n -> 模块（类或者函数）+资源

基于构件的软件工程（CBSE）

应具备以下特征

可组装：外部交互通过公开定义接口进行
可部署性：自包含，必须能独立实体提供构件模型实现的构件平台上运行
文档化：构件必须是完全文档化，用户根据文档判断构件是否满足需求
独立性：无其他特殊构件情况下进行组装和部署，如确需要其他构件提供服务，则应显示声明
标准化：使用构件必须符合某种标准化的构件模型

架构发展史

无架构阶段（汇编）
萌芽阶段（程序结构设计）
初级阶段（UML）
高级阶段（4+1视图）

软件架构建模

4+1视图

UML逻辑视图（最终用户：系统功能需求）

UML开发视图（编程人员：软件管理|源代码组件）

UML物理视图（系统工程人员：系统拓扑、安装、通信等|软件到硬件映射关系）

UML进程视图（系统集成人员：性能可扩展性、吞吐量等|并发）

场景（UML: 用例视图）

软件架构风格

（https://www.suibibk.com/topic/776202820129914880）

架构设计的一个核心问题是能否达到架构级复用

架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个构件有效地组织成一个完整系统。

架构风格定义了用于描述系统的术语表和一组指导构建系统的规则

5类架构(传统知识点)

5类分别是：数据流、调用/返回、独立构件、虚拟机、仓库架构风格。

架构风格名	关键概念及实例	简介与核心特点
数据流 - 批处理	数据被分成批次，每个阶段处理整个批次后传递给下一个阶段。 • 实例：传统编译器、数据仓库ETL过程。	数据以批次为单位顺序处理，每个阶段必须处理完整个批次后才进入下一阶段，强调整体性。
数据流 - 管道-过滤器	数据通过一系列过滤器处理，每个过滤器对数据流进行转换。 • 实例：Unix shell管道（如 `ls grep`）、图像处理管道。	数据从一个过滤器流到下一个，过滤器独立，前一个输出是后一个输入。通过数据格式解耦，支持并行处理。
调用/返回 - 主程序/子程序	主程序显式调用子程序执行特定任务。 • 实例：C语言程序中的函数调用、模块化编程。	显式调用关系，主程序控制流程，调用子程序完成功能，结构简单清晰。
调用/返回 - 面向对象	软件由对象组成，对象封装数据和方法。 • 实例：Java或C++应用程序、面向对象设计模式。	通过对象之间的方法调用实现交互，支持封装、继承和多态，提高代码复用性和可维护性。
调用/返回 - 层次结构	系统被分层，每层为上层提供服务，并使用下层的服务。 • 实例：OSI网络模型、TCP/IP协议栈、操作系统内核。	分层架构，每层通常只与相邻层交互，降低耦合，便于修改和扩展。
独立构件 - 进程通信	进程通过消息传递进行通信，支持同步和异步模式。 • 实例：分布式系统中的消息队列（如RabbitMQ）、微服务间通信。	进程间通过消息传递数据，组件独立运行，提高系统解耦和可伸缩性。
独立构件 - 事件驱动（隐式调用）	组件通过事件触发行为，事件发布和订阅机制。 • 实例：GUI应用程序（如按钮点击）、语法错误提示、Debugger断点事件。	不直接调用，通过事件驱动。构件在事件中注册过程，事件触发时系统自动调用。为软件重用提供了强大支持，但构件放弃了对系统计算的控制。
虚拟机 - 规则系统	系统基于规则库，解释引擎执行规则。 • 实例：专家系统、决策支持系统（DSS）、业务规则引擎。	使用规则库、规则解释器、选择器和工作内存，解释自定义规则，适用于人工智能和复杂决策场景。
仓库 - 数据库	中央数据存储，多个组件访问和修改数据。 • 实例：数据库管理系统（如MySQL）、现代IDE（以数据为中心）。	以共享数据库为中心，组件独立操作数据，保证数据一致性和持久性。
仓库 - 超文本	通过超链接连接信息资源，支持非线性访问。 • 实例：World Wide Web、维基百科。	基于超文本的网络链接结构，多用于互联网应用，支持用户自由导航。
仓库 - 黑板	多个知识源通过共享黑板协作解决问题。 • 实例：语音识别、知识推理系统。	用于问题复杂、解空间很大、求解过程不确定的软件系统。包括黑板、知识源和控制模块，支持协作推理。
闭环 - 过程控制	系统通过反馈循环调整行为，维持设定参数。 • 实例：汽车巡航定速、空调温度调节、工业自动化控制系统。	控制器发出命令并接受传感器反馈，循环调整以达成平衡，适用于实时控制系统。
C2风格	通过连接件绑定在一起的按照一组规则运作的并行构件网络。 • 实例：GUI框架、柔性系统集成。	构件和连接件都有顶部和底部，构件之间禁止直接连接，必须通过连接件通信，实现松耦合和可扩展性。

层次架构风格

两层C/S -> 三层C/S -> 三层B/S -> 混合架构

三层B/S

表现层 MVC -> MVP -> MVVM

MVC

Model（模型-Entity Bena）用于处理应用程序数据逻辑部分。

View（视图-JSP）处理数据显示部分。

Controller（控制器-Servlet）处理用户交互部分。

主动 MVC

被动 MVC

MVP（MVC 变种）

实现了 V 与 M 解耦（V不直接使用 M，修改 V 不影响 M）

更好支持单侧（业务逻辑在 P，可以脱离 V 来测试逻辑，一个 P 用于多个 V，不需改变 P 逻辑）

MVP 中 V 要处理界面事件，业务逻辑在 P 中，MVC 中界面事件由 C 处理。

MVVM

中间层
数据访问层 ORM

数据架构层数据库

富互联网应用（RIA）

RIA 结合了 C/S结构反应快，交互性强，以及BS架构传播范围易

RIA简化并改进了 BS 架构的用户交互

数据能被缓存在客户端，从而实现一个比 HTML 的响应速度更快的数据往返服务器的次数更少的用户界面。

基于服务的架构（SOA）

服务是为了满足某项业务需求的操作、规则等的逻辑组合，它包含一系列有序活动的交互，为实现用户目标提供支持。

ESB 总线（中介-简化为星形结构）

服务，松散耦合
构件，粗粒度
对象，标准化接口

实现方式：

Web Service（底层传输层、服务通信协议层、服务描述层、服务层、业务流程层、服务注册层）
服务注册中心
服务请求者
服务提供者
ESB（企业服务总线）

提供位置透明的消息路由和寻址服务

提供服务注册和命名的管理功能

支持多种消息传递泛型

支持多种可以广泛使用的传输协议

支持多种数据格式及其互相转换

提供日志和监控功能

服务注册表

服务注册、服务位置、服务邦定

关键技术

发现服务 UDDI、DISCO
描述服务 ESDL、XML Schema
消息格式层 SOAP、REST
编码格式层 XML(DOM、SAX)
传输协议层 HTTP、TCP/IP、SMTP等
WSDL：是 WebService 接口对应的 WSDL 文件，通过 xml 格式说明如何调用，相当于接口文档（使用说明书）
SOAP（Simple Object Access Protocol）：简单对象访问协议，用于访问网络服务的协议；SOAP协议=HTTP+XML

REST

HTTP+XML进行基于 Web 通信的技术
简单性，缺少严格配置文件
只支持几个操作（POST、GET、PUT、DELETE）
强调信息本身，称为资源

网络上所有事物抽象为资源

资源对应一个唯一标识

通过连接器接口对资源标识

对资源各种操作不会改变资源标识

所有操作无状态

微服务架构

面向服务架构(SOA)的一种，微小的服务。

特点是：小，专注于一件事情；轻量级通信机制；松耦合、独立部署

微服务的优势：

技术异构性
弹性
扩展
简化部署
与组织结构相匹配
可组合性
对可替代性的优化

微服务的缺点：

分布式系统的复杂度
运维成本
部署自动化
DevOps与组织结构
服务间依赖测试
服务间依赖管理

与SOA的区别

SOA是集中式架构，基于ESB(类似总线把所有服务集中在一起)。微服务是分布式架构没有ESB-有注册中心（去中心化但）。

微服务架构实现	SOA 实现
团队级，自低向上开展实施	企业级，自顶向下开展实施
一个系统被拆分为多个服务,粒度细\|服务由多个子系统组成，粒度大	无集中式总线，松散服务架构\|企业服务总线，集中式服务架构
集成方式简单（HTTP\REST\JSON）	集成方式复杂（ESB\WS\SOAP）
服务能独立部署	单块架构系统，相互依赖，部署复杂

架构复用（软件复用）

包括机会复用和系统复用。机会复用指开发过程，只要发现由可复用，就对其复用。系统复用是指在开发之前，就要进行规划，已决定哪些需要复用。

可复用资产包括：需求、架构设计、元素、建模与分析、测试、项目规划、过程方法和工具、人员、样本系统、缺陷消除。

包括3个阶段：

构造/获取可复用资产
管理这些资产（构件库）
针对特定需求，选择可复用部分，以开发满足需求的应用系统（使用可复用资产）

模型驱动架构（MDA）

Model 客观事物抽象表示

Architecture 构成系统部件、连接件及其约束的规约

Model-Driven 使用模型完成软件分析、设计、构建、部署、维护等各开发活动。 MDA 起源与分离系统规约和平台实现的思想

目标：可移植性(Portability)、互通性(interoperability)、可重用性(Reusability)

3种核心模型

平台独立模型（PIM）：具有高抽象层次，独立于任何实现技术模型。

平台相关模型（PSM）：为某种特定实现技术量身定制，让你用这种技术中可用的实现构造来描述系统的模型。PIM会变换成一个或多个PSM。

代码Code：用源代码对系统的描述（规约）。每个PSM都将变成代码。

架构描述语言（ADL）

ADL 三个基本元素

构件：计算或数据存储单元；
连接件：用于构件之间交互建模的体系结构构造块及其支配这些交互的规则
架构配置：描述体系结构的构件与连接件的连接图

主要的架构描述语言

Aesop: 支持体系结构风格的应用
MetaH：为设计者提供了关于实时电子控制软件系统的设计指导
C2：支持基于消息传递风格的用户界面系统的描述
Rapide：支持体系结构设计的模拟并提供了分析模拟结构的工具
SADL：提供了关于体系结构加细的形式化基础
Unicon：支持异构的构件和连接类型并提供了关于体系结构的高层编译器
Wright：支持体系结构构件之间交互的说明和分析

特定领域软件架构（DSSA）

DSSA是专用于某一类特定类型的任务（领域）的、整个领域中能有效使用的、为成功构造应用系统限定了标准的组合结构的软件构件的集合。

支持在一个特定领域中多个应用的生成。

垂直域：一个特定领域中通用软件架构，是一个完整架构
水平域：多个不同特定领域之间的相同的部分的小工具（购物和教育都有收费系统，收费系统是水平域）

三个基本活动

领域分析(建立领域模型) -> 领域设计(获得DSSA) -> 领域实现(开发和组织可复用信息)

四种角色，领域分析机制（1是军师，234是干活的）

领域专家：有经验的用户、同领域系统需求分析、设计、实现以及项目管理的有经验的软件工程师。提供选择样本系统作为领域工程依据，复审领域模型、DSSA等领域工程产品，等等。
领域分析人员：领域设计人员应由有经验的软件设计人员担任。控制整个领域分析过程，进行知识获取，将获取的知识组织到领域模型中。
领域设计人员：有经验的软件设计人员来担任。根据领域模型和现有系统开发出DSSA，并对DSSA的准确性和一致性进行验证。
领域实现人员：领域实现应由有经验的程序设计人员担任。根据领域模型和DSSA，开发构件。

建立过程

定义领域范围 -> 定义领域特定的元素 -> 定义领域的设计和实现需求约束 -> 定于领域模型和架构 -> 产生、搜集可复用的产品单元

基于架构的软件设计（ABSD）

ABSD 方法是架构驱动，即强调由业务、质量和功能需求的组合驱动架构设计。采用视角和视图来描述软件架构, 采用用例和质量属性来描述需求。用例描述功能需求，质量属性描述非功能需求。

使用ABSD方法，设计活动可以从项目总体功能框架明确就开始，意味着需求获取和分析没有完成，就开始了软件设计。

ABSD有三个基础。第一个是功能分解，基于模块内聚和耦合技术；第二是通过选择架构风格来实现质量和业务需求；第三个是软件模板的使用。

ABSD是递归的，而且迭代每个步骤都是清晰定义的。因此不管是否完成设计，架构总是清晰的，有助于降低架构设计的随意性。

设计与视图：从不同视角检查，所以会有不同的视图

用例用来捕获功能需求、特定场景来捕获质量需求

软件质量属性

软件系统质量属性分为开发期质量属性和运行期质量属性2个部分。

开发期：软件开发阶段所关注，6个方面。
- 易理解：设计被开发理解难易度
- 可扩展：适应新需求变化增加新功能的能力，也称灵活性
- 可重用：重用系统或某一部分难易度
- 可测试：测试证明满足需求规范难易度
- 可维护：修改bug、增加功能等难易度
- 可移植：切换运行环境难易度
运行期：软件运行阶段所关注，7个方面。
- 性能：及时提供相应服务能力，速度，吞吐量等。
- 安全性：同时兼顾服务和和合法性，阻止非授权使用的能力
- 可伸缩：用户和请求数增加，维持高服务质量能力。比如增加机器。
- 互操作：交换数据和互相调用服务难易度。
- 可靠性：一定时间内持续无故障能力
- 可用性：一定时间内正常工作所占时间比例。
- 鲁棒性：非正常情况仍能正常运行，也称健壮性或容错性。

架构评估质量属性（8项，核心4项）：

质量效用树：性能、可用性、安全性、可修改性。

性能

系统响应能力。

代表参数：响应时间、吞吐量等

设计策略：优先级队列、资源调度、减少开销、引入并发、采用资源调度

可用性

系统能够正常运行的时间比例。

代表参数：故障间隔时间

设计策略：冗余、心跳、选举、Ping/Echo

安全性

向合法用户提供服务的同时能阻止非授权用户使用的企图或拒绝服务的能力。

设计策略：追踪审计、入侵检测、用户认证、用户授权

可修改性

较高的性能价格比对系统进行变更的能力。

主要策略：信息隐藏

可靠性

意外错误使用或系统错误情况下维持软件功能特性。

代表参数：MTTF(平均无故障时间)、MTBF(平均故障间隔)、MTTR（平均故障修复时间）

设计策略：冗余、心跳、选举、Ping/Echo

功能性

系统所能完成所期望的工作能力

可变性

体系结构经扩充或变更成为新体系结构的能力。

互操作性

经常与其他系统或自身环境相互作用。

软件质量属性场景

面向特定质量属性的需求。6部分组成

刺激源(Souce)：生成刺激的实体 （人、计算机系统或者其他）
刺激(Stimulus)：刺激到达系统时需要考虑的条件（希望改变功能、质量属性、容量等）
环境(Environment)：某些条件内发生。（设计时、编译时、构建时、运行时）
制品(Artifact)：制品被激励。(用户界面、平台、环境或与目标系统交互的系统)
响应（Response）：激励到达后所采取的行动。（查找架构中需求修改的位置，进行修改且不影响其他功能，对修改测试，部署所做的修改）
响应度量（Measurement）：应当能以某种方式对其进行度量（修改对其他功能或属性所造成影响程度）

软件架构评估

评估方法分为三类：

基于调查问卷（检查表）的方式
基于度量的方式
基于场景的方式
1. SAAM
2. ATAM
3. CBAM

https://www.suibibk.com/topic/771497642910810112
为什么要进行架构评估？
架构评估到底评什么？
架构评估怎么评？

基于场景的架构分析方法（SAAM）

SAAM(Scenario-based Architecture Analysis Method)，它是一种基于场景的而且是非功能质量属性的架构评估方法，最早用于分析体系结构的可修改性(主要质量属性)，后来也用于其他质量属性的评估。

特定目标：描述应用程序属性的文档，验证基本架构假设和原则。

质量属性：任何形式质量属性具体化为场景，可修改性是主要质量属性。

架构描述：SAAM用于架构的最后版本，早于详细设计。架构描述形式应当被所有参与者理解。

功能、结构和分配被定义为描述架构3个主要方面

方法活动：输入是问题描述、需求声明和架构描述。包括5步骤: 场景开发、架构描述的、单个场景评估、场景交互和总体评估。

架构权衡分析法（ATAM）

ATAM的评估目的是依据系统质量属性和商业需求评估设计决策的结果。ATAM希望揭示出架构满足特定质量目标的情况，使我们更清楚地认识到质量目标之间的联系，即如何权衡多个质量目标。

四个主要活动领域，场景和需求收集、体系结构视图和场景实现、属性模型构造和分析、折中。评估过程以属性作为架构评估的核心概念。主要针对：性能、可用性、安全性和可修改性，开发系统前对这些质量属性进行评价和折中。

风险点：系统架构风险是指架构设计中潜在的、存在问题的架构决策所带来的隐患

敏感点：指为了实现某种特定的质量属性，一个或多个构件所具有的特性。

权衡点：影响多个质量属性的特性，是多个质量属性的敏感点。

架构评估目的

验证基本的体系结构假设和原则，评估体系结构固有的风险。SAAM指导对体系结构的检查，使其主要关注潜在的问题点，如需求冲突。SAAM不仅能够评估体系结构对于特定系统需求的使用能力，也能被用来比较不同的体系结构。

评估的参与者

风险承担者、记录人员、软件体系结构设计师。

评估活动和过程

形成场景

指的是风险承担者们集中在一起，集体讨论，提出一个个系统需求场景。记录人员把这些场景记录在册，形成文档的过程。

描述体系结构

指的是体现结构设计师，对待评估的体系结构进行适当的描述，包括静态属性和动态特征，可以用自然语言也可以用形式化手段，以让参加评估的所有人员都能充分理解。

这一步骤和上一个形成场景的步骤可以合并在一起，重复进行多次

对场景进行分类和确定优先级

系统可分为直接场景和间接场景，直接场景指的是本体系结构可以直接支持的场景，即不需要对体系结构做任何修改即可直接实现。

另外一种间接场景则是需要对现有体系结构做些更改才能支持的场景。

最后用投票的方法，确定间接场景的重要性优先级，以便大家将有限的时间花在最重要的事情上。

对间接场景进行单个评估

就是将选出来的重要场景与体系结构描述对应起来。体系结构设计师具体说明体系结构需要做哪些修改变更才能适用间接场景的要求，并估计这些变更的代价。

最后形成一份全部场景的总结性列表。

列表字段包括：场景编号、场景描述、直接/间接、需要做的更改、更改/新增构建数量、更改工作量估计

评估场景的相互作用

当两个或多个间接场景需要修改到同一个构建时，这时场景就在这个构件上出现了相互作用，需要特别评估。

出现这种情况，往往是设计方案中功能分配不合理，或者是设计文档未能充分说明体系结构。

形成总体评价

最后，评估人员对场景和场景间的相互作用做一个总体的权衡和评价。通过各个场景权重与分值得出一个总体的评价，从多个体系结构，或者一个体系结构的不同设计方案选择出一个最优的方案。

问题模式 -> 需求说明 -> 架构描述

软件产品线

构件与中间件技术

Web架构技术

信息安全体系

鉴别服务

用户名+口令

数字证书

生物特征识别

访问控制

自主访问控制（DAC）

访问控制列表（ACL）

强制访问控制（MAC）

基于角色的访问控制（RBAC）

基于任务的访问控制（TBAC）

数据完整性

阻止对媒体访问的机制：隔离，访问控制，路由控制

探测非授权修改的机制：数据签名，数据重复，数字指纹，消息序列号

数据保密性

通过禁止访问提供机密性

通过加密提供机密性

抗抵赖

数据签名

可靠性设计

避错技术

测试、技术设计

容错技术（自动化）

结构冗余（硬件、软件）

信息冗余（校验码）

时间冗余（重复多次进行相同计算）

检错技术（被动人工处理）

出错报警，人工处理，成本较低

降低复杂度设计

N版本程序设计（静态冗余）

支付多渠道集成。恢复实时性好，通过表决检测错误，多机硬件运行环境，向前恢复

恢复块设计（动态冗余）

相当于主备，错误回滚到前一个正确的状态。恢复实时性差，通过验证测试程序检测错误，单机硬件运行环境，向后恢复。

防卫式程序设计

try catch, 处理异常

实现策略：错误检测、破坏估计、错误恢复

双机容错

双机热备（主、备）

双机互备（同时提供不同服务、心不跳则接管）

服务器1

服务A(运行)、服务B（未运行）

服务器2

服务A（未运行）、服务B（运行）

双机双工（同时提供相同服务、集群的一种）

项目管理

范围管理

确定项目边界，哪些工作应该做，哪些不包含在项目中。

步骤：

范围计划编制
范围定义
创建WBS
范围确认
范围控制

时间管理（进度管理）

时间管理 - 也叫进度管理，采用科学的方法，确定进度目标，编制进度计划何资源供应计划，进行进度控制，在与质量、成本、目标协调的基础上，实现工期目标。

步骤：

活动定义（WBS工具包）
活动排序

前导图法（单代号网络图，PERT，PDM，有向无环图）

最早开始时间	持续时间	最早完成时间
	活动编号
最长开始时间	总差时	最迟完成时间

注意：总时差为0 是关键活动

关键路径法（双代号网络图）
甘特图（Gantt）

优点：简单直观、容易制作、便于理解，能清晰标识出每一个的起始与结束时间，适用于小型项目，可用于 WBS 的任何层次、进度控制、资源优化、编制资源和费用计划。
缺点：不能系统表达一个项目所包含的各项工作间的复杂关系，难以进行定量的计算和分析，以及计划的优化等。

活动资源估算
专家判断估算
三点估算

一个功能耗时估算三个时间点：简单实现-3人日+(正常实现-5人日*4)+技术难点实现-8人日

算法：3+(5*4)+8/6

解释：由于正常实现加权4倍，总共6倍所以除6

功能点估算
自上而下的估算
功能拆分，估算
自下而上的估算
功能负责人向上报时，统一收集
活动历时估算
制订进度计划
是否为关键活动
偏差是否大于总时长
偏差是否大于自由时差
进度控制
赶工：增加资源
快速跟进：活动并行执行

成本管理

整个项目实施过程中，为确保项目批准的预算条件下尽可能保质按期完成，而对所需的各个过程进行管理与控制

成本估算

自顶向下估算
自低向上估算
差别估算

成本预算

直接成本与间接成本
管理储备
零基准预算

成本控制

挣值分析（挣值管理）

计划工作量的预算成本(PV)

PV = 计划工作量*预算定额

已完成工作量的实际成本（AC）

已完成工作量的预算成本（EV|挣值）

EV = 已完成工作量*预算定额

完工预算（BAC）

BAC=完工时的PV总和

计算指标

进度偏差：SV=EV-PV

成本偏差：CV=EV-AC

进度绩效指数：SPI=EV/PV

成本绩效指数：CPI=EV/AC

剩余工作的成本（ETC）

ETC=BAC-EV

ETC=(BAC-EV)/CPI

完工估算（EAC）

EAC=AC+ETC

x项目在线测试项目设计对10个函数代码的编写（假设每个函数代码编写工作量相等），项目由2个程序员进行结对编程，计划在10天内完成，总体预算1000元，每个函数的平均成本是100元。项目进行到第五天，实际消耗是400元，完成了3个函数的编写。

PV=500

AC=400

EV=300

进度偏差：-200

成本偏差：-100

影响软件质量的3组因素

软件质量管理-质量保证与质量控制

CMMI、ISO9001

质量保证（QA）是每隔一定时间进行的，主要通过系统的质量审计和过程分析保证项目质量。工具包括：质量审计和过程分析。

质量控制（QC）是实时监控项目的具体结果，以判断它们是否符合相关质量标准，制订有效方案。

一定时间内质量控制的结果也是质量保证的质量审计对象。

主要目标：

事情预防工作
尽量在刚刚引入缺陷时即将其捕获，而不是让缺陷扩散到下一个阶段
作用于过程而不是最终产品
贯穿于所有活动之中，而不是集中一点

软件评审

不应以测试代替评审
评审人员应关注于实质性问题
评审会议不应变为问题解决方案讨论会
评审应被安排进入项目计划
评审参与者应了解整个评审过程
评审人员事先应对评材料充分了解
应重视评审的组织工作

软件过程改进 CMMI

国内过了认证之后很少坚持去使用优化

阶段式（组织能力成熟度）

已管理级：需求管理、项目计划、配置管理、项目监督与控制、供应商合同管理、度量和分析、过程和产品质量保证
已定义级：需求开发、计算解决方案、产品集成、验证、确认、组织级过程焦点、组织级培训、集成项目管理、风险管理、集成化的团队、决策分析和解决方案、组织级集成环境
定量管理级：组织级过程性能、定量项目管理
优化级：组织级改革与实施、因果分析和解决方案

用一个通俗类比理解 CMMI

可以把它理解成组织过程能力的升级路线：

已管理级：项目能按计划管起来；
已定义级：组织有统一标准过程，项目按标准裁剪执行；
定量管理级：用数据量化管理过程和项目；
优化级：能分析根因，持续改进过程。

一句话：

CMMI 是看一个组织“做事有没有章法、章法是否统一、能否用数据管、能否持续优化”的成熟度框架。

软件配置管理-配置项与配置库

关于配置项

配置项是构成产品配置的主要元素，分为两大类

基线配置项（可交付成果 - 属于产品组成部分的工作成果）：如需求文档、设计文档、源代码和测试用例、运行软件所需数据等；
非基线配置项（各类计划 - 属于项目管理和机构支撑过程域产生的文档）：工作计划、项目质量报告和项目跟踪报告等。

软件配置管理核心内容包括【版本控制】和【变更控制】

设备清单、CASE工具操作手册不属于配置项

每个配置项主要属性有：名称、标识符、文件状态、版本、作者和日期等。所有配置项都被保存在配置库里，确保捕获混淆、丢失。配置项及其历史记录反映了软件的演化过程。

关于配置库

开发库（动态库、程序员库、工作库）：可以随意修改
受控库（主库、系统库）：必须先申请，申请通过才有权限修改。
产品库（备份库、静态库）：不能修改。

软件工具

软件开发工具：需求分析工具、设计工具、编码与排错工具。
软件维护工具：版本管理工具（VSS、CVS、SCCS、SVN）、文档分析工具、开发信息库工具、逆向工程工具、再工程工具。
软件管理和软件支持工具：项目管理工具、配置管理工具、软件评价工具、软件开发工具和选择。

变更控制

变更申请
变更评估
变更决策
变更实施
变更验证
沟通存档

草稿 0.x -> 通过评审 -> 正式版 1.0 -> 修改 1.1 -> 通过评审 -> 正式版 1.1

风险管理 - 风险概念

关心未来
关心变化
关心选择

基本属性：随机性和相对性

项目风险

预算、进度、人员和组织、资源、用户和需求问题

项目复杂性、规模和结构的不确定性

技术风险

设计、实现、接口、测试和维护方面的问题

规格说明的多义性、技术上的不确定性、技术陈旧、最新技术（不成熟）

商业风险

市场风险：系统虽然优秀，但是脱离市场
策略风险：系统不符企业信息系统战略
销售风险：销售部门不清楚如何推销
管理风险：重点转移或人员变动而失去上级支持
预算风险：过程没有得到预算或人员保证

风险曝光度

技术方法是风险出现概率乘以风险可能造成的损失。风险曝光度=风险影响*概率

假设正在开发的软件项目可能存在一个未被发现的错误，而错误出现概率是0.5%，给公司造成损失将是1000000元，错误风险曝光度为：1000000*0.5%=5000元。

项目管理工具

能做什么（项目管理相关的工作辅助）：任务调度、成本估算、资源分配、预算跟踪、人时统计、配置控制，确定关键路径、松弛时间、超前时间和滞后时间，生成一定报表和报告。

不能做什么（开发技术相关辅助工作）：不能指导软件设计人员按软件生存周期各个阶段使用技术进行设计工作。

盈亏平衡

敏捷方法

传统软件开发方法

预设性
以开发过程为本
整体分阶段

敏捷方法

适应性
以人为本
增量迭代，小步快跑
适合小型项目

敏捷宣言

个体和交互胜过过程和工具
可工作的软件胜过大量的文档
客户合作胜过合同谈判
响应变化胜过遵循计划

敏捷方法 - XP

价值观【交流、朴素、反馈、勇气】、近螺旋式的开发方法。

4大价值观

沟通【加强面对面沟通】
简单【不过度设计】
反馈【及时反馈】
勇气【接受变更的勇气】

12条过程实践规则

简单设计
测试驱动
代码重构
结对编程
持续集成
现场客户
发行版本小型化
系统隐喻
代码集体所有制
规划策略
规范代码
40小时工作机制

敏捷方法 - SCRUM

侧重于项目管理

敏捷方法 - 水晶方法

提倡机动性的方法，拥有不同类型项目非常有效的敏捷过程。

敏捷方法 - 特征驱动开发方法（FDD)

认为有效的软件开发需要三要素【人、过程、技术】

关键的项目角色：项目经理、首席架构设计师、开发经理、主程序员、程序员和领域专家

敏捷方法 - 开放式源码

程序开发在地域上分布很广【其他方法强调集中办公】

敏捷方法 - ASD 方法

其核心是三个非线性的、重叠的开发阶段：猜测、合作与学习

敏捷方法 - 动态系统开发方法（DSDM）

倡导以业务为核心。

逆向工程

逆向工程用于恢复信息的方法有四类

用户指导下的搜索与变换：用于导出实现级和结构级信息。
变换式方法：除领域级外所有的抽象级别上的信息都可以用此方法推导
- 自动分析法：不需要维护人员过多干涉（静态分析和调用图、控制流图生成等）
- 用户指导变换法：基于特定库
基于领域知识的方法：主要用于恢复功能级和领域级信息。领域知识一般用规则库表示，用已确定或假定的领域概念与代码之间的对应关系推导进一步的假设，最后导出程序的功能。该类方法的不确定性最大。
铅板恢复法：仅适用于推导实现级和结构级信息，用于识别程序设计铅块或公共结构，铅板可为一个简单算法，也可以使相对复杂的成分。包含大量推理与决策。

方法	适用抽象级别	人工参与/依赖	理解要点
用户指导下的搜索与变换	实现级、结构级	人工指导较多	人带目标搜索并变换代码
变换式方法	除领域级外所有级别	依赖变换	把程序表示转成更抽象表示
自动分析法	主要实现级、结构级	人工干涉少	静态分析、调用图、控制流图
用户指导变换法	原文未明确，可归入用户指导类	基于特定库、用户指导	依赖变换库做恢复
基于领域知识的方法	功能级、领域级	依赖领域规则库	用领域概念与代码对应关系推导功能，不确定性最大
铅板恢复法	实现级、结构级	含大量推理与决策	识别程序设计中的公共结构/模式

教材方法	实际技术/工具举例	大白话
用户指导下的搜索与变换	IDE 全局搜索、正则搜索、结构化搜索替换、人工读代码、手工重构、程序切片辅助	人带着问题去代码里搜：这段逻辑在哪、谁调用它；边搜边整理、改写成更好理解的表示。
变换式方法	反汇编/反编译、AST 转换、模型转换、重构引擎、程序表示转换、抽象解释类分析	把“代码形态”一步步换成更抽象、更好懂的形态，比如机器码→汇编→高级表示，或源码→抽象语法树→结构图。
自动分析法	静态分析工具、调用图生成、控制流图生成、数据流分析、依赖分析；如 Understand、Source Insight、cflow、Soot、Joern 等	工具自动扫代码，画出“谁调用谁”“程序怎么走”“数据从哪来到哪去”，人少插手。
用户指导变换法	基于重构库/变换库/模式库的工具，人工选择变换规则；结构化搜索替换、重构工具、特定领域转换脚本	工具提供一套“变换招式库”，人挑招式来改代码或恢复结构，不是全自动。
基于领域知识的方法	领域规则库、业务规则匹配、领域本体、专家系统、代码与业务概念映射	靠“懂业务的人+业务规则”去猜代码在干什么：看到订单表、库存字段，推断这是下单/扣库存功能。最靠经验，所以不确定性最大。
铅板恢复法	设计模式识别、代码克隆检测、代码坏味识别、常见程序惯用法/idiom 识别、模式匹配	看代码里反复出现的“套路”：这段像单例、那段像工厂、这里是循环累加。认出套路，就恢复出程序里的公共结构