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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

То, как я рассматриваю UML и Rational Unified Process, состоит в том, что это больше говорит о том, что вы собираетесь делать, чем на самом деле делать то, что вы собираетесь делать.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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, Flowchard, Nassi-Schneiderman, что угодно – вместо того, чтобы выходить из дома.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

если вы связаны с группой SYSTEMS ENGINEERS , см. мою старую дискуссию .

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

UML no thanx.

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

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

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