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

http://www.posc.org/Specifications/Epicentre_V30/

Дальше можно щёлкнуть "Logical Model" для просмотра текстового представления, или "ER Diagrams" для просмотра графических представлений.

Например, щёлкаем "ER Diagrams" - появляется 5 фреймов - один большой слева, четыре узких справа. В третьем сверху (ERD Index) выбираем 1-й элемент (AC1: Activity Schedule) - слева появляется эта диаграмма.
Одна из самых больших сущностей в ней - это "activity".
Подносим курсор мыши к сущности и ждём несколько секунд. Третий сверху фрейм изменяется: 12 ER Diagrams with Entity: "activity", т.е. появляется список только тех диаграмм, в которых есть сущность "activity".
Щёлкнув на сущность, получаем её текстовое описание и т.д.

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

Сергей, откомментируйте пожалуйста приведенные в 2735 ссылки! Какие моменты вы там выделяете как важные?

Ответ на »сообщение 2767« (Как слышно? Приём!)
___________________________

А там и о аналоге UML можно подумать.

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

Это подразумевает свою достаточно универсальную методологию, свой инструментарий, свои языки, свою операционную платформу. При этом постараться снизить порог вхождения, сделать приемлемой для нынешних разработчиков миграцию в эту методологию, а также обеспечить поддержку параллельного сосуществования хотя бы одной из трех популярных операционных платформ: POSIX (Си), Java Platform (Java), .NET/CLR (C#).

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

Ответ на »сообщение 2768« (Как слышно? Приём!)
___________________________
Блин, пропало начало!
О том, что модель должна идти впереди расчёта.
Там речь шла о том, что в моей практике был случай, когда была построена модель
с непрерывной функциональной зависимостью. Выполнялись расчёты и так и этак - одни ошибки.
И только когда была построена графически одна часть баланса и другая и проводилось
их сопоставление в виде графиков стало понятно, что речь идёт о гистерезисной зависимости.
Авост возникал при прохождении зоны S-образной зависимости.
Далее см. 2768.

Ответ на »сообщение 2727« (Valery Solovey)
___________________________
Навесить математику на это - плёвое дело, дело техническое.
Модель, когда закладывалась непреравная функция внешнего поля была неверна.

>>> Закончил ваять и начал пристально рассматривать своё вторение.
>>> А потом воскликнул: "Ба! Дак это ж санузел!"
Такое бывает! Долго шёл негр по пустыне, нашёл кувшин с джином и попросил у него,
чтобы рядом всегда журчала вода, быть белым, и много голых женщин рядом.
Джин воскликнул: "Ба! Дак это ж санузел!" Помните такой баян?

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

>>> Каждый раз при попытке познать что-то новое всё начинается с нулевой отметки.
Ну, что Вы! Если Вы о науке, то происходит отвоёвываение суши от океана, как в Голландии или Японии.
Уже есть фреймвок к которому принайтовывается новых блок после согласования и подгонки.

>>> Просто эти средства развращают.

А Вы не путаете любовь и разврат?

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

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

Графика хороша в интерактивном конструировании. Здесь текст плачет и отдыхает.
Скомбинировали и попробовали. Причём комбинирование идёт не методом тупого тыка.
Как уже упоминалось, у блоков есть разъёмы разного вида и сцепить несоответствующие не удастся.
Это резко снижает количество комбинаций.
Кроме того, было предложение индицировать логический траффик.

Надеюсь, что нужды разработчиков Росы на инструмент для сетей Петри создает поле деятельности
для апологетов графики по-любому. Что бы тут не говорили заговорщики-текстовики :)
А там и о аналоге UML можно подумать.
С тем, что блок-схемы отошли в прошлое не согласен.
Это перегиб палки периода эйфории от структурного программирования.

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

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

Ответ на »сообщение 2757« (Сергей Прохоренко)
___________________________
У Вас уже есть модель в форме математической записи условий. Ваша задача как программиста - сделать модель понятной для компьютера.
И для человека!

Компьютер вполне понимает математическую запись условий. Что еще нужно?
Компьютер к сожалению ничего не понимает :(
И современный софт "понимает" только очень небольшую часть математических условий.


В простейшем случае все объекты получают все сообщения. Затем объект проверяет выполнение условия, содержащегося в сообщении.
Ну вот, опять в "простейшем случае"....
Проверка условия может потребовать нескольких суток вычислений. Будем проверять у всех подряд?

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

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

для сферы ИТ как раз характерно то, что люди лепят (потому что лепка физическими ограничениями гораздо слабее ограничена, чем, скажем, проектирование самолетов), а потом делают "впиндюринг" (забыл, кто тут сказал, хорошее словцо).

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

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

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

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

>>> Какие именно проблемы? ... А с текстовым представлением они не возникают?

Очень даже возникают проблемы с текстовым представлением.

"И ответил мне меняла кратко:
О любви в словах не говорят.
О любви вздыхают лишь украдкой
И глаза как яхонты горят.

Поцелуй названья не имеет -
Поцелуй не надпись на гробах.
Алой розой поцелуи веют,
Лепестками тая на губах.

От любви не требуют поруки.
С нею знают радость и беду.
"Ты моя" сказать лишь могут руки,
Что срывали чёрную чадру."

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

О чем говорит, что человек не может кого-то убедить, даже нескольких?
Да много вариантов:
что не прав;
что не умеет убеждать;
что не понимает, что идет против догмы (независимо от правоты любой стороны);
что те несколькие -- менее его компетентны или априорно его не любят...
Вот я и предлагал подумать, что есть не только варианты 3 ил 4 (согласно перечислению в этом списке). И стоит задуматься, действительно ли мы тут устроили "заговор против GUI".