- •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. Последовательность событий «Выбор необходимой температуры»
10.2. Структура подсистемы датчиков
В описанном выше распределенном решении существует по одному экземпляру Подсистемы Датчиков для каждого помещения.
Архитектура задач для Подсистемы Датчика показана на рис.20. Она аналогична архитектуре для нераспределенного решения (см. рис.15) с тем отличием, что экземпляров подсистем существует несколько.
Задача Интерфейс Пульта ДУ посылает Запросы на Обслуживание, содержащие информацию о требуемой температуре, Планировщику. Интерфейсы задач для пересмотренной архитектуры изображены на рис.16.
Рис.18. Архитектура задач для Подсистемы Вентиляции
Рис.19. Архитектура задач для подсистемы Вентиляции: интерфейсы задач
Рис.20. Архитектура задач для Подсистемы Датчиков
10.3. Структура подсистемы планировщика
Существует единственный экземпляр подсистемы Планировщик, которая состоит из двух задач и одного скрывающего информацию объекта. Это объект абстрагирования данных Сводное Состояние и Планирование Вентиляции, который содержит текущее состояние каждого Вентиляции и план его работы, описывающий, как Вентиляция работает: обогревает или охлаждает (см. рис.21б).
В любом узле доступ к объекту Локальное Состояние и Планирование Вентиляции осуществляется со стороны задач Контроллер Вентиляции и Диспетчер Вентиляции. Но, чтобы Планировщик знал состояния и планы работ всех Вентиляции, каждый Контроллер Вентиляции посылает ему сообщения о состоянии, извещающие о достижении Вентиляцией температуры. Кроме того, Диспетчер Вентиляции передает Планировщику два вида сообщений об обязательствах Вентиляции с уведомлением о том, какую температуру Вентиляция должен обеспечивать.
Подсистема Планировщика разбита на две задачи: Сервер Состояния и Планирование Вентиляции (серверная задача) и Планировщик Вентиляции (координирующая задача). Первая принимает сообщения о состоянии и обязательствах Вентиляции и обновляет объект Сводное Состояние и Планирование Вентиляции, а вторая принимает Запросы на Обслуживание от нескольких экземпляров задачи Интерфейс Пультов ДУ.
Архитектура задач для Подсистемы Планировщика показана на рис.22. Интерфейсы задач для пересмотренной архитектуры изображены на рис.23.
Объект абстрагирования данных Сводное Состояние и Планирование Вентиляции предоставляет операции, температура достигнута, пик загрязненности, обновить План и выбрать Вентиляция (см. рис.216 и 23). Задача Сервер Состояния и Планирование Вентиляции вызывает операции обогревать или охлаждать, когда получает сообщение о состоянии. При получении сообщения об обязательстве Вентиляции она вызывает операцию обновить План.
10.4. Интерфейсы подсистем
После определения интерфейсов задач во всех трех подсистемах можно обновить архитектуру распределенной программы с целью показа интерфейсов подсистем (см. рис.24). На самом деле все интерфейсы принадлежат той или иной из ранее рассмотренных задач.
11. Проектирование скрывающих информацию классов
Сами классы были определены на этапе разбиения на объекты, теперь речь пойдет о проектировании их операций. Классы абстрагирования данных описаны выше; в этом разделе мы разработаем остальные классы, скрывающие информацию.
Рис.22. Архитектура задач для Подсистемы Планировщика