Модельно-ориентированный подход к разработке программного обеспечения (MDSD) обещает повышение скорости разработки и качества программного обеспечения за счет использования формальной модели в качестве основы для внедрения системы.
Особое внимание уделяется итеративному инкрементальному процессу MDSD и использованию общих промышленных инструментов и методов, интегрированных вместе, вместо полноценных рабочих столов MDSD.
В контексте теории MDSD концентрируется на двух темах: специфические для домена языки (DSL) и генерация кода. DSL работают с обработкой входных данных модели для представления в памяти. Генерация кода использует модель "в памяти" для генерации целевого кода.
MDSD в основном рассматривается с точки зрения крупномасштабной архитектуры программного обеспечения. Предполагается, что новая система или семейство систем будет реализована путем описания каждой существенной части и аспекта системы с использованием формальных моделей. Однако на практике это не всегда так. Когда разработка системы начнется, может не быть известно, что в будущем понадобится целое семейство продуктов. Поэтому заранее неясно, будет ли разработка на основе модели применима и что инвестиции в нее окупятся.
Конечно, в реальности MDSD можно рассматривать в меньшем масштабе, где на основе моделей генерируются только отдельные части системы. Как показывают последние исследования, большинство успешных проектов MDSD были разработаны именно таким образом.
В этом случае знание MDSD может быть полезным даже для одного программиста (или небольшой команды), работающего над частью системы и внедряющего MDSD, не требует значительных изменений в архитектуре системы в целом.
MDSD часто ассоциируется с интегрированными инструментами моделирования или рабочими столами языков. Эти инструменты включают в себя разработку мета-модели, специфического для конкретной области языка, используемого для выражения моделей, и генератора, который воспроизводит работоспособный код на основе модели. Однако эти инструменты зачастую являются сложными и требуют больших затрат на обучение.
Что еще важно, использование таких инструментов создает риск блокировки поставщика. Хотя интегрированные инструменты могут быть полезны во многих ситуациях, они не обязательно требуются в рамках подхода, основанного на моделировании.
Можно использовать набор независимых инструментов для отдельных частей инфраструктуры разработки на основе модели. Такой подход обеспечивает свободное сцепление и гибкость при выборе инструментов.
MDSD требует специального процесса разработки программного обеспечения.
Считается, что подход, основанный на моделировании, требует использования специального процесса разработки программного обеспечения, в котором мета-модель и язык моделирования должны быть полностью определены и реализованы, прежде чем модель системы может быть разработана. Это мнение делает MDSD настолько же негибким и несовместимым с динамичными процессами разработки, которым отдается предпочтение в настоящее время.
Однако инфраструктуру моделирования можно развивать итеративно, и этот подход успешен в промышленной практике. Мета-модель, языковой процессор и генератор могут развиваться вместе с остальной частью системы.
Использование мелкомасштабных MDSD и простых инструментов значительно упрощает такой итеративный процесс разработки и позволяет использовать MDSD с общими гибкими методологиями.
Без понимания этого вопроса представляется, что MDSD не является широко используемым подходом на практике. В действительности, подходы, основанные на моделировании и генерации, распространены и даже считаются хорошей практикой для прагматичного программирования. Большинство примеров, однако, представляют собой небольшие приложения MDSD, которые включают в себя:
● Генераторы схем баз данных (например, DOMMLite или инструменты рефакторинга баз данных) и код объектно-реляционного картирования (ORM) из описания структуры данных (используется в различных инструментах ORM).
● Генераторы кода для доступа к веб-сервисам на основе описания WSDL.
● Инструменты для графического проектирования пользовательских интерфейсов, генерирующие код в соответствии с графическим представлением пользовательского интерфейса (например, для бизнес-приложений).
● IDE плагины для конкретных технологий, способных генерировать скелеты повторяющихся артефактов (например, GWT плагин для IntelliJ Idea, генерирующий стандартные сервисные артефакты GWT RPC).
● Генеративная структура Spring Roo, позволяющая реализовать пользовательские генераторы кода для различных повторяющихся артефактов кода (в настоящее время публикуемые генераторы ориентированы на область применения CRUD на основе веб-технологий).
Более того, приложение MDSD часто скрывается от программиста библиотеками и фреймворками, что позволяет задавать поведение с помощью модели, не зная деталей обработки модели.
В случае динамических языков, таких как Ruby, для описания моделей могут быть использованы внутренние специфические для домена языки, а генерация кода может быть заменена на модификацию программы во время выполнения с использованием отражения. Такой подход делает использование MDSD еще менее очевидным.
Поколение приложений CRUD было разделено на следующие четыре части, которые соответствуют вышеупомянутым итерациям:
1. Простая генерация уровня данных. Генерируемые артефакты - это классы для объектов данных (например, класс Patient в случае применения CRUD в домене), простые интерфейсы DAO, реализации DAO и сценарий создания таблицы базы данных SQL. Решение этой итерации не может создать целую систему, но может создать загрузочный уровень данных для приложения CRUD.
2. Поддержка в преодолении организационных ограничений. Объекты-субъекты, которые обрабатываются приложениями CRUD, должны быть проверены на соответствие правилам домена. Эта итерация обогащает реализацию DAO для проверки объектов объектов перед их сохранением в базе данных.
3. Ссылки между субъектами. Третья итерация снова добавляет сгенерированный код на уровень данных и бизнес-уровня. Первые две итерации поддерживали простые сущности. Это позволяет наладить отношения между ними, вводя ссылки.
4. И, наконец, четвертая итерация представляет собой консольный пользовательский интерфейс. Это включает в себя несколько новых артефактов исходного кода. Во-первых, создается меню для взаимодействия с приложением, показывающее опции для каждого субъекта, с которым работает приложение. Затем для каждой сущности имеется таблица, в которой представлены все экземпляры и форма для редактирования и создания экземпляров.
