Что именно представляет собой модель программного обеспечения (MDSE)?

Сегодня я наткнулся на сокращение MDSE на infoq , и информация, которую я смог найти, была довольно непонятной, а описание было полно словечек:

MDSE позволяет инженерам-программистам работать на уровне абстракции, где требования, архитектура и информация о дизайне максимально упорядочены (с точки зрения информационной энтропии) и сохранены. (Назовите это «продуктом проектной работы»). Кроме того, MDSE должен предоставить инженерам средства для проверки и подтверждения их проектов в первую очередь с точки зрения их «продукта для проектирования».

И, видимо, все это делают: (снова из статьи)

Мы находимся на заре эры MDSE. В ближайшие 5–10 лет мы увидим значительный сдвиг в сторону MDSE, и я полагаю, что к концу этого периода около 60–80% программного обеспечения будет разрабатываться с использованием методов, основанных на моделях.

Я хотел бы получить конкретное, без слов модное описание того, что такое MDSE. Рисует ли он UML-блоки и генерирует с ним код, как это было в 90-х годах с Rational Rose?

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

«Разработка программного обеспечения на основе модели (MDSE)» - это маркетинговое обещание производителей программного обеспечения, что «скоро» из программных моделей могут быть созданы значимые части программного обеспечения.

Партнер по интервью в статье, к которой вы обращаетесь , Роберт Хоу (Robert Howe) - производитель инструмента ( подробности см. На http://www.verum.com/ ).

Но вопреки обещаниям производителей инструментов mdse еще не стал мейнстримом.

Система интернет-магазина hybris является рабочим примером «MDSE»: вы, как разработчик программного обеспечения, поддерживает файлы xml-model-files ("* -items.xml"), а генераторы кода / интерпретаторы генерируют db-modell / java-code для постоянства / guis из этого. Если вам нужен дополнительный атрибут, просто добавьте его в xml-модель, и после того, как генератор / интерпретатор выполнит свою работу, вы можете использовать атрибут для реализации бизнес-логики.

ИМХО « управляемая моделью » - это большое преувеличение, особенно когда оно используется в сочетании с модными словами, такими как «дизайн» или «разработка программного обеспечения» (вместо «разработка»). Вероятно, он был изобретен некоторыми людьми, у которых ошибочное представление о том, что «проектирование программного обеспечения» выполняется путем рисования некоторых в основном графических моделей с использованием UML, например, архитектор рисует чертеж дома, а «кодирование» - это все равно, что закладывать кирпичи для дома, следуя плану. (Надеюсь, мне не нужно объяснять здесь, почему это неправильно, если у вас другое мнение, пожалуйста, сначала прочтите «Код как дизайн» Джека Ривза, прежде чем опровергать меня.)

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

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

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

Это напоминает мне много моделей Fat, концепцию тощих контроллеров .
Основная идея этой концепции заключается в том, чтобы в модель было заложено как можно больше бизнес-логики, а контроллер и представление очень упрощены.
Лично я нахожу это очень интересной идеей, хотя у меня не было возможности использовать ее.
Удивительно, но 8 из 10 лучших ссылок в поиске Google говорят против этого.
Но если вы думаете о модели не как о едином классе, а как о фасаде нескольких внутренних классов, то имеет смысл сохранить бизнес-логику в модели.