软件架构师-第十一章 软件架构设计

软件架构设计

软件架构的概念⭐⭐⭐

软件架构的概念：

架构的本质

• 高级抽象：软件架构对软件系统的结构（组件组成）、行为（组件交互逻辑）、属性（系统特性，如性能、安全性）进行高层次抽象，忽略细节，聚焦整体框架。
• 惯用模式与约束：软件架构风格是特定领域中反复使用的成熟模式（如 MVC、微服务），同时通过定义 **“词汇表”（组件、交互等术语）和 “约束”（组件关系规则、设计原则）**规范系统构建。

架构的作用

• 交流媒介：为项目干系人（如开发人员、客户、管理者）提供统一沟通框架，确保对系统设计的理解一致。
• 可复用与质量预测：作为可传递、可复用的模型，通过分析架构能提前预判软件的质量（如可维护性、扩展性）。
• 简化迭代与支持培训：清晰的架构让系统修改、推理更简单，支持循序渐进的原型设计（分阶段实现架构），还能作为团队培训基础，帮助成员快速理解系统设计。

架构的所处位置

• 概念等同：明确 “软件架构 = 软件体系结构”，二者是同一概念的不同表述。
• 开发阶段关系：
  • “需求分析 — 架构 — 软件设计” 的流程，其中 “架构” 处于 “业务”（需求分析）与 “技术”（软件设计）的 “鸿沟” 之间，扮演桥梁角色，衔接业务需求与技术实现。
• 架构设计本质：强调 “架构设计就是需求分配”，即把满足业务需求的职责，合理分配到软件系统的各个组件上，确保需求通过技术组件落地实现。

软件架构的发展历程

1. 无架构阶段：对应早期使用汇编语言开发的时期，此时软件规模小，开发过程缺乏对架构的系统性设计，处于 “无架构” 状态。
2. 萌芽阶段：随着软件复杂度提升，开始关注程序结构设计，对程序内部结构的规划初步体现架构思维，标志着软件架构概念的萌芽。
3. 初级阶段：引入统一建模语言（UML），通过标准化图形化工具（如类图、时序图等）对软件结构进行建模，使架构设计更规范，进入初级发展阶段。
4. 高级阶段：采用4+1 视图方法（逻辑视图、进程视图、物理视图、开发视图 + 用例视图），从多维度全面描述软件架构，支持更复杂系统的设计，代表架构发展的高级阶段。

整个历程体现了软件架构从无到有、从简单到系统化的演进过程，对应技术工具与设计方法的不断升级。

软件架构的 “4+1” 视图

• “架构的‘4+1’视图”

  • 核心视图与关注角色：

    1. 逻辑视图：面向最终用户，聚焦功能需求，描述系统的逻辑结构与功能实现。
    2. 开发视图：针对编程人员，关注软件管理（如代码组织、模块划分），体现开发层面的架构设计。
    3. 进程视图：系统集成人员视角，关注性能、可扩充性、吞吐量等，涉及线程、进程、并发等设计。
    4. 物理视图：系统工程人员视角，聚焦系统拓扑、安装、通信等，描述软件到硬件的物理映射。

  • “1” 的核心 —— 场景：作为各视图的关联枢纽，通过场景整合不同视图，体现系统在实际应用中的交互逻辑。

• “UML 的‘4+1’视图”

  • 视图构成：
    1. 逻辑视图：系统分析 / 设计人员视角，关注类与对象，体现系统逻辑结构。
    2. 实现视图（开发视图）：程序员视角，对应物理代码文件和组件，关注软件实现细节。
    3. 进程视图：系统集成人员视角，聚焦线程、进程、并发等运行时特性。
    4. 部署视图：系统 / 网络工程师视角，描述软件到硬件的部署映射。
    5. 用例视图（“1”）：核心枢纽，以需求分析模型为基础，代表最终用户视角，通过用例整合功能需求，串联其他视图。

• “架构的‘4+1’视图” 与“UML 的‘4+1’视图” 的对应关系：

  • 逻辑视图：

    • 均关注系统功能逻辑。
    • 左侧面向最终用户的功能需求；
    • 右侧是系统分析、设计人员视角，通过类与对象体现逻辑结构。

  • 开发视图 ↔ 实现视图：

    • 左侧 “开发视图” 聚焦编程人员的软件管理（如代码组织）；
    • 右侧 “实现视图” 对应程序员视角，关注物理代码文件和组件实现。

  • 进程视图：

    • 两侧一致，均服务于系统集成人员，关注性能、可扩充性、线程 / 进程 / 并发等运行时特性。

  • 物理视图 ↔ 部署视图：

    • 左侧 “物理视图” 侧重系统工程人员关注的系统拓扑、安装、通信；
    • 右侧 “部署视图” 描述软件到硬件的映射，本质均涉及物理层面的架构设计。

  • 场景 ↔ 用例视图：

    • 左侧 “场景” 作为视图关联枢纽；
    • 右侧 “用例视图” 代表最终用户需求分析模型，是 “1” 的核心，二者均用于整合功能需求，串联其他视图。

基于架构的软件开发⭐⭐⭐⭐

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

ABSD 方法的驱动核心

• ABSD 方法以 架构驱动 为核心，强调软件架构设计由 业务需求、质量需求、功能需求 三者的组合共同驱动，而非单一需求主导。

ABSD 方法的三个基础

• 功能分解：采用基于模块的 内聚和耦合技术，将系统功能拆解为可管理的模块，确保模块独立性与协作性。
• 架构风格选择：通过选取合适的 架构风格（如 MVC、微服务等），实现质量需求（如性能、可维护性）和业务需求的落地。
• 软件模板使用：借助标准化的软件模板，加速开发过程，提升架构设计的规范性与复用性。

视角与视图

• 延续 “不同视角对应不同视图” 的理念（如 “4+1” 视图），从多元角度（用户、开发人员、工程师等）检查架构，形成多维度的视图描述，确保架构全面性。

需求捕获方式

• 用例：用于捕获 功能需求，明确系统 “做什么”，如用户交互流程、功能模块定义。
• 特定场景：用于捕获 质量需求，通过模拟实际使用场景（如高并发、容错场景），验证系统性能、可靠性等质量属性。

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

核心要点

• 软件重用：ABSD 通过标准化架构设计与文档，促进组件复用，提升开发效率。
• 文档关键作用：文档完整性和质量是架构成功的核心，直接影响团队协作与系统实现。

开发流程（详情如下）

1. 架构需求：确定业务、功能、质量等需求，为后续设计奠定基础。
2. 架构设计：根据需求设计系统结构、组件划分及交互逻辑。
3. 架构文档化：
   • 输出架构规格说明和测试架构需求的质量设计说明书。
   • 强调文档编写需从使用者角度出发，分发给所有开发人员并保证实时更新。
4. 架构复审：审查架构文档，识别潜在风险，发现设计缺陷与错误，保障架构质量。
5. 架构实现：依据设计与文档完成代码开发，实现软件架构。
6. 架构演化：根据需求变更或迭代，优化调整架构，支持软件持续发展。

• 架构需求

  1. 需求获取：从 “需求库” 中提取业务、功能、质量等需求，作为开发基础。

  2. 标识构件：

     1. 生成类图：通过类图描述系统的类及关系。
     2. 对类分组：按功能或特性将类划分为不同组。
     3. 打包成构件：将分组后的类整合为可复用的构件，完成构件标识。

  3. 需求评审：对需求获取及构件标识结果进行审查，确保需求准确性与构件合理性。

• 架构设计

  1. 提出架构模型：基于需求，设计系统整体架构模型。

  2. 映射构件：将需求过程中标识的构件，映射到架构模型中，明确构件位置与职责。

  3. 分析构件相互作用：研究构件间的交互逻辑、数据流动及协作规则。

  4. 产生架构：整合上述步骤，形成完整的软件架构设计。

  5. 设计评审：对架构设计进行审查，评估合理性、可行性，识别潜在问题。

• 架构实现

  1. 输入基础：以 “复审后的文档化的架构” 为起点，确保架构设计经过审查验证。

  2. 分析与设计：基于构件库中的可复用构件，进行系统分析与详细设计。

  3. 构件实现：开发具体构件，完成代码编写与功能实现。

  4. 构件组装：将实现的构件按架构设计进行集成组装。

  5. 系统测试：对组装后的系统进行测试，验证功能与质量是否达标。

  6. 架构演化：测试完成后，为应对后续需求变化，进入架构演化阶段。

• 架构演化

  1. 需求变化归类：对需求变更进行分类，明确变化类型（如功能、性能调整）。

  2. 制定演化计划：根据需求变化，规划架构调整方案与实施步骤。

  3. 构件变动：从构件库获取相关构件，修改或新增构件以适应变化。

  4. 更新构件交互：调整构件间的相互作用关系，确保架构逻辑一致性。

  5. 构件组装与测试：重新组装变动后的构件，进行测试验证。

  6. 技术评审：对演化后的架构进行技术审查，确认合理性。

  7. 输出结果：形成 “演化后的架构”，完成本轮迭代，支持系统持续发展。

软件架构的风格⭐⭐⭐⭐⭐

架构风格定义

• **明确架构风格的作用：**定义了描述系统的 术语表，以及指导构建系统的 规则集合，是软件架构设计的重要依据。

五大软件架构风格及子风格

• 数据流风格（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 步处理、第 2 步处理…… 第 N 步处理 的分步处理过程。前一步的处理结果作为后一步的输入，体现 “数据驱动” 的核心特点。
• 核心机制：各处理步骤间通过数据传递衔接，强调数据在流程中的流动与处理。

数据流风格的特点

• 优点：
  1. 松耦合：符合高内聚低耦合原则，模块独立性强；
  2. 重用性 / 可维护性好：模块功能单一，便于复用和维护；
  3. 可扩展性：通过标准接口适配，易于扩展新功能；
  4. 隐蔽性好：内部实现细节对外部透明；
  5. 支持并行：部分处理步骤可并行执行。
• 缺点：
  1. 交互性较差：侧重数据单向流动，人机交互能力弱；
  2. 复杂性高：多步骤处理增加系统复杂度；
  3. 性能较差：每个处理环节（如过滤器）需解析和合成数据，消耗资源。
• 典型实例：
  • 传统编译器：按词法分析、语法分析等流程处理代码；
  • 网络报文处理：对网络数据按步骤解析、转换。

数据流风格子分类

• 批处理序列：
  • 处理特点：针对 大量整体数据 进行一次性处理，处理过程 无需用户交互，强调数据整体输入与输出。
• 管道 - 过滤器：
  • 处理特点：处理 流式数据（数据连续流动），用户交互性 较弱，通过管道传输数据，过滤器对数据进行分阶段处理，符合数据流风格 “数据驱动” 的特性。

调用 / 返回风格

基础交互流程

• 主函数调用子函数，子函数完成任务后，将执行结果返回给主函数，体现模块化的控制流转。
• 提升软件的模块化程度，使程序结构更清晰，便于开发与维护。

调用 / 返回风格的子风格

• 主程序 / 子程序（面向过程）：典型的面向过程编程模式，程序以主程序为中心，通过调用子程序实现功能，如 C 语言中的函数调用体系。

• 面向对象：对象的方法调用：在面向对象编程中，通过对象调用其内部方法（如 Java、Python 中类的方法调用），本质也是调用 / 返回逻辑。

• 分层：层与层之间的方法调用：软件分层架构中，上层模块调用下层模块的方法，下层处理后向上返回结果，实现分层解耦（如网络协议栈的分层调用）。

  • 结构设计：以同心圆形式呈现分层结构，从内到外依次为 核心层（最内层基础支撑）、基本工具（中间层工具支持）、用户系统（最外层用户交互层）。

  • 交互方式：通过 过程调用 实现层间交互，底层（如核心层）为上层（如用户系统）提供功能支持，体现分层架构中 “下层服务上层” 的逻辑。

  • 优缺点及特点

    • 优点：

      1. 重用性好：只要接口不变，层内构件可复用在其他系统；
      2. 可维护性好：分层结构清晰，便于定位和修改问题；
      3. 可扩展性强：支持递增设计，方便新增功能或扩展层次。

    • 缺点：

      1. 分层适配难：并非所有系统都适合分层设计；
      2. 抽象方法难寻：难以定义合适、准确的层次抽象规则；
      3. 高耦合实现难：层间耦合度高时，系统实现和维护难度大。

    • 特点：

      • 各层组件形成不同功能级别的 “虚拟机”，每层封装特定功能；
      • 多层协同工作，且上层使用下层功能时，无需关注底层实现细节（实现透明）。

独立构件风格

• 交互流程：

  • 主函数触发事件，将请求交给 事件管理机制（中间协调组件）；
  • 事件管理机制通知 子函数 执行任务，子函数完成后通过事件管理机制返回执行结果给主函数。

• 优缺点及特点：

  • 优点

    • 松耦合：构件之间不直接交互，依赖度低，降低了修改某一构件对其他构件的影响。

    • 重用性 / 可修改性 / 可扩展性好：由于松耦合特性，构件可独立复用；新增功能或修改构件时，对系统整体影响小，便于扩展和维护。

  • 缺点

    • 控制缺失：构件触发事件时，无法确定其他构件是否响应，也无法保证注册过程的调用顺序，导致系统控制逻辑不明确。

    • 数据交换问题：构件间通过事件交互，可能引发数据传递不顺畅或格式不兼容等问题。

    • 正确性推理困难：过程语义依赖事件触发的上下文约束，难以对系统行为的正确性进行清晰推理。

  • 特点

    • 系统整体性：由多个子系统构成统一整体，围绕共同目标协作。

    • 子系统主从关系：子系统有主从之分，分工明确。

    • 独立事件机制：每个子系统具备独立的事件收集和处理机制，实现事件驱动的交互逻辑。

虚拟机风格

子风格

• 解释器：
  • 优点：能够灵活应对自定义场景，支持个性化规则的实现。
  • 缺点：系统复杂度较高，设计与维护难度较大。
  • 适合领域：适用于需要 “自定义规则” 的场景，如特定领域的语言解释或灵活规则处理。
  • 核心组件
    • 解释器引擎：作为处理核心，负责解析和执行程序指令，连接各模块交互。
    • 程序执行的当前状态：接收输入，记录程序运行时的状态，与解释器引擎双向交互，反馈处理进展。
    • 被解释执行的程序：提供待执行的指令和数据，由解释器引擎调用。
    • 解释器引擎的内部状态：存储解释器运行的中间状态，支持指令执行时的数据获取与存储。
    • 存储器：负责数据的存储与读取，为程序执行和解释器引擎提供数据支持。
  • 交互流程
    • 输入与状态处理：输入数据进入 “程序执行的当前状态”，解释器引擎从中获取信息。
    • 指令与数据处理：解释器引擎从 “被解释执行的程序” 中选择指令和数据，结合 “解释器引擎的内部状态” 进行处理。
    • 数据存储与输出：通过存储器完成数据的获取 / 存储；处理结果通过 “计算状态机” 输出，形成完整的执行闭环。
• 规则为中心：
  • 特点：在解释器的基础上增加经验规则，结合规则推理与解释执行。
  • 适合领域：适用于专家系统，例如基于规则的知识推理系统，利用经验规则处理专业领域问题。
  • 系统构成:基于规则的系统由四大模块组成：
    • 规则集：存储一系列预设的规则，是系统决策的逻辑基础。
    • 事实集：包含已知的事实数据，与规则集共同构成知识库。
    • 规则解释器：负责解析规则、处理数据，驱动系统执行逻辑。
    • 规则 / 数据选择：从规则集和事实集中筛选匹配的规则与数据，传递给规则解释器。
    • 工作内存：存储输入数据，接收规则解释器处理后更新的数据，是数据交互的核心区域。
  • 交互流程
    • 输入与数据存储：外部数据输入至工作内存，作为触发系统运行的初始数据。
    • 规则与数据匹配：工作内存的数据触发规则 / 数据选择模块，从知识库（规则集、事实集）中筛选匹配的规则和事实。
    • 规则解释执行：规则解释器获取被选择的规则和数据，执行逻辑处理，更新工作内存中的数据。
    • 输出结果：处理后的结果通过规则解释器输出，完成一次规则驱动的流程。
  • 应用领域
    • 该架构风格常用于 人工智能领域（如专家系统）和 决策支持系统（DSS），通过规则匹配与逻辑推理，实现自动化决策或问题求解。

仓库风格

仓库风格核心模型

• 数据为中心：“数据” 作为核心仓库，周围多个构件均围绕数据进行交互（读取、修改等操作）。构件不直接彼此通信，而是通过共享数据仓库间接协作，体现 “以数据为中心” 的架构特点。
• 仓库风格通过集中化的数据管理，实现构件间的松耦合，适用于需要数据共享、多模块协作的软件系统。

仓库风格的子分类（右图）

• 数据库系统：典型的仓库风格应用，通过数据库存储数据，多个模块（构件）基于数据库进行数据操作。

• 黑板系统：用于需要知识推理、多模块协作的场景，如语音识别、知识推理。不同组件通过 “黑板”（共享数据区）交换信息，协作完成任务。

  • 架构核心

    • 黑板（共享数据）：作为系统的中心枢纽，存储共享数据，是各组件交互的核心载体。所有知识源通过黑板读取或写入数据，实现间接协作。

  • 组件与交互

    • 知识源：围绕黑板的多个模块（如不同功能组件），负责提供专业知识或处理能力。知识源从黑板获取数据，执行计算或推理后，再将结果写回黑板。

  • 数据操作路径：

    • 直接存取：知识源可直接对黑板数据进行读取或存储操作。
    • 内存交互：黑板数据与内存关联，支持数据的临时存储与快速访问。
    • 计算驱动：知识源基于黑板数据执行计算任务，计算结果反馈至黑板，形成数据更新。

  • 应用特性

    • 该架构适用于需要多模块协作的场景（如语音识别、知识推理），通过共享黑板数据，实现知识源之间的松耦合交互，整合不同模块的能力完成复杂任务。

  • 优点

    • 可更改性与可维护性：系统结构清晰，便于修改和维护；
    • 知识源重用：知识源（模块）具备独立性，可重复利用；
    • 容错性和健壮性：多知识源协作机制提升系统容错能力，增强稳定性。

  • 缺点

    • 测试与设计挑战：测试难度大，难以保证最优解决方案，且控制策略设计困难；
    • 效率与开发问题：执行效率低，开发复杂度高，缺乏高效并行处理机制。

  • 特点

    • 延续仓库风格 “以数据为中心” 的特性，通过中心数据（黑板）触发业务逻辑部件（知识源）的协作。

• 超文本系统：以超文本数据为中心，各组件围绕超文本内容（如网页链接、文档结构）进行展示、跳转等交互。

C2 风格

架构组成

• 构件：独立功能模块（如 “构件” 框），是系统功能的实现单元。
• 连接件：充当构件间交互的中介，负责传递消息或协调交互。

C2 架构基本规则

• 构件与连接件的结构：构件和连接件均具备 “顶部” 和 “底部” 两个接口。
• 连接约束：
  • 构件顶部连接到连接件底部，构件底部连接到另一连接件顶部，禁止构件直接互连。
  • 连接件可与任意数量的构件、连接件连接。
  • 两个连接件直接连接时，必须遵循 “一个连接件底部→另一个连接件顶部” 的规则。

风格特点

• 通过严格的层次化连接规则，实现构件间的松耦合，便于系统扩展与维护，适用于需要灵活组装、动态调整的软件系统（如交互式应用、分布式系统）。

Model Driven Architecture（MDA，模型驱动架构）

MDA 的基础定义

• Model（模型）：对客观事物的抽象表示，用于提炼系统关键特征与逻辑。
• Architecture（架构）：定义系统的构成要素（部件、连接件）及其交互约束的规则，明确系统组织方式。

Model-Driven（模型驱动）的内涵

• 指通过模型驱动完成软件全生命周期活动，包括 分析、设计、构建、部署、维护 等，以模型为核心驱动软件开发过程。

MDA 的起源

• 源于 “分离系统规约和平台实现” 的思想，即通过模型抽象系统核心逻辑，使其独立于具体平台（如操作系统、技术框架），降低平台依赖。

MDA 的主要目标

• Portability（可移植性）：模型可适配不同平台，减少重复开发。
• Interoperability（互通性）：支持不同系统或模块间的交互与集成。
• Reusability（可重用性）：模型可在多个项目或场景中复用，提升开发效率。

MDA 的 3 种核心模型

• 平台独立模型（PIM）：
  具有高抽象层次，独立于任何实现技术（如编程语言、框架），关注系统核心业务逻辑，不涉及具体平台细节。
• 平台相关模型（PSM）：
  针对特定实现技术（如 Java、Web 平台）设计，使用该技术的实现构造描述系统。PIM 可转换为一个或多个 PSM，适配不同平台。
• 代码（Code）：
  用源代码对系统的具体描述，是开发的最终产物。每个 PSM 通过转换工具生成对应的代码。

模型转换流程

• PIM ↔ PSM（映射）：
  通过 “变换工具” 实现 PIM 与 PSM 的转换。PIM 作为抽象起点，经映射生成适配特定平台的 PSM。
• PSM → Code：
  再次使用变换工具，将 PSM 转换为可执行的源代码，完成从模型到实现的落地。

题目与答案整理1：

• 题目：Java 程序可以做到 “一次编写，到处运行”，从架构风格上看符合（ ）风格的特点。
  答案：虚拟机
  思路：Java 依赖虚拟机（如 JVM）屏蔽硬件差异，实现跨平台运行，符合虚拟机风格通过中间层解耦代码与硬件的特点。
• 题目：在网络通信中，进行包的解析，一般先进行包头的分离，然后进行报文解析及后续处理，根据这一特点，选用（ ）风格最合适。
  答案：数据流（管道 - 过滤器）
  思路：包解析过程中，数据依次经过包头分离、报文解析等处理模块，如同数据流通过 “管道 - 过滤器”，每个过滤器（模块）处理特定环节，是数据流风格中管道 - 过滤器架构的典型应用。
• 题目：某公司欲开发一个基于图形用户界面的集成调试器。该调试器的编辑器和变量监视器可以设置调试断点。当调试器在断点处暂停运行时，编辑程序可以自动卷屏到断点，变量监视器刷新变量数值。针对这样的功能描述，采用（ ）的架构风格最为合适。
  答案：隐式调用
  思路：断点触发编辑器卷屏、变量监视器刷新，组件间通过事件隐式交互，而非直接调用，符合隐式调用风格的事件驱动特性。
• 题目：某游戏公司欲开发一个大型多人即时战略游戏，游戏设计的目标之一是能够支持玩家自行创建战役地图，定义游戏对象的行为和之间的关系。针对该目标，公司应该采用（ ）架构风格最为合适。（四选一：管道 - 过滤器、隐式调用、主程序 - 子程序、解释器）
  答案：解释器
  思路：支持玩家自定义地图规则、游戏对象行为，需灵活解释执行自定义内容，解释器风格能适配这种 “自定义规则处理” 的需求。
• 题目：某公司承接了一个开发家用空调自动调温器的任务，调温器测量外部空气温度，根据设定的期望温度控制空调的开关。根据该需求，公司应采用（ ）架构风格最为合适。（四选一：解释器、过程控制、分层、管道 - 过滤器）
  答案：过程控制
  思路：调温器实时监测温度（输入），根据设定控制空调开关（输出），形成 “监测 - 控制” 的反馈循环，属于过程控制风格在实时系统中的应用。

题目与答案整理2：

1. 语音识别系统架构风格判断
   • 题目：某公司欲开发一个语音识别系统，语音识别的主要过程包括分割原始语音信号、识别音素、产生候选词、判定语法片断、提供语义解释等。每个过程都需要进行基于先验知识的条件判断并进行相应的识别动作。针对该系统的特点，采用（ ）架构风格最为合适。（四选一：解释器、面向对象、黑板、隐式调用）
   • 答案：黑板
   • 思路：语音识别涉及多阶段处理（分割、识别、语义解释等），需多个模块基于共享数据（如中间识别结果）协作。黑板风格以共享数据为中心，各知识源（模块）通过黑板交互，适配多阶段协作场景。
2. 漫步者机器人架构风格判断
   • 题目：某公司欲开发一个漫步者机器人，用来完成火星探测任务。机器人的控制者首先定义探测任务和任务之间的时序依赖性，机器人接受任务后，需要根据自身状态和外界环境进行动态调整，最终自动完成任务。针对这些需求，该机器人应该采用（ ）架构风格最为合适。（四选一：解释器、主程序 - 子程序、隐式调用、管道 - 过滤器）
   • 答案：解释器
   • 思路：机器人需动态调整任务，适配自定义的任务规则及时序逻辑。解释器风格可灵活解释执行自定义规则，支持根据环境和状态动态处理任务，符合需求。
3. Windows 图形界面架构风格判断
   • 题目：Windows 操作系统在图形用户界面处理方面采用的核心架构风格是（ ）风格。
   • 答案：隐式调用
   • 思路：Windows 图形界面通过事件（如鼠标点击、窗口消息）触发组件响应，组件间通过事件机制间接交互，而非直接调用，属于隐式调用（事件驱动）风格的典型应用。

题目与答案整理1：

“编译器” 是一种非常重要的基础软件，其核心功能是对源代码形态的单个或一组源程序依次进行预处理、词法分析、语法分析、语义分析、代码生成、代码优化等处理，最终生成目标机器的可执行代码。考虑以下与编译器相关的软件架构设计场景：

• 传统的编译器设计中，上述处理过程都以独立功能模块的形式存在，程序源代码作为一个整体，依次在不同模块中进行传递，最终完成编译过程。针对这种设计思路，传统的编译器采用（1）架构风格比较合适。
• 随着编译、链接、调试、执行等开发过程的一体化趋势发展，集成开发环境（IDE）随之出现。IDE 集成了编译器、连接器、调试器等多种工具，支持代码的增量修改与处理，能够实现不同工具之间的信息交互，覆盖整个软件开发生命周期。针对这种需求，IDE 采用（2）架构风格比较合适。IDE 强调交互式编程，用户在修改程序代码后，会同时触发语法高亮显示、语法错误提示、程序结构更新等多种功能的调用与结果呈现，针对这种需求，通常采用（3）架构风格比较合适。
• 某公司已经开发了一款针对某种嵌入式操作系统专用编程语言的 IDE，随着一种新的嵌入式操作系统上市并迅速占领市场，公司决定对 IDE 进行适应性改造，支持采用现有编程语言进行编程，生成符合新操作系统要求的运行代码，并能够在现有操作系统上模拟出新操作系统的运行环境，以支持代码调试工作。针对上述要求，为了使 IDE 能够生成符合新操作系统要求的运行代码，采用基于（4）的架构设计策略比较合适；为了模拟新操作系统的运行环境，通常采用（5）架构风格比较合适。

选项：

• （1）A．管道 - 过滤器　B．顺序批处理　C．过程控制　D．独立进程
• （2）A．规则引擎　B．解释器　C．数据共享　D．独立构件
• （3）A．隐式调用　B．显式调用　C．主程序 - 子程序　D．层次结构
• （4）A．代理　B．适配　C．包装　D．模拟
• （5）A．隐式调用　B．仓库结构　C．基于规则　D．虚拟机

答案与思路：

1. （1）B．顺序批处理
   • 思路：传统编译器对源代码按预处理、词法分析等顺序依次处理，每个阶段批量处理数据，强调 “顺序 + 批量” 的处理模式，符合顺序批处理风格。
2. （2）C．数据共享
   • 思路：IDE 集成多种工具，需实现工具间信息交互，核心是通过数据共享让不同工具（编译器、调试器等）协同工作，因此采用数据共享架构风格。
3. （3）A．隐式调用
   • 思路：用户修改代码后，自动触发语法高亮、错误提示等功能，组件间通过事件隐式触发交互，而非直接调用，属于隐式调用风格。
4. （4）B．适配
   • 思路：改造 IDE 生成符合新操作系统的代码，需调整架构使现有功能适配新系统要求，采用适配策略实现对新平台的兼容。
5. （5）D．虚拟机
   • 思路：模拟新操作系统运行环境，需构建虚拟运行空间，屏蔽底层差异，虚拟机风格可实现这一目标，如通过虚拟环境运行调试代码。

特定领域软件架构⭐⭐⭐

定义

• DSSA 以特定问题领域为对象，构建包含领域参考模型、参考需求、参考架构的开发基础架构，目标是支持同一特定领域内多个应用的生成，提升该领域软件研发的复用性与效率。

DSSA 基本活动及产出物

通过领域分析、设计、实现三个逐步求精的阶段：

• 领域分析：建立领域模型，明确领域内共性问题与需求；
• 领域设计：基于模型设计架构，获得 DSSA；
• 领域实现：开发并组织可复用信息（如组件、模块），最终形成支持领域应用开发的架构基础。

DSSA 类型

• 垂直域：聚焦相同领域，深入挖掘该领域内的共性，实现架构的深度复用；
• 水平域：面向不同领域，通过迁移通用架构模式，实现跨领域的横向复用。

参与 DSSA 的人员分类及职责

1. 领域专家：具备领域经验的用户、需求分析员、软件设计师、项目管理者等，负责提供领域内系统的需求规约、实现知识。
2. 领域分析人员：需具备知识工程背景，由有经验的系统分析员担任，主导领域分析工作。
3. 领域设计人员：由有经验的软件设计人员担任，负责领域架构设计。
4. 领域实现人员：由有经验的程序设计人员担任，落实领域架构的开发实现。

建立过程步骤

1. 定义领域范围：明确 DSSA 适用的特定领域边界，确定目标领域范畴。
2. 定义领域特定的元素：识别该领域内特有的组成元素（如组件、模块等），提炼领域共性特征。
3. 定义领域特定的设计和实现需求约束：梳理领域内软件设计与实现的限制条件（如技术规范、业务规则等）。
4. 定义领域模型和架构：基于前面的分析，构建领域参考模型与软件架构，形成 DSSA 的核心框架。
5. 产生、搜集可复用的产品单元：开发或收集领域内可复用的组件、模块等资源，支撑后续应用开发。

过程特性

左侧标注 “并发的、递归的、反复的、螺旋型的”，说明 DSSA 建立并非线性流程，而是通过迭代循环、反复优化的方式，在不同步骤间交叉推进，逐步完善架构。

三层次模型

三层次结构与对应角色

1. 领域开发环境
   • 负责人员：领域架构师。
   • 核心内容：构建领域开发的基础要素，包括参考结构、参考需求、架构、领域模型、开发工具等，为整个领域的软件研发提供底层支撑。
2. 领域特定的应用开发环境
   • 负责人员：应用工程师。
   • 核心内容：基于 “领域开发环境” 的输出（如参考架构），进行实例化操作，生成具体应用的架构，推动领域内应用的开发。
3. 应用执行环境
   • 使用人员：操作员。
   • 核心内容：作为最终应用的运行环境，供用户实际使用已开发完成的软件应用。

层次间逻辑关系

• 从下到上，领域开发环境为上层提供基础资源；领域特定的应用开发环境基于前者进行实例化，最终输出到应用执行环境，形成 “架构设计→应用开发→用户使用” 的完整链条，体现 DSSA 从通用架构到具体应用的落地过程。

软件质量属性⭐⭐⭐⭐⭐

软件架构评估中的质量属性分类

• 性能

  • 定义：明确性能指 系统的响应能力，包括对事件的响应时间，或单位时间内处理事件的数量
  • 性能战术分类：
    • 资源需求：通过提高计算效率、减少计算开销、管理事件率、控制采样频率等方式，优化资源使用。
    • 资源管理：采用引入并发、维持多个副本、增加可用资源等策略，提升资源利用效率。
    • 资源仲裁：通过资源调度策略（如先进先出、固定优先级、动态优先级、静态调试），协调资源分配，保障性能。

• 可用性

  • 定义：指系统能够正常运行的时间比例，通常通过 “两次故障间隔时间” 或 “故障后恢复正常的速度” 衡量。
  • 示例说明：
    • 主服务器故障时，1 分钟内切换至备用服务器；
    • 系统故障后，1 小时内完成修复；
    • 系统支持 7×24 小时不间断工作。
  • 可用性战术分类：
    • 错误检测：通过命令 / 响应（如 Ping/Echo）、心跳机制、异常监测等方式发现系统错误。
    • 错误恢复：利用表决机制、冗余（主动 / 被动冗余）、备件等手段，确保系统故障后恢复正常。
    • 错误预防：借助进程监视器、事务处理、从服务器删除等策略，降低错误发生的可能性。

• 安全性

  • **定义：**系统向合法用户提供服务，同时阻止非授权用户使用或拒绝服务的能力。进一步细分为：
    • 机密性：防止信息泄露给未授权用户；
    • 完整性：避免信息被篡改；
    • 不可否认性（不可抵赖）：确保操作行为可追溯；
    • 可控性：对信息传播和内容具有控制能力。
  • 示例说明：
    • 抵御 SQL 注入攻击（体现抵抗攻击能力）；
    • 完整记录计算机操作（体现审计追踪）；
    • 用户信息数据库授权保证高可用（结合可用性）。
  • 安全性战术分类：
    • 抵抗攻击：通过身份验证、用户授权、数据加密、限制暴露 / 访问、保障数据完整性等方式，防御外部攻击。
    • 检测攻击：利用入侵检测机制，发现潜在的安全攻击行为。
    • 从攻击中恢复：
      • 识别：通过审计追踪记录操作，便于定位攻击；
      • 恢复：借助冗余等手段（与可用性战术重叠），降低攻击后的系统影响。

• 可修改性

  • 定义：指以较高性价比快速变更系统的能力，通常通过具体变更的代价（如时间、人力）衡量。
  • 细分为 可维护性、可扩展性、结构重组、可移植性。
  • 例如：
    • 更改系统报表模块需在 2 人周内完成；
    • 修改 Web 界面风格需在 4 人月内完成。
  • 可修改性战术分类：
    • 局部化修改：
      通过维持语义一致性、泛化模块、抽象通用服务等策略，将修改范围限制在局部，降低变更影响。
    • 防止连锁反应：
      采用隐藏信息（封装内部细节）、维持现有接口、限制通信路径、使用仲裁者等方式，避免一处修改引发全局连锁问题。
    • 推迟绑定时间：
      利用运行时注册、配置文件、多态、组件更换、遵守已定义协议等方法，延迟系统元素的绑定，提升灵活性，便于后续变更。

• 易用性

  • 定义：关注用户完成期望任务的容易程度，以及系统提供的用户支持种类。
  • 示例：
    • 界面友好：体现系统在交互设计上对用户的友好性；
    • 新用户学习使用系统时间不超过 2 小时：说明系统操作简单，用户上手快。

• 可测试性

  • 定义：指通过测试揭示软件缺陷的容易程度，衡量软件是否便于测试。
  • 示例：
    • 提供远程调试接口，支持远程调试：通过技术手段（如开放调试接口）降低测试难度，便于发现软件缺陷。

• 可靠性

  • 进一步细分为 容错 和 健壮性；

• 功能性

• 可变性

• 互操作性

质量效用树

通过分层拆解的方式，将软件架构的质量属性（效用）细化为可衡量的具体指标，便于评估架构设计。

质量属性分层

• 效用：作为顶层，向下拆解为四大核心质量属性：性能、可修改性、可用性、安全性。

字母（如 M、H、L）代表优先级或约束条件，用于区分不同指标的重要程度或实现难度，帮助团队在架构设计中聚焦关键质量目标。

软件架构评估⭐⭐⭐⭐

核心概念定义

• 敏感点：
  指一个或多个构件（及构件间关系）的特性，影响单一软件质量属性。例如某构件特性仅影响性能属性。
• 权衡点：
  影响多个质量属性的特性，是多个质量属性敏感点的交集。图中通过天平图示，说明 “安全” 与 “性能” 可能此消彼长，需权衡设计。
• 风险点：
  架构设计中潜在的、有问题的决策带来的隐患。例如架构决策不明确，可能导致后续功能重复或质量下降。
• 非风险点：
  明确无隐患的设计，通常以 “XXX 要求可实现（或接受）” 表述，如对系统性能指标的明确可实现描述。

示例解析

• 例（1）：交易请求处理时间影响数据传输协议设计，体现敏感点（影响性能相关设计）。
• 例（2）：“1 秒内完成交易请求” 是可实现的表述，属于非风险点。
• 例（3）：业务逻辑描述未达成共识，可能导致模块重复，影响可修改性，属于风险点。
• 例（4）：更改加密级别同时影响安全性和性能，属于权衡点（涉及多个质量属性的权衡）。

软件架构评估的三种方法

1. 基于调查问卷（检查表）的方式：通过预设问题或检查项收集反馈，分为通用调查问卷和特定领域检查表。
2. 基于度量的方式：通过量化指标（如性能数据、复杂度数值等）客观评估架构。
3. 基于场景的方式：围绕特定系统的使用场景（如用户操作、故障处理场景）进行评估。

评估方法对比表格

评估维度	调查问卷	检查表	场景	度量
通用性	通用	特定领域	特定系统	通用或特定领域
评估者对架构的了解程度	粗略了解	无限制	中等了解	精确了解
实施阶段	早	中	中	中
客观性	主观	主观	较主观	较客观

• 通用性：调查问卷适用广泛，检查表针对特定领域，场景绑定特定系统，度量灵活。
• 了解程度：度量需精确了解架构，场景需中等了解，问卷 / 检查表对了解深度要求较低。
• 客观性：度量最客观，基于数据；问卷、检查表、场景更多依赖主观判断。

场景

• 场景：从 风险承担者（如用户、开发者等）的角度，对其与系统交互过程的简短描述。

场景的六要素

• 刺激源：触发交互的主体（如用户、外部系统）。
• 刺激：风险承担者对系统执行的操作或输入。
• 制品：被交互的系统组件或功能。
• 环境：交互发生的条件或上下文（如系统运行状态）。
• 响应：系统针对刺激的反馈动作。
• 响应度量：对响应效果的量化指标。

性能场景示例解析

• 刺激源：10000 名希赛学员（触发交互的主体）。
• 刺激：同时进行在线测试（学员对系统的操作）。
• 制品：在线测试系统（被操作的目标系统）。
• 环境：正常运行（系统所处状态）。
• 响应：请求被处理（系统的反馈动作）。
• 响应度量：平均响应时间 2 秒（量化响应效果）。

基于场景的三种评估方法

• 软件架构分析法（SAAM）

  • 起源与关注点：最初聚焦于 可修改性，后续扩展至 可移植性、可扩充性 等质量属性。通过场景分析，评估架构在面对变更时的适应能力，判断架构设计对修改的支持程度。
  • 整体流程
    • 前期准备：
      • 问题描述：明确架构评估的目标与背景。
      • 需求说明：通过需求分析，梳理系统需求。
      • 架构描述：完成架构设计，输出架构描述文档，作为 SAAM 评估的输入。
    • 评估阶段：
      • 场景开发：结合架构描述，构建评估所需的场景（如修改场景、交互场景）。
      • 评估过程：
        • 单个场景评估：针对每个场景，分析架构对该场景的支持程度。
        • 场景交互评估：评估不同场景间的交互影响，判断架构在复合场景下的表现。
      • 总体评估：
        • 对单个架构，综合场景评估结果，得出整体架构质量结论。
        • 若比较多个架构，通过场景评估结果对比，筛选更优架构方案。

• 架构权衡分析法（ATAM）

  • 演进与目标：在 SAAM 基础上发展而来，主要针对 性能、实用性、安全性、可修改性 等质量属性。通过分析不同质量属性间的权衡关系（如提升安全性可能影响性能），帮助架构师做出更合理的设计决策。

    评估流程（四阶段）

    • 第一阶段：场景和需求收集
      • 收集场景：定义架构评估所需的使用场景。
      • 收集需求 / 约束 / 环境：梳理系统需求、约束条件及运行环境。
    • 第二阶段：架构视图和场景实现
      • 描述架构视图：从不同视角（如逻辑架构、物理架构）描述系统架构。
      • 实现场景：分析架构如何满足第一阶段收集的场景。
    • 第三阶段：属性模型构造和分析
      • 特定属性分析：基于单一理论（如性能模型、安全模型），对质量属性进行深入分析。
    • 第四阶段：折中
      • 标志敏感度：识别架构决策对各质量属性的敏感程度。
      • 标志折中：权衡不同质量属性，确定最终架构方案的折中策略，形成行动计划。

• 成本效益分析法（CBAM）

  • 定位与模型：基于 ATAM 建立，关注软件的 “经济” 模型。不仅评估架构的技术属性，还从成本、效益角度分析架构决策，例如衡量架构优化投入与收益（如维护成本降低、性能提升带来的效益），为架构设计提供经济层面的评估依据。

三种方法层层递进，SAAM 奠定基础，ATAM 扩展多属性权衡，CBAM 引入经济维度，共同构成基于场景的软件架构评估体系。

软件产品线⭐⭐⭐

软件产品线特性

• 核心要素：以 “核心资源” 为基础，形成 “产品集合”，专注 “特定领域”。
• 实施特征：强调 “过程驱动”，依赖 “技术支持”，并 “以架构为中心”（围绕 DSSA 展开），实现特定领域内的产品开发与技术整合。

双生命周期模型

两大工程模块

• 领域工程：
  • 输入：分析 “现有系统需求”。
  • 流程：按 “领域分析→领域设计→领域实现” 推进，产出 “领域需求模型”“领域架构”“领域可复用构件”，形成可复用的核心资产。
• 应用工程：
  • 输入：基于 “新系统需求”。
  • 流程：借助领域工程成果，通过 “需求分析→系统设计→系统实现”，最终开发出 “新系统”。

协作关系

领域工程是应用工程的基础，为其提供可复用的构件与架构；应用工程则通过复用领域工程成果，高效实现特定系统开发，体现软件产品线 “复用资产 + 定制开发” 的双生命周期特性。

建立方式

分类框架

从 “基于现有产品” 和 “全新产品线” 两个维度，结合 “演化方式” 与 “革命方式”，形成四种软件产品线建立方式：

• 基于现有产品：
  • 演化方式：基于现有产品架构，演化现有构件以开发产品线构件。
  • 革命方式：核心资源开发基于现有产品集需求及未来需求超集。
• 全新产品线：
  • 演化方式：核心资源随产品新成员需求逐步演化。
  • 革命方式：直接开发满足所有预期产品线成员需求的核心资源。

补充说明

• 进一步归纳为四类实践：
  1. 将现有产品演化为产品线（基于现有产品的演化）；
  2. 用软件产品线替代现有产品集（基于现有产品的革命）；
  3. 全新软件产品线的演化（全新产品线的演化）；
  4. 全新软件产品线的开发（全新产品线的革命）。

组织结构

组织结构类型

• 设立独立的核心资源小组：单独成立小组负责核心资源开发与维护。
• 不设立独立的核心资源小组：无专门小组，核心资源相关工作融入其他团队。
• 动态的组织结构：根据项目需求灵活调整组织形式，适配不同阶段任务。

成功实施产品线的关键因素

• 领域经验：需对目标领域具备长期、深厚的经验积累。
• 核心资源库：拥有高质量的核心资源库，支撑产品构建。
• 产品线架构：设计良好的软件产品线架构，确保系统性与扩展性。
• 管理支持：涵盖软件资源管理、人员组织协调、过程管理等全方位管理支持。

软件与中间件技术⭐⭐⭐

构件的定义

通过三种定义阐释构件的本质：

• 定义 1：构件是具备规范接口规约和显式语境依赖的组装单元，支持独立部署，可由第三方任意组装。
• 定义 2：构件是系统中有价值、近乎独立且可替换的部分，在明确的体系结构语境中实现清晰功能。
• 定义 3：构件是独立发布的功能模块，通过接口提供服务。

模块、对象、构件的特性对比

• 模块的特性：结构化开发的产物，侧重功能分解。
• 对象的特性：
  1. 作为实例单元，有唯一标志；
  2. 可能具备外部可见的状态；
  3. 封装自身状态与行为。
• 构件的特性：
  1. 是独立部署单元；
  2. 作为第三方组装单元，支持灵活组合；
  3. 无外部可见状态，更强调接口交互与功能封装。

通过定义和特性对比，明确构件在软件技术中的定位，突出其区别于模块、对象的独立部署、标准化接口等核心特征。

构件系统架构特性

构件系统体系结构组成

• 由三部分构成：
  • 平台决策：确定系统基础架构的关键决策。
  • 构件框架：围绕关键机制的专用体系结构，同时包含作用于构件层机制的固定策略。
  • 互操作设计：定义构件框架间交互的规则，确保系统整体连接与协作。

构件、原子构件及相关元素

• 构件与原子构件：
  • 构件是需同时部署的原子构件集合。原子构件通常不单独部署（尽管技术上允许），由模块和资源组成。
• 模块：包含类、过程、函数等结构，是代码集合（面向对象或非面向对象）。
• 资源：类型化项的固定集合，可包含代码资源（如模块）。在 “纯对象” 方法中，资源是外部化、不可改变的对象（因构件无持久化标志，复制后无法区分）。

架构设计核心思想

• 强调构件框架的策略性、互操作设计的规则性，以及构件、原子构件、模块、资源的层级关系，体现构件系统架构的模块化、可部署性和协作性。

中间件技术

中间件的双重属性

• 作为一类构件：中间件具备构件的通用特性，如标准化接口、可复用性。
• 作为一类系统软件：中间件属于系统软件范畴，为上层应用提供基础服务。

架构示意图

• 层级关系：
  • 上层：多个应用程序（如应用程序 1、2、3）。
  • 中层：中间件（标注 “系统服务”），作为桥梁连接应用程序与底层。
  • 下层：不同的操作系统 / 硬件平台（如平台 1、平台 2）。
• 作用展示：中间件屏蔽了底层操作系统和硬件平台的差异，使上层应用程序无需关注底层细节，直接通过中间件调用系统服务。

中间件的核心价值

• 简化结构：通过中间层抽象，降低应用开发复杂度。
• 屏蔽差异：隐藏不同操作系统、硬件平台的异构性，统一服务接口。
• 利于复用：提供标准化系统服务，促进应用程序对公共功能的复用，提升开发效率。

采用中间件技术的优点

• 面向需求：
  帮助设计师将精力集中于业务逻辑本身，无需过度关注底层技术细节，直接围绕需求进行设计。

• 业务的分隔和包容性：
  支持应用开发人员按不同业务划分功能，通过不同接口或交互模式实现业务隔离，提升系统模块化程度。

• 设计与实现隔离：
  构件通过接口对外作用或交互，使用者只需关注接口定义，无需了解内部实现，实现设计与实现的分离，降低开发复杂度。

• 隔离复杂的系统资源：
  中间件将系统资源（如硬件、操作系统）与应用构件隔离，为构件的可复用、“即插即用” 提供基础，匹配中间件的核心设计意图。

• 符合标准的交互模型：
  中间件实现标准化的架构模型与协议，确保构件交互遵循统一规范，提升系统兼容性和互操作性。

• 软件复用：
  通过构件封装、交互规则定义、环境隔离等机制，为软件复用提供便捷方案，减少重复开发工作。

• 提供对应用构件的管理：
  基于中间件的系统可通过标识机制对构件进行清晰划分，方便实现构件的注册、调用、监控等管理操作，提升系统维护效率。

• 中间件的分类及其特点

中间件分类	特点
通信处理（消息）中间件	实现可靠、高效、实时的跨平台通信，典型产品如 eLink、MQSeries。
事务处理（交易）中间件	支持事务分发与负载均衡，例如 Tuxedo，确保交易处理的高效与均衡。
数据存取管理中间件	简化虚拟缓冲存取、格式转换、解压等操作，方便数据存取与处理。
Web 服务器中间件	具备负载均衡、缓存、安全性等功能，优化 Web 服务器的性能与安全。
安全中间件	提供加密、认证等安全功能，保障系统安全。
跨平台和架构的中间件	解决跨平台交互问题，典型代表如 CORBA，支持不同平台与架构的互操作。
专用平台中间件	针对特定应用领域设计领域参考模式，构建专属架构，满足定制化需求。
网络中间件	涵盖网管、接入、网络测试、虚拟社区、虚拟缓冲等功能，管理网络相关操作。

该表格系统地梳理了中间件的类型，每种类型对应独特的功能特点及应用场景，有助于理解中间件在不同场景下的作用与价值。

软件复用

• 软件复用（重用）指在多次不同的软件开发过程中，重复使用相同或相似的软件元素。
• 可复用的元素包括：需求分析文档、设计过程、设计文档、程序代码、测试用例、领域知识等。

复用的历史发展线路

• 结构化时代：以函数库为复用载体。
• 面向对象时代：发展为类库，进一步延伸出框架（多个类的组合，提供通用设计结构）。
• 后续演进：从类库发展为构件库，再到更高级的服务库，体现复用粒度和抽象层次的提升。

复用的维度

• 水平复用：不区分行业领域，聚焦通用功能（如通用工具类、基础算法）。
• 垂直复用：针对特定行业或领域，提供专用的复用资源（如金融领域的交易构件、医疗领域的电子病历模块）。

构件的复用

构件复用流程

• 检索与提取构件：通过特定方法从构件库中查找并获取所需构件。

  • 基于关键字的检索：
    • 特点：采用树形或有向无回路图结构，通过关键字匹配检索构件（如示例中的形状搜索界面）。
  • 刻面检索法：
    • 特点：利用 “Facet” 描述构件功能、操作数据、应用语境等特征。
    • 示例：从 “应用领域”“使用环境”“功能” 等多个刻面分类检索构件。
  • 超文本检索法：
    • 特点：模拟人类联想思维，支持在文档中任意跳转到相关概念或构件的文档。

• 理解与评价构件：分析构件功能、适用性等，评估是否满足需求。

  • 构件复用的关键前提
    • 准确理解构件：复用构件时，精准理解其功能、机制是基础，尤其在对构件进行修改时，理解不充分会导致复用失败。
  • 开发标准要求
    • 遵循公共标准：为确保构件在不同场景下可复用、易理解和修改，构件开发过程必须遵循公共标准，这是构件复用的重要约束条件。
  • 构件库文档内容规范
    • 构件库文档需全面准确说明以下信息：
      • 构件功能与行为：明确构件能实现的功能及运行逻辑。
      • 领域知识：关联的领域背景知识，帮助理解构件应用场景。
      • 约束与例外：构件的适应性约束条件（如适用环境限制）和例外情形。
      • 修改指引：可预见的修改部分及具体修改方法，降低复用成本。

• 修改构件：根据实际应用场景，对构件进行适应性调整。

  • 构件修改的必要性

    • 理想与现实的差异：理想状态是直接复用构件库中现成的构件，但实际应用中，因需求变化，多数情况需对构件进行修改以适配新需求。

  • 减少修改工作量的设计原则

    • 抽象化、通用化、参数化设计：开发人员需将构件的功能、行为和接口设计得更抽象、通用，并支持参数化。这样复用者可通过调整参数（实参选取）直接适配构件功能，若仍不满足需求，再借助设计文档深入修改构件。

  • 无适配构件的处理方式

    • 若构件库中没有可修改使用的构件，需按新需求重新开发构件，并将新构件存入构件库，为后续复用提供资源。

• 组装构件：将筛选、修改后的构件组合成完整软件系统。

  • 构件组装的三种方式

    • 基于功能的组装

      • 采用子程序调用和参数传递的方式，将构件组合在一起，聚焦功能层面的整合。

    • 基于数据的组装

      • 虽仍依赖传统子程序调用与参数传递，但设计方法转向 “面向数据”（如 Jackson 系统开发方法），以数据为核心组织构件。

    • 面向对象的组装

      • 若从类库中检索的基类完全满足新系统需求，直接复用；若不满足，则以基类为父类，生成子类，通过继承与扩展适配新需求。

  • 构件组装失配问题

    • 由构件引起的失配

      • 因系统对构件基础设施、控制模型、数据模型的假设存在冲突，导致构件无法适配。

    • 由连接子引起的失配

      • 系统对构件交互协议、连接子数据模型的假设冲突，影响构件间的交互与协作。

    • 全局体系结构假设冲突

      • 系统成分对整体体系结构的假设存在矛盾，引发组装失配。解决失配需先检测问题，再通过调整手段消除冲突。

构件标准中的三大构件标准

• COBRA：作为三大构件标准之一，是一种跨平台、跨语言的分布式对象标准，支持不同系统间的互操作。
• J2EE（EJB）：
  • 会话 Bean：实现业务逻辑，负责完成服务端与客户端的交互，处理业务规则和流程。
  • 实体 Bean：实现对象 / 关系（O/R）映射，将数据库操作抽象化，简化数据库开发工作，便于数据持久化管理。
  • 消息驱动 Bean：处理并发请求与异常访问，通过异步消息机制提升系统的响应能力和稳定性。
• DNA 2000：微软提出的构件标准，旨在构建分布式应用系统，整合服务器、客户端等资源，实现高效的企业级应用开发。

CORBA（公共对象请求代理体系结构）的工作原理，分为客户端和服务端两部分，具体内容如下：

• 客户端

  • 客户机 ORB（对象请求代理）：负责解释请求，查找实现请求的对象，传输参数并返回结果，使客户端无需关注服务对象的位置、通信方式等细节。

  • 桩 / 存根（IDL Stub）：客户端的接口，用于发起请求调用。

  • 请求调用：通过 IDL Stub 触发对服务端的操作请求。

  • 对象引用：建立客户端与服务端 CORBA 对象的逻辑连接标识。

• 服务端

  • 服务器 ORB：与客户端 ORB 协作，处理实际请求流。

  • 框架（IDL Skeleton）：服务端的接口框架，配合对象适配器工作。

  • 对象适配器（POA）：屏蔽 ORB 内核实现细节，为服务器对象实现者提供抽象接口，以便使用 ORB 内部功能。

  • 伺服对象（Servant）：CORBA 对象的具体实现，负责处理客户端请求。

  • CORBA 对象：服务端对外提供服务的抽象对象，通过逻辑连接接收客户端请求。

• 关键组件解释

  • 伺服对象（Servant）：CORBA 对象的真正实现，完成客户端请求的具体业务逻辑。

  • 对象适配器（Object Adapter）：隐藏 ORB 内核细节，为服务器对象实现提供统一接口，方便使用 ORB 功能。

  • 对象请求代理（ORB）：核心组件，协调客户端与服务端交互，解释请求、查找对象、传递参数并返回结果，实现位置透明、通信透明等。

ADL

ADL 的定义

ADL（架构描述语言）是一种形式化语言，在底层语义模型支持下，为软件系统的概念体系结构建模提供具体的语法规则和概念框架，用于精准描述软件架构。

ADL 的三个基本元素

1. 构件：软件架构中的计算单元或数据存储单元，是系统功能实现的基础模块。
2. 连接件：用于对构件间交互进行建模的构造块，包含支配交互过程的规则，定义构件如何通信与协作。
3. 架构配置：通过图示或描述，展现构件与连接件的连接关系，形成体系结构的整体拓扑图。