Уважаемые господа!
Удивительно, насколько многим людям приходится делать системы сбора данных (ССД), в том или ином виде. И всем приходится решать по сути одни и те же задачи. И все решают по-разному, но все решения объединяет одно: пишется долго и муторно, часто - неудачно. Конечно, педагогическую ценность пути "через тернии к звездам" никто не отменял, но... В связи с чем у меня возникла вот какая мысль: нужен фреймвок для ССД с хорошей реализацией. Мне кажется, что можно сделать практически законченную систему, оставив на совести пользователя реализацию лишь предметной логики. Думается, что под эту задачу ББ заточен исключительно хорошо. Выскажу некоторые свои соображения, хотя программером меня можно назвать с очень большой натяжкой. Надеюсь на ваше понимание.
Я бы предложил разделить задачу на 3 основных модуля. Я назвал их так: Драйвер, Ядро, Диспетчер. "Работает" это система так.
Драйвер общается с портами.
Он же предоставляет интерфейс для настройки этого общения, позволяет запускать и останавливать считывание. Считав данные с порта, Драйвер "генерирует" сообщение, которое содержит считанные данные с привязкой по каналам.
Это сообщение принимается на следующем уровне, на уровне Ядра. Ядро позволяет подключать/отключать датчики на каналы, вызывать настроечные окна датчиков (для калибровки и пр.). Получив очередную порцию данных от Драйвера, Ядро обрабатывает (рассчитывает) данные по датчикам в соотв. с их калибровками, и генерируют сообщение, в котором указываются имена рассчитанных параметров и их значения. Это сообщение отправляется Диспетчеру.
Роль Диспетчера по моему замыслу - ключевая. Его задача: обеспечить подключение/отключение произвольных модулей для обработки первичных данных. Именно в этих модулях и происходит обработка данных в соотв. с предметной областью. Модули могут не только обрабатывать данные и сигнализировать о выходе за пределы, например, но и отображать данные в таблицах, на графиках, сохранять в БД и пр.
Я бы предложил такой интерфейс для загружаемых модулей:
- "Тип модуля" (рассчетный (производит расчеты), информационный (отображение значений или графиков, сохранение на диск))
- Список входных параметров (по сути - их имена) - для рассчетных модулей
- Список выходных (рассчитанных) параметров - для рассчетных модулей
- Команда для открытия настроечного окна для данного модуля
- Команда для запуска расчета (навроде Do*(IN ..., OUT...) где IN - значения входных параметров, в соотв. со списком, а OUT - значения выходных, рассчитанных)
- "Описание" (короткое имя модуля, которое идет в соотв. системное меню. Именно кликом по "описанию" в системном меню запускается команда для открытия окна настроек соотв. модуля).
- "Кнопка" в тулбар (бывает нужна для оперативного реагирования).
Работает Диспетчер так: считав список имен модулей в соотв. документе, Диспетчер загружает эти модули, добавляет соотв. пункты (если для этого модуля оно требуется) в системное меню, добавляет кнопки (по необходимости) на тулбар. Считывает списки входных и выходных параметров и в зависимости от них определяет порядок, в котором рассылаюся сообщения между подгруженными пользовательскими модулями.
Работает так.
Пусть, для простоты, у нас 4 модуля, А, Б, С, Д.
Модуль А на вход требует a, b на выходе имеет c, d.
Модуль Б на вход требует a, d на выходе дает f.
А вот С - это модуль "информационный", он отображает числовые значения в таблице (или графики рисует).
Модуль Д тоже "информационный", его задача - сохранение рассчитанных данных в БД.
От Ядра пришло сообщение со значениями параметров a, b.
Диспетчер, в соотв. с определенным ранее порядком, сообщает значения a, b модулю А и вызывает его команду на рассчет.
Модуль А рассчитывает c,d и "сообщает" Диспетчеру эти рассчитанные значения.
Далее, Диспетчер сообщает значения входных параметров модулю Б и запускает его на рассчет.
После того, как расчетные модули сделали по порядку свое дело, данные отправляются модулям информационным.
В каком порядке расположены модули С и Д уже не важно, ибо они сами ничего не рассчитывают.
Диспетчер расположил их в таком порядке: С, Д.
Модуль С отобразил рассчитанные данные в своей таблице, модуль Д сохранил рассчитанные данные на диск.
В принципе, такой каскад можно организовать для неограниченного числа модулей с пользовательской логикой. Модули, имеющий "тип" - информационный, всегда идут в конце (здесь их порядок относительно друг друга уже не важен, ибо они всегда получают все рассчитанные данные). Эти модули рисуют графики, сохраняют на диск и т.п.
Несколько несущественных замечаний:
1. Потребуется интерфейсный модуль для работы с БД.
Нужно будет учесть, то работать придется с 2-мя типами данных. Первый - значения настроек в модулях, второй тип - значения рассчитанных параметров, которые нужно постоянно сохранять на диск. Работать можно будет с разными БД, на "вкус и цвет".
2. Для каждого типа датчика следует предусмотреть свой загружаемый динамически модуль.
3. Про педагоческую ценность, вкупе с практической даже и упоминать не буду
Конечно, это лишь очень грубая прикидка. И в ходе более детальной проработки будут изменения. Но, все-таки, мне кажется, что таким путем можно здорово облегчить жизнь разработчикам. Ведь им, по сути, остается лишь реализация предметной логики и модулей под разные типы датчиков.