软考高级系统架构设计师-软件架构设计思维导图模板

软件架构的概念

架构的本质

1、软件架构为软件系统提供了一个结构、行为和属性的高级抽象

2、软件架构风格是特定应用领域的惯用模式，架构定义一个词汇表和一组约束

架构的作用

1、软件架构项目干系人进行交流的手段

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

3、软件架构使推理和控制的更改更加简单，有助于循序渐进的原型设计，可以作为培训的基础

软件架构=软件体系结构（学术界叫法）

软件架构连接起需求分析和软件设计，架构设计就是需求分配，即满足需求的职责分配到组件上。

软件架构设计与生命周期

需求分析阶段

模型转换关注两个问题：如何根据需求模型构件SA模型+模型转换可追溯

设计阶段

SA研究关注得最早和最多的阶段。ADL、4+1视图

实现阶段

编码开发

构件组装阶段

在较高层次上实现系统，高效

部署阶段

SA为部署提供高层次视图指导

后开发阶段

动态软件体系结构、体系结构恢复与重建

架构描述语言ADL

概念

ADL是一种形式化语言（存在于理论体系），他在底层语义模型的支持下，为软件系统的概念体系结构建模提供了具体语法和概念框架

种类

C2SADL【基于组件和消息的软件架构描述语言】

Wright【分布、并发类型的架构描述语言】

ACME【架构互换语言】

UniCon【基于组件和连接的架构描述语言】

Rapide【基于事件的架构描述语言】

其他【Darwin\MetaH\Aesop\Weaves\SADL\xADL】

ADL三个基本元素

构件

计算或数据存储单元

连接件

用于构件之间交互建模的体系结构构造块，及其支配这些交互的规则

架构配置

用于描述体系结构的构件与连接件的连接图

架构“4+1”视图

逻辑视图

最终用户、功能需求

类与对象

实现/开发视图

程序员

配置、装配

进程视图

系统集成人员

性能、可伸缩性、吞吐率、并发

部署/物理视图

系统工程人员

发布、安装、拓扑结构

用例/场景视图

分析测试人员、贯穿所有视图

基于架构的软件开发方法（ABSD）

概念

1、ABSD方法是架构驱动，即强调由业务【商业】、质量和功能需求的组合驱动架构设计

2、ABSD方法有三个基础

一、功能的分解。在功能分解中，ABSD方法使用已有的基于模块的内聚和耦合技术

二、通过选择架构风格来实现质量和业务需求

三、软件模版的使用

3、视角与视图：从不同的视角来检查，所以会有不同的视图

4、用例用来捕获功能需求、特定场景【刺激、环境、响应】用来捕获质量需求

5、ABSD能很好的支持软件重用

6、ABSD方法是一个自顶向下，递归细化的方法，直到能产生软件构件和类

开发过程

架构需求

获取需求

生成类图

对类进行分组

把类打包成构件

需求评审

架构设计

提出架构模型

映射构件

分析构件相互作用

产生架构

设计评审

架构文档化

架构规格说明书

测试架构需求的质量设计说明书

架构复审

又称【架构评估】，目的是标识潜在的风险，及早发现架构设计中的缺陷和错误。

架构实现

复审后的文档化的架构

分析与设计

构件实现

构件组装

系统测试

架构演化

需求变化归类

架构演化计划

构件变动

更新构件的相互作用

构建组装与测试

技术评审

演化后的架构

软件架构风格

概念

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

2、软件架构风格是特定应用领域的惯用模式

五大架构风格

数据流风格

批处理

大量整体数据、无需用户交互

管道-过滤器

流式数据、弱用户交互

调用/返回风格（显示调用）

主程序/子程序

面向过程

面向对象

对象的方法调用

分层架构

层与层之间的方法调用

独立构件风格

进程通信

事件驱动（隐式调用）

虚拟机风格

解释器风格

适用于需要“自定义规则”的场合

组成

程序执行的当前状态

被解释执行的程序（自定义程序）

解释器引擎内部的状态

解释器引擎

规则系统

适用于专家系统、人工智能领域和DSS（决策支持系统）

组成

工作内存

规则集

规则数据选择

规则解释器

以数据为中心（仓库风格）

数据库系统

黑板系统

优点

可更改性和可维护性

可重用的知识源

容错性和健壮性

缺点

测试困难；低效；开发困难；缺少并行机制

不能保证有好的解决方案

难以建立良好的控制策略

特点

在以数据为中心的基础上，使用中心数据触发业务逻辑部件

典型实例

语音识别

模式识别

图像处理

知识推理

超文本系统

*扩展

闭环控制架构（过程控制）

适用于嵌入式系统，用于解决简单闭环控制问题

经典应用

空调温控

定速巡航

C2风格

构件和连接件都有一个顶部和一个底部

构件的顶部要连接到连接件的底部，构件的底部要连接到连接件的顶部。构件之间不允许直连

一个连接件可以和任意数目的其他构件和连接件相连

当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部

MDA【模型驱动架构】

概念

1、来自于形式化开发，以数据建模为基础的开发方法

2、【模型】客观事物的抽象表示。 【模型驱动】使用模型完成软件的分析、设计、构建、部署、维护等开发活动 【架构】构成系统的部件、连接件及其约束的规约

3、MDA起源于分离系统规约和平台实现的思想

4、主要目标【可移植性】【互通性】【可复用性】

核心模型

计算无关模型【CIM】

对某具体行业内一个项目的业务需求及其系统功能需求进行分析。行业共性需求，领域级

平台独立模型【PIM】

具有高抽象层次、独立于任何实现技术的模型。【UML】

平台相关模型【PSM】

为某种特定实现技术量身定做，让你用这种技术中可用的实现构造来描述系统的模型。PIM会变成一个或多个PSM

代码Code

用源代码对系统的描述（规约），每个PSM都将被转换成代码

软件架构复用

概念

1、【软件复用】是一种系统化的软件开发过程，通过识别、分析、分类获取和修改软件实体，以便在不同软件开发过程中重复使用它们

2、软件开发过程中重复使用相同或相似【软件元素的过程】

复用的发展路线

函数库

类库

构件库

服务库

复用的维度

水平复用：不分行业领域，通用

垂直复用：分行业领域，专用

复用类型

机会复用：开发过程中，只有发现有可复用的资产，就对其进行复用

系统复用：开发之前，要进行规划，以决定哪些需要服用

复用范围

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

复用过程

构造可复用资产

可复用资产库

复用这些资产

特定领域软件架构（DSSA）

定义

特定领域软件架构以一个特定问题领域为对象，形成由参考模型、参考需求、参考架构等组成的开发基础架构， 支持一个特定领域中多个应用的生成。

DSSA基本活动和产出物

领域分析

建立领域模型

领域设计

获得DSSA

领域实现

开发和组织可复用信息

DSSA类型

垂直域：相同领域，深入

水平域：不同领域，平移

DSSA参与人员

领域专家

1、有经验的用户、从事该领域中系统的需求分析、设计、实现以及项目管理的有经验的软件工程师等

2、领域专家的主要任务包括提供关于领域中系统的需求规约和实现的知识

领域分析人员

领域分析人员应具有知识工程背景的有经验的系统分析员来担任

领域设计人员

领域设计人员应由有经验的软件设计人员来担任

领域实现人员

领域实现人员应由有经验的程序设计人员来担任

DSSA三层次模型

领域开发环境

领域架构师

领域特定的应用开发环境

应用工程师

应用执行环境

操作员

软件产品线

【核心资源库】+【产品集合】

【核心资源库】为产品构造的基础，领域工程的所有结果的集合

软件质量属性

质量属性【总览、分类不统一】

性能

可靠性

容错

健壮性

可用性

安全性

可修改性

可维护性

可扩展性

结构重组

可移植性

功能性

可变性

互操作性

【开发期】质量属性

1、易理解性

指设计被开发人员理解的难易程度

2、可扩展性

软件因适应新需求或需求变化而增加新功能的能力，也称为灵活性

3、可重用性

指重用软件系统或某一部分的难易程度

4、可测试性

对软件测试以证明其满足规范的难易程度

5、可维护性

修改缺陷、增加功能、提高质量属性时，识别修改点并修改的难易程度

6、可移植性

将软件系统从一个运行环境转移到另一个不同的运行环境的难易程度

【运行期】质量属性

1、性能

性能是指软件系统及时提供相应服务的能力，如速度、吞吐量、容量等

2、安全性

指软件系统同时兼顾向合法用户提供服务，以及组织非法授权使用的能力

3、可伸缩性

用户数和数据量增加时，软件系统维持高服务质量的能力。例如增加服务器来提高能力

4、互操作性

指本软件系统与其他软件系统交互数据和相互调用服务的难易程度

5、可靠性

软件系统一定时间内持续无故障运行的能力

6、可用性

系统在一定时间内正常工作时间所占比例。可用性会受到系统错误，恶意攻击，高负载等问题的影响

7、鲁棒性

软件系统在非正常情况下仍能够正常运行的能力，也成健壮性或容错性

重点质量属性展开说明

性能（performance）

是指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理事件的个数。

性能战术

资源需求

提高计算效率，减少计算开销（优化算法），管理事件率，控制采样频率

资源管理

引入并发，维持多个副本，增加可用资源。（主从机制）

资源仲裁

资源调度策略：先进先出；固定优先级；动态优先级；静态调用

可用性（availability）

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

可用性战术

错误检测

命令/响应【Ping/Echo】;心跳；异常

错误恢复

表决、冗余【主动/被动】、备件

错误预防

进程监视器、事务、从服务器删除

安全性（security）

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

可划分子类

机密性

信息不泄露给未授权用户

完整性

防止信息被篡改

不可否认性

不可抵赖

可控性

对信息的传播及内容具有控制的能力

安全性战术

抵抗攻击

身份验证；用户授权；数据加密；数据完整性；限制暴露；限制访问

检测攻击

入侵检测

从攻击中恢复

识别：审计追踪；恢复：冗余【与可用性重叠】

可修改性（modifiability）

是指能够快速地以较高的性价比对系统进行变更的能力。通常以某种具体的变更为基准，通过考察这些变更的代价衡量系统的可修改性。

可用性战术

局部化修改

维持语义一致性；预期期望的变更；泛化模块；限制可能的选择；抽象通用服务

防止连锁反应

信息隐藏；维持现有的接口；限制通信路径；使用仲裁者

推迟绑定时间

运行时注册；配置文件；多态；组件更换；遵守已定义的协议

易用性

易用性关注的是对用户来说完成某个期望任务的容易程度和系统所提供的用户支持的种类

可测试性

通过测试揭示软件缺陷的容易程度

软件架构评估

识别4个点

敏感点

是一个或多个构件（和/或构件之间的关系）的特性，它能影响系统的某个质量属性

权衡点

影响多个质量属性的特性，是多个质量属性的敏感点

风险点

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

非风险点

是指不会带来隐患，一般陈述句表达。

架构评估方法

基于调查问卷、检查表的方式

主观性较强

基于度量的方式

较为客观、执行困难（评估者需要对架构精确了解）

基于场景的方式

较主观，评估者对架构中等了解即可

质量属性场景

是从风险承担者的角度与系统交互的简短描述，它通常作为描述质量属性的手段。

场景描述六要素

刺激源

生产该刺激的实体

刺激

当刺激达到系统时需要考虑的条件。刺激动作

环境

该刺激在某些条件内发生。当激励发生时，系统可能处于过载、运行等其他情况。描述的是系统环境的运行状态或模式。

制品

某个制品被激励。肯呢个是整个系统（或系统的一部分）

响应

该响应是在激励到达后所采取的行动

响应度量

当响应发生时，应当能够以某种方式进行度量，以对需求进行测试。

对可用性、可修改性、性能、可测试性、易用性、安全性质量属性常见的描述【P153-P156】

基于场景的评估方法

SAAM【软件架构分析法】

最初关注可修改性，后扩充到可移植性、可扩充性等。最早形成文档并得到广泛使用的软件架构分析方法。

输入

问题描述

需求说明

架构描述

ATAM【架构权衡分析法】

由SAAM发展而来，主要针对性能、实用性（可用性）、安全性、可修改性。在系统开发之前，对这些质量属性进行评价和折中。

4个活动领域

1、场景和需求收集

1、收集场景

2、收集需求/约束/环境

2、架构视图和场景实现

3、描述架构视图

4、实现场景

3、属性模型构造和分析

5、特定属性分析（优秀的单一理论）

4、折中

6、标志折中

7、标致敏感度

质量效用树（4层）

树根

质量属性

属性分类

质量属性场景（分主次H、L、M）

CBAM【成本效益分析法】

在ATAM基础上建立的，软件的“经济”模型

构件与中间件技术

构件的定义

定义1：软件构件是一种组装单元，它具有规范的接口规约和显示的语境依赖。软件构件可以被独立地部署并由第三方任意地组装。

定义2：构件是某系统中有价值的、几乎独立的并可替换的一部分，它在良好定义的体系结构语境内满足某清晰的功能。

定义3：构件是一个独立发布的功能部分，可以通过其接口访问它的服务。

构件的复用

检索与提取构件

1、基于关键字的检索

2、刻面检索法

3、超文本检索法

理解与评价构件

1、准确的理解构件至关重要

2、必须要求构件的开发过程遵循公共标准

3、构件文档要求说明：构件的功能与行为、相关的领域知识、可适应性约束条件与例外情形、可以预见的修改部分及修改方法。

修改构件

1、理想状态是直接复用构件库中现成的构件。

2、为了减少构件修改的工作量，要求构件开发人员尽量使构件的功能、行为和接口设计更为抽象化、通用化和参数化。 这样复用者即可通过对实参的选取来调整构件的功能或行为。如何这种调整任不满足，复用者需要借助设计信息和文档来修改构件。

3、构件库中若无可修改使用的构件，则按照新需求开发构件，并存入构件库。

组装构件

构件组装的三种方式

1、基于功能的组装：采用子程序调用和参数传递的方式将构件组装起来

2、基于数据的组装：任然采用子程序调用与参数传递。但它所依赖的软件设计方法不再是功能分解，而是面向数据的设计方法，例如，Jackson系统开发方法

3、面向对象的组装：如果从类库中检索出来的基类能够完全满足新系统的需求，则可以直接应用。否则，必须以基类为父类，生成相应的子类，以满足新系统的需求。

构件组装失配问题

1、由构件引起的失配，包括由于系统对构件基础设施、构件控制模型和构建数据模型的假设存在冲突引起的失配

2、由连接子引起的失配，包括由于系统对构件交互协议、连接子数据模型和假设存在冲突引起的失配

3、由于系统成分对全局体系结构的假设存在冲突引起的失配等

构件的分类

1、独立而成熟的构件

已经在实际运行环境多次检验，该类构件隐藏了所有接口，用户只需用规定好的命令进行使用

例如：数据库管理系统，操作系统

2、有限制的构件

提供了接口，指出了使用的条件和前提，这种构件在装配时，会产生资源冲突、覆盖等影响，在使用时需要加以测试。

例如：各种面向对象程序设计语言中的基础类库等

3、适应性构件

适应性构件进行了包装或使用了接口技术，把不兼容、资源冲突等进行了处理，可以直接使用。

例如：ActiveX等

4、装配的构件

已经装配在系统里，使用胶水代码就可以进行连接使用

例如：一些软件商提供的大多数软件产品都属这一类

5、可修改的构件

对原构件修改错误、增加新功能。可以利用重新“包装”或写接口来实现构件的版本替换。

例如：应用开发中使用的构件

中间件的定义

中间件是一类构件，中间件是一类系统软件，中间件的存在简化结构，屏蔽差异，利于复用。

中间件的优点

1、面向需求

2、业务的分隔和包容性

3、设计与实现隔离

4、隔离复杂的系统资源

5、符合标准的交互模型

6、软件复用

7、提供对应用构件的管理

中间件的分类

通信处理中间件

可靠、高效、实时跨平台通信，eLink，MQSeries

事务处理中间件

事务分发，负载均衡，Tuxedo

数据存取管理中间件

为虚拟缓冲存取、格式转换、解压等带来方便

Web服务器中间件

由负载均衡、缓存、安全性等功能

安全中间件

加密，认证

跨平台和架构的中间件

解决跨平台问题，CORBA

专用平台中间件

为特定应用领域设计领域参考模式，建立相应架构

网络中间件

包括网关、接入、网络测试、虚拟社区和虚拟缓冲等。

三大构件标准

CORBA

伺服对象（Servant）：CORBA对象的真正实现，负责完成客户端请求

对象适配器（Object Adapter）：用于屏蔽ORB内核的实现细节，为服务器对象的实现者提供对象接口，以便他们使用ORB内部的某些功能。

对象请求代理（Object Request Broker）：解释调用并负责查找实现该请求的对象，将参数传给找到的对象，并调用返回结构。客户方不需要了解服务对象的位置、通信方式、实现、激活或存储机制。

J2EE【EJB】

会话Bean：实现业务逻辑，负责完成服务端与客户端的交互

实体Bean：实现O/R映射，简化数据库开发工作

消息驱动Bean：处理并发与异步访问

DNA 2000

C/S架构

微服务架构

SOA架构

云原生架构

大数据分层架构