Если необходима передача вызовов не всем получателям, а только некоторым, то используется адресное распределение. Поскольку тип используемого адреса заранее не определен, то для сравнения адресов нужно использовать предикаты.
На этом изложение теоретического материала можно считать законченным. Далее рассмотрим, как обратные вызовы используются в практике разработки ПО.
6. Практическое использование обратных вызовов
Итак, мы изучили теоретические основы проектирования обратных вызовов, теперь пришло время продемонстрировать, как они используются в реальных системах. Для иллюстрации мы воспользуемся примером разработки модуля управления датчиками из проекта «автоматизированная система управления технологическими процессами», в котором когда-то принимал участие автор. Данный пример адаптирован, в нем опущены многие детали, которые не имеют отношения к рассматриваемой теме. Мы пройдемся через основные этапы проектирования и проследим, как обратные вызовы используются в реальных инженерных задачах.
Подробное описание всех компонентов модуля заняло бы слишком много места и навряд ли имеет практическую ценность, поэтому мы будем рассматривать самые общие принципы функционирования с акцентом на использование обратных вызовов. Полностью проект можно посмотреть здесь: https://github.com/Tkachenko-vitaliy/Callbacks/tree/master/Sensor.
6.1. Разработка архитектуры
6.1.1. Техническое задание
Первый вопрос, который должен быть задан перед началом разработки чего бы то ни было, звучит следующим образом: что мы будем разрабатывать и что мы хотим в итоге получить? Этот вопрос совсем не тривиальный, как может показаться вначале. Без ясного осознания конечной цели, без четкого понимания свойств и характеристик, которыми должна обладать проектируемая система, разработка может растянуться до бесконечности: происходят постоянные переделки, доработки, хаотичная реализация все новых и новых функций с не очень понятной ценностью, и т. п. В итоге, вместо результата мы сосредотачиваемся на процессе, а конечная цель пропадает где-то за горизонтом. Не сталкивались с такими проектами? Что ж, вам крупно повезло; чтобы также везло в дальнейшем, и подобные проекты в вашей карьере отсутствовали, любое проектирование нужно начинать с постановки целей, которые выражаются в требованиях, предъявляемых к системе. В нашем случае они будут следующими.
Разработать модуль управления датчиками, который должен обеспечивать:
1. Настройку конфигурации датчиков и возможность ее изменения в процессе работы.
2. Отслеживание состояния и определение неисправности датчиков.
3. Считывание показаний отдельных датчиков.
4. Считывание показаний всех работоспособных датчиков.
5. Асинхронный опрос показаний.
6. Возможность получения минимальных и максимальных значений для группы датчиков.
7. Настройка пороговых значений показателей и уведомление при их превышении.
8. Возможность работы как с реальными физическими датчиками, так и с их программными моделями.
6.1.2. Сценарий функционирования
Базовый сценарий функционирования модуля следующий.
Основным компонентом, поставляющим информацию, являются датчики. Они могут производить измерения трех типов: текущее, сглаженное и производное. Для идентификации датчикам присваиваются уникальные номера.
Перед началом работы производится настройка, т. е. определяется состав датчиков, с которых будут сниматься показания. Настройка не статическая, она может изменяться в процессе работы.
В любой момент приложение может запросить показания датчиков как в синхронном, так и в асинхронном режиме. Показания возвращаются только для функционирующих датчиков, в приложении должна иметься возможность проверить их работоспособность.
Коммуникация с датчиками осуществляется через протокол USB либо Ethernet путем пересылки / получения команд в соответствии с заданным протоколом.
В процессе работы модуль должен отслеживать и уведомлять приложение о том, что некоторые показатели превышают заданные пороговое значение. Состав измеряемых значений и их предельные величины настраиваются приложением.
В соответствии с описанием структура системы может быть представлена следующим образом (Рис. 26).
В соответствии с описанием структура системы может быть представлена следующим образом (Рис. 26).
Рис. 26. Структурная схема
Приложение через интерфейс обращается к функциям модуля. В зависимости от вызываемой функции интерфейс обращается к соответствующим компонентам и возвращает результат.
Компонент «Асинхронный вызов» предназначен для выполнения асинхронных вызовов. «Наблюдатель» предназначен для отслеживания пороговых значений. «Контейнер» хранит список датчиков. Компонент «Датчик» через компонент «драйвер» обращается к аппаратному обеспечению.
6.1.3. Декомпозиция системы
Итак, в соответствии методологией объектно-ориентированного анализа необходимо определить состав классов и связи между ними, отражающие предметную область. Нам будут необходимы следующие классы:
класс для работы с датчиком;
контейнер для хранения указанных классов;
драйвер, обеспечивающий низкоуровневое взаимодействие с аппаратурой;
очередь для выполнения асинхронных запросов;
класс для отслеживания пороговых значений;
интерфейсный класс, который будет взаимодействовать с приложением для вызовов соответствующих функций модуля.
Обобщенная диаграмма классов модуля представлена на Рис. 2735.
Рис. 27. Обобщенная диаграмма классов
Класс ISensorControl объявляет интерфейс модуля, класс SensorControl реализует указанный интерфейс. SensorControl содержит классы Observer (отслеживает пороговые значения), CommandQueue (очередь комманд для асинхронных запросов), SensorContainer (реализует контейнер для хранения классов для работы с датчиком).
Интерфейс для работы с датчиками объявлен в классе ISensor, обощенная реализация интерфейса осуществляется в классе SensorAbstract. Указанный класс хранит указатель на IDriver, который используется для получения значений датчиков. В классе IDriver объявляется интерфейс для взаимодействия с аппаратурой.
6.2. Реализация классов
6.2.1. Общие определения
В Листинг 86 представлены общие объявления типов.
Листинг 86. Общие объявления типов (SensorDef.h)namespace sensor
{
class ISensor;
class IDriver;
using SensorNumber = unsigned int; // (1)
using SensorValue = double; // (2)
using CheckAlertTimeout = unsigned int; // (3)
enum class SensorType : uint32_t // (4)
{
Spot = 0,
Smooth = 1,
Derivative = 2,
};
enum class DriverType : uint32_t // (5)
{
Simulation = 0,
Usb = 1,
Ethernet = 2
};
enum class AlertRule : uint32_t // (6)
{
More = 0,
Less = 1
};
using SensorPointer = std::shared_ptr<ISensor>; // (7)
using DriverPointer = std::shared_ptr<IDriver>; // (8)
using SensorValueCallback = std::function<void(SensorNumber, SensorValue)>; // (9)
using SensorAlertCallback = std::function<CheckAlertTimeout(SensorNumber, SensorValue)>; // (10)
}; //namespace sensor
В строке 1 объявлен тип для номера датчика, в строке 2 объявлен тип значения, возвращаемого датчиком. В строке 3 объявлен тип значения интервала опроса датчиков для сигнализации пороговых значений.
В строке 4 объявлены идентификаторы типов датчиков, в строке 5 объявлены идентификаторы драйверов. В строке 6 объявлены идентификаторы правил для задания пороговых значений (сигнализация превышения или опускания ниже заданного значения).
В строке 7 объявлен тип для хранения указателей классов датчиков, в строке 8 тип для хранения указателей классов драйверов. В строке 9 объявлен тип обратного вызова, в который передается значение датчика, в строке 10 тип обратного вызова, в который передается значение датчика в случае срабатывания сигнализации порогового значения.
6.2.2. Обработка ошибок
В процессе работы любой программы могут ситуации, приводящие к ошибкам. Причины ошибок могут быть самыми различными: неправильные действия пользователя, некорректная работа ПО, сбои в работе оборудования и т. п. Таким образом, возникает необходимость реализации подсистемы обработки ошибок, которая осуществляет восстановление работоспособности компонента после возникновения ошибочной ситуации и уведомление об этом пользователя.