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