Я преподаю разработку программного обеспечения на уровне бакалавриата, и у меня есть вопрос к практикующим UML.
Большинство учебников по программной инженерии серьезно относятся к диаграммам UML. Но с другой стороны, я слышал от многих выпускников, что UML, похоже, больше не используется в окопах.
Какие UML-диаграммы до сих пор широко используются в профессиональной практике и почему? Есть ли схемы, которые больше не используются и почему?
NB. Во избежание дискуссий и обсуждений, основанных на мнениях, просьба проиллюстрировать свой ответ фактическими и объективными элементами (если это возможно, поддающимися проверке) или нейтральными замечаниями о личном опыте.
Ответы:
Из множества диаграмм, предложенных UML, диаграммы классов и диаграммы последовательностей все еще широко используются, за которыми наверняка следуют диаграммы состояний:
Я думаю, что варианты использования в реальной жизни используются более случайным образом. В больших проектах с несколькими сотнями сценариев использования диаграммы трудны для рисования и дают небольшую выгоду по сравнению с табличной формой. BPMN для проектирования процессов, отображения пользовательских историй или табличной декомпозиции событий в стиле Кокберна используются гораздо чаще. Почему ? Потому что им легче делиться с бизнес-пользователями для эффективной разработки требований.
Я уверен, что это те места, где UML все еще широко и систематически используется. Я не представляю, что аэрокосмическое программное обеспечение или системы управления атомными электростанциями производятся без полного комплекта документации UML. Но я считаю, что это скорее исключение, чем правило.
Я чувствую подтверждение в этом заявлении, когда смотрю в книжные магазины. Пару лет назад вы могли найти множество книг по UML 2.0. В настоящее время, если вы ищете UML 2.5, выбор довольно ограничен. Хуже того : многие авторы даже не приложить усилия , чтобы пересмотреть свои прежние книги , чтобы держать их в курсе (пример: хороший Фаулера « UML дистиллированная » введение , которое до сих пор датируется 2003 с UML 2.0 и та же для Эмблер «s«Элементы стиля UML 2.0 "!).
Я не думаю, что эта тенденция к снижению изменится, если взглянуть на обобщение agile и его продвижение «Работа программного обеспечения над всеобъемлющей документацией».
В конце я бы очень вызывающе заявил, что методы моделирования, похоже, следуют дарвинистической схеме: выживет только наиболее подходящая техника построения диаграмм, которая дает явное преимущество перед неформальными подходами (например, иллюстрация с салфеткой) и подробным кодом (например, зачем рисовать диаграмму активности А1, если соответствующий код может уместиться на листе А4?) ;-)
источник
Все они используются на практике. Но не все их используют. Некоторые люди полностью отказываются от дизайна и сразу переходят к кодированию. Вы не можете полагаться на неподтвержденные данные, чтобы знать, что делает «каждый».
Такие инструменты, как UML, работают лучше всего, если вы используете, когда они добавляют ценность ; например
Создавать их просто ради их выполнения (или потому что процесс говорит, что вы должны) не продуктивно. Лучшая практика - быть избирательным в отношении того, что вы рисуете, и какие виды вы используете. Используйте UML, когда и где это помогает ... и это включает выбор типов используемых вами диаграмм UML.
Также ... UML был изначально разработан как инструмент дизайна. Это не так эффективно (в наши дни), как инструмент документирования. Типичные IDE помогают визуализировать многие аспекты, если структура кода на лету. Это часто лучше, чем полагаться на UML-диаграммы, которые могут устареть / неточны.
источник
UML все еще используется в траншеях. Но, как всегда, люди используют его подмножество. Какое подмножество является предметом проблем под рукой.
UML поставляется во многих версиях. Но, как всегда, люди используют его символы неформально и непостоянно.
UML - это то, как мы понимаем большую часть книг по шаблонам. Это также один из способов общения на доске. Это не ушло. Но это никогда не будет использоваться так формально, как код.
Вместо того, чтобы предлагать учащимся, которые могут исправить любую диаграмму UML, чтобы они соответствовали UML версии 2.5 или любой другой версии, подготовьте учеников, которые могут понять, что диаграмма пытается сообщить, даже если она не полностью соответствует конкретной версии UML, потому что это как UML используется в траншеях. Это странные местные диалекты, смешанные с другими системами, и иногда мы просто создаем свои собственные символы.
Научи их, что нормально спрашивать, что это значит. Не учите их исправлять других, которые нарушают некоторые воображаемые правила. Мы просто пытаемся общаться здесь.
Лучшее использование, которое я видел в uml - это позволить новому программисту показать нам свой план решения проблемы. Это быстро показало нам части системы, которыми они пренебрегали или не осознавали, что они существуют.
Я также работал в местах, где требуется UML, даже когда он не нужен. Мы всегда использовали один и тот же шаблон, так что это была просто формальность. Мы дошли до того, что просто сфотографировали новые имена в старые диаграммы. Не поощряйте этот вид использования.
Но я думаю, что мы все знаем, что есть разница между обычной стрелкой и открытой стрелой. Правильно?
источник
Я собираюсь быть конкретным исходя из моего опыта: - Диаграмма развертывания - Диаграмма последовательности - Диаграмма классов Эти три наиболее часто используются в любом проекте, они обеспечивают реальную ценность общения с командой на разных уровнях.
источник