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

Ответ на »сообщение 2730« (Мухтар )
___________________________
Ничего сложного в графике нет.
Двусмысленная фраза... :)
Я действительно не видел ни одного удачного графического представления по настоящему сложных систем.
Например принципиальная схема зенитно-ракетного комплекса на 1000 листов вызывала у меня очень тяжелые ощущения. Таблица соединений была бы компактнее и проще в использованиии. Очень трудно ползти по линии соединения среди десятков других линий и не сбиться. Меня ведь интересовало только куда линия приведет.
Если нужно наглядно представить взаимодействие десятка объектов, очень удобно рисовать квадратики и стрелочки. А если хотя бы сотни?

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

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

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

Какие болтуны-то тут все...
Один Сергей Перовский всегда по делу-то высказываетца -- наш решпект!

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

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

Ответ на »сообщение 2730« (Мухтар )
___________________________

По поводу графических интерфейсов

Люди боятся, что это что-то сильно сложное? Отсюда поиск желаемых недостатков GUI?
Ничего сложного в графике нет.

В графике действительно ничего сложного нет, а вот в GUI есть - психология.

Ответ на »сообщение 2730« (Мухтар )
___________________________
Ничего сложного в графике нет.
Двусмысленная фраза... :)
Я действительно не видел ни одного удачного графического представления по настоящему сложных систем.
Например принципиальная схема зенитно-ракетного комплекса на 1000 листов вызывала у меня очень тяжелые ощущения. Таблица соединений была бы компактнее и проще в использованиии. Очень трудно ползти по линии соединения среди десятков других линий и не сбиться. Меня ведь интересовало только куда линия приведет.
Если нужно наглядно представить взаимодействие десятка объектов, очень удобно рисовать квадратики и стрелочки. А если хотя бы сотни?

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

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

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

Ответ на »сообщение 2733« (Руслан Богатырев)
___________________________

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

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

Ответ на »сообщение 2732« (Ка джа)
___________________________

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

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

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

Дракон - вовсе не мой пример (я этого дракона и в глаза не видел, но думаю, что блок-схемы - это тупиковая ветвь эволюции графического интерфейса - они слишком неуклюжие и плохо умещаются на выделенном им месте). См. http://forum.oberoncore.ru/viewtopic.php?f=28&t=493&st=0&sk=t&sd=a&hilit=%D0%B4%D1%80%D0%B0%D0%BA%D0%BE%D0%BD

Посмотрите на реализацию графического интерфейса в ПО: MS Access (построитель выражений в конструкторе запросов, построитель макросов и построитель форм, панель зависимости объектов) и Business Objects (Data Integrator и презентационная графика во многих модулях). Определенные удачные моменты есть и в MS Excel (построитель выражений, панель управления структурой документа, запись макроса по совершенным действиям - как на магнитофон).

Вот ссылка на более-менее систематизированное описание того, как графический интерфейс программирования должен выглядеть по моему мнению (это лишь первый набросок):

http://forum.oberoncore.ru/viewtopic.php?f=7&t=389&st=0&sk=t&sd=a&start=20#p7339

И несколько внешних ссылок:

http://gurin.tomsknet.ru/visual2k.html

http://rsdn.ru/article/philosophy/LOP.xml

http://www.eplsw.com/Introduction_IDE.asp

http://community.sharpdevelop.net/blogs/mattward/articles/FeatureTourCodeGeneration.aspx

Ответ на »сообщение 2726« (Илья Ермаков)
___________________________

Ответ на »сообщение 2724« (Сергей Прохоренко)
___________________________
Ответ на »сообщение 2715« (Руслан Богатырев)
___________________________
Отвечая на более раннее сообщение: цель графического интерфеса следующая. Старая технология программирования себя полностью исчерпала. Никакого прогресса в росте производительности труда программистов, сокращении сроков разработок и в качестве программных продуктов не наблюдается (попробуйте это опровергнуть фактами!).

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

Оптимизировать особыми инструментами можно только отдельные области - например, параллельное программирование, работа с СУБД и т.д., по специализациям.

http://www.altshuller.ru/triz/zrts3.asp

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

Если принципиально новый графический интерфейс (как программистский, так и пользовательский) будет в новой ОС, то это будет её огромное достоинство, ради которого на неё будут переходить.

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

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