Насколько важны UML-диаграммы для успешного проекта? [закрыто]

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

Мне было интересно, если это пустая трата моего времени? Должен ли я просто заниматься другими забавными вещами, такими как написание кода? А когда не стоит строить что-то, не пройдя весь концептуальный этап? Это все о сложности? И если да, то как это измерить?

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

Сегодня я почти полностью остановил UML. Иногда я использую диаграмму последовательности, которая мне кажется очень полезной для описания взаимодействия между системами, но не для других диаграмм.

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

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

Планирование имеет решающее значение, но, как предупреждает известный стратег Карл фон Клаузевиц

Ни один план кампании не выдерживает первого контакта с врагом

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

Более конкретно, вы можете использовать эти диаграммы, чтобы сообщить о своих намерениях среди своей команды и подумать о вашем плане атаки до и во время проекта. Но есть вероятность, что то, что вы придумали, нужно будет изменить при кодировании и узнать больше о проблеме. Почти всегда ваш первоначальный план / дизайн должен быть изменен, потому что вы не можете знать все заранее.

Я думаю, что UML-диаграммы могут быть полезны, только если они выражают что-то на более высоком уровне абстракции, чем ваш код .

Написание UML просто ради написания UML становится ненужной бюрократией и делает проект и код менее адаптируемыми к изменениям без какой-либо выгоды.

Например, диаграмма классов UML, показывающая все классы в пакете со всеми их атрибутами и методами - что-то, что может быть легко сгенерировано автоматически - не дает никакого значения вообще: она находится на том же уровне абстракции, что и ваш код , Кроме того, код, несомненно, будет лучшим источником этой информации, потому что он всегда будет актуальным, и, вероятно, он будет документирован и организован таким образом, чтобы было легче понять, какие методы / атрибуты / вещи важнее.

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

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

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

Во всяком случае, это только некоторые примеры; Есть много случаев, когда простая диаграмма может оказать большую помощь. Просто помните, что вы должны делать это только тогда, когда вы не можете выразить что-то в самом коде. Если вы обнаружите, что используете UML-диаграммы для объяснения самого исходного кода, вместо этого сделайте код soruce более самодокументированным.

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

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

Кроме того, вам не нужно рисовать идеальные, отточенные диаграммы. Примерно набросанная диаграмма последовательности на доске или диаграмма классов, в которой классы являются пост-онными примечаниями, прикрепленными к этой доске, могут быть достаточными, в зависимости от контекста.

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

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

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

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

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

Если кто-то планирует понять ваш проект, читая ваши UML-диаграммы, то это, вероятно, не пустая трата времени.

Я считаю полезным на начальном этапе проектирования получать идеи на бумаге или на доске. В основном я использовал диаграммы классов UML без строгого соблюдения стандартов. Полезно вернуться к исходному дизайну UML, когда вы на полпути, а также в конце проекта. Это помогло мне взглянуть на кодовую базу на более высоком уровне абстракции, которую вы когда-либо сможете, просто прочитав код, и даже помогло обнаружить потенциальные ошибки.

Там это точка хорошо сделано здесь по ragu.pattabi различения между двумя видами UML ...

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

Когда UML рассматривался как «обязательный навык» (10 или более лет назад), я, вероятно, был против этого из-за мнительных мнений его многочисленных поклонников в то время. Но теперь, когда оно перестало пользоваться популярностью, я обнаружил, что вижу его таким, какой он есть - полезный инструмент, который достоин, но не является серебряной пулей разработки программного обеспечения.

Я использую UML (или похожий на UML :)), когда говорю с друзьями о том, что мы собираемся сделать. Обсудить идеи. Не готовить проект UML, который будет автоматически генерировать код для меня. Я не могу представить, чтобы создавать свои классы в UML, а затем генерировать код, а не настраивать его позже. Такого никогда не бывает. Так что вам придется вносить изменения из кода в UML. И когда я использую UML, я рисую на доске или бумаге. Никогда в таком инструменте, как Enterprise Architect.

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

Проектная документация является фундаментальным результатом профессионального проекта. Сколько достаточно? Ну, это зависит, конечно, от многих факторов. Однако, на мой взгляд, сценарии использования, диаграммы классов, схемы процессов и т. Д. Вовсе не являются пустой тратой времени. Они имеют значение на разных этапах проекта. Единственная проблема с документацией - это обычно ресурсы.

Некоторые программисты считают документацию пустой тратой времени. Но это не так. Если вы рассматриваете документацию как отображение вашего дизайна и системных правил в элегантной и понятной форме, вы можете оценить ее больше. Кроме того, нужно поставить себя в положение людей, которые должны поддерживать систему. Быть брошенным 500 файлов кода и просить их исправить проблемы - это плохо, но не редкость.

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

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

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

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

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

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

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

Тем не менее, я использую UML время от времени. Оценить дизайн высокого уровня (хороший дизайн имеет сложность по краям и простоту в центре). Передать идею коллеге и получить обратную связь. Чтобы найти скрытые отношения, нормализовать и т. Д. Но это всегда отражение того, что уже в моей голове. Обычно я рисую UML ручкой и бумагой, желательно подальше от любого компьютера. При необходимости, когда дизайн кристаллизуется, я делаю визуальное представление в программе для рисования.

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

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

Я нахожу их сильно переоцененными. Я считаю их единственными картинами, которые не рисуют тысячи слов.

UML имеет ценность только в том случае, если разработчики системы не могут сами написать код. то есть, UML - это «язык», который передает архитектурные концепции кому-то еще, теперь, если вы человек, который разрабатывает код и реализует его, то зачем вам нужно показывать себе, что вы собираетесь делать ?! Садитесь и идите прямо к кодированию вместо этого. Вам все равно придется документировать то, что вы сделали позже, но общая эффективность быстрее.

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

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

Однако диаграмма классов устарела до ее рождения. Грубый дизайн не требует UML, и тщательная документация лучше автоматически извлекается (в реальном времени) из базы кода. Javadoc и Doxygen полностью устранили необходимость в ручных диаграммах классов.

Суть документации в том, что есть два уровня:

• Высокоуровневые (архитектурные) решения должны быть оформлены вручную
• факты низкого уровня (сущностные отношения) должны извлекаться автоматически

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

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

Я обнаружил, что итерация необходима, потому что просто рисование картинок всегда пропускает важные аспекты, в то время как только кодирование приводит к проблемным проектам.

Однако, как сказал другой плакат, все сводится к людям. Если они умело «используют» UML-диаграммы, то UML неоценим. Если это не так, то диаграммы не имеют значения.

Таким образом, ответ на ваш вопрос на самом деле, «это зависит». В этом случае это зависит от людей, сложности проекта и того, насколько важно, чтобы система работала правильно.

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

Я люблю диаграммы, но если бы меня попросили сделать один (особенно UML!), Я бы задал два вопроса:

1. Кто это для?
2. Им это нужно сейчас?

Диаграммы сразу устаревают. Так что, если вы сейчас не используете его для общения с кем-то, он просто сгниет. И если человек, с которым вы общаетесь, преуспеет с текстовым описанием, телефонным звонком или неофициальной биграммой на доске - предложите вместо этого.

Одна из основных проблем для меня относительно UML-диаграмм, которую я видел до сих пор, заключается в том, что они в основном служат лишь «красивыми картинками» на чьей-то стене или в виде свернутой страницы в привязке где-то и редко служат основой для производственного кода.

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

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

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

Не знаю, стоит ли вопрос о достоинствах UML или о достоинствах проектирования архитектуры программ.

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

О разработке программ.

1. У каждой программы есть дизайн, даже если вы его не планируете. Когда код написан, просто перепроектируйте его. Если вы этого не планировали, держите пари, что это будет плохой дизайн.

2. Дизайн сэкономит ваше время, используя известные шаблоны для повторяющихся проблем.

3. Если вы работаете в команде, дизайн необходим для обсуждения решений, передачи идей и очень практичный, но необходимый для распределения работы.