Раз уж речь зашла о графическом представлении кода - советую всем скачать бесплатную среду программирования для детей - Scratch http://scratch.mit.edu/

Там операторы представлены в виде блоков которые бросаются на экран, цепляются друг к другу, втавляются в блоки if или for, while.
Сами блоки имеют небольшие выемки поля, куда скажем прописывается условие для if или сколько раз прокручивать цикл. Или какой звуковой файл проиграть (можно выбрать из списка.)

На сайте куча примеров простеньких игр.
Среда полностью обьектно ориентированная (smalltalk). Обьекты обмениваются сообщениями (events).

осле того как наиграетесь, поймете что графическое представление кода конечно шикарно подходит для обучения детей, Но как только начинаешь писать нечто более менее большое (до тысячи строк кода), то заколебаешься просто таскать мышкой по экрану все эти блоки.
Для описания невизуальной информации текст все таки вне конкуренции. А потому Кады всякие только для визуальных дел (чертежи, GUI экраны, web страницы) и останутся.

Попробуйте сами, убедитесь.

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


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

Я тоже не в восторге от UML. Но процитированное выше обобщение совершенно неверно. Такие графические средства разработки, как автокад или геоинформационные системы (список можно продолжить) "тянут" очень сложные проектируемые системы. Просто для сложных программных систем еще нет хороших графических средств разработки. Видимо, сказалась сравнительная молодость, сложность для понимания и анархичность программной отрасли.

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

Ответ на »сообщение 3018« (Александр)
___________________________

Ответ на »сообщение 3017« (Илья Ермаков)
___________________________
Вот только одна проблема, ТЗ не дает представление о масштабах проекта всего.
ТЗ описывает потребности заказчика.

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

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

P.S. Еще раз извиняюсь за плохой пример.

Ответ на »сообщение 3017« (Илья Ермаков)
___________________________
Вот только одна проблема, ТЗ не дает представление о масштабах проекта всего.
ТЗ описывает потребности заказчика.

Ответ на »сообщение 3009« (Александр)
___________________________

Ответ на »сообщение 3000« (Илья Ермаков)
___________________________
ТЗ как высокоуровневая описательная часть которая понятна как заказчику так и исполнителю, по ТЗ делается спецификация и если нужно чертежи которые уже понятны только исполнителю (за редким исключением) и дальше по спеке и чертежам делается некоторый продукт с помощью некоторого инструмента. Какой будет инструмент это уже вопрос отдельный и может быть не главный, на мой взгляд главный вопрос насколько эффективно (с наименьшими трудозатратами) с помощью этого инструмента будет выполнено ТЗ.

А на каждом этапе трансляции ошибки, ошибки, ошибки... Причины несоответствий трудно найти, для этого надо опять проделать все этапы трансляции... Бррр.
Одна из идей модульных языков - пригодность к использованию в качестве языков спецификаций и архитектуры. Т.е. выше ЯВУ находится только "живой" язык ТЗ (текст, графика и т.п., но неформальное).

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

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

Ответ на »сообщение 3009« (Александр)
___________________________
Но представте мастера художественной ковки. Он сам себе заказчик. Берет молот, кусок металла и начинает фантазировать.
Вот таковы приверженцы Оберона. Они на нем думают и формулируют. То, что его еще и непосредственно понимает компьютер, для них только дополнительный плюс.

Вот-вот, иногда как подумаешь - а ить он ещё и вертится :-)))

Ответ на »сообщение 3012« (Александр)
___________________________
Произнеси еще раз, недопонял (С)
Очень туманные фразы, попробуйте почетче сформулировать.
А то получается - "казнить нельзя помиловать".

Ответ на »сообщение 3013« (Александр)
___________________________
Су-30МКИ на ИАЗе (Иркутский авиационный завод) это массовое производство ?
Откуда я могу знать? Пусть пригласят, я поползаю по технологическим цепочкам, классифицирую отдельные производства и скажу, к каким типам они относяться и какими методами их лучше всего автоматизировать.
Но тут обсуждается производство ПО, имеющее определенную спицифику, хотя и подчиняющееся общим принципам организации производства.

Ответ на »сообщение 3010« (Сергей Перовский)
___________________________
По поводу мейнстрима и массового производства. Сергей (вообщем вопрос для всех) ответьте Су-30МКИ на ИАЗе (Иркутский авиационный завод) это массовое производство ?