跳至主要內容

软件系统架构

BraumAce2026/2/22软考系统架构设计师系统架构设计约 6775 字大约 23 分钟

软件系统架构

1. 软件架构

1.1 概念（宏观）

  1. 软件系统架构是关于软件系统的 结构、行为 和 属性 的高级抽象（宏观层次上）。
  2. 在描述阶段，主要描述直接构成系统的抽象组件以及各个组件之间的连接规则，特别是描述组件的 交互关系。
  3. 在实现阶段，这些抽象组件被细化为实际的组件，比如具体类或对象。
  4. 软件系统架构不仅指定了软件系统的 组织 和 拓扑结构，而且显示了 系统需求 和 组件 之间的对应关系，包括设计决策的 基本方法和基本原理。
  5. ANSI/IEEE 1471-2000是对软件密集型系统的架构进行描述的标准。在该标准中，
    1. 视图 主要用于描述 软件架构模型。
    2. 在此基础上，通常采用 视角 描述某个 利益相关人（Stakeholder）所关注架构模型的某一方面。
    3. 架构 则是对所有利益相关人关注点的 响应和回答。

1.2 软件架构设计

  1. 软件架构设计包括 提出架构模型、产生架构设计、进行设计评审 等活动，是一个迭代的过程。
  2. 架构设计主要关注软件组件的 结构、属性 和 交互作用，并通过多种 视图 全面描述特定系统的架构。

1.3 生命周期

  1. 需求分析阶段：
    1. 从 软件需求模型 转换为 软件架构（SA）模型，主要是两方面：
      1. 根据需求模型构建 SA 模型：词法分析、一些经验规则
      2. 保证模型转换的可追踪性：表格、Use Case Map
  2. 设计阶段：
    1. SA 模型的描述
    2. SA 模型的设计与分析方法
    3. 对 SA 设计经验的总结与复用
  3. 实现阶段：
    1. 研究基于 SA 的开发过程支持
    2. 寻求从 SA 向实现过渡的途径
    3. 研究基于 SA 的测试技术
  4. 构件组装阶段：
    1. 支持可复用构件的互联
    2. 检测并消除体系结构适配的问题
  5. 部署阶段：
    1. 提供高层的体系结构视图来描述部署阶段的软硬件模型
    2. 基于 SA 模型分析部署方案的质量属性，并选择合理的部署方案
  6. 后开发阶段：
    1. 主要围绕维护、演化、复用等方面进行
    2. 典型的研究方法包括：
      1. 动态软件体系结构
      2. 体系结构恢复与重建

1.4 架构描述语言（ADL）

  1. 概念：是一种 明确说明软件系统的概念架构 和 对这些概念架构建模提供功能 的 语言。更关注构件间的 互联机制（连接子）。
  2. 主要包括以下组成部分：
    1. 组件
    2. 组件接口
    3. 连接件
    4. 架构配置

1.5 作用与重要性

  1. 软件架构的作用
    1. 分析设计在满足所规定的需求方面的有效性，侧重于非功能性属性
    2. 降低与软件构造相关联的风险
    3. 在设计变更相对容易的阶段，考虑系统结构的可选方案
    4. 便于技术人员与非技术人员就软件设计进行交互
    5. 展现 软件的结构、属性与内部交互关系
    6. 软件架构是降低成本、改进质量、按时和按需交付产品的关键因素
  2. 软件架构设计的重要性：
    1. 能够满足系统 质量属性，如 性能、安全性、可修改性、可维护性 等，并能够指导设计人员和实现人员的工作。
    2. 能够帮助项目（受益人）干系人（Stakeholder）更好地理解软件结构
    3. 确定组件之间的依赖关系，直接支持项目计划和项目管理的活动，协助估算项目成本
    4. 对系统开发的指导性，引导设计人员和实现人员的工作，确保体系架构的完整性
    5. 为复用奠定基础
    6. 能够有效地管理系统的复杂性，并降低系统维护费用
    7. 能够支持冲突分析

2. 基于架构的软件设计方法（ABSD）

2.1 概念

  1. 名字：Architecture-Based Software Design，ABSD
  2. 是一种 自顶向下的，递归细化 的开发方式，强调构成体系结构的 商业、质量、功能需求 的组合来驱动软件架构设计，最终产生 软件构件和类（模块）。
  3. 该方法中，顶层被分解为 概念子系统，第 2 层被分解为 概念构件 和一个或若干个附加软件模板。
  4. 采用 视角与视图 描述 软件架构。
  5. 采用 用例与质量场景 描述 功能 和 质量 需求。
    1. 用例 -> 功能需求
    2. 质量场景 -> 质量需求
  6. ABSD 方法有三个基础，分别是：
    1. 对系统进行 功能分解
    2. 采用 架构风格 实现质量属性与商业需求
    3. 采用 软件模板 设计软件结构
  7. 在 ABSD 中，强调从多个视角去分析系统架构，以确保设计的全面性和高质量。视角一共有 4 个：
    1. 静态视角：静态的展示系统功能结构、组织结构，以此分析系统的 质量特性
    2. 动态视角：关注系统在运行时的 行为特性，如并发性、实时响应性
    3. 配置视图：表示 软件到硬件 的映射和分布结构（即架构 4+1 视图的定义）
    4. 逻辑视图：描述系统中涉及 元素的功能、接口 等，明确它们在整个系统中承担的角色，是记录系统功能结构的一个核心视图

2.2 基于架构的软件设计方法模型（ABSDM）

ABSD 方法（也可以说是模型）主要包括 6 个主要活动，分别是：

2.2.1 架构需求

  1. 需求：指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望
  2. 需求工作包括 获取用户需求 和 标识系统中拟用构件
  3. 需求获取：来自三个方面：
    1. 系统的质量目标：如可用性、性能、安全性
    2. 系统的商业目标：如市场定位、成本控制、用户群体定位
    3. 系统开发人员的商业目标：重用已有构建、快速交付、降低开发成本
  4. 标识构件：该过程为系统生成三步：
    1. 生成类图
    2. 对类进行分组
    3. 把类打包成构件
  5. 架构需求评审：由不同代表组成小组，对架构需求及相关构件进行审查

2.2.2 架构设计

  1. 设计过程：
    1. 提出软件架构模型：获得关于架构属性的理解，为将来的实现和演化过程建立目标
    2. 映射构件：把已标识的构件映射到软件架构中
    3. 分析构件相互作用：为了把所有已标识的构件集成到软件架构中
    4. 产生体系结构设计评审：设计评审必须邀请独立于系统开发的外部人员。

2.2.3 架构文档化

  1. 主要输出结果是两个文档：
    1. 架构规格说明书
    2. 测试架构需求的 架构质量设计说明书

2.2.4 架构复审

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

2.2.5 架构实现

  1. 以复审后的文档化的 架构说明书 为基础（架构说明书中定义了系统中构件之间的关系），每个构件必须满足软件架构中说明的对其他构件的责任。
  2. 实现过程：
    1. 分析与设计：对架构说明书进行细化，定义构件的详细结构和接口，完成构件及相关数据库的详细设计
    2. 构件实现：依据详细设计规约，编写代码实现构件功能，并对构件进行单元测试
    3. 构件组装：按照架构说明书中定义的构件关系，将已实现的构件组装成完整的软件系统
    4. 系统测试：测试包括 单个构件的功能性测试、被组装应用的整体功能 和 性能测试

2.2.6 架构演化

  1. 针对 用户的需求变化，修改应用架构（使用系统演化步骤去修改应用），以满足新的需求
  2. 体系结构演化 6 个步骤：
    1. 需求变化归类：分析用户需求变化，并将其归类，决定影响哪些构件
    2. 制定体系结构演化计划：在变更实施前制定详细计划，指导后续开发
    3. 修改、增加或删除构件：根据需求变化对构件进行相应调整
    4. 更新构件的相互作用：随着构件变化，相互之间的调用与协作逻辑也需同步更新
    5. 构件组装与测试：将新旧构件重新组装成系统整体，并对其功能和性能进行测试
    6. 技术评审：对上述变更的正确性和有效性进行评审，以确保满足变更需求

3. 面向服务的体系结构（SOA，Service-Oriented Architecture）

3.1 概念

  1. 定义：
    1. 将系统功能 拆分 成独立的、可复用的服务，通过 标准化接口，实现系统各个模块间的 松耦合 通信，支持跨平台、跨语言集成。
    2. SOA 架构以 ESB 企业服务总线 链接各个子系统，是 集中式 的技术架构，应用服务间相互依赖导致部署复杂，应用间交互使用远程通信，降低了响应速度。

3.2 特点

  1. 松耦合：服务间的依赖程度较低，可以保持接口不变的情况下，对内部进行独立修改
  2. 服务复用：将业务逻辑封装为可复用的服务，避免重复开发，降低开发成本
  3. 标准化接口：通过标准接口（如 Web Service）定义服务契约，屏蔽底层实现细节，支持跨平台互操作
  4. 粗粒度服务：服务封装的是完整的业务功能，接口数量较少，减少了交互频率，提升了通信效率

3.3 SOA 的参考架构

以 服务为中心 的企业集成采用“关注点分离”的方法规划企业集成中的各种架构元素。从服务为中心的视角来看，企业集成的架构可划分为 6 大类：

  1. 业务逻辑服务：用于实现核心业务逻辑，包括新建应用服务、适配器连接的遗留系统和打包应用服务等
  2. 控制服务：包括业务流程管理和编排、事务处理等服务，负责协调多个服务的执行顺序
  3. 连接服务：即 企业服务总线（ESB），提供消息路由、格式转换和传输服务，是服务交互的基础设施
  4. 业务创新和优化服务：通过 业务活动监控（BAM）等手段，实时监控业务状态，支持业务流程的持续优化
  5. 开发服务：提供统一的开发和测试环境，贯穿服务的设计、开发、测试和部署全生命周期
  6. IT 服务管理：提供安全、管理和监控等支撑服务，保障系统的稳定性和安全性

3.4 企业服务总线（ESB，Enterprise Service Bus）

  1. 企业服务总线，是一种中介机制，也是一种架构模式，提供各个服务之间的 交互（动态地互联互通）。
  2. ESB 采用 总线结构 模式，简化了应用之间的集成拓扑，提供了基于标准的通用连接服务，使得服务请求者和服务提供者之间可以以 松耦合、动态 的方式交互。
  3. 是实现 SOA 解耦的关键组件。

3.5 服务注册模式四大核心技术

  1. UDDI（Universal Description，Discovery and Integration，通用协议发现与集成）：
    1. 是一个基于 XML 的 Web 服务注册和发现的标准规范。相当于一个服务黄页，提供集中式的服务信息存储和查询机制。
    2. 作用是 解决 服务在哪里 的问题。
    3. 用于让开发人员发布和查找 Web 服务，不负责远程调用。
    4. 核心功能（描述、发现、集成）：
      1. 描述服务元数据
      2. 发现服务提供者
      3. 集成现有服务
  2. WSDL（Web Service Description Language，Web 服务描述语言）：
    1. 是一个用来描述 Web 服务和操作的 XML 语言。
    2. 基于 XML 语言，描述外部服务的 接口信息。作为服务的 说明书，让客户端知道如何与服务交互，解决 服务如何交互 的问题。
    3. 三个基本属性：
      1. 服务做些什么：服务所提供的操作（方法）
      2. 如何访问服务：和服务交互的数据格式以及必要协议
      3. 服务位于何处：协议相关的地址，如 URL
  3. SOAP（Simple Object Access Protocol，简单对象访问协议）：
    1. 基于 XML 语言的通信协议，用于在分布式系统中 实现服务间的远程调用，跨平台、跨语言。
    2. 作用是 解决 服务如何调用 的问题，规范请求和响应的格式，确保不同系统能够理解彼此的消息（HTTP、SMTP、POP3）
    3. 包含 4 个部分：
      1. SOAP 封装（Envelop）：定义消息内容，发送者，处理方式
        1. SOAP 消息由一个 信封、头部（Header）、主体（Body）组成
        2. 信封定义了消息内容，并指明谁应该处理它们
      2. SOAP 编码规则（Encoding Rules）：表示应用程序需要使用的数据类型的实例
      3. SOAP RPC 表示（RPC Representation）：是远程过程调用和应答的协定
      4. SOAP 绑定（Binding）：是使用底层协议交换信息
    4. 特别地，信封和编码规则是被定义在不同的 XML 命名空间（Namespace）中，这样使得定义更加简单。
  4. BPEL（Business Process Execution Language，业务流程执行语言）：
    1. 基于 XML 语言，用于描述和执行业务流程。
    2. 用于 组合、编排和协调 多个 Web 服务，将它们组织成一个复杂的有机应用。
    3. 作用是 解决 服务如何协同工作 的问题。

REST 与 SOAP 的区别

  1. SOAP：更规范、更严格的协议规范
  2. REST：更轻量的，只基于 HTTP 方法的协议

3.6 SOA 设计的标准要求

  1. 文档标准化：WSDL 是用于描述服务的标砖语言
  2. 通信协议标准：用消息进行通信，消息通常使用 XML Schema 来定义（XSD，XML Schema Definition）
  3. 应用程序统一登记与集成：统一描述、定义和集成是服务登记的标砖
  4. 服务质量（QoS）：
    1. 可靠性
    2. 安全性
    3. 策略
    4. 控制
    5. 管理

3.7 SOA 的设计原则

  1. SOA 架构中，继承了来自对象和组件设计的各种原则，如封装、自我包含等。
  2. 结构上，服务总线 是 SOA 的架构模式之一。
  3. 关于服务的设计原则如下：
    1. 无状态：避免服务请求者依赖于服务提供者的状态
    2. 单一实例：避免功能冗余
    3. 明确定义的接口：服务的接口由 WSDL 定义
    4. 自包含和模块化：封装服务，实现服务的功能实体是完全独立自主的，独立进行部署、版本控制、自我管理和恢复
    5. 粗粒度：服务数量不应该太大，依靠消息交互。通常消息量比较大，但交互频度较低
    6. 服务之间的松耦合性：
    7. 重用能力：
    8. 互操作性、兼容和策略声明：确保服务规约的全面和明确

4. 特定领域软件架构（DSSA，Domain Specific Software Architecture）

4.1 概念

  1. 是一个在特定应用领域中，为一组应用提供组织结构参考的标准软件体系结构，即 用于某一类特定应用领域的标准软件构件集合。
  2. 特定领域软件架构以 一个特定问题领域 为对象，形成由 领域参考模型、参考需求、参考架构 等组成的开发基础架构，支持一个特定领域中多个应用的生成。
  3. 特点：领域性、普遍性、抽象性、可复用性
  4. 从功能覆盖的角度理解，分为两种：
    1. 垂直域：定义了 一个特定的系统族，包含整个系统族内的多个系统，可作为该领域系统的可行解决方案的一个通用软件架构（只能应用于一个成熟的、稳定的领域，但往往难以满足）
    2. 水平域：定义了 在多个系统和多个系统族 中功能区域的共有部分，在子系统级上涵盖多个系统族的特定部分功能

4.2 三层模型

  1. 领域开发环境：用于创建和维护领域模型、领域构件等领域资产（领域架构师）
  2. 领域特定应用开发环境：基于领域开发环境的资产，支持开发者构件特定领域的应用（应用工程师）
  3. 应用执行环境： 运行最终开发出的特定领域应用（操作员）

4.3 基本活动

  1. 领域分析：主要目的是获得 领域模型，从而描述领域中系统之间共同的 需求，即 领域需求。
  2. 领域设计：获得 特定领域软件架构（DSSA），从而描述领域模型中 表示需求的解决方案，且 DSSA 需要具备领域需求变化的适应性。详细过程见 4.5 建立过程
  3. 领域实现：开发和组织可重用信息，并实现基础软件架构

4.4 参与人员

  1. 领域专家：提供领域内的需求规格和实现经验，负责把握大方向
  2. 领域分析者：控制整个领域的分析过程，获取领域知识，并且将知识组织到领域模型中
  3. 领域设计者：控制整个软件设计过程，根据领域模型和现有的系统开发出 DSSA，并对 DSSA 的准确性和一致性进行验证
  4. 领域实现者：待 DSSA 开发完成后，将其转化为具体的系统（写代码的）

4.5 建立过程

DSSA 的建立过程是 并发的、递归的、反复的 螺旋模型，分为五个阶段：

  1. 定义领域范围
  2. 定义领域特定元素
  3. 定义领域特定的设计和实现约束
  4. 定义领域模型和体系结构
  5. 产生、搜集可重用的单元

5. 软件架构复用

5.1 概念

  1. 定义：
    1. 指系统化的软件开发过程：开发一组基本的软件构造模块，以覆盖不同的需求/架构之间的相似性，从而提高系统开发的效率、质量和性能。
  2. 核心思想：
    1. 通过重复利用已有的软件资产（如构件、架构、模式等），提高开发效率、降低成本、提升质量。
  3. 分类：
    1. 机会复用：指在开发过程中，只要发现有可复用的资产，就对其进行复用。
    2. 系统复用：指在开发之前，就要进行规划，以决定哪些需要复用。

5.2 原因

  1. 减少开发工作、减少开发时间以及降低开发成本，提高生产力
  2. 提高产品质量使其具有更好的互操作性
  3. 使产品维护变得更加简单

5.3 复用的对象及形式

  1. 可复用的资产有：需求，架构设计，元素，建模与分析，测试，项目规划，过程、方法和工具，人员，样本系统，缺陷消除
  2. 一般形式的复用包括：
    1. 函数的复用
    2. 库的复用
    3. 在面向对象开发中的 类、接口和包的复用

5.4 复用的基本过程

  1. 构造/获取可复用的软件资产：首先必须拥有可以复用的资产。这些资产可以是自己构造的，也可以是从第三方获取或开源项目中提取的，必须符合一定的规范和质量要求。
  2. 管理可复用资产：资产构造或获取之后，必须进行有效管理。包括分类、版本控制、文档维护、存储与检索机制等，确保资产的可维护性和可查找性。
  3. 使用可复用资产：最后，针对具体系统需求，选择合适的资产并集成到新系统中，实现真正的复用目标。

6. 系统应用集成（EAI）

6.1 概念

  1. EAI 通过构建统一标准的基础平台，在各个应用系统的接口之间共享数据和功能，基本原则是保证应用程序的 独立性。

6.2 核心原则

  1. EAI 的核心原则之一是确保各应用程序的 独立性，即各个系统可以独立运行，同时通过统一平台进行集成。这种独立性有助于系统的灵活性和可扩展性。

6.3 服务层次

  1. 通信：最基础的服务。
  2. 应用连接：第三层服务，用于实现不同应用系统的连接。
  3. 信息传递与转化：第二层服务，负责确保信息在不同系统之间的转换和传递。
  4. 流程控制：最上层服务，负责业务流程的管理和控制，确保整个系统的协调性和高效运行。

6.4 集成类型

  1. 表示集成
  2. 数据集成
  3. 控制集成
  4. 业务流程集成
  5. 企业间应用集成
  6. 事件驱动架构

7. 遗产系统（Legacy System）

7.1 概念

  1. 定义：指组织中美观虽然已有较长的使用历史，但仍在其业务运作中起关键作用，且通常伴随着技术陈旧、文档缺失等特征的信息系统。
  2. 核心问题：如何处理遗产系统是软件演化与系统迁移中的关键决策点，涉及 “淘汰、继承、改造” 等策略的选择。

7.2 特点

  1. 业务价值高：承载核心业务逻辑，支撑企业的日常运作，短时间内难以完全替代。
  2. 技术陈旧：采用过时的编程语言、数据库或硬件平台，维护困难，技术支持稀缺。
  3. 文档缺失：缺乏有效的技术文档和设计说明，系统逻辑往往隐含在代码中（“黑盒”状态）。
  4. 维护成本高：系统结构混乱（“面条代码”），修改容易引发连锁反应，适应性差。

7.3 分类与演化策略

根据系统的 技术水平（低/高）与 业务价值（低/高）两个维度，将遗产系统分为四类，并采取相应的演化策略：

  1. 低价值、低技术水平（淘汰）：
    1. 特点：业务价值低，技术落后，对组织贡献极小。
    2. 策略：完全淘汰，重新开发新系统或直接采购成熟软件包替代。
  2. 低价值、高技术水平（继承）：
    1. 特点：技术架构较新，运行良好，但业务价值较低（如辅助性系统）。
    2. 策略：保持现状，将其作为普通组件继承到新架构中，不做大规模改造。
  3. 高价值、低技术水平（改造）：
    1. 特点：核心业务系统，业务价值高，但技术落后，维护困难。
    2. 策略：进行重构或包装（如封装为 Web Service），集成到新架构中，挖掘其核心数据价值。
  4. 高价值、高技术水平（集成）：
    1. 特点：业务价值高，技术先进，系统运行良好。
    2. 策略：作为核心资产直接集成到新系统中，保持其运行并与其他系统协同工作。

8. MVC 模式

8.1 概念

  1. MVC 模式，即 模型—视图—控制（Model-View-Controller）模式，它实际上是一种架构模式。
  2. 是为那些需要为同样的数据提供多个视图的应用程序而设计的，它很好地体现了数据层与表示层的分离。

8.2 组成

MVC 把应用程序分为 3 种对象类型：

  1. 模型：应用问题域中包含的 抽象领域知识；
  2. 视图：将应用问题域中包含的 抽象领域知识呈现给用户的方法：
    1. 一个模型可以用于多个视图；
  3. 控制器：用户界面对用户输入的响应方式。

9. 其他

9.1 信息隐藏

  1. 信息隐蔽 是开发整体程序结构时使用的结构化原则
  2. 核心思想：将每个程序成分的内部细节限制在模块内部，不对外暴露实现细节，仅通过定义良好的接口进行交互。
  3. 优点：
    1. 可以降低模块间的耦合度
    2. 减少外部变化对模块内部的影响
    3. 可以提高软件的 可修改性、可测试性 和 可移植性。

9.2 中间件

  1. 在分布式系统中，中间件通常提供两种不同类型的支持，即 交互支持、提供公共服务。
编辑此页
最近更新:
贡献者: BraumAce
主题美化