系统架构设计师 - 系列文章目录
文章目录
-
[系统架构设计师 - 系列文章目录](#系统架构设计师 - 系列文章目录)
[一、软件架构的概念 ★★★](#一、软件架构的概念 ★★★)
[二、基于架构的软件开发 ★★★★](#二、基于架构的软件开发 ★★★★)
[三、软件架构风格 ★★★★](#三、软件架构风格 ★★★★)
[8.MDA（Model Driven Architecture）](#8.MDA（Model Driven Architecture）)
[四、特定领域软件架构 ★★★](#四、特定领域软件架构 ★★★)
[五、软件质量属性 ★★★★★](#五、软件质量属性 ★★★★★)
[六、软件架构评估 ★★★★](#六、软件架构评估 ★★★★)
[2.1 软件架构分析法（SAAM）](#2.1 软件架构分析法（SAAM）)
[2.2 架构权衡分析法（ATAM）](#2.2 架构权衡分析法（ATAM）)
[2.3 成本效益分析法（CBAM）](#2.3 成本效益分析法（CBAM）)
[七、软件产品线 ★★★](#七、软件产品线 ★★★)
[八、构件与中间件技术 ★★★](#八、构件与中间件技术 ★★★)
前言
国家软考 《系统架构设计师》第二版（即最新版本） 学习笔记
提示：以下是本篇文章正文内容，下面案例可供参考
一、软件架构的概念 ★★★
架构的本质
1.软件架构为软件系统提供了一个结构，行为和属性的高级抽象。
2.软件架构风格是特定应用领域的惯用模式，架构定义一个词汇表和一组约束。
架构的作用
1.软件架构是项目干系人进行交流的手段。
2.软件架构是可传递和可复用的模型，通过研究软件架构可能预测软件的质量。
3.软件架构使推理和控制的更改更加简单，有助于循序渐进的原型设计，可以作为培训的基础。
软件架构 = 软件体系结构
软件设计就是需求分配，即将满足需求的职责分配到组件上。
架构发展历程
架构的"4+1"视图
架构的"4+1"视图
UML的"4+1"视图
视角与视图：从不同的视角来检查，所以会有不同的视图
架构描述语言ADL
ADL是这样一种形式化语言，它在底层语义模型的支持下，为软件系统的概念体系结构建模提供了具体语法和概念框架。如：Aesop，MetaH，C2，Rapide，SADL，Unicon等
ADL的三个基本元素
- 构件：计算或数据存储单元
- 连接件：用于构件之间交互建模的体系结构构造块及其支配这些交互的规则
- 架构配置：描述体系结构的构件与连接件的连接图。
二、基于架构的软件开发 ★★★★
ABSD方法是架构驱动，即强调由业务【商业】，质量和功能需求的组合驱动架构设计。
ABSD方法有三个基础。第一个基础是功能的分解。在功能分解中，ABSD方法使用已有的基于模块的内聚和耦合技术；第二个基础是通过选择架构风格来实现质量和业务需求；第三个基础是软件模板的使用。
视角与视图：从不同的视角来检查，所以会有不同的视图。
用例用来捕获功能需求 ，特定场景【刺激，环境，响应】用来捕获质量需求。
开发过程
三、软件架构风格 ★★★★
架构风格定义了用于描述系统的术语表和一组指导构建系统的规则。
| 五大架构风格 | 子风格 |
|---|---|
| 数据流风格 【Data Flow】 | 批处理【Batch Sequential】，管道-过滤器【Pipes and Filters】 |
| 调用/返回风格 【Call/Return】 | 主程序/子程序【Main Program and Subroutine】， 面向对象【Object-oriented】，分层架构【Layered System】 |
| 独立构件风格 【Independent Components】 | 进程通信【Communicating Processes】 事件驱动系统（隐式调用）【Event System】 |
| 虚拟机风格 【Virtual Machine】 | 解释器【Interpreter】，规则系统【Rule-based System】 |
| 以数据为中心 【Data-Centered】 | 数据库系统【Database System】，黑板系统【Blackboard System】，超文本系统【Hypertext System】 |
1.数据流风格
批处理
| 优点 | 缺点 | 典型实例 |
|---|---|---|
| 1.松耦合【高内聚-低耦合】 2.良好的重用性/可维护性 3.可扩展性【标准接口适配】 4.良好的隐蔽性 5.支持并行 | 1.交互性较差 2.复杂性较高 3.性能较差（每一个过滤器都需要解析与合成数据） | 传统编译器 网络报文处理 |
管道-过滤器
2.调用/返回风格
分层架构风格
| 优点 | 缺点 | 特点 |
|---|---|---|
| 1.良好的重用性，只要接口不变可用在其它处 2.可维护性好 3.可扩展性好，支持递增设计 | 1.并不是每个系统都方便分层 2.很难照道一个合适的，正确的层次抽象方法 3.不同层次之间耦合度高的系统很难实现 | 各个层次的组件形成不同功能级别的虚拟机； 多层相互协同工作，而且实现透明。 |
3.独立构件风格
4.虚拟机风格
| 子分类 | 优点 | 缺点 | 特点 | 适合领域 |
|---|---|---|---|---|
| 解释器 | 可以灵活应对自定义场景 | 复杂度较高 | 适用于需要"自定义规则"的场合 | |
| 规则为中心 | 可以灵活应对自定义场景 | 复杂度较高 | 再解释器的基础上增加经验规则 | 适用于专家系统 |
基于规则的系统构成：规则集，规则解释器，规则/数据选择，工作内存 ，一般用在人工智能领域何DSS（决策支持系统）中。
5.以数据为中心
黑板系统：
| 架构风格 | 子分类 | 优点 | 缺点 | 特点 | 典型案例 |
|---|---|---|---|---|---|
| 以数据为中心 | 数据库系统 | 以数据为中心 | |||
| 以数据为中心 | 黑板系统 | 可更改性何可维护性；可重用的知识源；容错性何健壮性 | 测试困难；不能保证有好的解决方案；难以建立好的控制策略；低效；开发困难；缺少并行机制； | 在以数据为中心的基础上，使用忠新数据触发业务逻辑部件 | 语音识别 模式识别 图像处理 知识推理 |
6.闭环控制架构（过程控制）
- 适合于嵌入式系统，用于解决简单闭环控制问题
- 经典应用：空调温控，定速巡航
7.C2风格
C2架构的基本规则：
- 构件和连接件都有一个顶部和一个底部
- 构件的顶部要连接到连接件的底部，构件的底部要连接到连接件的顶部，构件之间不允许直连
- 一个连接件可以和任意数目的其他构件和连接件连接。
- 当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部
8.MDA（Model Driven Architecture）
Model -> 客观事物的抽象表示
Architecture -> 构成系统的部件，连接件及其约束的规约
Model-Driven -> 使用模型完成软件的分析，设计，构件，部署，维护等各个开发活动
MDA -> 起源于分离系统规约和平台实现的思想
MDA的主要目标：
- Portability (可移植性)
- Interoperability (互通性)
- Reusability (可重用性)
MDA的核心模型：
- 计算无关模型（CIM）：对某具体行业内一个项目的业务需求及其系统功能需求进行分析
- 平台独立模型（PIM）：具有高抽象层次，独立于任何实现技术的模型
- 平台相关模型（PSM）：为某种特定实现技术量身定做，让你用这种技术中可用的实现构造来描述系统的模型。PIM会被变换成一个或多个PSM
- 代码Code：用源代码对系统的描述（规约）。每个PSM都将被变换成代码。
四、特定领域软件架构 ★★★
1.基本概念
定义：特定领域软件架构以一个特定问题领域为都一项，形成由领域参考模型，参考需求，参考架构等组成的开发基础架构，支持一个特定领域中多个应用的生成。
DSSA类型：
- 垂直域：相同领域，深入
- 水平域：不同领域，平移
2.参与人员
参与DSSA的人员：
1.**领域专家：**有经验的用户，从事该领域中系统的需求分析，设计，实现以及项目管理的有经验的软件工程师等。
领域专家的主要任务包括提供关于领域中系统的需求规约和实现的知识。
2.**领域分析人员：**领域分析人员应由具有知识工程背景背景的有经验的系统分析员来担任
3.领域设计人员：领域设计人员应由有经验的软件设计人员来担任
4.领域实现人员：领域实现人员应由有经验的程序设计人员来担任
3.建立过程
五、软件质量属性 ★★★★★
1.性能
性能（Performance）是指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件的个数。
例如：
- 同时指出2000并发
- 响应时间小于1秒；
- 显示分辨率达到4K
2.可用性
可用性（availability）是系统能够**正常运行的时间比例。**经常用两次故障之间的时间长度或出现故障时系统能够恢复正常的速度来表示。
例如：
- 主服务器故障，1分钟内切换到备用服务器
- 系统故障，1小时内修复
- 系统支持7*24小时工作
3.安全性
安全性（security）是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。 安全性又可划分为**机密性【信息不泄露给未授权的用户】，完整性【防止信息被篡改】，不可否认性【不可抵赖】，可控性【对信息的传播及内容具有控制的能力】**等特性。
例如：
- 可抵御SQL注入攻击
- 对计算机的操作都有完整记录
- 用户信息数据库授权必须保证99.99%可用
4.可修改性
可修改性（modifiability）是指能够快速地以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准，通过考察这些变更的代价衡量可修改性。
例如：
- 更改系统报表模块，必须在2人月内完成
- 对web界面风格进行修改，修改必须在4人月内完成
5.易用性
易用性关注的是对用户来说完成某个期望任务的容易程度和系统所提供的用户支持的种类。
例如：
- 界面友好
- 新用户学习使用系统时间不超过2小时
6.可测试性
软件可测试性是指通过测试揭示软件缺陷的容易程度
例如：提供远程调试接口，支持远程调试
六、软件架构评估 ★★★★
敏感点是一个或多个构件（和/或构件之间的关系）的特征，它能影响系统的某个质量属性。（容易考概念）
权衡点是影响多个质量属性的特性，是多个质量属性的敏感点。（容易考概念）
风险点是指架构设计中潜在的，存在问题的架构决策所带来的隐患。（容易考概念）
非风险点是指不会带来隐患，一般以"XXX要求是可以实现（或接受）的"方式表达。（容易考概念）
例如：
- 对交易请求处理时间的要求将影响系统的数据传输协议和处理过程的设计； 敏感点
- 假设每秒中用户交易请求的数量是10个，处理请求的时间为30毫秒，则"在1秒内完成用户的交易请求"这一要求是可以实现的；非风险点
- 目前对系统信用卡支付业务逻辑的描述尚未达成共识，这可能导致部分业务功能模块的重复，影响系统的可修改性；风险点
- 修改加密的级别将对安全性和性能产生影响。权衡点
1.架构评估方式
- 基于调查问卷（检查表）的方式
- 基于度量的方式
- 基于场景的方式
|-----------------|----------|---------|--------|---------|
| 评估方式 | 调查问卷或检查表 || 场景 | 度量 |
| 评估方式 | 调查问卷 | 检查表 | 场景 | 度量 |
| 通用性 | 通用 | 特定领域 | 特定系统 | 通用或特定领域 |
| 评估者对架构的了解程度 | 粗略了解 | 无限制 | 中等了解 | 精确了解 |
| 实施阶段 | 早 | 中 | 中 | 中 |
| 客观性 | 主观 | 主观 | 较主观 | 较客观 |
【场景】是从风险承担者的角度对系统交互的简短描述。
场景可从6个方面进行描述：刺激源，刺激，制品，环境，响应，响应度量
2.基于场景的评估方法
2.1 软件架构分析法（SAAM）
最初用于分析架构可修改性，后扩展到其他质量属性
2.2 架构权衡分析法（ATAM）
在SAAM的基础上发展起来的，主要针对性能，实用性，安全性，可修改性，在系统开发之前，对这些主要属性进行评价和折中。
2.3 成本效益分析法（CBAM）
在ATAM基础上建立的，软件的"经济"模型。
七、软件产品线 ★★★
1.双生命周期模型
2.建立方式
| 演化方式 | 革命方式 | |
|---|---|---|
| 基于现有产品 | 基于现有产品架构设计产品线的架构，经过演化现有构件，开发产品线构件。 | 核心资源的开发基于现有产品集的需求和可预测的，将来需求的超集。 |
| 全新产品线 | 产品线核心资源随产品新成员的需求而演化 | 开发满足所有预期产品线成员的需求的核心资源 |
- 将现有产品演化为产品线
- 用软件产品线替代现有产品集
- 全新软件产品线的演化
- 权限软件产品线的开发
3.组织结构
组织结构类型：
- 设立独立的核心资源小组
- 不设立独立的核心资源小组
- 动态的组织结构
要成功实施产品线，主要取决于以下因素：
- 对该领域具备长期和深厚的经验
- 一个用于构件产品的好的核心资源库
- 好的产品线架构
- 好的管理（软件资源，人员组织，过程）支持
八、构件与中间件技术 ★★★
1.软件复用
软件复用【重用】是多次不同的软件开发过程中重复使用相同或相似【软件元素】的过程。
【软件元素】=> 需求分析文档，设计过程，设计文档，程序代码，测试用例，领域知识
复用的历史发展路线：
复用的维度：
- 水平复用：不分行业领域，通用
- 垂直复用：分行业领域，专用
2.中间件基本概念
构件的定义：
定义1：软件构件是一种组装单元，它具有规范的接口规约和显式的语境依赖。软件构件可以被独立地部署并由第三方任意地组装。
定义2：构件是某系统中有价值的，几乎独立的并可以替换的一个部分，它在良好定义的体系结构语境内满足某清晰的功能。
定义3：构件是一个独立发布的功能部分，可以通过其接口访问它的服务。（可能考概念）
3.构件的复用
4.中间件
中间件是一类构件
中间件是一类系统软件
简化结构，屏蔽差异，利于复用
采用中间件技术的有点：
- 面向需求。即设计师集中精力于业务逻辑本身。
- 业务的分隔和包容性。应用开发人员可以按照不同的业务进行功能的划分，体现为不同的接口或交互模式
- 设计与实现隔离。构件对外发生作用或者构件间的交互，都是通过接口进行的，构件使用者只需要知道构件的接口，而不必关心其内部实现，这是设计与实现分离的关键。
- 隔离复杂的系统资源。架构很重要的一个功能就是将系统资源与应用构建隔离，这是保证构件可复用甚至"即插即用"的基础，与中间件的意图也是一致的。
- 符合标准的交互模型。中间件则实现了架构的模型，实现了标准的协议
- 软件复用。中间件提供了构件封装，交互规则，与环境的隔离等机制，这些都为软件复用提供了方便的解决方案。
- **提供对应用构件的管理。**基于中间件的软件可以方便地进行管理，因为构件总可以通过标识机制进行划分。
| 中间件分类 | 特点 |
|---|---|
| 通信处理（消息）中间件 | 可靠，高效，实时跨平台通信； |
| 事务处理（交易）中间件 | 事务分发，负载均衡 |
| 数据存取管理中间件 | 为虚拟缓冲存取，格式转换，解压等带来方便 |
| Web服务器中间件 | 有负载均衡，缓存，安全性等功能 |
| 安全中间件 | 如：加密，认证等 |
| 跨平台和架构的中间件 | 解决跨平台问题 |
| 专用平台中间件 | 为特定应用领域设计，领域参考模式，建立相应架构 |
| 网络中间件 | 功能包括网管，接入，网络测试，虚拟社区和虚拟缓冲等 |
您的赞赏将是我继续更新的动力，欢迎赞赏！！！
