Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
1. с 1- 7 исправленная (Восстановлен).docx
Скачиваний:
24
Добавлен:
18.03.2015
Размер:
4.88 Mб
Скачать

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

Перейдем к архитектуре задач в Подсистеме Датчики, изображенной на рис.13. В подсистеме работает только 2 задачи – Задача Измерения текущей температуры и Задача измерения загрязненности воздуха. Обе используют реальные физические объекты Датчик Температуры и Датчик Загрязненности. Эти устройства могут работать синхронно. Поэтому целесообразно объединить описанные задачи в одну – Задача измерения температуры и загрязненности.

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

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

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

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

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

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

Рис.14. Уточненная статическая модель системы управления вентиляцией

Рис.15. Нераспределенная система управления вентиляциями: архитектура задач

Интерфейс между задачами Интерфейс Датчиков и Контроллер Вентиляции (см. рис.15) реализуется как сильно связанный обмен сообщениями (см. рис.16): когда задача Интерфейс Датчиков посылает сообщение о текущей температуре, задача Контроллер Вентиляции неактивна, так как система находит­ся в Активном режиме. Поэтому задача Интерфейс Датчиков не будет задержана на сколько-нибудь длительное время.

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

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

Рис.16. Нераспределенная система управления Вентиляциями: интерфейсы задач