Практичен ли UML?[закрыто]
https://stackoverflow.com/questions/18803
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
В колледже у меня было множество дизайнерских и UML ориентированных курсов, и я признаю, что UML может быть использован в интересах программного проекта, особенно пример использования картографирование, но действительно ли это практично?Я изучил несколько условий совместной работы, и оказалось, что UML не очень широко используется в отрасли.Стоит ли тратить время во время проекта на создание UML-диаграмм?Кроме того, я нахожу, что диаграммы классов, как правило, бесполезны, потому что просто быстрее просмотреть файл заголовка для класса.Какие конкретно диаграммы являются наиболее полезными?
Редактировать: Мой опыт ограничен небольшими, менее чем 10 проектами для разработчиков.
Редактировать: Много хороших ответов, и хотя они не самые подробные, я считаю, что выбранный является наиболее сбалансированным.
Решение
В достаточно сложной системе есть несколько мест, где некоторый UML считается полезным.
Полезные диаграммы для системы различаются в зависимости от применимости.Но наиболее широко используемыми из них являются Диаграммы состояний, Активности и Последовательности действий.
Есть много предприятий, которые клянутся ими, и много тех, кто прямо отвергает их как пустую трату времени и усилий.
Лучше всего не перегибать палку и не думать, что лучше для проекта, над которым вы работаете, а выбрать то, что применимо и имеет смысл.
Другие советы
Использовать UML - все равно что смотреть на свои ноги, когда вы идете.Это делает осознанным и явным то, что вы обычно можете делать неосознанно.Новичкам нужно тщательно продумать, что они делают, но профессиональный программист уже знает, что он делает.В большинстве случаев написание самого кода происходит быстрее и эффективнее, чем написание о коде, потому что их интуиция программиста настроена на выполнение задачи.
Но дело не только в том, что ты делаешь.А как насчет нового сотрудника, который придет через шесть месяцев и которому нужно будет быстро освоиться с кодом?А что будет через пять лет, когда все, кто сейчас работает над проектом, уйдут?
Невероятно полезно иметь некоторую базовую актуальную документацию, доступную для всех, кто присоединится к проекту позже.Я не сторонник полноценных UML-диаграмм с именами методов и параметрами (их слишком сложно поддерживать), но я действительно думаю, что базовая диаграмма компонентов системы с их взаимосвязями и базовым поведением бесценна.Если дизайн системы кардинально не изменится, эта информация не должна сильно измениться, даже по мере доработки реализации.
Я обнаружил, что ключом к документации является умеренность.Никто не собирается читать 50 страниц полноценных UML-диаграмм с проектной документацией, не засыпая на нескольких страницах.С другой стороны, большинство людей хотели бы получить 5-10 страниц простых диаграмм классов с некоторыми базовыми описаниями того, как устроена система.
Другой случай, когда я обнаружил, что UML полезен, - это когда старший разработчик отвечает за разработку компонента, но затем передает дизайн младшему разработчику для реализации.
Использовать UML - все равно что смотреть на свои ноги, когда вы идете.Это делает осознанным и явным то, что вы обычно можете делать неосознанно.Новичкам нужно тщательно продумать, что они делают, но профессиональный программист уже знает, что он делает.В большинстве случаев написание самого кода происходит быстрее и эффективнее, чем написание о коде, потому что их интуиция программиста настроена на выполнение задачи.
Исключением является то, что вы оказываетесь ночью в лесу без фонарика, и начинается дождь - тогда вам нужно смотреть под ноги, чтобы не упасть.Бывают моменты, когда задача, за которую вы взялись, сложнее, чем может справиться ваша интуиция, и вам нужно притормозить и явно указать структуру вашей программы.Тогда UML - это один из многих инструментов, которые вы можете использовать.Другие включают псевдокод, высокоуровневые диаграммы архитектуры и странные метафоры.
Общий рабочий процесс и DFDS могут быть очень полезны для сложных процессов.Все остальные схемы (ОСОБЕННО UML), по моему опыту, без исключения были болезненной тратой времени и сил.
Я должен был бы не согласиться, UML используется повсеместно - везде, где разрабатывается ИТ-проект, UML обычно присутствует.
Теперь о том, используется ли он что ж это другое дело.
Как сказал Стю, я нахожу оба варианта использования (вместе с описаниями вариантов использования) и диаграммы действий наиболее полезными с точки зрения разработчика.
Диаграмма классов может быть очень полезна при попытке показать связи, а также атрибуты объекта, такие как постоянство.Когда дело доходит до добавления какого-либо одного атрибута или свойства, они обычно излишни, тем более что они часто быстро устаревают после написания кода.
Одна из самых больших проблем с UML - это объем работы, необходимый для поддержания его в актуальном состоянии после создания кода, поскольку существует мало инструментов, которые могут реинжинирировать UML из кода, и еще мало таких, которые делают это хорошо.
Я уточню свой ответ, упомянув, что у меня нет опыта работы в крупных (подобных IBM) корпоративных средах разработки.
То, как я рассматриваю UML и Рациональный Унифицированный Процесс в том, что это нечто большее РАЗГОВАРИВАЮЩИЙ о том, что ты собираешься делать, чем на самом деле ДЕЛАЯ что ты собираешься делать.
(Другими словами, это в значительной степени пустая трата времени)
Выбрасывайте только по моему мнению.UML - отличный инструмент для обмена идеями, единственная проблема заключается в том, когда вы храните и поддерживаете его, потому что вы, по сути, создаете две копии одной и той же информации, и именно здесь это обычно срабатывает.После начального этапа внедрения большая часть UML должна быть сгенерирована из исходного кода, иначе он очень быстро устареет или потребует много времени (с ошибками вручную) для поддержания актуальности.
Последние два семестра в школе я совместно преподавал курс по разработке проектов для старших классов.Проект предназначался для использования в производственной среде с местными некоммерческими организациями в качестве платящих клиентов.Мы должны были быть уверены, что code работает так, как мы от него ожидали, и что студенты собирают все данные, необходимые для удовлетворения потребностей клиентов.
Время занятий было ограничено, как и мое время вне класса.Таким образом, нам приходилось проводить проверку кода на каждом собрании класса, но при участии 25 студентов время индивидуальной проверки было очень коротким.Инструментом, который мы сочли наиболее ценным на этих обзорных сессиях, были ERD, диаграммы классов и последовательности действий.ERD и диаграммы классов создавались только в Visual Studio, поэтому время, необходимое для их создания, было тривиальным для студентов.
Диаграммы передавали большой объем информации очень быстро.Получив краткий обзор проектов студентов, мы смогли быстро выделить проблемные области в их коде и выполнить более подробный анализ на месте.
Без использования диаграмм нам пришлось бы тратить время на то, чтобы один за другим просматривать файлы кода студентов в поисках проблем.
Я немного запоздал с этой темой и просто попытаюсь прояснить пару второстепенных моментов.Спрашиваю, полезен ли UML как слишком широкий.Большинство людей, казалось, ответили на этот вопрос с точки зрения типичного / популярного UML как инструмента рисования / коммуникации.Примечание:Мартин Фаулер и другие авторы книг по UML считают, что UML лучше всего использовать только для общения.Однако существует много других применений UML.Прежде всего, UML - это язык моделирования, который имеет обозначения и диаграммы, сопоставленные с логическими понятиями.Вот несколько вариантов использования UML:
- Информационные материалы
- Стандартизированная документация по проектированию/Решению
- DSL (язык, специфичный для конкретной предметной области) Определение
- Определение модели (профили UML)
- Шаблон / Использование активов
- Генерация кода
- Преобразования от модели к модели
Учитывая приведенный выше список использований, публикации Pascal недостаточно, поскольку она относится только к созданию диаграмм.Проект может извлечь выгоду из UML, если какой-либо из вышеперечисленных факторов является критическим фактором успеха или проблемными областями, требующими стандартизированного решения.
Обсуждение должно быть расширено от того, как UML можно переопределить или применить к небольшим проектам, до обсуждения того, когда UML имеет смысл или действительно улучшит продукт / решение, поскольку именно в этом случае следует использовать UML.Существуют ситуации, когда UML для одного разработчика также может иметь смысл, например, применение шаблона или генерация кода.
UML работает у меня уже много лет.Когда я начинал, я прочитал книгу Фаулера UML Дистиллированный где он говорит: "занимайтесь достаточным моделированием / архитектурой / и т.д.".Просто используй то, что тебе нужно потребность!
С точки зрения инженера по контролю качества, диаграммы UML указывают на потенциальные недостатки в логике и мышлении.Облегчает мою работу :)
Я думаю, что UML полезен, хотя я думаю, что спецификация 2.0 сделала то, что когда-то было четкой спецификацией, несколько раздутым и громоздким.Я действительно согласен с изданием временных диаграмм и т.д., поскольку они заполнили пустоту...
Чтобы научиться эффективно использовать UML, требуется немного практики.Самый важный момент - это четкое общение, моделирование, когда это необходимо, и моделирование в команде.Доски - лучший инструмент, который я нашел.Я не видел ни одного "программного обеспечения для цифровой доски", которому удалось бы передать полезность реальной доски.
Тем не менее, мне действительно нравятся следующие инструменты UML:
Фиолетовый - Если бы это было еще проще, это был бы лист бумаги
Altova UModel - Хороший инструмент для моделирования на Java и C #
MagicDraw - Мой любимый коммерческий инструмент для Моделирования
Poseidon - Достойный инструмент с хорошей отдачей
- StarUML - Лучший инструмент моделирования с открытым исходным кодом
Диаграммы 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
Хотя это обсуждение долгое время было неактивным, у меня есть пара - на мой взгляд, важных - моментов, которые я хотел бы добавить.
Глючный код - это одно.Оставленный дрейфовать по течению, ошибки проектирования могут привести к очень действительно, раздутый и уродливый.UML, однако, является самоподтверждающимся.Под этим я подразумеваю, что, позволяя вам исследовать ваши модели в нескольких, математически замкнутых и взаимопроверяющих измерениях, это создает надежный дизайн.
У UML есть еще один важный аспект:это "говорит" напрямую с нашей самой сильной способностью - визуализацией.Если бы, например, ITIL V3 (в основе своей достаточно простой) был представлен в виде UML-диаграмм, его можно было бы опубликовать на нескольких десятках раскладных листов формата A3.Вместо этого она вышла в нескольких томах поистине библейских масштабов, породив целую индустрию, умопомрачительные затраты и повсеместный кататонический шок.
Я вижу, что диаграммы последовательности и активности используются довольно часто.Я много работаю с системами "реального времени" и встроенными системами, которые взаимодействуют с другими системами, и диаграммы последовательностей очень помогают визуализировать все взаимодействия.
Мне нравится составлять диаграммы вариантов использования, но я встречал не так уж много людей, которые считают их ценными.
Я часто задавался вопросом, является ли Rational Rose хорошим примером приложений, которые вы получаете от проектирования на основе UML-моделей.Он раздутый, глючный, медленный, уродливый...
Я обнаружил, что UML не очень полезен для очень маленьких проектов, но действительно подходит для более крупных.
По сути, на самом деле не имеет значения, что вы используете, вам просто нужно помнить о двух вещах:
- Вам нужно какое-то архитектурное планирование
- Вы хотите быть уверены, что все в команде действительно используют одну и ту же технологию для планирования проекта
Итак, UML - это всего лишь то, что:Стандарт того, как вы планируете свои проекты.Если вы нанимаете новых людей, они, скорее всего, знают любой существующий стандарт - будь то UML, блок-схема, Nassi-Schneiderman, что угодно, - а не ваши собственные разработки.
Использование UML для одного разработчика и / или простого программного проекта кажется мне излишним, но при работе в более крупной команде мне определенно нужен какой-то стандарт для планирования программного обеспечения.
UML полезен, да, действительно!Основными применениями, которые я из этого извлек, были:
- Мозговой штурм по поводу того, как должна работать та или иная часть программного обеспечения.Это позволяет легко донести то, о чем вы думаете.
- Документирование архитектуры системы, ее шаблонов и основных взаимосвязей между ее классами.Это помогает, когда кто-то приходит в вашу команду, когда вы уходите и хотите убедиться, что ваш преемник поймет это, и когда вы в конце концов забываете, для чего, черт возьми, предназначался этот маленький урок.
- Документирование любого архитектурного шаблона, который вы используете во всех своих системах, по тем же причинам, что и точка выше
Я только не согласен с Майкл когда он говорит , что использование UML для одного разработчика и / или простого программного проекта кажется излишним для него.Я использовал его в своих небольших личных проектах, и документирование их с использованием UML сэкономило мне много времени, когда я вернулся к ним семь месяцев спустя и совершенно забыл, как я создавал и собирал воедино все эти классы.
Я полагаю, что может быть способ использовать варианты использования UML в стиле Кокберна для рыб, воздушных змеев и уровня моря, описанные Фаулером в его книге "UML Distilled". Моя идея состояла в том, чтобы использовать варианты использования Cockburn в качестве вспомогательного средства для удобства чтения кода.
Итак, я провел эксперимент, и здесь есть сообщение об этом с тегом "UML" или "FOWLER". Это была простая идея для c #.Найдите способ встроить варианты использования Cockburn в пространства имен программных конструкций (такие как пространства имен класса и внутреннего класса или используя пространства имен для перечислений).Я считаю, что это мог бы быть жизнеспособный и простой метод, но у меня все еще есть вопросы, и мне нужно, чтобы другие проверили его.Это могло бы быть полезно для простых программ, которым нужен какой-то псевдодоменный язык, который может существовать прямо посреди кода c # без каких-либо языковых расширений.
Пожалуйста, ознакомьтесь с этим сообщением, если вам интересно.Вперед здесь.
Одна из проблем, с которыми я сталкиваюсь при работе с UML, - это понятность спецификации.Когда я пытаюсь по-настоящему понять семантику конкретной диаграммы, я быстро теряюсь в лабиринте метамоделей и мета-мета-моделей.Одним из преимуществ UML является то, что он менее двусмыслен, чем естественный язык.Однако, если два или более инженеров интерпретируют диаграмму по-разному, она не достигает поставленной цели.
Кроме того, я пытался задавать конкретные вопросы о документе super-structure на нескольких форумах UML и членам самой OMG, но практически безрезультатно.Я не думаю, что сообщество UML еще достаточно зрелое, чтобы поддерживать себя само.
Исходя из слов студента, я нахожу, что от UML очень мало пользы.Я нахожу ироничным, что ПРОГРАММИСТАМ еще предстоит разработать программу, которая автоматически сгенерирует то, что, по вашим словам, необходимо.Было бы чрезвычайно просто спроектировать функцию в Visual Studio, которая могла бы извлекать фрагменты данных, искать определения и ответы на вопросы о продукте, достаточные для того, чтобы любой желающий мог взглянуть на нее, большую или малую, и понять программу.Это также позволило бы поддерживать его в актуальном состоянии, поскольку для создания информации требовалось бы брать информацию непосредственно из кода.
UML используется, как только вы представляете класс с его полями и методами, хотя это всего лишь своего рода UML-диаграмма.
Проблема с UML заключается в том, что книга основателей слишком расплывчата.
UML - это всего лишь язык, на самом деле это не метод.
Что касается меня, то меня действительно раздражает отсутствие UML-схемы для проектов с открытым исходным кодом.Возьмите что-то вроде Wordpress, у вас просто есть схема базы данных, ничего больше.Вам придется побродить по api codex, чтобы попытаться получить общую картину.
У UML есть свое место.Это становится все более важным по мере роста масштабов проекта.Если у вас давно запущенный проект, то лучше всего документировать все в UML.
UML, по-видимому, подходит для крупных проектов с большими командами людей.Однако я работал в небольших командах, где коммуникация была лучше.
Однако использование диаграмм в стиле UML полезно, особенно на стадии планирования.Я склонен мыслить кодом, поэтому мне сложно писать большие спецификации.Я предпочитаю записывать входные и выходные данные и оставлять разработчикам разрабатывать бит посередине.
По моему опыту:
Способность создавать и передавать осмысленные диаграммы кода является необходимым навыком для любого инженера-программиста, который разрабатывает новый код или пытается понять существующий код.
Знание специфики UML - когда использовать пунктирную линию или конечную точку круга - не так уж необходимо, но все равно полезно.
Я считаю, что UML полезен только тем фактом, что он заставляет людей задуматься об отношениях между их классами.Это хорошая отправная точка для того, чтобы начать думать о таких отношениях, но это определенно не решение для всех.
Я убежден, что использование UML зависит от ситуации, в которой работает команда разработчиков.
UML полезен двумя способами:
Техническая сторона:многие люди (менеджер и некоторые функциональные аналитики) думают, что UML - это роскошная функция, потому что Код - это документация:вы начинаете кодировать, после того как отладите и исправите.Синхронизация UML-диаграмм с кодом и анализом позволяет вам хорошо понимать запросы заказчика;
Сторона управления:диаграммы UMl являются зеркалом требований заказчика, которые являются неточными:если вы кодируете без UML, возможно, вы сможете найти ошибку в requireds после многих часов работы.Диаграммы UML позволяют вам найти возможные спорные моменты и разрешить их до начала кодирования => помогают вашему планированию.
Как правило, все проекты без UML-диаграмм имеют поверхностный анализ или небольшой размер.
если вы состоите в группе linkedin СИСТЕМНЫЕ ИНЖЕНЕРЫ, видеть моя старая дискуссия.
В конце концов, UML существует только из-за RUP.Нужен ли нам UML или любой другой связанный с ним материал для использования Java / .Net?Практический ответ заключается в том, что у них есть своя документация (javadoc и т.д.), Которой достаточно и которая позволяет нам выполнять нашу работу!
UML не благодарит.
UML, безусловно, полезен так же, как и junit.Все зависит от того, как вы продаете идею.Ваша программа будет работать без UML точно так же, как она работала бы без модульных тестов.Сказав это, вы должны создать do UML по мере того, как он связан с вашим кодом, т. е. когда вы обновляете UML-диаграммы, он обновляет ваш код, или когда вы обновляете свой код, он автоматически генерирует UML.Не делайте этого просто ради того, чтобы делать это.
UML определенно занимает свое место в отрасли.Представьте, что вы создаете программное обеспечение для самолетов Boing или какой-то другой сложной системы.UML и RUP были бы здесь большим подспорьем.
UML - это всего лишь один из методов общения внутри людей.Белая доска лучше.
