Che cos'è esattamente l'ingegneria software model driven (MDSE)?

"model driven software engineering (MDSE)" è la promessa di marketing dei produttori di strumenti software che "presto" parti significative del software possono essere generate da modelli di software.

Il partner dell'intervista in articolo a cui fai riferimento , Robert Howe è un produttore di utensili (vedi link per i dettagli)

Ma contro le promesse del produttore di strumenti, mdse non è ancora diventato mainstream.

Il hybris internet shop system è un esempio funzionante di "MDSE": tu come sviluppatore del software mantieni xml -model-files ("* -items.xml") e codegenerators / interpreti generano db-modell / java-code per persistenza / guis fuori di esso. Se hai bisogno di un attributo aggiuntivo, aggiungilo al modello xml e dopo il generatore / interprete ha fatto il suo lavoro è possibile utilizzare l'attributo per implementare la logica di business.

Il modello IMHO driven "è una grande esagerazione, specialmente se usato in congiunzione con parole chiave come" design "o" ingegneria del software "(invece di" sviluppo "). Probabilmente è stato inventato da alcune persone che hanno l'idea sbagliata che il "software design" è fatto disegnando alcuni modelli per lo più grafici con UML, come un architetto sta disegnando un progetto per una casa, e "codificare" è come porre i mattoni per la casa, seguendo il progetto. (Spero di non dover spiegare qui perché questo è sbagliato, se hai un'opinione diversa, leggi "Codice come Design "di Jack Reeves prima di mandarmi a fare un down.)

Questo è un grande modello mentale per quelle persone che si definiscono "architetti", "analisti di business", "designer", "ingegneri del software", che hanno studiato cinque anni di informatica, ma solo un anno e mezzo di vera esperienza di programmazione (al massimo), e ora è alla ricerca di un posto di lavoro nell'industria del software che include "progettazione di software" senza codifica. Immagino che questa sia la vera ragione per cui queste parole d'ordine "guidate dal modello" sono così popolari.

Non fraintendetemi, sono un grande fan dei modelli e dei generatori di codice per ridurre la necessità di scrivere manualmente il codice boilerplate. In alcune aree riservate come, ad esempio, i database, i modelli (di dati) possono essere davvero un buon strumento per comunicare con le persone del dominio. Lo sketch del flusso di dati tra i componenti per modello è una delle più importanti tecniche per portare la struttura in un sistema software (sfortunatamente le persone UML forgot si sono rifiutate di includere i diagrammi di flusso dei dati nella loro notazione; un mucchio di roba ridondante e inutile che nessuno usa in pratica).

Ma chiamerei questo "modello supportato lo sviluppo del software", non "model driven engineering del software", il che rende evidente che la modellazione supporta solo le principali attività di sviluppo , invece di essere l'attività principale stessa.

Questo mi ricorda un sacco di Concetto di modelli grassi, controller skinny .
L'idea principale di questo concetto è quella di inserire nel modello la maggior parte della logica aziendale e mantenere il controller e una vista molto semplicistici.
Personalmente, trovo questa idea molto interessante, anche se non ho avuto la possibilità di usarla.
Sorprendentemente, 8 link su 10 nella ricerca su google parlano contro di essa.
Ma, se si pensa a un modello non come a una singola classe, ma a una facciata di più classi interne, è perfettamente logico mantenere la logica aziendale nel modello.