Создавать UML-диаграммы после или перед кодированием?
Я ясно вижу преимущества наличия UML-диаграмм, показывающих вашу инфраструктуру приложения (имена классов, их члены, как они общаются друг с другом и т. д.).
Я начинаю новый проект прямо сейчас и уже структурировал базу данных (с визуальной парадигмой). Я хочу использовать некоторые шаблоны проектирования, чтобы направлять меня, как кодировать классы.
интересно, должен ли я сначала кодировать классы, прежде чем создавать диаграмму UML (возможно, из кода... кажется возможным) или я должен сначала создать диаграмму UML, а затем код (или создать код из UML, кажется возможным, что тоже).
какой у вас опыт говорит вам, что это лучший способ?
8 ответов
важно то, что вы думаю, до, во время и после кода. Если UML помогает вам сделать это, вы должны использовать его. В зависимости от программы, которую вы пишете, вы можете сосредоточиться на алгоритмах, архитектуре или пользовательском интерфейсе перед написанием кода.
еще до того, как вы начнете думать о как вы должны написать программу, вы также должны думать о что вы должны программировать. Опять же, такая программа, как вы написание диктует, о чем именно вы должны думать.
Я всегда создаю их во время разработки. Но это личное предубеждение.
следующая итеративная разработка, например, означает, что ваш код будет развиваться по мере продвижения проекта. Поэтому создание UML-диаграмм - пустая трата времени, так как через некоторое время ваш конечный результат будет ничем не похож на диаграммы, с которых вы начали. Даже при итеративной разработке такие вещи, как тестовая разработка, не препятствуют UML-диаграммам. Во время процесса планирования / проектирования для история / задача, UML-диаграммы могут пригодиться. Однако это не означает, что вы должны слепо писать UML для каждого фрагмента кода, который вы пишете.
напротив, диаграммы UML позволяют выражать большие идеи другим разработчикам в нескольких простых изображениях. Из диаграмм другие разработчики могут понять, как связаны приложение/компоненты.
вам лучше использовать UML-диаграммы в качестве инструмента, а не средства, на мой взгляд. Имея промышленный опыт, я могу заверить вас, что просто потому, что книги говорят вам писать UML / выполнять обширный дизайн, прежде чем писать какой-либо код, он очень редко, если вообще, работает так.
Я думаю, что для целей документации UML-диаграммы близки к бесполезным, так как их обновление практически невозможно. Однако я думаю, что они являются хорошими инструментами до и на начальных этапах разработки для обдумывания дизайна, а также его рассмотрения с другими членами команды. Поэтому мой ответ будет немного раньше немного на начальных этапах и не так много после этого.
Я делаю модель (когда я делаю ) перед кодированием, с карандашом и бумагой, но я не делаю 3 недели диаграммы или что-то в этом роде. Просто, 1 день или каждая итерация начинается.
тратить время в инструменте построения диаграмм является одним из самых смешных способов потерять ценное время кодирования ( IMHO ) .
использование карандаша / бумаги и камеры мобильного телефона оказалось полезным в прошлом.
Это всегда хорошая практика, чтобы иметь дизайн, прежде чем начать. Определяется ли этот дизайн как UML-диаграммы или где-то еще, не имеет значения. Вопрос, какой уровень детализации вам нужен ?
Если в среде, в которой вы работаете, вам нужен обзор дизайна Перед началом, вам понадобятся UML-диаграммы. Они должны быть достаточно полными, чтобы передать то, что вы собираетесь делать.
каждое место, где я работал в последнее время, требует диаграмм UML в качестве подлежащий доставке. Что я делаю, так это создаю некоторые базовые, а затем изменяю их в конце, обычно путем обратной разработки кода.
Я не профессионал и использую UML только в ограниченном объеме в своих личных проектах. Мой опыт в попытке использовать UML строго перед кодирование имеет тенденцию отправлять мои личные проекты в яму отчаяния. Я думаю, что это связано с попыткой схематизировать идеи, которые еще не существуют или не изучены должным образом.
они скажите: "картина стоит тысячи слов". Моя интерпретация этого заключается в том, что вы должны иметь идею в виду (или в словах), прежде чем вы рисуете картину. Художник не рисует картину заката, а затем решает нарисовать картину заката. Все наоборот.
схемы являются инструмент документации. Документация всегда в прошедшем времени, то есть любая документация касается решений, которые вы приняли в прошлом. По своему опыту я знал, что лучше документировать свои идеи в письменном виде, а потом рисовать диаграммы. Как и художнику, вам нужно решить, что вы рисуете, прежде чем вы сможете диаграмма. Если вы не знаете, какую идею вы выражаете, как вы рисуете ее картину?
диаграммы вариантов использования, например, являются иллюстрацией вашего решения о том, какую функциональность пользователь должен ожидать от вашей системы. Диаграммы классов-это графическое изображение вашего решения о структуре классов вашей программы и их отношениях друг с другом.
в случае диаграмм классов выбор существительных из требований и создание диаграммы неэффективны. Как вы знаете, действительно ли эти классы поддерживают функциональность, необходимую для поддержки вариантов использования? Изучение системы, разделение идей на модули, запись решений о взаимодействии модулей и запись некоторых начальных классов (или, по крайней мере, их интерфейсов) укрепляют ваши идеи. Документирование этих идей на диаграмме просто облегчает людям быстрое понимание принятых вами решений.
Если вы делаете диаграмму базы данных, скажем, для системы закупок, вы должны сделать решение это ордер много позиции прежде чем вы создадите диаграмму, показывающую это.
на самом деле я пытаюсь сказать, что я думаю, что диаграммы в прошедшем времени, как и вся документация. У вас есть идея; вы записываете ее, и это документация. У вас есть документация; вы рисуете картину, чтобы было легче понять. Я думаю, что лучше создавать диаграммы после того, как вы проанализировали проблему и создали ментальную и письменную модель. Ли ты постепенно добавьте к диаграмме после принятия каждого решения или постройте полную диаграмму после принятия нескольких решений. Составление диаграмм для идей до того, как вы их получите, или до того, как вы их поймете, Я думаю, ведет только к страданиям.
what are you experiences telling you is the best way?
я моделирую в UML, и если дело доходит до интерфейсов, классов и диаграмм последовательности, то удобнее использовать IDE и объявлять их, а также выполнять проектирование туда и обратно и видеть, что все эти методы и атрибуты появляются в диаграммах UML.
слишком утомительно объявлять все в инструменте UML.
только мое мнение.
лучше всего позволить пользователям делать то, что они хотят. Я имею в виду, если они хотят сначала смоделировать базу данных, а затем смоделировать приложение, вам нужно преобразовать вашу базу данных в код, а затем обратить ваш код в UML. Если вы хотите сначала смоделировать, а затем создать код и базу данных, вам нужно создать диаграммы, а затем использовать генераторы кода. Если вы хотите моделировать и код одновременно с синхронизацией кода любви и модели, вы можете использовать инструменты Hibernate для сопоставления вашего дизайна с базой данных как только концепция будет завершена.
обычный цикл UML должен моделировать, а затем генерировать код с использованием технологий MDD. Я предпочитаю итерационный подход, но кроме Omondo UML другие инструменты предпочитают использовать MDD, а не короткие циклы итерации UML. Не знаю почему, но ......