🔎这里是【软考——系统架构师】，关注我考试轻松过线 👍如果对你有帮助，给博主一个免费的点赞以示鼓励
欢迎各位🔎点赞👍评论收藏⭐️
软件架构的概念
软件架构的定义
软件体系结构是指系统的一个或者多个结构，这些结构包括软件的构件（可能是程序模块、类或者是中间件）、构件的外部可见属性以及他们之间的相互关系。体系结构的设计包括数据设计和体系结构设计，后者主要关注软件构件的结构、属性和交互作用。
软件架构设计与生命周期
软件架构（SA）是贯穿整个生命周期的，不同阶段的作用和意义不同。
| 阶段 | 作用和意义 |
|---|---|
| 需求阶段 | 有利于各阶段参与者的交流，也易于维护各阶段的可追踪性 |
| 设计阶段 | 关注的最早和最多的阶段 |
| 实现阶段 | 有效实现从软件架构设计向实现的转换 |
| 构件组装阶段 | 可复用构件组装的设计能够提高系统实现的效率 |
| 部署阶段 | 组织和展示部署阶段的软硬件架构、评估分析部署方案 |
| 后开发阶段 | 主要围绕维护、演化、复用进 |
体系结构描述语言（ADL）是用于描述软件体系架构的语言，和其他建模语言最大的区分在于其更关注构件间互联机制（连接子），典型的 ADL 语言包括 Unicon、Rapide、Darwin、Wright、C2SADL、Acme、XADLOL、XYZ/ADL 和 ABC/ADL 等。
多视图反映的是一组系统的不同方面，体现了关注点分散的思想，通常与 ADL 结合起来描述系统的体系结构。典型的模型包括：4+1 模型、Hofmesiter 的 4 视图模型、CMU-Sei 的 Views andBeyond 模型。视图标准包括：IEEE 的I471-2000、RM-ODP、UML 以及 IBM 的 Zachman。
视图不仅用语描述设计阶段的模型。
实现阶段的体系结构研究的内容：
（1）研究基于 SA 的开发过程支持
（2）寻求从 SA 向实现过渡的途径
（3）研究基于 SA 的测试技
缩小软件架构设计与底层实现概念差距的手段：模型转换技术、封装底层的实现细节、在SA 模型中引入实现阶段的概念（如用程序设计语言描述）。
中间件支持的连接子（封装的连接机制）实现具有的优势：
（1）中间件可有效保证构件之间的通信完整性
（2）产品化的中间件能够更好的保证最终系统的质量属性
待复用构件（现成的）对最终系统的结构体系和使用限定条件（环境假设）与实际状况不匹配造成的冲突，称为失配，主要包括：
（1）构件本身的失配
（2）连接子（互联机制）的失配
（3）部分和整体的失配
部署安装后（后开发阶段）的系统架构研究方向包括：动态软件体系结构、体系结构恢复与重建。
体系结构重建方法：
（1）手工体系结构重建
（2）工具支持的手工重建
（3）通过查询语言来自动建立聚集
（4）使用其他技术（如数据挖掘）
软件架构的重要性
软件架构设计是降低成本、改进质量、按时和按需交付产品的关键因素。
软件架构的重要性体现在：
（1）架构设计能够满足系统的品质
（2）架构设计使受益人达成一致的目标
（3）架构设计能够支持计划编制过程
（4）架构设计对系统开发的指导性
（5）架构设计能够有效地管理复杂性
（6）架构设计为复用奠定了基础
（7）架构设计能够降低维护费用
（8）架构设计能够支持冲突分析
基于架构的软件开发方法
体系结构的设计方法概述
- 基于体系结构的软件设计方法（ABSD）从项目总体功能框架明确开始（需求尚未完成）。
- ABSD 方法的三个基础：功能的分解、通过选择体系结构风格来实现质量和商业需求、软件 模板的使用。
概念与术语
- ABSD 是一个自顶向下，递归细化的，迭代的每一步都有清晰的定义，有助于降低体系结构设计的随意性。
基于体系结构的开发模型
- 传统软件开发模型开发效率较低，ABSDM 模型把整个基于体系结构的软件过程划分为体系结构需求、设计、文档化、复审、实现和演化 6个子过程。
体系结构需求
- 体系结构的需求工作包括获取用户需求和标识系统中拟用构件。
- 体系结构需求的获取一般来自三个方面：质量目标、系统的商业目标和系统开发人员的商业目标。
- 标识构件分三步完成：生成类图> 对类进行分组 >把类打包成构件
- 架构需求评审的审查重点包括需求是否真实反映了用户的要求，类的分组是否合理，构件合并是否合理等。
体系结构设计
- 软件的体系设计过程包括： 提出软件体系结构模型> 映射构件> 分析构件相互作用 >产生体系结构设计评审
- 设计评审必须邀请独立于系统开发的外部人员。
体系结构文档化
- 体系结构文档化过程的主要输出结果是体系结构规格说明和测试体系结构需求的质量设计说明书。
体系结构复审
- 一个主版本的软件体系结构分析之后，要安排一次由外部人员（用户代表和领域专家）参加的复审。
- 复审的目的是标识潜在的风险，及早发现体系结构设计中的缺陷和错误，必要时，可搭建一个可运行的最小化系统用于评估和测试体系架构是否满足需要。
体系结构实现
- 体系结构的实现过程是以复审后的文档化体系结构说明书为基础的，具体为：分析与设计 >构件实现 >构件组装> 系统测试
- 体系结构说明书中定义了系统中构件与构件之间的关系。
- 测试包括单个构件的功能性测试和被组装应用的整体功能和性能测试。
体系结构的演化
- 体系结构演化史使用系统演化步骤去修改应用，已满足新的需求。
-
系统演化步骤：
需求变化归类>体系结构演化计划 >构件变动 >更新构件的相互作用>构件组装与测试 >技术评审>演化后的体系结构
软件架构风格
- 软件体系结构设计的核心目标是重复的体系结构模式（软件复用/重用）
软件架构风格概述
- 一个体系结构定义一个词汇表和一组约束
- 词汇表包含构件和连接件
- 约束定义构件和连接件的组合方式
经典软件体系结构风格
- 管道和过滤器：每个构件都有输入和输出
- 数据抽象和面向对象组织：构件是对象，即抽象数据类型的实例
- 事件驱动系统：构件不直接调用一个过程，而是触发或广播一个或多个事件
- 分层系统：每一层为上层服务，并作为下层的接口，仅相邻层间具层接口
- 仓库系统级知识库
- C2 风格：通过连接件连接构件或某个构件组，构件与构件之间无连接
客户/服务器风格
- 二层 C/S 模式
（1）优点：客户应用和服务器构件分别运行在不同的计算机上.
（2）缺点：开发成本高，客户端设计复杂，信息内容和形式单一，不利于推广，软件移植困难，软件维护和升级困难。 - 三层 C/S 模式：瘦客户端模式
（1）应用该功能分为表示层、功能层和数据层
（2）表示层：用户接口与应用逻辑层的交互，不影响业务逻辑
（3）功能层：处理业务逻辑
（4）数据层：读写数据库
浏览器/服务器风格：
- B/S 风格是是三层应用结构的实现方式：浏览器/Web 服务器/数据库服务器
- 相对于 C/S 的不足之处：
（1）缺乏动态页面的支持能力
（2）系统拓展能力差
（3）安全性难以控制
（4）响应速度不足
（5）数据交互性不强
特定领域软件体系结构
DSSA 的定义
- DSSA 是在一个特定应用领域中为一组应用提供组织结构参考的标准软件体系结构，即用于某一类特定应用领域的标准软件构件集合。
- DSSA 的必备特征 （1）领域性 （2）普遍性 （3）抽象性 （4）可复用性
DSSA 的基本活动
-
DSSA 的基本活动：领域分析、领域设计、领域实现
-
领域分析：通过分析领域中系统的共性需求，建立领域模型。
-
领域设计：设计 DSSA，且 DSSA 需要具备领域需求变化的适应性。
-
领域实现：获取可重用信息
参与 DSSA 的人员
- 参与人员：领域专家、领域分析师、领域设计人员和领域实现人员。
DSSA 的建立过程
- DSSA 过程是并发的、递归的、反复的螺旋模型，分为 5 个阶段：
（1）定义领域范围
（2）定义领域特定元素
（3）定义领域特定的设计和实现约束
（4）定义领域模型和体系结构
（5）产生，搜集可重用的单元
系统架构的评估
系统架构评估概述
| 属性 | 子属性 | 作用及要点 |
|---|---|---|
| 性能 | 性能 | 效率指标：处理任务所需时间或单位时间内的处理量 |
| 可靠性 | 容错 | 出现错误后仍能保证系统争取运行，且自行修正错误 |
| 可靠性 | 健壮性 | 错误不对系统产生影响，按既定程序忽略错误 |
| 可用性 | 可用性 | 正常运行的时间比例 |
| 安全性 | 安全性 | 系统向合法用户提供服务并阻止非法用户的能力 |
| 可修改性 | 可维护性 | 局部修复使故障对架构的负面影响最小化 |
| 可修改性 | 可拓展性 | 因松散耦合更易实现新特性/功能，不影响架构 |
| 可修改性 | 结构重组 | 不影响主体进行的灵活配置 |
| 可修改性 | 可移植性 | 适用于多样的环境（硬件平台、语言、操作系统等） |
| 功能性 | 功能性 | 需求的满足程度 |
| 可变性 | 可变性 | 总体架构可变 |
| 互操作性 | 互操作性 | 通过可视化或接口方式提供更好的交互操作体验 |
评估中的重要概念
- 敏感点，实现质量目标时应注意的点，即构件特性。
- 权衡点，影响多个质量属性的敏感点。
- 风险承担者或利益相关者，影响体系结构或被体系结构影响的群体
- 场景，确定架构质量评估目标的交互机制，一般采用触发机制（教材中解释为“刺激”）、环境和影响三方面来描述。
主要评估方法
| 123 | SAAM | ATAM |
|---|---|---|
| 特定目标 | 通过程序文档验证体系结构，注重发现潜在问题，可用于评价单系统或进 | |
| 行多系统比较 | 确定在多个质量属性之间折中的必要性 | |
| 评估技术 | 场景技术 | 场景技术、启发式分析方法 |
| 质量属性 | 可修改性是主要分析内容 | 性能、实用性、安全性和可修改性 |
| 风险承担者 | 所有参与者 | 场景和需求收集过程中，相关人 |
| 体系结构描述 | 围绕功能、结构和分配描述 | 5 个基本结构及其映射关系 |
| 方法活动 | 场景开发、体系结构描述、单个场景评估、场景交互和总体评估 | 场景和需求收集、体系结构视图和场景实现、属性模型构造和分析、折中 |
| 知识库可复用性 | 不涉及 | 有基于属性的体系模型，可复用 |
| 方法验证（应用领域） | 空中交通管制系统、嵌入式音频系统、修正控制系统 | 仍处于研究中 |
交流
对软考有兴趣的朋友可以进博主的交流群，目前有软件设计师、高项、系统架构师、系统分析师四个群。文章来源：https://www.toymoban.com/news/detail-424472.html
- 群内有历年真题、电子书等资料可以自取；
- 无营销、纯交流群；
- 每周会有两次送书活动一次三本，包邮到家。
交流入口文章来源地址https://www.toymoban.com/news/detail-424472.html
到了这里，关于【软考——系统架构师】软件架构设计的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
