Czym dokładnie jest inżynieria oprogramowania oparta na modelu (MDSE)?

Przyszedłem do akronimu MDSE dzisiaj na infoq , a informacje mogłem znaleźć, co dość niejasne, a opis był pełen modnych słów:

MDSE polega na umożliwieniu inżynierom oprogramowania pracy na poziomie abstrakcji, w którym wymagania, architektura i informacje projektowe są maksymalnie uporządkowane (pod względem „entropii” informacji) i zachowane. (Nazwij to „produktem do prac projektowych”). Ponadto MDSE powinien zapewnić inżynierom środki do weryfikacji i walidacji ich projektów, przede wszystkim warunków ich „produktu do prac projektowych”

I najwyraźniej wszyscy to robią: (ponownie z artykułu)

Jesteśmy u progu wieku MDSE. W ciągu najbliższych 5–10 lat nastąpi znacząca zmiana w kierunku MDSE, do tego stopnia, że ​​uważam, że do końca tego okresu prawdopodobnie 60–80% oprogramowania zostanie zaprojektowanych przy użyciu technik opartych na modelach.

Chciałbym mieć konkretny, wolny od modnych słów opis tego, czym jest MDSE. Czy rysuje pola UML i generuje z nim kod, tak jak w latach 90. z Rational Rose?

(będąc przy tym, jeśli ktoś ma przykład oprogramowania wygenerowanego przy użyciu tych technik, naprawdę chciałbym zobaczyć konkretny przykład).

„inżynieria oprogramowania oparta na modelu (MDSE)” to obietnica marketingowa producentów narzędzi programowych, która „wkrótce” może wygenerować znaczną część oprogramowania z modeli oprogramowania.

Robert Howe, partner w wywiadzie w artykule, do którego się odnosisz , jest producentem narzędzi (szczegóły na stronie http://www.verum.com/ )

Ale wbrew obietnicom producentów narzędzi mdse nie stało się jeszcze głównym nurtem.

System sklepu internetowego Hybris jest działającym przykładem „MDSE”: Ty jako programista utrzymujesz pliki xml-model-files („* -items.xml”), a codegenerators / interpreters generują kod db-modell / java-code dla trwałości / guis z tego. Jeśli potrzebujesz dodatkowego atrybutu, po prostu dodaj go do modelu xml, a po wykonaniu generatora / interpretera możesz użyć tego atrybutu do zaimplementowania logiki biznesowej.

IMHO „ sterowane modelami ” to duża przesada, szczególnie w połączeniu z modnymi słowami, takimi jak „projektowanie” lub „inżynieria oprogramowania” (zamiast „rozwoju”). Prawdopodobnie został wymyślony przez niektórych ludzi, którzy mylnie rozumieją, że „projektowanie oprogramowania” odbywa się poprzez narysowanie niektórych głównie graficznych modeli za pomocą UML, podobnie jak architekt rysuje plan domu, a „kodowanie” jest jak układanie cegieł dla domu, zgodnie z planem. (Mam nadzieję, że nie muszę tutaj wyjaśniać, dlaczego jest to złe, jeśli masz inne zdanie, przeczytaj najpierw „Code as Design” Jacka Reevesa ).

To świetny model mentalny dla osób nazywających się „architektami”, „analitykami biznesowymi”, „projektantami”, „inżynierami oprogramowania”, którzy studiowali pięć lat informatyki, ale tylko pół roku prawdziwego doświadczenia programistycznego (maksymalnie ), a teraz szuka pracy w branży oprogramowania, która obejmuje „projektowanie oprogramowania” bez kodowania. To chyba prawdziwy powód, dla którego te modne słowa są tak popularne.

Nie zrozumcie mnie źle, jestem wielkim fanem modeli i generatorów kodów, które zmniejszają potrzebę ręcznego pisania kodu na płycie głównej. W niektórych ograniczonych obszarach, takich jak na przykład bazy danych, modele (danych) mogą być rzeczywiście dobrym narzędziem do komunikowania się z osobami z domeny. Szkicowanie przepływu danych między komponentami według modeli jest IMHO jedną z najważniejszych technik wprowadzania struktury do systemu oprogramowania (niestety ludzie UML zapomnieli dołączyć do notacji diagramy przepływu danych; zamiast tego dodali kilka zbędnych, niepotrzebnych rzeczy których nikt nie używa w praktyce).

Ale nazwałbym to „ opracowywaniem oprogramowania wspieranego przez model ”, a nie „ inżynierią oprogramowania opartą na modelu ”, co, miejmy nadzieję, wyjaśnia, że ​​modelowanie po prostu wspiera główne działania w rozwoju, a nie samo działanie główne.

Przypomina mi to wiele modeli Fat, chudych kontrolerów .
Główną ideą tej koncepcji jest wykorzystanie jak największej logiki biznesowej do modelu i utrzymanie uproszczonego kontrolera i widoku.
Osobiście uważam to za bardzo interesujący pomysł, chociaż nie miałem okazji z niego skorzystać.
Co zaskakujące, 8 na 10 najlepszych linków w wyszukiwarce Google przemawia przeciwko temu.
Ale jeśli myślisz o modelu nie jako o pojedynczej klasie, ale o fasadzie wielu klas wewnętrznych, sensowne jest zachowanie logiki biznesowej w modelu.