Che cos'è esattamente il software driven engineering engineering (MDSE)?

Mi sono imbattuto nell'acronimo MDSE oggi su infoq , e le informazioni che ho trovato abbastanza poco chiare e la descrizione era piena di parole d'ordine:

MDSE mira a consentire agli ingegneri del software di lavorare a un livello di astrazione in cui i requisiti, le informazioni di architettura e progettazione sono ordinate al massimo (in termini di "entropia" delle informazioni) e conservate. (Chiamalo "prodotto di progettazione"). Inoltre, MDSE dovrebbe fornire agli ingegneri i mezzi per verificare e convalidare i loro progetti principalmente in termini di "prodotto di progettazione"

E a quanto pare, lo stanno facendo tutti: (dall'articolo di nuovo)

Siamo agli albori dell'era della MDSE. Nei prossimi 5-10 anni assisteremo a un significativo spostamento verso l'MDSE, nella misura in cui credo che entro la fine di questo periodo forse il 60-80% del software sarà progettato utilizzando tecniche basate su modelli.

Vorrei avere una descrizione concreta e senza parole d'ordine di cosa sia l'MDSE. Disegna scatole UML e genera codice con esso, come hanno fatto negli anni '90 con Rational Rose?

(Anche se ci fosse, se qualcuno ha un esempio di software generato usando queste tecniche, mi piacerebbe davvero vedere un esempio concreto).

"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 software.

Il partner dell'intervista nell'articolo a cui ti riferisci , Robert Howe è un produttore di strumenti (vedi http://www.verum.com/ per i dettagli)

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

Il sistema del negozio online di hybris è un esempio funzionante di "MDSE": tu come sviluppatore di software mantieni i file modello xml ("* -items.xml") e i codegeneratori / interpreti generano db-modell / java-code per persistenza / guis fuori di esso. Se è necessario un attributo aggiuntivo, è sufficiente aggiungerlo al modello xml e dopo che il generatore / interprete ha svolto il proprio lavoro, è possibile utilizzare l'attributo per implementare la logica aziendale.

Il "modello driven " di IMHO è una grande esagerazione, specialmente se usato insieme a parole d'ordine come "design" o "ingegneria del software" (anziché "sviluppo"). Probabilmente è stato inventato da alcune persone con l'idea sbagliata che "la progettazione del software" sia fatta disegnando alcuni modelli per lo più grafici con UML, come un architetto sta disegnando un progetto per una casa, e "codificare" è proprio come posare i mattoni per la casa, seguendo il progetto. (Spero di non dover spiegare qui perché questo è sbagliato, se hai un'opinione diversa, leggi "Code as Design" di Jack Reeves prima di sottovalutarmi.)

Questo è un ottimo modello mentale per quelle persone che si definiscono "architetti", "analisti aziendali", "designer", "ingegneri del software", che hanno studiato cinque anni di informatica, ma solo un anno e mezzo di esperienza di programmazione reale (al massimo ) e ora alla ricerca di un lavoro nel settore del software che includa "la progettazione di software" senza codifica. Immagino che questo sia il vero motivo 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 del boilerplate. In alcune aree riservate come, ad esempio, database, i modelli (dati) possono essere davvero un buon strumento per comunicare con le persone del dominio. Lo sketch del flusso di dati tra componenti per modello è IMHO una delle tecniche più importanti per portare la struttura in un sistema software (sfortunatamente, le persone UML hanno dimenticato di rifiutarsi di includere diagrammi di flusso di dati nella loro notazione; invece, hanno aggiunto un mucchio di cose ridondanti e inutili che nessuno usa in pratica).

Ma chiamerei questo " sviluppo di software supportato da modelli ", non " ingegneria di software guidata da modelli ", il che chiarisce la speranza che la modellazione supporti solo le principali attività di sviluppo, anziché essere l'attività principale stessa.

Questo mi ricorda un sacco di modelli Fat, concetto di controller skinny .
L'idea principale di questo concetto è quella di inserire nel modello quanta più logica di business possibile e mantenere il controller e una visione molto semplicistica.
Personalmente trovo che sia un'idea molto interessante, anche se non ho avuto la possibilità di usarla.
Sorprendentemente, 8 dei 10 migliori collegamenti nella ricerca di Google parlano contro di esso.
Ma, se si pensa a un modello non come a una singola classe, ma a una facciata di più classi interne, ha perfettamente senso mantenere la logica aziendale nel modello.