"Универсальная компонентная среда" (Нужны советы коллективного разума.)

[Denjs]

"механизм атрибут связь"

Как понимаю это из представления модели данных, т.е. ER-модель?

ER- это "сущность-связь".... и отношение может быть чем угодно - не обязательно "взаимодействием". ("(я) -> [думаю о]-> (девушка)" - это тоже "сущность-связь" но никак не того рода, что обеспечивает взаимодействие.)

А тут нам нужно описать именно взаимодействие, передачу информации.
в общем тема "атрибут-связь"... не раскрыта...

почему-то я сильно сомневаюсь что с такими вы сможете реализовать _кроссплатформенную_ систему.

"С такими" - что? С чем "с такими"?

простите, читать так:
>> почему-то я сильно сомневаюсь что с такими требованиями вы сможете реализовать _кроссплатформенную_ систему.

Кроссплатформенную систему создать вряд ли удастся без привлечения Java, .Net или чего-то подобного.

гм... а чем тогда занимается С++\Qt? позволяет писать "кроссплатформенный код" для создания "мультиплатформенных систем"?
ну тогда простите, я немного спутал термины ))) в таких терминах - я имел в виду мультиплатыорменную систему.

но тогда - с такими требованиями, вам будет необходимо писать низкоуровневую реализацию ваших механизмов отдельно для каждой системы. А это слишком серьезно... я тут писал код для работы с компортом - что бы морда класса была одинаковая для венды и линукса (см класс t_seriallink в otpd)... знаете - "задолбался я немного"... но если вы сможете - респект и уважуха)))
Если вы создадите отказоустойчивый механизм межмодульной передачи информации... гм... посмотрим... на лавры MQSeries (который "100% гарантирует доставку", пусть и без гарантии порядка и времени доставки) вы будете замахиваться?

давайте уже что нибудь проектируйте, блин) я хоть посомтрю)))

[Zeus]

Значит про "атрибут-связь".
Термин "атрибут" я позаимствовал из SCADA своей конторы, где атрибуты - это действительно CORBA-аттрибуты CORBA-компонентов.

Код: Выделить всё

interface fan: attributeManager
{
attribute long state;
const long stateNoControl = 0;
const long stateOff = 1;
const long stateOn = 2;
const long stateError = 3;

attribute long command;
const long commandOff = 1;
const long commandOn = 2;
const long commandSwitch = 3;
...
};

В интерфейсе attributeManager описаны методы привязки к изменению аттрибутов.
Реализация - в скелете, предоставляемом SCADA, она заполняет эти скелеты во время mapping'а из CORBA в С++.
Прикладному программисту остаётся наполнить содержанием только методы класса

Код: Выделить всё

void
fan_i::state (long _value)
{
...
};

long
fan_i::state ()
{
...
};

и т.д.

Если вызвать метод базового класса (реализацию которого вставила SCADA при mapping'е)
fan_base::state (long _value), то его код произведёт рассылку нового значения (_value) аттрибута state подписавшимся компонентам.
При подписке они вызывали функцию типа:
subscribe (string _attribute, CORBA::Object _who, string _whoAttribute).
Базовый класс сохранил это всё в ассоциативном массиве <attribute, set<link<_who, _whoAttribute> > > и когда вызывается метод установки аттрибута (в базовом классе) он лезет в этот массив и для всех связей, последовательно вызывает метод установки аттрибута _who->_whoAttribute.
Можно унаследоваться от интерфейса attributeManagerAsync и тогда рассылка будет производиться асинхронно.

Вот примерно это я называю принципом "атрибут-связь".
Т.е. это - "прямой" вызов методов компонента, подписавшегося на получение изменений атрибута данного компонента.

Шина же - это некий отдельный программный объект, которому мы отдаём сообщение на доставку и всё.


Насчёт мультиплатформенности.
В движке я не собираюсь реализовывать функционал системы (упомянутую "бизнес-логику").
Движок - очень простой (насколько это возможно), контейнер плюс набор базовых классов, плюс средства автоматизации (что-то вроде того самого CORBA-mapping'а).
Всё написано на чистых "плюсах" - с очень малым количеством платформенно-зависимого кода. В идеале - вообще чистый C++ и никаких сторонних библиотек.
Такой код откомпилится на любой платформе, где есть плюсовый компилятор.

А вот набор компонентов - он может от платформы к платформе отличаться.
Но опять-таки, компоненты, где чистая обработка данных, логика - они тоже должны портироваться очень легко.
И сложности будут только с системно-зависимыми компонентами или окружением движка.

[Denjs]

гм... выводы и ограничения... т.е. фактически в вашей архитектуре :

1) информационное взаимодействие между объектами в вашей архитектуре ограничивается информированием других объектов об изменении значений своих атрибутов. Наверное, атрибут может быть и сложным (структурой, объектом класса) но это один атрибут.. так?

2) информирование другого объекта обязано привести к установке другого значения у приемного объекта? ну наверное понятно что при этом можем вызваться обработчик установки атрибута...

3) возврат какого-либо вычисляемого значения исходному объекту не возможен? т.е. объект не может "сказать" подписавшимся на его события объектам - "вот вам значение : посчитайте его пожалуйста" - и получить на выходе массив значений?

4) объекты подписчики обязаны знать ссылку на объект, на событие изменения атрибута которого они подписываются?

5) ""прямой" вызов методов компонента" - суть call-back, о минусах которого говорилось не раз, поломано не мало дров, и костылей к которому написано очень много. Понятно что это "просто", имеет свои плюсы, и все минусы мало кого останавливают (даже в Qt-шных софтинах) от его использования.

Ну и вопросы межпроцессного взаимодействия при прямом вызове тоже остаются за кадром... а тут ещё надо атрибут менять у приемного объекта.


Теперь моё сравнение с Qt-шным механизмом сигнал-слотов...
(1) : в сигналах Qt вы можете передавать несколько атрибутов, или не передавать атрибутов вообще... Сигнал в Qt - это не только информирование мира об изменении собственого состояния. Это может быть ещё и "команда". Испускание сигнала не обязано менять состояние атрибутов исходного объекта. Но если в обработчике атрибута написано "испускать сигнал" - он конечно будет испущен.

В вашей архитектуре - сигнал обновления будет испускаться, если новое значение атрибута будет равно старому?

(2) : в Qt прием сигнала не обязан менять состояние приемного объекта. Вы просто обрабатываете полученные значения в функции-слоте.

(3) : в Qt в чистом виде, возврат значения возможен только при прямом вызове. Однако если использовать доп. класс ( да я пиарюсь: прототип мною писан t_returnSyncObject. покритикуйте если что) - можно "просить внешний мир рассчитать нужные тебе значения, при этом не особо заботясь о том, кто тебе их рассчитывает". Более того - его легко можно доработать до возможности собирать массив рассчитанных значений). Кроме того - решаются вопросы подтверждения доставки сигнала до приемника (иногда мне это интересно знать).
Фактически это решение для синхронного взаимодействия через асинхронные механизмы... но оно например работает как между объектами в разных потоках и между локальными объектами, и обеспечивает при этом "таймаут".
Ну это все "так", почти на заметку, про ещё один/два способа/аспекта взаимодействия объектов между друг-другом.

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

(4) : при сборке системы - в идеале - кроме "объекта-сборщика" который "видит всех" - никто ничего не обязан знать.
т.е. объекты взаимодействуют друг с другом не зная с кем они работают.
Удаление объекта не приводит к сегфолту программы (см пункт 5).
Сборка программы из объектов производится в main (или я это делаю в специальном классе с гордым названием t_dispatcher - тот самый "объект-сборщик"). а потом объекты "просто работают друг с другом"... изменения в объктной структуре часто ограничены , скажем так, "локальной областью видимости"...

(5) : Собственно сигнал-слоты судя по описаниям и проектировали для того, что бы избавить народ от необходимости использовать call-back. Да, если (теоретически !!!) "встанет" EventLoop - то это конечно приведет к нарушению работы в программе.. но я вот о таких случаях даже не слышал...

в Qt многие вопросы межпроцессного взаимодействия "остаются за кадром" т.к. решаются самим сигнал-слотовым механизмом. Есть несколько типов соединения для пары сигнал-слотов(прямой вызов, асинхронный, синхронный межпроцессный, и ещё парочка). Есть и стандартные механизмы для гибкой настройки работы.

________________________________________________________________________________

ну где-то так...
ещё раз - я пытаюсь не "макать вас в недостатки", но стараюсь дать хоть сравнительный анализ... если кто сделает такое по другим тезнологиях - например в бусте -же тоже наверняка есть "не call-back" механизмы взаимодействия?
в споре должна рождаться истина, иначе это все зазря)))

Всё написано на чистых "плюсах" - с очень малым количеством платформенно-зависимого кода. В идеале - вообще чистый C++ и никаких сторонних библиотек.
Такой код откомпилится на любой платформе, где есть плюсовый компилятор.

гм... мне как человеку плохо знающему STL и "чистый С++" - скажите - межпроцессное взаимодействие вы тоже сможете на "чистых плюсах" написать? загрузка библиотек? что-то ещё?...
>> И сложности будут только с системно-зависимыми компонентами или окружением движка. <<---- вот вот... вам надо решить что именно и как вы будете использовать системно зависимого, и насколько вы сможете от жтого отказаться ради портируемости.

[sash-kan]

извините, что встреваю в дускуссию.
просто до боли она знакома.
по листу рассылки eas-а.
с приведённой ссылкой никто не знакомился?

http://eas.lrn.ru/
тоже программная платформа.
пока разрабатываемая.

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

[Zeus]

гм... выводы и ограничения... т.е. фактически в вашей архитектуре :

1) информационное взаимодействие между объектами в вашей архитектуре ограничивается информированием других объектов об изменении значений своих атрибутов. Наверное, атрибут может быть и сложным (структурой, объектом класса) но это один атрибут.. так?

Именно так. Задумывается, что компонент (точнее его программист) может заявить атрибут любого типа.
Главное, чтобы предоставил адаптеры-преобразователи из других типов.

2) информирование другого объекта обязано привести к установке другого значения у приемного объекта? ну наверное понятно что при этом можем вызваться обработчик установки атрибута...

Это зависит от того, что реализовал программист "приёмного" объекта.
Если оставил реализацию базового класса, то - да: он "умеет" только установить новое значение атрибута и в свою очередь разослать его тем, кто на него подписан.
А если программист реализовал методы получения нового значения, то это будет просто вызов метода. С параметром.
А уж будет он устанавливать атрибут у своего объекта или нет - это его дело.
Может вообще написать компонент "чёрная дыра" у которого есть атрибуты с любым именем, он готов принимать туда значения любого типа и все они будут там пропадать не вызывая никаких последствий.

3) возврат какого-либо вычисляемого значения исходному объекту не возможен? т.е. объект не может "сказать" подписавшимся на его события объектам - "вот вам значение : посчитайте его пожалуйста" - и получить на выходе массив значений?

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

4) объекты подписчики обязаны знать ссылку на объект, на событие изменения атрибута которого они подписываются?

Если хотят (если программист компонента захочет), то возможна и работа компонента с контейнером, поиск других компонентов по имени, подписка к ним, отписка, удаление, создание новых компонентов - на это ограничений нет.
Но предполагается, что абсолютному большинству компонентов для своей работы знать о том откуда они получают данные - не обязательно.
И устанавливать связи будет некий "настройщик", "конфигуратор" системы.

5) ""прямой" вызов методов компонента" - суть call-back, о минусах которого говорилось не раз, поломано не мало дров, и костылей к которому написано очень много. Понятно что это "просто", имеет свои плюсы, и все минусы мало кого останавливают (даже в Qt-шных софтинах) от его использования.

Я вообще про call-back думал по-другому.
Что ты отдаёшь какую-то работу на сторону и по завершению просишь "дёрнуть вот эту вот мою функцию".
А тут - просто вызовы виртуальных функций (если говорить в терминах C++) одних компонентов другими.

Ну и вопросы межпроцессного взаимодействия при прямом вызове тоже остаются за кадром... а тут ещё надо атрибут менять у приемного объекта.

Я потому и говорю, что контейнер будет очень простым, потому что он не будет заморачиваться такими вопросами.
Его задача - хранить ссылки на компоненты и предоставлять определённый сервис. И всё.
Все остальные "вопросы" - к компонентам.
А там будет и межпроцессное взаимодействие, и CORBA, и чёрт-в-ступе, но! Самое главное: их можно стыковать друг с другом в рамках контейнера.

Теперь моё сравнение с Qt-шным механизмом сигнал-слотов...
(1) : в сигналах Qt вы можете передавать несколько атрибутов, или не передавать атрибутов вообще...

Это похоже на WinAPI: куча функций с кучей аргументов.
"Редкий программист долетит до середины MSDN..."

Громоздко, одним словом.

Сигнал в Qt - это не только информирование мира об изменении собственого состояния. Это может быть ещё и "команда".

Что значит "команда"?

Испускание сигнала не обязано менять состояние атрибутов исходного объекта. Но если в обработчике атрибута написано "испускать сигнал" - он конечно будет испущен.

В вашей архитектуре - сигнал обновления будет испускаться, если новое значение атрибута будет равно старому?

Так и тут никто не заставляет действительно изменять атрибут исходного объекта.
"Сигнал обновления будет испускаться" тогда когда программист компонента в коде вызовет функцию send базового класса.
Хочешь - вызови send с тем же самым значением и оно разошлётся всем подписанным.
А уж как они будут на него реагировать (на повторяющиеся значения) - это их дело.
Может действительно как на команду, а может проигнорируют.
Кстати, можно изменить атрибут и "втихаря": т.е. положить в переменную новое значение, но не вызывать send.
Тогда это изменение обнаружит только тот, кто САМ прочитает значение атрибута.
Может в этом тоже найдётся какой-нибудь алгоритмический смысл.
Кстати, чтение атрибута - это же тоже вызов метода. И вовсе не обязательно, что это будет просто возврат текущего значения переменной.
Вполне возможно, что метод полезет куда-нибудь в базу данных или в устройство - узнать его состояние.

=== Denjs ===
(2) : в Qt прием сигнала не обязан менять состояние приемного объекта. Вы просто обрабатываете полученные значения в функции-слоте.
============
Абсолютно аналогично.

=== Denjs ====
(3) : в Qt в чистом виде, возврат значения возможен только при прямом вызове.
============
Своё мнение про возврат значения я уже изложил выше.
Добавлю: в решавшихся мною задачах практически всегда получалось так, что данные для вычисления даёт один компонент, вычисляет второй, а результат нужен... не тому, первому компоненту, а другому - третьему.

==== Denjs ====
(4) : при сборке системы - в идеале - кроме "объекта-сборщика" который "видит всех" - никто ничего не обязан знать.
т.е. объекты взаимодействуют друг с другом не зная с кем они работают.
==============
Тоже абсолютно аналогично.
За исключением:
1) Неких "системных" компонентов. Системных не с точки зрения операционной системы, а с точки зрения разрабатываемой системы.
2) Компонентов, которые специально созданы для работы друг с другом помимо интерфейса контейнера.

=== Denjs ====
Удаление объекта не приводит к сегфолту программы (см пункт 5).
=============
Я к этому тоже стремлюсь. Потому и обдумываю всяческие proxy-объекты, компоненты-заглушки, сообщающие, что объекта больше нет - короче какой-то корректный механизм удаления объекта из контейнера.

=== Denjs ===
(5) : Собственно сигнал-слоты судя по описаниям и проектировали для того, что бы избавить народ от необходимости использовать call-back. Да, если (теоретически !!!) "встанет" EventLoop - то это конечно приведет к нарушению работы в программе.. но я вот о таких случаях даже не слышал...
============
Так сигнал-слот - это, получается, что-то вроде очереди (шины) сообщений? Раз там присутствует цикл выборки событий.
А насчёт "встанет". Сам он может быть "вылизан" и содержит минимальное число ошибок, а критических и вообще нет.
Но что если его заблокирует некорректно написанный компонент?

=== Denjs ===
ещё раз - я пытаюсь не "макать вас в недостатки", но стараюсь дать хоть сравнительный анализ... если кто сделает такое по другим тезнологиях - например в бусте -же тоже наверняка есть "не call-back" механизмы взаимодействия?
в споре должна рождаться истина, иначе это все зазря)))
============
Я именно для этого и затеял эту тему.
Ну и плюс, если всё-таки дойдёт до программёжа - чтобы спрашивать у знатоков как реализовать тот или иной сложный момент.
Мне сейчас некоторые вещи из задуманного - не очевидны.


==== Denjs ====
скажите - межпроцессное взаимодействие вы тоже сможете на "чистых плюсах" написать? загрузка библиотек? что-то ещё?...
==============
Межпроцессное взаимодействие, как я уже написал выше - это к контейнеру не относится. Этим занимаются компоненты.
Вот загрузка библиотек - да, будет относительно небольшой кусок платформенно-зависимого кода.
Без этого никуда. Не Java всё-таки.

====== Denjs ======
>> И сложности будут только с системно-зависимыми компонентами или окружением движка. <<---- вот вот... вам надо решить что именно и как вы будете использовать системно зависимого, и насколько вы сможете от жтого отказаться ради портируемости.
=================
Задумка такая, что движок, которым занимаюсь я - портируется относительно легко.
А вот компонентами - занимаются их авторы и соответственно и портированием тоже. Или соавторы - если исходник компонента лежит в Сети с какой-нибудь свободной лицензией - бери и адаптируй под свою платформу. Становись соавтором.
Опять-таки, если речь не идёт о каком-то системном, платформенно-аппаратно-библиотечно-зависимом алгоритме, то он скомпилируется любым C++-компилятором, постольку поскольку в нём есть только код архитектуры контейнера (а он, предполагаем, уже на этой платформе присутствует) и самые стандартные конструкции C++.

=== sash-kan ===
извините, что встреваю в дускуссию.
просто до боли она знакома.
по листу рассылки eas-а.
с приведённой ссылкой никто не знакомился?

http://eas.lrn.ru/
тоже программная платформа.
пока разрабатываемая.

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

Я всё-таки стремлюсь к максимальной скорости взаимодействия компонентов друг с другом.
Это расширяет класс задач, которые можно решать с помощью движка и компонентов к нему.
Я и от CORBA из-за этого ухожу, хотя там почти всё, что сейчас у меня вызывает самые большие раздумья - уже реализовано.
Но маршалинг-анмаршалинг в пределах одного процесса, считаю мягко говоря лишним.

[sash-kan]

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

Я всё-таки стремлюсь к максимальной скорости взаимодействия компонентов друг с другом.
Это расширяет класс задач, которые можно решать с помощью движка и компонентов к нему.
Я и от CORBA из-за этого ухожу, хотя там почти всё, что сейчас у меня вызывает самые большие раздумья - уже реализовано.
Но маршалинг-анмаршалинг в пределах одного процесса, считаю мягко говоря лишним.

дадада. и это, насколько помнится, в рассылке тоже пылко обсуждалось.
всё-таки полистайте рассылку, там вполне неглупые люди мнениями обменивались.
наверняка, найдёте и полезные для себя мысли.
впрочем, если не хотите тратить время на изучение опыта предшественников, но есть желание получать опыт методом своих собственных проб и ошибок, то кто ж камень бросит? большая часть всей нашей деятельности — это набивание своих собственных «уникальных» шишек.

[Denjs]

http://eas.lrn.ru/
тоже программная платформа.
пока разрабатываемая.

А можно там как нибудь подправить кодировку на страничках?
на самом деле надо бы описание кодировки исправить , что бы соответсвовало реально используемому UTF-8...

а то в теле страницы написано iso8859 :

Код: Выделить всё

<meta http-equiv="Content-Type" content="text/html; charset=iso8859-1" />

и приходится постоянно переключать .. ну это как-то не удобно, что ли....

ну и я тож потом почитаю....

[sash-kan]

А можно там как нибудь подправить кодировку на страничках?

там, наверно, контакты web-мастера имеются.
ну, или Андрею Черепанову непосредственно изложите предложение. благо он временами появляется и у нас на форуме.

[Zeus]

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

А как её листать?
Я только архивную почитал. Там обсуждают структуру БД, какие-то бухгалтерские заморочки, формы отчётности, на каком языке вести документацию...

[sash-kan]

А как её листать?

http://lists.linux.ru.net/pipermail/eas-dev-rus/

[Zeus]

А как её листать?

http://lists.linux.ru.net/pipermail/eas-dev-rus/

Выдержал полтора часа.
Тонны воды вперемешку с тупняком.
Не увидел ни одной подсказки для себя, зато бухгалтерии там - выше крыши.

[sash-kan]

Тонны воды вперемешку с тупняком

я сплошные перлы и не обещал.