Инструменты (лучшие практики?) Для разработки на основе моделей?

Question

Разработка программного обеспечения на основе моделей.

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

Связь между экспертами в области (заказчиком) и разработчиками имеет решающее значение для работы этой методологии. То, что я хочу знать, есть ли набор инструментов или набор лучших практик, которые помогут в начальной стадии MDSD? Как только домен станет понятным, как насчет отображения этой модели в ORM (или что-то еще)?

Я просто погружаюсь в сферу MDSD и DSL, поэтому любые конструктивные идеи или комментарии будут оценены.

Answer 1

Если вы разрабатываете на платформах Microsoft, вы можете также попробовать Осло. Здесь есть хороший обзор: http://www.pluralsight.com/community/blogs/aaron/archive/2008/11/03/introducing-quot-oslo-quot.aspx

Вот тонна ссылок от Криса Селлса: http://www.sellsbrothers.com/news/showTopic.aspx?ixTopic=2197

Я пока не готов отождествлять доменно-управляемый дизайн с разработкой Model Drive.

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

Большая проблема в Модельно-управляемой деятельности - все, что связано с тем, откуда берется опыт, который извлекает реализации из моделей и на каком уровне обслуживания (и отладки) происходят. Моим тестом доступных книг было бы то, как они делают понятным конвейер и насколько хорошо можно понять путь от моделирования до развертывания и обратно.

Answer 2

Если вы программируете в.net, вы должны прочитать "Применение доменного дизайна и шаблонов" Джимми Нильссона. У него также есть раздел, посвященный ORM (NHibernate), SOA и инъекциям Dependency.

В любом случае вам стоит взглянуть на "Domain Driven Design" Эрика Эванса. Это классика, где вы можете найти бесценную информацию о шаблонах и лучших практиках для доменного дизайна

Answer 3

Отказ от ответственности: я разработчик бизнес-приложений. Следующий взгляд, безусловно, сформирован из моего опыта в окопах корпоративных ИТ. Я знаю, что существуют другие области разработки программного обеспечения. Особенно в разработке промышленных и / или встроенных систем мир может выглядеть иначе.

Я думаю, что MDSD все еще слишком привязан к генерации кода.

Генерация кода полезна только тогда, когда ваш код содержит много шума и / или очень повторяется. Другими словами, когда ваш код не может в основном сосредоточиться на существенной сложности, но загрязнен случайной сложностью.

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

Таким образом, эти новые платформы / фреймворки сильно удаляют паруса движения MDSD.

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

Поэтому, даже если DSL часто упоминаются вместе с MDSD, я думаю, что они действительно являются альтернативой MDSD. И, учитывая текущую ажиотаж, они также лишают импульс движения MDSD.

Если вы достигли цели окончательного устранения случайной сложности из своего кода (я знаю, что это вымышленное), то вы пришли к текстовой модели вашей бизнес-проблемы. Это не может быть упрощено!

Хорошие рамки и диаграммы не предлагают другого упрощения или повышения уровня абстракции! Они могут быть хороши для визуализации, но даже это сомнительно. Картина не всегда является лучшим представлением, чтобы понять сложность!

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

Посмотрите на следующую модель ActiveRecord, как иллюстрацию моей теории:

class Firm < ActiveRecord::Base
   has_many   :clients
   has_one    :account
   belongs_to :conglomorate
end

Я не думаю, что это может быть упрощено. Кроме того, любое графическое представление с прямоугольниками и линиями не будет упрощением и не будет более удобным (подумайте о компоновке, рефакторинге, поиске, изменении...).

Answer 4

MDD может быть действительно сложным или относительно простым.

Если вы хотите автоматизировать преобразование из ваших различных моделей (например, в UML) в код и выполнить круговую инженерию и все такое, вы можете получить довольно симпатичные инструменты.

Или же

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

Идея построения модели сначала является устоявшейся передовой практикой. Это часто называют "дизайном". Проблемы возникают, когда люди связывают дизайн со спецификацией. Модель того, что будет построено, не является спецификацией программирования. Это абстракция, которую можно использовать для оценки правильности, определения контрольных примеров, написания спецификаций и т. Д.

Вам не нужно все моделировать. Вы можете запустить MDD, имея модель данных - независимую от какой-либо конкретной реализации.

1. Вы рисуете свою модель, используя UML.

2. Вы преобразуете UML в определения классов.

3. Вы используете слой ORM (или ODBMS), чтобы отобразить ваши модели в какое-то хранилище.

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

Проблемы обычно возникают из-за всех видов преждевременной оптимизации, которая происходит во время разработки программного обеспечения. Ранние скачки в физическом дизайне РСУБД. Ранний переход к дизайну веб-страниц и его использованию для управления моделью данных. Ранний переход к определению архитектуры сервера и распределению хранилища.

Answer 5

Вы должны прочитать эту превосходную статью о лучших методах MDSD от Маркуса Фольтера: http://www.jot.fm/issues/issue_2009_09/column6.pdf

Что касается опции MDSD/DSL, экосистема EMF ( https://www.eclipse.org/modeling/emf/) предоставляет множество полезных строительных блоков:

• реализовать метамодели и редакторы моделей (EMF)
• реализует редакторы моделей (EMF, Sirius, Xtext...)
• управлять совместимостью и масштабируемостью (EMF-Transaction, CDO)
• реализовать правила проверки модели (EMF-Validation)
• реализовать генераторы кода (Acceleo, Xtend/Xpand, Mwe...)
• реализовать генераторы документов (pxDoc, m2doc...)

Интересным вариантом для сокращения инвестиций в инструментальные средства также может быть использование расширяемого UML-моделлера и определение ваших собственных профилей UML и пользовательских инструментов поверх многократно используемого моделера (предыдущий список по-прежнему подходит, если ваш UML-моделлер основан на UML2/ ЭДС реализации).