Является ли UML практичным?

Ответ 1

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

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

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

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

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

Ответ 2

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

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

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

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

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

Ответ 3

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

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

Ответ 4

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

Ответ 5

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

Теперь, правильно ли он используется, это другое дело.

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

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

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

Ответ 6

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

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

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

Ответ 7

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

Ответ 8

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

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

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

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

Ответ 9

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

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

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

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

Ответ 10

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

Ответ 11

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

Ответ 12

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

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

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

• Фиолетовый - если бы он был более простым, это был бы лист бумаги

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

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

• Посейдон - достойный инструмент с хорошим ударом для доллара

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

Ответ 13

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

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

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

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

Как узнать "хороший дизайн/архитектура программного обеспечения"? на https://stackoverflow.com/questions/268231/how-to-learn-good-software-design-architecture/2293489#2293489

Ответ 14

Хотя эта дискуссия давно неактивна, у меня есть несколько моментов, которые нужно добавить.

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

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

Ответ 15

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

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

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

Ответ 16

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

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

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

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

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

Ответ 17

UML полезен, да! Основное использование, которое я сделал, это:

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

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

Ответ 18

Я считаю, что может существовать способ использования UFC-игр Cockburn, использования кайта и использования на уровне моря, как описано Фаулером в его книге "UML Distilled". Моя идея заключалась в том, чтобы использовать примеры использования Cockburn в качестве помощи для чтения кода.

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

Пожалуйста, проверьте сообщение, если вы заинтересованы. Go здесь.

Ответ 19

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

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

Ответ 20

Исходя из студента, я считаю, что UML очень мало используется. Мне показалось ироничным, что PROGAMERS еще не разработали программу, которая автоматически генерирует то, что вы сказали, необходимы. Было бы очень просто разработать функцию в Visual Studio, которая могла бы вытащить фрагменты данных, искать определения и удовлетворять ответы на продукты, чтобы любой мог взглянуть на нее, большой или малой, и понять программу. Это также будет поддерживать его актуальность, потому что для получения информации непосредственно из кода потребуется информация.

Ответ 21

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

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

UML - это просто язык, это не действительно метод.

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

Ответ 22

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

Ответ 23

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

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

Ответ 24

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

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

Ответ 25

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

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

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

Ответ 26

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

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

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

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

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

Ответ 27

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

UML no thanx.

Ответ 28

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

Ответ 29

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

Ответ 30

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