Що саме є моделювання програмного забезпечення (MDSE)?

Я сьогодні зіткнувся з абревіатурою MDSE сьогодні на infoq , і інформація, яку я міг знайти, яка зовсім незрозуміла, і опис був повний модних слів:

MDSE передбачає можливість інженерам програмного забезпечення працювати на рівні абстракції, де вимоги, архітектура та інформація про дизайн максимально впорядковані (з точки зору інформації "ентропія") та зберігаються. (Назвіть це "продуктом дизайнерської роботи"). Крім того, MDSE має надати інженерам засоби для перевірки та затвердження своїх конструкцій, насамперед, умов їх "проектування робочого продукту"

І, мабуть, всі це роблять: (із статті знову)

Ми на світанку віку MDSE. У наступні 5 - 10 років ми побачимо суттєвий зсув у бік MDSE, наскільки я вважаю, що до кінця цього періоду, можливо, 60 - 80% програмного забезпечення буде розроблено з використанням модельних методів.

Я хотів би мати конкретний, безкоштовний опис того, що таке MDSE. Це малювання полів UML та генерування коду з ним, як це було у 90-х роках із Rational Rose?

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

"інженерія програмного забезпечення, що керується моделями" (MDSE) - це маркетингова обіцянка виробників програмних засобів, що "незабаром" значні частини програмного забезпечення можуть бути сформовані з програмних моделей.

Партнер-інтерв'ю у статті, яку ви посилаєтесь , Роберт Хоу є виробником інструментів (детальніше див. Http://www.verum.com/ )

Але проти обіцянок виробника інструменту mdse ще не став мейнстрімом.

Система Інтернет-магазину гібридів є хорошим прикладом "MDSE": ви як розробник програмного забезпечення підтримуєте xml-model-файли ("* -items.xml"), а генератори коду / інтерпретатори генерують db-modell / java-код для стійкості / guis з нього. Якщо вам потрібен додатковий атрибут, просто додайте його до xml-моделі, і після того, як генератор / інтерпретатор виконає свою роботу, ви можете використовувати цей атрибут для реалізації бізнес-логіки.

IMHO " керована модель " - це велике перебільшення, особливо, коли воно використовується в поєднанні з такими мовними словами, як "дизайн" або "інженерія програмного забезпечення" (замість "розробка"). Це, мабуть, придумали деякі люди, які мають помилкове уявлення "дизайн програмного забезпечення" робиться шляхом малювання деяких переважно графічних моделей за допомогою UML, як архітектор малює креслення для будинку, а "кодування" - це як укладання цегли для будинку, слідом за планом. (Я сподіваюсь, що мені не доведеться пояснювати, чому це неправильно. Якщо у вас інша думка, будь ласка, прочитайте "Кодекс як дизайн" Джека Ривза спочатку, перш ніж звертатись на мене.)

Це чудова ментальна модель для тих, хто називає себе "архітекторами", "бізнес-аналітиками", "дизайнерами", "програмними інженерами", які вивчали п'ять років інформатики, але лише півроку реального досвіду програмування (максимум ), і тепер шукаю роботу в галузі програмного забезпечення, яка включає "проектування програмного забезпечення" без кодування. Я здогадуюсь, що це справжня причина, чому ці мовленнєві слова "керовані моделлю" настільки популярні.

Не зрозумійте мене неправильно, я великий фанат моделей та генераторів кодів, щоб зменшити необхідність писати код котла вручну. У деяких обмежених областях, таких як, наприклад, бази даних, (дані) моделі, справді можуть бути хорошим інструментом для спілкування з людьми домену. Ескіз потоку даних між компонентами за моделями - IMHO - одна з найважливіших методик для введення структури в програмну систему (на жаль, люди UML забули відмовитись від включення діаграм потоку даних у свої нотації; натомість додали купу зайвих, непотрібних речей який ніхто не використовує на практиці).

Але я б назвав це " розробкою програмного забезпечення, що підтримується моделлю ", а не " інженерією програмного забезпечення, що керується моделями ", що, сподіваємось, зрозуміло, що моделювання просто підтримує основні напрямки розвитку, а не основну діяльність.

Це мені дуже нагадує жирні моделі, концепцію худих контролерів .
Основна ідея цієї концепції полягає в тому, щоб якомога більше ділової логіки було вкладено в модель і зберегти контролер і вигляд дуже спрощеними.
Особисто мені здається, що це дуже цікава ідея, хоча я не мав можливості її використати.
Дивно, але 8 з 10 найпопулярніших посилань у пошуку в Google говорять проти цього.
Але, якщо ви думаєте про модель не як про один клас, а про фасад з декількох внутрішніх класів, має ідеальний сенс зберігати ділову логіку в моделі.