7.3. Выделение задач в подсистеме диспетчера

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

Поскольку речь идет о нераспределенном решении, очевидно, что Диспетчер может напрямую читать Состояние. Архитектура задач для нераспределенного случая представлена на рис. 13.

Рис.13. Нераспределенная система управления дамбой: архитектура задач

7.4. Определение интерфейсов задач

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

Взаимодействие между задачами Интерфейс кнопок и задачей Диспетчер, показанными на рис.13, отображается на слабо связанный обмен сооб­щениями (рис.14). Тем самым гарантируется, что исполнение задач Интерфейс кнопок не будет приостановлено после отправки сообщения задаче Дис­петчер.

Рассмотрим интерфейс между Дис­петчером и двумя зада­чами-мониторами ресурсов: Монитор контроля функционирования шлюза и Монитор контроля исправления ошибок. Дис­петчер дает команды управления Монитору контроля функционирования шлюза и команды управления - Монитору контроля исправления ошибок (см. рис. 13). Подобное взаимодействие отображается на слабо связанный обмен сообщениями, так как несколько экзем­пляров Дис­петчера в состоянии одновременно посылать сообщения Монитору контроля функционирования шлюза или Монитору контроля исправления ошибок (см. рис.14) и при этом не должны блокироваться.

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

Рис.14. Нераспределенная система управления исправлением ошибок: интерфейсы задач

7.5. Проектирование класса абстрагирования данных

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

Чтобы определить операции класса абстрагирования данных, необходимо по­нять, как к нему обращаются. На рис. 14 показана задача, обращающаяся к такому объекту: Диспетчер.

Диспетчер читает план и состояние шлюзов с целью выбрать шлюз, в котором произошла неполадка. Эта функция вы­полняется внутри операции выбратьШлюз. Диспетчер обновляет план работы системы испраления ошибок и проверяет, не произошла ли неполадка в каком-либо шлюзе. Эта функ­ция реализуется операцией обновитьПлан. Каждое из названных сообщений отображается на опера­цию объекта абстрагирования данных (см. рис. 15).

Рис.15. Классы абстрагирования данных: а – для централизованного решения; б – для распределенного решения

Операция проверитьЭтотШлюз вызывается с параметром Шлюз# и проверяет, существует ли неполадка и обновляет состояние и план работы шлюзов. Операция возвращает СостояниеШлюза: поломка, если в шлюзе произошла неполадка, или норма – в противном случае.

Операция проверитьСледующийШлюз (вызываемая после этого) проверяет, есть ли неполадка в каком-либо другом шлюзе. Операция также возвращает СостояниеШлюза: поломка, если в шлюзе произошла неполадка, или норма – в противном случае.