Проектные документы против UML или и то, и другое?

Question

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

1. Стоит ли UML всех затрат времени на изучение / выполнение, даже для небольших и средних проектов?
2. Могут ли хорошо проработанные проектные документы, хотя и более высокого уровня, быть достаточными для того, чтобы программисты стремились создавать правильный код даже в командах?

Answer 1

Я не думаю, что UML сам по себе достаточен.

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

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

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

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

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

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

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

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

Answer 2

Я бы ответил:

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

Это означает определенный уровень разбиения задачи на простые формулировки для менеджеров «что нам нужно делать» и объяснение любых препятствий.

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

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

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

UML, насколько я понимаю, того не стоит.

Answer 3

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

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

Answer 4

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