Что вы думаете о разработке программного обеспечения на основе моделей?

Question

Мне действительно интересно услышать, что вы думаете о разработке программного обеспечения на основе моделей для Java и / или .NET.

Экономит ли это время? Это улучшает качество?

Answer 1

Я использую MDSD в проекте с IBM Rational Rhapsody для C ++. Модель довольно близка к UML, поэтому там у нас нет предметно-ориентированного языка. Но все же я бы утверждал, что использовать MDSD. По моему опыту, есть много преимуществ с MDSD:

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

б) Большая документация с изображением ПО, как правило, лучше с MDSD. Конечно, есть инструменты, которые автоматически генерируют диаграмму классов из вашего кода. Но эти диаграммы состоят из 1000 классов, и вы не видите аспект интереса. С MDSD вы специально рисуете один аспект системы, и та же самая диаграмма также используется для генерации части вашего кода.

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

d) Использование MDSD помогает придерживаться принципов стиля кодирования. Нет лучшего способа получить согласованный стиль кода, чем позволить генерировать код с помощью набора правил.

Конечно, есть и некоторые недостатки MDSD: г) Если у вас есть модель, вы хотите, чтобы каждая строка кода исходила от этой модели. И может быть трудно включить внешние библиотеки в проект. Так что либо вы живете с тем фактом, что ваша система основана на внешних компонентах, либо вы заново изобретаете колесо, чтобы включить его в свою модель.

e) У инструментов моделирования могут возникнуть проблемы с использованием инструментов управления версиями. Исходный код обычно проще объединить, чем диаграмму модели. Это вынуждает команду перейти от рабочего процесса копирования-редактирования-слияния к рабочему процессу блокировки-редактирования-слияния.

Answer 2

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

Я видел нечто, похожее на доменный дизайн, называемое MDA, если вы имеете в виду, что я все за него: -)

Answer 3

Гул.

Во что я верю, OTOH, это моделирование во время выполнения. Вместо генерации кода поддерживайте модель во время выполнения, и пусть ваше приложение будет интерпретатором этих моделей во время выполнения.

Я не знаю, было ли это сделано для Java. Для Smalltalk см. Magritte , который используется в Приморском.

Answer 4

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

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

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

Answer 5

Я думаю, что это предпочтительнее. Это то, что я пытался на указать о MVC-ARS, а не MVC. ARS (действие / представление / состояние) содержится в модели в соответствии с проектом и предотвращает перегрузку контроллера или представления.

Answer 6

Просто добавьте две книги, которые я нашел полезными для понимания MDA, как сказано выше, это широкая тема.

• MDA Distilled - Принципы модельно-управляемой архитектуры. (Меллор)
• Реальный MDA: решение проблем бизнеса с модельно-управляемой архитектурой (Гутман)

Вам не нужно читать весь Гутман, чтобы понять эту идею, поскольку тематические исследования становятся скучными, но вступление было приятно читать.

Answer 7

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

Тем не менее я не видел такого мощного инструмента MDA, как Forté (или UDS, теперь уже мертвый) + Express. Я полагаю, что MDA с возможностями Forté и более совершенным шаблоном для достижения независимого уровня обслуживания (как шаблоны ActiveRecord или EntityTransactionManager) может стать убийственным приложением для любой платформы.

Проблема с фактическим применением, нацеленным на трехуровневый подход MDA, заключается в том, что их очень сложно настроить и адаптировать к конкретным требованиям. Просто подумайте о ставках ABAP и SAP

Answer 8

Это звучит хорошо, но я еще не видел, чтобы это было реализовано в практической манере.

Я держу это так: Код - это модель. Таким образом, ваша модель и ваш код всегда в курсе: -)