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

StackOverflow https://stackoverflow.com/questions/262279

Вопрос

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

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

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

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

Это было полезно?

Решение

Если вы разрабатываете на платформах 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), но, возможно, не так уж и много.

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

Другие советы

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

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

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

Я думаю, что 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

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

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

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

Или

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

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

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

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

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

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

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

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

Вам следует прочитать эту превосходную статью о лучших практиках 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-Транзакция, CDO)
  • реализовать правила проверки модели (EMF-Validation)
  • реализовать генераторы кода (Acceleo, Xtend/Xpand, Mwe...)
  • внедрить генераторы документов (pxDoc, m2doc ...)

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top