当前位置：首页 > news >正文

软件架构风格概述

news 来源：原创 2025/5/24 22:20:09

数据流风格（Data Flow Style）

在数据流风格的架构中，所有的数据在执行过程中按照流的形式前进，这意味着数据不会因为某个步骤的重复或重构而回流或重新处理。数据经过一系列独立的数据处理组件，在每个组件中被处理，然后结果被传递给下一个组件，最终输出结果。

优点：

简化流程管理： 由于数据是按顺序流动的，流程管理相对简单，每个组件只负责处理它接收到的数据流。
便于调试： 数据的流动路径清晰，便于追踪和调试。

缺点：

灵活性不足： 由于数据是按顺序流动的，如果需要调整处理顺序或插入新的处理步骤，可能会比较复杂。

想象一下，你有一条流水线，上面流水的是各种各样的数据。这些数据按照一定的顺序流动，通过一系列处理数据的机器（称为数据组件）。每个机器只负责处理经过它的那部分数据，并将处理后的结果传给下一个机器。最后，所有的处理结果被收集起来输出。

流水线：所有的数据都在这条流水线上按照固定顺序流动。
数据组件：就像是流水线上的机器，每个机器只处理经过它的数据，并将结果传给下一个机器。
输出：最终结果由流水线末端的机器收集并输出。

这种架构的好处是：

每个机器（数据组件）只负责一部分工作，分工明确，便于维护。
可以很自然地将多个机器组合在一起，实现复杂的功能。
数据处理是连续的，不会出现数据的反复和重构。

管道—过滤器（Pipes and Filters）

管道—过滤器架构是一种软件架构，其中每个组件都有自己的输入和输出。数据流通过管道传输，每个过滤器对数据进行处理并传递结果给下一个过滤器。这种架构支持增量处理，即在输入数据完全消费之前就开始产生输出。

特点：

独立性： 每个过滤器都是独立的实体，不与其他过滤器共享数据。
无序依赖： 过滤器之间不依赖过程的顺序，不清楚上下游的标识。
并行执行： 每个过滤器可以作为一个单独的任务执行，因此可以与其他任务并行执行。

优点：

隐蔽性和内聚性： 使得软构件具有良好的隐蔽性和高内聚、低耦合的特点。
简单合成： 设计者可以将整个系统的输入/输出行为看作是多个过滤器的行为的简单合成。
重用性： 只要提供适合的数据，任何两个过滤器都可以连接起来。
易于维护和增强： 可以添加新的过滤器或替换旧的过滤器以增强系统性能。
属性分析： 支持对系统吞吐量、死锁等属性的分析。
并行执行： 支持并行执行，提高系统效率。

缺点：

批处理结构： 过滤器的独立性导致整个过程可能成为批处理结构。
不适合交互应用： 不适合需要增量显示改变的应用。
数据传输复杂性： 没有通用的数据传输标准，每个过滤器都需要解析和合成数据，增加了系统复杂性和性能开销。

想象一下，你有一个工厂，工厂里有很多流水线（管道），每条流水线上都有很多机器（过滤器）。这些机器对流水线上的数据进行变换和增量计算。也就是说，机器在处理数据的过程中，不需要等到所有数据都到达，而是可以在数据到达后立即开始处理，并将处理结果传给下一个机器。

管道：就像是流水线，数据在管道中流动。
过滤器：就像是流水线上的机器，每个机器可以独立地处理数据的一部分，并将结果传给下一个机器。
输入/输出：每个过滤器都有输入和输出，不依赖于其他的过滤器。

这种架构的好处是：

每个过滤器（机器）独立工作，不会与其他过滤器共享数据，这样可以提高系统的隐蔽性和稳定性。
所有的数据处理结果延迟小，因为数据可以增量地处理。
支持软件重用，只要数据格式合适，任何两个过滤器都可以连接起来。
系统维护和性能增强简单，可以添加或替换过滤器。
支持并行执行，因为每个过滤器可以作为一个单独的任务进行处理。

批处理序列（Batch Sequential）

批处理序列是一种软件架构，其中每一步处理都是独立的，并且按顺序进行。只有当前一步处理完成后，后一步处理才能开始。数据必须是完整的才能传递到下一步。

特点：

整体数据处理： 每一步处理都是对完整的数据集进行操作，而不是部分数据。
顺序性： 处理步骤是按顺序排列的，必须严格遵循顺序执行。

优点：

简单性： 每一步处理都是独立的，容易理解和实现。
稳定性： 这种架构通常更加稳定，因为每一步处理都是在前一步的基础上进行的。

缺点：

延迟高： 由于每一步处理都是在前一步完成后才能开始，整个过程的延迟较高。
资源占用： 处理整体数据集时，可能会占用大量资源，尤其是在数据量大的情况下。

想象一下，你有一个仓库，里面堆满了货物。你需要对这些货物进行一系列的处理，比如打包、装车、运输。每一步处理都是独立的，需要先完成前一步的所有处理，才能开始后一步的处理。

每一步处理独立：比如你先完成所有货物的打包，然后才能开始装车。
顺序进行：每一步完成后，下一次才能开始。
数据完整传递：需要等待所有数据（货物）处理完毕后，才能开始下一步。

批处理序列的优点是：

简单明了，每一步都处理所有数据，然后传递给下一步。
适用于需要完整处理数据的情况，比如数据导出、备份等。

缺点是：

输入数据时需要等待所有数据处理完毕，效率较低。
不适合需要即时反馈的情况，比如交互式应用。
数据处理过程中需要完整的数据集，增加了数据传输的复杂性。

批处理序列风格与管道—过滤器风格比较

共同点：

固定顺序的计算单元： 两种风格都将任务分成一系列固定顺序的计算单元（组件）。
数据传递交互： 组件间只通过数据传递进行交互。

区别：

批处理： 批处理强调数据传送在步与步之间作为一个整体，数据处理是全部的、高潜伏性的，输入时可随机存取，无合作性、无交互性。
管道过滤器： 管道过滤器是递增的，数据结果延迟小，输入时处理局部化，有反馈、可交互。通过这种方式，可以更高效地处理数据流，并且更容易扩展和维护。

示例：早期的编译器

早期的编译器采用管道—过滤器风格，将代码分段处理。具体来说，编译器将代码依次进行词法分析、语法分析、语义分析等步骤，而不是在词法分析完成后才开始语法分析。这种方式提高了编译效率，并且每个步骤都可以独立优化。

总结

数据流风格：适合数据按顺序流动的场景，每个组件只处理它接收到的数据。
管道—过滤器风格：适合需要增量处理和并行执行的场景，每个过滤器独立处理数据流，并将结果传递给下一个过滤器。
批处理序列风格：适合需要整体处理数据集的场景，每一步处理都是在前一步完成后进行的。

共同点：两者都把任务分成一系列固定顺序的计算单元（组件），组件间只通过数据传递交互。
区别：
批处理：全部数据作为一个整体进行处理，步骤之间数据传递是完整的，处理延迟较高。
管道过滤器：数据可以增量地处理，步骤之间数据传递是局部的，处理延迟较低，可以并行执行，适合需要即时反馈的情况。

调用/返回风格

主程序/子程序风格和面向对象风格，以及分层架构。这些风格的不同之处在于它们如何组织程序构件（如子系统、对象、模块等）和这些构件之间的交互方式。

调用/返回是一种分而治之的策略，通过将一个复杂的大系统分解为多个子系统来降低系统的复杂度，同时也提高了系统的可修改性。
当程序执行时，它从某个起点开始执行一个构件的代码，然后在该构件执行完成后，控制权返回到调用该构件的程序部分。
这种风格有助于管理复杂性，使得每个子系统可以独立开发、测试和修改，而不影响其他部分。

想象你正在做一道复杂的菜。这道菜需要很多步骤，比如切菜、炒菜、炖汤等。调用/返回风格就像你请一位厨师来帮你做这道菜。你告诉厨师你需要做什么菜，厨师开始烹饪，最后把做好的菜“返回”给你。在这个过程中，你不需要知道厨师是怎么切菜、炒菜的，你只要知道最终的结果即可。如果厨师想改进他的切菜技巧，你不需要做任何改变，因为你只关心最终的菜品，而不是制作过程的具体细节。

主程序/子程序风格 (Main Program and Subroutine):
- 主程序/子程序风格是结构化开发方法的一部分，它将程序分解为主程序和许多子程序。这种风格通常采用单线程控制，即程序按顺序执行各步骤。这种风格强调任务的分解和顺序执行，每个子程序可以独立完成自己的任务，并且可以被多次调用。子程序可以合并成模块，模块之间的交互通过过程调用来实现。子程序的正确性和可靠性依赖于其调用的子程序是否正确。

继续使用做菜的例子。主程序/子程序风格就像你自己在做这道菜，但是你把一些具体的步骤交给助手去做。你作为主厨师，负责总体的指导和安排，比如先炒什么、后炖什么。助手们则负责具体的子任务。当一个子任务完成时，助手会把结果“返回”给你，你再继续下一个步骤。

面向对象风格 (Object-oriented):
- 这种风格中的构件是对象，他们是抽象数据类型的实例。
- 对象是管理者，因为它们负责保持所管理资源的完整性。
- 对象之间的通信通过函数和过程的调用来实现。
- 这种风格有两个重要特征：
  - 封装性：对象负责维护其数据（表示）的完整性。
  - 隐蔽性：对象对其表示方式对外部其他对象是隐蔽的，这意味着对象可以改变自己的实现而不影响使用它的其他对象。
- 面向对象的优点包括：
  - 可以独立改变对象的实现而不影响其他对象的正确性。
  - 可以将复杂的数据存取操作分解为简单的交互，通过代理程序来实现。
- 面向对象也有一些问题：
  - 对象之间的交互需要知道彼此的标识符，因此标识符的改变会导致所有相关代码的修改。
  - 对象的使用可能会产生一些非预期的副作用，特别是在多个对象使用同一个对象的情况下。

面向对象风格则更进一步。假设你是一家餐厅的老板，你需要管理不同的资源，如食材、厨房设备等。你创建了一些对象来代表这些资源，比如“食材对象”、“厨房设备对象”。每个对象都有自己的行为（方法）和状态（数据）。比如，“食材对象”可以有“切”、“洗”等方法，“厨房设备对象”可以有“开启”、“关闭”等方法。这些对象之间的交互通过调用方法来实现。面向对象的优点是，你可以独立改变一个对象的实现，比如改进食材的处理方式，而不影响其他对象的操作。但是，如果对象的标识符改变，你需要修改所有调用它的代码。此外，多个对象使用同一个对象时，可能会出现一些非预期的效果，比如多个厨师同时使用同一把刀可能会导致刀具的磨损。

分层架构 (Layered System):
- 分层架构是一种将程序分为不同层次的设计风格，每个层次都为上层提供服务，同时作为下层的客户端。
- 这种风格最常见于分层通信协议中，每一层提供一个抽象的功能，使得上层可以基于这些功能进行通信。
- 分层架构有助于清晰地分离不同的功能，使得系统的不同部分可以独立开发和测试。

分层架构就像是一个酒店的服务体系。酒店有前台、客房、餐厅等多个部门。前台为顾客提供订房服务，而作为客房的客户端，需要为顾客提供房间；餐厅为客户提供餐饮服务，而作为前台的客户端，需要为顾客提供餐饮信息。每个部门（层）只负责自己的事情，并且只与相邻的层进行交互。这种设计使得各个部门可以独立地开发和测试，比如你可以先优化前台的服务流程，而不需要立即考虑客房和餐厅的变化。分层架构最常见的是通信协议，比如TCP/IP协议栈，每一层都为上层提供抽象的功能，使得上层可以基于这些功能进行通信。

独立构件风格（Independent Components）

定义：强调系统中的每个构件都是独立的个体，不直接通信。
优点：
- 降低耦合度，提升灵活性。
- 适应分布式系统，构件分工明确，耦合性低。
应用：适用于需要高灵活性和可扩展性的系统。

想象你有一个大盒子，里面装着许多小盒子。每个小盒子是一个独立的构件，它们各自负责不同的任务。这些小盒子之间不会直接对话，而是通过一个中央仓库来交换信息。这样做的好处是，每个小盒子可以根据需要独立变化，而不会影响其他小盒子。比如，你可以随时更换一个装巧克力的小盒子，而其他装水果或糖果的小盒子不会受到影响。

1. 进程通信（Communicating Processes）

定义：构件是独立的过程，通过消息传递进行交互。
特点：
- 消息传递的方式多样：点到点、异步、同步、远程过程调用等。
- 构件通常是命名的，便于管理。
应用：适用于需要并发执行和复杂通信的系统。

现在考虑一个餐厅的情况。餐厅里有许多厨师，每个厨师是一个独立的进程。厨师之间不直接对话，而是通过托盘上的订单来进行交流。这种交流可以是点对点的（比如，甜品厨师只和点心厨师交流），也可以是广播的（比如，餐厅经理可以通过公告板给所有厨师发消息）。这种风格允许厨师们在各自的厨房里工作，而不需要知道其他厨房里发生了什么。托盘上的订单可以是异步的（厨师们可以随时处理订单，不一定要立即回应），也可以是同步的（厨师们需要立即回应订单，比如紧急情况下的订单处理）。还可以通过远程过程调用来实现，即厨师可以通过电话或电脑来处理来自其他餐厅的订单。

2. 事件驱动系统（Event System）

定义：构件不直接调用过程，而是触发或广播事件，其他构件注册的过程在事件触发时被自动调用。
特点：
- 事件触发者不知道哪些构件会受到影响。
- 构件处理顺序和过程调用顺序不确定。
- 通过事件注册实现模块间的交互。
优点：
- 软件重用：只需将构件注册到系统事件中即可加入现有系统。
- 改进系统：替换构件时不会影响其他构件的接口。
缺点：
- 控制丧失：不能确定事件是否会被响应或响应顺序。
- 数据交换：依赖共享仓库时会带来性能和资源管理问题。
- 正确性推理：过程语义依赖于事件的上下文，推理正确性存在困难。

进一步想象一个音乐节的场景。每个乐队是一个独立的构件，他们各自准备自己的表演。当音乐节开始时，导演会触发一系列事件，比如“摇滚乐队开始”、“民谣乐队上场”等。每个乐队会预先注册好自己要响应的事件，当事件触发时，乐队会自动开始表演。这样做的好处是，导演不需要知道每个乐队的具体表演内容，只需要触发相应的事件。如果某个乐队临时决定更换他们的演出曲目，其他乐队和导演都不需要知道这个变化，因为他们只要响应事件即可。这种风格的主要优点是易于软件重用和改进系统，主要缺点是难以控制计算顺序和数据交换的复杂性。

虚拟机风格（Virtual Machine）

基本思想：人为构建一个运行环境，以便在该环境中解析和运行自定义语言。
目的：增加架构的灵活性。

想象你有一个玩具箱，里面装满了各式各样的玩具。虚拟机风格就像是为这些玩具创建了一个特殊的玩具世界。在这个世界里，你可以根据需要设计并运行任何一种玩具的规则，而不需要直接与现实世界互动。这样做的好处是可以灵活地改变玩具的行为，同时不会影响到其他玩具的正常运行。这就好比在一个隔离的环境中运行不同的程序，通过虚拟机可以解析和运行自定义语言，增加了架构的灵活性。

解释器（Interpreter）
- 用途：设计和实现编程语言的解释器。
- 核心思想：将程序执行过程分为多个层次，不同的组件负责程序的解析、执行和管理。
- 组成部分：
  - 解释引擎：这是解释器的核心部分，负责翻译和执行代码。
  - 存储区：存放待解释的代码。
  - 状态数据结构：记录解释器当前的工作状态。
  - 进度数据结构：记录代码解释和执行的进度。
  - 举个例子，如果你有一本英文童话书，但你不会英语，你可以请一个翻译官（解释器）读给你听。翻译官会逐句翻译书的内容，并将这些内容用你熟悉的语言（比如中文）表达出来。这样，你就可以理解并享受这本书了。
规则系统（Rule-based System）
- 应用领域：人工智能、专家系统和决策支持系统。
- 核心思想：通过一组规则来进行推理和决策。规则系统就像是一个智能的裁判，它根据预先设定的一系列规则来做出决策。这种风格广泛应用于需要复杂推理和决策的领域，如人工智能、专家系统和决策支持系统。
- 规则引擎：是规则系统的“大脑”，它负责解释和执行规则。
- 业务规则与应用程序分离：这意味着你可以独立地管理规则，而不需要改变应用程序本身的代码。这种分离减少了运维的工作量，因为只需要更新规则而不需要重写整个程序。
- 优点：
  - 适用于复杂决策和推理场景。
  - 规则管理和推理过程灵活透明。
- 规则引擎：负责解释和实现规则，可以将业务规则与应用程序分离，减少运维工作。
- 典型应用：VIP管理系统根据商场活动不定期更新审核标准和折扣标准。

仓库风格 / 以数据为中心（Data-centered）：

数据共享风格（Data-centered）数据共享风格，也被称为仓库风格，是一种系统架构风格，强调通过共享的数据来实现不同部分之间的通信。这种风格的核心是有一个中央数据单元（资源库），存储系统的当前状态数据，并且有一组相互依赖的构件（构件组）可以对这个中央数据单元进行操作。构件之间并不直接通信，而是通过中央数据单元来进行信息交换，这样可以降低耦合度，提升系统的灵活性和可维护性。

中央数据单元

中央数据单元，通常被称为资源库，是一个集中存储系统当前状态数据的地方。它为整个系统提供了一个统一的数据视图，是信息交换的基础。

构件组

构件组是一组能够对中央数据单元进行操作的构件。这些构件通过读取中央数据单元中的数据来执行任务，并将结果写回到中央数据单元中。构件之间的信息传递通过中央数据单元进行，而不是直接通信。

控制策略

数据共享体系结构根据所使用的控制策略不同，可以分为两种主要类型：数据库应用系统和黑板应用系统。

数据库应用系统

数据库应用系统是一种由输入流中的事件驱动信息处理的系统，执行结构存储在中央数据单元（数据库）中。这种系统主要用于存储和管理大量结构化数据。数据库应用系统通常具有事务处理机制，确保数据的一致性和完整性。常见的应用场景包括企业级应用、管理系统等。

数据库应用系统是一种特定的系统架构风格，主要用于存储和管理大量结构化数据。

输入流中的事件驱动信息处理：这意味着系统处理的工作是由外部事件触发的。例如，当用户提交一个新的订单时，这个动作可以被视为一个事件，触发系统去处理这个订单的存储和管理。

执行结构存储在中央数据单元（数据库）中：在数据库应用系统中，所有的操作和处理结果都会被存储在一个中央的数据存储位置，即数据库。数据库是一个集中式的存储系统，可以存储和管理大量数据，并提供高效的查询和更新操作。

主要用于存储和管理大量结构化数据：结构化数据是指可以按照某种规则组织起来的数据，通常以表格的形式存在，如关系数据库中的表结构。数据库系统特别擅长处理这种类型的数据，提供高效的存储、检索和管理能力。

事务处理机制：事务是一种逻辑工作单元，对数据库进行的一系列操作要么全部成功，要么全部失败，而不会处于中间状态。事务处理机制确保了数据库中的数据一致性，即使在系统出现故障的情况下，也能保证数据的完整性和准确性。

常见的应用场景：数据库应用系统广泛应用于各种需要管理大量结构化数据的场景中，包括企业级应用（如ERP、CRM系统）、管理系统（如库存管理系统、订单管理系统）等。

形象解释

想象一下，你有一个图书馆（中央数据单元），里面存放着所有的书籍（结构化数据）。当有读者（构件）想要借阅一本书时，他们会在图书馆的系统中（数据库应用系统）提交一个借阅请求（事件）。系统会根据这个请求（事件驱动）去查找书籍并准备借阅（执行结构存储在中央数据单元中），同时确保每本书的借阅记录都是准确的（事务处理机制），这样其他读者（构件）可以清楚地知道哪些书已经被借出，哪些书还可以借阅（数据共享风格）。

这种方式使得图书馆的图书管理更加高效和灵活，可以根据不同的需求（事件）来处理借阅请求，而不会影响到图书馆的其他功能（结构化数据管理）。

黑板应用系统

黑板应用系统是一种由中央数据单元的当前状态驱动系统运行的系统。这种风格特别适用于解决状态冲突和处理可能存在的不确定性知识源。黑板系统常用于信号处理领域（如语音和模式识别）以及自然语言处理领域（如机器翻译和句法分析）。黑板系统允许多个构件同时读写数据，通过状态变化来驱动系统运行，特别适合需要多轮推理和决策的场景。

黑板应用系统：这是一种系统，其运行是由中央数据单元的当前状态决定的。中央数据单元可以看作是一个共享的数据空间或“黑板”，系统中的各个部分（称为构件）可以读取和写入这个黑板上的数据。

驱动系统运行：系统的运行并不是由预先设定的固定流程决定的，而是根据黑板上的数据状态变化动态调整的。这意味着系统的操作会随着数据的变化而变化。

解决状态冲突和处理不确定性知识源：黑板系统特别适合在状态信息可能有冲突或知识来源可能不确定的情况下工作。它可以通过集体决策和多轮推理来处理这些复杂情况。

应用领域：黑板系统被广泛应用在信号处理（如语音识别和模式识别）和自然语言处理（如机器翻译和句法分析）等需要复杂推理和分析的领域。

允许多个构件同时读写数据：这意味着黑板系统支持并发操作，多个构件可以同时访问和修改黑板上的数据，这对于提高系统的效率和灵活性非常有用。

特别适合多轮推理和决策：这种系统特别适合那些需要多次迭代推理和决策的场景，因为它能够根据每次推理的结果更新黑板上的数据，并基于新的数据状态进行下一轮的推理和决策。

总体来说，黑板应用系统是一种通过共享数据空间和并发操作来实现复杂推理和决策的系统架构，适用于需要处理状态冲突和不确定性的场景。

黑板应用系统可以想象成一个教室里的黑板。在这个教室里，每个学生（或称为构件）都可以随时上去查看黑板上的内容，也可以在黑板上添加新的信息。黑板本身就像一个中央数据单元，存储了所有的信息。

这个系统的特点是，黑板上的内容会不断变化，每当内容更新时，所有学生都可以看到新的信息，并根据这些信息进行思考、讨论或添加新的内容。这些持续的信息变化就像是系统的“状态变化”，驱动着整个系统向前发展。

黑板系统特别适合那些需要多人协作、多轮讨论和决策的场景。比如，信号处理领域中的语音识别任务，可以理解为多个学生根据黑板上的声音信号信息，不断尝试识别出正确的词语或句子；或者自然语言处理中的句法分析任务，可以看作是多个学生根据黑板上的句子结构信息，逐步确定句子的语法结构。

由于黑板系统允许多个构件同时读写数据，这就意味着它可以高效地处理多个信息源之间的冲突，也能处理那些不完全确定的信息。这样，整个系统就能更加灵活和智能地应对复杂的任务。

超文本系统

超文本系统是一种用于管理非结构化数据（如网页和文档）的系统。与数据库系统相比，超文本系统处理的数据通常没有固定的模式，而是以超链接的形式组织，支持用户通过点击链接在不同文档之间跳转。这种系统通常用于信息展示和内容发布，例如网站、文档库等。

想象一下你有一个巨大的图书馆，里面藏满了各种各样的书籍、报纸、杂志和其他阅读材料。这些材料并不像传统图书馆中的书籍那样按照固定的方式排列，而是根据内容之间的关联来组织。每本书、每篇论文、甚至每一段文字都可以包含指向其他相关材料的链接。

这种图书馆就是超文本系统的一个例子。当你在这样的图书馆中阅读一本书时，如果对某个概念或人物感兴趣，你可以轻松地点击文本中的链接，跳转到另一本书或文档中获取更详细的信息。这种跳转可以是无限制的，只要你对内容感兴趣，就可以一直点击下去，探索新的知识领域。

与传统的数据库系统不同，超文本系统不需要预先定义数据的结构。它更像是一个网，每一个节点（可以是网页、文档等）都和其他节点通过链接连接在一起。这种灵活的组织方式使得超文本系统非常适合用来展示和发布信息，比如网站和在线文档库。

简单来说，超文本系统就是一种让你可以通过点击链接在不同文档之间自由跳转的灵活的信息管理系统。

区别

中央数据单元的用途：
- 数据库应用系统：主要用于存储结构化数据，有明确的数据表和模式。
- 黑板应用系统：主要用于存储状态数据，并支持多轮推理和决策。
- 超文本系统：主要用于存储和展示非结构化数据，如网页和文档。
控制策略：
- 数据库应用系统：由输入事件驱动，处理事件并将结果存储到中央数据单元。
- 黑板应用系统：由中央数据单元的状态驱动，构件根据数据状态变化进行操作。
- 超文本系统：通常由用户交互驱动，用户通过点击链接在不同文档之间跳转。
应用场景：
- 数据库应用系统：适用于企业级应用、管理系统等需要大量结构化数据存储和管理的场景。
- 黑板应用系统：适用于信号处理、自然语言处理等需要复杂推理和处理不确定性知识源的场景。
- 超文本系统：适用于信息展示和内容发布，如网站、文档库等。