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