Ответ на »сообщение 57« (Сергей Перовский)
___________________________
>>> Как когда-то программисты делали блоксхемы задним числом для отчета...
... так сейчас они, например, пишут технические задания (вместо заказчика) ;-)

Это же не значит, что ТЗ не нужны. Просто нет у разработчиков ни культуры разработки, ни времени на детальную проработку задачи. Поэтому -- филькины грамоты для того, чтобы красиво выглядеть.

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

Оберонщики, которые были основными критиками необходимости
графического подхода, активно развивают ДРАКОН
http://forum.oberoncore.ru/viewforum.php?f=62&sid=7419307ffd4aafa474f54acaab042307

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

http://ru.wikipedia.org/wiki/Принцип_семантической_границы

http://ru.wikipedia.org/wiki/Семантическая_сеть

Ответ на »сообщение 53« (Сергей Перовский)
___________________________
Как говорил Штирлиц "запоминается последняя фраза" :)
>>> По мере декомпозиции модель быстро становится необозримой.
Так я и говорил "во первых строках письма",
что основной недостаток программ для работы с объектными графами -
это отсутствие эффективного инструмента композиции.

Структурное программировавние имеет тот существенный недостаток,
что построено на минимальной топологии связей.
Число связей равно количеству объектов минус один.
Можно бы было меньше - сделали бы меньше.
Корень задан. Все связи завязаны на предков. Дерево хрупкое.
Как Вы писали - при объединении двух моделей неизбежен крах.
Дихотомия от общего к частному.
1234
12-34
1-2-3-4
Графическое описание бессмыслено по причине вырожденности топологии.
Я говорю об инструменте, который бы позволял, например, при рассмотрении
3 элемента выделять только его семантическое окружение.
12-3-4
Схема обозрима, наглядна, а по сему эффективна при разработке.

Ответ на »сообщение 56« (Cepгей Poщин)
___________________________
Помните блоксхемы? :)
Начальство не желает читать текст программы. Считается, что картинки проще для понимания.
Как когда-то программисты делали блоксхемы задним числом для отчета, так теперь рисуют UML схемы для представления концепции высокому начальству.
Хотя, в обоих случаях считается, что схемы предшествуют программированию.
Если есть математическая модель, то программисту схема не нужна. А если нет, то можно, конечно, сначала поиграться в квадратики, чтобы понять, чего, собственно мы хотим добиться.

...однако во многих конторах, наряду с пунктом "требуется постоянная регистрация", есть пункт "требуется/желательно знание UML". :o) Интересно, кто-нибудь реально использует его в повседневной работе, или это не более чем "штамп в паспорте"?

Ответ на »сообщение 54« (Николай)
___________________________
>>> был страшно разочарован (как программист) образовашейся кашей из квадратиков и стрелок
"Сколько я ни встречал собак с забавными кличками, все они никуда не годились" (с) Джек Лондон
Сколько я ни встречал систем Reverse чего-то там, их результаты все равно нужно было потом обрабатывать, чтобы можно было разобраться и прочитать. И это не обязательно UML. Возьмем банальные программы ДОСовских времен, которые, взяв программу, восстанавливали ее ассемблерный листинг. Пока этот листинг руками не причешешь, понять что-либо невозможно.

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

Ответ на »сообщение 53« (Сергей Перовский)
считается, что если использовать не текст, а квадратики и стрелочки, то и менеджер поймет

Когда я впервые поставил себе на компьютер Rational Rose и сделал Reverse engineering для проекта Delhi, то был страшно разочарован (как программист) образовашейся кашей из квадратиков и стрелок.
Мне кажется, что подобный инструмент, обладающий такой универсальностью, как язык программирования, просто бессмысленен. А вот в для конкретных предметных областей их стоило бы иметь. Т.е. цель поставлена нереальная.

Ответ на »сообщение 52« (Как слышно? Прием!)
___________________________
То есть это как бы не для программистов, а для менеджеров.
Есть такое дело, считается, что если использовать не текст, а квадратики и стрелочки, то и менеджер поймет :)
Между тем UML - Unified Modeling Language - ЯЗЫК. И, как и языки программирования, должен читаться как компьютером, так и человеком. Программисты знают, что второе важнее.
Но восприятие схемы эффективнее, чем восприятие текста, только при низкой сложности. По мере декомпозиции модель быстро становится необозримой.
Стрелочки, аналогично GOTO, при больщом количестве безнадежно запутывают восприятие.

нет библиотек, состоящих из стандартно сгруппированных графических элементов.
По сути, Вы предлагаете аналог структурного программирования :)
Очень правильная идея.

Ответ на »сообщение 49« (Сергей Перовский)
___________________________
>>> И дело тут не в инструменте разработчика, а в отсутствии теоретической модели предприятия.

Если нет модели, то и говорить не о чем.

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

Это приводит к неудобству манипуляции со схемой и при разработке и при анализе.
С ростом сложности получаем растущий монолит.
Аналогия с текстовой программой - программа из одного модуля.
Т.е. отсутствие модульности.

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

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