Привет, форумчанин! Собственно вопрос, а встречалось ли тебе использование UML в реальных проектах, приносящее проекту пользу? В каком виде и кем применялся UML, кем продвигался, каков был результат?
Было бы интересно услышать о твоем практическом опыте.
UML дозволяє суттєво зменшити витрати на перші ітераціі формування архітектури програми, оскільки вони здійснюється без зміни коду. Також він значно спрощує комунікацію між учасниками проекта, зменшує час на входження нових програмістів в проект і покращує якість архітектури.
Ефект UML — це візуалізація релевантних особливостей програми. Як і будь-який інструмент, його треба використовувати з розумом. Занадто багато деталей на діаграмах може мати негативний ефект.
Реально використовував діаграми класів, прецедентів і послідовностей.
зменшує час на входження новых програмістів в проектУгу, учитывая что при найме надо к “спринг-хибернейт” найти еще и человека который знает УМЛ. А дальше начинается комедия со словом “знает”, под ним можно понимать знание всей спецификации или же просто “куда стрелочки направленны”.
Згадані найбільш часто вживані діаграми інтуітивно зрозумілі і без знання UML. А навчитися створювати іх в якомусь засобі моделювання (наприклад Visio) можна за 1 годину. Знати всю специфікацію UML нема сенсу, бо реально з неі викиростовують мало, а засоби моделювання значно спрощують створення діаграм і містять «знання» UML.
вообще судя по реакции основная масса населения DOU пилит сайтики про котиков- настоящих буйных мало
Котикофф не трожжЪ!!! ((
Просто хз як стати буйним та не протянути ноги.
За котиків хоч платять.
за грусняшки с айбиемом индусами и uml тоже
Китайский язык тоже родился языком моделирования. Теперь миллиард человек страдают и ничего не могут с ним сделать :)
Угу. А потом был импортирован в Японию как письменность. И японцы теперь мучаются-мучаются аж совсем. Но это еще мелочи.
Ведь есть ещё математика. Есть еще сопромат. Есть еще чертежи. Строительные Нормы и Правила. У-у-у... А есть ещё бухгалтерия. А есть еще юрисприденция. А есть еще не в приличном обществе
У нас взаимодействие мобильных приложений и сервера описывается в документации и если от клиента нужна какая-то строгая последовательность шагов — рисуется диаграмма в plantuml.
Программистам эти диаграммы нравятся, вижу что их даже распечатывают :) Но польза не столько от UML, сколько от документации вообще.
Угу, оба раза в мое практике UML был выбран мной просто как удобный инструмент, никакой «религии».
Использовал в двух проектах. Первый раз — для себя, когда проект эволюционировал и укрупнялся и я понял, что могу что-то уже в голове и потерять. Так и получилось — после того как проанализировал UML, нашел места где можно было оптимизировать. Это был enterpise проект. Второй раз — mobile проект. Изначально было требование заказчика — отразить структуру SDK, как мы планируем его делать согласно требований. (SDK нужно было под Android и iOS). Весьма потом полезно было iOS команде (была послабее Android) не на пальцах объяснять архитектуру, а по документу.
Спасибо за ответ! Какие виды диаграмм использовали?
Диаграммы классов,компонентов, пакетов, структурную.
Точно скажу, що не зустрічалось.
Кілька разів бувало, що учасники моєї команди малювали простенькі блок-схеми на «UML».
Але це робилось без особливої потреби. Просто щоб зайнятись хоча б чимось і зробити видимість роботи.
Та й давно це було. Останній раз
Совпадает с моим опытом. На достаточно большом проекте, где знания передавались на уровне народного эпоса — из уст в уста, использование deployment diagramm добавило в проект ясности.
Странный вопрос
используется обычно в документации для обьяснения технических дизайнов,
это не серебрянная пуля но просто еще один инструмент
Обычно не выживает за пределами тру Ынтерпрайзов, однако в таковых может сильно облегчать жизнь
Что такое тру энтерпрайз?
когда предложение купить oracle exadata уже вызывает не смех а оживление например
Или когда предложение Оракла «купить вашу компанию» воспринимается чисто технически более чем адекватно. ))
видел когда компания где я работал покупала кое какой региональный бизнес у майкрасофта например
))
«2011: Менеджмент выкупает 100% акций (Miratech ) у EDB ErgoGroup».
не знал что миратех взад купили )))
Evry конечно здоровые но не MSFT :)
Встречалось в нескольких видах:
1) Как инструмент коммуникации между программистами, форма документации. Самый очевидный вариант использования.
2) Как инструмент моделирования, т.е. есть какая-то проблемная область ( domain ) и с помощью диаграмм можно сконцентрировать знания о ней. Например при разговорах с бизнес-аналитиком, можно построить модель предметной области и от нее уже будет плясать схема базы, разбиение приложения на модули, и т.п. В общем если в проекте Rich Domain Model, то смоделировать ее сначала в UML, а потом сгенерировать/закодить это хорошая идея.
3) Как DSL для генерации кода в MDE ( Model-Driven-Engineering). Это довольно часто встречается при embedded разработке. Правда там UML частитчно вытеснен его расширением — SysML. Впрочем есть тулы и для джавы на UML ( к примеру — trimm.tigerteam.dk ).
В общем, штука весьма полезная. Главное не забывать что это просто графическая нотация, а не решение всех проблем.
Интересно, про SysML и применение UML в Embedded слышу впервые. Можете пожалуйста рассказать поподробнее как MDE и SysML применяются в Embedded? Для меня сейчас это актуально.
Как правило, любой разработчик, перед тем как начать писать код, берет лист бумаги и рисует на нем какие-то стрелочки, прямоугольнички и прочие каляки-маляки, чтобы визуализировать свою будущую программу. Просто потому, что графическая информация воспринимается легче чем текст. А UML это всего лишь попытка формализовать этот процесс, сведя его к единой нотации. Польза от этого для проекта может проявляться во многих аспектах: собрались, к примеру, с командой у доски и обсудили структуру классов или высокоуровневый алгоритм; спека от аналитиков с картинками читается, опять же лучше, чем без оных; эстимейты на объемные таски лучше подкреплять дизайн документом, на котором по количеству стрелочек и прямоугольников будет виден масштаб работ; с заказчиком тоже удобно согласовывать какие use case будут у системы и какие пользователи будут с ней работать.
Практический результат применения UML состоит обычно в облегчении коммуникации со всеми участниками проекта, как письменной, так и устной, когда вместе рисуете диаграммы на доске или на листе бумаги, вместо того, чтобы на пальцах показывать. Еще заметил такой эффект, что когда рисуешь диаграмму перед написанием кода, то появляется много дополнительных деталей и вопросов по реализации, которых не замечал, когда просто обдумывал решение.
Главное относиться к рисованию диаграмм без фанатизма, т.к. они имеют очень ограниченный срок жизни, особенно те, которые описывают низкоуровневые детали, и через месяц в коде все может быть совсем не так как на диаграммах. Собственно, это относится к любой документации, которую нужно или поддерживать в актуальном состоянии, или не вести вовсе.
Спасибо за развернутый ответ! Я так понял, вы используете UML в основном для себя. Приходилось ли его использовать на уровне проекта (при общении с другими разработчиками, с заказчиком)?
На текущем проекте спецификации от аналитиков как правило содержат UML-диаграммы деятельности. Когда с командой обсуждаем новые фичи или изменения, в которых участвует больше нескольких классов, то рисуем диаграмму классов, чтобы всем сразу было понятно что происходит.
На прошлом моем проекте активно развивалась архитектура программы, и у всех было множество идей как заимплементить то или иное решение, поэтому было очень много обсуждений и споров у доски. Поначалу все рисовали в каких-то своих нотациях, и в пылу спора зачастую сложно было понять, что имеет в виду коллега, проталкивающий свое решение, под той или иной закорлючкой. Думаю, все могут представить себе спор, один собеседник неправильно понял другого, и сходу начинает обвинять его в том, что он тупой и предлагает какой-то бред :) Поэтому постепенно мы пришли к осознанию необходимости общей нотации, и самым перспективным вариантом был UML. Для начала всем было рекомендовано прочитать книжку, а потом, в целях практического закрепления, начали проводить в команде семинары по паттернам. По очереди коллеги брали один паттерн из списка, и рассказывали у доски остальным, попутно рисуя все необходимые UML-диаграммы и показывая соответствующий им код. Результатом всех этих мер стало существенное улучшение коммуникации в команде, ну и повышение архитектурных навыков, само собой.
Спасибо за ответ, очень интересный практический опыт.
Программисты в Украине всё. Можно закрывать лавочку.
ну что вы — а кто котиков то пилить будет
пусть живут
Котикофф не трожжЪ!!! ((
Ценность UML в аккурат такая же, как и совковых блок-схем. Это красиво для презентаций. Создаёт имитацию чего-то, под что не стыдно дать деньги. Но реальность отличается как Земля от древней карты мира: в UML должно стоять на трёх слонах, в реале — круглое.
Если Вы не пользуетесь UML, или не видели как он приносит пользу, это не значит, что UML бесполезен.
Для синхронизации понимания и документирования договоренностей очень полезная штука (из моего опыта).
По поводу слонов: на диаграмме классов (к примеру) можно изобразить модель предметной области, концепт структуры данных проекта и фактическую реализацию. И это 3 (!) разных диаграммы. Само собой что сущности предметной области могут отличаться от реализованных в софте классов, т.о. и диаграммы будут разные. Последнюю, кстати, должен рисовать разработчик, а 1 и 2 может БА или архитектор.
Если разработка спецификации и разработка ПО разнесены по времени и делается разными людьми — UML один из вменяемых способов донести идею, я бы дополнил еще BPMN диаграммами — это простые и компактные способы передачи инфы о том, как оно должно работать.
Обычный язык представляет куда более эффективные средства передачи информации чем UML. Общаться по делу лучше всего на нём. UML даёт красоту. Расплата за это — требование к месту. Как только места начинает не хватать, все его теоретические преимущества идут коту под хвост, остаётся лишь красивая картинка. Которая не соответствует реальному процессу.
Я приведу лишь один пример, во что уже однажды вылилось увлечение языками моделирования. Китайский язык!
Уже представил как вы пишете на доске
Алексей, глупости пишете
UML позволяет просто визуализировать сложные вещи. Рискну предположить, что Вы UML никогда не использовали, но мнение имеете :)
Рискну предположить, что вам не приходилось объяснять действительно сложные вещи. А если приходилось — то не на UML, а лишь изредка и кое-где его используя.
у меня сейчас в базе 5 тыщ таблиц например, и еб его знает сколько кода на pl/sql (включая автоматически генерированный) + очереди и оч не очевидные процессы того что и как происходит в живой системе
когда возникает желание добавить куда нибуть поле — без правильных диаграмм становится как то неуютно
бггг на какую? В финансах по моему только карта глубин дичи ментся от компании к компании но не сама дичь
Use cases, deployment, classes отлично вписываются в любое объяснение где используется 5 и больше сущностей. Аудитория вводится в курс дела за 5 минут, так как в UML ничего сложного нет —
Использование UML очень оправдано на сложных проектах, а на коленках пишется что-то небольшое и очень глючное )
Подпишусь.
На днях чуть дипломную не завалил; после сего хочу просто по принципу подтянуть знания UML.
Тем более, я не знаю как еще можно научиться «мыслить архитектурно», не умея изобразить архитектуру на бумаге.
На днях чуть дипломную не завалил; после сего хочу просто по принципу подтянуть знания UML.
Тем более, я не знаю как еще можно научиться «мыслить архитектурно», не умея изобразить архитектуру на бумаге.Я так понимаю диплом бакалавра :)
Специалиста. Да, я не учил ЮМЛ, и мне сказали, что мои диаграммы говно и с ошибками — что здесь забавного-то :)?
Может и не нужен, но и не мешает же. Почему бы не использовать готовые варианты «микроязыков»? Да и микроязыки у каждого есть — я думаю, что все когда-то рисуют, пытаясь изобразить на бумаге проект, не важно как часто. И если я вижу хорошие варианты изображения каких-то вещей и процессов — мне очень помогает их использование. Потому я считаю, что намерение освоить ЮМЛ мне никак не помешает.
UML это что-то из
В PHP например никакой UML не нужен — мы просто бьем пальцами (иногда другими частями тела) по клавиатуре, пока заказчик не станет доволен.
В PHP например никакой UML не нужен — мы просто бьем пальцамиШкода, що Артур Еддінгтон так і не дожив до початку практичного доведення своєї «Теореми про нескінченних мавп»
я чаще думал о пхпшниках как о китайской комнате подключенной в сорс контрол
в худшем случае — в продакшен по ftp
Когда я работал на PHP, то у нас такой гавнокодинг никто не практиковал, всегда сперва был анализ/проектирования, хотя не использовали UML для фиксации.
Расскажи это друпальщикам, которые адепты методологии чик-чик и в продакшен
Видимо да, хотя по крайней мере они себя так называют
Andriy Kurhanevych
Bogdan Shyiak
Andriy Kurhanevych
Нестор Иванович
Alex Fogol
Kotiki і чай
Нестор Иванович
Олексій Пєніє
Макс Матюхин
Sergey Malenko
Sergey Malenko
Andriy Loboda
anonymous
anonymous
Anton Danylov
Anton Danylov
Alex Fogol
Kirill Nehaev
Олексій Пєніє
Dmitriy Chaban
Алексей Лукьяненко
Egon Schiele
Egon Schiele
Дмитрий Вежнин
Mikl Kovach
NoName
61 коментар
Додати коментар Підписатись на коментаріВідписатись від коментарів