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

[Zeus]

Начнём так.
Уже не для одного проекта видится удобным иметь набор компонентов с разным функционалом, которые бы можно было соединять друг с другом в различные программные системы: систему имитационного моделирования, SCADA и т.п.

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

Для начала, самые общие концепции:
https://docs.google.com/document/pub?id=1Go...MS2Hfxzl_NIwX2k

если не будет решительного "от ворот поворот", то идеи будут уточняться, а там глядишь и до кода дойдёт.

[deadhead]

Судя по документу уклон все же в сторону АСУ ТП. И наверняка вы уже знаете о существующих программных платформах. Тем не менее посмотрите в сторону этого малоизвестного проекта. Возможно это хорошая база для ваших идей. ;-)

[sash-kan]

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

[Zeus]

Просмотрел всё что предложили.
Всё не то.
И в первую очередь потому что это - именно SCADA. Они изначально проектировались как SCADA и ими и являются. (кроме последней - это какая-то бухгалтерская система).
Я же хочу разработать именно универсальную среду с универсальными компонентами.
Универсальные компоненты - в том смысле, что им не важно в каком проекте работать: SCADA или какой-нибудь преобразователь данных или ещё что...
Они выполняют каждый свою функцию, их можно произвольно связывать друг с другом для достижения нужного функционала системы.
Короче, это я опишу в следующем документе.

[Denjs]

гм... я на такое уже замахнулся) QDroid , гы))) (некоторое спутанное описание годовалой давности можно почитать на http://qdroid.berlios.de/docuw/ )

Я пошел по пути создания "stand-alone" среды исполнения QtScript и создания в этой "среде" стандартных средств для загрузки расширений, предоставляющих новые классы.
( а из-за "близко-родственности" с Qt - практически любой C++\Qt-класс c минимальными затратами можно обернуть в такое расширение )

Т.е. в скрипте вы даете команду "loadlib_qd(LibName()" (который подкгружает динамическую библиотечку-расширение) - и после этого у вас становится доступным создание нового класса объектов через new().
а далее - сигнал-слоты или простая программа...

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

Описать новую бизнес-логику без механизма описания алгоритмов (суть - "скриптования") - вы не сможете.
_Теоретически_ - система настройки (невероятно гибкая!!!) вам может помочь, но это костыль.
"Системы настройки", без скриптования - не хватит (иначе бы адепты case-разработки и визуального программирования давно бы "вытеснили программистов с рынка").

Имхо: скрипты + "стандратная" система загрузки расширенй + сигнал слотовый механзм = это как раз то что нужно. Но это моё решение.

Если будете хотеть исходники - дайте отмашку - на qdroid.berliod.de давно не обновлял - я или вам вышлю или обновлюсь там.

В принципе, народ уже спрашивал про IDE для QtScript - и я вижу что ваш "САПР проектировщика" как раз очень даже "близко звучит" как IDE для QtScript с возможностью легкого подключения расширений-компонент.

Теперь о том "что уже есть", и какие я вижу аналогии:
"Движок УКС - контейнера компонентов" - подсистема загрузки и подключения расширений QDroid
"Пакета программ разработчика компонентов" - для QDroid это наверное - шаблоны компонент-расширений для QDroid
"Совокупность компонентов" - для QDroid есть tcp-сервер, tcp-клиент, частично - управление принтерами, компоненты работы с ком-портами, с USB-принтерами, есть визуальные компоненты (обеспечивающие построение html-интерфейса для отчетов и обработок).

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

Чем ваш "САПР проектировщика" будет отличаться от существующих IDE ?

[Crazy]

Есть такая хреновина, как Eclipse RCP

[deadhead]

И в первую очередь потому что это - именно SCADA. Они изначально проектировались как SCADA и ими и являются. (кроме последней - это какая-то бухгалтерская система).
Я же хочу разработать именно универсальную среду с универсальными компонентами.

Уже не для одного проекта видится удобным иметь набор компонентов с разным функционалом, которые бы можно было соединять друг с другом в различные программные системы: систему имитационного моделирования, SCADA и т.п.

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

[Crazy]

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

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

[Zeus]

Совершенно верно.
В абсолютном большинстве SCADA из вышеприведённого списка - по-крайней мере из тех, где видна внутренняя программная структура или она хотя бы вырисовывается из описания системы, - прямо "изо всех щелей лезет" назначение системы.
Всякие "подсистемы протоколирования", "источники сигналов", alarm'ы.

В моём же понимании, универсальная среда это в первую очередь - контейнер компонентов.
Функциональность контейнера - минимальна. Буквально самые необходимые сервисные функции. И никаких там "алармов" и т.п.
Всё остальное делают компоненты.


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

[Zeus]

гм... я на такое уже замахнулся) QDroid , гы))) (некоторое спутанное описание годовалой давности можно почитать на http://qdroid.berlios.de/docuw/ )

Почитал.
Суть, как я понял:
1. Qt снизу-доверху.
2. Qt-компоненты, сидящие в контейнере QDroid.
3. QtScript.
Приблизительно так получается?

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

Такие затейливые слова непривычны для уха пирата

Я всего-лишь программист АСУТП.
Что подразумевается под "бизнес-логикой"?
Первые два абзаца отсюда?

Бизнес-логика — в разработке информационных систем — совокупность правил, принципов, зависимостей поведения объектов предметной области (области человеческой деятельности, которую система поддерживает). Иначе можно сказать, что бизнес-логика — это реализация правил и ограничений автоматизируемых операций. Является синонимом термина «логика предметной области» (англ. domain logic).
Проще говоря, бизнес-логика — это реализация предметной области в информационной системе. К ней относятся, например, формулы расчёта ежемесячных выплат по ссудам (в финансовой индустрии), автоматизированная отправка сообщений электронной почты руководителю проекта по окончании выполнения частей задания всеми подчиненными (в системах управления проектами), отказ от отеля при отмене рейса авиакомпанией (в туристическом бизнесе) и т. д.

Если так, то функционал системы я рассчитывал поместить в компоненты.
Компонент "GUI-кнопка" - знает как эта кнопка работает.
Компонент "вентилятор" - знает всё об управляемом объекте.
Компонент "среднее геометрическое вектора" - тоже сам разберётся что ему с вектором делать и что выставить на выходе.
Т.е. если в предметной области появляется новое понятие, то нужно сделать новый компонент.
Тем более если появляется целая предметная область.

Описать новую бизнес-логику без механизма описания алгоритмов (суть - "скриптования") - вы не сможете.
_Теоретически_ - система настройки (невероятно гибкая!!!) вам может помочь, но это костыль.
"Системы настройки", без скриптования - не хватит (иначе бы адепты case-разработки и визуального программирования давно бы "вытеснили программистов с рынка").

Вот как-раз скрипты - сильно не хотелось бы.
Хотя в некотором упрощённом виде возможно и придётся их поддерживать (хотя есть мысли как это переложить на "плечи" командного интерпретатора).
В АСУТП моей конторы в качестве скриптового языка используется python.
Хотя я в своих проектах его применение уменьшил до минимума, как-раз-таки переносом всей логики в CORBA-компоненты.
python остался в процессе разворачивания приложения, инстанцирования компонентов, а в дальнейшем - не используется.
А не хочу скриптовые языки по причине:
1) Меньшей производительности.
2) Меньшей надёжности: пока код не отработает, ты не знаешь даже правильный ли он хотя бы с точки зрения синтаксиса, не говоря уже о тонкостях вроде типов переменных и т.п.

В принципе, народ уже спрашивал про IDE для QtScript - и я вижу что ваш "САПР проектировщика" как раз очень даже "близко звучит" как IDE для QtScript с возможностью легкого подключения расширений-компонент.

Я "САПР проектировщика" вижу похожим на... ну типа на Builder-Delphi.
Набрать проект из готовых "кирпичиков" (соединив их входы-выходы).
Какие-то из "кирпичиков" имеют графическое представление (окно, панель, SVG-картинка) - такие в процессе "накидывания" в проект сразу же вылезут на экран в режиме WYSIWYG и можно подкорректировать внешний вид, раскладку, размеры.
Собственно, наполняя проект в САПРе, проектировщик на самом деле уже и заполняет контейнер компонентами, устанавливает связи между ними - всё то, что потом выполнится автоматически, без САПРа - чисто по настроечным файлам, которые этот САПР и сгенерит.
Результатом работы САПРа являются:
1) Настроечные файлы.
2) Документация.
По второму - это я уже говорю как программист АСУТП, "наевшийся" этого по горло.
У компонентов должно быть развитое описание, выполненное программистом, который создавал этот компонент.
САПР на основе этого описания, плюс на основе структуры проекта (которую он знает, потому как сам её делал), плюс на основе некоторых шаблонов (например ЕСПД или какой-нибудь другой стандарт - забугорный например) - формирует программную документацию.
Совсем замечательно, если бы для компонентов, работающих с конкретным железом (полевые шины, модули ввода-вывода...) формировалась бы и конструкторская документация - тоже по шаблонам (ЕСКД и т.д.). Грубо говоря, чтобы готовые листики можно было вложить в проект железа.
А может даже (хотя до этого наверное не доживём) - САПР мог бы сгенерить и целиком проект шкафа. Понятно, что не всё автоматически. Много нужно ввести ручками, но всё же...

Чем ваш "САПР проектировщика" будет отличаться от существующих IDE ?

Да... чем...
Наверное тем же, чем они все друг от друга отличаются.
Всем.
Но вот если хотите "чисто визуально" я его вижу в чём-то похожим на Delphi, которым баловался лет 15 назад.
Но, понятно, что в дельфях это было чисто: накидать на форму кнопочек и описать реакцию на события.
У меня же упор делается на связывание входов-выходов (пока, по аналогии со SCADA на моей работе - аттрибутов) компонентов.
Т.е. компонент "Кнопка" имеет визуальное представление, но это - для пользователя программы, а в контейнере - он такой же компонент, как и все остальные компоненты.
И, например, по нажатию - производит рассылку значения своего аттрибута "pressed".
А этот "pressed" попадает на аттрибут "send" компонента tcp_send.
А данные для отсылки в этом tcp_send уже лежат в аттрибуте "data" и попали они туда из другого компонента с графическим представлением - textArea.

У меня, как у АСУТП-программиста, видение работы системы и работы с нею - примерно такое.

[Denjs]

Почитал.

>> 1. Qt снизу-доверху.

ну как бы на нем все и писано, если вы это имеете в виду... использование только Qt позволяет не заботиться в том числе и о кроссплатформенности.

>> 2. Qt-компоненты, сидящие в контейнере QDroid.

не совсем. Во первых - Qt-классы сидящие в "контейнере QDroid" - и то - только для расширений. Контейнер занимается регистрацией класса в скриптовом движке, в его системе метаданых, регистраией конструкторов класса. А вот уже созданные объекты - "погружаются" в скриптовую среду "без всяких контейнеров". через тот же QScriptEngine::newQObject()

>>3. QtScript.

гм... да. Он и является тем связующим свеном, которое загружает нужные компоненты, создает объекты, организует связи между ними, обрабатывает данные при необходимости и дергает их функции.

>>Что подразумевается под "бизнес-логикой"?

Я _здесь_ понимаю под этим логичку взаимодействия приложения с внешними миром.
Логику того приложения, в которое и набираются компоненты, что бы работать вместе и достигать цели создания приложения - полезную функцию.
слово "бизнес" я использовал в том смысле, что это задача, цуль сущетсвоания приложения во внешнем мире. Логика его работы с точки зрения внешнего наблюдателя, смотрящего на то, что должен делать объект.

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

Да, это все скажем так "не канонически", но я как системный аналитик, использующий в работе UseCase предпочиаю смотреть на проектируемый объект в первую очередь как на набор функций описывающий последовательность взаимодейтсвия, но не то как это взимодейтсвие реализуется...
ну мы отвлеклись.. последний абзац можно забыть.

>>А не хочу скриптовые языки по причине:
>>1) Меньшей производительности.
>>2) Меньшей надёжности: пока код не отработает, ты не знаешь даже правильный ли он хотя бы с точки зрения синтаксиса, не говоря уже о тонкостях вроде типов переменных и т.п.

Ваше право.
Я чаще всего сталкиваюсь с необходимостью "перекроить/расширить функции здесь и сейчас".

>>>>Denjs: В принципе, народ уже спрашивал про IDE для QtScript - и я вижу что ваш "САПР проектировщика" как раз очень даже "близко звучит" как IDE для QtScript ...
>>Я "САПР проектировщика" вижу похожим на... ну типа на Builder-Delphi.

имхо, одно другому не мешает... но

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

>>Собственно, наполняя проект в САПРе, проектировщик на самом деле уже и заполняет контейнер компонентами, устанавливает связи между ними -
>>всё то, что потом выполнится автоматически, без САПРа - чисто по настроечным файлам, которые этот САПР и сгенерит.

>>У меня же упор делается на связывание входов-выходов (пока, по аналогии со SCADA на моей работе - аттрибутов) компонентов.
>>Т.е. компонент "Кнопка" имеет визуальное представление, но это - для пользователя программы, а в контейнере - он такой же компонент, как и все остальные компоненты.

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

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

т.е. "просто так" - можно описать только типовые, базовые варианты взаимодействия.
Без дополнительного программирования как правило н еобойтись (см например на Blender - там питон весьма активно пользуется... при том что у него есть графические схемы распространения событий, объекты которые на них реагируют и прочее...)

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

так...? так. и все хорошо, пока мы находимся в рамках простых, "однофункциональных программ", работающих как "элемент обработки потоковых данных"...

________________________________________________________________________________
____________
но как только мы хотим большего.... тут есть более серьезная и "принципиальная проблема".
Радиосхема - статична. Т.е. её структруа не меняется в процессе работы системы.
и при этом функция эта - "статична", не меняется во времени. она одна.

А у программы - структура объектов в рантайме вполне себе может меняться.
new() и delete() не просто так придумано. Кроме того структура связей может меняться динамически. сейчас компонет источник был подключен к этому оъекту, а теперь события направляются к другому объекту. Потмоу что теперь надо регулировать уровень воды, а не температуру нагрева.

Определение связей на основе ini-файла - хорошо. но оно не даст вам возможности описать динамическое изменеие этих связей в рантайме и логику этого изменения.

Спроектируйте например в ваших статичных вариантах - логику работы простого чат-сервера. а-ля IRC.
Вроде все компоненты у нас есть, - но количнство экземпляров tcp-соединения - разное, и заранее не известно.
добавьте туда личные чаты, создание-удаление комнат ... и мы выйдем на необходимость программирования.

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

Хотя, для ряда систем, _простых_ по своей внутренней структуре - с одной статичной функцией - разработки в стиле понакидал элементов и определил связи - может быть вполне достаточно.
и факт того, что ini-файлы покрывают только часть задач - думаю можно считать доказанным?

_______________________________________________________________________
Причем "программирование логики работы" - должно вестись, скажем так - на "логический уровень выше", чем используемые вами компоненты.
Та точка, в которой будет определяться логика взаимосвязей ваших компонент - не может быть точно такой-же компонентой - потому что она должна знать о других компонентах.
А задача компонент - быть именно таким, что они ничего не знают друг о друге.

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

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

_______________________________________________________________________
PS: я вас не отговариваю. Я задаю вам вопросы на которые вы должны будете скорее всего отвечать при попытке создания приложений на базе вашей "универсальной компонентной среды".

PPS: А вот с документацией - вы это уж сами подумайте... это мало связано с проблемами о которых я вам рассказываю... это с моей точки зрения - дополнительная фича системы.

[Denjs]

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

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

Важно акцентировать внимание на том, что
1) на одноразоваой логике все и держится. Одноразовая логика использует "многоразовую".
2) "одноразовая логика" может быть "весьма хитрая".

Задача компонент - это хранение/описание "многоразовой логики".
"Одноразовая логика" - создается только для конкретного случая, и потому она должна быть описана отдельно, вне компонент.
вы пытаетесь описать одноразовую логику через описание связей между элементами, но програма - это не радиосхема, в общем случае - её логика работы может потребовать изменения объектной структуры в рантайме, не говоря о реализации собственного поведения...

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

[Crazy]

Чем не устраивает Rich Client Platform (RCP)?

[Denjs]

Вы вообще или автора?

Если вообще - то имхо жаба не нужна)))

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

Т.е. "программу" на выходе его "САПР проектировщика" можно будет ознозначно отрисовать "почти как схему-электрическую-принципиальную":
,

где каждая из "микросхем" или элементов - это программный модуль. А компонентная среда занимается только их связыванием, и передачей сигналов.

ну или смотрите "диааграмму взаимодействия" из UML.
"

Т.е. если я правильно понимаю его идею - то Zeus хочет свести разработку программы _только_ к созданию такого рода схемы. Ну и разработке "модулей".
Zeus, я правильно излагаю ваши идеи?

[Crazy]

Вы вообще или автора?

RCP это взгляд на архитектуру.

Если вообще - то имхо жаба не нужна)))

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

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

Пусть смотрит на LabVIEW и его графический язык G.

[Denjs]

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

Пусть смотрит на LabVIEW и его графический язык G.

LabVIEW ? о! ссыль: http://labview-rus.blogspot.com/

[Crazy]

LabVIEW ? о! ссыль: http://labview-rus.blogspot.com/

Когда смотришь на LabVIEW, понимаешь куда катится современные САПРовские системы.

[Zeus]

Напишу без особого цитирования, просто по пунктам:

1. Возможно я действительно смотрю на поставленную задачу со своей позиции и концепция сборки приложения "из кубиков" без "вольного программёжа" имеет определённые ограничения. Какой-нибудь офис наверное таким образом не построишь. Пусть так.
Однако для решавшихся мною по работе задач:
- программирование SCADA нашей конторы,
- "мост" между двумя системами телемеханики,
- специализированный программный осциллограф,
- система имитационного моделирования (её правда не доделал, но компонентная концепция была заложена и в ней),
все эти задачи я решал путём создания некоей компонентной модели, движка, в котором эти компоненты "варятся" и конфигурируется это всё XML'ем.
И, на мой взгляд, эти довольно разнотипные задачи вполне себе решались без привлечения скриптовых языков. Только путём "соединения входов и выходов".
Однотипность принципов решений этих задач, но разнообразная их программная реализация и подтолкнула меня к мысли: зачем каждый раз, для каждой задачи писать новое? Может разработать один общий, универсальный движок, привести все созданные компоненты к его интерфейсу и получить гибкую систему.

2. Насчёт "ящика с изменяемой логикой".
Ведь никто не запрещает создать такой компонент, в котором будет не чётко зашитая логика, а просто интерпретатор некоего языка. Любого.
Архитектура это не запрещает.
В этом-то основная идея и состоит: в виде КОМПОНЕНТОВ, можно написать что угодно, но САМ ДВИЖОК ничего такого в себе не содержит. Он просто контейнер компонентов, которые имеют общий программный интерфейс, ориентированный на взаимодействие аттрибутами.
(вот потихоньку вытягивают из меня мысли, которые я хотел сформулировать и изложить в следующем документе).

3. Насчёт статичности такой программной структуры.
Если говорить именно о структуре, то почему она обязательно должна быть статична?
Например на этапе запуска, когда контейнер наполняется компонентами, устанавливаются связи - она меняется каждое мгновение.
И ничто не мешает ей меняться и в дальнейшем. Внутри контейнера на это нет никаких ограничений. Всё зависит от управления этим контейнером.
Может ему на вход будет подаваться "бесконечный настроечный файл", в котором постоянно будут удаляться старые компоненты, создаваться новые, будут устанавливаться новые связи.
У компонентов может быть аттрибут delete.
Как, кстати, и new (или clone).
Не стоит забывать и про п.2 - компонент-интерпретатор.
Архитектура движка ничему этому не препятствует.

4.

Я использую Qt ещё и потому, что сигнал слотовый механизм позволяет мне связать 2 объекта которые созданы разными библиотечками, которые не знают ничего друг о друге ни этапе сборки ни в рантайме....

Эти два объекта знают друг о друге главное: они оба поддерживают механизм "сигнал-слот".
Ну и тут так же: ВСЕ компоненты имеют одинаковый базовый интерфейс, достаточный для получения доступа к специфическому набору аттрибутов любого компонента.

5.

PS: я вас не отговариваю. Я задаю вам вопросы на которые вы должны будете скорее всего отвечать при попытке создания приложений на базе вашей "универсальной компонентной среды".

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

6. "Автодокументирование" - конечно это не функция движка. Это, скажем так, "навязанный стиль" программистам компонентов, который использует САПР - совершенно отличное от движка приложение.

7. Java, при всём моём к ней уважении, не хотелось бы.
Как-то не вижу я её в объектных контроллерах или в качестве ПО АРМ диспетчера какого-нибудь большого диспетчерского центра перед которым огромный полигон управления... (типа ЦУПа в Звёздном городке).
У нас лет 10 назад SCADA была сделана на Java. Точнее - как-раз графическая "морда". Логика была на C++ и связывалось это по CORBA.
Я тогда был программёр ещё сырее, чем сейчас, поэтому всех подробностей не знаю, но более опытные программисты - которые это всё и разрабатывали, от Java в итоге отказались в пользу... QT GUI. Впрочем сейчас и он их не устраивает и всё переписано на GTK.

8.

Т.е. если я правильно понимаю его идею - то Zeus хочет свести разработку программы _только_ к созданию такого рода схемы. Ну и разработке "модулей".
Zeus, я правильно излагаю ваши идеи?

В идеале - да. Для большинства приложений должно хватить модулей.
Если какая-то логическая функция достойна тиражирования - она реализуется в виде ещё одного модуля так сказать "системным программистом".
В противном случае (видимо то, что было названо "одноразовой логикой) - если уж без этого никак не обойтись, ну тогда использовать какой-то "программируемый модуль" и накидать НЕБОЛЬШОЙ, предельно простой и "прозрачный" скрипт для него.

9. LabView.
Я когда делал тот самый упомянутый мною специфический осциллограф, то рассматривал как вариант и использование LabView.
Основной "затык" в разработке заключался в драйвере для АЦП. Железка такая... не очень удобная для поставленной задачи, но какая уж была.
Я надеялся, что "уж в LabView-то драйвер наверное есть и тогда я убедю начальство купить лицензию и будет мне щастье".
Драйвер действительно был, но такой который у меня уже был сделан.
Для осциллографа он не годился и вина в этом была не его. Да и не LabView. Железка просто такая.
Пришлось делать всё самому.
И понятно, что дело не в LabView, но после этого я стал смотреть на неё как-то... снисходительно что-ли. Типа, я ждал от неё большего
Короче, чистая психология.

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

P.S.

Когда смотришь на LabVIEW, понимаешь куда катится современные САПРовские системы.

А поподробнее?

[Crazy]

все эти задачи я решал путём создания некоей компонентной модели, движка, в котором эти компоненты "варятся" и конфигурируется это всё XML'ем.
И, на мой взгляд, эти довольно разнотипные задачи вполне себе решались без привлечения скриптовых языков. Только путём "соединения входов и выходов".

Скорее всего использовалась потоковая модель, которая никак не относится к универсальной.

Java не подходит для Real Time систем.
За универсальность все равно придется расплачиваться.

[Zeus]

Скорее всего использовалась потоковая модель, которая никак не относится к универсальной.

В каком смысле?
"Универсальная" - это вообще так сказать "общечеловеческое" слово, а не какой-то вид модели.

[Denjs]

концепция сборки приложения "из кубиков" без "вольного программёжа" имеет определённые ограничения.

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

Почему-то мне пришла в голову ассоцияция с некой "универсальной шиной обмена сообщениями", к которой вы подключаете выаши объекты-компоненты, и настраиваете каналы обмена информацией.

Т.е. выходит так, что "Универсальную компонентную среду" можно будет большей частью свести к идее "шины/среды обмена сообщениями с настраиваемыми каналами связи"?
просто так уж более понятнее что из себя это представляет технически и сразу становится понятнее назначение, возможности и возможные способ применения подсистемы.

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

Эти два объекта знают друг о друге главное: они оба поддерживают механизм "сигнал-слот".
Ну и тут так же: ВСЕ компоненты имеют одинаковый базовый интерфейс, достаточный для получения доступа к специфическому набору аттрибутов любого компонента.

Ну так и используйте сигнал-слотовый механизм)))) он и есть эти самые ваши связи между объектами.

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

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

Представление о программе Qt как о наборе модулей радио-аппаратуры - оно постоянно витает.
Если вы сможете генерировать схемы структуры и связей для момента времени - это думаю позволит гораздо быстрее разбираться в чужих программах.

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

потому что выше -

все эти задачи я решал путём создания некоей компонентной модели, движка, в котором эти компоненты "варятся" и конфигурируется это всё XML'ем.

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

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

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

[Zeus]

концепция сборки приложения "из кубиков" без "вольного программёжа" имеет определённые ограничения.

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

Да ну, вот ещё. Пусть практика, так сказать сама жизнь и покажет границы применения

Почему-то мне пришла в голову ассоцияция с некой "универсальной шиной обмена сообщениями", к которой вы подключаете выаши объекты-компоненты, и настраиваете каналы обмена информацией.
Т.е. выходит так, что "Универсальную компонентную среду" можно будет большей частью свести к идее "шины/среды обмена сообщениями с настраиваемыми каналами связи"?

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

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

Это если будет шина.
Кстати, недостаток шины в том, что это - некий ОДИН программный объект. В терминах паттернов проектирования можно даже сказать singleton.
И если он, извиняюсь, "встал раком" (заблокировался на каком-нибудь объекте ядра или ещё чего), то всё - работа всей системы встала. Нужно рестартить.
А если компоненты сами занимаются рассылкой своих аттрибутов, то - ну "загнулся" какой-нибудь компонент, ну остановилась логика в одном сегменте приложения - остальное приложение продолжает работать и можно как-нибудь доковылять до такого состояния (или времени) когда можно вывести систему на техобслуживание (грубо говоря - перезагрузить).

Эти два объекта знают друг о друге главное: они оба поддерживают механизм "сигнал-слот".
Ну и тут так же: ВСЕ компоненты имеют одинаковый базовый интерфейс, достаточный для получения доступа к специфическому набору аттрибутов любого компонента.

Ну так и используйте сигнал-слотовый механизм)))) он и есть эти самые ваши связи между объектами.

Вот как в знатоку Qt и его "потрохов" - вопрос:
насколько механизм "сигнал-слот" подобен декларируемому мною мехнизму "аттрибут-связь"?
Это просто разные названия одной и той же сущности или всё-таки в Qt имеется ввиду что-то другое?
Навскидку: я так понимаю, что приёмником "сигнала" в механизме "сигнал-слот" Qt является любая функция. Главное, чтобы сигнатура совпадала с той, на которую рассчитывает сигнал. Так?

Просто в "моей" аттрибутной модели - аттрибут это некое ОДНО значение. Ну или если говорить о "потрохах" компонента: функция с одним параметром.
Т.е. у аттрибута есть только тип. Его сигнатура состоит только из одного параметра.

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

Я вот как-раз не хочу завязываться на Qt.
Отдельные компоненты, а может даже целый "кластер", семейство компонентов - вполне могут быть написаны на Qt. И если хотят - могут и взаимодействовать между собой средствами Qt. Но в контейнер этой универсальной компонентой среды они встраиваются и связываются как компоненты этого контейнера. И сообщения они получают из контейнера так же как и остальные компоненты.
Что уж они там "воротят" за рамками взаимодействия компонентов контейнера - это их дело, но такой подход позволит стыковать, например, Qt-компоненты и компоненты, которые о Qt не имеют никакого представления. И наоборот. И вообще не Qt, а Gtk или какая-нибудь математическая библиотека, или компоненты, обслуживающие железо. Всё это можно запихать и состыковать друг с другом, если обеспечить единый программный интерфейс.

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

потому что выше -

все эти задачи я решал путём создания некоей компонентной модели, движка, в котором эти компоненты "варятся" и конфигурируется это всё XML'ем.

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

Хорошо. XML это я упомянул в связи с уже разработанными проектами. Там, да - начальное состояние, конфигурируется XML.
Но:
1) Даже в этом случае связи между компонентами не обязательно должны быть статичны.
Они меняются (точнее, для моих задач их надо было разрывать и устанавливать снова - в зависимости от внешних условий).
Занимаются этим - сами компоненты, под управлением своей логики.

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


Denjs date='Apr 24 2011, в 05:29':
Просто помещать алгоритм управления котейнером в один из компонентов находящихся внутри контейнера... это может выползти непонятной логической лапшой и неструктурированностью логики работы програмы... имхо...
=============
Я в общем-то не вижу в этом ничего страшного, но уже выше отмечал, что всё-таки такие "программируемые скриптом компоненты" нужно использовать только в крайнем случае.

[Crazy]

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

Это будет зависеть от архитектуры. Примером можно считать циклы обработки событий в Qt, или асинхронный режим Boost.Asio.

[Zeus]

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

Это будет зависеть от архитектуры. Примером можно считать циклы обработки событий в Qt, или асинхронный режим Boost.Asio.

Примером - чего?

[Crazy]

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

Это будет зависеть от архитектуры. Примером можно считать циклы обработки событий в Qt, или асинхронный режим Boost.Asio.

Примером - чего?

Примером такой шины.

[Zeus]

В смысле - там нечему "ломаться"?

[Denjs]

концепция сборки приложения "из кубиков" без "вольного программёжа" имеет определённые ограничения.

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

Да ну, вот ещё. Пусть практика, так сказать сама жизнь и покажет границы применения

)))) хорошо. перефразируем. Освойте для начала хотя бы одну область. Пока вы не сконцентрируетесь хотя бы на одном - вы не сделаете ничего.

Почему-то мне пришла в голову ассоцияция с некой "универсальной шиной обмена сообщениями", к которой вы подключаете выаши объекты-компоненты, и настраиваете каналы обмена информацией.
Т.е. выходит так, что "Универсальную компонентную среду" можно будет большей частью свести к идее "шины/среды обмена сообщениями с настраиваемыми каналами связи"?

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

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

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

Это если будет шина.
Кстати, недостаток шины в том, что это - некий ОДИН программный объект. В терминах паттернов проектирования можно даже сказать singleton.
И если он, извиняюсь, "встал раком" (заблокировался на каком-нибудь объекте ядра или ещё чего), то всё - работа всей системы встала. Нужно рестартить.
А если компоненты сами занимаются рассылкой своих аттрибутов, то - ну "загнулся" какой-нибудь компонент, ну остановилась логика в одном сегменте приложения - остальное приложение продолжает работать и можно как-нибудь доковылять до такого состояния (или времени) когда можно вывести систему на техобслуживание (грубо говоря - перезагрузить).

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

В смысле - там нечему "ломаться"?

Думаю, основной посыл в том, что оно работает и вполне надежно. А второй посыл, имхо : то, что вы начнете создавать сами - рискует быть гораздо менее надежным решением. имхо.


Попробуйте сделать "исполняемую архитектуру" с использованием хоть чего-либо уже существующего. а потом уже будете решать после обкатки - стоит ли вам идти тем или иным путем.
Вы конечно можете сначала взвешивтаь все за и против, но ПО иногда разумнее выращивать, чем строить. Постройте маленький прототип и попробуйте его вырастить.... или 2 прототипа на одной или другой технологии....

[Denjs]

насколько механизм "сигнал-слот" подобен декларируемому мною мехнизму "аттрибут-связь"?

может быть я плохо онимаю что это такое? "механизм атрибут связь"...
уж не частный ли он случай механизма сигналов и слотов Qt? у многих классов есть сигналы которые извещают внешний мир об изменении тех или иных атрибутов...

Это просто разные названия одной и той же сущности или всё-таки в Qt имеется ввиду что-то другое?
Навскидку: я так понимаю, что приёмником "сигнала" в механизме "сигнал-слот" Qt является любая функция. Главное, чтобы сигнатура совпадала с той, на которую рассчитывает сигнал. Так?

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

Просто в "моей" аттрибутной модели - аттрибут это некое ОДНО значение. Ну или если говорить о "потрохах" компонента: функция с одним параметром.
Т.е. у аттрибута есть только тип. Его сигнатура состоит только из одного параметра.

в Qt вы можете объявить даже сигналы и столы без аргументов. пример такого сигнала - QAbstractButton::pressed()

[Zeus]

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

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

Кроссплатформенную систему создать вряд ли удастся без привлечения Java, .Net или чего-то подобного.
Я больше задумываюсь о мультиплатформенной, т.е. системе, представленной на разных платформах.
А для упрощения этого - система должна быть максимально простой и по минимуму использовать сторонние библиотеки.

Остальное - завтра.

[Crazy]

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

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