stern писал(а):
Удивительно, насколько многим людям приходится делать системы сбора данных (ССД), в том или ином виде.
Да, это мы проходили...
stern писал(а):
И все решают по-разному, но все решения объединяет одно: пишется долго и муторно, часто - неудачно.
Не знаю, мои все работают : )
stern писал(а):
Мне кажется, что можно сделать практически законченную систему, оставив на совести пользователя реализацию лишь предметной логики.
Предметная логика - это что? То, что делать потом со всеми этими собранными данными? Если так, то во-первых, почему пользователь вообще что-то должен реализовывать? Если "пользователь" - это на самом деле не пользователь, а программист, использующий данный пакет ССД, то у него в любом случае будут большие трудности, см. ниже.
stern писал(а):
Думается, что под эту задачу ББ заточен исключительно хорошо.
Под ССД? Пожалуй, соглашусь, если добавить, что ССД должна быть расчитана в основном на автономную (не интерактивную) работу.
stern писал(а):
Работает Диспетчер так: считав список имен модулей в соотв. документе, Диспетчер загружает эти модули, добавляет соотв. пункты (если для этого модуля оно требуется) в системное меню, добавляет кнопки (по необходимости) на тулбар.
С этим уже придётся колдовать: прямой поддержки динамических меню и тулбаров нет. Будете рыться в HostMenus. Это к вопросу об интерактивной работе и приспособленности Блэкбокса. Штатное решение: открыть окошко поверх прочих с нужными кнопками/коммандерами при запуске среды и оставить меню для других целей.
stern писал(а):
От Ядра пришло сообщение со значениями параметров a, b. Диспетчер, в соотв. с определенным ранее порядком, сообщает значения a, b модулю А и вызывает его команду на рассчет.
А если от параметра а приходят значения, а от b уже час нет ответа? Будет ли Диспетчер вызывать пересчёт или воздержится? Если будет пересчитывать, то будет ли использовать последнее известное значение b или какое-то экстраполированное из прежнего поведения датчика? Какой бы вы ответ ни дали, могут быть задачи, где необходим противоположный ответ или смешанная логика. Вопрос: эту логику вы будете встраивать в базовую ССД и вываливать тонну настроек, или же доработка ССД опять-таки ложится на "пользователя-программиста"?
stern писал(а):
Диспетчер расположил их в таком порядке: С, Д.
А почему не по алфавиту: Д, С? ; )
stern писал(а):
В принципе, такой каскад можно организовать для неограниченного числа модулей с пользовательской логикой.
Как система будет реагировать на попытку внесения цикла в данный каскад, например, когда модуль Б выдаёт параметр а или его скорректированное значение?
stern писал(а):
2. Для каждого типа датчика следует предусмотреть свой загружаемый динамически модуль.
Не вижу, почему именно "следует". Можно сделать - да, но обязательно ли и какие последуют преимущества? Дополнительные проверки интерфейса при динамической загрузке займут не одну страницу кода, в отличие от автоматической загрузки, где всё это уже реализовано.
stern писал(а):
Конечно, это лишь очень грубая прикидка. И в ходе более детальной проработки будут изменения. Но, все-таки, мне кажется, что таким путем можно здорово облегчить жизнь разработчикам. Ведь им, по сути, остается лишь реализация предметной логики и модулей под разные типы датчиков.
А кто будет реализовывать протокол обмена? Пусть есть COM-порт, но это ещё не протокол. Приходящие данные надо по определённому алгоритму декодировать, сверить контрольные суммы, обработать ошибки. Что делать в случае сбойного пакета? Послать некий повторный запрос данных? Проигнорировать сбойный и дождаться следующего пакета?
Сдаётся мне, что вы обрисовали некую архитектуру, общее устройство программы, которое в принципе может быть применимо для нескольких (похожих или не очень) ССД. Это тянет на публикацию статьи или разработку SDK для клиентов вашего предприятия, но получится ли из этого действительно ССД общего назначения, которую можно использовать в смысле программного кода, а не общего подхода, - не знаю.