Как UML полезный? [дубликат]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

UML не используется для разработки базы данных OO. Он используется для моделирования различных конструкций программного обеспечения. Например, Use Case используется для захвата границы системы или взаимодействия субъектов/пользователей с системой. Эта конструкция помогает зафиксировать требования пользователей. Статические диаграммы используются для моделирования класса и его взаимосвязи. Вы можете моделировать взаимодействие с помощью диаграммы последовательности, и это чрезвычайно полезно в IMHO.

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

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

Попробуйте встроенную утилизацию содержимого, однако я должен проверить это:

Response.ContentType = "application/pdf"; 
Response.AppendHeader("content-disposition", "inline; filename=" + name ); 

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

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

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

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

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

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

Class diagram - это круто, но всегда устаревает, поэтому не очень важно.

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