Практичен ли UML? [закрыто]

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

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

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

20.08.2008 20:53:05
Результаты опроса 2013 года показывают, что он используется не так часто, как ожидают (!) Профессора разработки программного обеспечения, и показывают некоторые причины: oro.open.ac.uk/35805/8/UML%20in%20practice%208.pdf
Fuhrmanator 11.06.2015 23:21:25
30 ОТВЕТОВ
РЕШЕНИЕ

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

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

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

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

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

45
7.09.2019 04:08:57

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

18
20.08.2008 20:56:36

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

1
20.08.2008 20:58:29
Или, по крайней мере, ключевые вопросы дизайна.
Silvercode 6.11.2008 08:20:57

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

-3
20.08.2008 21:02:43

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

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

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

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

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

16
20.08.2008 21:02:56

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

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

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

2
20.08.2008 21:02:56

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

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

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

13
20.08.2008 21:10:37
Я не буду голосовать против вас, потому что я думаю, что это хороший ответ, но я не мог не согласиться больше. Каждый раз, когда я что-то строю, я экономлю часы или месяцы времени разработки и почти всегда развиваюсь один (в последнее время).
Dan Rosenstark 22.10.2008 06:09:40
Разговор и письмо о том, что вы хотите сделать, поможет вам и другим быстрее понять и уловить возможные проблемы.
Kamran Bigdely 16.06.2015 17:34:32

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

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

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

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

10
20.08.2008 22:57:44
+1 Хорошая визуализация данных помогает выявлять проблемы и тенденции, которые в противном случае скрыты за несущественными деталями.
Vlad Gudim 14.01.2010 11:43:09

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

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

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

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

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

2
20.08.2008 23:03:43

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

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

32
21.08.2008 00:09:42
Странная вещь об этом сайте, нет никакого способа сказать, что вы цитируете кого-то в первом абзаце, а затем не соглашаетесь с ним ... но да, правда: псевдокод также является отличным методом построения диаграмм и очень часто используется. Странные метафоры, касающиеся лесов, факелов и т. Д., Тоже великолепны.
Dan Rosenstark 22.10.2008 06:13:28
совсем не согласен - если вы делаете сложные компоненты - ум должен быть
yehonatan yehezkel 26.05.2019 12:19:11

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

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

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

2
23.05.2017 12:02:56

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

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

1
21.08.2008 05:15:38
Также в немного меньших проектах это расстраивает работу, общаясь по моему мнению. Если вам приходится все время спрашивать и рассказывать много материала, это прерывает работу и никаких документов не производится. Вместо этого ключевые принципы проектирования должны быть документированы и смоделированы.
Silvercode 6.11.2008 08:24:53

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

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

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

0
21.08.2008 19:29:44

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

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

1
21.08.2008 19:50:23

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

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

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

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

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

82
21.08.2008 20:00:22
«А как насчет нового найма, который появится через шесть месяцев и должен быстро освоить код?» Э-э-э ... как насчет кода? Это единственный точный и полный способ освоения кода. Также самый естественный способ, учитывая, что мы программисты. Я считаю, что нам нужно взглянуть на диаграмму, чтобы понять код полностью смехотворно, а также удручающе, что этот мусор каким-то образом получил широкое распространение.
BobTurbo 3.06.2011 08:31:25
Согласитесь с BobTurbo, я никогда не использовал UML, особенно чей-то еще UML. Я всегда предпочитаю идти прямо к коду.
James Adam 20.02.2013 19:38:41
Я нашел рисование диаграммы классов UML, прежде чем приступить к кодированию сэкономило мне время. Это позволило мне визуализировать недостатки дизайна и недостатки и обсудить их с моими коллегами. Еще лучше, если они нарисованы с использованием инструментов CASE, они сгенерируют базовый структурный код вашего приложения. Таким образом, срок окупаемости в три раза.
Andrew S 28.01.2014 07:09:10
@ Джеймс Адам, ни одна диаграмма не должна заменить взгляд на код, но в огромных базах кода (попробуйте миллионы строк кода), имеющих более общий обзор системы, можно сэкономить кучу времени и нервов.
serine 24.01.2015 01:14:30
Изображение по-прежнему стоит тысячи слов, даже если это код @BobTurbo. Я не вижу никаких рациональных аргументов против этого - и это включает аргументы, которые начинаются с «Ну, настоящие программисты ...». Если я собираюсь поговорить об архитектуре с моей командой, я не собираюсь скотч 10 страниц исходного кода на доске.
DavidS 19.06.2015 21:51:56

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

12
21.08.2008 19:54:36
Вау. Как насчет инструмента, который поддерживает диаграмму в синхронизации с кодом и наоборот, например, Вместе?
Dan Rosenstark 22.10.2008 06:08:21
Тот факт, что UML может быть сгенерирован из исходного кода, для меня означает, что чтение UML не дает никакой выгоды по сравнению с простым чтением исходного кода. Другими словами, это пустая трата времени.
Marcus Downing 25.09.2011 23:42:31
@ MarcusDowning Нет, это помогает новым сотрудникам в массовом порядке. На UML смотреть быстрее, чем на код.
Kamran Bigdely 16.06.2015 17:37:41

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

5
24.08.2008 09:41:45

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

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

Пожалуйста, проверьте почту, если вы заинтересованы. Иди сюда .

2
23.05.2017 12:10:43

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

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

2
25.09.2008 05:04:25

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

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

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

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

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

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

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

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

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

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

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

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

8
15.11.2016 10:59:45

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

4
22.10.2008 06:12:43

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

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

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

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

если вы находитесь в группе « СИСТЕМНЫЕ ИНЖЕНЕРЫ» , посмотрите мое старое обсуждение .

0
13.01.2009 14:19:29

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

2
27.01.2009 05:01:44
Это не так просто! Если вы используете реверс-инжиниринг для извлечения UML-модели из реального кода, вы, как правило, получаете столько деталей в вашей UML-модели, что это бесполезно. Без сомнения, исследователи занимаются этим, но решить эту проблему нелегко.
ComDubh 4.02.2016 17:20:37

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

-2
13.04.2009 21:18:04

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

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

-1
14.04.2009 04:27:17
RUP - это управление процессами, UML - это язык. UML полезен, когда вы имеете дело с большим количеством людей и нуждаетесь в общем языке.
programmernovice 9.08.2009 10:20:43
Вы когда-нибудь слышали о китайских шепотах - чем больше переводится из одной формы в другую, тем больше значения, различий и ошибок. Если UML настолько хорош, почему Microsoft, Sun, Google не включают UML в детали своего продукта? Вам будет трудно найти любой. Что случилось с инструментами? Прямые / обратные двухсторонние инструменты? Их не существует, потому что это увлечение умерло из-за недостатка заслуг.
mP. 11.08.2009 11:55:27

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

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

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

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

2
9.08.2009 10:17:40

Диаграммы 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

3
23.05.2017 12:26:33

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

-1
20.02.2010 03:20:16

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

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

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

3
13.05.2011 10:18:26
Вы читали стандарт UML? у него НЕТ математического фона, и даже есть внутренние противоречия. Это также очень трудно понять: например, прямоугольники с закругленными углами используются для двух совершенно разных вещей (состояний в конечных автоматах и ​​действий и действий в диаграммах действий). Это ужасно.
vainolo 27.06.2012 20:48:40