Ответ на »сообщение 2749« (Сергей Прохоренко)
___________________________

Ответ на »сообщение 2747« (Beginner)
___________________________

Ответ на »сообщение 2735« (Сергей Прохоренко)
___________________________
Очень печально :(
Ваши примеры по ссылкам - стандартные RAD со старыми граблями.


А вы хотели чего-то готовенького? Так его нет в природе - надо делать.
А по ссылкам можно найти только отдельные интересные элементы.

Предлагаю Вашему (и не только) вниманию:

• HIASM - конструктор программ (www.hiasm.com). Явно нестандартный RAD (с новыми граблями). :)
  
• Clarion (уже обсуждался) - если Вы ещё с ним незнакомы, возможно, это то, что Вам нужно!
  Демо версии 5 - ftp://ftp.clarion.ru/Demo%20&%20Free/C5/c5eval/c5eval_full.zip (сейчас актуальна версия 6)
  
• 1С. Просьба не пинать. Интересует мнение именно о GUI (конструктора). На мой взгляд, есть приятные моменты.
  
• Suneido (www.suneido.com) - is a complete, integrated application platform - a system for developing and deploying applications without the frustrations of integrating multiple different products. ... Suneido is Open Source - it is provided free, with complete source code. Также любопытно мнение присутствующих.
  

Ответ на »сообщение 2746« (Сергей Прохоренко)
___________________________
Я сомневаюсь, что в Дельфи есть панель зависимости объектов как в Access'е (под объектом здесь понимается всё, что угодно, а не понятие ООП).
Зависимость всего, чего угодно, представить сложно, но зависимость модулей, компонентов, объектов, полей, методов и процедур отображается в древовидной структуре.

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

Ответ на »сообщение 2748« (Сергей Прохоренко)
___________________________
Никто же не заставляет. Можете разбить одним способом.
Могу, только большинству будет не удобно.
С теми же кораблями: для судостроителя корабль делится на секции, которые будут изготавливаться отдельно, для командира корабля на боевые части (размазанные по кораблю экзотическим образом), для специалиста по остойчивости на отсеки. Еще есть попалубное деление, по различным сетям и т.д. и т.п.
То же самое с структурой программы: как только, кроме замечательной логики нужно отобразить обработку исключений и обмен сообщениями и, не дай бог, параллельные процессы,  так с графическом представлением возникают проблемы.

Ответ на »сообщение 2747« (Beginner)
___________________________

Ответ на »сообщение 2735« (Сергей Прохоренко)
___________________________
Очень печально :(
Ваши примеры по ссылкам - стандартные RAD со старыми граблями.


А вы хотели чего-то готовенького? Так его нет в природе - надо делать.
А по ссылкам можно найти только отдельные интересные элементы.

Ответ на »сообщение 2744« (Сергей Перовский)
___________________________

Ответ на »сообщение 2742« (Сергей Прохоренко)
___________________________
Одна большая блок-схема сразу отпадает - не влезет ни в какой экран, и связи отслеживать тяжело. Размещение сотен объектов одновременно на экране тоже отпадает по той же причине. Все эти сотни надо разбить на десятки групп (нажал на плюсик - и уведел объекты в группе, нажал на минус - они скрылись).
А разбить нужно десятком разных способов :(


Никто же не заставляет. Можете разбить одним способом.


Добавить древовидную панель зависимостей (как в Access'е). Для установления связей между объектами удобно использовать мышиную технологию: щелкнул на одном объекте, протянул до другого и отпустил. Связь готова, автоматически вываливается таблица настройки связи. Отдельно можно посмотреть таблицы всех связей, связей внутри выбранной группы или связей между группами.
Для каждого вида связи потребуется свое дерево.


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


В современном автомобиле километр проводов. А попробуйте построить сколько-нибудь подробную модель авианосца. Картинки будут полезны, но абсолютно недостаточны.


О каких картинках речь? До сих пор мною описывались только списки и таблицы.


И это будут статические модели, динамику и логику работы они не отражают.


Отражают. Код на декларативном (функциональном или логическом) языке программирования тоже выглядит стачично - но это только видимость.


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


Совершенно согласен. Я тоже против блок-схем как стандартного человеко-машинного интерфейса. Их место в презентациях.

Ответ на »сообщение 2735« (Сергей Прохоренко)
___________________________
Очень печально :(
Ваши примеры по ссылкам - стандартные RAD со старыми граблями.

Ответ на »сообщение 2743« (Сергей Осколков)
___________________________

MS Access (построитель выражений в конструкторе запросов, построитель макросов и построитель форм, панель зависимости объектов)
Вообще-то все это есть и в Дельфи и, подозреваю, и в других средах разработки. Сейчас по-моему его уже не поставляют, а в предыдущих версияхе был графический построитель запросов (Visual Query Builder). Совершенно обычная вещь - визуальный редактор форм. Но это понятно, форма - графический объект, естественно её и проектировать графически. Есть окно, где отображается структура объектов. Есть средства моделирования с поддержкой UML.
Так что всё это вполне обычные хорошо знакомые вещи и непонятно по какому поводу домаются копья.

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


Во-первых, ничего этого нет в Блэкбоксе, кроме конструктора форм, который был приведен просто для сравнения.

Во-вторых, насколько мне известно, в Дельфи нет построителя кода и нет структурированных гипертекстовых документов с кодом, и я сомневаюсь, что в Дельфи есть панель зависимости объектов как в Access'е (под объектом здесь понимается всё, что угодно, а не понятие ООП).

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

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

Ответ на »сообщение 2731« (Ка джа)
___________________________
Пером в экран неудобно - закрываете часть экрана и рука на весу.
А для наладонников перо давно стандарт.
Кстати, экранное перо, если не ошибаюсь, было ещё до мыши. Было легко организовать синхронизацию по линиям развёртки ЭЛТ монитора.
Мышь более удобна - основание ладони на столе, управление пальцами - наиболее "интеллектуальные", тонкие инструменты (кроме языка, наверно:).

Ответ на »сообщение 2742« (Сергей Прохоренко)
___________________________
Одна большая блок-схема сразу отпадает - не влезет ни в какой экран, и связи отслеживать тяжело. Размещение сотен объектов одновременно на экране тоже отпадает по той же причине. Все эти сотни надо разбить на десятки групп (нажал на плюсик - и уведел объекты в группе, нажал на минус - они скрылись).
А разбить нужно десятком разных способов :(

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

MS Access (построитель выражений в конструкторе запросов, построитель макросов и построитель форм, панель зависимости объектов)
Вообще-то все это есть и в Дельфи и, подозреваю, и в других средах разработки. Сейчас по-моему его уже не поставляют, а в предыдущих версияхе был графический построитель запросов (Visual Query Builder). Совершенно обычная вещь - визуальный редактор форм. Но это понятно, форма - графический объект, естественно её и проектировать графически. Есть окно, где отображается структура объектов. Есть средства моделирования с поддержкой UML.
Так что всё это вполне обычные хорошо знакомые вещи и непонятно по какому поводу домаются копья.

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