Ответ на »сообщение 69« (Geo)
___________________________
>>> UML -- это попытка застолбить нишу, захватить приоритет, задать стандарт.

Согласен.
Именно из-за того что впопыхах создали стандарт,
наворотили мешающие частности он и застопорился.

Ответ на »сообщение 67« (Jack Of Shadows)
___________________________
>>> для быстрой наброски идей я использую  FreeMind

Это не графика.
Текст организованный в фолдеры.

Ответ на »сообщение 67« (Jack Of Shadows)
___________________________
UML -- это попытка застолбить нишу, захватить приоритет, задать стандарт. "Провал" UML -- это всего лишь провал UML, но отнюдь не провал использовния CASE-средств для разработки программного обеспечения. Для разработки больших систем использование чисто текстов на языке программирования неэффективно: слишком много кода, слишком много однотипного кода, слишком сложно удерживать целостность. И инструменты визуального проектирования (та же Delphi) это показали, хотя это пока лишь промежуточный этап перехода от кодирования к проектированию.

А в той же 1С как узкоспециальном инструменте кодирование на языке вообще сведено к минимуму. И ничего... эивет и процветает.

"произошло еще в эпоху полновластия ООП" - я что-то пропустил? Эпоха прошла? И что сменило ООП?

"То есть четко очерченные ниши" - ага, как и у "текстового программирования" то-же своя ниша! Которую глупо смешивать с "текстовым программированием"! К примеру гуи руками писать - верх извращенства!

Лично меня UML заинтересовала только в контексте MDA. Даже если учесть, что это совсем не новая парадигма, у меня всёравно стойкое ощущение, что она "ещё сырая"... Но другую эволюцию средств работы с данными, кроме MDA - я представить не могу!

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

А вот для быстрой наброски идей я использую  FreeMind: http://freemind.sourceforge.net/wiki/index.php/Main_Page

Ответ на »сообщение 63« (Сергей Перовский)
___________________________
>>> Какое максимальное количество блоков приходилось рисовать?
Десяток-два. Естественно, на одном листе. Дальше нужна декомпозиция, схемы верхнего уровня, но там уже все намного прозе (или сложнее), и там уже не требуются блок=схемы. Еще раз, блок-схемы рисую для разработки каких-нибудь навороченных ветвистых алгоритмов, типа, парсинг, анализ посимвольного ввода и т.п., где куча IF-ов, порядок которых может изменяться. Сначала рисуется блок-схема тупо в лоб, потом анализируется и перерисовывается, чтобы быть поэффективнее: а потом по этой блк-схеме пишется код.

>>> Да еще, а какой инструмент используется для оформления блок-схемм?
Бумага и ручка. Причем, нотация упрощенная: лишь бы мне было понятно.

Я же не призываю рисовать блок-схемы всего кода для SAP R/3 :D

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

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

Именно для её отображения и требуются графические методы.
Текстовой набор описаний связей не отражает структуры как целостности.
Между тем именно особенности структуры являются определяющими в системе.

Рассмотрим объектный граф системы, состоящий из N объектов.
Число связей между ними N(N-1)/2 (имеются в виду одиночные связи).
Теперь введем вес связи, который характеризует существенность её для модели.
Ограничимся только теми связями, вес которых больше некоторого порогового уровня.
То есть введём параметр точности модели.
Теперь будем увеличивать порог с тем, чтобы число связей было обозримым.
Откуда следует, что полученная структура будет иерархической?
А структурное программирование и ООП навязывают нам именно такой
"единственно правильный" выбор.

Системы, построенные на основе естественноструктурированной модели
при объединении не будут требовать переделки с нуля,
так как в них уже выбраны существенные связи.
Требуется лишь добавление связей между объединяемыми подсистемами.

Это было озвучено переходом от подхода алгоритмирования к моделированию.

Ответ на »сообщение 63« (Сергей Перовский)
___________________________
>>> какой инструмент используется для оформления блок-схемм?

Пока самый эффективный - карандаш с бумагой.
Позор программистам!
Именно поэтому UML и блок-схемы - имеют "посмертное" применение.

Ответ на »сообщение 61« (Geo)
___________________________
А я, например, блок=схемами пользуюсь достаточно часто. Если разрабатываю какой-нибудь сложный "ветвистый" алгоритм.
Какое максимальное количество блоков приходилось рисовать?
На мой взгляд, как только блок-схема перестает помещаться на листе, ее смысл проподает.
Да еще, а какой инструмент используется для оформления блок-схемм?

Ответ на »сообщение 61« (Geo)
___________________________
... так сейчас они, например, пишут технические задания (вместо заказчика) ;-) Тем не менее, ни где в вакансиях я не видел чтобы среди требований значилось умение писать ТЗ и рисовать блоксхемы :o)
Ну допустим Пушкин рисовал рядом со стихами еще и картинки, однако ж ни кто не думает, что это обязательное требование для хороших стихов. А вот с UML почемуто по другому.