Здравствуйте, Леонид, Вы писали:

ГВ>>Sequence-диаграммы, statechart-диаграммы. Прекрасно позволяют документировать и callbacks, и несколько потоков. Не нужно только забывать, что callback-а "в другой поток" не бывает.
Л> — помогают ли эти диаграмы вам самому позже при "разборе полётов" или вы просто документируете определенные решения для других разработчиков?

Скорее, в основном, для себя. Это помогает не столько при "разборе" полётов, сколько "утрясти", дофоромулировать абстракции, а потом уже переходить к кодированию. Поэтому, кстати, имеет смысл наброски делать небольшими: проще поддерживать их в актуальном виде.

"Для других", ИМХО, имеет смысл держать документацию по основным сущностям и связям и только её. Иначе придётся очень много времени тратить на актуализацию. А читать всё равно никто не будет. Хотя здесь бывают забавные ситуации: например, у меня пару раз было так, что в довольно крупных проектах (~десятки мегабайт исходного кода) жили своей жизнью два комплекта схожих функций общего назначения. Форматирования разные, функции работы с датой/временем и т.п.

Л>Интересует именно 1-й вариант — т.к. у "нас" всем абсолютно наплевать на документацию кода , ...

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

Л>...а мне попеременно приходится учавствовать в нескольких разных проэктах и при обратном переходе тратится много времени на восстановление собственных идей в памяти .

В этом нет ничего удивительного, при перемещенеии с проекта на проект всегда некоторое время пребываешь в замешательстве. Даже внутри одного большого проекта. Welcome to the real world, тыксыть. Но иногда перетряхивать мысли даже полезно.

Л>Да и свои новые идеи порой тяжело отобразить на бумаге, а вот в голове держать всё как то тяжеловато...

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

Л> — в догонку... если ответ "Да", то посоветуйте плз еще где можно почерпнуть инф-ю о использовании данных диаграмм, потому как живого толкового наставника мне до сих пор встретить так и не удалось...

Ну как тебе сказать... www.rsdn.ru, не можешь — помогут, не хочешь... а что тут тогда делать? Излагай идеи, обсудим.

ГВ>>PS.: В остальном присоединяюсь к MaximVK.
Л> Ок, уговорили, буду снова копать в UML, т.к. алтернативы, как я посмотрю, не намечается...

А всё равно будут те же квадратики и стрелочки, только с немного другой семантикой.

Здравствуйте, Леонид, Вы писали:

UIE>>Ну это Вы лукавите. Попробуйте нарисуйте с первого раза на бумажке диаграмму классов или activity. Тут одной бумажкой не обойдешься, придется альбом заводить, пока все квадратики удобно разместишь. А в софтине все это намного быстрее сделается и при этом сколько лесов сохраняется!

Л>А какой софт юзаете?
Есть бесплатный инструмент для рисования UML-диаграмм StarUML.

Здравствуйте, Леонид, Вы писали:

iZEN>>Ключевое слово для поиска в любимом поисковике: MindMap.
Л>Вы юзаете? на сколько успешно, как давно, что именно удобно? в основном для каких целей?
Мне это без надобности (ценные мысли, как правило, забиваю в TXT), но для вас, если вы отвергаете UML и, тем не менее, нуждаетесь в чём-то "визуальном" для выражения идей, может пригодится.
(MindMap: сначала узнайте, что это такое и как правильно использовать, а потом ищите нужный софт.)

UML — хорошая вещь, когда задаются базовые классовые конструкции,
т.е. практически паттерны.

Дальше — начинается более концептуальное проектирование,
которое в UML никак не укладывается, чтобы было продуктивно, для дальнейшего понимания,
(а только как много отчетсности)
и тут word к примеру лучше,
а лучше сочетание word и UML, "как сочтется более понятным"

Здравствуйте, MaximVK, Вы писали:

MVK>Здравствуйте, Леонид, Вы писали:

MVK> Прошу прощения за тафтологию: UML — это просто язык. Не больше, но и не меньше. Использование UML при проектировании кроме очевидного плюса как универсального языка моделирования на котором многие умеют общаться имеет и еще один, весьма немаловажный. Если есть достаточный опыт работы с UML, то всегда можно с уверенностью утверждать следущее: если ты прекрасно знаешь, как решается задача, то не составит труда задокументировать решение в виде UML-диаграмм и, наоборот, если решение, которое созрело у тебя в голове ты неспособен описать средствами UML — то и закодировать ты его не сможешь. Т.е. ограниченность UML относительно естественного языка(и тем более относительно "языка мыслей") есть его большой плюс. Жесткая форма UML позволяет нам ясно выразить содержание. Отбраковка некачественных построений происходит в момент формулирования решения на языке UML. Здесь можно позволить не очень корректную, но напрашивающуюся аналогию с проверкой корректности кода на стадии компиляции.

UML знать — надо и пользоваться там где адекватно.
Но зна проблему и выразив ее в UML вы во многих сложных случаях не полуите преимущества,
а получите набор квадратов,
а не вашу цель — понятность документации и проекта.


MVK> Если кто-то сталкивался с описанием бизнес процессов в стандарте IDEF0, который еще более ограничен в средствах, нежели UML-диаграммы, поймет следующий пример. Зачастую, специалисту предметной области кажется, что он отлично понимает какие бизнес процессы существуют на его предприятии, как они между собой взаимодействуют и т.д. Свою уверенность в этом знании он с удовольствием демонстрирует в пространных монологах на естественном языке. Но, как только он пытается описать это знание в терминах IDEF0 выясняется, что знание это крайне фрагментарное, во многом неточное, построенное на сравнениях и нечетких ассоциациях. Естественный язык — есть отражение нашего мышления — ассоциативен по своей сути. Формальное описание не терпит ассоциативности или требует, чтобы эта ассоциативность была явно формализована.

Це — хорошая часть UML,
однако проблема в том что выразив в точности, что может быть ЛЕГКО — ничего хорошего не получите.
тупой набор квадратов.

MVK> Вспоминая теорему Геделя о неполноте, можно указать на один основной недостаток UML, который является прямым следствием его плюсов — существуют программные решения, которые в терминах UML выразить невозможно. Замечу, что это не должно становиться для незрелого программиста причиной отказываться от изучения UML — т.к. без достаточного опыта, к подобным решениям лучше не прибегать, а необходимость выразить решение в терминах UML присечет подобные попытки на корню.

знать надо.
иногда все-таки весьма полезен.
Плохо что "иногда".
т.е. не надо применять "всегда"

MVK> P.S. Сам использую UML с двумя целями: как язык на котором можно общаться в команде при обсуждении решений на высоком абстрактном уровне и для документирования ключевых моментов в системе.

ZEN>Мне это без надобности (ценные мысли, как правило, забиваю в TXT), но для вас, если вы отвергаете UML и, тем не менее, нуждаетесь в чём-то "визуальном" для выражения идей, может пригодится.


правильнее будет сказать не "отвергают", а — "кто не пользуется UML -ВСЕГДА,
а только тогда когда это обосновано, или лучший вариант" (и так бывает ИНОГДА)


ZEN>(MindMap: сначала узнайте, что это такое и как правильно использовать, а потом ищите нужный софт.)

"Сам не пользую — но вам- настоятельно рекомендую" ("будет хорошее наказание")