Аналогично классу Keypad, класс LCDDevice не понимает, зачем он выводит тот или иной элемент на экран. Это дает возможность свободно оперировать нашими абстракциями, однако требует наличия некоего внешнего агента, выполняющего функции посредника между датчиками и дисплеем. Мы отложим рассмотрение соответствующей абстракции до того, как изучим некоторые сценарии работы системы.
Последним классом, на который следует обратить внимание, является таймер. Сделаем упрощающее предположение о том, что таймер будет один на всю систему, и что системные прерывания будут осуществляться с периодичностью 60 раз в секунду. Лучше если детали реализации подобного таймера будут скрыты от остальных абстракций. Для этого можно организовать еще один класс, использующий функцию обратного вызова (техника callback объяснена в разделе 2.2) и экспортирующий только статические элементы класса (тем самым мы наложим ограничение на систему, запрещающее создание более чем одного таймера).
На рис. 8-6 приведена диаграмма взаимодействий, иллюстрирующая применение данной абстракции. На ней видно, как клиент взаимодействует с таймером:
сначала клиент передает таймеру функцию обратного вызова, а затем с периодичностью в 0.1 секунды таймер вызывает эту функцию. Тем самым мы освобождаем клиента от заботы о том, как осуществляются прерывания, а таймер - от необходимости знать, что при этом прерывании делать. Единственным требованием к клиенту должно быть ограничение на продолжительность выполнения функции обратного вызова - оно не должно превышать 0.1 секунды, в противном случае таймер может пропустить событие.
Класс Timer, осуществляющий прерывания, является активной абстракцией, он инициирует цепочку управляющих команд. Его можно формализовать с помощью следующего описания:
Имя:
Timer
Ответственность:
Осуществление прерываний и диспетчеризация функций обратного вызова.
Операции:
setCallback() - установка функции обратного вызова
Сценарии
Определив в рамках нашей системы основные абстракции, продолжим анализ задачи и рассмотрим некоторые сценарии работы системы. Начнем с составления списка ситуаций. С точки зрения пользователя список будет выглядеть примерно следующим образом:
• Мониторинг первичных измеряемых параметров: скорости и направления ветра, температуры, барометрического давления и влажности.
• Мониторинг производных параметров: коэффициента жесткости погоды, точки образования росы, трендов температуры и барометрического давления.
• Показ максимальных и минимальных значений выбранных параметров.
• Установка времени и даты.
• Калибровка выбранных датчиков.
• Включение системы.
Добавим еще две дополнительные ситуации:
• Отказ питания.
• Отказ датчика.
Исследуем вышеприведенные сценарии для того, чтобы понять поведение (именно поведение, а не внутреннюю структуру) системы.
Главной задачей системы является мониторинг основных измеряемых параметров. Одним из ограничений является невозможность обрабатывать информацию с частотой, превышающей 60 измерений в секунду. К счастью, наиболее интересные для нас погодные параметры меняются с гораздо меньшей скоростью. Дополнительный анализ показывает, что для своевременной регистрации изменений различных погодных параметров достаточно обеспечить следующие частоты снятия информации:
• каждые 0.1 секунды направление ветра
• каждые 0.5 секунды скорость ветра
• каждые 5 минут температура, барометрическое давление и влажность
Ранее мы приняли решение о том, что классы датчиков не должны отвечать за организацию периодических измерений. Эта работа лежит в сфере ответственности внешнего агента, взаимодействующего с датчиками. Отложим пока описание поведения данного агента (оно определяется в большей степени особенностями реализации системы и будет рассмотрено на этапе проектирования). Диаграмма взаимодействий, приведенная на рис. 8-7, иллюстрирует в некоторой степени сценарий его работы. Мы видим, что когда агент начинает обработку измерений, он последовательно опрашивает датчики, однако при этом может пропускать те из них, для которых интервал опроса больше 0.1 секунды. Такая схема, в отличие от той, где каждый датчик самостоятельно отвечает за измерение, обеспечивает более предсказуемое поведение системы, потому что контроль за процессом считывания параметров сосредоточен в одном месте, а именно, в экземпляре класса-агента. Назовем этот класс Sampler.
Продолжим рассмотрение данного сценария. Теперь нам предстоит решить, какие из объектов, приведенных на диаграмме, должны отвечать за вывод информации на экран дисплея, то есть, фактически, за передачу данных экземпляру класса LCDDevice. Здесь возможны два варианта: можно передать ответственность за эти действия самим классам датчиков (подобная схема реализована в архитектурах, подобных MVC), либо создать отдельный класс для связи между датчиками и дисплеем. В данном случае мы выбираем второй вариант, так как он позволяет нам изолировать в рамках одного класса все проектные решения, касающиеся механизмов реализации вывода параметров на экран. В итоге к результатам нашего анализа добавляется описание еще одного класса:
Имя:
DisplayManager
Ответственность:
Организация отображения параметров на экране дисплея.
Операции:
drawStaticItems - рисование статических элементов displayTime - вывод времени displayDate - вывод даты displayTemperature - вывод температуры displayHumidity - вывод влажности displayPressure - вывод давления displayWindChill - вывод коэффициента жесткости погоды displayDewPoint - вывод точки росы displayWindSpeed - вывод скорости ветра displayWindDirection - вывод направления ветра displayHighLow - вывод максимальных и минимальных значений
Операция drawStaticItems рисует на экране ту часть изображения, которая не изменяется в процессе работы системы, например, розу ветров для индикации направления ветра. Мы также предполагаем, что операции displayTemperature и displayPressure ответственны за вывод на экран трендов соответствующих параметров (следовательно, когда мы перейдем к реализации проекта, надо будет выработать подходящие сигнатуры этих операций).
На рис. 8-8 приведена диаграмма классов, иллюстрирующая связи между абстракциями, ответственными за вывод информации на экран, и роль каждой из них в обеспечении заданного сценария.
Отметим еще одно важное преимущество нашего решения о выделении отдельного класса DisplayManager. Задача локализации системы для различных стран предполагает изменение языка, на котором информация выводится на дисплей. Наличие отдельного класса, ответственного за вывод сообщений на экран, существенно облегчает процесс локализации, так как имена
