Как полезен UML?

Возможный дубликат:
Является ли UML практичным?

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

Я хочу знать технические причины, по которым UML используется в профессиональном мире; почему это важно. Не просто научиться этому, потому что профессор так говорит.

Ответ 1

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

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

Ответ 2

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

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

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

Ответ 3

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


UML не используется для проектирования базы данных OO. Он используется для моделирования различного дизайна программного обеспечения. Например, вы будете использовать Use Case для захвата границы системы или взаимодействия участников/пользователей с системой. Эта конструкция помогает отслеживать пользовательские требования. Вы используете статические диаграммы для моделирования класса и их отношений. Вы можете моделировать взаимодействие с использованием диаграммы последовательностей, и это очень полезно в ИМХО.

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

Ответ 4

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

Используя их вместе, UML выполняет две вещи:

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

Ответ 5

UML может использоваться для разных целей:

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

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

3) диаграмма классов может служить в качестве документации макроструктуры проектов. Крайне важно иметь такую ​​диаграмму классов, если вы хотите пригласить новых разработчиков в свой проект.

Ответ 6

Дает вам визуальный дизайн проекта

Ответ 7

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

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

Ответ 8

У меня есть более 10 лет опыта работы с кодированием, C/С++/С# в финансовом секторе, и ни разу я не использовал UML.
Это может быть отражением моей работы ха-ха, но я никогда не видел ее в использовании. Проектные документы, как правило, основаны на письменных описаниях и/или раскадровке.
Судя по всему, к моменту написания точной и всеобъемлющей диаграммы UML, которая должна быть преобразована в код, вы также можете написать код.
Существует аргумент, что если вам нужно передать дизайн другим, это может быть полезно... но я думаю, вам нужно знать:

  • Как часто вам нужно делать такой дизайн (предположительно с нуля)? Не так много систем настолько зеленые, что они нуждаются в таком полном дизайне.
  • будут ли люди, с которыми вы говорите, чтобы они действительно понимали это так же полно, как вы, кто потратил время на это? Деловые люди вряд ли будут.
  • будут ли диаграммы потоков/раскадровки/говорить достаточно? Вообще, это намного более интуитивно понятный и доступ к более широкой аудитории.
  • люди бизнеса хотят, чтобы вы начали внедрять его, прежде чем сможете его закончить, из-за требований конкурентов/прототипов? Будет ли такая формальная диаграмма иметь значение, если к тому моменту, когда вы это сделали, требования меняются настолько, что вы должны ее переделать?
    Я думаю, если вы пишете реальное программное обеспечение, например, системы управления самолетами, это должен быть рок-дизайн, но я не знаю, является ли это методом.

Ответ 9

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

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

Ответ 10

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

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

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