Централизованное управление

В модели централизованного управления одна из систем назначается главной и управляет работой других подсистем. Такие модели можно разбить на два класса, в зависимости от то­го, последовательно или параллельно реализовано выполнение управляемых подсистем.

1. Модель вызова-возврата. Это известная модель организации вызова программных процедур "сверху вниз", в которой управление начинается на вершине иерархии процедур и через вызовы передается на более нижние уровни иерархии. Данная модель применима только в последовательных системах.

2. Модель диспетчера. Применяется в параллельных системах. Один системный компо­нент назначается диспетчером и управляет запуском, завершением и координиро­ванием других процессов системы. Процесс (выполняемая подсистема или модуль)

может протекать параллельно с другими процессами. Модель такого типа приме­нима также в последовательных системах, где управляющая программа вызывает отдельные подсистемы в зависимости от значений некоторых переменных состоя­ния. Обычно такое управление реализуется через оператор case.

Системы, управляемые событиями

В моделях централизованного управления, как правило, управление системой опреде­ляется значениями некоторых переменных ее состояния. В противоположность таким моделям существуют системы, управление которыми основано на внешних событиях. В данном контексте под событием подразумевается не только бинарный сигнал типа "да-нет". Здесь сигнал может принимать некоторый диапазон значений. Различие между событием и обычными входными данными заключается в том, что планирование события выходит за рамки управления процессом, обрабатывающим это событие. Для обработки события подсистеме необходим доступ к информации состояния, однако такая информация обыч­но не определяется потоком управления.

Разработано множество различных типов событийно-управляемых систем. К ним относят­ся электронные таблицы, в которых изменение значения в какой-либо ячейке изменяет содер­жимое других ячеек, системы искусственного интеллекта, в которых при выполнении некото­рого условия происходит инициирование действия либо используются активные объекты, то­гда при изменении значения свойства объекта инициируется некоторое действие. В этом разделе описаны две модели систем, управляемых событиями.

1. Модели передачи сообщений. В этих моделях событие представляет собой передачу со­общения всем подсистемам. Любая подсистема, которая обрабатывает данное со­бытие, отвечает на него.

2. Модели, управляемые прерываниями. Такие модели обычно используются в системах реального времени, где внешние прерывания регистрируются обработчиком пре­рываний, а обрабатываются другим системным компонентом.

Модульная декомпозиция

После этапа разработки системной структуры в процессе проектирования следует этап декомпозиции подсистем на модули. Между разбивкой системы на подсистемы и подсис­тем на модули нет принципиальных отличий. На этом этапе можно использовать модели, рассмотренные в разделе 10.1. Однако компоненты модулей обычно меньше компонентов подсистем, поэтому можно использовать специальные модели декомпозиции.

Здесь рассматриваются две модели, используемые на этапе модульной декомпозиции подсистем.

2. Модель потоков данных. Система состоит из функциональных модулей, которые по­лучают на входе данные и преобразуют их некоторым образом в выходные данные. Такой подход часто называется конвейерным.

В объектно-ориентированной модели модули представляют собой объекты с собственными состояниями и определенными операциями над этими состояниями. В модели потоков данных модули выполняют функциональные преобразования. В обеих моделях мо­ли реализованы либо как последовательные компоненты, либо как процессы.

По возможности разработчикам не стоит принимать поспешных решений о том, будет [ система параллельной или последовательной. Проектирование последовательной системы имеет ряд преимуществ: последовательные программы легче проектировать, реализовать, проверять и тестировать, чем параллельные системы, где очень сложно формализовать, управлять и проверять временные зависимости между процессами. Лучше сначала разбить систему на модули, а на этапе реализации решить, как организовать их выполнениe — последовательно или параллельно.