Utilizzi MDA/MDD/MDSD o qualsiasi tipo di approccio basato su modelli?Sarà il futuro?

Question

I linguaggi di programmazione hanno avuto diversi passi (r)evolutivi nella loro storia.Alcuni sostengono che gli approcci basati su modelli saranno la prossima grande cosa.Esistono strumenti come openArchitectureWare, AndroMDA, Sculptor/Fornax Platform ecc.che promettono incredibili aumenti di produttività.Tuttavia, ho sperimentato che all'inizio è piuttosto facile iniziare, ma anche rimanere bloccati ad un certo punto quando si prova qualcosa che non era previsto o piuttosto difficile trovare informazioni sufficienti che dicano come iniziare il progetto perché potrebbero esserci molte cose da considerare.

Penso che un'intuizione importante per ottenere qualcosa da qualcosa basato sul modello sia capire che il modello non è necessariamente un insieme di belle immagini o un modello di albero o UML, ma potrebbe anche essere una descrizione testuale (ad es.una macchina statale, regole aziendali, ecc.).

Cosa ne pensi e cosa ti dice la tua esperienza?Esiste un futuro per lo sviluppo basato su modelli (o come preferisci chiamarlo)?

Aggiornamento: Non sembra esserci molto interesse per questo argomento.Per favore fatemi sapere se avete qualche esperienza (buona o cattiva) con approcci basati su modelli o perché pensate che non sia affatto interessante.

Answer 1

Penso che ci vorrà del tempo finché gli strumenti non diventeranno più raffinati e più persone acquisiranno esperienza con MDD.Al momento se vuoi ottenere qualcosa da MDD devi investire parecchio, quindi il suo utilizzo rimane limitato.

Guardando openArchitectureWare ad esempio:Sebbene sia abbastanza robusto ed esista una documentazione di base, manca la documentazione sul funzionamento interno e ci sono ancora problemi con la scalabilità, che non sono documentati - forse migliorerà quando Xtext e Xpand verranno riscritti.

Ma nonostante queste limitazioni, la generazione stessa è abbastanza semplice con oAW, puoi navigare tra i tuoi modelli come un incantesimo in Xtend e Xpand e combinando diversi flussi di lavoro in flussi di lavoro più grandi, puoi anche fare cose molto complesse.Se necessario puoi ricorrere a Java, quindi hai una grande flessibilità in ciò che puoi fare con i tuoi modelli.Anche scrivere il tuo DSL con Xtext in oAW è veloce, ma ottieni il tuo meta-modello, un parser e un editor molto carino praticamente gratis.Inoltre puoi ottenere i tuoi modelli praticamente da ovunque, ad es.un componente in grado di convertire un database in un metamodello e i modelli corrispondenti può essere scritto senza grandi sforzi.

Quindi direi che MDD è ancora in fase di sviluppo, poiché gli strumenti e l'esperienza con esso aumentano.Può già essere utilizzato con successo, se possiedi le competenze necessarie e sei pronto a spingerlo all'interno della tua azienda.Alla fine, penso che sia un'ottima cosa, perché si può e si deve generare molto codice adesivo (ovvero copia incolla).Farlo con MDD è un modo molto carino e strutturato per farlo, che facilita la riusabilità, secondo me.

Answer 2

Disclaimer:Sono uno sviluppatore di applicazioni aziendali.La visione seguente è certamente modellata dalle mie esperienze nelle trincee dell'IT aziendale.Sono consapevole che esistono altri ambiti dello sviluppo del software.Soprattutto nello sviluppo di sistemi industriali e/o embedded il mondo potrebbe apparire diverso.

Penso che MDSD sia ancora troppo legato alla generazione di codice.

La generazione del codice è utile solo quando il codice contiene molto rumore e/o è molto ripetitivo.In altre parole, quando il tuo codice non riesce a concentrarsi principalmente sulla complessità essenziale, ma è inquinato da complessità accidentale.

A mio avviso, la tendenza nelle piattaforme e nei framework attuali è esattamente quella di rimuovere la complessità accidentale e lasciare che il codice dell'applicazione si concentri sulla complessità essenziale.

Quindi queste nuove piattaforme/framework tolgono molto vento alle vele del movimento MDSD.

I DSL (quelli testuali) sono un'altra tendenza che cerca di consentire l'attenzione esclusiva sulla complessità essenziale.Sebbene i DSL possano essere utilizzati come sorgente per la generazione di codice, non sono principalmente legati alla generazione di codice.I DSL (in particolare i DSL interni) sostanzialmente lo consentono di essere interpretato/eseguito in fase di esecuzione.[la generazione del codice runtime è una via di mezzo].

Quindi, anche se i DSL vengono spesso menzionati insieme all’MDSD, penso che siano davvero un’alternativa all’MDSD.E data l’attuale campagna pubblicitaria, tolgono slancio anche al movimento MDSD.

Se hai raggiunto l'obiettivo di rimuovere definitivamente la complessità accidentale dal tuo codice (so che è fittizio), allora sei arrivato a un modello testuale del tuo problema aziendale.Questo non può essere ulteriormente semplificato!

Le belle scatole e i diagrammi non offrono un'altra semplificazione o elevazione del livello di astrazione!Possono essere utili per la visualizzazione, ma anche questo è discutibile.Non sempre una foto è la rappresentazione migliore per cogliere la complessità!

Inoltre, lo stato attuale degli strumenti coinvolti nell’MDSD aggiunge un altro livello di complessità accidentale (si pensi:sincronizzazione, diffing/merging, refactoring...) che sostanzialmente annulla l'obiettivo finale della semplificazione!

Guarda il seguente modello ActiveRecord, come illustrazione della mia teoria:

class Firm < ActiveRecord::Base
   has_many   :clients
   has_one    :account
   belongs_to :conglomorate
end

Non penso che questo possa essere più semplificato.Inoltre qualsiasi rappresentazione grafica con riquadri e linee non rappresenterebbe una semplificazione e non offrirebbe alcuna comodità in più (si pensi al layout, al refactoring, alla ricerca, al diffing ...).

Answer 3

Lo sviluppo basato su modelli esiste da molto tempo.

Il tentativo più riuscito dei primi è stato James Martins Integrated Engineering Facility", che è ancora in circolazione e commercializzato da CA con il marchio decisamente poco cool "Coolgen".

Allora perché non ha conquistato il mondo se era così bello?

Bene, questi strumenti sono bravi a rendere le cose semplici più semplici, ma non rendono le cose difficili più facili e in molti casi rendono le cose difficili più difficili!

Puoi passare ore cercando di persuadere un linguaggio di modellazione grafica 4GL a "fare la cosa giusta" quando sai che codificare la cosa giusta in Java/C/SQL o qualsiasi altra cosa sarebbe banale.

Answer 4

Penso che forse non esista una risposta definitiva, da qui la mancanza di "interesse" per questa domanda.

Ma personalmente ho avuto esperienze contrastanti con la MDA.L'unica volta in cui è stata una buona esperienza è stata con ottimi strumenti - usavo TogetherSoft (credo che in qualche modo siano finiti a Borland) - sono stati tra i primi a introdurre l'editing che non era "generazione di codice" ma effettivamente modifica del codice/ model direttamente (in modo da poter modificare il codice o il modello, era tutta una cosa).Avevano anche il refactoring (che è stata la prima volta che lo ricordo dopo gli ambienti di conversazione).

Da allora non ho più visto MDA crescere in popolarità, almeno nel mainstream, quindi in termini di popolarità non sembra essere il futuro (quindi questa è la risposta).

Naturalmente la popolarità non è tutto, e le cose tendono a ripresentarsi, ma per il momento penso che MDA+tools sia visto da molti come strumenti di "generazione di codice basata su procedure guidate" (indipendentemente da cosa sia realmente) quindi io penso che ci vorrà del tempo o forse mai perché decolla davvero.

Answer 5

Uno dei problemi di MDD è che, poiché funziona a un livello di astrazione più elevato, richiede sviluppatori che possano salire anche a quel livello.Ciò riduce notevolmente l’universo degli sviluppatori in grado di comprendere e utilizzare tali metodologie.

Answer 6

Per favore fatemi sapere se avete qualche esperienza (buona o cattiva) con approcci basati su modelli o perché pensate che non sia affatto interessante.

Penso che i contributori qui facciano parte del campo "No Silver Bullet" (lo sono sicuramente).Se l'MDA funzionasse (equivale a un "enorme risparmio"), lo sapremmo, questo è certo.La domanda è:fino a che punto puoi spingerti "meta" mantenendo il tuo sistema gestibile?Questo fu il punto di svolta in UML 2.0 quando introdussero un meta-meta-modello più formale.Finora non ho visto un utilizzo reale del potere di modellazione di UML 2.0 (ma il mio mondo è piuttosto limitato).Inoltre, con un approccio basato sul modello hai solo due scelte:generare codice o avere un runtime che sfrutta il tuo modello.Il generatore di codice definitivo senza vincoli è chiamato "umano", mentre i tempi di esecuzione definitivi si trovano nei 4GL (qual è il numero attuale al giorno d'oggi?).Forse questo spiegherebbe la mancanza di entusiasmo.

Answer 7

Noi di itemis (www.itemis.com) utilizziamo molto lo sviluppo software basato su modelli.Finora abbiamo avuto esperienze davvero positive.Certo, non è una soluzione miracolosa, ma aiuta a migliorare la qualità del software e quindi a renderlo più utile ai nostri clienti.

Answer 8

Lo sviluppo basato su modelli sarà il futuro se e solo se i modelli che utilizza saranno flessibili quanto scrivere il codice che dovrebbe generare.Penso che il motivo per cui non sta andando così bene in questo momento è che è difficile fare lo stesso "andata e ritorno" che i linguaggi di programmazione basati su testo fanno da decenni.

Con i linguaggi di programmazione basati su testo, cambiare il modello è semplice come cambiare poche righe di codice.Con un linguaggio di programmazione grafico (ovvero un diagramma MDD come UML), devi trovare un modo per tradurre quel modello fino al suo equivalente basato su testo (che era già espressivamente efficiente in primo luogo) e può essere molto, molto disordinato.

IMHO, l'unico modo in cui MDD può mai essere utile se è costruito da zero per essere espressivo e flessibile come la sua controparte basata su testo.Il tentativo di utilizzare linguaggi di progettazione grafica top-down esistenti (come UML) per strumenti che sono intrinsecamente costruiti dal basso verso l'alto utilizzando astrazioni stratificate (come i linguaggi di programmazione) pone un enorme disadattamento di impedenza.Non riesco a capirlo bene, ma manca ancora qualcosa in MDD che lo renderebbe utile come la gente affermerebbe che fosse...

Answer 9

Questa è una risposta molto tardiva, ma attualmente sto cercando strumenti MDD per sostituire Rose RT, che purtroppo è stato soppiantato da Rhapsody.Siamo nello spazio C++ in tempo reale, incorporato e distribuito e otteniamo MOLTO da MDD.Stiamo cercando di passare a uno strumento migliore e di ottenere un utilizzo più diffuso dello strumento nella nostra grande azienda.È una battaglia in salita a causa di alcune delle ottime ragioni qui menzionate.

Penso a MDD solo come un livello sopra il compilatore, proprio come il compilatore è sopra l'assembly.Voglio uno strumento che mi consenta, in qualità di architetto, di sviluppare il framework dell'applicazione e modificare ampiamente la generazione del codice (script) per utilizzare quel framework e qualunque middleware utilizziamo per il passaggio dei messaggi.Voglio che gli sviluppatori creino classi UML e diagrammi di stato completi che includano tutto il codice necessario per generare l'applicazione e/o la libreria.

È vero che puoi fare qualsiasi cosa con il codice, ma riassumerei approssimativamente i vantaggi di MDD in questo modo:

1. Alcune persone creano il framework dell'applicazione, gli adattatori middleware e li incollano allo strumento MDD.Costruiscono la "casa".
2. Altre persone creano classi complete, diagrammi e codici di transizione della macchina a stati.Ciò consente loro di concentrarsi sull'applicazione anziché sulla "casa".
3. È facile capire quando le persone hanno un design strano poiché il diagramma è il codice.Non abbiamo tutti sviluppatori esperti ed è bello allevare i giovani in questo modo.
4. Principalmente è il brutto codice macchina a stati che può verificarsi in qualcosa come un progetto di robotica mobile.Voglio che le persone creino diagrammi di stato che io possa comprendere, criticare e con cui lavorare su di essi.
5. Puoi anche avere un bel refactoring come il trascinamento di operazioni e attributi su catene di ereditarietà o su altre classi, ecc.Mi piace di più che scavare nei file.

Anche mentre scrivo questo mi rendo conto che puoi fare tutto nel codice.Mi piace uno strumento sottile posizionato sopra il codice per garantire l'uniformità, documentare il design e consentire un refactoring un po' più semplice.

Il problema principale che riscontro e per il quale non ho una buona risposta è che non esiste un insieme standard di funzionalità e formato di file per tali modelli.Le persone si preoccupano che il venditore se ne vada e poi rimanga bloccato.(Praticamente è successo con Rose RT.) Non è così con il codice sorgente.Tuttavia, avresti la versione più recente dello strumento e il codice del corso che hai generato per ultimo :).Sono disposto a scommettere che i benefici superano i rischi.

Devo ancora trovare uno strumento come questo, ma sto cercando di convincere alcuni venditori ad ascoltarmi e magari ad accettare denaro per realizzarlo.