mesierТерпеть не могу UML!...учебник толковый...Посоветуете?

странно, но не ново.

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

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

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

удачи вам
(круглый)

Relic Hunter...Я их даже не читал.

и не читайте. они не нужны, т.к. мертвы в вашем случае.

ещё раз:
UML это способ записи мысли. Если Вам приносят мысль - сто пудово это тухлый вариант :) !!! Это я Вам чисто из практики.

Другое дело - есло речь идёт о записи результата процесса ООА и ООП, в котором должны участвовать (отгадайте кто? - правильно! Вы так-же!!!) так же и Вы на своём уровне проработки задачи. Т.е. вам _не_должны_ давать то, в чём Вы не участвовали и не понимаете о чём это.

а писать ради писать - это гоните ваших менагеров, это фуфляндия всё ребята :)

Relic Hunter...думал буквы. Быстрее...

тут как бы высказывание идёт в разрез общеизвестных вещей. в частности всем известно, что образ быстрее воспринимается, нежели текст на энном кол-ве листов.

ну это уже к делу не относится - офф так сказать.

ик
(круглый)

mesier...нужно бы описать алгоритм весьма сложного и запутанного метода, реализующего бизнес-логику.. Как это сделать?

никак. потому как задача нафик никому не нужная.
ООА и ООП это есть единственная (на мой взгляд) _технология_ перехода от жизни к коду. и в этом её прелесть и сила. под другим соусом или ракурсом - это завдомо мёртво рождённый, со всеми вытекающими.

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

рекомендую взять в руки учебник по данной теме (одного из основателей UML) - Гради Буча "ООА и ООП...." там же всё разжовано, и на кошках показано.

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

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

удачи вам
(круглый)

mesier...А разве хотя бы для документирования проекта это не окажется нужным?..

правы, правы... но я попытался высказать следующую мысль:
документирование не есть минимально необходимое для успеха. для успеха важнее понимание сущностей всеми(!) участниками производства софта.

т.е. писать ради писанины - это пойдёт мимо всё (плюсы есть, но их "маловато будет").
а вот когда каждый участник производства оперирует такими сущностями - это уже другое дело! На самом деле, при реализации бизнес модели от этого и идут. Т.е. берут те сущности, которыми оперируют люди из бизнес среды(которую необходимо автоматизировать). Вы же понимаете, что их конечное число. И гораздо (на порядки!!!) меньше чем у программистов в коде! Не задавались вопросом почему? На мой взгляд - это(лишнии классы) и есть тот баласт который образовался без ОО подхода в производстве софта, при плохом(точнее отсутствии) должного управления (обычно это происходит на этапе становления фирмы - когда все делают всё). Что влечёт за собой бюрократию, тормоза в производстве, излишки кода и создания никому не нужных сущностей. Ну и в дальнейшем - отсос мощностей на переработку кода. Знакомо? Оно практически везде так. Везде пишут на си плас плас в ассемблерном стиле... Исключения если есть - то они настолько еденичны, что встретить практически не реально.

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

можно долго говорить про плюсы и минусы. Но основная мысль такая кмк:
В первую очередь применение ОО-методологии на всех этапах производства, всех участников. А уж потом идёт запись полёта мысли удобными средствами и языками, в том числе и UML.