Perché non stiamo ancora facendo tutti uno sviluppo guidato da modelli? [chiuso]

Sono un vero sostenitore dello sviluppo guidato da modelli, penso che abbia la possibilità di aumentare la produttività, la qualità e la prevedibilità. Guardando MetaEdit i risultati sono sorprendenti. Mendix nei Paesi Bassi sta crescendo molto molto velocemente e ha grandi risultati.

So anche che ci sono molti problemi

• controllo delle versioni di generatori, modelli e framework
• progetti che non sono adatti allo sviluppo guidato da modelli (non abbastanza ripetizione)
• rischi più elevati (quando il primo progetto fallisce, si ottengono meno risultati di quelli che si avrebbero con uno sviluppo più tradizionale)
• eccetera

Tuttavia, questi problemi sembrano risolvibili e i benefici dovrebbero superare lo sforzo necessario.

Domanda : quali sono i maggiori problemi che non ti fanno nemmeno considerare lo sviluppo guidato da modelli?

Voglio usare queste risposte non solo per la mia comprensione, ma anche come possibile fonte per una serie di articoli interni che ho intenzione di scrivere.

Non esiste un martello d'oro. Ciò che funziona bene in un dominio è piuttosto inutile in un altro. C'è una certa complessità intrinseca nello sviluppo del software e nessuno strumento magico lo rimuoverà.

Si potrebbe anche sostenere che la generazione del codice è utile solo se il linguaggio stesso (o il framework) non è abbastanza di alto livello da consentire potenti astrazioni che renderebbero MDD relativamente inutile.

Domanda interessante! Lo ammetto, non sono un fan, ma poi ho provato a utilizzare lo sviluppo basato sui modelli più volte in progetti che si adattano ad alcuni dei problemi che hai appena sollevato.

Ecco la mia lista dei motivi:

• curva di apprendimento - gli strumenti di modellazione si sono evoluti così rapidamente, che mi viene molto difficile trovare ingegneri che capiscano profondamente lo strumento. Trovo ancora che tu sia bravo solo come il tuo strumento di modellazione. Certo, molti dei problemi sottostanti potrebbero risalire a questo problema - ogni volta che pensi che uno strumento sia troppo limitante, è possibile che non lo sappia abbastanza bene.
• Troppo strutturato - Personalmente, mi sono trovato in situazioni in cui ho scoperto che lo strumento di modellazione era semplicemente troppo strutturato per permettermi di descrivere tutto ciò che avevo bisogno di descrivere. E una volta che passo a disegnare alcune parti del modello all'esterno dello strumento, le cose decadono rapidamente mentre le persone iniziano a spostarsi all'esterno dello strumento per trovare le informazioni.
• Costo della messa a punto dello strumento: ogni volta che ho provato a generare automaticamente il codice, ho finito per rielaborare manualmente il codice una volta che ho visto ciò che lo strumento pensava fosse giusto. So che dopo alcuni giri, questo problema diminuisce, ma ciò significa che devi sopravvivere ai primi giri. In genere ho sentito che stavamo giocando a colpire una talpa - crea modello -> genera codice -> correggi codice -> aggiorna modello -> correggi modello, risciacqua e ripeti.
• Gestione della configurazione del modello: poiché il modello descrive gran parte del progetto, ad un certo livello il modello CM sarà più trasversale rispetto al codice creato. La suddivisione in compartimenti dei file di modellazione è un'arte in sé: farlo in modo sbagliato e spesso si finisce con deadlock degli sviluppatori o modelli obsoleti quando le persone rinunciano e scendono al codice.
• time to market: ho riscontrato problemi precisi in una situazione in cui la necessità di software funzionante era urgente. Se il progetto e il team sono abbastanza piccoli, non vedo alcun motivo per perdere tempo con uno strumento di modellazione quando è possibile impiegare il tempo a programmare e testare. Non tutti i progetti sono abbastanza grandi da richiedere tali investimenti.
• Costo del fallimento - quando ho visto progetti scappare dagli strumenti di modellazione, è a causa dell'elevato costo del fallimento - per utilizzare gli strumenti, è necessario che tutti gli sviluppatori siano coinvolti. Questo è un grande investimento nella formazione e nell'apprendimento pratico, e un errore molto costoso se qualcuno ha impostato male il modello. La mia esperienza è che possono essere necessarie due o tre versioni per ottenere il modello giusto, quindi molti progetti non sopravvivono agli errori di modellazione abbastanza a lungo per realizzare i vantaggi.

È già stato citato, ma No Silver Bullet affronta abbastanza bene il punto:

L'essenza di un'entità software è un costrutto di concetti di interblocco: set di dati, relazioni tra elementi di dati, algoritmi e invocazioni di funzioni. Questa essenza è astratta in quanto un tale costrutto concettuale è lo stesso in molte rappresentazioni diverse. È comunque estremamente preciso e ricco di dettagli.

Credo che la parte difficile della costruzione di software sia la specifica, la progettazione e il collaudo di questo costrutto concettuale, non il lavoro di rappresentarlo e testare la fedeltà della rappresentazione. Facciamo ancora errori di sintassi, per essere sicuri; ma sono sfocati rispetto agli errori concettuali nella maggior parte dei sistemi.

Se questo è vero, la creazione di software sarà sempre difficile. Non c'è intrinsecamente nessun proiettile d'argento.

Successivamente, Brooks sottolinea quanto segue sul concetto di "programmazione automatica":

Per quasi 40 anni, le persone hanno anticipato e scritto sulla "programmazione automatica" o sulla generazione di un programma per risolvere un problema da una dichiarazione delle specifiche del problema. Alcuni oggi scrivono come se si aspettassero che questa tecnologia fornisse la svolta successiva.

Parnas implica che il termine è usato per glamour, non per contenuto semantico, affermando: "In breve, la programmazione automatica è sempre stata un eufemismo per la programmazione con un linguaggio di livello superiore rispetto a quello che era attualmente disponibile per il programmatore".

Sostiene, in sostanza, che nella maggior parte dei casi è il metodo di soluzione, non il problema, la cui specifica deve essere data.

Fondamentalmente, direi che MDD è solo un altro eufemismo per la programmazione con un linguaggio di livello superiore rispetto a quello precedentemente disponibile.

Questo non vuol dire che la programmazione in un linguaggio di livello superiore non può essere d'aiuto, anzi spesso può. Ma l' essenza del problema rimane la stessa: non importa quanto sia grande uno strumento o quanto sia grande una lingua che stai usando, alla fine della giornata devi pensare a tutti i problemi e risolverli. Il meglio che uno strumento o un processo può fare è rimuovere il "fuzz" in modo da poter concentrarsi sull'importante questione, che è, come ha detto Brooks, "la specifica , la progettazione e il test di questo costrutto concettuale ".

Perché non tutta la programmazione è orientata agli oggetti, cosa che tutti gli strumenti MDD sembrano aspettarsi. Lo stesso UML si basa sulla presunzione di oggetti. Sicuramente puoi usare i diagrammi di sequenza per modellare le funzioni, ma molte volte è maldestro.

Perché ci sono programmatori come me che ottengono più progressi e risultati da TDD che da MDD.

Perché la modellazione! = Programmazione.

Perché il rapporto costi / benefici era troppo elevato dal lato dei costi e non abbastanza dal lato dei benefici. Questo è probabilmente cambiato dall'ultima volta che ho guardato MDD, allora ti verrà richiesto di pagare> $ 6000 / posto (USD) per uno strumento che sarebbe moderatamente capace di MDD.

Perché un modello che descrive sufficientemente una funzione per generare il codice non è più utile come modello.

Perché ci sono programmatori come me che usano solo modelli di alto livello e poi elaborano i dettagli con il codice. Vedi le cose in modo diverso nel codice rispetto a quanto fai nel software di modellazione.

Questi sono alcuni dei motivi per cui personalmente non faccio MDD. Sono stato esposto ad esso, ma nulla è stato in grado di farmi un convertito. Forse sono troppo vecchia scuola. Forse sono una scuola troppo nuova (qualunque cosa sia). Non è solo uno strumento che sono stato in grado di pagare da solo.

Microsoft / Apple / Google non lo sta spingendo :)

Il tipo di sviluppo che viene reso popolare ha molto a che fare con gli strumenti, il sostegno e l'evangelizzazione. È molto difficile sfondare con qualcosa senza avere un grosso sostenitore (Ruby su rotaie forse è l'eccezione ma è ancora piccolo rispetto a Java / C # / Python)

A causa di una semplice legge che ha interessato tutti questi strumenti di modellazione, sai, CASE, UML e simili:

Tra un programmatore e il suo codice è molto costoso.

In tal caso, è necessario creare un compilatore / interprete adeguato, i generatori di codice generano un flusso di lavoro terribile e un terribile feedback al programmatore (messaggi di errore e simili).

Una delle grandi intuizioni di Domain Driven Design è che i modelli dovrebbero essere nel codice, non in qualcosa di esterno al codice.

Alla fine la domanda è: perché i tuoi modelli non si adattano al codice? Se stai eseguendo uno sviluppo integrato e sei bloccato con C o hai bisogno di generare codice per piattaforme diverse, la generazione del codice può valere il costo. Per tutti gli altri, un linguaggio di programmazione più potente e una migliore progettazione del codice sono generalmente migliori della progettazione del codice in qualcosa di diverso dal codice.

• Sembra una seccatura gigantesca per pochissimi benefici.
• Mi sembra sempre di avere a che fare con astucci e cose strane, le cose magiche non sembrano mai funzionare bene.
• OO non è un proiettile d'argento; trasferire una metodologia generatrice di software su OO non lo rende argento.

Ma non mi piacciono le soluzioni aziendali in generale.

Ho avuto la discussione e mi piacerebbe fare l'MDA, ma il più grande svantaggio è il supporto degli strumenti per ora. Sto usando una derivazione di MDA che mi piace chiamare "valutazione del modello di runtime", ma ne parlerò più avanti.

Gli svantaggi di MDA sono, come so:

• Supporto di refactoring mancante: suppongo che io voglia modellare le entità del mio modello di dati con MDA (tipico caso d'uso n. 1). Se ho il mio modello, diciamo, un diagramma UML e lo cambio, nulla del mio codice cambia con esso (almeno le classi generate) e invece di avere ancora un'app funzionante con attributi meglio denominati, ottengo un molti errori devo correggere manualmente.
• Supporto di debug mancante: in genere le traduzioni dal modello al codice vengono eseguite con un linguaggio di trasformazione a portata di mano. Questo non sarebbe di solito un problema, ma quando eseguiamo il debug, non dovremmo preoccuparci in modo ottimale del codice che generiamo e un debugger dovrebbe entrare nel modello di trasformazione. Invece entra nel codice generato e, come tutti sappiamo, le trasformazioni dovrebbero avere un bell'aspetto, non il codice generato. Okey, possiamo piuttosto stamparlo, ma in un mondo ottimale il codice generato è un artefatto del compilatore e non dovrebbe mai essere aperto in un editor per una sessione di debug (potrei conviverci e questo argomento è un po 'teoricamente, ma è una ragione contro la MDA)
• I modelli codificati sono facili: in altri esempi, il Modello potrebbe modellare alcuni aspetti del dominio e che viene quindi compilato in codice. Sì, è MDA, ma la maggior parte dei modelli MDA sono solo file di configurazione sofisticati, che possono essere facilmente gestiti in fase di esecuzione.
• Le trasformazioni sono difficili da testare: se si utilizzano trasformazioni in un IDE specializzato, vengono eseguite dal "compilatore" IDE. Ma le trasformazioni devono essere viste come parte del codice dell'applicazione e come tali dovrebbero anche essere soggette ai requisiti di test e copertura del codice dell'app.

Quello che attualmente preferisco è "Valutazione del modello di runtime" (se qualcuno conosce un nome accettato per questo, per favore illuminami). Le mie entità sono memorizzate in normali classi Java e tutto ciò di cui ho bisogno per "modellare" è fatto da annotazioni che ho letto all'avvio dell'app. Non sono necessarie trasformazioni, è stato solo un po 'difficile ottenere il mio meta-modello giusto.

Tutto il resto viene eseguito con file di proprietà o XML per dati gerarchici. Se hai un modello, è sempre gerarchico, quindi non c'è nulla che puoi modellare che non puoi esprimere anche con XML. E se hai bisogno di un editor di modelli speciali, che probabilmente dovrai anche scrivere, puoi anche creare un editor che funzioni anche in fase di esecuzione dell'app e rendere l'app più configurabile di tutto ciò che potresti modellare.

Sento che la maggior parte delle persone che usano No Silver Bullet di Fred Brooks per spiegare perché le persone che non stanno facendo MDD mancano del punto che Brooks fa. Certo, la conclusione finale è che l'effettiva complessità intrinseca nello sviluppo del software non andrà mai via e quindi MDD non risolverà questo problema.

Ma una delle ragioni per cui Brooks discute persino di questa complessità intrinseca è quella di confrontarla con la grande quantità di tempo che in genere impieghiamo a combattere con linguaggi, librerie e strumenti, vale a dire non affrontando la complessità intrinseca del problema che stiamo cercando di risolvere. Quindi questo è esattamente il punto in cui MDD brilla: tagliando via tutta la confusione e creando un linguaggio, un modello o un altro formalismo su misura per affrontare la vera complessità a portata di mano.

Quindi, da questo punto di vista, No Silver Bullet è un ottimo motivo per investire in MDD. Cioè, se non fosse per il problema che credo ostacola l'adozione dell'MDD: l'effettivo sviluppo di un ambiente basato su modelli che ti consente di concentrarti completamente sulla complessità intrinseca del problema che stai cercando di risolvere è molto più difficile di semplicemente risolvere direttamente il problema in un linguaggio di uso generale. Principalmente perché gli strumenti MDD esistenti sono estremamente complessi.

Confrontalo in questo modo: è molto più semplice scrivere un programma in C che scrivere un compilatore C. Invece di risolvere semplicemente un problema e gestire la cruft in un linguaggio di uso generale, creare un ambiente MDD per altri sviluppatori richiede fondamentalmente di scrivere un programma che risolva tutti i possibili problemi relativi alla cruft nello spazio problematico. È piuttosto impegnativo.

Per quanto ne so, MDE e MDA non soddisfano in modo sufficiente le esigenze dello sviluppatore del controller incorporato. I modelli possono certamente essere usati per descrivere un sistema, ma non credo che lo sviluppatore incorporato sia pronto a fidarsi del modello per fornire il codice sorgente migliore o addirittura corretto.

Esistono numerosi plug-in per Eclipse che consentono a uno sviluppatore di utilizzare il modello per creare / aggiornare il codice Java o il codice Java per creare / aggiornare il modello. Questo sembra uno strumento utile. Sfortunatamente, tutto il mio sviluppo è fatto in ANSI / ISO C e non ci sono plug-in, di cui sono a conoscenza, che mi permetterebbero di fare la stessa cosa.

Inoltre, come può uno sviluppatore indicare al modello di implementare il codice come un HSM guidato da eventi, o qualche altro modello di progettazione, su qualsiasi altro modello di progettazione (o anti-modello)? Se il codice viene aggiornato manualmente per utilizzare un modello di progettazione sconosciuto, il modello può rappresentarlo accuratamente?

Come implementate quelle funzioni che non rientrano in un modello?

Risposta breve ... perché il modello guidato è spesso correlato alla generazione del codice e il codice è fragile; ciò di cui abbiamo bisogno è l'eliminazione del codice e il modello guidato è sicuramente la strada da percorrere.

Alcuni hanno respinto la domanda sostenendo che non esiste un martello d'oro e che lo sviluppo del software è intrinsecamente complesso.

Sono pienamente d'accordo con loro sul fatto che non esiste un martello d'oro, ma non credo che il modello guidato sia una ricerca di martelli d'oro o proiettili d'argento!

Vorrei andare oltre con complessità; ci sono due tipi di complessità uno che io chiamo complessità organica o naturale, complessità che è inerente all'azienda e ai suoi processi ma abbiamo anche complessità cerimoniale.

Complessità che si insinua nell'istruzione di sistema per istruzione, giorno dopo giorno. La complessità cerimoniale - complessità non necessaria - emerge essenzialmente dalla manipolazione incontrollata di codice tecnico con codice orientato al business, ma anche dalla mancanza di struttura e uniformità nel sistema.

Oggi l'intera complessità che tormenta lo sviluppo di sistemi di informazione e causa guasti e vita è la complessità cerimoniale; complessità che può essere eliminata.

La complessità cerimoniale è lo spreco, lo spreco causato dal codice, il valore in meno, il cambiamento inverso, il codice invariante; codice che deve essere ridotto al minimo indispensabile.

Come farlo? Semplice! Non scriverlo e non generarlo, in primo luogo!

Codice tecnico necessario e invariante; codice utilizzato per leggere / scrivere, visualizzare, comunicare ... Ecco dove entrano in gioco i modelli, descrivendo la struttura logica dei dati - aggiungerei in modo relazionale - i modelli possono abilitare la gestione generica della lettura / scrittura standard, la visualizzazione e la comunicazione di dati.

È proprio come un sistema operativo, non lo riscrivi per ogni progetto che usi. Quindi è necessario un motore tecnico che gestisca gli aspetti invarianti del software in base a un modello. Lo chiamo un motore AaaS (Architecture as a Service).

Per quanto riguarda il codice non necessario, è un codice non necessario, quindi potrebbe anche lasciarlo non scritto.

Ciò ci lascia con il necessario codice orientato al business che dovrebbe essere scritto, i dati necessari orientati al business che dovrebbero essere progettati e l'interfaccia utente necessaria e l'esperienza che dovrebbe essere progettata e immaginata.

Eliminando il fragile codice, possiamo abbracciare Architecture as a Service un nuovo paradigma per lo sviluppo del software basato molto più sulla modellazione e la progettazione che sul codice.

Credo che ci siano diverse ragioni, ma una è certa che l'MDD non rientra nel curriculum delle università. In genere il più vicino è un corso che insegna la modellazione e lì i modelli rimangono come schizzi (nessun controllo, generazione di codice, debug a livello di modello). Questo corso di "modellazione" introduce spesso anche UML e gli studenti sono perplessi sul perché apprendere una notazione così ampia e complessa quando il valore dei modelli creati è basso.

Confrontalo con altri campi dell'ingegneria come sviluppatori di hardware embedded o ingegneri di controllo in cui gli studenti hanno un'esperienza abbastanza diversa. Con strumenti come Simulink o Labview gli studenti possono disegnare un modello e poi ti ha generato il codice, o almeno puoi eseguirlo in simulazione.

In passato le università insegnavano compilatori e parser, ma ora dovrebbero insegnare come creare generatori, implementare DSL, ecc.

Lo sviluppo guidato da modelli non ha senso perché si tratta di un approccio dall'alto verso il basso per l'approccio al codice. È impossibile creare un'applicazione in esecuzione completa solo da un modello e quindi MDD è inutile !!

Quello che faccio è usare UML solo a un livello superiore di astrazione per creare lo scheletro della mia applicazione. Intendo creare pacchetti, classi ecc ... quindi iniziare immediatamente a programmare in linguaggio Java.

Ho scoperto che la sincronizzazione live con strumenti come Togethersoft, Omondo era davvero utile quando ho iniziato a modellare per la prima volta nel 2004. Recentemente Omondo ha introdotto una nuova fase che è una sorta di mappatura tra Java, modello e ID del database. Davvero potente e funziona bene nei miei progetti.

I miei diagrammi UML mi aiutano ora ad accelerare il mio progetto e non sono più inutili :-)

MDD aggiunge un altro passo al processo di sviluppo, che è un aspetto negativo in situazioni in cui non esiste un buon modello e la prima soluzione parziale imprevedibile o quasi rotta sul mercato potrebbe vincere la maggior parte dei marmi.

È stato un vero problema avere modelli eseguibili di processi aziendali. In teoria non avresti bisogno di programmatori per quello. La pratica mostra che, con MDE, che far funzionare il modello reale è complicato quanto scrivere un codice.

Direi che per sviluppatori esperti sarebbe molto più semplice compilare le classi generate da UML, piuttosto che preoccuparsi, ad esempio, di ExecutableUML. D'altra parte, per ExecutableUML hai bisogno di una notevole quantità di conoscenze informatiche, quindi non puoi fare affidamento sul fatto che il manager aziendale lo crei da solo. In teoria avrebbe semplicemente combinato blocchi pronti (classi), ma in realtà la "colla" è ciò che causa problemi.

Inoltre, l'utilità di MDE è limitata ai sistemi con molto riutilizzo dei componenti.

MBSE - Model Based Software Engineering è il termine più pertinente.

Mettendo il problema dei vari strumenti che sono in effetti soluzioni puntuali, MBSE richiede un diverso flusso di lavoro del progetto. Il DSML (linguaggio di modellazione specifico del dominio) deve essere al livello di astrazione richiesto per comunicare efficacemente i requisiti per la revisione con le parti interessate. Quindi è necessario trasformare il modello attraverso livelli di perfezionamento sempre crescenti per generare eventualmente codice.

Quando il DSML e i processi di trasformazione / generazione sono pienamente e correttamente implementati, la generazione di artefatti ha un costo molto basso. Ma fino a quando non raggiungi quella fase degli strumenti di debug è molto doloroso.

La maggior parte delle storie di successo di MDD riguarda l'area della Product Line Engineering (PLE) in cui una successione di prodotti simili viene generata utilizzando strumenti consolidati. Naturalmente, molti dei generatori di codice Java sono versioni semplificate di MDD. Alcuni XML in entrata e codice generato.

Hai scritto:

So anche che ci sono molti problemi ... progetti che non sono adatti allo sviluppo guidato da modelli (non abbastanza ripetizione)

Se il tuo codice è ripetitivo, allora hai scelto un linguaggio di programmazione scadente o lo stai usando male. Con lingue migliori, non è necessario ripetere. Considera la libreria Ruby Active Record. Le tabelle del database vengono create scrivendo le migrazioni. Non è necessario ripetere la definizione dello schema in nessun altro posto. Non è necessario definire una classe con membri di dati corrispondenti alle colonne della tabella. Una singola riga di codice collega una classe a una tabella.

Considero lo sviluppo guidato da modelli come una soluzione complessa e inefficiente per linguaggi di programmazione deboli.