Документы дизайна против UML или оба? - PullRequest
5 голосов
/ 01 марта 2010

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

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

Ответы [ 4 ]

3 голосов
/ 01 марта 2010

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

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

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

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

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

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

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

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

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

2 голосов
/ 01 марта 2010

Я бы ответил:

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

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

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

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

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

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

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

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

0 голосов
/ 28 мая 2014

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

...