Создать UML-диаграммы после или после кодирования?

Ответ 1

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

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

Ответ 2

Я всегда создаю их во время разработки. Это личное уклонение, хотя.

После итеративной разработки, например, ваш код будет развиваться по мере продвижения проекта. Поэтому создание диаграмм UML спереди является пустой тратой времени, так как через некоторое время ваш конечный результат будет ничем иным, как диаграммы, с которых вы начали. Даже при итеративном развитии такие вещи, как Test-Driven Development, не препятствуют диаграммам UML. В процессе планирования/проектирования для истории/задачи диаграммы UML могут пригодиться. Однако, чтобы не сказать, что вы должны вслепую писать UML для каждого фрагмента кода, который вы пишете.

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

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

Ответ 3

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

Ответ 4

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

Время простоя в инструменте диаграмм является одним из самых смешных способов потерять ценное время кодирования (IMHO).

Использование карандаша/бумаги и камеры сотового телефона оказалось полезным в прошлом.

Ответ 5

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

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

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

Ответ 6

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

Говорят, что "картина стоит тысячи слов". Моя интерпретация этого заключается в том, что вы должны иметь представление о мысли (или на словах), прежде чем нарисовать ее. Художник не рисует картину заката, а затем решает нарисовать закат. Это наоборот.

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

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

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

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

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

Ответ 7

what are you experiences telling you is the best way?

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

Это слишком утомительно, чтобы объявить все в инструменте UML.

Просто мое мнение.

Ответ 8

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

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