Документы дизайна против UML или оба?
Мне было тяжело сидеть перед UML и извлекать из него пользу, потому что это кажется почти такой же работой, как программирование (если вы используете выразительный язык). Я считаю, что написание на естественном языке говорит мне больше о программном проекте, чем о создании сложных диаграмм. Впрочем, я новичок в UML, и мне было интересно узнать, кто хорошо знает UML:
- Стоит ли UML все время, чтобы учиться / делать, даже для небольших и средних проектов?
- Могут ли хорошо продуманные проектные документы, хотя и на более высоком уровне, быть достаточными для того, чтобы программисты были нацелены на создание правильного кода даже в командах?
4 ответа
Я не думаю, что UML достаточно сам по себе.
Мне было тяжело сидеть перед UML и извлекать из него пользу, потому что это кажется почти такой же работой, как программирование (если вы используете выразительный язык).
Я согласен с этим. UML может предоставить подписи метода, но вы не заполняете сущность метода. Хуже того, вы ничего не можете сделать, приближаясь к TDD с UML. Если бы у меня был выбор, я бы предпочел использовать TDD и функциональный код, а не диаграммы UML.
Я считаю, что написание на естественном языке говорит мне больше о программном проекте, чем о создании сложных диаграмм.
Пятно на. Картинки могут быть полезны, если только они не плохие. Диаграммы последовательности имеют тенденцию становиться невероятно сложными для всех, кроме тривиальных потоков.
Стоит ли UML все время, чтобы учиться / делать, даже для небольших и средних проектов?
Продавцы и архитекторы скажут вам, что UML необходим, но я не согласен. Я попал в лагерь "Skecher" пользователей UML.
Могут ли хорошо продуманные проектные документы, хотя и на более высоком уровне, быть достаточными для того, чтобы программисты были нацелены на создание правильного кода даже в командах?
Я не знаю, что достаточно для того, чтобы программисты были в курсе, но я думаю, что UML не является большой частью этого. Архитекторам это нравится, потому что инструменты UML заставляют их работать, но большинству разработчиков все равно, кроме рамок и стрелок на белых досках.
Я бы ответил:
Ничто, абсолютно ничто не заменяет потребность в хорошем общении между программистами в команде разработчиков и менеджментом.
Это означает определенный уровень разбивки задачи на простые "что нам нужно сделать" заявления для менеджеров и объяснения любых препятствий.
Я работал над небольшим проектом, в котором вся структура классов программы была разработана кем-то на UML до написания любого кода. Отлично, но дизайнеры не предполагали, как могут использоваться классы, или необходимости менять определенные структуры, чтобы лучше соответствовать логике программы. Они просто выбросили дизайн, который, как они думали, будут работать.
Мне еще предстоит встретиться с кем-то, кто может разработать программу в своей голове и создать именно это при написании ее, помимо очень простых вещей. Процесс довольно органичен, и вещи должны меняться по мере того, как программисты осознают свои ранние ошибки и исправляют их. Я могу понять, почему начинает происходить ползучесть функций, и именно здесь руководству необходимо понять, что происходит, быть в курсе и обновляться. Хорошие менеджеры будут слушать то, что им говорят их программисты, и соответствующим образом корректировать взгляды.
Итак, из двух ваших вариантов я бы выбрал проектный документ высокого уровня: мы хотим, чтобы программное обеспечение делало это, работало на этой платформе, принимало такого рода вводные данные и выплевывало подобные вещи. Это работает, если вышеупомянутое сохраняется.
UML, насколько я понимаю, не стоит этого.
Не по моему мнению. Однажды я сделал модуль проектирования ОО как часть MSc в области компьютерных наук, и UML едва упоминался (хотя, по моему мнению, его следовало бы обсудить намного больше, учитывая его влияние).
Существует больше возможностей для уменьшения неоднозначности в письменном тексте, чем в диаграмме UML, большинство диаграмм UML оставляют много возможностей для интерпретации. При этом я очень большой поклонник использования диаграмм в документах по разработке программного обеспечения, и многие диаграммы UML чрезвычайно лаконичны: развертывание, состояние, класс и активность - мои любимые. Когда я создаю UML-диаграммы, я стараюсь грубо придерживаться соглашений, но я не позволяю им мешать, если они не могут представить концепцию, которую я пытаюсь донести.
Мы не можем полностью игнорировать UML, так как некоторые диаграммы полезны, когда речь идет о сложной функциональности или, скажем, длительном рабочем процессе и сценариях, когда разработчики могут пропустить некоторые случаи, когда сценарии не прорисованы / не разработаны. Еще одна важность UML - помнить в будущем, как работает система и как ее модули взаимодействуют друг с другом, чтобы обеспечить масштабируемость проекта без появления огромных ошибок, которые могут быть бесконечными и серьезными. Таким образом, как письменный проектный документ, так и UML важны для любого среднего или крупного проекта.