- •Пример системы управления лифтами
- •1. Описание задачи
- •2. Модель прецедентов
- •2.1. Прецедент «Выбор Этажа Назначения»
- •2.2. Прецедент «Вызов Лифта»
- •2.3. Абстрактные прецеденты
- •2.4. Абстрактный прецедент «Остановка Лифта на Этаже»
- •2.5. Абстрактный прецедент «Планирование Лифта»
- •2.6. Конкретный прецедент «Выбор Этажа Назначения»
- •2.7. Конкретный прецедент «Вызов Лифта»
- •18.3. Статическая модель предметной области
- •5. Динамическая модель
- •5.1. Диаграмма кооперации для прецедента «Выбор Этажа Назначения»
- •5.2. Диаграмма кооперации для прецедента «Вызов Лифта»
- •5.3. Диаграмма кооперации для прецедента «Остановка Лифта на Этаже»
- •5.4. Абстрактный прецедент «Отправить Лифт»
- •6. Модель состояний
- •7. Консолидация диаграмм кооперации
- •8. Разбиение на подсистемы
- •9. Разбиение системы на задачи
- •9.1. Выделение задач в подсистеме лифта
- •9.2. Выделение задач в подсистеме этажа
- •9.3. Выделение задач в подсистеме планировщика
- •9.4. Определение интерфейсов задач
- •9.5. Проектирование класса абстрагирования данных
- •9.6. Обсуждение альтернативных архитектур
- •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. Последовательность событий «Выбор Этажа Назначения»
- •14.7. Последовательность событий «Вызов Лифта»
- •15. Анализ производительности распределенной системы управления лифтами
- •15.1. Сценарий для анализа производительности
- •15.2. Планирование в реальном времени для распределенной архитектуры
- •15.3. Последовательность событий «Остановка Лифта на Этаже»
- •15.4. Последовательность событий «Выбор Этажа Назначения»
- •15.5. Последовательность событий «Вызов Лифта»
9.2. Выделение задач в подсистеме этажа
Перейдем к архитектуре задач в Подсистеме Этажа, изображенной на рис.17. Объект Интерфейс Кнопки Этажа выделяется в самостоятельную задачу Интерфейс Кнопок Этажа на основе критерия асинхронного интерфейса устройства ввода и критерия группировки задач. В случае нераспределенного решения задача Интерфейс Кнопок Этажа отвечает за обработку ввода от всех кнопок этажа. Она активизируется прерыванием, обрабатывает его и посылает Запрос на Обслуживание объекту Планировщик, после чего готова к приходу следующего прерывания.
Лампочки этажа и направления - это пассивные устройства вывода. С ними взаимодействуют объекты Интерфейс Лампочки Этажа и Интерфейс Лампочки Направления. Бывает так, что различные экземпляры задачи Контроллер Лифта одновременно посылают запросы лампочкам. В таком случае необходимо иметь для каждого устройства задачу-монитор ресурса, которая сможет сериализовать обработку параллельных запросов. Итак, выявилась потребность в задачах Монитор Лампочек Этажа и Монитор Лампочек Направления. Все объекты Интерфейс Лампочки Этажа отображаются на задачу Монитор Лампочек Этажа. Все объекты Интерфейс Лампочки Направления отображаются на задачу Монитор Лампочек Направления. Задачи, из которых состоит Подсистема Этажа в нераспределенной системе управления лифтами, показаны на рис.19. Вместо этого допустимо завести единственный монитор ресурсов для лампочек этажа и направления, однако первоначальное решение обладает большей гибкостью.
9.3. Выделение задач в подсистеме планировщика
В случае нераспределенного решения Планировщик — это подсистема, которая состоит из одного объекта-координатора, выделенного в задачу. Задача Планировщик активизируется по запросу, в частности после получения Запроса на Обслуживание, и выбирает лифт, наиболее подходящий для его удовлетворения.
Поскольку речь идет о нераспределенном решении, очевидно, что Планировщик может напрямую читать Состояние и План Движения Лифта. Следовательно, различные экземпляры задачи Контроллер Лифта не обязаны посылать Планировщику сообщения Прибыл и Отбыл. Архитектура задач для нераспределенного случая представлена на рис.19.
9.4. Определение интерфейсов задач
Рассмотрим теперь, как определяются интерфейсы задач. В случае интерфейсов обмена сообщениями между параллельными задачами возможен либо слабо связанный, либо сильно связанный обмен. Необходимо исследовать только интерфейсы между объектами, выделенными в самостоятельные задачи. Кроме того, следует точно описать сообщения, включая их имена и параметры.
Взаимодействие между задачами Интерфейс Кнопок Лифта и Диспетчер Лифта, показанными на рис.19, отображается на слабо связанный обмен сообщениями (рис.20). Тем самым гарантируется, что исполнение задачи Интерфейс Кнопок Лифта не будет приостановлено после отправки сообщения задаче Диспетчер Лифта. Планировщик посылает сообщения запрос Планировщика в ту же очередь. Поскольку Планировщик в момент передачи ему сообщения часто бывает занят, то интерфейс между задачами Планировщик и Интерфейс Кнопок Лифта также отображается на слабо связанный обмен сообщениями (см. рис.20).
Рис.19. Нераспределенная система управления лифтами: архитектура задач
Интерфейс между задачами Интерфейс Датчиков Прибытия и Контроллер Лифта (см. рис.19) реализуется как сильно связанный обмен сообщениями (см. рис.20): когда задача Интерфейс Датчиков Прибытия посылает сообщение приближается к Этажу, задача Контроллер Лифта неактивна, так как находится в состоянии Лифт Едет. Поэтому задача Интерфейс Датчиков Прибытия не будет задержана на сколько-нибудь длительное время.
Интерфейс между задачами Диспетчер Лифта и Контроллер Лифта (см. рис.19) реализуется как сильно связанный обмен сообщениями (см. рис.20). Диспетчер Лифта может посылать сообщения «вверх» или «вниз». Интерфейс является сильно связанным, поскольку Диспетчер Лифта способен отправлять сообщения Контроллеру Лифта только тогда, когда последний находится в состоянии Лифт Стоит и, следовательно, должен быть активизирован.
Рассмотрим теперь интерфейс между Контроллером Лифта и двумя задачами-мониторами ресурсов: Монитор Лампочек Этажа и Монитор Лампочек Направления. Контроллер Лифта дает команды управления лампочками этажа Монитору Лампочек Этажа и команды управления лампочками направления - Монитору Лампочек Направления (см. рис.19). Подобное взаимодействие отображается на слабо связанный обмен сообщениями, так как несколько экземпляров Контроллера Лифта в состоянии одновременно посылать сообщения Монитору Лампочек Этажа или Монитору Лампочек Направления (см. рис.20) и при этом не должны блокироваться.
Проанализируем пассивные сущностные объекты, к которым обращается сразу несколько задач. Состояние и План Движения Лифта - объект абстрагирования данных, который инкапсулирует состояние и план движения лифта. В нераспределенном варианте есть только один экземпляр этого объекта, так что можно использовать централизованное хранилище. К объекту осуществляют доступ несколько экземпляров задач Контроллер Лифта, Диспетчер Лифта, а также Планировщик (см. рис.20). Доступ к пассивному объекту должен быть синхронизирован, чтобы его операции исполнялись взаимно исключающим образом.
