Какие диаграммы UML Вы используете? [закрытый]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Меня не волнует формальности в моих диаграммах; это грубые наброски на доске.

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

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

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

Меня не волнует формальности в моих диаграммах; это грубые наброски на доске.

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

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

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

Меня не волнует формальности в моих диаграммах; это грубые наброски на доске.

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

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

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

Меня не волнует формальности в моих диаграммах; это грубые наброски на доске.

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

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

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

Меня не волнует формальности в моих диаграммах; это грубые наброски на доске.

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

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

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

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

Use-Case diagrams do not provide any detail, but I haven't seen a better way to quickly give an overview of all the use-cases in the system.

Class diagrams are useful for showing the classes that are part of each package. However, I seldom see them used for that purpose by other developers. They are usually used to throw a bunch of classes on a picture with little rhyme and reason as to why the particular classes are in each picture. Thus, the diagrams end up not being very useful.

Sequence diagrams are indispensable. The tools absolutely do not support useful usage of sequence diagrams so you have to be somewhat inventive within the limitations of the tools. But I use sequence diagrams to prove that my use-cases match my architecture and my design matches my package operations etc... I don't think there is a more useful diagram. However, most people don't use them, probably because it forces you to think about your design.

The concept of the component diagram is useful. The UML version is pretty ugly, so I usually end up drawing my own diagram using Powerpoint or Visio.

I'm not much of a fan of state or activity diagrams. I had some bad experiences with other people's state machine designs early in my career and thus avoid them like the plague.

When it comes to presenting to a customer/manager then I use the information from these diagrams but I put it in a format that is easier to understand and at a much higher level.

However, for presenting to other software developers then these diagrams should be sufficient to convey the required information through design. But, usually they do require some narrative text be written in order to be of value.

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

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

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

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

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

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

Хотя я '

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

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

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

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

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

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