【软考架构】第七章 系统架构设计基础知识-7.2基于架构的软件开发方法：Architecture-Based Software Design,ABSD

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

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

基于体系结构的软件设计（ABSD）是由体系结构驱动的开发方法，其核心是通过商业（业务）、质量和功能需求的组合驱动设计过程。它强调采用视角和视图来描述软件架构，采用用例和质量属性场景来描述需求。

ABSD的显著特点是：设计活动可在需求抽取和分析未完成时启动，并与需求活动并行进行（尤其适用于产品线系统或长期运行系统，需快速启动设计）。

ABSD方法的3个基础：

1. 功能分解：采用基于模块的内聚和耦合技术；
2. 体系结构风格选择：通过选择合适的风格满足质量和商业需求；
3. 软件模板使用：利用已有软件系统的结构模板。

ABSD是递归且迭代的，每一步骤定义清晰，确保体系结构始终清晰，降低设计的随意性。

7.2.2 概念与术语

1. 设计元素

ABSD采用自顶向下、递归细化的方式定义软件体系结构，设计元素分层如下：

• 顶层：系统分解为若干概念子系统和一个或多个软件模板；
• 下层：概念子系统进一步分解为概念构件和附加软件模板，最终细化到可生成软件构件和类。

2. 视角与视图

体系结构需从不同视角分析其属性，通过视图（如逻辑视图、进程视图、实现视图、配置视图）全方位描述设计：

• 逻辑视图：记录设计元素的功能和概念接口，定义其在系统中的角色（如功能、性能）；
• 动态视图（如进程视图）：展示并发行为，判断系统行为特性。

3. 用例和质量场景

• 用例：捕获功能需求，是系统为用户提供结果值的功能点；
• 质量场景：捕获非功能需求（如变更、性能、可靠性、交互性），包括预期场景（如用户量年增10%的影响）和非预期场景（如用户量年增100%的影响，用于定义设计边界）。

7.2.3 基于体系结构的开发模型

ABSD将开发过程划分为6个子过程，区别于传统模型（架构设计位于需求分析后），强调架构驱动以提升效率和重用性：

1. 体系结构需求；2. 体系结构设计；3. 体系结构文档化；4. 体系结构复审；5. 体系结构实现；6. 体系结构演化。

7.2.4 体系结构需求

需求是用户对系统功能、性能、设计约束等的期望，受技术环境和设计师经验影响，过程包括：

1. 需求获取

需求来源包括系统的质量目标、商业目标和开发人员的商业目标，需同时获取：

• 功能需求：定义开发人员需实现的功能，支持用户完成任务；
• 非功能需求：软件质量属性（如性能、可靠性）。

2. 标识构件

生成系统初始逻辑结构，分3步：

1. 生成类图（可通过CASE工具如Rational Rose自动生成）；
2. 类分组：按隔离性、概括关联、聚合/合成关联等标准分组，简化结构；
3. 打包构件：将类簇打包为构件，可进一步合并为更大构件。
   

3. 架构需求评审

由分析人员、客户、设计人员、测试人员组成评审组，审查内容包括：需求是否反映用户要求、类分组及构件合并是否合理，必要时在“需求获取—标识构件—评审”间迭代。

7.2.5 体系结构设计

设计是迭代过程，步骤如下：

1. 提出软件体系结构模型：选择合适的体系结构风格，建立理想化模型（为实现和演化设定目标）；
2. 映射构件到架构：将需求阶段标识的构件映射到体系结构，形成中间结构；
3. 分析构件相互作用：明确构件间的关系和交互，确保集成可行性；
4. 产生软件体系结构：在中间结构基础上精化，形成最终架构；
5. 设计评审：邀请外部人员（独立于开发）评审架构合理性。

7.2.6 体系结构文档化

体系结构多为抽象概念（如“层”），需文档化以指导实现，输出两个核心文档：

• 体系结构规格说明：形式化描述需求模型构件，作为用户与开发者的协约；
• 质量设计说明书：测试体系结构需求的质量目标。

文档需从使用者角度编写，分发至所有相关开发人员，并确保版本最新，其完整性和质量是架构成功的关键。

7.2.7 体系结构复审

设计、文档化和复审是迭代过程，复审需：

• 邀请外部人员（用户代表、领域专家）参与；
• 搭建最小化可运行系统，评估架构是否满足需求、识别技术和协作风险；
• 审查重点：需求满足度、质量需求体现、层次清晰度、构件划分合理性、文档明确性等。

7.2.8 体系结构实现

基于复审后的文档，将架构转化为实体系统，步骤如下：

1. 遵循架构说明书中的结构性设计决策，按规定分割构件并定义交互方式；
2. 从构件库查找符合接口约束的构件，或开发新构件；
3. 通过组装工具将构件组装，完成系统合成；
4. 测试：包括单个构件功能测试和整体系统功能、性能测试。

7.2.9 体系结构的演化

应对需求变化（如开发中或移植后的需求变动），演化过程包括：

1. 需求变化归类：将变动需求与已有构件对应，标记需新增的构件；
2. 制订演化计划：指导后续开发；
3. 修改/增删构件：根据归类结果调整构件，进行功能测试；
4. 更新构件相互作用：调整控制流以适配构件变化；
5. 组装与测试：合成新体系结构，测试整体功能和性能；
6. 技术评审：确认演化后架构是否满足新需求，必要时迭代调整，最终将修改集成到原有架构。

ABSD方法通过架构驱动的迭代过程，平衡需求动态性与设计稳定性，提升软件系统的可重用性、可维护性和开发效率。

加深理解

1. “由体系结构驱动” (Architecture-Driven)

这是ABSD与传统功能驱动开发最根本的区别。

• 传统方法（如瀑布模型）：通常是功能点列表驱动。开发团队根据需求文档逐个实现功能，架构往往是随着功能实现而自然形成的，或者事后补上的，缺乏前瞻性和统一规划。
• ABSD方法：首先关注的是如何设计一个能够承载所有功能、并满足各种非功能性需求（质量属性）的坚实基础——即软件架构。这个架构是一个蓝图，它：
  • 指导开发：定义了系统由哪些组件组成、组件之间如何交互、遵循什么规则。
  • 约束开发：确保所有开发人员都在同一个框架内工作，保证系统的一致性和完整性。
  • 支持迭代：架构先于详细设计和实现，并且在迭代过程中可以围绕架构进行扩展和修改，而不是推倒重来。

简单来说，ABSD认为“构建什么（功能）”和“如何构建（架构）”同样重要，并且“如何构建”是成功实现“构建什么”的关键保障。

2. “采用视角和视图来描述软件架构” (Perspectives and Views)

这是描述和沟通复杂软件架构的核心手段。由于软件架构涉及众多利益相关者（如项目经理、客户、开发人员、测试人员、运维人员），他们关心的角度各不相同。

• 视图（View）：是从某一特定角度观察到的系统结构的描述。它代表了系统某个方面的设计决策。常见的视图有：

  • 逻辑视图：描述系统的功能需求，即系统应该提供给用户的业务功能。包含类、包、子系统等。面向分析师和设计师。
  • 开发视图：描述程序的静态组织结构（如模块、库、组件）及其管理。面向开发人员和构建管理员。
  • 进程视图：描述系统的并发、同步、通信等运行时行为。面向集成人员和性能优化人员。
  • 物理视图：描述软件如何映射到硬件上，涉及网络布局、服务器部署等。面向系统和运维工程师。
  • 场景（用例视图）：通过重要的用例场景将各种视图串联起来，验证其有效性。面向所有利益相关者。

• 视角（Perspective）：有时也称为“非功能性视角”，它是横切多个视图的通用质量和约束要求。例如“可维护性”视角会影响到逻辑视图（高内聚、低耦合的设计）、开发视图（清晰的模块划分）、进程视图等多个方面。其他常见视角包括安全性、性能、可伸缩性、可用性等。

比喻：描述一栋建筑时，结构视图是承重墙和梁柱，电气视图是电线走向，管道视图是水管布局。而节能视角则会同时影响到三个视图（用什么材料、如何布线和用什么设备）。

3. “采用用例和质量属性场景来描述需求” (Use Cases & Quality Attribute Scenarios)

这是ABSD捕获需求的独特方式，它明确区分了两种不同类型的需求。

• 用例（Use Cases）：描述功能性需求。它们以用户（参与者）与系统的交互为主线，回答“系统做什么”的问题。例如：“用户成功登录系统”、“用户下单支付”。它们是驱动功能设计的基础。

• 质量属性场景（Quality Attribute Scenarios, QAS）：描述非功能性需求（即质量属性）。它们比简单的“系统性能要高”这种模糊描述要精确得多。一个质量属性场景通常包含六个部分：

  1. 刺激源（Source）：谁/什么发起了这个刺激？（例如，一个并发用户）
  2. 刺激（Stimulus）：发生了什么？（例如，提交一个搜索请求）
  3. 环境（Environment）：刺激发生时，系统处于什么状态？（例如，系统正常运行时）
  4. 构件（Artifact）：哪个部分被刺激了？（例如，搜索服务组件）
  5. 响应（Response）：系统应该如何响应？（例如，在2秒内返回搜索结果）
  6. 响应度量（Response Measure）：如何量化评估响应？（例如，95%的请求在2秒内完成）

  示例（可用性场景）：

  • 刺激源：主数据库服务器
  • 刺激：发生硬件故障宕机
  • 环境：系统正常运行时
  • 构件：系统中的事务处理模块
  • 响应：系统自动切换到备用数据库，期间未提交的事务回滚，丢失的数据少于1条。
  • 响应度量：切换时间不超过30秒。

通过这种方式，质量需求变得具体、可测试、可验证，并为架构设计提供了明确的决策依据（例如，为了满足上述场景，架构必须设计为主从备份模式）。

ABSD的工作流程简述

基于以上概念，一个典型的ABSD过程如下：

1. 需求分析：同时收集用例（功能）和质量属性场景（非功能）。
2. 架构设计：
   • 根据最关键的质量属性场景（如高并发、高安全）做出主要的架构风格选择（如微服务、分层架构）。
   • 设计组件的划分、职责和交互关系，形成不同的视图。
3. 架构实现：根据设计好的架构视图，组织团队进行开发和集成。
4. 架构验证：使用用例和质量属性场景来评估和验证架构设计是否满足需求（通常通过原型、建模或评审会）。
5. 迭代：根据验证反馈调整架构和设计，重复上述过程。

总结

您对ABSD的总结非常到位。ABSD是一种前瞻性的、以架构为中心的设计方法，它通过：

• 视角和视图为复杂的架构提供了结构化的描述和沟通语言。
• 用例和质量属性场景将模糊的需求（尤其是非功能性需求）转化为具体、可衡量的设计目标。

这种方法极大地降低了大型复杂系统的开发风险，确保了系统不仅功能正确，更在性能、安全、可靠性等质量属性上达到预期目标。