 |
|
|
Архитектура Астрономия Аудит Биология Ботаника Бухгалтерский учёт Войное дело Генетика География Геология Дизайн Искусство История Кино Кулинария Культура Литература Математика Медицина Металлургия Мифология Музыка Психология Религия Спорт Строительство Техника Транспорт Туризм Усадьба Физика Фотография Химия Экология Электричество Электроника Энергетика |
Проектирование класса абстрагирования данных
При централизованном подходе есть только один класс абстрагирования данных - Состояние и План Движения Лифта. Состояние лифта - это его текущее положение (номер этажа) и направление движения (вверх, вниз, стоит). План движения представляет собой список этажей, которые лифт должен посетить. Поскольку есть только один экземпляр указанного класса, мы вправе прибегнуть к централизованному хранилищу, как показано на рис.21а. Чтобы определить операции класса абстрагирования данных, необходимо понять, как к нему обращаются. На рис.19 показаны три разные задачи, обращающиеся к такому объекту: Планировщик, Диспетчер Лифта и Контроллер Лифта (последняя существует в нескольких экземплярах - по одному для каждого лифта). Планировщик читает план и состояние каждого лифта с целью выбрать лифт, которому будет поручено обслуживание нового запроса. Эта функция выполняется внутри операции выбратьЛифт. Диспетчер Лифта обновляет план движения лифта и проверяет, не находится ли лифт в состоянии покоя. Эта функция реализуется операцией обновитьПлан. Задача Контроллер Лифта обращается к объекту Состояние и План Движения Лифта четырьмя способами (путем отправки четырех разных сообщений): чтобы обновить состояние, когда лифт прибыл или отбыл, чтобы проверитьЭтотЭтаж и чтобы проверитьСледующийЭтажНазначения. Каждое из названных сообщений отображается на операцию объекта абстрагирования данных (см. рис.21).
Рис.20. Нераспределенная система управления лифтами: интерфейсы задач
Рис.21. Классы абстрагирования данных: а -для централизованного решения; б - для распределенного решения
Операция проверитьЭтотЭтаж вызывается с параметрами этаж# и лифт#, проверяет, должен ли лифт остановиться на данном этаже, и обновляет состояние и план движения лифта. Операция возвращает состояниеЭтажа: стоп, если лифт должен остановиться, или мимо - в противном случае, а также направление, являющееся предварительным индикатором того, вверх или вниз лифт будет двигаться. Операция проверитьСледующийЭтажНазначения (вызываемая после этого) проверяет, в каком направлении лифту следовать дальше. Она устанавливает состояние лифта равным «вверх», «вниз» или «покой» (если невыполненных запросов нет) и возвращает направление, которое будет равно соответственно запросВверх, запросВниз или нетЗапросов. 9.6. Обсуждение альтернативных архитектур Вместо только что описанной архитектуры мы могли бы ввести для каждого лифта по одному экземпляру задач Интерфейс Кнопок Лифта, Интерфейс Датчиков Прибытия и Диспетчер Лифта в дополнение к задаче Контроллер Лифта. При наличии одного процессора такое решение нежелательно из-за слишком больших накладных расходов. Но в многопроцессорной среде для каждого лифта допустимо иметь свой процессор, на котором будут выполняться экземпляры задач Интерфейс Кнопок Лифта, Интерфейс Датчиков Прибытия, Диспетчер Лифта и Контроллер Лифта. Задачи Планировщик, Интерфейс Кнопок Этажа, Монитор Лампочек Этажа и Монитор Лампочек Направления удобно разместить на отдельном процессоре. В случае нескольких ЦП с общей памятью объект абстрагирования данных Состояние и План Движения Лифта по-прежнему хранился бы в разделяемой памяти. Если же процессоры не располагают общей памятью, то несколько задач не смогут напрямую обращаться к объекту Состояние и План Движения Лифта. Далее мы опишем проект распределенной системы управления лифтами.
Поиск по сайту: |
