Я не люблю MDD, но люблю UML - зачем мне использовать MDD, если я считаю его бесполезным?
Я разработчик / архитектор программного обеспечения Java, и мне нравится UML.
Сказать, что я также ненавижу сгенерированный Java-код.
Я не вижу никакой ценности в создании каркаса моего приложения:
- создавать пустые классы очень просто, и мне не нужен инструмент для этого
- также я не могу повторно использовать сгенерированный код, потому что способ, которым он генерируется, делает невозможным повторное использование
Дилемма для меня заключается в том, что мои требования менялись так быстро, что мне нужно было немедленно реализовать новое требование в существующем коде.
Моя проблема заключается в том, что если я сгенерирую свой код из своей модели, а затем вручную разрабатываю внутри сгенерированной кодовой базы, я не могу сгенерировать код снова, используя модель, потому что моя модификация будет удалена.
За исключением того, что я копирую / вставляю изменения туда и обратно. Это огромное усилие из-за слишком небольшого количества результатов. Поэтому я не использую MDD, но все еще использую много UML.
Может ли UML быть успешным в проекте без генерации кода MDD?
Я задаю этот вопрос, потому что у меня есть новый начальник, который хочет представить полный процесс MDD с IBM RSA, и сегодня я предпочитаю иметь живой код и синхронизацию модели или объединяться с Omondo.
- Зачем менять работающую и проверенную систему?
- Зачем систематически генерировать код из модели, тогда как я могу сделать это непосредственно в коде и просто объединить его позже с моделью?
- Зачем создавать генерацию кода для дерьмовой базы данных, которую невозможно развернуть, пока я могу добавить стереотип, чтобы получить аннотацию Java и использовать ее с Hibernate для создания моей базы данных?
Одна из причин смены начальника - получить лучшую проектную документацию в формате HTML. Я очень сомневаюсь в этом и думаю, что он ищет больше контроля над доставкой и не знает, что еще изобрести!
Другие аргументированные причины:
- Используйте продукт от большой и стабильной компании.
- Подготовьте полную модель, которую можно развернуть на любом другом языке.
(Вот почему для меня MDD глупо, потому что невозможно развернуть на любой платформе какой-либо сервер, любую базу данных только из модели. Так зачем тратить мое время?)
Пожалуйста, дайте мне несколько аргументов, чтобы вернуться на следующую встречу и разбить этого глупого нового поклонника MDD, который хочет реорганизовать нашу сегодняшнюю работу!
3 ответа
Я думаю, что ваш пост содержит ответ.
MDD страдает от 2 фундаментальных проблем:
- Ввод (язык моделирования), который недостаточно выразителен, чтобы охватить всю проблему. Результат: вам необходимо дополнить спецификацию другим языком (кодом).
- Генераторы - то есть правила, которые преобразуют модели в код - как правило, неполны и / или не открыты для модификации командой разработчиков и / или генерируют код низкого качества.
Соедините эти две вещи вместе, и вы получите ужасный беспорядок, который вы упомянули. Следствие: попытка соединить рукописный код с некачественным сгенерированным кодом. Результат: не симпатичный.
Тем не мение. Пожалуйста, не думайте сверху, что я против MDD. Я нет - на самом деле все наоборот. НО: инструментарий и процесс должны решать две фундаментальные проблемы, описанные выше.
Я сталкивался / очень / мало, что делают. Я использовал RSA несколько лет назад, и он определенно не был одним из них. (Тем не менее, у него было время для улучшения, поэтому оно может быть там сейчас).
Простой вопрос "проверки температуры" состоит в том, чтобы спросить, предоставляет ли инструмент полный язык действий. Если этого не произойдет, это приведет к фолу проблем (1). Если этого не произойдет, скорее всего, вам будет больно.
Если вашему боссу действительно нужна хорошая HTML-документация, просто интегрируйте UMLGraph или apiviz в свою сборку.
Итак, чтобы ответить на ваш конкретный вопрос:
Можно ли успешно использовать UML без MDD? Да. Обычно двумя способами:
- В качестве неформальной или полуформальной записи для эскизов на доске при выяснении проблемы и / или решения (то, что Мартин Фаулер называет UML Sketch)
- Как автоматически сгенерированная документация из кода как часть процесса сборки.
В конечном итоге вы теряете непродуктивное время, создавая формальные UML-диаграммы (часто с дорогим инструментом), которые не имеют прямой ссылки на код.
НТН.
Если вы не можете контролировать поколение, вы, вероятно, используете неправильные инструменты.
То, что вы генерируете - скелеты или специфичный для фреймворка код - также зависит от инструмента. Используйте инструменты, которые позволяют создавать свои собственные шаблоны.
Неправильно предполагать, что проектирование в обе стороны будет работать. Вы не можете преобразовать менее детальную модель в более детальный код и затем вернуться без потери информации. Одним из способов решения этой проблемы было бы иметь тот же уровень детализации в моделях, что и в коде, что не очень хорошая вещь.
Лучшим подходом является использование односторонней генерации из моделей в сочетании с некоторыми хорошими практиками для объединения сгенерированного и написанного вручную кода.
Вы можете использовать защищенные области для написанного вручную кода:
- Вы указываете в местах шаблона - например, тела метода, которые не должны быть перезаписаны при восстановлении
Или образец разрыва между поколениями:
- вы генерируете абстрактные классы и код, используя скелеты конкретных классов, которые вы заполняете вручную).
Есть еще один способ приблизиться к этому - генерация полного кода.
Это может выглядеть как плохая практика кодирования с использованием моделей, но дело в том, чтобы специализироваться на создании приложений определенного типа - веб-приложений, встроенных приложений. То, что вы генерируете, это, в основном, специфичный для фреймворка код, который часто можно выразить и поддерживать с помощью моделей.
Не забывайте, что моделирование - это не только диаграммы, вы также можете использовать текстовые DSL.
На ваш вопрос - UML изначально не предназначался для MDD (многие специалисты по MDD вообще не используют UML...), поэтому вы можете использовать его для ОО-анализа и проектирования по своему усмотрению.
Когда дело доходит до вашего босса и RSA, постарайтесь выяснить, что ваш босс действительно нуждается и хочет, а затем постарайтесь предоставить ему некоторые лучшие инструменты или методы.
Как уже упоминалось в другом ответе, существует множество инструментов для документации.
С MDD внесение изменений в дизайн, надеюсь, станет дешевле: если требования изменятся, в вашем подходе вы должны обновить документацию на основе UML и код. Теперь, если код может быть сгенерирован автоматически, изменения в коде должны автоматически следовать за изменениями в модели, и вам не придется делать это вручную (по крайней мере, в тех местах, где вы не добавляете новые вещи или нужно сменить бизнес логику).
Предполагая, что MDD работает (да, верно;), не могли бы вы оправдать двойную стоимость обслуживания модели (для документации и проектирования) и кода?
Один из аргументов в вашу пользу может заключаться в том, что если проект не слишком большой (что бы это ни значило), не стоит брать на себя все накладные расходы.