架构设计部分（必考！！）

13.1构件技术

从需求分析到软件设计之间的过度过程称为软件架构。将满足需求的职责分配到组件上。

软件架构为软件系统提供了一个接口、行为和属性的高级抽象，由构件的描述、构件的相互作用（连接件）、指导构件集成的模式以及这些模式的约束组成，不仅指定了系统的组织结构和拓补结构，并且显示了系统需求和构件之间的关系。解决好软件的复用、质量和维护问题，是研究架构的根本目的。

活动：提出架构模型、产生架构设计、进行设计评审，是一个迭代的过程。

架构设计主要关注软件组件的结构、属性和交互作用，并通过多种视图全面描述特定系统的架构;

软件架构能够在设计变更较容易的阶段，考虑系统结构的可选方案，便于技术人员与非技术人员就软件设计进交互，能够展现软件的结构、属性与内部交互关系

软件架构是项目干系人交流的手段，软件架构是可传递和可复用的模型，通过研究软件架构可能预测软件的质量

架构设计在各阶段的作用：

1. 需求阶段：需求分析是问题空间、架构设计SA是解空间。关注：如何根据需求模型构建SA模型。如何保证模型转化的可追踪性
2. 设计阶段：SA研究关注最早最多的阶段。主要活动：SA模型描述、SA模型的设计与分析、SA设计经验的总结与复用
3. 实现阶段：研究基于SA的开发过程支持、从SA向实现过度的途径、基于SA的测试技术
4. 构建组装阶段：在SA指导下，可复用构建的组装可以在较高层次上实现，提高实现效率；SA设计模型起到系统蓝图作用

主要作用包括：（1）如何支持可复用构建的互联。（2）在组装过程中如何检测并消除体系结构失配问题

1. 部署阶段：提供高层次体系结构视图来描述部署阶段的软硬件模型。基于SA模型可分析部署方案的质量属性
2. 后开发阶段：围绕维护、演化、复用方面进行。典型研究方向：

1. 动态软件体系结构：体系结构在运行是发生改变。变化包括两类：1.内部执行导致、2.外部请求对软件的重配置；包括两个部分的研究设计阶段支持、运行时刻基础设施的支持
2. 体结构恢复与重建：现有系统没有SA的情况，从这些系统中恢复和重构

构件是一个独立可交付的功能单元，外界通过接口访问提供的服务。由一组通常需要同时部署的原子构件组成，一个原子构件由模块和一组资源组成

模块是不带资源的原子构件，是一组类和可能的非面向对象结构体（过程、函数）;构件提供的两种服务：平台服务和支持服务

构件：独立部署单元、作为第三方的组装单元、没有外部可件的属性

对象：一个实例单元,具有唯一标志、可能具有状态（外部可见）、封装了自己的状态和行为

一个构件可以包含多个类元素、一个类元素只能属于一个构件;

构件特性：自包容、可重用；构件组装模型：架构设计组装、建立构件库、构建应用软件、测试与发布

构件接口：接口标准化是对接口中消息的格式、模式和协议的标准化，关注输入输出的消息标准化

面向构件编程（COP）关注于如何支持建立面向构件的解决方案;

构建技术：利用某种编程手段将人们所关心又不便于让最终用户直接操作的细节进行封装，同时对各种业务逻辑规则进行了实现。

三大流派：

1、J2EE：包括Servlet、EJB（会话Bean、实体Bean、消息驱动Bean）

2、COM、DCOM、COM+：

3、CORBA标准：(公共对象请求代理架构)，三个层次

1. 对象请求代理ORB（最底层，对象间的通讯和互操作，分布式对象系统中的软总线）、
2. 公共对象服务（提供如并发服务、事务服务、安全服务等）
3. 公共设施（最上层，定义了组件框架，可直接为业务对象使用的服务、规定业务对象有效协作所需的协定规则）

CORBA定义了四种构件标准：实体（需要长期持久化，用于事务性行为）、加工（需要持久化但没有客户端）、会话（不需要持久化）、服务（构建无状态）

CCM构件模型式OMG组织指定的规范，三项内容：抽象构建模型（构件互操作）、构件容器结构（构建运行和管理，集成）、构件配置和打包规范

IDL是一种接口定义语言，具体的定义会涉及接口以及相关部分。文件包含的主要元素有：接口描述（核心）、模块定义（映射为包）、类型定义、常量定义、异常、值类型。接口描述是IDL文件中最核心的内容。

13.2架构风格

架构风格是描述某一特定应用领域内系统组织方式的惯用模式，架构设计的核心问题是能否达到架构级的软件复用

架构领域反应了领域中系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效的组织成一个完整的系统。

架构风格定义了一个系统家族，即一个架构定义、一个词汇表和一组约束；架构风格定义了用于描述系统术语表和一组指导构建系统的规则

词汇表：包含一些构件和连接件类型；约束：指系统如何将这些构件和连接件组合起来。

数据流	传统编译器，按照顺序从前往后执行	批处理风格	一个接一个，以整体为单位
		管道过滤器	前一个的输出是后一个输入（过滤器是构件、连接件是管道）; 扩展性好、交互性差
调用返回风格	构件之间存在调用关系	主/子程序（显式）	单线程控制，主程序调用子程序（主子程序是构件、调用是连接件）
		面向对象	通过对象调用封装的方法和属性（构件是对象，连接件是对象间的交互），
		层次结构	将整个系统按照抽象层次的不同分为多层，每个层次的程序只需要负责与相邻的上下两层打交道
独立构件风格	构件之间相互独立，不存在调用关系而是通过事件触发； 为软件复用提供了强大支持，为构件维护、演化带来了方便，缺点是构件放弃了对系统计算的控制	事件驱动 （隐式调用）	事件触发推动动作。构件注册到事件中，当事件发生时，所有注册到该事件的过程会自动触发。构件之间进一步解耦
		进程通信	消息传递的方式可以是点对点、异步或同步、远程过程调用等 构件是独立的进程，连接件是消息传递；
虚拟机风格	创建一套规则，使用者基于这个规则进行开发。自定义流程、按照流程执行，规则随时改变，业务灵活定义； 机器人	解释器	核心是虚拟机（解释引擎、被解释代码的存储区、记录解释器当前工作状态的数据结构）弥合程序语义与硬件语义之间的差异，仿真硬件的执行过程.执行效率低
		基于规则的系统	包含规则集、规则解释器、规则/数据选择器和工作内存； 一般用在人工智能领域和DSS（决策支持）中
仓库风格（数据共享风格）	现代编译器，以数据为中心，所有操作都是围绕建立数据中心进行的	数据库系统	主要两大类：中央共享数据源和多个相对独立的处理单元
		黑板系统	知识源（独立计算的单元，提供解决问题的知识）、黑板（全局数据库，是知识元相互作用的唯一媒介，知识源响应通过黑板状态变化控制）、控制三部分； 应用在对解决问题没有确定性算法的软件中（信号处理、问题规划）
		超文本	以网状链接方式相互链接
C2风格	通过连接件绑定一起，按照一组规则运行并构件网络		构件连接件都有顶部和底部，构件和构件之间不能直接连接

风格名称	特点	优点	缺点	适合系统
管道过滤器风格	过滤器相对独立	可扩展性强。可维护性高 模块独立性高，模块复用，具有并发性	不适合交互性强的应用，对存在关系的数据流必须进行协调	适合系统可划分清晰模块。模块间相对独立，有清晰模块接口
面向对象	力争实现问题空间和软件系统空间结构一致	可扩展性强。易维护， 高度模块性，实行封装，代码共享灵活	增加了对象之间的依赖	多种领域
事件驱动	系统有若干子系统组成，子系统有主次之分，每个子系统都有事件收集和事件处理机制	扩展性好。容易实现并发处理和多任务。适合描写系统组， 有类层次结构简化代码	树形结构，削弱了对系统的控制能力；各个对象逻辑关系复杂	适合一个系统对外表现可以从他对事件的处理表征出来
分层结构风格	各个层次的组件形成不同功能级别的虚拟机，各层组件相互协作，而且实现透明	1、支持软件复用 2、将复杂问题分解为一个增量步骤实现，可扩展性好， 3、支持系统设计过程中的逐级抽象，越底层抽象基本越高，	1、不是所有系统都可以很容易划分为分成模式，不同层次间耦合度高的系统难以实现 2、效率会降低	适合功能层次抽象且相互之间低耦合的系统
数据共享风格	主要两大类：中央共享数据源和多个相对独立的处理单元	以数据为中心， 中央数据单元实现了数据集中	适合特定系统	专家系统、人工智能领域
解释器风格	系统核心是虚拟机，性能低	可以用多种操作解释一个句子，灵活应对自定义语义	适合特定系统	模式匹配系统 语言编辑器
闭环控制风格	采用不断测量被控对象，认识和掌握被控对象	将控制理论引入到计算机软件系统的体系结构中	适合特定系统	该系统一定存在有目标的作用，信息处理闭环处理过程

13.3层次架构风格、SOA

两层CS缺点：开发成本高、客户端设计复杂、用户界面不统一、软件移植困难、软件维护升级困难；

三层CS优点：1、各层逻辑上相对独立，结构更清晰，提高了可维护性可扩展性；2允许灵活有效的选用相应的平台和硬件系统；

3、各层可并行开发； 4、功能层有效的隔离了表示层和数据层，更安全，管理层次更加合理和可控

三层CS架构的关键是各层之间的通信效率；

三层BS架构缺点：缺乏对动态页面的支持能力；安全性难以控制；数据查询响应速度低于CS架构；数据提交以页面为单位，数据的交互性不强

混合架构风格：内部使用CS外部使用BS，查询采用BS修改采用CS；混合架构实现困难，成本高

RIA(小程序)本质还是3层BS架构：结合了CS架构反应速度快、交互性强的优点与BS架构传播范围广及容易传播的优点，

简化了BS架构的用户交互，数据能缓存在客户端，借助高速网速实现必要插件在本地的快速缓存；

MVC架构：控制器Controller：处理用户交互，控制用户输入；模型Model：处理应用程序数据逻辑、存取数据；视图View：处理数据显示

MPV架构：主要的程序逻辑在呈现层Presenter，与具体View没有直接联系，而是通过定义好的接口进行交互，View<=>Presenter<=>Model

MVVM（ViewModel）架构：View<—>ViewModel<=>Model；低耦合、可重用性（逻辑放到ViewModel，使得View可重复用）、独立开发、可测试

SOA(面向服务架构)，粗粒度、松耦合的服务架构，服务之间通过精确定义的接口进行通信，不涉及底层编程接口和通信。

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

SOA不仅是一种开发方法，还具有管理上的优势，管理员可以直接给管理开发人员所构建的相同服务。多个服务通过企业服务总线提出服务请求。

SOA的关键目标是实现企业IT资产重用的最大化，

SOA的主要特征：可以从企业外部访问、随时可用、粗粒度接口、松耦合、精确定义的服务接口、可重用的服务及服务接口管理、标准化的接口（WSDL、SOAP、XML是核心）、支持各种消息模式

与传统构件的区别：粗粒度；接口是标准的，主要是WSDL（传统以API形式）；实现与语言无关；通过构件容器提供QoS（传统由程序代码直接控制）

SOA关键技术：

发现服务：UDDI（web服务注册统一描述、发现、集成）、DISCO

描述服务：WSDL（将Web服务描述定义为一组服务的访问点，用于描述服务）、XML Schema

消息格式层：SOAP（交换XML编码信息的轻量级协议，用于传递信息，为Web服务和服务请求者之间通信提供支持）、REST

编码格式：XML（DOM、SAX）：在WebService中表示数据的基本格式，用于数据交互

传输协议层：HTTP、TCP.IP、SMTP

SOA实现方式：

1. WebService：服务请求者、注册中心、服务提供者
2. 服务注册表：服务注册、服务位置、服务绑定
3. ESB：包括客户端（服务请求者）、基础架构服务（中间件）、核心集成服务（提供服务）。

ESB用来连接各个服务节点，ESB的存在是为了集成不同协议的不同服务、ESB做了消息转化、解释、路由的工作；

ESB的特点1.在面向服务架构中起到总线作用，2.描述元数据和服务注册管理，3.传递数据以及对数据进行转化，4.发现、路由、匹配和选择能力

ESB的功能：服务位置透明、传输协议转化、消息格式转化、消息路由、

BPEL:面向Web服务的业务流程执行语言，是一种使用Web服务定义执行业务流程的语言，使用BPEL可以通过组合、编排和协调Web服务自上而下的实现面向服务体系结构，BPEL提供了一种相对简易方法，可以将Web服务组合到一个新的复合服务（业务流程）中

微服务架构：1没有ESB，分布式架构；2、去中心化；微服务：纵向业务划分、细粒度、独立部署、使用轻量级的通信方式http

微服务架构是一种分布式系统架构，将一个应用程序拆分为一组消小型、独立的服务，每个服务都有特定的业务功能，并通过轻量级的通信机制进行通信

13.4软件架构复用

软件产品线是指一组软件密集型系统，他们共享一个公共的、可管理的特性集，以规定的方式用公共的核心资产集开发出来；

软件架构复用：机会复用、系统复用（在开发之前就要进行规划）

复用的基本过程：构造/获取可复用的软件资产、管理资产（分类、检索）、针对特定需求从资产中选择可复用部分

DSSA（特定领域架构），

用于一类特定类型的任务(领域)的软件构件的集合。是一个特定问题领域中支持一组应用的领域模型、参考需求、参考架构等组成的开发基础，目标就是支持在一个特定领域中多个应用的生成。垂直域：同一个领域的通用软件架构，是一个完整的架构；水平域：不同领域之间相同部分的小工具

基本活动：

领域分析：获取领域模型（领域需求），识别信息源并在 此基础上分析领域系统需求

领域设计：获取领域架构DSSA，DSSA描述在领域模型中表示的需求解决方案，是能适应领域中多个系统的需求的一个高层次的设计。

领域实现：开发和组织可重用信息（从现有系统获取或者新开发）

四种角色：
领域专家：领域中系统有经验的用户、从事该领域中系统需求分析、设计、实现及项目管理有经验的工程师；在领域分析阶段

领域分析人员（系统分析员）、领域设计人员（软件设计人员）、领域实现人员（程序设计人员）

过程：1.定义领域范围；2.定义领域特定的元素（建立数据字典，归纳领域术语）；3.定义领域特定的设计和实现约束；4.定义领域模型和架构；

5.产生和搜集可复用单元。整个过程是并发、递归、反复、螺旋

三层次结构：领域开发环境（领域架构师决定核心架构，产出参考结构、参考需求、架构、领域模型、开发工具）；

领域特定的应用开发环境（应用工程师将核心架构实例化）、应用执行环境（操作员实现实例化的架构）

ABSD（基于架构的软件开发）架构驱动

ABSD是一个自顶向下、递归细化的方法，在最顶层系统被分解为若干个概念子系统和一个或多个软件模板；强调由业务、质量、功能需求的组合驱动架构设计；

采用视角和视图（4+1）来描述软件架构，采用用例（功能需求）和质量属性场景(质量需求)来描述需求；需求来自系统的质量目标、系统的业务目标、和系统开发人员的业务目标。

特点：采用ABSD设计活动可以从项目总体功能框架明确就开始，这意味着需求获取分析还没有完成就可以进行软件设计

ABSD方法的三个基础：1、功能分解（基于模块的内聚和耦合）；2、通过选择架构风格来实现质量和业务需求；3、软件模板的使用

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

1.架构需求（需求获取、标识构件【生成类图、对类分组、把类打包成构件】、需求评审）、

2.架构设计（将需求阶段的标识构件映射成构件；提出架构模型、映射构件、分析构件相互作用、产生架构、设计评审）、

3.架构文档化（架构规格说明、架构需求质量设计说明书）、4.架构复审（外部人员）、5.架构实现（用实体显示架构，实现构件、组装系统）、6.架构演化

13.5质量属性、架构评估

软件质量属性：分为开发期质量属性和运行期质量属性

性能	系统响应能力，经过多长时间才能对某个事件做出响应，或者在某个时间段内系统能处理的事件个数	优先级队列、采用资源调度、增加资源、引入并发
可靠性	在意外或者错误使用的情况下，维持软件系统功能特性的基本能力，如MTTF\MTBF\MTTR	心跳、Ping/Echo、冗余、选举
可用性（优先）	能够正常运行的时间比例，如故障时间间隔	心跳、Ping/Echo、冗余、选举
安全性	向合法用户提供服务，同时阻止非授权用户使用，如保密、完整、不可抵赖、可控	入侵检测、用户认证、用户授权、追踪审计
可修改性	以较高性价比对系统进行变更	接口-实现分离、抽象、信息隐藏
功能	系统能完成所期望工作的能力
可变性	体系机构扩充或变更为新体系结构的能力
互操作性	与其他系统和自身环境相互作用

质量属性场景是一种面向特定质量属性的需求；

六部分组成：刺激源（生成该刺激的实体）、刺激（当该刺激达到系统时需要考虑的条件）、环境（该刺激在某些条件内发生）、制品（被激励，系统或系统的一部分）、响应（激励到达后采取的行动）、响应度量（响应发生时，能够以某种方式进行度量）

敏感点：指为了实现某种特定的质量属性，一个或多个构件所具有的特点；权衡点：影响多个质量属性的特征，是多个质量属性的敏感点；

风险点：可能引起风险的因素，

架构评估在架构设计之后，系统设计之前，为了评估所采用的架构是否能解决软件系统的需求，但不是单纯的确定是否满足需求

质量属性(开发)：易理解、可扩展（增加新功能）、可重用、可测试性（证明满足需求）、可维护性、可移植性

评估方式	调查问卷或检查表		场景	度量
	调查问卷	检查表
通用性	通用	特定领域	特定系统	通用或特定领域
对架构了解程度	粗略了解	无限制	中等了解	精确了解
实施阶段	早	中	中	中
客观性	主观	主观	较主观	较客观

质量属性(运行)：性能、安全性、可伸缩性（用户数和数据量增加）、可靠性、可用性、鲁棒性（容错性，非正常操作能正常方式终止）

评估方式：

1. 基于调查问卷（检查表）：要求对评估人员对领域熟悉，客观
2. 基于度量：制定一些定量指标来度量架构，对架构熟悉，较客观
3. 基于场景：确定应用领域的功能和软件架构的结构之间的映射，设计用于体现待评估质量属性的场景，分析软件架构对场景的支持程度。要求对领域熟悉也对架构熟悉。

从刺激、环境、响应三个方面进行设计

SAAM：基于场景的质量属性分析方法，用于初始架构评估,非功能质量属性的架构分析方法

输入：问题描述、需求说明、架构描述；

目标是：对描述应程序属性的文档，验证基本的架构假设和原则；

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

架构描述：SAAM用于架构的最后版本，但早于详细设计

方法活动：主要输入是问题描述、需求声明和架构描述。

主要步骤：场景开发、架构描述、单个场景评估、场景交互、总体评估

功能、结构、分配被定义为描述架构的三个方面

ATAM：架构权衡分析法，让架构师明确如何权衡多个质量目标。整个过程强调以属性作为架构评估的核心概念。

ATAM主要分为四个主要活动领域：场景和需求收集、体系结构视图和场景实现、属性模型构造和分析、折中；

质量属性效应树：树根、属性分类、质量属性、质量属性场景；主要针对性能、可用性、安全性、可修改性

ATAM主要阶段：描述和介绍阶段（描述ATAM、描述业务动机、描述架构）、调查和分析阶段（确定架构方法、生成质量属性效应树、分析架构方法）、测试阶段（讨论场景和对场景分级、分析架构方法）、报告阶段（描述评价结果）

CBAM：成本效益法。基于场景的架构评估：SAAM、CBAM、ATAM；从三个方面：环境、刺激、响应

SAEM：将软件架构看作一个最终产品及设计过程的中间产品，从外部质量属性和内部质量属性评估;

SAABNet：用来表达和使用定性知识以辅助架构定性评估，源于人工智能;AHP：对定性问题进行定量分析；

SASAM:对预期架构和实际架构进行映射和比较来静态评估架构

SACMM（Change and Cost）: 软件架构修改的度量；ALRRT（Reliability）：可靠性风险评估；COSMIS+UML:可维护性

中间件，在分布式系统环境中，处于操作系统和应用程序之间的软件，可以在不同的技术之间共享资源，将不同的操作系统、数据库以及若干应用结合成一个有机的协同工作整体；中间件位于客户机/服务器的操作系统之上管理计算机资源和网络通信；

特点：1、是一类软件，2、不仅仅实现互联，还要实现应用之间的互操作；3、基于分布式处理的软件，最突出的特点是网络通信功能

任务：使应用程序的开发变得更容易，通过提供统一的程序抽象，隐藏异构系统和分布式系统下低级别编程的复杂度

主要类别：数据库访问中间件(JDBC)、远程过程调用（RPC）、面向消息中间件(MOM)、分布式对象中间件（对象技术和分布式计算技术）、事务中间件（事务处理监控器TPM，完成事务管理与协调、负载均衡、失效恢复等）

J2EE：采用分布式应用程序模型；四类结构：客户层组件（Html）、Web层组件（JSP或Servlet）、业务层组件（Bean）、信息系统层（数据库）

ADL架构描述语言，形式化语言，说明软件系统的概念架构和对这些概念架构建模提供功能的语言。

ADL主要包括以下组成部分:构件和构件接口，连接件和架构配置;

比较典型的有：架构互换语言ACME、基于组件和连接的架构描述语言UniCon、基于事件的架构描述语言Rapide。

13.6设计模式

架构模式：软件设计中的高层决策，例如CS架构

设计模式：设计模式描述的是我们周围不断发生的问题以及该问题的解决方案的核心；

四要素：模式名称、问题（在何时使用）、解决方案（设计的内容）、效果

创建型设计模式主要是处理创建对象，提供灵活创建对象方法，包含工厂方法（子类决定实例化）、抽象工厂（创建一系列相关或相互依赖的对象）、

构造器(类和构造分离)、单例、原型(Prototype，原型实例，copy)。

结构型设计模式主要是处理类和对象的组合,主要解决如何组织类和对象，【外侨组员代装适】包含适配器（Adapter,接口转化，兼容接口），

桥接（Bridge，抽象和实现分离，可独立变化），组合（Composite，树形结构表示整体-部分层次），装饰（Decorator，动态附加职责），

外观（Facade，定义高层接口，对外统一接口），享元（Flyweight，细粒度对象共享），代理（Proxy，代理控制对象），

行为型设计模式主要描述类和对象的交互行为，解决各类和对象之间如何协作，

责任链（Chain of Responsibility，将接收对象连起来，链中传递请求，减少请求发送者和接收者之间的耦合），

观察者（Observer，定义对象一对多的依赖关系，状态改变时通知、自动更新），

中介者（Mediator，中介对象封装一系列的对象交互，对象不需要显示的相互调用，不直接使用），

访问者（Visitor，作用于对象结构中多个元素的操作，在不改变元素类的前提下定义作用于这些元素的新操作，数据和操作分离），

备忘录（Memento不破坏封装前提下，捕获、保存对象内部状态，可以在以后恢复）、

模板方法（Template，定义算法骨架，将步骤延续到子类，在子类重新定义算法特定步骤）

命令（Command，日志记录、可撤销），策略（Strategy，算法替换），状态（State 状态改变行为，如会员行为），

解释器（Interperter，），迭代器（Iterator顺序访问、不暴露内部）

策略模式：利用组合代替继承，将算法的实现与算法的选择分离出来。降低了程序间的耦合，增强了代码的可扩展性和可维护性

工厂模式：可以有效的解决客户需求变化对设计的影响，设计者无需知道哪个类被实例化，子类会根据具体的情况自己决定实例化哪个类，符合高内聚、低耦合的设计和原则，具有很好的可扩展性

企业信息化的前提是对企业功能的集成，企业信息资源集成管理的核心是对企业的内部外部的信息流，企业系统规划法通过自上而下的是识别企业目标、企业过程和数据，然后对数据分析，自上而下地设计信息系统

数据集成主要有： 数据联邦：指不同应用共同访问一个全局虚拟数据库，通过全局虚拟数据库为不同的应用提供服务

数据复制：将各个数据源的数据复制到同一处数据仓库，像访问普通数据库一样直接访问数据仓库

基于接口的数据集成：不同系统之间利用适配器来实现相互调用已达到集成的目标

MYSQL的主从复制机制：基于SQL的复制（SBR）、基于行的复制（RBR）、混合复制（MBR）

Redis的持久化机制：AOF（aof文件）、RDB（快照）

结构化的图：（分析）：STD、DFD、ER、（设计）N-S图、PAD图、IPO

数据流图和流程图的定义和区别：

数据流图作为一种图形化工具，用来说明业务处理过程、系统边界内所包含的功能和系统中的数据流。

流程图以图形化的方式展示应用程序从数据输入开始到获得输出为止的逻辑过程，描述处理过程的控制流。

两者的区别主要包括：

（1）数据流图中的处理过程可并行；流程图在某个时间点只能处于一个处理过程。

（2）数据流图展现系统的数据流；流程图展现系统的控制流。

（3）数据流图展现全局的处理过程，过程之间遵循不同的计时标准；流程图中处理过程遵循一致的计时标准。

（4）数据流图适用于系统分析中的逻辑建模阶段；流程图适用于系统设计中的物理模阶段。

负载均衡技术：应用层（HTTP重定向、反向代理）；传输层（DNS、NAT）