- •1. Описание задачи
- •2. Модель прецедентов
- •2.1. Прецедент «Выбор необходимой температуры»
- •2.2. Прецедент «Поддержание оптимальной частоты воздуха и заданной температуры»
- •2.3. Абстрактные прецеденты
- •2.4. Абстрактный прецедент «Планирование вентиляционной установки при аварии»
- •2.5. Абстрактный прецедент «Забор воздуха с улицы»
- •2.6. Конкретный прецедент «Выбор необходимой
- •2.7. . Конкретный прецедент «Поддержание оптимальной частоты воздуха и заданной температуры»
- •3. Статическая модель предметной области
- •4. Разбиение на объекты
- •5. Динамическая модель
- •5.1. Диаграмма кооперации для прецедента «Выбор необходимой температуры»
- •5.2. Диаграмма кооперации для прецедента «Забор воздуха с улицы»
- •6. Модель состояний
- •7. Консолидация диаграмм кооперации
- •8. Разбиение на подсистемы
- •9. Разбиение системы на задачи
- •9.1. Выделение задач в подсистеме Вентиляции
- •9.2. Выделение задач в подсистеме датчиков
- •9.3. Выделение задач в подсистеме планировщика
- •9.4. Определение интерфейсов задач
- •10. Проект распределенной системы управления вентиляцией
- •10.1. Структура подсистемы вентиляции
- •10.2. Структура подсистемы датчиков
- •10.3. Структура подсистемы планировщика
- •10.4. Интерфейсы подсистем
- •11. Проектирование скрывающих информацию классов
- •11.1. Проектирование классов интерфейса устройств
- •11.2. Проектирование класса, зависящего от состояния
- •12. Разработка детального проекта программы
- •12.1. Проектирование объектов-разъемов для Вентиляции
- •12.2. Проектирование составных задач
- •13. Конфигурирование целевой системы
- •14. Анализ производительности нераспределенной системы управления Вентиляцией
- •14.1. Сценарий для анализа производительности
- •14.2. Последовательности событий
- •14.3. Назначение приоритетов
- •14.4. Планирование в реальном времени для нераспределенной архитектуры
- •14.5. Последовательность событий «Забор воздуха с улицы»
- •14.6. Последовательность событий «Выбор необходимой температуры»
9.2. Выделение задач в подсистеме датчиков
Перейдем к архитектуре задач в Подсистеме Датчики, изображенной на рис.13. В подсистеме работает только 2 задачи – Задача Измерения текущей температуры и Задача измерения загрязненности воздуха. Обе используют реальные физические объекты Датчик Температуры и Датчик Загрязненности. Эти устройства могут работать синхронно. Поэтому целесообразно объединить описанные задачи в одну – Задача измерения температуры и загрязненности.
9.3. Выделение задач в подсистеме планировщика
В случае нераспределенного решения Планировщик — это подсистема, которая состоит из одного объекта-координатора, выделенного в задачу. Задача Планировщик активизируется по запросу, в частности после получения Запроса Температуры, и выбирает действие, наиболее подходящее для его удовлетворения. Таким образом происходит выбор нагревать или охлаждать воздух.
Поскольку речь идет о нераспределенном решении, очевидно, что Планировщик может напрямую читать Состояние и Планирование Вентиляции. Следовательно, различные экземпляры задачи Контроллер Вентиляции не обязаны посылать Планировщику сообщения. Архитектура задач для нераспределенного случая представлена на рис.15.
9.4. Определение интерфейсов задач
Рассмотрим теперь, как определяются интерфейсы задач. В случае интерфейсов обмена сообщениями между параллельными задачами возможен либо слабо связанный, либо сильно связанный обмен. Необходимо исследовать только интерфейсы между объектами, выделенными в самостоятельные задачи. Кроме того, следует точно описать сообщения, включая их имена и параметры.
Взаимодействие между задачами Интерфейс Пультов ДУ и Диспетчер Вентиляции., показанными на рис.15, отображается на слабо связанный обмен сообщениями (рис.16). Тем самым гарантируется, что исполнение задачи Интерфейс Пультов ДУ не будет приостановлено после отправки сообщения задаче Диспетчер Вентиляции. Планировщик посылает сообщения запрос Планировщика в ту же очередь. Поскольку Планировщик в момент передачи ему сообщения часто бывает занят, то интерфейс между задачами Планировщик и Интерфейс Пультов ДУ также отображается на слабо связанный обмен сообщениями (см. рис.16).
Рис.14. Уточненная статическая модель системы управления вентиляцией
Рис.15. Нераспределенная система управления вентиляциями: архитектура задач
Интерфейс между задачами Интерфейс Датчиков и Контроллер Вентиляции (см. рис.15) реализуется как сильно связанный обмен сообщениями (см. рис.16): когда задача Интерфейс Датчиков посылает сообщение о текущей температуре, задача Контроллер Вентиляции неактивна, так как система находится в Активном режиме. Поэтому задача Интерфейс Датчиков не будет задержана на сколько-нибудь длительное время.
Интерфейс между задачами Диспетчер и Контроллер Вентиляции (см. рис.15) реализуется как сильно связанный обмен сообщениями (см. рис.16). Диспетчер Вентиляции может посылать сообщения «греть» или «охлаждать», изменяя задаваемую температуру. Интерфейс является сильно связанным, поскольку Диспетчер способен отправлять сообщения Контроллеру только тогда, когда последний находится в пассивном режиме, следовательно, должен быть активизирован.
Проанализируем пассивные сущностные объекты, к которым обращается сразу несколько задач. Состояние и Планирование Вентиляции - объект абстрагирования данных, который инкапсулирует режим и план работы Вентиляции. В нераспределенном варианте есть только один экземпляр этого объекта, так что можно использовать централизованное хранилище. К объекту осуществляют доступ несколько экземпляров задач Контроллер Вентиляции, Диспетчер Вентиляции, а также Планировщик (см. рис.16). Доступ к пассивному объекту должен быть синхронизирован, чтобы его операции исполнялись взаимно исключающим образом.
Рис.16. Нераспределенная система управления Вентиляциями: интерфейсы задач