Разбиение системы на задачи

В распределённой системе управления освещением помещений имеется по одному экземпляру Подсистемы Этажа (подсистемы сбора данных от всех датчиков на этаже) на каждый этаж и по одному экземпляру Подсистем управления Лампами и Жалюзи на всё здание (см. рис. 9).

В случае нераспределённой системы можно упростить следующее:

1) все подсистемы сбора данных (Подсистемы Этажа) можно объединить в одну централизованную подсистему сбора данных;

2) обе управляющие подсистемы (управления лампами и жалюзи) объединить в одну универсальную управляющую подсистему, поскольку принцип работы обеих подсистем практически идентичен, за исключением того, что они изменяют состояние разных объектов — ламп и жалюзи, т. е. будут немного отличаться структуры отправляемых сигналов (кортежи параметров).

9. 1. Выделение задач в Подсистеме Этажа

В нераспределённой системе управления освещением Подсистема Этажа в соответствии с диаграммой своей структуры разбивается на 3 задачи: Интерфейс Выключателей, Интерфейс Датчиков яркости и Интерфейс Датчиков движения. Каждая задача имеет по одному экземпляру.

В ходе разбиения на задачи каждый объект Управление Лампами отображается на отдельную задачу Контроллер Ламп, а каждый объект Управление жалюзи — на задачу Контроллер Жалюзи.

Предварительная архитектура задач изображена на начальной диаграмме параллельной кооперации:

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

9. 2. Выделение задач в Подсистеме управления лампами и жалюзи

В универсальной Подсистеме, управляющей и лампами, и моторами жалюзи, можно выделить 4 задачи: Диспетчер ламп и жалюзи, Монитор ламп, Монитор жалюзи, Контроллер ламп и жалюзи. Все задачи имеют по одному экземпляру. Как уже было сказано, это обусловлено практически идентичным принципом работы Подсистемы управления лампами и Подсистемы управления жалюзи (немного отличаются только «форматы» передаваемых сообщений, в частности, в сообщениях, касающихся моторов жалюзи, имеется дополнительный параметр, а именно значение уровня, до которого нужно поднять / опустить жалюзи, т. е. «длительность» непрерывной работы мотора до остановки).

Диспетчер ламп и жалюзи (всего один экземпляр в нераспределенном решении) реализуется асинхронно по отношению к задаче Контроллер Ламп, так как запрос к любой лампе может прийти в любой момент.

Мониторы ресурсов позволяют сериализовать обработку параллельных запросов, принятых от универсального контроллера (для ламп и жалюзи).

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

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

Рассмотрим следующие взаимосвязи между различными задачами:

(1) Интерфейс Датчиков яркости — Диспетчер ламп и жалюзи;

(2) Интерфейс Датчиков движения — Диспетчер ламп и жалюзи;

(3) Контроллер ламп и жалюзи — Монитор ламп;

(4) Контроллер ламп и жалюзи — Монитор жалюзи;

(5) Диспетчер ламп и жалюзи — Контроллер ламп и жалюзи.

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

То же самое выполняется и для взаимосвязи (2).

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

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

Интерфейс (5) между задачами Диспетчер Ламп и Жалюзи и Контроллер Ламп и жалюзи (см. рис. 13) реализуется как слабо связанный обмен сообщениями (см. рис. 14). Диспетчер посылает Контроллеру номера добавленных в План сообщений о включении / выключении ламп и поднятии / опускании жалюзи. Контроллер по параметрам выбранного сообщения определяет, какому Монитору нужно его передать.

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

Нужно учесть, что в рамках функции изменитьСостояние[Лампы | Жалюзи](in запись, out ответ) сначала проверяется состояние того или иного элемента с помощью функции проверитьСостояние[Лампы | Жалюзи](in координатыЭлемента, out состояние).

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

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

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

Диспетчер принимает сообщения от Датчиков и Выключателей и на основании этих данных обновляет План включения ламп и жалюзи. Также Диспетчер отсылает номера добавленных записей Контроллеру, который выбирает из Плана записи по данным номерам и распределяет их по Мониторам (в зависимости от параметров в сообщении).

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

9. 5. Обсуждение альтернативных архитектур

В соответствии с архитектурой нераспределённой версии системы мы объединили две подсистемы - Подсистему управления лампами и Подсистему управления жалюзи - в одну ввиду схожести принципа работы обеих подсистем. Однако при наличии одного процессора такое решение нежелательно из-за слишком больших накладных расходов.

Но в многопроцессорной среде для каждой Подсистемы допустимо иметь свой процессор, на котором будут выполняться экземпляры задач Диспетчер, Контроллер (количество теперь равняется количеству этажей в здании), Монитор (ламп либо жалюзи). Что касается объекта абстрагирования данных Состояние и План включения, то здесь можно выбрать одно из двух решений:

· В случае нескольких ЦП с общей памятью объект абстрагирования данных по-прежнему хранился бы в разделяемой памяти;

· Можно не объединять объекты абстрагирования, а оставить их в своих Подсистемах: Состояние и План включения ламп оставить в Подсистеме управления лампами, а объект Состояние и План включения моторов жалюзи — в Подсистеме управления жалюзи.