对软考高级系统架构设计的历年核心考点进行详细的梳理和精华知识总结，万字长文，先收藏，然后认真阅读，重在理解和记忆。

1

系统架构设计基础知识

一. 系统架构概述

系统架构的定义

系统架构（System Architecture）是系统的一种整体的高层次的结构表示，是系统的骨架和根基，支撑和链接各个部分，包括构件、连接件、约束规范以及指导这些内容设计与演化的原理，是刻画系统整体抽象结构的一种手段。

软件架构的定义

软件体系结构为软件系统提供了结构、行为和属性的高级抽象，由构成系统的元素描述、元素的外部可见属性、这些元素的相互作用、指导元素集成的模式以及这些模式的约束组成。软件体系结构不仅指定了系统的组织结构和拓扑结构，并且显示了系统需求和构成系统的元素之间的对应关系，提供了一些设计决策和演化的基本原理，是构建于软件系统之上的系统级复用。

信息系统架构的定义

信息系统架构 ISA 是关于软件系统的结构、行为和属性的高级抽象，结构中包括软件的构件、构件的外部可见属性、这些构件之间的相互关系。

在描述阶段，其对象是直接构成系统的抽象组件以及各个组件之间的连接规则，特别是相对细致的描述组件之间的通信。

在实现阶段，这些抽象组件被细化为实际的组件，比如具体的类、对象。

1.架构描述语言（ADL)
架构描述语言（Architecture Description Language, ADL）是一种为明确说明软件系统的概念架构和对这些概念架构建模提供功能的语言。

2.ADL基本构成要素
ADL即架构描述语言，其基本构成要素包括：组件、组件接口、连接件、架构配置。

组件（构件）是一个计算单元或数据存储。也就是说，组件是计算与状态存在的场所。在架构中，一个构件可能小到只有一个过程或大到整个应用程序。

连接件是用来建立组件间的交互以及支配这些交互规则的架构构造模块。

架构配置或拓扑是描述架构的组件与连接件的连接图

二. 软件架构的生命周期

1. 需求析阶段           

从软件需求模型向SA模型的转换，主要关注两个问题：

(1) 根据需求模型构建架构模型：用例图经过词法分析转换为SA模型（类图）。

(2) 保证模型转换的可追踪性：表格或用例映射。

2. 设计阶段           

这个阶段的研究主要包括3个方面：

(1) SA模型的描述

(2) SA模型的设计与分析方法

(3) 对SA设计经验的总结与复用

SA模型描述的三个层次

(1) SA的基本概念：SA描述方法是构件和连接子的建模。

(2) 体系结构描述语言ADL：支持构件、连接子及其配置的描述语言。

(3) SA模型的多视图表示：体现了关注点分离的思想。“4+1”视图模型。

1. 逻辑视图：最终用户关注系统的功能，描述系统的静态结构。

表示了设计模型中在架构方面具有重要意义的部分。

记录设计元素的功能和概念接口。（类图、对象图）

2. 开发视图：程序员关注系统的实现, 描述系统构件组织和模块之间的依赖。

对组成系统的构件进行建模，描述了在开发环境中软件的静态组织结构，代码构件组织、模块、模块之间的依赖关系。（模块结构图、构件图）

3. 过程视图：系统集成人员关注并发和同步特征，描述线程间的并发和同步。

可执行线程和进程作为活动类的建模，是逻辑视图的一次执行实例，描述了并发与同步结构。（活动图、状态图）

4. 物理视图：系统工程师关注系统的部署、安装, 定义软硬件的物理体系结构。

描述了软件到硬件的映射，主要描述硬件配置，系统中软硬件的物理体系结构及连接。（配置图）

5. 统一场景：分析人员和测试人员关注系统的行为。

用例：描述功能需求。

质量场景：描述质量需求。

3. 实现阶段           

这个阶段的研究主要包括3个方面：

(1) 研究基于SA的开发过程支持：项目组织结构、配置管理。

(2) 寻求从SA模型向实现过渡的途径：模型映射、构件组装、复用中间件平台。

(3) 研究基于SA的测试技术。

填补高层SA模型和底层实现的鸿沟的典型方法

(1) 在SA模型中引入实现阶段的概念，如引入程序设计语言元素。

(2) 通过模型转换技术，将高层的SA模型逐步精化成能够支持实现的模型。

(3) 封装底层的实现细节，使之成为较大粒度构件，在SA指导下通过构件组装的方式实现系统，通常需要底层中间件平台的支持。

4. 构件组装阶段           

这个阶段的研究主要包括2个方面：

(1) 支持可复用构件的互联，即对SA设计模型中规约的连接子的实现提供支持。

(2) 在组装过程中，检测并消除体系结构失配问题。

对设计阶段连接子的支持：

将连接子转换为具体的程序代码，在工具的支持下，生成连接子的代码。

中间件的基本功能：

提供了构件之间跨平台交互的能力。

提供强大的公共服务能力。

体系结构失配：待复用构件对最终系统的体系结构和环境的假设，与实际状况不同而导致的冲突。

5. 部署阶段           

SA对软件部署的作用：

(1) 描述部署阶段的软硬件模型：基于SA提供的高层的体系结构视图。

(2) 分析部署方案的质量属性：基于SA模型分析，选择合理的部署方案。

6. 后开发阶段           

这个阶段的研究主要围绕维护、演化、复用来进行，有2个典型的研究方向：

(1) 动态软件体系结构

• 体系结构设计阶段的支持

变化的描述、修改策略、描述修改过程、修改的可行性、修改所带来的影响。

• 运行时刻基础设施的支持

体系结构的维护、保证修改在约束范围内、运行时刻信息、分析修改后的体系结构符合指定的属性、正确映射构造元素的变化到实现模块。

(2) 体系结构恢复与重建

从已实现的系统中获取体系结构的过程，输出一组体系结构视图。

重建的方法分为4类：手工重建、工具支持的手工重建、通过查询语言来自动建立聚集、使用其它技术(数据挖掘)。

三. 基于架构的软件设计ABSD

基于体系结构的软件设计 Architecture-Based Software Design

ABSD方是体系结构驱动的，指由构成体系结构的商业、质量、功能需求的组合驱动的架构设计。

ABSD方法是一个自顶向下、递归细化的方法，软件系统的体系结构通过该方法得到细化，直到能产生软件构件和类。

ABSD设计活动从项目总体框架明确就开始，此时需求抽取和分析还没完成。

ABSD法的3个基础

1. 功能的分解。

2. 通过选择体系结构风格来实现质量和商业需求。

3. 软件模板的使用。

视角与视图 — 描述软件架构

用例 — 描述功能需求

质量场景 — 描述质量需求

静态视角：展示功能组织，判断质量特性。

动态视角：展示并发行为，判断行为特性。

• 描述软件架构：视角 + 视图

• 描述需求：用例(功能需求) + 质量属性场景(质量需求)

要点1：使用ABSD方法的3个基础

(1) 功能的分解：使用已有的基于模块的内聚和耦合技术。

(2) 选择架构风格：实现质量和业务需求。

(3) 软件模块的使用：复用软件系统的结构。

要点2：基于架构的开发模型

需求获取 -> 生成类图 -> 对类进行分组 -> 把类打包成构件 -> 需求评审

提出架构模型 -> 映射构件 -> 分析构件相互作用 ->产生架构 -> 设计评审

体系结构规格说明 + 测试体系结构需求的质量设计说明书

阶段1：架构需求

1. 需求获取

2. 标识构件：生成类图 —> 对类进行分组 —> 把类打包成构件

3. 需求评审

阶段2：架构设计

1. 提出架构模型

2. 把已标识的构件映射到架构中

3. 分析构件之间的相互作用

4. 产生软件体系结构

5. 设计评审

阶段3：架构文档化

体系结构规格说明

测试体系结构需求的质量设计说明书

阶段4：架构复审

安排一次由外部人员（用户代表和领域专家）参加的复审，标识潜在的风险，及早发现架构设计中的缺陷和错误。

阶段5：架构实现

1. 复审后的文档化的架构

2. 分析与设计

3. 构件实现

4. 构件组装

5. 系统测试

6. 架构演化

阶段6：架构演化

1. 需求变化归类

2. 制订架构演化计划

3. 修改、增加、删除构件

4. 更新构件的相互作用

5. 构件组装与测试

6. 技术评审

四. 架构风格

架构风格：描述某一特定应用领域中系统组织方式的惯用模式，反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。

一个架构定义了一个词汇表和一组约束。

词汇表：包含一些构件和连接件类型。

约束：指出系统是如何将这些构件和连接件组合起来的。

对架构风格的研究和实践促进对设计的重用。

5类架构风格

架构风格	定义	代表
1. 数据流	面向数据流，按照一定的顺序从前向后执行	批处理序列 管道-过滤器
2. 调用/返回	构件之间存在显式的互相调用关系	主程序/子程序 面向对象 层次结构 客户端/服务器
3. 独立构件	每个构件都相对独立，构件之间不直接通信，不存在显式的调用关系，而是通过某个事件触发、异步的方式来执行（隐式调用）	进程通信 事件系统
4. 虚拟机	自定义一套规则，使用者基于这个规则来开发构件，能够跨平台适配，规则随时改变，业务灵活定义、组合	解释器 基于规则的系统
5. 仓库	以数据为中心，所有的操作都是围绕建立的数据中心进行的	数据库系统 超文本系统 黑板系统

1. 数据流风格

批处理序列：每个处理步骤是一个单独的程序，每一步必须在前一步结束后才能开始，数据必须是完整的，以整体的方式传递。

构件：一系列固定顺序的独立应用程序，构件之间只通过数据传递交互。

连接件：某种类型的媒介。

管道-过滤器：对数据的处理分解为几个序贯的步骤，处理步骤由过滤器实现，数据传输由管道负责。每个构件都有一组输入和输出，构件读取输入的数据流，经过内部处理，产生输出数据流。每个阶段产生的结果作为下一个阶段的输入，即前一个构件的输出作为后一个构件的输入，前后数据流关联，前面执行到部分可以开始下一个的执行。

构件：过滤器。

连接件：管道。

2. 调用/返回风格

主程序/子程序：单线程控制，显式调用，主程序直接调用子程序，过程调用作为交互机制，调用关系具有层次性。

构件：主程序、子程序。

连接件：过程调用。

面向对象：对象封装了属性和操作，通过对象调用封装的方法和属性。

构件：对象。

连接件：过程调用。

层次结构：每层为上一层提供服务，使用下一层的服务，只能见到与自己相邻的层接口。修改某一层，最多只影响其相邻的两层，通常只能影响上层。

优点：

(1) 支持基于可增加抽象层的设计，将一个复杂问题分解成一个增量步骤序列的实现。

(2) 不同的层次处于不同的抽象级别，越靠近底层，抽象级别越高，核心层封装通用的方法，与业务无关。

(3) 由于每层最多只影响两层，只要给相邻层提供相同的接口，允许每层用不同的方法实现，为软件复用提供支持。

缺点：

(1) 很难找到一个合适且正确的层次抽象方法，系统划分层次不容易。

(2) 层次越多，性能越差。

构件：组成一个层次结构。

连接件：通过决定层间如何交互的协议来定义。

3. 独立构件风格

进程通信：独立的进程间消息传递的方式可以是点对点、同步、异步、远程过程调用。

构件：独立的进程。

连接件：消息传递。

事件驱动(隐式调用)：基于事件的隐式调用，用于实现松耦合的组件通信。

构件之间不直接调用彼此的方法，而是通过事件驱动，采用发布-订阅的模式进行通信。构件中的过程在一个或多个事件中注册，这些过程被绑定到特定的事件上，当该事件被触发时，在这个事件中注册的相应过程会被自动调用。

构件：一些模块（过程、事件的集合）。

连接件：在事件中注册一些过程，当发生这些事件时，过程被调用。

4. 虚拟机风格

解释器：解析与运行自定义的规则/业务/语言，通常被用来建立一种虚拟机，以弥合程序语义与硬件语义之间的差异，但执行效率低。

解释引擎-解释自定义的规则，存储区-存放被解释的程序，存放解释引擎当前工作状态的数据结构，存放程序被解释执行进度的数据结构。

基于规则的系统：将业务逻辑中频繁变化的部分定义为规则，通过灵活的自定义规则，实现规则的重组。

规则定义：根据具体需求，设计和定义一系列规则，形成规则集。

数据输入：数据输入至工作内存，并进行预处理。

规则匹配：通过规则选择器，将输入数据与规则集中的规则进行匹配。

操作执行：当规则匹配成功，由规则解释器根据规则定义的操作执行相应的动作。

输出生成：根据执行结果生成输出数据。

5. 仓库(共享数据)风格

数据库系统：中央共享数据源+多个独立处理的构件。

黑板系统：适用于解决复杂的非结构化问题，解空间很大，求解过程不确定，对于解决问题没有确定性算法，求解过程中综合运用多种不同的知识源。

(1) 知识源：独立计算的不同单元；(2)黑板：全局数据库；(3)控制：通过黑板状态的变化来控制。

应用于信号处理、语音识别、问题规划、编译器优化、知识推理、松耦合代理数据共享存取。

超文本系统：互联网领域，网状链接，构件之间任意跳转。

6. 闭环控制风格

发出控制命令并接收反馈，循环往复达到平衡，设定参数，不断调整。

适合于嵌入式系统，涉及连续的动作与状态。软件与硬件之间可以表示为一个反馈。汽车巡航定速。

7. C2体系结构风格

通过连接件绑定在一起，按照一组规则运作的并行构件网络。顶部、底部。

五. 特定领域软件体系结构DSSA

特定领域软件体系结构 DSSA（domain specific software architecture）

定义：专用于一类特定的应用领域，支持一组应用的领域模型、参考需求、参考架构等组成的标准体系结构，目标是支持在一个特定领域中多个应用的生成。

是在整个领域中能有效使用的、标准的组合结构的软件构件的集合。

DSSA的必备特征

1. 一个严格定义的问题域和问题域解。

2. 具有普遍性，可用于领域中某个特定应用的开发。

3. 对整个领域的构件组织模型的恰当抽象。

4. 具备该领域固定的、典型的在开发过程中可重用元素。

垂直域：局限在一个特定领域中的通用的完整的软件架构。

水平域：横跨多个不同的领域，涵盖多个领域之间相同的、共有的部分功能。

要点1：DSSA的3个基本活动

1. 领域分析

主要目标：获得领域模型。

定义领域的边界，分析领域中系统的需求，确定哪些需求是领域中的系统广泛共享的，从而建立领域模型。（问题域）

领域模型：描述领域中系统之间的共同需求。

2. 领域设计

主要目标：获得DSSA特定领域的软件架构。

DSSA描述在领域模型中表示的需求的解决方案，适应领域中多个系统的需求的一个高层次的设计。（解空间）

3. 领域实现

主要目标：依据领域模型和DSSA，开发和组织可重用信息。

可重用信息：从现有系统中提取得到、通过新的开发得到。

要点2：建立DSSA的5个过程

1. 定义领域范围：领域中的应用要满足用户一系列的需求。

2. 定义领域特定的元素：建立领域字典、归纳领域术语的同义词、识别出领域中相同和不同的元素。

3. 定义领域特定的设计和实现需求的约束：描述解空间中有差别的特性。

4. 定义领域模型和架构：产生一般的体系结构，说明构成它们的模块或构件的语法和语义。

5. 产生、搜集可复用的产品单元：为DSSA增加可复用的构件。

总结：DSSA 的建立过程是并发的、递归的、反复进行的。该过程的目的是将用户的需求映射为基于实现限制集合的软件需求，这些需求定义了DSSA。

要点3：DSSA的三层次系统模型

1. 领域 开发环境：核心通用架构、领域模型、参考需求、参考结构。

2. 领域特定的 应用开发环境：根据具体环境把核心架构实例化。

3. 应用 执行环境：实现实例化的架构。

要点4：参与DSSA的4种角色

1. 领域专家：提供需求规约、实现知识、领域字典、领域模型、DSSA、样本系统。

2. 领域分析人员：控制领域分析过程，将获取的知识组织到领域模型中，验证领域模型的准确性和一致性，维护领域模型。

3. 领域设计人员：根据领域模型开发出DSSA，建立领域模型和DSSA之间的联系。

4. 领域实现人员：开发可重用构件、从现有系统中提取可重用构件，对可重用构件进行验证，建立DSSA与可重用构件之间的联系。

六. 系统架构评估

架构分析是在架构满足功能需求的前提下，为满足质量属性需求寻找适当的架构策略，重点关注软件系统的质量属性，通常采用质量属性场景的方式来精确、定量的描述。

质量属性的定义

质量属性是一个系统的可测量或者可测试的属性，用来描述系统满足利益相关者需求的程度。

面向架构评估的质量属性

1. 性能 

系统的响应能力，用系统完成某个事务处理所需的时间、单位时间内所处理事务的数量来对性能进行定量表示，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件的个数。

2. 可用性

系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。MTBF = MTTF + MTTR

3. 可靠性

系统能够持续无故障运行的能力，在意外或错误使用的情况下，维持软件系统的功能特性的基本能力。可靠性是最重要的软件特性，分为两个方面：

容错：在错误发生时，确保系统正确的行为，并进行内部修复。

健壮性：应用程序不受错误使用和错误输入的影响，在发生意外错误时，确保应用系统处于预先定义好的状态，保证软件按照某种已经定义好的方式终止执行。

4. 安全性

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

机密性：保证信息不泄露给未授权的用户、实体或过程。

完整性：保证信息的完整和准确，防止信息被非法修改。

不可否认性：信息交换的双方不能否认其在交换过程中发送或接收信息的行为。

可控性：保证对信息的传播及内容具有控制的能力，防止为非法者所用。

5. 可修改性

能够快速的以较高的性价比对系统进行变更的能力。

可维护性：问题的修复对其它构件的负面影响最小化。

可扩展性：使用新特性来扩展软件系统。
结构重组：重新组织软件系统的构件、构件间的关系，在不影响实现的主体部分的情况下，灵活的配置构件。

可移植性：系统能够在不同计算环境下运行的能力，适用于多种硬件平台、操作系统、用户界面、编程语言或编译器。

6. 功能性

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

7. 可变性

架构经扩充/变更，而成为新架构的能力。

8. 互操作性

系统通常与其它系统或自身环境相互作用，必须为外部可视的功能特性和数据结构提供精心设计的软件入口。

质量属性场景描述

质量属性场景（Quality Attribute Scenario）是一个具体的质量属性需求，是利益相关者与系统的交互的简短陈述。

场景要素	概念	情况
1. 刺激源	生成刺激的实体	最终用户、开发人员、系统管理员
2. 刺激	当刺激到达系统时，需要考虑的条件	希望增加、删除、修改、概念功能、质量属性、容量
3. 环境	刺激在某些条件内发生	系统设计时、编译时、构建时、运行时
4. 制品	某个制品被激励，被刺激的客体	用户界面、平台、与目标系统交互的系统
5. 响应	在激励到达后所采取的行动	查找架构中需要修改的位置，进行修改且不影响其他功能，对所做修改进行测试，部署所做的修改
6. 响应度量	当响应发生时，应当能够以某种方式对其进行度量	根据所影响元素的数量度量的成本、努力、资金； 该修改所造成影响的程度

架构评估中的重要概念

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

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

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

风险点：可能引起风险的因素，可能导致一些问题。

非风险点：如果某件事是可行的、可接受的，则为非风险点。

场景：从风险承担者的角度对系统的交互的简短描述，描述了各种系统必须支持的活动和可能存在的状态变化，一般用刺激、环境、响应三方面来对场景进行描述。

3种类型的场景

用例场景：对系统典型的使用、引出信息，面向最终用户。

增长场景：对系统的修改，代表了架构发展的方式。
探索场景：可能会对系统造成过载的极端修改，架构中极端的增长形式。

系统架构评估

是在对架构分析、评估的基础上，对架构策略的选取进行决策。

利用数学或逻辑分析技术，针对系统的一致性、正确性、质量属性、规划结果等不同方面，提供描述性、预测性和指令性的分析结果。

3类系统架构评估的方法

1. 基于问卷调查或检查表

2. 基于场景的评估方法：SAAM、ATAM

3. 基于度量的评估方法

1

  软件架构分析方法 SAAM

基于场景的架构分析方法 Scenarios-based Architecture Analysis Method

SAAM的基本特点是把任何形式的质量属性都具体化为场景，但可修改性是SAAM分析的主要质量属性。是最早形成文档并得到广泛使用的软件架构分析方法，最初用于比较不同软件体系的架构，以分析系统架构的可修改性，后来实践证明也可用于其它非功能质量属性，最终发展成了评估一个系统架构的通用方法。

SAAM的优点

1. 有利于评估架构固有的风险。

2. 指导对架构的检查，主要关注潜在的问题点。

3. 评估架构对于特定系统需求的使用能力。

4. SAAM被用来比较不同的架构。

SAAM的主要输入

1. 问题描述

2. 需求声明

3. 架构描述

SAAM分析评估架构的过程包括5个步骤

1. 场景开发

通过各类风险承担者协商讨论，开发一些任务场景，体现系统所支持的各种活动。

2. 架构描述

体现系统的计算构件、数据构件以及构件之间的关系（数据和控制）。

3. 单个场景评估

对场景生成一个关于特定架构的场景描述列表（直接场景和间接场景）。

4. 场景交互评估

通过对场景交互的分析，得出系统中所有场景对系统中的构件所产生的影响的列表。

5. 总体评估

对场景和场景间的交互作一个总体的权衡和评价。

	SAAM方法	ATAM方法
定义	基本特点是把任何形式的质量属性都具体化为场景，但可修改性是SAAM分析的主要质量属性。是最早形成文档并得到广泛使用的软件架构分析方法。	主要针对性能、可用性、安全性、可修改性，在系统开发之前，对这些质量属性进行评价和折中。 分析多个相互竞争的质量属性，权衡取舍。
特定目标	对描述应用程序属性的文档，验证基本的架构假设和原则。	在考虑多个相互影响的质量属性的情况下，确定在多个质量属性之间折中的必要性，提供一种架构策略
质量属性	可修改性	性能、可用性、安全性、可修改性
评估技术	场景技术	场景技术
风险承担者	不同参与者感兴趣的共同方面	所有系统相关人员
架构描述	用于架构的最后版本，但早于详细设计。 描述架构的3个主要方面：功能、结构、分配	基于5种基本结构： 1. 功能结构 2. 代码结构 3. 过程结构 4. 数据结构 5. 部署结构
方法活动	1. 场景开发 2. 架构描述 3. 单个场景评估 4. 场景交互 5. 总体评估	场景和需求收集 架构视图描述和场景实现 属性模型构造和分析 对质量属性进行评价和折中
领域知识库的可重用性	不考虑	领域知识库通过ABAS维护。 ABAS 基于属性的架构风格。 基于特定质量属性的模型 基于属性的架构分析的标准问题集合
方法验证	空中交通管制、嵌入式音频、修正控制WRCS、根据上下文查找关键词KWIC	质量属性效用树Utility tree

2

  架构权衡分析法 ATAM

架构权衡分析法 Architecture Tradeoff Analysis Method

目标：以质量属性作为架构评估的核心概念，分析多个相互竞争的质量属性，对这些质量属性进行评价和折中。

4个主要的活动领域（阶段）

1. 场景和需求收集

2. 架构视图描述 + 场景实现

3. 属性模型构造和分析

4. 对质量属性进行评价和折中

质量属性效用树 Utility tree

对质量属性进识别和优先级排序。

树的结构：效用(树根) — 质量属性 — 属性分类 — 质量属性场景(叶子节点）

效用树沿着2个维度进行优先级排序：

场景对系统成功的重要性；

场景实现的难易程度。

每个场景有一个优先级对：（重要度，难易度）

例如：（H，L）表示该场景重要且易实现

评估的步骤

一. 描述和介绍阶段

1. 介绍ATAM方法

2. 描述业务目标

3. 描述体系结构

二. 调查和分析阶段

1. 确定架构方法

2. 生成质量属性效用树

3. 分析架构方法

三. 测试阶段

1. 讨论场景和对场景分级

2. 分析架构方法

四. 报告阶段

1. 描述评估结果。

评估步骤详解

一. 描述和介绍阶段

1. 介绍ATAM方法

评估小组负责人向所有参与者描述ATAM方法、介绍ATAM的信息、说明评估中使用的分析技术、说明评估的预期结果、解答疑问。

2. 描述业务目标

项目决策者从业务角度，提供被评估系统的业务目标、系统功能、利益相关方、系统其它限制的更多信息。

3. 描述体系结构

首席架构师演示体系结构、描述要评估的架构、为满足质量属性而实施的架构方法。侧重于体系结构的质量要求、技术约束。

二. 调查和分析阶段

4. 确定架构方法

架构设计师确定能达成关键目标的架构方法，解释了架构的流程控制。

5. 生成质量属性效用树

场景生成、对质量属性进刻画和优先级排序。

6. 分析架构方法

• 评估小组调查架构方法，分析能否满足这些质量属性。

• 创建分析问题，高优先级场景中产生的分析问题。

• 分析问题的答案。

• 确定架构方法的风险、非风险、敏感点、权衡点。

风险点：可能引起风险的因素，可能导致一些问题。

非风险点：如果某件事是可行的、可接受的，则为非风险点。

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

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

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

三. 测试阶段

7. 讨论场景和对场景分级

• 利益相关者使用头脑风暴收集场景。

• 相同质量属性有关的所有场景都被合并，利益相关者投票选出各自认为的最重要的场景，票数 = 场景总数 x 30%

• 场景按总票数排序。

• 将头脑风暴请求的优先列表与步骤5中质量属性效用树进行比较。

8. 分析架构方法

仍然是4个步，区别在于，步骤6中高优先级质量属性来自效用树，这一步要考虑头脑风暴投票中票数最高的质量属性，可能会新产生一些高优先级的质量属性，检查相应的架构设计方案是否能满足这些质量属性。

• 调查架构方法

• 创建分析问题

• 分析问题的答案

• 确定架构方法的风险、非风险、敏感点、权衡点

四. 报告阶段

9. 评估小组负责人描述评估结果，产出具体的报告。

3

  成本效益分析法 CBAM

Cost Benefit Analysis Method

对架构设计决策的成本和收益进行建模，根据投资收益率ROI来选择合适的架构。作为ATAM的补充，在ATAM确定满足质量属性的基础上，再对效益进行分析。

八. 架构设计的方法

架构设计的核心问题：能否达到架构级别的软件重用。

架构设计主要关注软件构件的结构、属性和交互作用。

1. 领域驱动 domain-driven

通过面向领域的思维方式，将要解决的业务概念和业务规则等内容提炼为领域知识，然后借由不同的建模范式，将这些领域知识抽象为能够反映真实世界的领域模型，从领域模型导出架构抽象。

领域：业务范围，范围即是边界。

子领域：对领域进行拆解，将其细化为多个子领域。

核心域：直接对业务产生价值，是决定产品核心竞争力的子域。

通用域：通用功能子域，具有通用性，例如：鉴权、登录等。

支撑域：支撑其它领域业务，具有企业特性，间接对业务产生价值。

DDD分层架构

调用关系：接口层 -> 应用层 -> 领域层 -> 基础层

1. 接口层

完成具体用户请求。

包括：controller、远程调用服务。

2. 应用层

对领域层做编排，协调下一层中的领域对象，只负责分配工作，不包含业务规则，尽量简单。

包括：AppService，消息处理。

3. 领域层

是系统的核心，封装业务逻辑。

包括：模型、值对象、域服务、事件。

4.  基础设施层

对所有上层提供技术能力。

包括：数据库、事件总线、发送消息、消费消息、API网关、缓存等。

DDD六边形架构

系统通过适配器的方式与外部交互，将应用服务和领域服务封装在系统内部。

2. 工件驱动 attifact-driven

从工件描述中提取架构。

3. 用例驱动 usecase-driven

从用例导出架构抽象。

4. 模式驱动 pattern-driven

从模式导出架构抽象。

5. 属性驱动 attribute-driven

从设计过程中获得架构质量属性需求。

九. 架构模型

1

  层次式架构

1. 表现层：用户界面，负责视觉和用户互动。

2. 业务层（中间层): 实现业务逻辑。

3. 数据访问层（持久层): 提供数据，SQL语句就放在这一层。

4. 数据层：保存数据。

2

  微服务架构

3

  云原生架构

云架构的组成

1. 处理单元

实现业务逻辑

2. 虚拟中间件

负责通信、保持会话控制、数据复制、分布式处理、处理单元的部署。

(1) 消息中间件

管理用户请求和会话控制，当一个请求进来以后，它决定分配给哪一个处理单元。

(2) 数据中间件

将数据复制到每一个处理单元，即数据同步。

(3) 处理中间件

如果一个请求涉及不同类型的处理单元，该中间件负责协调处理单元。

(4) 部署中间件

负责出库单元的启动和关闭，监控负载和响应时间，当负载增加，就新启动处理单元；负载减少，就关闭处理单元。

4

  面向服务架构

5

  事件驱动架构

通过事件进行通信的软件架构，分成四个部分：

1. 事件队列：接收事件的入口。

2. 分发器：将不同的事件分发到不同的业务逻辑单元。

3. 事件通道：分发器与处理器之间的联系渠道。

4. 事件处理器：实现业务逻辑，处理完成后会发出事件，触发下一步操作。

6

  微核架构

又称为插件架构，指软件的内核相对较小，主要功能和业务都能通过插件实现。

内核core通常只包含系统运行的最小功能。

插件是相互独立的，插件之间的通信应该减少到最低，避免出现互相依赖的问题。

2

软件工程基础知识

软件开发生命周期

• 软件定义时期：问题定义、可行性研究、需求分析。

• 软件开发时期：概要设计、详细设计、编码、测试。

• 软件运行和维护：软件产品移交给用户使用。

软件系统的文档

• 用户文档：描述系统功能、使用方法。

• 系统文档：描述系统设计、实现、测试。

软件系统工具

• 开发工具：需求分析工具、设计工具、编码与排错工具、测试工具。

• 维护工具：版本控制工具、文档分析工具、开发信息库工具、逆向工程工具、再工程工具。

• 管理和支持工具：项目管理工具、配置管理工具、软件评价工具、软件开发工具的评价和选择。

软件工程过程：包括4个方面活动

• P（Plan）-- 软件规格说明。规定软件的功能及其运行时的限制。

• D（Do）-- 软件开发。开发出满足规格说明的软件。

• C（Check）-- 软件确认。确认开发的软件能够满足用户的需求。

• A（Action）-- 软件演进。在运行过程中不断改进以满足客户新的需求。

软件设计的4个活动

1. 数据设计

2. 架构设计（体系结构设计）

3. 人机界面设计（接口设计）

4. 过程设计

一

软件过程模型

1

  瀑布模型

是一个严格串行化的过程模型，因果关系紧密相连，前一个阶段工作的输出结果，是后一个阶段工作的输入。每一个阶段工作完成后，都伴随着一个里程碑，对该阶段的工作进行审查和确认。

• 严格的顺序限制了开发的灵活性。

• 不适应需求变化，难以快速响应变化。

• 风险管理困难。

• 缺乏客户参与，用户在开发过程中的反馈和意见很难被及时纳入。

• 过程不可逆，导致后期发现问题时，无法及时修正。

2

  原型模型

根据用户提出的软件系统的定义，快速的开发一个原型，该原型包含目标系统的关键问题、反映目标系统的大致面貌。

• 水平原型（行为原型）：只是功能的导航，主要用在界面上。

• 垂直原型（结构化原型）：实现了部分功能，主要用在复杂的算法实现上。

• 抛弃原型：在需求确认后，原型被抛弃不用。

• 演化原型：在需求确认后，不断补充和完善原型，直至形成一个完整的产品。

3

  螺旋模型

在快速原型的基础上扩展而成，支持大型软件开发，适用于具有高风险的系统。

• 目标设定：需求分析，指定对过程和产品的约束，制订详细的管理计划。

• 风险分析：对可选方案进行风险识别、制订解决办法，采取措施避免风险。

• 开发和有效性验证：实施工程，开发原型，开发软件产品。

• 评审：客户评估，对项目进行评审，制订下阶段计划。

总结：为了使软件生命周期中的各项任务能够有序的按照规程进行，需要一定的工作模型对各项任务给予规程约束，这样的工作模型 称为 软件过程模型。

二

敏捷模型

敏捷方法的特点

• 适应性，而非预设性。

• 面向人的，而非面向过程的。

敏捷方法的核心思想

• 适应性，而非可预测。

• 以人为本，而非以过程为本。

• 迭代增量式的开发过程。

主要敏捷方法

1. 极限编程XP  

是一种近螺旋式的开发方法，提倡测试先行，将复杂的开发过程分解为一个个相对比较简单的小周期，通过交流、反馈、简单、勇气，开发人员和客户可以非常清楚开发进度、变化、待解决的问题、潜在的困难等，并根据实际情况及时的调整开发过程。

在执行交付计划之前，极限编程要求团队对系统的架构做一次预研（架构穿刺），当架构的初始方案确定后，就可以进入每次小版本的交付，每个小版本交付又被划分为多个周期相同的迭代，在迭代过程中，要求执行一些必须的活动，如编写用户故事、故事点估算、验收测试等。

2. 水晶系列方法  

提倡“机动性”的方法，包含具有共性的核心元素，每个都含有独特的角色、过程模式、工作产品和实践。

3. 并列争求scrum  

侧重于项目管理，是迭代式增量软件开发过程，包括了一系列实践和预定义角色的过程骨架。在scrum中使用Product Backlog来管理产品的需求，Product Backlog是一个按照商业价值排序的需求列表。根据Backlog的内容，将整个开发过程分为若干个短的迭代周期（sprint）。在spring中，scrum团队从Product Backlog中挑选最高优先级的需求组成Spring backlog。在每个迭代结束时，scrum团队将递交潜在可交付的产品增量。当所有spring结束时，提交最终的软件产品。

角色

1. 产品负责人- product owner职责：把方向 — 做正确的事

PO是利益相关方的代表，从业务角度出发，对需求按权重排序，合理调整产品功能和迭代顺序。

2. scrum主管 - scrum master 职责：找方法 — 正确的做事

SM负责提高团队效率，确保所有的障碍backlog中的问题都已分配并可以得到解决，开发思想得到利益相关方的理解和支持，让利益相关方获得最大化的投资回报。

3. 开发团队：职责：执行 — 把事情做正确

尽一切可能去完成任务，发布产品，充分理解PO的产品愿景，合作完成冲刺中的每一个目标，更好的支持可能需要进一步开发的产品发布。

工件

1. product backlog：按照商业价值排序的需求列表。

2. spring backlog：从Product Backlog中挑选最高优先级的需求。

3. 产品增量 increment：每个迭代结束时交付给客户的内容。

4. 燃尽图：显示当前冲刺中未完成的任务数目，描述随着时间的推移而剩余的工作量，可用于表示工作进展。

活动

每个迭代召开“四会”：计划会、站立会、评审会、回顾会。

1. 冲刺计划会：在每个冲刺之初，由PO讲解需求 

2. 每日站立会：每天进行沟通的内部短会。

会议由SM主持，团队成员把注意力集中在回答关键问题上，把已完成的任务从"处理中"状态转为"已完成"。会议结果：更新后的燃尽图、障碍backlog、冲刺backlog。

3. 冲刺评审会：在冲刺结束前给PO演示并接受评价的会议。

开发进度通过实际已完成的产品的功能审核来进行控制。开发团队演示这个spring中完成的功能，由PO断定实际所发布的功能是否与既定的spring目标一致。会议结果：对当前冲刺的结果和整个产品的开发状态达成共识。

4. 冲刺回顾会：在冲刺结束后召开的关于持续演进的会议。

分析冲刺的成功经验、所遇到的障碍、改进目标。

4. 特性驱动开发方法FDD  

是一个迭代的开发模型，FDD认为有效的软件开发需要3个要素：人、过程、技术。6种关键的项目角色：项目经理、首席架构设计师、开发经理、主程序员、程序员、领域专家。

5个核心过程

• 开发整体对象模型

• 构造特征列表

• 计划特征开发

• 特征设计

• 特征构建

三

统一过程模型 RUP

RUP描述了如何有效的利用商业的、可靠的方法开发和部署软件，是一种重量级过程。RUP类似一个在线指导者，它可以为所有方面和层次的程序开发提供指导方针、模板以及事例支持。RUP软件开发生命周期是一个二维的软件开发模型，有9个核心工作流。

9个核心工作流

1. 业务建模

理解待开发系统所在的机构及其商业运作，评估待开发系统对所在机构的影响。

2. 需求

定义系统功能及用户界面，使客户知道系统的功能，使开发人员理解系统的需求，为项目预算及计划提供基础。

3.分析与设计

把需求分析的结果转化为分析与设计模型。

4. 实现

把设计模型转化为实现结果，对开发的代码做单元测试，将不同的模块集成为可执行系统。

5. 测试

检查各个子系统之间的交互、集成，验证所有需求是否被正确实现，对发现的软件质量上的缺陷进行归档，对软件质量提出改进建议。

6. 部署

打包、分发、安装软件，培训用户，提供技术支持。

7. 配置和变更管理

跟踪并维护系统开发过程中产生的所有制品的完整性和一致性。

8. 项目管理

为软件开发项目提供计划、人员分配、执行、监控等方面的指导，为风险管理提供框架。

9. 环境

提供软件开发环境，提供过程管理和工具支持。

RUP生命周期的4个阶段

1. 初始：定义最终产品视图和业务模型，确定系统范围。

2. 细化：设计及确定系统的体系结构，制订工作计划及资源要求。

3. 构建：构造产品，继续演进需求、体系结构、计划直至产品提交。

4. 移交：把产品提交给用户使用。

核心概念

• 角色：描述人或小组的行为与职责。who

• 活动：有明确目的的独立工作单元。how

• 制品：是活动生产、创建、修改的一段信息。what

• 工作流：描述了一个有意义的连续的活动序列，每个工作流产生一些有价值的产品，并显示了角色之间的关系。when

RUP的特点

1. 用例驱动

2. 以体系结构为中心：软件的体系结构是一个多维的结构。

3. 迭代与增量

RUP采用“4+1”视图模型来描述软件系统的体系结构。

1. 用例视图：分析人员和测试人员关注系统的行为，描述系统的功能需求。

2. 逻辑视图：最终用户关注系统的功能，描述系统的静态结构。

3. 进程视图：系统集成人员关注并发和同步特征，描述线程间的并发和同步。

4. 实现视图：程序员关注模块之间的依赖关系, 描述系统代码构件组织和模块。

5. 物理视图：系统工程师关注系统的部署、安装。定义软件到硬件的映射。

四

能力成熟度模型

能力成熟度模型CMM

• 初始级：杂乱无章，没有明确定义的步骤。

• 可重复级：基本的项目管理过程和实践，可跟踪，必要的过程准则。

• 已定义级：软件过程已经文档化、标准化、标准软件过程。

• 已管理级：详细度量标准、对软件过程和产品质量有定量的理解和控制。

• 优化级：不断持续改进。

能力成熟度模型集成CMMI

1. 初始级

过程通常是随意且混乱的。

2. 已管理级

确保策划、文档化、执行、监督、控制项目级的过程。

为过程建立明确的目标，能实现成本、进度、质量目标。

3. 已定义级

企业能够根据自身的特殊情况定义适合企业和项目的标准流程，将这套管理体系与流程予以制度化，同时企业开始进行项目积累，企业资产的收集。

4. 量化管理级

建立了产品质量、服务质量、过程性能的定量目标，对过程性能的可预测。

5. 优化级

通过增量式、创新式的过程与技术改进，不断改进过程性能。

3

需求工程

软件需求的3个不同层次

• 业务需求：客户对系统高层次的目标要求。

• 用户需求：用户要求系统必须能完成的任务。

• 功能需求：开发人员必须实现的软件功能。

需求工程的活动主要被划分为5个阶段

1. 需求获取

2. 需求分析

3. 形成需求规格（需求文档化）

4. 需求确认与验证

5. 需求管理

需求开发

1. 需求获取

2. 需求分析

3. 需求定义：需求规格说明书，严格定义 or 原型方法

4. 需求确认与验证：需求评审 + 需求测试

需求管理

1. 变更控制

2. 版本控制

3. 需求跟踪

4. 需求状态跟踪

需求获取的基本步骤

1. 开发高层的业务模型

2. 定义项目范围和高层需求：描述系统的边界

3. 识别用户角色和用户代表

4. 获取具体的需求

5. 确定目标系统的业务工作流

6. 需求整理与总结

需求获取方法

• 用户面谈

• 需求专题讨论会

• 问卷调查

• 现场观察

• 原型化方法

• 头脑风暴法

需求管理的主要活动

1. 变更控制

2. 版本控制

3. 需求跟踪

4. 需求状态跟踪

变更控制过程

1. 问题分析和变更描述

2. 变更分析和成本计算

3. 变更实现

变更策略

1. 必须遵循变更控制过程。

2. 由变更控制委员会CCB决定。

3. 绝不能删除或修改原始文档。

4. 未获得批准的变更不允许设计和实现。

5. 项目风险承担者应该了解变更的内容。

6. 变更保持水平可追踪性。

需求跟踪

1. 正向跟踪：检查《需求规格说明书》中的每个需求是否都能在后继工作成功中找到对应点。

2. 逆向跟踪：检查设计文档、代码、测试用例等工作成功是否都能在《需求规格说明书》中找到出处。

需求跟踪矩阵：保存了需求与后继工作成果的对应关系。

4

系统分析与设计

一. 结构化方法  

面向功能、面向数据流。

1

 结构化分析 SA

分析的步骤

1. 分析业务情况，做出反映当前物理模型的数据流图DFD。

2. 推导出等价的逻辑模型的DFD。

3. 设计新的逻辑系统，生成数据字典和基元描述。

4. 建立人机接口，提出可供选择的目标系统物理模型的DFD。

5. 确定各种方案的成本和风险等级，据此对各种方案进行分析。

6. 选择一种方案。

7. 建立完整的需求规约。

分析的结果

1. 功能模型：数据流图DFD，描述系统的功能需求（过程建模 / 功能建模）。

2. 行为模型：状态转换图STD，描述系统的状态和引起状态转换的事件和条件。

3. 数据模型：实体联系图E-R，描述系统中各个实体之间的关系。

4. 数据字典：对DFD中的各个元素做出详细的定义和说明。

数据流图DFD 

功能建模、过程建模。

核心：数据流

目的：描述系统的功能需求

DFD的4种基本元素

1. 数据流：描述数据的流向。

2. 加工：表示对数据进行的加工/处理和转换。

3. 数据存储：表示用数据库形式存储的数据。

4. 外部实体：描述系统数据的提供者、或数据的使用者。

DFD的建模过程

1. 明确目标，确定系统范围。

2. 建立顶层DFD图。

3. 构建第一层DFD分解图。

4. 开发DFD层次结构图。

5. 检查确认DFD图。

数据流图DFD的作用

1. 从数据传递和加工的角度，利用图形符号，通过逐层细分，描述系统内各个部件的功能、数据在各功能模块之间传递的情况，是需求分析的手段。

2. 描述系统的功能需求，为系统建立功能模型，是结构化分析方法中理解和表达用户需求的重要工具。

3. DFD概括描述了系统的内部逻辑过程，是需求分析结果的表达工具。

4. DFD作为一个存档的文字材料，是进一步修改和充实开发计划的依据。

5. DFD的顶层图定义了系统与外部实体间的界限和接口，清晰界定出系统的范围。

数据流图DFD中的常见错误

错误1：黑洞 --- 加工只有输入，没输出。

错误2：奇迹 --- 加工只有输出，没有输入。

错误3：灰洞 --- 加工的输入不足以产生输出，两者不对称。

错误4：加工没有编号。

错误5：数据的流向没有经过加工。数据流的流向必须经过加工。

错误6：数据流没有方向箭头。

错误7：数据流没有名称。

数据字典DD 

数据字典：是系统中使用的所有数据元素定义的集合，目的是对DFD中出现的所有元素都加以定义和详细说明，使得每个图形元素的名字都有一个确切的解释。

数据字典的组成

1. 数据项

2. 数据结构

3. 数据流

4. 数据存储

5. 处理过程

数据字典的作用

1. 按各种要求列表，列出所有数据条目，保证系统设计时不会遗漏。

2. 互相参照，便于系统修改。

3. 由描述内容检索名称。

4. 一致性检验和完整性检验。

2

  结构化设计 SD

SD是面向数据流的设计方法，以SRS和SA阶段所产生的数据流图和数据字典等文档为基础，是一个自顶向下、逐步求精、模块化的过程。

SD方法的基本思想是将软件设计成由相对独立且具有单一功能的模块组成的结构。

概要设计：主要任务是确定软件系统的结构，对系统进行模块划分，确定每个模块的功能、接口、模块之间的调用关系，形成系统结构图SC。

详细设计：主要任务是为每个模块设计实现的细节，每个模块的实现算法、所需的局部数据结构。

信息隐藏与抽象：采用封装技术，将模块的实现细节隐藏起来。

模块化：功能--做什么，逻辑--怎么做，状态--使用的环境和条件。

模块的外部特性：模块名、参数表、影响。

模块的内部特性：完成其功能的代码、仅供模块内部使用的数据。

• 非直接耦合

• 数据耦合：传递简单数据。

• 标记耦合：传递记录等复杂信息、数据结构。

• 控制耦合：传递的信息中包含用于控制模块内部逻辑的信息。

• 通信耦合：共享了输入或输出。

• 公共耦合：公共的数据环境，全局数据结构。

• 内容耦合：一个模块直接访问另一个模块的内部数据。

• 功能内聚：完成一个单一功能，各个部分协同工作，缺一不可。

• 顺序内聚：必须顺序执行。

• 通信内聚：所有处理元素集中在一个数据结构的区域上。

• 过程内聚：必须按特定的次序执行。

• 时间内聚：必须在同一时间间隔内执行。

• 逻辑内聚：完成逻辑上相关的一组任务。

• 偶然内聚

系统结构图SC：模块结构图，反映了系统的总体结构，各模块之间的层次结构。

详细设计的基本步骤

1. 分析并确定输入/输出数据的逻辑结构。

2. 找出输入数据结构和输出数据结构中有对应关系的数据单元。

3. 按一定的规则由输入、输出的数据结构导出程序结构。

4. 列出基本操作与条件，并把它们分配到程序结构图的适当位置。

5. 用伪码写出程序。

详细设计的工具

1. 图形工具：业务流图、程序流程图、PAD图、NS盒图、IPO图。

流程图：只能描述执行过程，不能描述有关的数据。

PAD图：问题分析图，既表示逻辑，也描述数据结构，支持自顶向下的过程，可自动转化成高级语言程序，更直观，结构更清晰。

NS盒图：功能域明确，容易表示嵌套和层次关系，具有强烈的结构化特征，不能任意转移控制，不适合复杂程序设计。

2. 表格工具：一张表描述过程的细节。

3. 语言工具：PDL伪代码，描述模块内部的具体算法，可作为注释直接插在源码中，也可由PDL自动生成代码。

3

  结构化编程 SP

结构化程序设计采用自顶向下、逐步求精的方法。

各个模块通过“循序、选择、循环”的控制结构进行连接，并且只有一个入口和一个出口。

程序 = 算法 + 数据结构

二. 面向对象方法  

面向对象方法是以用例驱动、以体系结构为中心、迭代的、渐增式的开发过程。

1

 面向对象分析 OOA

OOA模型的5个层次

1. 主题层

2. 对象类层

3. 结构层

4. 属性层

5. 服务层

OOA的5个活动

1. 标识对象类

2. 标识结构

3. 定义主题

4. 定义属性

5. 定义服务

对象之间的2种结构

1. 分类结构：一般 与 特殊

2. 组装结构：整体 与 部分

OOA的基本原则

1. 抽象：抽取共同的、本质的特征，过程抽象 + 数据抽象。

2. 封装：把对象的 属性(数据) 和 操作(服务) 结合为一个不可分的系统单位，隐蔽对象的内部细节。

3. 继承：特殊类对一般类的继承，不再重复定义一般类中已定义的属性和方法。

4. 分类：把具有相同属性和服务的对象划分为一类，用类作为这些对象的抽象描述。

5. 聚合：多个对象的组装。

6. 关联

7. 消息通信：对象之间只能通过消息进行通信。

8. 粒度控制

9. 行为分析

分析的步骤

1. 确定对象和类：类是多个对象的共同属性和方法的集合。

2. 确定结构：分类结构：泛化-特化、组装结构：整体-部分。

3. 确定主题：指事物的总体概貌、总体分析模型。

4. 确定属性：数据元素，描述对象或分类结构的实例。

5. 确定方法：收到消息后必须进行的一些处理方法。

分析的结果

1. 用例模型：从用户视角分析需求，描述系统的功能需求。

2. 分析模型

静态分析模型：描述系统的基本逻辑结构，展示对象和类如何组成系统。

动态分析模型：描述系统的动态行为，展示对象在系统运行期间不同时刻的通信和交互。

用例建模的步骤

1. 识别参与者

2. 合并需求获得用例

3. 细化用例描述

4. 调整用例模型

建立分析模型的步骤

1. 定义概念类

2. 确定类之间的关系

3. 为类添加职责：类的职责分解为类的属性和方法，属性封装数据，方法封装行为。

4. 建立交互图

图的对比

数据流图：强调系统内数据的流动，描述系统的功能需求，面向数据流。

流程图：面向过程。强调处理过程，各处理过程之间有严格的顺序和时间关系，只能表示顺序执行的过程，不能描述有关的数据.

交互图

1. 顺序图（序列图）

顺序图通常能更精确的描述对象间特定交互过程的详细步骤，着重展现对象之间按时间顺序进行的消息交互，以及这些消息之间的时序关系，强调交互的消息的顺序和时序。

2. 协作图（通信图）

协作图通常表示较高层次的概览性视图，通过对象之间的集合和连接来描述多个对象在一定场景下的交互和协作关系，强调接收和发送消息的对象的结构组织，着重展现对象之间的协作和通信方式。

3. 定时图（计时图）

强调消息的实际时间。

4. 交互概览图

动态图

1. 活动图

描述用例和对象内部的工作过程，用于捕获动作及动作的结果，是内部处理驱动的流程。可以将一个活动图中的活动进行分组，每个活动都明确属于一个泳道，每一组表示一个特定的对象，负责完成组内的活动。

强调活动间的顺序和控制流，能够表示并发活动的情形。

适用于系统行为建模，关注活动的并发和同步，侧重从行为的动作来描述。

活动图是状态图的一种特殊形式。

2. 状态图

描述一个对象在生命周期内响应事件所经历的状态序列。

状态间的转移需要外部事件的触发且满足指定的条件。

适合用于反应式系统建模，关注对象的状态变化，侧重从行为的结果来描述。

2

 面向对象设计 OOD

分析模型：顶层架构图、用例与用例图、领域概念模型

设计模型：以包图表示的架构图、以交互图表示的用例实现图、完整精确的类图、描述复杂对象的状态图、描述流程化处理过程的活动图。

在OOD中，类分为3种类型

1. 实体类

映射需求中的每个实体，保存需要存储在永久存储体中的信息。

2. 控制类

用于控制用例工作的类，对一个或几个用例所特有的控制行为进行建模。

3. 边界类

用于封装在用例内、外流动的信息或数据流，位于系统与外界的交界处。

3

 面向对象编程 OOP

OOP达到了软件工程的3个主要目标：重用性、灵活性、扩展性。

OOP = 对象 + 类 + 继承 + 多态 + 消息

OOP的基本特点：封装、继承、多态

4

 数据持久化

在面向对象开发方法中，对象只能存在于内存中。

对象持久化：把内存中的对象保存到数据库 或 可永久保存的存储设备中。

持久层：实现了数据处理层内部的业务逻辑和数据逻辑的解耦。

对象/关系映射ORM：将对象持久化到关系数据库中。

5

软件测试

测试方法

1. 静态测试：代码走查、代码审查、桌前检查。

2. 动态测试：运行被测程序。

3. 黑盒测试：对功能和界面进行测试，不考虑代码结构。（等价类划分、边界值划分、错误推测、因果图）

4. 白盒测试：从程序结构方面对代码逻辑进行测试。（语句覆盖、判定覆盖、条件覆盖、路径覆盖）

5. 灰盒测试：在内部结果出错，但输出结果正确的情况下用该方法测试。

6. 自动化测试：在预先设定的条件下，自动运行被测程序。

测试阶段

1. 单元测试：对软件的模块进行测试，测试依据 -- 详细设计说明书。

2. 集成测试：对已经组装起来的模块同时进行测试，检查模块结构组装的正确性，发现与接口有关的问题，测试依据 --- 概要设计说明书。

3. 系统测试：采用黑盒测试，检查该系统是否符合软件需求。

• 功能测试、用户界面测试、健壮性测试、可靠性及安全性测试

• 性能测试：模拟多种正常、峰值、异常负载条件，对各项性能指标测试。

• 负载测试：测试当负载逐渐增加时，系统各项性能指标的变化情况。

• 压力测试：通过确定系统的瓶颈，来获得系统能提供的最大服务级别。

4. 验收测试：用户对要交付的软件进行测试，验证是否满足SRS和签订的合同中的各项要求。

• Alpha测试：用户在开发环境下测试。

• Beta测试：用户在实际使用环境中测试。

5. 回归测试：测试变更部分的正确性，以及不影响软件原有的功能。

6

净室软件工程

净室软件工程CSE：在软件开发过程中，强调在软件中建立正确性的需要。

是一种应用数学与统计学理论，以经济的方式生产高质量软件的工程技术，力图通过严格的工程化的软件过程，达到开发中的零缺陷或接近零缺陷。

净室软件工程是一种形式化方法，使用盒结构规约进行分析和设计建模，强调将正确性验证作为发现和消除错误的主要机制。

CSE要求在规约和设计中消除错误，强调在软件中建立正确性的需要，降低软件开发中的风险，以合理的成本开发出高质量的软件。

理论基础

1. 函数理论：完备性、一致性、正确性。

2. 抽样理论：对样本进行测试。

技术手段

1. 统计过程控制下的增量式开发

增量开发、控制迭代。

2. 基于函数的规范与设计

盒子结构方法的3种抽象层次

(1) 行为视图：外部行为，黑盒。

(2) 状态机视图：状态盒。

(3) 过程视图：明盒。

盒子结构是基于对象的，满足信息隐藏、实现分离。

3. 正确性验证

CSE的核心

4. 统计测试和软件认证

净室测试方法，采用统计学的基本原理，抽样统计，测试用例是总体的一个随机样本。

缺点

1. 太理论化，需要更多的数学知识，正确性验证的步骤比较困难且比较耗时。

2. 不进行传统的模块测试，这不现实。

3. 带有传统软件工程的一些弊端。

7

基于构件的软件工程

基于构件的软件工程CBSE：是一种基于分布对象技术、强调通过可复用构件设计与构造软件系统的软件复用途径。基于已有构件的组装，更快的构造系统。

构件：又称组件，是一个独立可交付的功能单元，向外提供统一的访问接口，构件外部只能通过接口来访问构件。

构件由一组通常需要同时部署的原子构件组成。

原子构件是部署、版本控制和替换的基本单位，大多数原子构件永远都不会被单独部署，尽管它们可以被单独部署。

大多数原子构件都属于一个构件家族，一次部署往往涉及整个家族。

1. 对象：一个实例单元，封装了自己的状态和行为。

2. 模块：不带单独资源的原子构件。

3. 构件：一个原子构件 = 一个模块 + 一组资源，构件由多个原子构件组成。

4. 服务

构件的特性

1. 自包容、可重用。

2. 独立部署单元。

3. 没有外部的可见状态。

4. 作为第三方的组装单元。

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

对象的特性

1. 一个实例单元，具有唯一的标志。

2. 可能具有状态，此状态外部可见。

3. 封装了自己的状态和行为。

构件模型：接口、使用信息、部署。

面向构件的编程COP

面向构件的编程需要下列基本的支持：

1. 多态性：可替代性。

2. 模块封装性：高层次信息的隐藏。

3. 后期的绑定和装载：部署独立性。

4. 安全性：类型和模块安全性。

构件的组装模型

1. 设计构件组装

将系统划分成一组构件的集合，明确构件之间的关系。

2. 建立构件库

在确定了系统构件后，开发软件构件、重用已有的构件、选用第三方的构件。

构件之间通过接口相互协作。

3. 构建应用软件

构件组装。

4. 测试与发布

构件组装模型的优点

1. 系统可扩展性良好：构件的自包容使得系统更容易扩展。

2. 降低软件开发成本：重用已有的构件。

3. 更加灵活：构件的粒度小，可独立开发。

构件组装模型的缺点

1. 构件设计不好会降低构件组装模型的重用度。

2. 考虑重用度时，可能会对性能等其它方面做出让步。

3. 增加了学习成本。

4. 第三方构件库的质量难以控制。

商用构件的标准规范

1. EJB

在J2EE中，EJB是中间层（业务逻辑层）的中间件技术，与JavaBeans不同，它提供了事务处理的能力。

会话Bean：维护会话

实体Bean：处理事务

消息驱动Bean

2. COM、DCOM、COM+

COM：构件对象模型component object model

DCOM：分布式构件对象模型。

主要适合windows平台。

3. CORBA

公共对象请求代理架构，主要分为3个层次：

(1) 对象请求代理 ORB

最底层，规定了分布对象的定义（接口）和语言映射，实现对象间的通信和互操作，是分布对象系统中的"软总线"。

(2) 公共对象服务

在ORB上定义了很多公共服务，可以提供诸如并发服务、名字服务、事务(交易)服务、安全服务等。

(3) 公共设施

最上层，定义了构件框架，提供可直接为业务对象使用的服务，规定业务对象有效协作所需的协定规则。

8

中间件

中间件：是一类软件，在一个分布式系统环境中，处于操作系统和应用程序之间，提供应用软件与各种操作系统之间使用的标准化编程接口和协议，起到承上启下的作用，使应用软件的开发独立于计算机硬件和操作系统，并能在不同的系统上运行。

中间件分类

1. 通信处理中间件（消息中间件）

实现分布式系统中可靠的、高效的、实时的跨平台数据传输，可靠的消息传递机制，保证系统能在不同平台之间通信。kafka、RocketMQ。

2. 事务处理中间件（交易中间件）

在分布式事务处理系统中，大量事务在多台服务器上实时并发运行，每项事务需要多台服务器上的程序按顺序协调完成。

Seata 是一款开源的分布式事务解决方案，包括 AT、TCC、Saga 和 XA 事务模式，可支持多种编程语言和数据存储方案。

3. 数据存取管理中间件

在分布式系统中，数据服务器中的数据可以是关系型的、复合文档型、各种格式的多媒体型，或者是经过加密、压缩存放的，数据存取管理中间件的作用是便于在网络上虚拟缓冲存取、格式转换、解压。通过一个抽象层访问数据库，从而允许使用相同或相似的代码访问不同的数据库资源，例如JDBC。

4. web服务器中间件

在web应用程序和服务器之间，用于处理http请求和响应，实现负载均衡。

nginx--反向代理服务器，将客户端请求分发到多个后端服务器上，实现负载均衡，支持多种负载均衡算法。快速、高效的提供静态内容，如html、css、image等。

Tomcat--Java servlet容器，用于运行Java web应用程序。

5. 安全中间件

防火墙、加密、认证。

6. 跨平台和架构的中间件

架构中间件用于在分布式系统中，集成各结点上的不同系统平台上的构件。

CORBA：可以跨任意平台，但过于庞大。

JavaBeans：灵活简单，适合用于浏览器，但运行效率有待改善。

COM+：主要适合windows平台。

7. 专用平台中间件

为特定应用领域设计领域参考模型，建立相应架构，配置相应的构件库和中间件。

8. 网络中间件

网管、接入、网络测试、虚拟社区、虚拟缓冲。

分布式事务模式

1. XA模式

2. TCC模式

3. Saga模式

4. AT模式

5. 基于本地消息的模式

9

逆向工程

逆向工程

4个级别	包括	完备性	抽象级别
实现级	抽象语法树 符号表 过程的设计表示	高	低
结构级	结构图 调用图 程序 数据结构	-	-
功能级	数据 控制流模型	-	-
领域级	E-R模型	低	高

1. 逆向工程

在比源代码更高抽象层次上建立程序的表示过程。

2. 重构

同一抽象级别上，转换系统描述形式。

3. 设计恢复

从已有程序中抽象出设计。

4. 再工程

在逆向工程所获得信息的基础上，修改或重构已有系统，产生系统的一个新版本，是对现有系统的重新开发过程。

再工程 = 逆向工程 -> 新需求的考虑 ->正向工程

5. 正向工程

恢复设计信息，使用该信息修改或重构已有系统。