К какому классу можно отнести описанную систему?

Question

[Chesheersky]

Начну вопрос с описания наболевшего.

Сейчас работаю в компании производящей мед оборудование. У нас есть порядка 4 разновидностей устройств. Каждое из устройств имеет некое множество версий. Каждая версия имеет немного отличающийся от других протокол общения с внешним миром. Также мы имеем ПО, которое общается с этити устройствами. ПО тоже имеет разные версии. Требуется поддерживать совместимость между самыми разными версиями устройств и ПО.

Пока мы успешно справляемся со всем этим зоопарком, но это стоит трудов. Что-то мне подсказывает что рост зоопарка приведет к непропорциональному росту трудозатрат. И это вызывает беспокойства =)

Вопрос может показаться нелепым, но я все же его задам. Есть ли какое-либо название у подобного класса систем? Есть ли какие-то книги или статьи на эту тему?

Answer 1

[Владимир Мартьянов]

Название - бардак :-) Надо как-то решать вопрос совместимость версий протоколов...

Comments

[Chesheersky]

Вопрос решается, и пока успешно. Все работает друг с другом, quality assurance period не выходит за разумные рамки, багов в продакшене тоже довольно не много.
Просто хочется почитать про подобные системы, узнать с чем люди сталкивались, на какие грабли наступали, что с ними делали.

Answer 2

[Тимур Шемсединов]

Тут есть задача максимально отвязать оборудование от ПО. Конечно, ПО должно знать о структуре и возможностях оборудования, но эти знания можно обобщить и разработать специализированный язык-посредник, т.е. метаязык для формального описания протоколов (программных интерфейсов) устройств. При чем, синтаксические конструкции свои делать не нужно, лучше взять синтаксис, для которого уже разработаны распространенные и оптимизированные парсеры, например JSON. Таким образом, ПО будет знать не интерфейс оборудования, а языка описания этого интерфейса. Точнее, обобщенные элементы интерфейса, каждому из которых поставлены в соответствие обобщения более высокого порядка: команда (процедура, метод), параметр, датчик, измерение, и т.д. В этом метаязыке можно предосмотреть не только декларативные конструкции описательного характера, но и активные, включив в него скрипты например на JavaScript, которые могут описывать алгоритмы работы с теми же структурами, которые метаязык и описывает. Из декларативной части можно динамически строить и пользовательский интерфейс и связывать его с формированием конкретных команд, отправляемых в устройство. Более подробне описать не могу, т.к. не знаю специфики Ваших задач. О метапрограммировании можно кое-что почитать тут: habrahabr.ru/post/227753 и тут: habrahabr.ru/post/137446 ну может еще вот тут: habrahabr.ru/post/154891

Comments

[Chesheersky]

Спасибо за ответ, обязательно почитаю статьи по ссылкам. Если у вас есть время - я мог бы подробнее описать систему в личном сообщении.

[Тимур Шемсединов]

Мои контакты тут habrahabr.ru/users/marcusaurelius

Answer 3

[Максим Кузнецов]

Боюсь, не смогу дать чёткого решения проблемы, слишком мало данных. Но может, мой опыт пригодится.

В своё время делал комплексную систему безопасности. Это был коробочный продукт, при мне выпустили 4 версии. В системе требовалось привязать кучу оборудования: видеокамеры, считыватели, СКУД, сканеры документов и прочую снедь. Проблему решили просто: были созданы унифицированные абстрактные классы под каждый класс оборудования: для сканеров (получение сканов документов), под СКУД (информация о проходах), под считыватели (события чтения карт, билетов, биометрии), под камеры (получение видео и фотоизображений), под системы распознавания изображений... Абстрактные классы имели абстрактные методы для получения входных данных и реализацию методов дальнейшей обработки информации, соответствующих данному классу устройств. Реализация конкретных классов для конкретных моделей устройств была вытащена в плагины, которые подцеплялись динамически.

Мы всегда знали, какие устройства поддерживаем, и делали под них соответствующие плагины. Интерфейсы и абстрактные классы переделывать было не нужно, они не менялись. Допустим, было несколько считывателей: магнитные карты нескольких типов, билеты со штрих-кодом, отпечатки пальцев... Но они все были нужны, чтобы выполнить одну функцию: опознать владельца предъявленного идентификатора. Поэтому реализация плагина была для каждого устройства своя, а вот интерфейс его взаимодействия с ядром системы - один на все устройства.