Должны ли вы создавать диаграммы классов до или после реализации?

11

Как я вижу, если вы создадите его, прежде чем получите преимущество:

  • Планирование наперед
  • Обзор проекта

но ты проиграл

  • Время (выполняя работу, которую вы, вероятно, будете повторять при написании кода)

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

Какой из них служит целям диаграмм классов, а какой является более выгодным?

Jonn
источник
2
Вопрос может быть: «Стоит ли вообще создавать диаграммы классов?». В противном случае, смотрите ответ Лоренцо :)
Хайлем

Ответы:

9

Если вы создадите их раньше, они будут частью этапа проектирования.

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

Кстати, вы не теряете время на занятие дизайном! Часть кодирования будет быстрее. И лучше.

В конце концов, вы думаете, что проектирование небоскреба или моста - это потеря времени, а не просто его строительство?

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

Wizard79
источник
Начните кодировать только с идей, которые вы имеете в виду на тот момент, которые могут ввести в заблуждение всю вашу команду разработчиков. Вам необходимо написать хотя бы первоначальный проект, а затем улучшить его по мере необходимости в процессе разработки. Таким образом, вся команда знает, куда они направляются.
Луис Агилар
12

Когда я их создал до кодирования, мы рассматриваем их как «временные» документы. То есть мы создаем диаграммы и переносим свои мысли на бумагу. Мы начинаем кодирование с этих диаграмм классов. Затем мы выбрасываем их. Не стоит тратить время на их поддержание после начала кодирования. А если вам нужны современные модели классов, используйте инструмент для их создания из кода.

Джефф Сивер
источник
4

В любом случае они останутся как часть документации. Никто не будет обновлять их при внесении изменений в реализацию. На диаграммах не будет дат, поэтому вы даже не будете знать, на какую версию кода они ссылаются. Когда в проект добавляется новый человек, вы даете ему или ей диаграммы с надписью «Вот некоторые диаграммы, которые были созданы в какой-то момент в процессе проектирования или реализации. Мы не знаем, насколько они актуальны».

Марк Луттон
источник
3
Это происходит с документацией в целом. Я недавно начал новую работу, и они дали мне пачку устаревшей документации. И что еще хуже, я все еще должен документировать все, что я делаю.
Корбин
3

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

Обеспечение дизайна после реализации - это то, что я бы назвал «ковбойским кодированием», и уверен, что вы можете процветать на диком диком западе, но помните, что ковбои обычно оказываются мертвыми в тот или иной момент.

Крис
источник
3

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

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

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

Мэтт Оленик
источник
1

До реализации. Как сказал один из моих бывших коллег: «Мне нравится заниматься как можно большим количеством программ, прежде чем я начну программировать», и я думаю, что это хороший подход к этому.

GSto
источник
1

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

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

Кейт Грегори
источник
1

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

В моем последнем проекте лица, принимающие решения, меняли мои требования более 50 раз за последний год. Это действительно больно, и UML помогает мне следить за изменениями и почему. UML должен позволять моделирование и слияние кода в любое время итеративным способом (например, из кода в модель, из модели в код, из обоих, из кода после рефакторинга и т. Д.). Я использую Omondo EclipseUML для Helios, и я действительно доволен этот инструмент. Моя любимая функция - это слияние моделей, которое позволяет мне обновлять мою модель в любое время без потери информации о модели. Мне также нравится моделирование сущностей непосредственно в диаграмме классов и создание базы данных с использованием стереотипа и гибернации. Действительно мощный и полный от объекта к базе данных!

UML_GURU
источник
1

До : это поможет вам организовать ваши мысли и сообщить о ваших намерениях. Не вдавайтесь в подробности здесь.

После : он автоматически генерируется из кода как часть процесса сборки, очевидно (надеюсь, вы не слишком привязаны к uml)

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

Матье М.
источник
0

С Topcased я создаю свои диаграммы классов на этапе проектирования. Затем я нажимаю кнопку «Создать код» для создания холста моей реализации. Затем я заполняю заполнители кодом.

mouviciel
источник
0

Я собираюсь голосовать за ответ (С) Не беспокойтесь.

Они в основном не нужны. Лично я никогда не смотрю на них, когда они предоставляются.

Они не нужны перед разработкой, потому что дизайн все равно изменится. И если вы не думаете, что дизайн ваших классов изменится, то вы уже надеваете на себя наручники и не позволяете своему будущему «я» правильно решить проблему. Если вы думаете, что должны придерживаться каких-то уже существующих диаграмм классов, то вы либо работаете в НАСА, либо стреляете себе в ногу.

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

Конечно, этот ответ звучит очень высокомерно и самоуверенно; Ну что ж.

Крис Холмс
источник
0

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

Грег Домян
источник