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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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