Какие схемы UML вы используете?

Ответ 1

Я чаще использую следующие диаграммы:

• диаграммы классов:  Чтобы объяснить отношение класса
• Диаграммы последовательности:  Для захвата взаимодействия объектов
• Диаграммы действий:  Объяснить действия (поток алгоритмов).

EDIT: Добавлены ссылки в комментарии от @Smith325.

Ответ 2

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

Онлайн-инструмент

Ответ 3

Я не использую его.

Я почти не видел их со времен университета и моих дипломных проектов.

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

Хотя я не говорю, что UML не может принести никаких преимуществ.

Ответ 4

Возможно, было бы лучше спросить, какую практическую пользу я получу от использования UML?

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

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

Ответ 5

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

Ответ 6

• диаграммы вариантов использования: для определения поведенческих требований
• диаграммы последовательности: для захвата взаимодействий объектов

очень мало или вообще не используется вообще ничего

Ответ 7

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

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

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

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

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

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

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

Ответ 8

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

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

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

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

Ответ 9

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

Ответ 10

Все они могут использоваться для проектирования и документирования проекта. Это очень удобно для интерпретации.

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

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

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

Ответ 11

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

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

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

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

Я не беспокоюсь о формальности моих диаграмм; это грубые эскизы на доске.

Ответ 12

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

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

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

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

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

3) Наконец, кодирование решения, которое отвечает как определению проблемы, так и предлагаемой технической спецификации, приведенной на этапах 1 и 2 выше, приспосабливая решение, чтобы соответствовать реальности, где это необходимо (шаги 2 и 3 часто пересекаются, причем одна подача в другой).

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

• Хуже того, когда вы указываете на нетехнических евангелистов UML, что они не определили проблему до того, как попытались описать предлагаемое решение, они обычно указывают вам на нагрузку "случаев использования" и диаграмм с небольшими фигурами палки, которые они любят называть "актеров" и совершенно не понимают, что те аспекты их производства, в лучшем случае, просто неполные описания одного возможного решения и никоим образом не представляют собой абстрактное определение проблемы. Например, прецедент "Боб нажимает на педаль акселератора, и машина идет быстрее" - это частичное описание потенциального решения (автомобиля), то есть само по себе только одно возможное решение (и, пожалуй, не самое подходящее ) к фактической основной проблеме, которую "Бобу нужно получить от А до Б. Если вы также знаете, что Боб 1) не может двигаться, 2) в любом случае живет на лодке - какие факты только полное определение фактической проблемы скажет вы - этот прецедент о педали начинает выглядеть довольно неуместным, не так ли?

Ответ 13

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

Ответ 14

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

Ответ 15

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

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

Ответ 16

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

Ответ 17

Спросите себя, что .Net или Java поставляют UML где-то в составе пакета документации?

Ответ 18

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

Ответ 19

Мое личное голосование: Примеры использования диаграмм Схемы последовательности Диаграммы классов

со случайной дополнительной диаграммой деятельности.

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

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

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

Ответ 20

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