用于控制的架构模式用于控制的架构模式

80 阅读 0 评论 53 点赞

我是靠谱客的博主活泼可乐，最近开发中收集的这篇文章主要介绍用于控制的架构模式用于控制的架构模式，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

用于控制的架构模式

架构模式可以从不同的角度反映系统的组织。这里的模式反映了在系统中组织控制的常用控制方式。

集中控制，其中有一个组件负责调用系统中其他组件的服务。反映了编程语言中的方法/过程/子例程调用。

基于事件的控制，系统响应来自系统环境的异步事件。

基于事件的控制是实时系统和许多具有键盘、鼠标等输入的交互式系统中的标准。

集中控制

在集中式控制模型中，一个组件被指定为控制器，并负责管理其他组件的执行。集中控制模型分为两类，具体取决于受控组件是顺序执行还是并行执行。

调用返回模型这是熟悉的自上而下的子例程模型，其中控制从子例程层次结构的顶部开始，并通过子例程调用传递到树的下层。子例程模型仅适用于顺序系统。
管理器模型这适用于并发系统。一个系统组件被指定为系统管理器，并控制其他系统进程的启动，停止，协调和调度。进程是可以与其他进程并行执行的组件或模块。此模型的形式也可以应用于顺序系统，在该系统中，管理例程根据某些状态变量的值调用特定的组件。这通常以case语句的形式实现。

调用返回模型如图1所示。主程序可以调用例程1、2和3；它们可以调用例程1、2和3。例程1可以调用例程1.2或1.2；例程3可以调用例程3.1或3.2；等等。这是程序动力学的模型。它不是结构模型；它不是结构模型。例如，无需将例行程序1.1纳入例行程序1。

图1呼叫返回控制模型

这种熟悉的模型已嵌入到C，Ada和Pascal等编程语言中。控制从层次结构中的上级例程传递到下级例程。然后返回到调用例程的位置。当前正在执行的子例程负责控制，并且可以调用其他例程或将控制权返回给它的父例程。返回到程序中的其他点是不好的编程风格。

此调用返回模型可以在模块级别用于控制功能或对象。被其他子例程调用的编程语言中的子例程自然具有功能。但是，在许多面向对象的系统中，对对象（方法）的操作被实现为过程或功能。例如，当Java对象从另一个对象请求服务时，它通过调用关联的方法来这样做。

这种模式的僵化和局限性既是优点也是缺点。这是一种优势，因为分析控制流和弄清系统如何响应特定输入相对简单。这是一个弱点，因为正常操作的异常难以处理。

图2是并发系统控制的集中管理模型的说明。该模型通常用于没有严格时间限制的“软”实时系统中。中央控制器管理与传感器和致动器相关的一组过程的执行。第20章中讨论的建筑物监控系统使用此控制模型。

图2实时系统的集中控制模型

系统控制器进程根据系统状态变量决定何时启动或停止进程。它检查其他进程是否产生了要处理的信息或将信息传递给它们以进行处理。控制器通常连续循环，轮询传感器和其他过程以了解事件或状态变化。因此，该模型有时称为事件循环模型。

事件驱动控制

在集中控制模型中，控制决策通常由某些系统状态变量的值确定。相反，事件驱动的控制模型由外部生成的事件驱动。在此上下文中，术语事件不仅表示二进制信号。它可能是一个信号，可以采用一定范围的值，也可以是从菜单输入的命令。事件和简单输入之间的区别在于事件的计时不在处理该事件的过程的控制范围之内。

有许多类型的事件驱动系统。其中包括许多编辑器，其中用户界面事件表示编辑命令；在AI中使用的基于规则的生产系统，其中条件变为真会触发动作；在活动对象中，更改对象属性的值会触发某些动作。Garlan等。（1992）讨论了这些不同类型的系统。

在本节中，我将讨论两个事件驱动的控制模型：

广播模型在这些模型中，原则上将事件广播到所有组件。已被编程为处理该事件的任何组件都可以对此做出响应。
中断驱动模型这些模型专门用于由中断处理程序检测到外部中断的实时系统。然后将它们传递到其他组件进行处理。

广播模型可以有效地集成分布在网络上不同计算机上的组件。中断驱动模型用于对时序有严格要求的实时系统。

在广播模型（图1）中，组件会记录对特定事件的兴趣。当这些事件发生时，控制权将转移到可以处理该事件的组件。该模型与集中式模型之间的区别在于，控制策略未嵌入事件和消息处理程序中。组件确定它们需要哪些事件，并且事件和消息处理程序确保将这些事件发送给它们。

图1：基于选择性广播的控制模型

所有事件都可以广播到所有组件，但这会带来大量处理开销。通常，事件和消息处理程序维护组件和它们感兴趣的事件的寄存器。组件会生成事件，这些事件可能表明某些数据可用于处理。事件处理程序检测事件，查阅事件寄存器，然后将事件传递给已声明感兴趣的组件。在更简单的系统中，例如由用户界面事件驱动的基于PC的系统中，存在显式的“事件侦听器”组件，它们侦听来自鼠标，键盘等的事件并将其转换为更具体的命令。

事件处理程序通常还支持点对点通信。一个组件可以显式地将消息发送到另一个组件。该模型有许多变体，例如Field环境（Reiss，1990年）和Hewlett-Packard的Softbench（Fromme，1993年）。这两种方法都已用于控制软件工程环境中的工具交互。CORBA中使用的对象请求代理（ORB）也支持这种控制模型，用于分布式对象通信。

这种广播方法的优点是演进相对简单。通过向事件处理程序注册其事件，可以集成用于处理特定事件类别的新组件。任何组件都可以在不知道其名称或位置的情况下激活任何其他组件。这些组件可以在分布式计算机上实现。这种分布对其他组件是透明的。

该模型的缺点是组件不知道是否或何时处理事件。当组件生成事件时，它不知道哪些其他组件已对该事件进行了关注。不同的组件很有可能注册相同的事件。当提供处理事件的结果时，这可能会导致冲突。

要求快速处理外部事件的实时系统必须是事件驱动的。例如，如果使用实时系统控制汽车中的安全系统，则它必须检测到可能发生的碰撞，并且可能在驾驶员的头部撞到方向盘之前给安全气囊充气。为了对事件提供这种快速响应，您必须使用中断驱动的控制。

中断驱动的控制模型如图2所示。已知中断类型的数量，每种类型都定义了一个处理程序。每种类型的中断都与存储其处理程序地址的内存位置相关。当接收到特定类型的中断时，硬件开关将导致控制立即转移到其处理程序。然后，该中断处理程序可以响应于该中断所通知的事件来启动或停止其他进程。

图2：中断驱动的控制模型

该模型主要用于需要对某些事件做出即时响应的实时系统。它可以与集中式管理模型相结合。中央管理器通过基于中断的紧急控制来处理系统的正常运行。

这种方法的优点是它允许对事件实施非常快速的响应。它的缺点是编程复杂且难以验证。在系统测试期间可能无法复制中断时序的模式。如果中断数量受硬件限制，则很难更改使用该模型开发的系统。一旦达到此限制，就无法处理其他类型的事件。您有时可以通过将几种类型的事件映射到单个中断上来解决此限制。然后，处理程序将确定发生了哪个事件。但是，如果需要对单个中断的快速响应，则中断映射可能不切实际。

参考文献

Fromme B.和Walker，J。（1993）。用于工具和流程集成的开放式体系结构。程序。第六届 软件工程环境，英国雷丁，IEEE出版社。

Reiss S.，P.（1990）。在现场环境中使用消息传递连接工具。IEEE软件，7（4），57-66。