Здравствуйте, GlebZ, Вы писали:
GZ>А ты пропробуй реализовать порядка 30 прецедентов в котором штуки по 3-4 альтернативных сценария на диаграмме последовательностей. Уже на 2 прецеденте наступит просветление что ты тратишь на рисование недопустимо много времени. Рисовать их будешь месяц.
Не рисуй. Остановись на верхнем уровне. Покажи только неочевидные вещи.
Здравствуйте, Аноним, Вы писали:
А>Не рисуй. Остановись на верхнем уровне. Покажи только неочевидные вещи.
И мы снова очутились перед тезисом. На UML хорошо документировать, но не проектировать.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, UnIc0dE, Вы писали:
GZ>А ты пропробуй реализовать порядка 30 прецедентов в котором штуки по 3-4 альтернативных сценария на диаграмме последовательностей. Уже на 2 прецеденте наступит просветление что ты тратишь на рисование недопустимо много времени. Рисовать их будешь месяц.
Во-первых не ты а Вы, мы вроде как на будершафт не пили. А во-вторых, у Вас есть какой-то альтернативный вариант проектирования? Рисование в голове? Тогда я Вам завидую, у меня столько информации в голове не удерживается, знаете ли, семья, дети, да и на принтер это все потом не пошлешь.
А вообще очень странная позиция, что UML нужен для документирования, а не для проектирования. Этому у нас теперь в институтах учат?
Если добро всегда побеждает зло, значит кто победил — тот и добрый.
Здравствуйте, UnIc0dE, Вы писали:
UIE>Во-первых не ты а Вы, мы вроде как на будершафт не пили.
Есть такая примета, если человек на форумах переходит на Вы, значит сейчас конструктив закончится, пойдут личные наезды и лучше быстро смотаться. Посему, если будете повнимательней, то заметите, что общение, де факто, идет в основном на ты. Даже если знаешь, что человек старше по возрасту(а чаще и не знаешь).
UIE>А во-вторых, у Вас есть какой-то альтернативный вариант проектирования? Рисование в голове?
Есть две вещи — первое бумага. Второе — Word. Если нужно проиграть прецеденты, то лучше бумага. Если нужно еще после этого что-то оставить, то начинаешь писать в формате прецедентов. Человеческий язык более богат, и легче отобразить не только особенности того или иного решения, но и почему оно сделано.
UIE>Тогда я Вам завидую, у меня столько информации в голове не удерживается, знаете ли, семья, дети, да и на принтер это все потом не пошлешь.
Аналогично. Семья, дети. Поэтому время берегу.
UIE>А вообще очень странная позиция, что UML нужен для документирования, а не для проектирования. Этому у нас теперь в институтах учат?
Вообще-то, когда я учился UML еще не существовало. Так что ответить не могу.
Re[6]: пнуть ногой UML? а что взять?
От:
Аноним
Дата:
06.05.06 13:37
Оценка:
Здравствуйте, GlebZ, Вы писали:
GZ>И мы снова очутились перед тезисом. На UML хорошо документировать, но не проектировать.
Если у тебя есть средство, генерирующее большое количество кода (не просто пустые методы) по диаграмме классов, — это документирование или проектирование?
Сам по себе UML — это набор соглашений; проблемы его использования — это, в основном, проблемы инструментов и организации процесса проектирования и разработки.
UIE>>Во-первых не ты а Вы, мы вроде как на будершафт не пили. GZ>Есть такая примета, если человек на форумах переходит на Вы, значит сейчас конструктив закончится, пойдут личные наезды и лучше быстро смотаться. Посему, если будете повнимательней, то заметите, что общение, де факто, идет в основном на ты. Даже если знаешь, что человек старше по возрасту(а чаще и не знаешь).
Странно, по моим наблюдениям это происходит как раз при общении на "ты", но не важно.
UIE>>А во-вторых, у Вас есть какой-то альтернативный вариант проектирования? Рисование в голове? GZ>Есть две вещи — первое бумага. Второе — Word. Если нужно проиграть прецеденты, то лучше бумага. Если нужно еще после этого что-то оставить, то начинаешь писать в формате прецедентов. Человеческий язык более богат, и легче отобразить не только особенности того или иного решения, но и почему оно сделано.
Не знаю, зависит наверное от человека. Use Case, Activity, диаграмма классов и.т.п. — не представляю в ворде. Я даже читать это не буду, если увижу. Потому что язык инженерии — это схемы и чертежи. Наверное так меня учили. Возможно, если кому то удобнее исписать несколько страниц текста чтобы собрать в кучку свои мысли — пожалуйста, лишь бы результат был. Только это работает в проектах из одного человека, который потом же и поддержку будет осуществлять. Но если ты работаешь в команде, то должен быть единый технический язык общения между всеми ее членами, и этот язык пока — UML, другого я не знаю.
Попробуйте представить себе архитектора здания, который передает прорабу вместо чертежа здания документ ворд на двухстах страницах. Прораб же охренеет вначале. Потом ему придется либо сменить работу либо выучить новый для него технический язык общения с архитектором, но масса времени уйдет на согласование терминов, потому что они изначально разговаривают на разных языках. Кстати, не из-за этого ли развалилось строительство Вавилонской башни?
Перенесите эту ситуацию в разработку и станет понятно что UML нужен не для того чтобы убивать полезное время на рисование бесполезных рисунков, а для общения всех членов команды на одном единственном языке. У меня в команде очень интернациональный состав, и UML — это наше спасение.
Если добро всегда побеждает зло, значит кто победил — тот и добрый.
Прошу прощения за тафтологию: UML — это просто язык. Не больше, но и не меньше. Использование UML при проектировании кроме очевидного плюса как универсального языка моделирования на котором многие умеют общаться имеет и еще один, весьма немаловажный. Если есть достаточный опыт работы с UML, то всегда можно с уверенностью утверждать следущее: если ты прекрасно знаешь, как решается задача, то не составит труда задокументировать решение в виде UML-диаграмм и, наоборот, если решение, которое созрело у тебя в голове ты неспособен описать средствами UML — то и закодировать ты его не сможешь. Т.е. ограниченность UML относительно естественного языка(и тем более относительно "языка мыслей") есть его большой плюс. Жесткая форма UML позволяет нам ясно выразить содержание. Отбраковка некачественных построений происходит в момент формулирования решения на языке UML. Здесь можно позволить не очень корректную, но напрашивающуюся аналогию с проверкой корректности кода на стадии компиляции.
Если кто-то сталкивался с описанием бизнес процессов в стандарте IDEF0, который еще более ограничен в средствах, нежели UML-диаграммы, поймет следующий пример. Зачастую, специалисту предметной области кажется, что он отлично понимает какие бизнес процессы существуют на его предприятии, как они между собой взаимодействуют и т.д. Свою уверенность в этом знании он с удовольствием демонстрирует в пространных монологах на естественном языке. Но, как только он пытается описать это знание в терминах IDEF0 выясняется, что знание это крайне фрагментарное, во многом неточное, построенное на сравнениях и нечетких ассоциациях. Естественный язык — есть отражение нашего мышления — ассоциативен по своей сути. Формальное описание не терпит ассоциативности или требует, чтобы эта ассоциативность была явно формализована.
Вспоминая теорему Геделя о неполноте, можно указать на один основной недостаток UML, который является прямым следствием его плюсов — существуют программные решения, которые в терминах UML выразить невозможно. Замечу, что это не должно становиться для незрелого программиста причиной отказываться от изучения UML — т.к. без достаточного опыта, к подобным решениям лучше не прибегать, а необходимость выразить решение в терминах UML присечет подобные попытки на корню.
P.S. Сам использую UML с двумя целями: как язык на котором можно общаться в команде при обсуждении решений на высоком абстрактном уровне и для документирования ключевых моментов в системе.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, _Obelisk_, Вы писали:
_O_>>UML полезен лишь в больших проектах, где сотни (и больше!) разработчиков, а размер моделей достигает гигабайтов. _O_>>На небольших проектах UML может лишь одну головную боль вызвать.
А>Головную боль вызывает увольнение ключевых сотрудников, когда оказывается, что никто не знает ни что сделано, ни как сделано, ни зачем оно сделано. Разобраться можно, но это ресурсы. И необязательно разработчиков должно быть много, может быть много проектов (подсистем). А может быть и проект маленький и разработчиков два штука, но тянется проект годами.
А>Четкие правила документирования позволяют быстро реализовать доработки, даже если разработчик вообще не работал с этой предметной областью.
Дело в том что разобраться с кодом быстрее чем с UML.
UML — это иллюстративная документация,
1. которая может быть нарисована адекватно программе, т.е. верно
но настолько криво- что никто не поймет никогда, т.е. гарантии понимания нет.
2. Это не прямое отображение кода — когда в хорошем случае,
когда полезно.
В этом случае это высокоуровневая концепция — которую рисует архитектор.
и вам не надо именно UML, а надо серьезного архитектора,
который знает как им пользоваться чтобы было не прямое отображение кода, а польза.
___________________________
Архитектура в свою очередь,
нужна для того чтобы декомпозировать сложную разбросанную документацию,
в хорошо разграниченные понятные куски,
что дает понимание и разделение задчачи, т.е. всю хорошую организацию.
А напрямую UML — это обман для навязчивых менеджеров:
(типа получи свою доку, наивно надейся что поможет)
или только способ отрисовывать простые паттерны.
Как комбинировать паттерный UML нет,
тут используются "символические картинки"
платите хорошему архитектору больше, будете здоровы.
Винтовку добудешь в бою!
Re[4]: пнуть ногой UML? а что взять?
От:
Аноним
Дата:
10.05.06 14:24
Оценка:
Здравствуйте, vgrigor, Вы писали:
V>Дело в том что разобраться с кодом быстрее чем с UML.
Неверно, если есть хотя бы один случай, когда это не так. Таких случаев множество.
V>UML — это иллюстративная документация,
V>1. V>2.
На эти тезисы я отвечал в соседней ветке: http://gzip.rsdn.ru/Forum/Message.aspx?mid=1886599&only=1
V>А напрямую UML — это обман для навязчивых менеджеров: V>(типа получи свою доку, наивно надейся что поможет)
Безосновательно.
V>Как комбинировать паттерный UML нет, V>тут используются "символические картинки"
Вот это совсем не понял.
V>платите хорошему архитектору больше, будете здоровы.
Платить хорошему больше — верно для любого сотрудника.
Еще раз. Молотком хорошо забивать гвозди и отбивать пальцы. Отбитые пальцы — не результат устройства молотка.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, vgrigor, Вы писали:
V>>Дело в том что разобраться с кодом быстрее чем с UML. А>Неверно, если есть хотя бы один случай, когда это не так. Таких случаев множество.
Ну раз вы о точной логике — то да,
если таких случаев 2 из 10 то вы правы.
но практиески — вы будете надеяться на 20% ?
На этот вопрос можно ответить "100% нет".
т.е. если не поставлен вопрос как "применять UML чтобы было хорошо",
то на 100% — на только UML надеяться не стоит.
>проблемы его использования — это, в основном, проблемы инструментов и организации процесса проектирования и разработки.
вы неправильно ответили:
Это не проблемы инструментов — т.к. все они рализуют UML,
и процесс использования UML задокументирован вполне хорошо,
в "лучших практиках архитектур на UML",
но вот приходит человек, и наинает говорить — вот у вас куча диаграмм,
и есть код ему соответствующий — я гораздо лучше понимаю код,
а по UML тяжело т.к. " UML — язык кривой" и это типично.
по UML часто — нельзя понять программу,
нужно что-то ЗА ПРЕДЕЛАМИ UML.
V>>А напрямую UML — это обман для навязчивых менеджеров: V>>(типа получи свою доку, наивно надейся что поможет) А>Безосновательно.
Это практика — приходят люди и говорят — нам надо доку на UML,
и люди садятся и срисовываю с гтового проекта по стандарту диаграммы,
потом- их читаешь — непонятно, а код весьма понятен.
И это неоднократно.
Если бы он был так хорош то во многих местах им бы не пренебрегали, с большим успехом.
Это практика — УСПЕШНЫХ ПРОЕКТОВ, а не домыслы.
V>>Как комбинировать паттерный UML нет, V>>тут используются "символические картинки" А>Вот это совсем не понял.
А>Еще раз. Молотком хорошо забивать гвозди и отбивать пальцы. Отбитые пальцы — не результат устройства молотка.
Как раз результат — хорошим инструментом- вы создадите успешный проект,
а плохим — развалите.
Напрмер возьмите создание новых языков- С -С++ С#,
каждый следующий беспечивает успех более сложных проектов.
а UML — еще в зародыше проектирования, первый и простейший шаг,
таким инструментом только руки ломать в серьезных случаях,
когда надо забить 1000 гвоздей.
а когда 10 — то он пойдет, но это не архитеткура.
Винтовку добудешь в бою!
Re[6]: пнуть ногой UML? а что взять?
От:
Аноним
Дата:
11.05.06 05:39
Оценка:
Здравствуйте, vgrigor, Вы писали:
А>>Неверно, если есть хотя бы один случай, когда это не так. Таких случаев множество. V>Ну раз вы о точной логике — то да, V>если таких случаев 2 из 10 то вы правы.
Посчитать случаи нереально.
V>но практиески — вы будете надеяться на 20% ?
Почему надеятся? Есть способ организовать разработку таким образом, что использование UML будет краеуголным камнем.
V>На этот вопрос можно ответить "100% нет".
Я бы сказал так — есть случаи как удачного так и неудачного использования UML.
Ключевое слово (опять же) — "использование".
V>то на 100% — на только UML надеяться не стоит.
Это верно для чего угодно.
V>Это не проблемы инструментов — т.к. все они рализуют UML, V>и процесс использования UML задокументирован вполне хорошо, V>в "лучших практиках архитектур на UML",
Каждый инструмент предполагает свою концепцию использования UML. Rational Rose 200x предполагал, что модель генерит код и код актуализирует модель. Связи подтягиваются через раз. Генерируемый код так мал, что легче руками написать, чем ждать пока Роза кончит тупить. Результат — модель и код почти соответствуют друг другу. Теперь перестаем генерить код. Один раз подняли код в модель. Поправили, отдали соисполнителям вместе с бинарниками. Отлично.
В этом смысле идельный UML-инструмент — ручка и бумага. Нет возражений против рисования при обсуждении архитектуры?
V>и есть код ему соответствующий — я гораздо лучше понимаю код,
Я думаю обсуждать индивидуальные особенности бессмысленно.
V>а по UML тяжело т.к. " UML — язык кривой" и это типично.
По сравнению с C# или HTML? Не с чем его сравнить.
V>нужно что-то ЗА ПРЕДЕЛАМИ UML.
А нету.
V>потом- их читаешь — непонятно, а код весьма понятен.
UML не виноват.
V>Это практика — УСПЕШНЫХ ПРОЕКТОВ, а не домыслы.
К сожалению, успешность проекта не зависит от (не)использования UML. Она вообще хрен знает от чего зависит.
V>Как раз результат — хорошим инструментом- вы создадите успешный проект, V>а плохим — развалите.
Нет. "Сделать из говна конфекту" — типичная ситуация, создаваемая полититческими играми.
А еще есть проблемы бюджета, кадров и т.п. Но не факт, что проект сдтохнет.
Мне UML не брат и не сестра. Но удивительно слушать, что UML не нужен. Я рисую диаграммы, генерю из них код, контролирую работу подчиненных, передаю готовые решения в другие подразделения, общаюсь с бизнес-аналитиками, с руководством, с заказчиком — и все это UML.
К стати, считаю use-case модель просто незаменимой вещью. Отлично прочищает мозги.
PS Надеюсь, мы не обсуждаем UML для написание драйверов.
Здравствуйте, Леонид, Вы писали:
Л>Ищу средство/способ/методологию для проэктирования/визуального описания кода. Л>Собственно необходимо два отображения: Л> 1) структура Л> 2) схема действия/работы как отдельных объектов, так и всей системы в целом.
Л>Читал когда то довольно поверхностно книжечки по UML — сейчас думал вернуться перечитать, но, полистав форум заметил, что довольно многие заявляют о полной бесполезности использования UML.
Просто не надо из него делать фетиш.
Л>Что посоветуете в таком ракурсе? куда копать? Л>Что именно Вы используете при проэктировании софта — еще до написания кода, после написания...
Первые проектные решения чаще всего появляются на бумаге посредством ручки.
Л>Мне как то проще рисовать на бумаге графы с изображением классов, пометками к ним и связями с другими классами. — но это подходит только для решения задачи [1], а вот для [2] выходит всё довольно запутанно, особенно когда классы связаны между собой через события, callback-и плюс еще и запускаются в отдельных потоках
Sequence-диаграммы, statechart-диаграммы. Прекрасно позволяют документировать и callbacks, и несколько потоков. Не нужно только забывать, что callback-а "в другой поток" не бывает. Кстати, для документирвания алгоритмики очень неплох банальный язык блок-схем.
Л> Сейчас схему работы держу в голове, но чувствую, что если сделать месячный перерыв, то потом долго буду разбираться что к чему Л> Я вот интуитивно чувствую, что толковые архитекторы(да и простые программеры, просто с большим опытом, чем мой), постоянно юзают одну и ту же наработанную схему, может поделитесь, а?
Дык, ты её как раз и выразил: бумага/ручка + в часть в голове. Для того, чтобы не забыть, что к чему — [не-]большие пометки в виде UML-диаграмм.
PS.: В остальном присоединяюсь к MaximVK.
... << RSDN@Home 1.2.0 alpha rev. 643>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Леонид, Вы писали:
Л>Привет всем...
Л>Ищу средство/способ/методологию для проэктирования/визуального описания кода. Л>Собственно необходимо два отображения: Л> 1) структура Л> 2) схема действия/работы как отдельных объектов, так и всей системы в целом.
Ключевое слово для поиска в любимом поисковике: MindMap.
Здравствуйте, Геннадий Васильев, Вы писали: Л>>Мне как то проще рисовать на бумаге графы с изображением классов, пометками к ним и связями с другими классами. — но это подходит только для решения задачи [1], а вот для [2] выходит всё довольно запутанно, особенно когда классы связаны между собой через события, callback-и плюс еще и запускаются в отдельных потоках
ГВ>Sequence-диаграммы, statechart-диаграммы. Прекрасно позволяют документировать и callbacks, и несколько потоков. Не нужно только забывать, что callback-а "в другой поток" не бывает.
— помогают ли эти диаграмы вам самому позже при "разборе полётов" или вы просто документируете определенные решения для других разработчиков? Интересует именно 1-й вариант — т.к. у "нас" всем абсолютно наплевать на документацию кода , а мне попеременно приходится учавствовать в нескольких разных проэктах и при обратном переходе тратится много времени на восстановление собственных идей в памяти . Да и свои новые идеи порой тяжело отобразить на бумаге, а вот в голове держать всё как то тяжеловато...
— в догонку... если ответ "Да", то посоветуйте плз еще где можно почерпнуть инф-ю о использовании данных диаграмм, потому как живого толкового наставника мне до сих пор встретить так и не удалось...
Л>> Сейчас схему работы держу в голове, но чувствую, что если сделать месячный перерыв, то потом долго буду разбираться что к чему Л>> Я вот интуитивно чувствую, что толковые архитекторы(да и простые программеры, просто с большим опытом, чем мой), постоянно юзают одну и ту же наработанную схему, может поделитесь, а?
ГВ>Дык, ты её как раз и выразил: бумага/ручка + в часть в голове. Для того, чтобы не забыть, что к чему — [не-]большие пометки в виде UML-диаграмм.
ГВ>PS.: В остальном присоединяюсь к MaximVK.
Ок, уговорили, буду снова копать в UML, т.к. алтернативы, как я посмотрю, не намечается...
Здравствуйте, UnIc0dE, Вы писали:
UIE>Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>>На бумажке проще рисовать. Трудозатрат меньше, чем проводить стрелочки мышкой в любой графической софтине.
UIE>Ну это Вы лукавите. Попробуйте нарисуйте с первого раза на бумажке диаграмму классов или activity. Тут одной бумажкой не обойдешься, придется альбом заводить, пока все квадратики удобно разместишь. А в софтине все это намного быстрее сделается и при этом сколько лесов сохраняется!
Здравствуйте, iZEN, Вы писали:
ZEN>Здравствуйте, Леонид, Вы писали:
Л>>Привет всем...
Л>>Ищу средство/способ/методологию для проэктирования/визуального описания кода. Л>>Собственно необходимо два отображения: Л>> 1) структура Л>> 2) схема действия/работы как отдельных объектов, так и всей системы в целом.
ZEN>Ключевое слово для поиска в любимом поисковике: MindMap.
Вы юзаете? на сколько успешно, как давно, что именно удобно? в основном для каких целей?
