⇧
❮
❯
↻
系统架构设计 12146字 61分钟

系统架构核心知识（3a）：软件架构设计（概述、风格、ABSD、DSSA）

作者

软考高级架构考点——软件架构设计：软件架构的概念 ⭐️⭐️⭐️、基于架构的软件开发 ⭐️⭐️⭐️⭐️、软件架构风格 ⭐️⭐️⭐️⭐️⭐️、特定领域软件架构 ⭐️⭐️⭐️、软件质量属性 ⭐️⭐️⭐️⭐️⭐️、软件架构评估 ⭐️⭐️⭐️⭐️、软件产品线 ⭐️⭐️⭐️、构件与中间件技术 ⭐️⭐️⭐️

重中之重！！！！！！

Hyplus目录

1 软件架构概述 ⭐️⭐️⭐️

软件架构/体系结构（Architecture）就是需求分配，即将满足需求的职责分配到组件上。架构设计的目标是确定应用软件的哪些部分将分配到何种硬件。识别出正在开发系统的主要软件构件并分配到系统将要运行的硬件构件。

架构的本质：

  1. 软件架构为软件系统提供了一个结构、行为和属性的高级抽象。
  2. 软件架构风格是特定应用领域的惯用模式，架构定义一个词汇表和一组约束。
  3. 软件系统架构不仅指定了软件系统的组织和拓扑结构，而且显示了系统需求和组件之间的对应关系，包括设计决策的基本方法和基本原理。

架构的作用：

  1. 软件架构是项目干系人进行交流的手段。
  2. 软件架构是可传递和可复用的模型，通过研究软件架构可能预测软件的质量。
  3. 软件架构使推理和控制的更改更加简单，有助于循序渐进的原型设计，可以作为培训的基础。

架构从全局考虑，独立于实际问题，更偏向非功能性需求

软件架构

1.1 ANSI/IEEE 1471-2000标准

ANSI/IEEE 1471-2000是描述软件架构的第一个标准，其中要素的关系如下：

  1. 第一层：Mission
    • Mission：任务、使命。即为什么要做这个系统，可能的原因有为了更大的赢利、市场占有率更高、完善产品系列等。
  2. 第二层：Environment、System、Architecture
    • System：系统。具体定义为一系列组件组织在一起，相互作用，从而完成一个或者一些特殊的功能。
    • Architecture：系统架构。每个系统有一个架构，是对所有利益相关人（Stakeholder）的关注点（Concern）的响应和回答，通过架构描述（Architecture Description）来说明。
  3. 第三层：Stakeholder、Architectural Description、Rationale
  4. 第四层：Concern、Viewpoint、View
  5. 第五层：Library Viewpoint、Model
    • Model：模型。用来表达视图的方法，即描述系统中各种元素如何组织在一起发挥作用，用图形化的表示把看到的东西表达出来。

ANSI/IEEE 1471-2000是对软件密集型系统的架构进行描述的标准。在该标准中，【视图】（View）这一概念主要用于描述软件架构模型。在此基础上，通常采用【视角】（Viewpoint）描述某个利益相关人（Stakeholder）所关注架构模型的某一方面。【架构】（Architecture）则是对所有利益相关人关注点的响应和回答。

软件架构设计是降低成本、改进质量、按时和按需交付产品的关键因素。架构设计能够满足系统的性能、可维护性等品质；能够使得不同的利益相关人达成一致的目标；能够支持项目计划和项目管理等活动；能够有效地管理复杂性；等等。然而系统架构的给出必须建立在需求明确的基础上。

在ANSMIEEE 1471-2000标准中，系统是为了达成利益相关人（Stakeholder）的某些使命（Mission），在特定环境 （Enviroment）中构建的。每一个系统都有一个架构（Architecture）。架构（Architecture）是对所有利益相关人的关注点（Concern）的响应和回答，通过架构描述 （Architecture Description）来说明。每一个利益相关人都有各自的关注点。这些关注点是指对其重要的，与系统的开发、运营或其他方面相关的利益。架构描述（Architecture Description）本质上是多视图的。每一个视图 （View）是从一个特定的视角（Viewpoint）来表述架构的某一个独立的方面。试图用一个单一的视图来覆盖所有的关注点当然是最好的，但实际上这种表述方式将很难理解。视角 （Viewpoint）的选择，基于要解决哪些利益相关人的哪些关注点。它决定了用来创建视图的语言、符号和模型等，以及任何与创建视图相关的建模方法或者分析技术。一个视图（View）包括一个或者多个架构模型（Model），一个模型也可能参与多个视图。模型较文本的表述的好处在于，可以更容易的可视化、检查、分析、管理和集成。

1.2 软件架构RUP“4+1”视图

多视图表示从不同的视角描述特定系统的体系结构，从而得到多个视图，并将这些视图组织起来以描述整体模型。系统的每一个不同侧面的视图反映了一组系统相关人员所关注的系统的特定方面，多视图体现了【关注点分离】的思想。其中，“4+1”模型是描述软件体系结构的常用模型。

视角与视图：从不同的视角来检查，会有不同的视图。

架构的“4+1”视图

架构的统一过程模型（RUP）“4+1”视图与OOA中的UML“4+1”视图相互对应，相互匹配使用（因为架构紧接于需求分析之后）。如下所示：

  • 左上——逻辑视图（Logical View）：主要支持系统的功能需求，即系统提供给最终用户的服务。在逻辑视图中，系统分解成一系列的功能抽象，这些抽象主要来自问题领域。这种分解不但可以用来进行功能分析，而且可用作标识在整个系统的各个不同部分的通用机制和设计元素。在OO技术中，通过抽象、封装和继承，可以用对象模型来代表逻辑视图，用类图来描述逻辑视图。逻辑视图中使用的风格为面向对象的风格，在设计中要注意保持一个单一的、内聚的对象模型贯穿整个系统。——功能需求（同UML，又称“用户视图”）
  • 右上——开发视图（Development View）/模块视图：主要侧重于开发人员对软件模块的组织和管理，即开发环境中软件的静态组织结构。开发视图要考虑软件内部的需求，例如，软件开发的容易性、软件的复用性和软件的通用性，要充分考虑由于具体开发工具的不同而带来的局限性。开发视图通过系统I/O关系的模型图和子系统图来描述。——软件管理（UML中称为实现视图）
  • 左下——进程视图（Process View）：侧重于系统的运行特性，主要关注与系统集成人员有关的非功能性需求，例如系统的性能和可用性等。进程视图强调并发性、分布性、系统集成性和容错能力，以及从逻辑视图中的主要抽象如何适合进程结构等，它也定义了逻辑视图中的各个类的操作具体是在哪一个线程中被执行的。进程视图可以描述成多层抽象，每个级别分别关注不同的方面。——性能可扩充性、吞吐量等（同UML）
  • 右下——物理视图（Physical View）：主要考虑系统工程人员如何把软件映射到硬件上，它通常要考虑到解决系统拓扑结构、系统安装和通信等问题。当软件运行于不同的物理节点上时，各视图中的构件都直接或间接地对应于系统的不同节点上。因此，从软件到节点的映射要有较高的灵活性，当环境改变时，对系统其他视图的影响最小化。——系统拓扑、安装、通信等（注意：UML中称为部署视图）
  • 中心——场景（Scenarios）：可视为重要系统活动的抽象，它使四个视图有机联系起来，某种意义上说场景视图是最重要的需求抽象。在开发软件架构时帮助架构设计师找到构件及其相互关系。同时，架构设计师也可以用场景视图来分析一个特定的视图，或描述不同视图的构件之间是如何相互作用的。场景可以用文本表示，也可以用图形表示。（UML中为用例视图）

架构发展历程图：

架构发展历程

1.3 架构描述语言（ADL）

架构描述语言（Architecture Description Language，ADL）是一种为明确说明软件系统的概念架构和对这些概念架构建模提供功能的形式化语言。它在底层语义模型的支持下，为软件系统的概念体系结构建模提供了具体语法和概念框架。如：Aesop、MetaH、C2、Rapide、SADL、Unicon等。

Unicon示例（运用极少，了解即可）：

USES p1 PROTOCOL Unix-pipe
USES sorter INTERFACE Sort-filter
CONNECT sorter.output TO p1.source
USES p2 PROTOCOL Unix-pipe
USES printer INTERFACE Print-filter
CONNECT sorter.input TO p2.sink

ADL更关注构件间的互联机制（连接子），而非其他选项所述的内容。

ADL的三个基本元素：

  • 构件：计算或数据存储单元。（组件、组件接口）
  • 连接件：用于构件之间交互建模的体系结构构造块及其支配这些交互的规则。
  • 架构配置：描述体系结构的构件与连接件的连接图。

1.4 软件架构设计与生命周期

软件架构贯穿整个生命周期，不同阶段的作用和意义不同，各阶段架构工作表现如下所示：

  • 需求分析阶段：有利于各阶段参与者的交流，也易于维护各阶段的可追踪性。
  • 设计阶段：关注最早和最多的阶段。
  • 实现阶段：有效实现从软件架构设计向实现的转换。
  • 构件组装阶段：可复用构件组装的设计能够提高系统实现的效率。
  • 部署阶段：组织和展示部署阶段的软硬件架构、评估分析部署方案。
  • 后开发阶段：主要围绕维护、演化、复用进行。

其中【设计与实现阶段】在软件架构上的工作最多，也最重要，因此关注力度最大。

1.5 软件架构复用

软件复用/重用（Reusability）是多次不同的软件开发过程中重复使用相同或相似软件元素的过程，软件元素的组成有需求分析文档、设计过程、设计文档、程序代码、测试用例、领域知识。软件架构复用是系统化的软件开发过程：开发一组基本的软件构件模块，以覆盖不同的需求/体系结构之间的相似性，提高系统开发的效率、质量和性能。

复用的历史发展线路：结构化时代（函数库） → 面向对象时代（类库/框架【多个类的组合】、构件库、服务库）。在当前的趋势下，复用体由小粒度向大粒度的方向发展。

复用的维度：

  • 横向重用：重用不同应用领域中的软件元素，例如数据结构、分类算法和人机界面构建等。标准函数是一种典型的、原始的横向重用机制。
  • 纵向重用：在一类具有较多公共性的应用领域之间进行软部件重用。纵向重用活动的主要关键点是域分析（根据应用领域的特征及相似性预测软部件的可重用性）。

复用的类型：

  • 机会复用：开发过程中，只要发现有可复用的资产，就对其进行复用。
  • 系统复用：在开发之前，就要进行规划，以决定哪些需要复用。

软件架构复用的原因：减少开发工作、减少开发时间、降低开发成本、提高生产力、提高产品质量，更好的互操作性。

可复用的资产：需求、架构设计、元素、建模分析、测试、项目规划、过程+方法+工具、人员、样本系统、缺陷消除。（不含原材料）

一般形式的复用：函数的复用、库的复用、面向对象开发中的类、接口和包的复用。

复用的基本过程：

  1. 构建/获取可复用的软件资产（复用前提）：首先需要构造恰当的、可复用的资产，并且这些资产必须是可靠的、可被广泛使用的、易于理解和修改的。
  2. 管理可复用资产：该阶段最重要的是构件库（Component Library），由于对可复用构件进行存储和管理，它是支持软件复用的必要设施。构件库中必须有足量的可复用构件才有意义，应提供的主要功能包括构件的存储、管理、检索以及库的浏览与维护等，以及支持使用者有效地、准确地发现所需的可复用构件。在该过程中存在两个关键问题——
    • 构件分类：将数量众多的构件按照某种特定方式组织起来。
    • 构件检索：给定几个查询需求，能够快速准确地找到相关构件。
  3. 使用可复用资产：在最后阶段，通过获取需求，检索复用资产库，获取可复用资产，并定制这些可复用资产——修改、扩展、配置等，最后将它们组装与集成，形成最终系统。

软件架构演化时期包括设计时演化、运行前演化、有限制运行时演化和运行时演化。

2 软件架构风格 ⭐️⭐️⭐️⭐️⭐️☀️

重中之重！！！各种Web架构风格详见后述。

软件架构风格（Architecture Style）：描述特定软件系统组织方式的惯用模式（组织方式描述了系统的组成构件和这些构件的组织方式；惯用模式则反映众多系统共有的结构和语义），定义了用于描述系统的术语表和一组指导构建系统的规则。

架构模式是软件设计中的高层决策，反映了开发软件系统过程中所作的基本设计决策，例如C/S结构；设计模式主要关注软件系统的设计，与具体的实现语言无关；惯用法则是实现时通过某种特定的程序设计语言来描述构件与构件之间的关系，例如C++语言中的引用-计数。

五大架构风格 子风格
数据流风格 批处理、管道-过滤器
调用/返回风格 主程序/子程序、面向对象、分层架构
独立构件风格 进程通信、事件驱动系统（隐式调用）
虚拟机风格 解释器、规则系统
仓库风格（以数据为中心） 数据库系统、黑板系统、超文本系统

其他常见风格：闭环控制（过程控制）风格、C2风格……

2.0 软件架构案例分析总结 ☀️☀️

软件架构风格是描述某一类特定应用领域中软件系统组织方式和惯用方式。组织方式描述了系统的组成构件和这些构件的组织方式，惯用模式则反映众多系统共有的结构和语义。

  • 管道-过滤器架构风格中，每个构件都有一组输入和输出，构件接受数据输入，经过内部处理，然后产生数据输出。这里的构件称为过滤器，构件之间的连接件称为数据流传输的管道。
  • 主程序-子程序架构风格中，所有的计算构件作为子程序协作工作，并由一个主程序顺序地调用这些子程序，构件通过共享存储区交换数据。
  • 面向对象架构风格的特征是将数据表示和基本操作封装在对象中。这种模式的构件是对象，对象维护自身表示的完整性，对象之间通过消息机制进行通信，对象交互时需要知道彼此的标识，通过对象之间的协作完成计算过程。
  • 控制环路（过程控制）架构风格是将过程输出的指定属性维护在一个特定的参考值（设定点）。控制环路风格包括过程变量、被控变量、输入变量、操纵变量和设定点等构件，通过收集实际和理想的过程状态信息，并能调整过程变量使得实际状态趋于理想状态。
比较因素 管道-过滤器风格 数据仓库风格
交互方式 顺序结构或有限的循环结构 星型
数据结构 数据流 文件或模型
控制结构 数据流驱动 业务功能驱动
扩展方法 接口适配 模型适配

【例】某软件公司为其新推出的字处理软件设计了一种脚本语言，专门用于开发该字处理软件的附加功能插件。为了提高该语言的编程效率，公司组织软件工具开发部门为脚本语言研制一套集成开发环境。软件工具开发部门根据字处理软件的特点，对集成开发环境进行了需求分析，总结出以下3项核心需求：
（1）集成开发环境需要提供对脚本语言的编辑、语法检查、解释、执行和调试等功能的支持，并要实现各种功能的灵活组合、配置与替换。
（2）集成开发环境需要提供一组可视化的编程界面，用户通过对界面元素拖拽和代码填充的方式就可以完成功能插件核心业务流程的编写与组织。
（3）在代码调试功能方面，集成开发环境需要实现在脚本语言编辑界面中的代码自动定位功能。具体来说，在调试过程中，编辑界面需要响应调试断点命中事件，并自动跳转到当前断点处所对应的代码。
针对上述需求，软件工具开发部门对集成开发环境的架构进行分析与设计，王工认为该集成开发环境应该采用管道-过滤器的架构风格实现，李工则认为该集成开发环境应该采用以数据存储为中心的架构风格来实现。公司组织专家对王工和李工的方案进行了评审，最终采用了李工的方案。
问题1：
请用200字以内的文字解释什么是软件架构风格，并从集成开发环境与用户的交互方式、集成开发环境的扩展性、集成开发环境的数据管理三个方面说明为什么最终采用了李工的设计方案。
问题2：
在对软件系统架构进行设计时，要对架构需求进行分析，针对特定需求选择最为合适的架构风格，因此实际的软件系统通常会混合多种软件架构风格。请对核心需求进行分析，说明为了满足需求（2）和（3），分别应采用何种架构风格，并概要说明采用相应架构风格后的架构设计过程。
【解】
问题1：
软件架构风格是指描述特定软件系统组织方式的惯用模式。组织方式描述了系统的组成构件和这些构件的组织方式，惯用模式则反映众多系统共有的结构和语义。
从集成开发环境与用户的交互方式看，用户通常采用交互式的方式对脚本语言进行编辑、解释执行与调试。在这种情况下，采用以数据存储为中心的架构风格能够很好地支持交互式数据处理，而管道-过滤器架构风格则对用户的交互式数据处理支持有限。
从集成开发环境的扩展性来看，系统核心需求要求实现各种编辑、语法检查、解释执行等多种功能的灵活组织、配置与替换。在这种情况下，采用以数据存储为中心的架构风格，以数据格式解耦各种功能之间的依赖关系，并可以灵活定义功能之间的逻辑顺序。管道-过滤器架构风格同样以数据格式解耦数据处理过程之间的依赖关系，但其在数据处理逻辑关系的灵活定义方面较差。
从集成开发环境的数据管理来看，集成开发环境需要支持脚本语言、语法树（用于检查语法错误）、可视化模型、调试信息等多种数据类型，并需要支持数据格式的转换。以数据存储为中心的架构将数据存储在统一的中心存储器中，中心存储器能够表示多种数据格式，并能够为数据格式转换提供各种支持。管道-过滤器架构风格通常只能支持有限度的数据格式，并且在数据格式转换方面的灵活性较差。
问题2：
为了满足需求（2），应该采用解释器架构风格。具体来说，需要：①为可视化编程元素及其拖拽关系定义某种语言，并描述其语法与语义；②编写解释器对该语言进行解释；③生成对应的脚本语言程序。
为了满足需求（3），应该采用隐式调用架构风格。具体来说，首先需要定义“断点在调试过程中命中”这一事件，并实现当断点命中后的屏幕定位函数。集成开发环境维护一个事件注册表结构，将该事件与屏幕定位函数关联起来形成注册表中的一个记录项。在调试过程中，集成开发环境负责监听各种事件，当“断点在调试过程中命中”这一事件发生时，集成开发环境查找事件注册表，找到并调用屏幕定位函数，从而实现脚本语言编辑界面与调试代码的自动定位。

2.1 数据流风格

数据流风格（Data Flow）的基本特点为数据驱动——前一步处理的结果是后一步的输入内容。有批处理、管道-过滤器两种子风格。

数据流风格

优点：

  1. 松耦合【高内聚-低耦合】
  2. 良好的可修改性——重用性（各处理单元独立且功能明确）、可维护性（结构简单）、可扩展性【标准接口适配】
  3. 良好的隐蔽性
  4. 支持并行

缺点：

  1. 交互性较差
  2. 复杂性较高
  3. 性能较差（例如每个过滤器都需要解析与合成数据）

典型实例：

  • 传统编译器（C语言）
  • 网络报文处理

子风格：

  1. 批处理序列（Batch Sequential）：大量【整体】数据、无需用户交互。
  2. 管道-过滤器（Pipes and Filters）：【流式数据】（例如流媒体）、弱用户交互。（结构如下图所示）
    • 基本思想：把多个过滤器使用管道相联。输入某个构件，经过内部处理，产生数据输出。

管道-过滤器

2.2 调用/返回风格

调用/返回风格（Call/Return）是平日开发程序时最基础的风格。其发展过程与编程思想（面向过程 → 面向对象 → 面向服务）的发展基本一致。有主程序/子程序、面向对象、分层架构风格三种子风格

调用/返回风格

子风格：

  1. 主程序/子程序（Main Program and Subroutine）：面向过程
  2. 面向对象（Object-oriented）：对象的方法调用
  3. 分层架构（Layered System）：层与层之间的方法调用。

2.2.1 分层架构概述

结构：

分层架构

优点：

  • 良好的可修改性——可维护性（参考三层解耦的作用）、可扩展性（支持递增设计）、重用性（只要接口不变即可用在其它处）

缺点：

  1. 并不是每个系统都方便分层
  2. 很难找到一个合适的、正确的层次抽象方法（效率损失）
  3. 不同层次之间耦合度高的系统很难实现

特点：

  • 各个层次的组件形成不同功能级别的虚拟机
  • 多层相互协同工作，而且实现透明

2.2.2 C/S、B/S、RIA架构

C/S（Client/Server）架构与B/S（Browser/Server）架构的发展历史：

  1. 2层C/S：胖客户端【业务逻辑】 ↔ 服务器【数据库】
    • 升级维护困难
  2. 3层C/S：瘦客户端【仅界面】 ↔ 应用服务器【业务逻辑】 ↔ 服务器【数据库】
    • 业务逻辑变化不再需要更新客户端
    • 对这进行明确分割，不同层构件相互独立，层间的接口简洁，适合复杂事务处理。分为以下3层：
      1. 表示层：应用的用户接口部分，担负与应用逻辑间的对话功能。用于用户从工作站输入的数据，并显示应用输出的数据。为使用户能直观地进行操作，一般要使用图形用户界面（GUI），在变更用户界面时，只需改写显示控制和数据检查程序，而不影响业务逻辑。
      2. 功能层：应用的本体，负责具体的业务处理逻辑，例如在制作订购合同时要计算合同金额。表示层和功能层之间的数据互交要尽可能简洁。例如，用户检索数据时，要将有关检索要求的信息一次性地传送给功能层，检索结果数据也由功能层一次性地传送给表示层。
      3. 数据层：通常为数据库管理系统，负责管理对数据库数据的读写。数据库系统必须能迅速执行大量数据的更新和检索。
  3. 3层B/S：零客户端【浏览器】 ↔ WEB应用服务器【业务逻辑】 ↔ 服务器【数据库】
    • 完全不需要客户端，升级维护容易

RIA（Rich Internet Applications）架构风格的优点：

  • 反应速度快
  • 易于传播
  • 交互性强

RIA

2.2.3 分布式系统的逻辑计算层

分布式系统开发中，通常需要将任务分配到不同的逻辑计算层，共分为5层：

  1. 表示层：实现用户界面
  2. 表示逻辑层：执行为了生成数据表示而必须进行的处理任务，如输入数据编辑等
  3. 应用逻辑层：包括为支持实际业务应用和规则所需的应用逻辑和处理过，如信用检查、数据计算和分析等
  4. 数据处理层：包括存储和访问数据库中的数据所需的应用逻辑和命令，如查询语句和存储过程等
  5. 数据层：数据库中实际存储的业务数据

C/S系统开发时可以采用不同的分布式计算架构：

  1. 分布式表示架构：应用逻辑层、数据处理层、数据层仍放置于服务器，表示层、表示逻辑层放置于客户机（2层C/S）
  2. 分布式数据架构：数据层、数据处理层放置于服务器，应用逻辑层、表示逻辑层、表示层放置于客户机（2层C/S；服务器仅保留数据相关层）
  3. 分布式数据和应用架构：数据层、数据处理层放置于数据服务器，应用逻辑层放置在应用服务器上，表示层、表示逻辑层放置于客户机。(3层C/S)

2.3 独立构件风格

独立构件风格（Independent Components）与调用/返回风格的不同在于强调每一个构建都具有相对独立性（不直接调用；将紧耦合改为松耦合；例如绑定onclick()）。有进程通信、事件驱动系统（隐式调用）两种子风格。

独立构件风格

其中，事件管理器的事件管理机制（衔接“主函数”与“子函数”）如下图所示：

事件管理器

优点（构件的优点）：

  1. 松耦合
  2. 良好的可修改性——可扩展性、重用性

缺点（较为罕见）：

  1. 构件放弃了对系统计算的控制。一个构件触发一个事件时，不能确定其他构件是否会响应它。并且即使它知道事件注册了哪些构件的过程，也无法保证这些过程被调用的顺序。
  2. 数据交换的问题。
  3. 由于过程的语义必须依赖于被触发事件的上下文约束，关于正确性的推理存在问题。

特点：

  • 系统由若干子系统构成且成为一个整体
  • 系统有统一的目标
  • 子系统有主从之分
  • 每一子系统有自己的事件收集和处理机制

子风格：

  1. 进程通信 （Communicating Processes）：略（进程相关内容详见操作系统-进程管理）
  2. 事件驱动系统（Event System）/隐式调用：通过所监听的事件来驱动系统运作
    • 典型实例：onclick()；Windows操作系统UI（由点击等事件驱动）……

2.4 虚拟机风格

虚拟机风格（Virtual Machine）在日常开发中亦使用甚多，能够创建虚拟环境（用于沙盒类建造游戏等）。Java虚拟机是最常见的一种虚拟机（如下图所示），可以实现跨平台（“一次编写，到处运行”）。有解释器、规则系统两种子风格。

虚拟机风格

解释器（Interpreter）架构风格：构建一个解释器来解释并执行特定领域或问题领域的语言或规则。

  • 结构组成：解释器引擎、被解释执行的程序、两个状态（程序执行的当前状态、解释器引擎的内部状态）
  • 优点：可以灵活应对自定义场景。
  • 缺点：复杂度较高。
  • 适用场景：需要“自定义规则”的场合。（有时序要求、要求业务灵活组合等）
    • 【典例】某公司欲开发一个漫步者机器人，用来完成火星探测任务。机器人的控制者首先定义探测任务和任务之间的时序依赖性，机器人接受任务后，需要根据自身状态和外界环境进行动态调整，最终自动完成任务。针对这些需求，该机器人应该采用虚拟机（解释器、规则系统）架构风格最为合适。

解释器

规则系统（Rule-based System）架构风格：加强版解释器，在解释器的基础上增加经验规则（知识性规则）。

  • 结构组成：规则集、规则解释器、规则/数据选择、工作内存
  • 优缺点：同解释器
  • 适用场景：一般用在人工智能领域和DSS（决策支持系统）等信息系统中，非常适合专家系统（ES）。其他场合用解释器亦足够满足需求。

规则系统

2.5 仓库风格

日常生活中，数据无处不在，但并不是所有的数据都可以成为资产。数据作为资产需要具有以下特性：可控制、可量化、可变现。故数据资产（Data Assets）一般具备虚拟性、共享性、时效性、安全性、交换性、规模性。

仓库风格又称以数据为中心（Data-centered）。仓库（Repository）是存储和维护数据的中心场所。有两种不同的构件：【中央数据结构】说明当前数据的状态以及一组对中央数据进行操作的【独立构件】，仓库与独立构件间的相互作用在系统中会有大的变化，这种风格的连接件即为仓库与独立构件之间的交互。

仓库风格

子风格：

  • 数据库系统（Database System）：以数据为中心
  • 超文本系统（Hypertext System）：略
  • 黑板系统（Blackboard System）实质上只是在数据库系统上新增了触发机制（黑板上信息变动时触发数据源）。

【例】现代编译器主要关注编译过程和程序的中间表示，围绕程序的各种形态进行转化与处理。这种情况下，可以针对程序的各种形态构建数据库，通过中心数据库进行转换与处理。

以下着重介绍黑板系统。

结构：

黑板系统

优点：

  1. 良好的可修改性——可维护性、重用性（知识源）、可扩展性
    • 仓库均具有风格良好的可扩展性：各应用以数据为中心，当需要扩展时只需新增数据结点即可，耦合程度相对较低。
  2. 容错性和健壮性

缺点：

  1. 测试困难
  2. 不能保证有好的解决方案
  3. 难以建立好的控制策略
  4. 低效
  5. 开发困难
  6. 缺少并行机制

特点：

  • 在以数据为中心（数据库系统的特点）的基础上，使用中心数据触发业务逻辑部件

典型实例：

  • 语音识别（非常适合这种复杂的应用场景）
  • 模式识别
  • 图像处理
  • 知识推理

2.6 闭环控制（过程控制）风格

闭环控制（Closed-loop Control）架构风格又称过程控制，不属于5大风格，但应用甚多。

与开环风格相比（开环系统所发出的信息则不返回），闭环存在反馈环节，使得所发送的数据能够返回给比较器（判断是否达到预期）。如下图所示：

闭环控制架构

特点：

  • 适合于嵌入式系统，用于解决简单闭环控制问题
  • 不适合复杂场景

经典应用：

  • 空调温控（电视机遥控器则是开环）
  • 定速巡航

2.7 C2风格

C2（Component and Connector）架构风格实际上属于层次架构风格的一种，存在构件和连接件，连接件将构件进行相连。

C2风格

C2架构的基本规则：

  • 构件和连接件都有一个顶部和一个底部。
  • 构件的顶部要连接到连接件的底部，构件的底部要连接到连接件的顶部，构件之间不允许直连。
  • 一个连接件可以和任意数目的其他构件和连接件连接。
  • 当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部。（根据图进行理解）

2.8 模型驱动架构（MDA）

模型驱动架构（Model-Driven Architecture，MDA）起源于分离系统规约和平台实现的思想，是一种关注模型的软件设计和实现方法，使用了UML模型的一个子集来描述系统。MDA可创建一系列不同抽象层次的模型。

相关概念：

  • 模型（Model）：客观事物的抽象表示。
  • 架构（Architecture）：构成系统的部件、连接件及其约束的规约。
  • 模型驱动（Model-Driven）：使用模型完成软件的分析、设计、构建、部署、维护等各开发活动。

MDA的主要目标：Portability（可移植性），Interoperability（互通性），Reusability（可重用性）

MDA的3种核心模型以及代码，由上到下抽象程度由大到小：

  1. 计算无关模型（Computation-Independent Model，CIM）：对系统中使用的重要的领域抽象进行建模，因此有时被称为领域模型（另见DSSA-领域分析）。
  2. 平台无关模型（Platform-Independent Models，PIM）：在不涉及实现的情况下对系统的运转进行建模。具有高抽象层次、独立于任何实现技术的模型。
  3. 平台相关模型（Platform-Specific Models，PSM）：与某种特定实现技术紧密相连的模型。对平台无关模型转换后得到，对于每个应用平台都有一个单独的PSM。PIM会被变换成一个或多个PSM。
  4. 代码（Code）：用源代码对系统的描述（规约）。每个PSM都将被变换成代码。

MDA

3 基于架构的软件设计（ABSD） ⭐️⭐️⭐️⭐️

基于架构的软件设计（Architecture-Based Software Design，ABSD）方法以构成软件架构的商业、质量和功能需求等要素来驱动整个软件开发过程，是一个自顶向下、递归细化的软件开发方法。软件系统的体系结构通过该方法得到细化，直到能产生软件构件和类（模块）。

3.1 基本组成与作用

ABSD强调由商业、质量和功能需求的组合驱动软件架构设计。使用ABSD方法，设计活动可以从项目总体功能框架明确就开始，并且设计活动的开始并不意味着需求抽取和分析活动可以终止，而是应该与设计活动并行。

ABSD方法有三个基础：

  1. 第一个基础：功能分解。在功能分解中，ABSD方法使用已有的基于模块的内聚和耦合技术。
  2. 第二个基础：通过选择【架构风格】来实现质量和业务需求。
  3. 第三个基础：软件模板的使用。软件模板利用了一些软件系统的结构。

ABSD强调采用视角与视图来描述软件架构（从不同的视角来检查/描述，会有不同的视图，另见架构“4+1”视图），采用用例和质量属性场景来描述质量需求（用例捕获功能需求，质量属性场景捕获质量需求）

3.2 基于架构的软件开发方法——视角与视图

在以架构为核心的软件系统开发方法，架构用来激发和调整设计策略，不同的视图用来表达与质量目标有关的信息。架构设计是一个迭代过程，在建立软件架构的初期，首要任务是选择一个合适的架构风格（见前述），在此基础上，开发人员通过架构模型，可以获得关于软件架构属性（见后述）的理解，为将来的架构实现与演化过程建立了目标。

当考虑架构时，重要的是从不同的视角（Perspective）来检查，这促使设计师考虑具体架构的不同属性。例如：展示功能组织的静态视角能判断质量特性，展示并发行为的动态视角能判断系统行为特性。在ABSD方法中，使用不同的视角来观察设计元素，一个子系统并不总是一个静态的架构元素，而是可以从动态和静态视角观察的架构元素。

将选择的特定视角或视图与Kruchten提出的类似，即逻辑视图、进程视图、实现视图和配置视图（见软件架构RUP“4+1”视图），要点如下：

  • 逻辑视图用于记录设计元素的功能和概念接口，设计元素的功能定义了它本身在系统中的角色，这些角色包括功能性能等。
  • 进程视图也称为并发视图，使用并发视图来检查系统多用户的并发行为。使用“并发"来代替“进程”，是为了强调没有对进程或线程进行任何操作，一旦执行这些操作，则并发视图就演化为进程视图。
  • 实现视图即开发视图，主要侧重于开发人员。
  • 配置视图代表了计算机网络中的节点，即系统的物理结构。

3.2 基于架构的软件设计模型（ABSDM） ⭐️

基于架构的软件设计模型（Architecture-Based Software Design Model，ABSDM）把整个基于体系结构的软件过程划分为6个阶段：

  1. 架构需求
    • 需求获取（从需求库中）
    • 【标识构件】：生成类图 → 对类进行分组 → 把类打包成构建
    • 需求评审
    • 将系统需求模型转换为架构模型是软件系统需求分析阶段的一项重要工作，如何采用表格或用例映射保证转换的可追踪性是在转换过程中需要关注的问题。
  2. 架构设计：提出架构模型 → 映射构件 → 分析构件相互作用 → 产生架构 → 设计评审
    • 一旦得到了详细的软件架构设计，需要邀请独立于系统开发的外部人员对系统进行评审。
    • 一般来说，软件架构设计活动将已标识构件集成到软件架构中，设计这些构件，但不予以实现。
  3. 架构文档化
    • 输出：架构规格说明、测试架构需求的质量设计说明书
    • 文档的完整性和质量是软件架构成功的关键因素。
    • 注意事项：
      1. 文档要从使用者的角度进行编写
      2. 必须分发给所有与系统有关的开发人员
      3. 必须保证开发者手上的文档是最新的，但更新不要过于频繁（不要随时都是最新的）
      4. 架构文档中描述应该尽量避免不必要的重复
      5. 每次架构文档修改都应该记录进行修改的原则
  4. 架构复审：主要由用户代表与领域专家决定架构是否满足需求、质量需求是否在设计中得到体现。
    • 目的：标识潜在的风险，及早发现架构设计中的缺陷和错误
    • 过程：通常会对一个可运行的最小化系统进行架构评估和测试。
  5. 架构实现：复审后的文档化的架构 → 分析与设计 → 构件实现 → 构件组装 → 系统测试
  6. 架构演化：需求变化归类 → 架构演化计划 → 构件变动 → 更新后的相互作用 → 构建组装与测试 → 技术评审 → 演化后的架构

总体流程如下图所示（0:M、0:N表示多轮迭代）：

开发过程

架构需求与架构设计

架构实现与架构演化

4 特定领域软件架构（DSSA） ⭐️⭐️⭐️

特定领域软件架构（Domain Specific Software Architecture，DSSA）以一个特定问题领域为对象，形成由领域参考模型、参考需求、【参考架构】等组成的开发基础架构，支持一个特定领域中多个应用的生成。

DSSA的特征包括领域性、普遍性（非独特性）、抽象性、可复用性。

4.1 基本活动

DSSA的基本活动及产出物：

  1. 领域分析：建立【领域模型】（即MDA中的CIM），领域模型描述领域中系统之间共同的需求，即领域需求。
  2. 领域设计：获取特定领域软件架构（DSSA），DSSA描述领域模型中表示需求的解决方案。
  3. 领域实现：依据领域模型和DSSA开发和组织可重用信息，并对基础软件架构进行实现。

DSSA

拓展

领域驱动设计（Domain-Driven Design，DDD）强调【领域模型】（由开发人员与领域专家协作构建，可反映深层次领域知识，见前述）的重要性，并通过模型驱动设计来保障领域模型与程序设计的一致。从业务需求中提炼出统一语言（Ubiquitous Language），再基于统一语言建立领域模型；这个领域模型会指导着程序设计以及编码实现；最后通过重构来发现隐式概念，并运用设计模式改进设计与开发质量。

4.2 水平域与垂直域

从功能覆盖的范围角度理解DSSA中领域的含义有两种方法：

  1. 垂直域：定义了一个特定的系统族，导出在该领域中可作为系统的可行解决方案的一个通用软件架构。
  2. 水平域：定义了在多个系统和多个系统族中功能区域的共有部分，在子系统级上涵盖多个系统（族）的特定部分功能。

在特定领域架构中，垂直域关注的是与行业相关的，聚焦于行业特性的内容，而水平域关注的是各行业共性部分的内容。

4.3 领域分析机制

参与DSSA的人员：

  1. 领域专家：有经验的用户、从事该领域中系统的需求分析、设计、实现以及项目管理的有经验的软件工程师等。
    • 领域专家的主要任务包括提供关于领域中系统的需求规约和实现的知识。（是出意见的人，下面3位是干活的人）
  2. 领域分析人员：应由具有知识工程背景的有经验的系统分析员来担任。
  3. 领域设计人员：应由有经验的软件设计人员来担任。
  4. 领域实现人员：应由有经验的程序设计人员来担任。

参与人员

4.4 建立过程

建立DSSA的过程：

  1. 定义领域范围
  2. 定义领域特定的元素
  3. 定义领域特定的设计和实现需求约束
  4. 定义领域模型和架构
  5. 产生、搜集可复用的产品单元

最后回归第一步，不断求精。这是一个并发的、递归的、反复的、螺旋型的过程。（参考螺旋模型）

建立过程

DSSA的三层次模型：

  1. 领域开发环境：领域架构师
  2. 领域特定应用开发环境：应用工程师
  3. 应用执行环境：操作员

三层次模型

A 关于长文拆分

软件系统架构设计内容极多，故于2026年7月26日将后半部分内容（软件质量评估、中间件技术等）拆至另一文，请通过系列博文系统进行博文导航。

发表评论