Что вы думаете о разработке программного обеспечения на основе моделей?
Мне действительно интересно услышать, что вы думаете о разработке программного обеспечения на основе моделей для Java и / или.NET.
Это экономит время? Это улучшает качество?
8 ответов
Я использую MDSD в проекте с IBM Rational Rhapsody для C++. Модель довольно близка к UML, поэтому там у нас нет предметно-ориентированного языка. Но все же я бы утверждал, что использовать MDSD. Из моего опыта, есть много преимуществ с MDSD:
а) Использование MDSD помогает вывести архитектуру программного обеспечения на сложный уровень. Вы всегда работаете на очень абстрактном уровне, думая о большой картине. Программному обеспечению для ковбойского кодирования обычно не хватает хорошей архитектуры, потому что разработчик застрял в деталях. С MDSD я вижу тенденцию в своей работе решать проблемы с помощью классов соответствующего размера, хороших шаблонов или просто лучшего кода.
б) Большая документация с изображением ПО, как правило, лучше с MDSD. Конечно, есть инструменты, которые автоматически генерируют диаграмму классов из вашего кода. Но эти диаграммы состоят из 1000 классов, и вы не видите аспект интереса. С MDSD вы специально рисуете один аспект системы, и та же самая диаграмма также используется для генерации части вашего кода.
в) Моделирование помогает справиться с присущей системе сложностью. Я бы сказал, что некоторые системы слишком сложны, чтобы их можно было создавать без поддержки со стороны компьютерного проектирования. Никто не будет проектировать процессор без помощи огромных программных инструментов. Используйте SW, чтобы помочь вам написать еще более сложный SW.
г) Использование MDSD помогает придерживаться принципов стиля кодирования. Нет лучшего способа получить согласованный стиль кода, чем позволить сгенерировать код с помощью набора правил.
Конечно, есть и некоторые недостатки MDSD: d) Если у вас есть модель, вы хотите, чтобы каждая строка кода исходила от этой модели. И может быть трудно включить внешние библиотеки в проект. Так что либо вы живете с тем фактом, что ваша система основана на внешних компонентах, либо вы заново изобретаете колесо, чтобы включить его в свою модель.
e) У инструментов моделирования могут возникнуть проблемы с использованием инструментов управления версиями. Исходный код обычно проще объединить, чем диаграмму модели. Это вынуждает команду перейти от рабочего процесса копирования-редактирования-слияния к рабочему процессу блокировки-редактирования-слияния.
MDA - это немного перегруженная концепция. Иногда это означает превращение UML или диаграмм другого типа в исполняемый код. Я никогда не видел, чтобы это работало хорошо с инструментами, доступными в настоящее время. Обычно это приводит к тому, что проекты получают результаты очень быстро, а затем вызывают кошмар обслуживания, потому что доступные инструменты на самом деле не поддерживают большие команды, работающие над визуальными диаграммами, и потому, что люди начинают работать с диаграммами и сгенерированным кодом.
Я видел что-то похожее на доменно-ориентированный дизайн, называемый MDA, если вы имеете в виду, что я все для этого:-)
Гул.
Во что я верю, OTOH, это моделирование во время выполнения. Вместо генерации кода поддерживайте модель во время выполнения и позвольте вашему приложению быть интерпретатором этих моделей во время выполнения.
Я не знаю, было ли это сделано для Java. Для Smalltalk см. Магритт, который используется в Приморском.
Разработка программного обеспечения на основе моделей - это не только MDA, существует ряд других подходов, в том числе, возможно, более популярный подход к предметно-ориентированным языкам.
Конечно, код представляет собой модель "а", но захват модели более высокого уровня в DSL является еще более кратким способом выражения того же намерения. Ключ должен всегда генерировать ваш код из модели, а не разрешать независимую модификацию сгенерированного кода.
Доступно множество инструментов и множество опубликованных материалов, в том числе тематические исследования, которые расскажут вам, как создать свои собственные генераторы, если вы недовольны приобретением готового генератора. Возможно, это дает вам больше контроля, чем работа с универсальным языком программирования.
Я думаю, что это предпочтительнее. Это то, что я пытался указать на этот вопрос о MVC-ARS, а не MVC. ARS (действие / представление / состояние) содержится в модели в соответствии с проектом и предотвращает перегрузку контроллера или представления.
Это, конечно, звучит хорошо, но я еще не видел, чтобы это было реализовано на практике.
Я держу это так: Код - это модель. Таким образом, ваша модель и ваш код всегда в курсе:-)
Просто добавить две книги, которые я нашел полезными для понимания MDA, как было сказано выше, это широкая тема.
- MDA Distilled - Принципы модельно-управляемой архитектуры. (Меллор)
- Реальный MDA: решение проблем бизнеса с модельно-управляемой архитектурой (Гутман)
Вам не нужно читать весь Guttman, чтобы понять, как учебные примеры становятся скучными, но вступление было приятно читать.
MDA обычно затрудняет интеграцию бизнес-правил внутри уровня сервера, поскольку отображение представления модели обрабатывается сгенерированным кодом, а функциональные перехватчики предоставляются в качестве ответчиков на события.
Тем не менее, я не видел такого мощного инструмента MDA, как Forté (или UDS, уже мертвый) + Express. Я полагаю, что MDA с возможностями Forté и более совершенным шаблоном для достижения независимого уровня обслуживания (как шаблоны ActiveRecord или EntityTransactionManager) будет убийственным приложением для любой платформы.
Проблема с фактическим применением, нацеленным на трехуровневый подход MDA, заключается в том, что их очень сложно настроить и адаптировать к конкретным требованиям. Просто подумайте о ставках ABAP и SAP