8.2. Структура подсистемы шлюзов

В описанном выше распределенном решении существует по одному экзем­пляру Подсистемы шлюзов для каждого шлюза. В каждом таком экземпляре есть по одному экземпляру задач Интерфейс датчика неполадок шлюза и Интерфейс датчика исправления ошибок.

Архитектура задач для Подсистемы шлюзов показана на рис. 19. Она ана­логична архитектуре для нераспределенного решения с тем отли­чием, что экземпляров подсистем существует несколько. Интерфейсы задач для пересмотренной архитектуры изображены на рис. 20.

Рис. 19. Архитектура задач для подсистемы шлюзов

Рис. 20. Архитектура задач для подсистемы шлюзов: интерфейсы задач

8.3. Структура подсистемы диспетчера

Существует единственный экземпляр Подсистемы шлюзов, которая со­стоит из двух задач и одного скрывающего информацию объекта. Это объект аб­страгирования данных Сводное Состояние, который содержит текущее состояние каждого шлюза, описывающий, существует ли неполадка в работе шлюза или нет.

В любом узле доступ к объекту Локальное Состояние осуществляется со стороны задач Диспетчер. Серверная задача принимает сообщения о состоянии шлюза и обновляет объект Сводное Состояние, а координирующая задача принимает Запросы на обслуживание от нескольких экземпляров задачи Интерфейс кнопок. Каждый раз при получении сообщения Запрос на обслуживание задача Диспетчер проверяет, по отношении к какому шлюзу осуществляется запрос. Архитектура задач для Подсистемы диспетчера показана на рис. 21. Интерфейсы задач для пересмотренной архитектуры изображены на рис. 22.

Рис. 21. Архитектура задач для подсистемы диспетчера

Рис. 22. Архитектура задач для подсистемы диспетчера: интерфейсы задач

8.4.Интерфейсы подсистем

После определения интерфейсов задач во всех подсистемах можно обно­вить архитектуру распределенной программы с целью показа интерфейсов под­систем (см. рис. 23). На самом деле все интерфейсы принадлежат той или иной из ранее рассмотренных задач.

Рис. 23. Архитектура распределенной программы: интерфейсы подсистем

9. Проектирование скрывающих информацию классов

Сами классы были определены на этапе разбиения на объекты, теперь речь пойдет о проектировании их операций. Классы абстрагирования данных описа­ны выше; в этом разделе мы разработаем остальные классы, скрывающие инфор­мацию.

9.1. Проектирование классов интерфейса устройств

Класс интерфейса устройства скрывает истинный интерфейс с физическим устройством, предлагая вместо него виртуальный интерфейс. Для каждого типа устройств ввода/вывода имеется отдельный интерфейсный класс. Состав опера­ций, поддерживаемых таким классом, зависит от функций, которые должен под­держивать объект интерфейса. Классы интерфейса устройств изображены на рис.24 и описаны ниже:

– Интерфейс Кнопок Прибора. Предоставляет две операции: читать (считы­вает значение датчика кнопки прибора) и инициализировать;

– Интерфейс Датчика Яркости. Предоставляет две операции: читать (считывает значение датчика поломок) и инициализировать;

– Интерфейс Поля индикации. Предоставляет две операции: читать (считывает значение поля индикации) и инициализировать;

9.2. Проектирование класса, зависящего от состояния

В системе есть только один зависящий от состояния класс Управление дамбой. Он поддерживает две операции: обработать состояние и текущее состояние. Этот объект вложен в задачу Диспетчер. Поскольку задача существует в нескольких экземплярах, то и экземпляров класса будет несколько – по одному для каждого прибора. Спецификация класса Управ­ление дамбой представлена на рис.25.

Рис. 24. Классы интерфейса устройств

Рис. 25. Зависящий от состояния управляющий класс