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

Question

Я ясно вижу преимущества наличия диаграмм UML, показывающих вашу инфраструктуру приложения (имена классов, их члены, то, как они общаются друг с другом и т. Д.).

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

Интересно, должен ли я сначала кодировать классы, прежде чем создавать UML-диаграмму (возможно, из кода ... кажется возможным), или мне следует сначала создавать UML-диаграмму, а затем кодировать (или генерировать код из UML, кажется возможно это тоже).

Что, по вашему опыту, говорит вам, что это лучший способ?

Answer 1

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

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

Answer 2

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

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

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

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

Answer 3

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

Answer 4

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

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

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

Answer 5

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

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

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

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

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

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

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

Answer 6

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

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

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

Answer 7

what are you experiences telling you is the best way?

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

Слишком утомительно объявлять все в инструменте UML.

Только мое мнение.

Answer 8

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

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