Далее изложение предполагает наличие у читателя представления о том, как была организована работа с сообщениями, датчиками и выходными сигналами в последней версии Uni Set? (применённой в Имитаторе), где был опробован отказ от вкомпилированных числовых идентификаторов.
Просьба сторонним читателям не особо беспокоиться по поводу данного текста.
!!
Этот раздел надо распилить!!
Каждый объект в системе должен иметь уникальное имя, с которым он регистрируется в репозитории. По этому имени к объекту можно обратиться (получив по его имени специальную ссылку). Идеология примерно как в интернете, где по web-адресу обращаешься к нужной странице.
В системе существуют разные объекты:
В общем случае репозиторий представляет из себя древовидную структуру наподобие каталогов и файлов. Никто конечно не запрещает всем объектам регистрироваться сразу в «корневом каталоге». Тогда они будут иметь самые короткие имена "Корень / Имя Объекта?".
Но мы у себя используем следующую структуру (пока негласную):
Т.е. для того, чтобы получить ссылку на объект О1 необходимо использовать полное имя "Корень / Объекты / О 1?".
Чем удобна такая структура (если её зафиксировать):
Конечно все эти вещи можно решить и без обязательной древовидной структуры, но пока проблемм особых она не вызывала, да и «внутренне» мне как-то больше нравится именно такое разбиение, чем «валить всё в кучу».
Раньше мы использовали статический массив и автоматическое генерирование enum-а. Конечно использование выглядело лучше conf->oind->getNameById(Sensor 1?).
Но статическая компиляция не позволяет:
– без перекомпиляции добавлять новые датчик или объекты
– генерировать имена на ходу
Глобальный вопрос использования числовых идентификаторов.
Т.е. в CORBA все ссылки являются строками (по крайней мере имеют функции преобразования в строку и обратно). И в «числе» ей для работы нет необходимости. ЧИСЛО (ID) придумали мы.
Числовые идентификаторы объектов имеют следующие плюсы:
К минусам приходится отнести только усложнение механизма работы и возможно некоторое неудобство при программировании (по крайней мере визуально). Т.е. получается – что надо каким-то образом каждому объекту присваивать уникальный идентификатор
Объект регистрируется в репозитории с уникальным именем и только после этого может взаимодействовать с другими объектами.
Активный объект представлен классом (в С++) и имеет свойства, которые хранятся в конф. файле проекта и определяют тип интерфейса объекта.
Существует ряд базовых типов интерфейса:(Uni Set Object?, Objects Manager?, IONotifyController, для каждого из которых определён набор допустимых над ним операций.
Названия типов, хранящиеся в конф. файле, соответствуют названию классов в С++.
Для каждого активного объекта на основе конф. файла генерируется базовый класс, который наследован от одного из базовых классов, в зависимости от типа его интерфейса. Класс записывается в отдельный файл и содержит в секции protected переменные состояния датчиков и идентификаторы датчиков. Для этого класса формируется функция, отвечающая за обновление переменных с состояниями датчиков. Также указывается название объекта (уникальное для данного узла). В конструкторе класса происходит получение необходимых идентификаторов.
В конфигурационном файле для каждого объекта перечислены объекты, с которыми он взаимодействует. Для датчиков – перечислены заказчики, для выходов – перечислены управляющие им объекты, для активных объектов – объекты, имеющие право отправлять сообщения. Программа проверки должна проверять корректность этих ссылок. Этот механизм позволяет генерировать локальные переменные, содержащие идентификаторы используемых объектов (получаемые на основании имени) и контролировать допустимость взаимодействия, то есть право использования.
На перспективу:
Полный путь объекта имеет вид
\\узел\Корень\Вид объекта\Устройство\Название объекта на устройстве
(допустимы любые символы в названии, кроме \0, \\ и '.'
Этот путь является полностью уникальных в пределах системы.
Локальный путь к объекту имеет вид
\Корень\Вид объекта\Название объекта
Для разных узлов сети адрес может повторяться.
Название объекта может повторяться для различных видов объектов.
Требует обсуждения, нужно ли что-то кодировать в названии объекта
Для пересылки и обработки использоваться числовой код (идентификатор) объекта, имеющий однозначное взаимное соответствие с путём к объекту.
Должен предлагаться дешёвый механизм по преобразованию код->путь->код.
Конкретных реализаций может быть несколько: от непосредственного задания кода в XML-файле до создания хэш-функции.
Принятым рабочим вариантом является хранение всей информации об объектах в XML-файлах, копируемых на все узлы сети
В использовании констант, обозначающих код объекта, необходимости не найдено.
Надо дополнить