Поэтому, когда я учился в университете, я узнал о преимуществах UML и его будущем в разработке кода.

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

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

Но когда я смотрю на Visio и Enterprise Architect, кажется, что у них много разных типов графиков, фигур, объектов свойств, большинство из которых я не использую.

Люди используют UML для выполнения более сложных задач, таких как генерация кода или базы данных?

Да, инструменты UML CASE были одним из самых популярных предметов 90-х годов ... и затем не смогли доставить.

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

Единственное потенциальное исключение из этого, о котором я знаю, это диаграммы Entity-Relationship, которые не включают в себя код как таковой, только (как следует из их названия) фрагменты данных и их взаимосвязи. Но я никогда не слышал об успешной попытке использовать какие-либо UML-диаграммы для генерации реального кода [Обновление], т. Е. Больше, чем скелеты классов и тривиальный код, такой как геттеры / сеттеры, - за исключением специальных инструментов / областей, таких как ORM, что подтверждается Док Браун ниже [/ Update] , и я думаю, что это не случайно.

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

Поэтому, когда я был в универе (некоторое время назад), мне сказали, что будущее за UML, UML заменит программирование, а мы будем просто генерировать код из диаграмм и т. Д.

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

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

НЕТ

Легенда была основана на ошибочном предположении, что написано:

class ClassName extends SomeThing
{

}

... это сложно и нуждается в автоматизации .

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

Был там, не нашел это слишком полезным.

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

В одном проекте мы должны были разработать код в UML modeller (Rhapsody) и сгенерировать его оттуда. Это работало и, вероятно, было немного легче, чем печатать заголовки (это был C ++) и прототипы вручную. Способность автоматически поддерживать эти два параметра была несколько полезной.

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

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

Хотя конечно можно генерировать код (и даже целые системы) прямо из моделей UML, я никогда не сталкивался с его использованием таким образом.

По моему опыту, большинство компаний, кажется, используют его как средство коммуникации для требований или «MS Paint для рисования диаграмм».

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

все это (диаграммы моделирования) для коммуникационных целей

Моделирование имеет 4 важных использования в процессе разработки программного обеспечения:

1. Интегрированный инструмент дизайна

2. Инструмент связи

3. Помощь в создании программного обеспечения

4. Способ уменьшить сложность проблемы с реальными словами (я узнал об этом из ответа @kevin cline выше)

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

Моделирование, на мой взгляд, жизненно важно для построения баз данных (диаграммы ER), понимания потоков процессов (диаграммы деятельности) и понимания взаимодействия пользователя с системой (диаграммы вариантов использования).

Люди используют UML для выполнения более сложных задач, таких как генерация кода или базы данных?

Да, в самом деле. ERD (не диаграмма UML) и диаграммы классов могут использоваться (в зависимости от возможностей вашего инструмента) для генерации:

1 - язык определения данных (DDL)

2 - Хранимые процедуры для CRUD и диаграмм классов на предпочитаемом вами языке (менее полезны, поскольку инструменты ORM делают больше с этим)

Среди наиболее ценных функций инструментов моделирования:

1 - Возможность сохранить целостность модели. Если вы делаете изменение, оно распространяется в модели

2 - Возможность ответить на вопросы, где используются (где «учетная запись» используется в моей модели?)

3 - Возможность одновременной работы пользователей над моделью

4 - Поиск в графических представлениях

5 - Контроль печати

6 - Слоистость (организуйте элементы диаграммы по слоям), чтобы вы могли сосредоточиться на послойно

7 - Генерация кода базы данных для нескольких систем баз данных

8 - Проверка модели (проверка согласованности, отсутствующих ключей, циклов и т. Д.)

Таким образом, инструменты моделирования, особенно хорошие, делают намного больше, чем Paint.

Мы используем Software Architect для создания высокоуровневых проектов и для документирования некоторых более загадочных взаимодействий компонентов в наших материалах. Иногда мы генерируем скелет приложения из диаграмм, но как только это будет сделано, мы поддерживаем оба этих компонента по отдельности, мы не пытаемся преобразовать код обратно в диаграмму после ее завершения. Раньше я использовал инструмент под названием Rational XDE, который довольно хорошо работал для небольших программ, но он потерялся, когда вы начали добавлять обработчики событий Swing или пытались работать со Struts.

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

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

В своем последнем проекте я использую UML-Lab (https://www.uml-lab.com). Это хороший инструмент, который позволяет модели реверсировать. Инструмент генерирует Java-код и даже аннотации JPA, которые достаточно точны.

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

Это первый раз, когда я увидел, как продукт выполняет моделирование объектов и данных одновременно, а также генерацию кода.

В противном случае в моих прошлых проектах я всегда видел устаревшие модели, которые неточны или слишком подробны.

В моих прошлых проектах я иногда генерировал диаграммы с помощью реверс-инжиниринга. Большую часть времени я обнаружил, что диаграммы загромождены, и я предпочел рисовать их вручную, фильтруя весь шум.

Я думаю, что мы можем использовать UML для генерации кода. Не бизнес-логика, так как бизнес-логика не является стандартом и варьируется от приложения к приложению. Диаграммы классов вместе с диаграммами ER могут использоваться для генерации интерфейсов, классов, спящих объектов, базовых методов dao и т. Д. С помощью биграмм объектов также можно генерировать другой шаблонный код, такой как реализация фасада, преобразователи типов данных (например, объект для передачи объектов). ,

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

Используя OAW и инструмент моделирования, такой как Enterprise Architect, мы можем создавать более мощные генераторы кода, которые могут даже помочь в создании файлов конфигурации, заводского кода с использованием стереотипов и теговых значений.

Я до сих пор не понимаю, почему бизнес-аналитика с такими инструментами, как Business Object, способна анализировать и использовать преимущества всей информации компании, в то время как на технологическом уровне мы все еще работаем только на уровне кода или на абстрактном уровне с UML !!

Проблема не в UML, а в преобразовании модели между UML и MOF и генерации кода из классической диаграммы или из xmi с использованием шаблонов. Говорят, что UML дает абстрактное представление о реальном мире, поэтому вы видите только то, что действительно важно. Сказав это, как генерировать точный код, если UML-диаграмма - это просто представление о реальном мире? Это невозможно, и поэтому разработка, основанная на модели, которая генерирует код из модели, не удалась.

Решение заключается в преобразовании для отображения реального мира и, следовательно, всего кода проекта в одну модель UML. Имея единую модель и полную логику проекта, вы можете каждый раз генерировать представления из модели, а не из кода. Omondo выдвигает смелую инициативу в рамках технологии Java / Jee. Идея состоит в том, чтобы напрямую синхронизировать MOF и UML с кодом и ORM. Диаграмма UML теперь является просто представлением высокого уровня модели, которая отображает весь проект. Вы можете создать сотни просмотров, добавить сотни заметок и т. Д., Чтобы лучше понять проект. Код будет сгенерирован, только если элемент изменен или создан. Удивительная технология, в которой идентификатор Java отображается на идентификатор UML без традиционного моста преобразования между MOF и UML.

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

Я никогда не разочаровывался UML в качестве средства просмотра высокого уровня, если в реальном времени выполнял синхронизацию с кодом, но он был абсолютно разрушен традиционным использованием MDA с генерацией кода в шаблонах разработки, управляемых моделями. Генерация кода из модели похожа на HTML-страницу из текстового документа. Как изменить его, когда он генерируется? Обновление просто невозможно, и вы тратите больше времени на очистку кода, чем на запись с нуля!