Насколько практичен UML? [закрыто]

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

Изменить: мой опыт ограничен небольшими проектами разработчиков до 10.

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

В достаточно сложной системе есть места, где некоторые UMLсчитаются полезными.

Полезные диаграммы для системы различаются в зависимости от области применения.
Но наиболее широко используются:

• Диаграммы классов
• Диаграммы состояний
• Диаграммы деятельности
• Диаграммы последовательности

Есть много предприятий, которые клянутся ими, и многие, которые категорически отвергают их как пустую трату времени и усилий.

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

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

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

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

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

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

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

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

Общий рабочий процесс и DFD могут быть очень полезны для сложных процессов. По моему опыту, все остальные диаграммы (ОСОБЕННО UML) без исключения были болезненной тратой времени и усилий.

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

Теперь другой вопрос, хорошо ли его используют .

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

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

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

Я уточню свой ответ, упомянув, что у меня нет опыта работы в крупных (подобных IBM) корпоративных средах разработки.

Я смотрю на UML и Rational Unified Process так , что он больше ГОВОРИТ о том, что вы собираетесь делать, чем на самом деле ДЕЛАТЬ то, что вы собираетесь делать.

(Другими словами, это пустая трата времени)

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

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

Время в классе было ограничено, как и мое время вне класса. Таким образом, нам приходилось выполнять проверку кода на каждом собрании класса, но с 25 зачисленными студентами время индивидуальной проверки было очень коротким. Инструментами, которые мы нашли наиболее ценными в этих обзорных сессиях, были ERD, диаграммы классов и диаграммы последовательностей. Диаграммы ERD и классов создавались только в Visual Studio, поэтому время, необходимое для их создания, для студентов было тривиальным.

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

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

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

• Общение
• Стандартизированная документация по проекту / решению
• Определение DSL (язык для домена)
• Определение модели (профили UML)
• Шаблон / использование активов
• Генерация кода
• Преобразования модели в модель

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

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

UML работал у меня много лет. Когда я только начинал, я читал « UML Distilled» Фаулера, где он говорит: «Сделайте достаточно моделирования / архитектуры / и т. Д.». Просто используйте то, что вам нужно !

С точки зрения QA-инженера, диаграммы UML указывают на потенциальные недостатки логики и мышления. Делает мою работу проще :)

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

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

При этом мне нравятся следующие инструменты UML:

1. Фиолетовый - Если бы это было проще, это был бы лист бумаги

2. Altova UModel - хороший инструмент для моделирования на Java и C #

3. MagicDraw - Мой любимый коммерческий инструмент для моделирования

4. Посейдон - достойный инструмент с хорошей отдачей

5. StarUML - лучший инструмент моделирования с открытым исходным кодом

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

Из темы: Использование моделей в процессе разработки на http://msdn.microsoft.com/en-us/library/dd409423%28VS.100%29.aspx

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

Вы также можете прочитать мой ответ на следующий пост:

Как научиться «хорошему дизайну / архитектуре программного обеспечения»? на /programming/268231/how-to-learn-good-software-design-architecture/2293489#2293489

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

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

У UML есть еще один важный аспект: он «говорит» напрямую с нашей сильнейшей способностью - визуализацией. Если бы, например, ITIL V3 (в сущности достаточно простой) был представлен в форме диаграмм UML, его можно было бы опубликовать в нескольких десятках листов формата A3. Вместо этого он вышел в виде нескольких томов поистине библейских масштабов, породив целую индустрию, невероятные затраты и широко распространенный кататонический шок.

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

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

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

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

По сути, не имеет значения, что вы используете, вам просто нужно иметь в виду две вещи:

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

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

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

UML действительно полезен! Я использовал его в основном:

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

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

Я считаю, что есть способ использовать примеры использования UML для рыбы, воздушного змея и уровня моря в стиле Кокберна, как описано Фаулером в его книге «UML Distilled». Моя идея заключалась в том, чтобы использовать варианты использования Кокберна для облегчения чтения кода.

Итак, я провел эксперимент, и здесь есть сообщение об этом с тегом «UML» или «FOWLER». Для C # это была простая идея. Найдите способ встраивать варианты использования Кокберна в пространства имен программных конструкций (например, пространства имен классов и внутренних классов или используя пространства имен для перечислений). Я считаю, что это может быть жизнеспособный и простой метод, но все еще есть вопросы, и другие должны его проверить. Это может быть хорошо для простых программ, которым нужен своего рода псевдодоменный язык, который может существовать прямо посреди кода C # без каких-либо языковых расширений.

Пожалуйста, ознакомьтесь с публикацией, если вам интересно. Иди сюда .

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

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

Будучи студентом, я считаю, что от UML очень мало пользы. Мне кажется парадоксальным, что ПРОГРАММИРОВАТЕЛИ еще не разработали программу, которая автоматически генерирует то, что, по вашему мнению, необходимо. Было бы чрезвычайно просто разработать функцию в Visual Studio, которая могла бы извлекать фрагменты данных, искать определения и ответы на продукты, достаточные для того, чтобы любой мог посмотреть на нее, большой или маленький, и понять программу. Это также будет поддерживать его в актуальном состоянии, поскольку для создания информации потребуется информация непосредственно из кода.

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

Проблема с UML в том, что книга основателей слишком расплывчата.

UML - это просто язык, а не метод.

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

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

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

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

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

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

По моему опыту:

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

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

UML полезен двумя способами:

• Техническая сторона: многие люди (менеджер и некоторый функциональный аналитик) думают, что UML - это роскошная функция, потому что код - это документация: вы начинаете кодировать после того, как отладите и исправите . Синхронизация диаграмм UML с кодом и анализом заставят вас хорошо понимать запросы заказчика;

• Управленческая сторона: диаграммы UMl являются зеркалом требований клиента, который является неточным: если вы кодируете без UML, возможно, вы найдете ошибку в требованиях после долгих часов работы. Диаграммы UML позволяют найти возможные спорные моменты и разрешить их до кодирования => помочь в планировании.

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

Если вы состоите в linkedin group SYSTEMS ENGINEERS , см. мою старую дискуссию .

В конце концов, UML существует только благодаря RUP. Нужен ли нам UML или что-либо подобное для использования Java / .Net? Практический ответ заключается в том, что у них есть собственная документация (javadoc и т. Д.), Которой достаточно, чтобы мы могли выполнять свою работу!

UML нет, спасибо.

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

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

UML - это всего лишь один из способов общения внутри людей. Доска лучше.