В настоящее время я сталкиваюсь с ситуацией, когда мне, как стороннику разработки, управляемой тестами, приходится конкурировать с защитником разработки программного обеспечения на основе моделей (MDSD) / архитектуры на основе моделей (MDA).

На мой взгляд, генерация кода является ценным инструментом в моем наборе инструментов, и я интенсивно использую шаблоны и автоматизацию, когда это необходимо. Я также создаю диаграммы в UML, когда думаю, что это помогает понять внутреннюю работу или обсудить архитектуру на белой доске. Однако я сильно сомневаюсь, что создание программного обеспечения через UML (создание диаграмм состояний и диаграмм последовательности для создания рабочего кода, а не только скелетов кода) более эффективно для многоуровневых приложений (уровень базы данных, уровень бизнеса / домена и графический интерфейс пользователя, возможно, даже распределенный). Мне кажется, что когда дело доходит до MDSD, инструмент CASE неожиданно перестает быть просто инструментом, но его нужно удовлетворить: как мне кажется, с одной стороны, MDSDevelopers извлекает выгоду из более высокой абстракции, которую дает им UML, но при в то же время они борются с модификацией генератора кода / шаблона / движка, чтобы полностью удовлетворить свои потребности, которые могут быть легко реализованы (и протестированы), если использовать другой инструмент из своего набора инструментов (VisualStudio, Eclipse, ...).

Все это заставляет меня задуматься о том, была ли история успеха (если, конечно, продукт был развернут вовремя, в рамках бюджета и только с несколькими ошибками, и части программного обеспечения были повторно использованы позднее) для реального приложения, которое полностью заполняет этот creteria и был разработан с использованием строгого модельно-ориентированного подхода:

это не имеет ничего общего с Группой управления объектами (OMG) или с консультантами, связанными с MDSD / MDA / SOA /приложение не относится к моделированию бизнес-процессов и не является инструментом CASEприложение активно используется конечным пользователемон имеет как минимум три уровня, включая пользовательский интерфейс, который выходит за рамки отображения необработанных табличных значений и не является одним из распространенных примеров MDA / MDSD («как моделировать кофемашину, светофор, посудомоечную машину»).