基于架构的软件开发方法

摘要

基于架构的软件开发方法（Architecture-Based Software Development，简称ABSD）是一种以软件体系结构为核心的开发范式。该方法从项目总体功能框架出发，强调在需求尚未完全明确时即开始体系结构设计，通过自顶向下、递归细化的方式降低设计的随意性。本文系统介绍ABSD的基本概念、三个基础、开发模型以及六大子过程------体系结构需求、设计、文档化、复审、实现与演化，旨在为软件工程实践提供理论指导。

一、概述与基本概念

1.1 体系结构的设计方法概述

基于体系结构的软件设计方法（ABSD）不同于传统瀑布模型或原型模型，它从项目的总体功能框架明确开始，而此时完整的需求可能尚未完成。ABSD方法建立在三个基础之上：功能的分解、通过选择体系结构风格来实现质量和商业需求、以及软件模块的使用。这一方法有助于在早期阶段把握系统的宏观结构，降低后续开发中的不确定性。

1.2 概念与术语

ABSD是一种自顶向下、递归细化的方法。每一次迭代都有清晰的定义，从而有效降低体系结构设计的随意性。它强调将系统逐层分解为更小的子系统或构件，并通过定义它们之间的交互关系来满足功能与非功能需求。

二、基于体系结构的开发模型

传统软件开发模型（如瀑布模型）往往存在开发效率较低、需求变更适应性差等问题。为此，ABSDM模型（Architecture-Based Software Development Model）将整个开发过程划分为六个连续的子过程：体系结构需求 、体系结构设计 、体系结构文档化 、体系结构复审 、体系结构实现 和体系结构演化。这六个子过程形成一个闭环，支持系统持续演进。

三、体系结构需求

体系结构需求工作是整个开发过程的起点。它包含两个主要任务：获取用户需求，以及标识系统中拟用的构件。

体系结构需求的获取通常来源于三个方面：质量目标（如性能、安全性）、系统的商业目标（如市场占有率、投资回报）以及系统开发人员的商业目标（如可维护性、可重用性）。标识构件则分三步完成：首先生成类图，然后对类进行分组，最后将类打包成构件。在架构需求评审中，审查重点包括：需求是否真实反映了用户的要求、类的分组是否合理、构件合并是否合理等。

四、体系结构设计

体系结构设计是承接需求并转化为具体结构模型的关键环节。其设计过程包含四个步骤：提出软件体系结构模型、映射构件、分析构件相互作用、以及产生体系结构设计评审。设计评审必须邀请独立于系统开发的外部人员参与，以保证评审的客观性和全面性。

五、体系结构文档化

文档化过程的主要输出结果是体系结构规格说明 和测试体系结构需求的质量设计说明书。前者详细描述系统的构件、接口及相互关系，后者则用于验证体系结构是否满足既定的质量需求。良好的文档化为后续的复审、实现和演化提供了可靠依据。

六、体系结构复审

当一个主版本的软件体系结构分析完成后，需要安排一次由外部人员（包括用户代表和领域专家）参加的复审。复审的核心目的是识别潜在的风险，及早发现体系结构设计中的缺陷和错误。必要时，可以搭建一个可运行的最小化系统（原型或骨架系统），用于评估和测试体系架构是否真正满足需求。

七、体系结构实现

体系结构的实现过程以复审通过的文档化体系结构说明书为基础。具体步骤包括：分析与设计、构件实现、构件组装、系统测试。体系结构说明书中明确定义了系统中构件与构件之间的关系。测试工作分为两个层次：单个构件的功能性测试，以及被组装应用后的整体功能和性能测试。只有两个层次的测试均通过，才能认定实现符合体系结构设计要求。

八、体系结构演化

软件系统在使用过程中会不断面临新的需求或环境变化，体系结构演化正是应对这一现实的手段。演化是指使用系统演化步骤修改已有应用，以满足新的需求。系统演化的标准步骤如下：

1. 需求变化归类
2. 制定体系结构演化计划
3. 实施构件变动
4. 更新构件之间的相互作用
5. 进行构件组装与测试
6. 组织技术评审
7. 得到演化后的体系结构

通过这种有序的演化过程，软件系统能够持续保持其体系结构的合理性和生命力。

结语

基于架构的软件开发方法提供了一套完整、可操作的开发框架。从需求获取到设计、文档化、复审、实现直至演化，每个阶段都有明确的输入、活动与输出。该方法强调外部评审、风险识别以及迭代细化，有效提升了大型复杂软件系统的开发质量与可维护性。对于希望构建健壮、可演化软件系统的组织而言，ABSD是一种值得深入实践的方法论。

基于架构的软件开发方法（ABSD）------从入门到实践

软件架构不是"画完就扔"的图纸，而是贯穿整个生命周期的核心资产

前言

在软件开发中，我们经常遇到这样的困境：需求不断变更，代码越写越乱，系统逐渐沦为"大泥球"。如何从一开始就抓住系统的"骨架"，让后续开发有章可循？基于架构的软件开发方法（Architecture-Based Software Development，ABSD） 给出了答案。

本文结合经典软件工程知识体系，系统梳理ABSD的核心概念、六大子过程以及实战要点。无论你是架构师、项目经理还是开发人员，都能从中获得启发。

---

一、什么是ABSD？

ABSD是一种以软件体系结构为核心的开发范式 。它从项目的总体功能框架明确开始------此时完整的需求可能尚未完成，通过自顶向下、递归细化的方式逐步构建系统。

1.1 ABSD的三个基础

基础	说明
功能的分解	将系统逐层拆解为更小的功能模块
通过选择体系结构风格来实现质量和商业需求	如分层、微服务、事件驱动等风格，满足性能、安全等非功能需求
软件模块的使用	强调可复用构件，提高开发效率

1.2 ABSD的核心特点

• 自顶向下、递归细化：每次迭代都有清晰的定义，降低设计随意性
• 需求未完成即可启动：不等待全部需求冻结，提前进行架构设计
• 外部评审贯穿始终：独立于开发团队的用户代表、领域专家参与复审

---

二、ABSDM开发模型：六个子过程

传统瀑布模型、原型模型在应对变化时效率较低。ABSDM模型（Architecture-Based Software Development Model）将开发划分为六个连续的子过程，形成一个支持持续演进的闭环：

体系结构需求 → 体系结构设计 → 体系结构文档化 → 体系结构复审 → 体系结构实现 → 体系结构演化

下面逐一展开。

2.1 体系结构需求

目标：获取用户需求 + 标识拟用构件

• 需求来源：质量目标（如性能、安全性）、系统商业目标（如市场占有率）、开发人员商业目标（如可维护性）
• 标识构件三步走：生成类图 → 对类进行分组 → 把类打包成构件
• 需求评审重点 ：
  • 需求是否真实反映用户要求？
  • 类的分组是否合理？
  • 构件合并是否合理？

2.2 体系结构设计

四个步骤：

1. 提出软件体系结构模型
2. 映射构件
3. 分析构件相互作用
4. 产生体系结构设计评审

⚠️ 重要原则：设计评审必须邀请独立于系统开发的外部人员参与，避免"自己审自己"的主观性。

2.3 体系结构文档化

主要输出两份文档：

• 体系结构规格说明：详细描述构件、接口及相互关系
• 质量设计说明书：用于测试体系结构需求是否满足

好的文档是后续复审、实现、演化的基石。

2.4 体系结构复审

• 参与者：用户代表 + 领域专家（外部人员）
• 目的：标识潜在风险，及早发现设计缺陷和错误
• 进阶做法 ：必要时搭建一个可运行的最小化系统（原型或骨架），用于实际评估和测试架构是否满足需要

2.5 体系结构实现

以复审通过的文档化说明书为基础，按以下流程进行：

分析与设计 → 构件实现 → 构件组装 → 系统测试

• 构件之间的关系已在体系结构说明书中明确定义
• 测试分为两个层次 ：
  • 单个构件的功能性测试（单元测试）
  • 组装后的整体功能和性能测试（集成测试、系统测试）

2.6 体系结构演化

需求永远在变，架构也需要随之演化。标准演化步骤为：

步骤	活动
1	需求变化归类
2	制定体系结构演化计划
3	实施构件变动
4	更新构件之间的相互作用
5	构件组装与系统测试
6	组织技术评审
7	得到演化后的体系结构

通过这种有序的演化，系统可以持续保持活力，而不会陷入"架构腐烂"。

---

三、一张图记住ABSD

┌─────────────────────────────────────────────────────────┐
│                    ABSD 六大子过程                       │
├──────────┬──────────────────────────────────────────────┤
│ 需求     │ 获取用户需求 + 标识构件（类图→分组→打包）      │
│ 设计     │ 建模→映射构件→分析交互→外部评审               │
│ 文档化   │ 规格说明 + 质量设计说明书                     │
│ 复审     │ 用户代表+领域专家参与，识别风险，搭建最小系统   │
│ 实现     │ 分析设计→构件实现→组装→系统测试               │
│ 演化     │ 需求归类→计划→变动→更新交互→测试→评审→新架构  │
└──────────┴──────────────────────────────────────────────┘

---

四、ABSD与传统开发方法的区别

对比维度	传统瀑布/原型	ABSD
架构设计时机	需求完整后开始	需求尚未完成时即可开始
迭代性	线性或松散迭代	递归细化，每一步定义清晰
评审参与	通常内部评审	强制外部人员（用户代表、领域专家）参与
文档化	有时被忽略	明确要求规格说明和质量设计说明书
演化支持	后期修改困难	有标准演化步骤，支持持续演进

---

五、实践建议

1. 不要等待完美需求：ABSD的精髓之一就是"在需求模糊时开始架构设计"，用架构来引导需求细化。
2. 外部评审是必须的，不是可选的：自己很难发现自己的盲点，用户和领域专家的视角至关重要。
3. 最小化原型验证：在复审阶段构建一个可运行的最小系统，比看文档100遍都有效。
4. 文档不是负担，而是资产：尤其当团队发生人员变动时，清晰的架构文档能救你一命。
5. 把演化当成常规流程：不要等到系统积重难返才重构，而是每次需求变化都走一遍演化步骤。

---

结语

基于架构的软件开发方法不是银弹，但它提供了一套可操作、可评审、可演化 的工程框架。从需求到设计，从文档到复审，从实现到演化，每一步都有明确的输入和输出。尤其值得强调的是：外部评审 和风险驱动的迭代细化，让ABSD在面对复杂系统时展现出独特的优势。

如果你的项目正面临以下问题：

• 需求频繁变更，代码越来越混乱
• 架构设计随意，团队理解不一致
• 系统难以维护，改动一处引发多处崩溃

不妨试一试ABSD的思路------从今天开始，给你的软件一个坚实的骨架。

---

#软件架构 #ABSD #系统设计 #软件工程

<!DOCTYPE html>
<html lang="zh-CN">
<head>
    <meta charset="UTF-8">
    <title>基于架构的软件开发方法 | 文章</title>
    <style>
        * {
            margin: 0;
            padding: 0;
            box-sizing: border-box;
        }

        body {
            background-color: #e2e6e9;
            font-family: 'Times New Roman', '宋体', SimSun, '微软雅黑', serif;
            padding: 40px 20px;
        }

        /* 整体纸张效果 */
        .paper {
            max-width: 1200px;
            margin: 0 auto;
            background-color: white;
            box-shadow: 0 8px 20px rgba(0,0,0,0.1);
            padding: 40px 30px;
        }

        /* 两栏布局 */
        .two-column {
            column-count: 2;
            column-gap: 40px;
            column-rule: 1px solid #ccc;
            text-align: justify;
            line-height: 1.5;
            font-size: 10.5pt;
        }

        /* 标题样式 */
        h1 {
            font-size: 22pt;
            text-align: center;
            margin-bottom: 10px;
            column-span: all;
            color: #1e3c5c;
        }

        .subtitle {
            text-align: center;
            font-size: 12pt;
            color: #4a6a8b;
            margin-bottom: 30px;
            border-bottom: 1px solid #aaa;
            padding-bottom: 12px;
            column-span: all;
        }

        h2 {
            font-size: 16pt;
            margin-top: 20px;
            margin-bottom: 10px;
            color: #2c5a7a;
            column-span: all;
            background-color: #f0f3f8;
            padding-left: 8px;
            border-left: 6px solid #2c5a7a;
        }

        h3 {
            font-size: 13pt;
            margin: 15px 0 8px 0;
            color: #3a6b92;
            column-span: all;
        }

        /* 表格样式 --- 带框线 */
        table {
            width: 100%;
            border-collapse: collapse;
            margin: 16px 0;
            font-size: 10pt;
            column-span: all;  /* 表格跨栏显示，避免断裂难看 */
            break-inside: avoid;
            page-break-inside: avoid;
        }

        th, td {
            border: 1px solid #333;
            padding: 8px 10px;
            vertical-align: top;
            background-color: #fff;
        }

        th {
            background-color: #eef4fc;
            font-weight: 600;
            text-align: center;
        }

        /* 列表样式 */
        ul, ol {
            margin-left: 20px;
            margin-bottom: 12px;
        }

        li {
            margin: 4px 0;
        }

        /* 引述或重点框 */
        .note {
            background-color: #f9f7e3;
            padding: 8px 12px;
            border-left: 4px solid #e6b422;
            margin: 12px 0;
            font-style: normal;
            column-span: all;
            break-inside: avoid;
        }

        /* 确保跨栏元素不被截断 */
        .no-break {
            break-inside: avoid;
            page-break-inside: avoid;
        }

        /* 针对打印/PDF优化 */
        @media print {
            body {
                background: white;
                padding: 0;
                margin: 0;
            }
            .paper {
                box-shadow: none;
                padding: 20mm;
                max-width: 100%;
            }
            .two-column {
                column-gap: 30px;
            }
            h2, h3, .note, table {
                break-inside: avoid;
            }
        }

        /* 用于小屏时临时取消双栏 */
        @media (max-width: 700px) {
            .two-column {
                column-count: 1;
                column-rule: none;
            }
        }

        footer {
            text-align: center;
            margin-top: 35px;
            font-size: 9pt;
            color: #555;
            column-span: all;
            border-top: 1px solid #ccc;
            padding-top: 15px;
        }
    </style>
</head>
<body>
<div class="paper">
    <h1>基于架构的软件开发方法</h1>
    <div class="subtitle">Architecture-Based Software Development (ABSD) 全面解析</div>

    <div class="two-column">
        <p><strong>摘要：</strong>基于架构的软件开发方法（ABSD）以软件体系结构为核心，从总体功能框架出发，在需求尚未完全明确时即开展设计。通过自顶向下、递归细化的方式降低随意性，并将开发过程划分为需求、设计、文档化、复审、实现和演化六个子过程。本文系统介绍ABSD的概念、三大基础、开发模型及每个子过程的关键活动，旨在为软件工程实践提供理论指导。</p>

        <h2>一、概述与基本概念</h2>
        <h3>1.1 体系结构的设计方法</h3>
        <p>ABSD从项目总体功能框架明确开始（需求尚未完成）。其三个基础为：功能的分解、通过选择体系结构风格来实现质量和商业需求、软件模块的使用。该方法有助于早期宏观把控，降低不确定性。</p>

        <h3>1.2 概念与术语</h3>
        <p>ABSD是自顶向下、递归细化的方法，每一次迭代都有清晰定义，有效降低体系结构设计的随意性。它强调逐层分解系统为更小的子系统或构件，并定义交互关系来满足功能与非功能需求。</p>

        <h2>二、基于体系结构的开发模型</h2>
        <p>传统模型（如瀑布模型）开发效率较低，适应性差。ABSDM模型将开发过程划分为六个连续子过程：<strong>体系结构需求 → 设计 → 文档化 → 复审 → 实现 → 演化</strong>，形成闭环，支持持续演进。</p>
        
        <!-- 表格框线示例：六大子过程 -->
        <table>
            <caption><strong>表1 基于体系结构的软件开发六大子过程</strong></caption>
            <thead>
                <tr><th>子过程</th><th>核心任务</th></tr>
            </thead>
            <tbody>
                <tr><td>体系结构需求</td><td>获取用户需求，标识构件（类图→分组→打包成构件）</td></tr>
                <tr><td>体系结构设计</td><td>提出模型、映射构件、分析相互作用、外部评审</td></tr>
                <tr><td>体系结构文档化</td><td>输出规格说明、质量设计说明书</td></tr>
                <tr><td>体系结构复审</td><td>外部人员（用户代表、领域专家）参与，识别风险，必要时搭建最小化系统测试</td></tr>
                <tr><td>体系结构实现</td><td>分析与设计→构件实现→构件组装→系统测试</td></tr>
                <tr><td>体系结构演化</td><td>需求变化归类→演化计划→构件变动→更新相互作用→组装测试→技术评审</td></tr>
            </tbody>
        </table>

        <h2>三、体系结构需求</h2>
        <p>需求工作包括获取用户需求及标识拟用构件。需求获取来自三个方面：<strong>质量目标、系统商业目标、开发人员商业目标</strong>。标识构件分三步：生成类图→对类分组→打包成构件。架构需求评审重点审查：需求是否真实反映用户要求、类分组是否合理、构件合并是否合理等。</p>

        <h2>四、体系结构设计</h2>
        <p>设计过程包含：提出软件体系结构模型→映射构件→分析构件相互作用→产生体系结构设计评审。设计评审必须邀请<strong>独立于系统开发的外部人员</strong>参与，确保客观性。</p>

        <h2>五、体系结构文档化</h2>
        <p>主要输出<strong>体系结构规格说明</strong>和<strong>测试体系结构需求的质量设计说明书</strong>。前者详细描述构件、接口及相互关系，后者验证质量需求。良好的文档化为复审、实现和演化提供依据。</p>

        <h2>六、体系结构复审</h2>
        <p>每个主版本分析之后安排由<strong>用户代表和领域专家</strong>参加的外部复审。目的：标识潜在风险，及早发现缺陷。必要时搭建可运行的最小化系统（原型）评估架构是否满足需要。</p>

        <h2>七、体系结构实现</h2>
        <p>实现以复审通过的说明书为基础，具体过程：分析与设计→构件实现→构件组装→系统测试。体系结构说明书中定义了构件间关系。测试包括单个构件的功能性测试及整体应用的功能与性能测试。</p>

        <h2>八、体系结构演化</h2>
        <p>软件系统需持续适应新需求。演化步骤为：<strong>需求变化归类→体系结构演化计划→构件变动→更新构件相互作用→构件组装与测试→技术评审→演化后的体系结构</strong>。通过有序演化保持体系结构合理性。</p>

        <!-- 另一个带框线的表格：演化步骤展示 -->
        <table>
            <caption><strong>表2 体系结构演化的标准步骤</strong></caption>
            <thead><tr><th>步骤序号</th><th>活动内容</th></tr></thead>
            <tbody>
                <tr><td>1</td><td>需求变化归类</td></tr>
                <tr><td>2</td><td>制定体系结构演化计划</td></tr>
                <tr><td>3</td><td>实施构件变动</td></tr>
                <tr><td>4</td><td>更新构件之间的相互作用</td></tr>
                <tr><td>5</td><td>构件组装与系统测试</td></tr>
                <tr><td>6</td><td>组织技术评审</td></tr>
                <tr><td>7</td><td>得到演化后的体系结构</td></tr>
            </tbody>
        </table>

        <div class="note">
            <strong>要点总结：</strong> ABSD方法强调外部评审、风险识别、迭代细化，有效提升大型复杂软件系统的开发质量与可维护性。六大子过程形成完整生命周期，尤其关注体系结构的可演化能力。
        </div>

        <h2>结语</h2>
        <p>基于架构的软件开发方法提供了一整套可操作的开发框架。从需求获取到设计、文档化、复审、实现直至演化，每个阶段均有明确的输入、活动与输出。该方法通过外部评审和风险提前识别，显著提高大型系统的质量与适应性。对于希望构建健壮、可演化软件系统的组织，ABSD是一种值得深入实践的方法论。</p>
    </div> <!-- 两栏结束 -->
    <footer>来源：软件工程架构设计知识体系 · 基于架构的软件开发方法（ABSD）</footer>
</div>
</body>
</html>

[1](https://chat.deepseek.com/share/h4xnwf9mv0s83fvk8e)