UniSet/ПредлагаемыеИзмененияВОбъектах

План изменений по взаимодействию объектов

Далее будут приведено подробное обоснование предлагаемых изменений, сделанное на основании обсуждений ситуации 13.07.2005 и 14.07.2005.

Изменения ставят целью создание простого, завершённого интерфейса для написания алгоритмов управления, а также графических интерфейсов и процессов ввода-вывода.

Все допустимые взаимодействия между объектами должно быть жёстко указано, не должно быть возможно несанкционированное вмешательство в объект из кода, к нему не относящегося. Это относится к удалённому вызову функций, удалённому изменению состояния датчиков.

При написании/проектировании интерфейсов следует предусматривать разделение на уровни - интерфейс, предоставляемый пользователю и интерфейс, нужный самой системе.

Отмена функций askState/askValue

Поскольку информация о заказываемых датчиков для надёжности перенесена в конф. файл, необходимости заказывать датчики напрямую в приложении нет. Чтобы сделать API стройным, функция заказа датчиков упраздняется. Для того, чтобы собрать сведения о том, какой датчик нужен какому объекту, достаточно просмотреть секцию sensors конфигурационного файла.

На данный момент отказаться от этих функций не представляется возможным. Даже если считать, что список заказа формируется в конф. файле, то остаётся вопрос о событии ЗапускПроцесса

Функции saveState/Value

Это способ управления состоянием фиктивных входных датчиков? Такой способ применяться не должен.

saveState НЕ должен быть доступен снаружи объекта.

Функция сохранения состояния не должна быть использована вне процесса, владеющего объектом, для которого меняется состояние. Поэтому из UniversalInterface она должна быть вынесена. ?

Упразднение разделения датчиков на виды

Исторически сложилось, что введены понятия аналоговых (принимающих значение в определённом диапазоне) и дискретных (имеющих два состояния - 1 и 0) датчиков. Для каждого вида датчиков реализован свой набор функций.

• Предлагается упразднить разделение аналоговых и цифровых датчиков/выходов при обращении с ним. Для двоичных по природе датчиков состояние 0 будет кодироваться значением 0, состояние 1 - ненулевым значением.

• В сообщениях поле state будет упразднено (при желании можно сделать совмещение полей state и value)

• Предлагется ввести код состояния датчика (или кодировать его состояние в value). Это позволит узнавать об обрыве/замыкании датчика.

Соответственно функции семейства *State упраздняются.

Отмена функций getState/Value

Функция получения текущего значения часто используется в алгоритмах. В данный момент использование это выглядит очень неуклюже, стоимость вызова достаточно велика, вызов вносит дополнительные задержки, загромождает код и не обеспечивает когерентность (одновременное измерение) запрашиваемых датчиков.

Поэтому предлагается функцию для прямого получения состояния (значения) отменить. Информация об изменении значений будет доставляться заказанными извещениями о изменении состояния датчиков. Для хранения информации о состоянии в класс вводятся локальные переменные, значение которых заполняется специальной функцией, действующей перед обычным вызовом processingMessage, таким образом, что в любой момент при обращении к этим переменным их значения будут максимально актуальны.

Для облегчения программирования добавление необходимого кода в класс будет осуществляться автоматически. Для каждого заказанного датчика будут созданы локальные переменные name (хранящая состояние датчика) и id_name (хранящая идентификатор датчика).

Для указания конкретного имени переменной, соответствующей датчику, его необходимо явно указать в конф. файле, иначе оно будет сгенерировано по умолчанию (нужно сформулировать правила). Способ передачи имени переменной в конф. файл обсуждается.

Тип сообщения

Предлагается убрать доступ к полю типа сообщения (датчик/выход дискретный/аналоговый), поскольку информация о содержании датчика должна быть интерпретирована программистом на основании его названия.

Пока не будет чётко определён механизм разделения интерфейсов на доступные конечным разработчикам и доступные библиотечным классам(объектам) это поле предлагаю оставить. Т.к. оно используется в реализации DBServer и по нему определяется в какую таблицу необходимо сохранить запись об изменении состояния датчика. Для БД разделение на аналоговые и дискретные существенно, т.к. связано с оптимизацией хранения (Cейчас аналоговые и дискретные датчики хранятся в разных таблицах. Более того, изменение аналоговых датчиков происходит чаще).