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

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

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

Domanda interessante! Ammetto, non sono un fan, ma poi ho provato a utilizzare lo sviluppo guidato dal modello più volte in progetti che rispondono ad alcuni dei problemi che hai appena sollevato.

Ecco il mio elenco di motivi:

• curva di apprendimento - gli strumenti di modellazione si sono evoluti così rapidamente che ho difficoltà a trovare ingegneri che capiscano a fondo lo strumento. Trovo ancora che tu sia buono come il tuo strumento di modellazione. Certo, molti dei problemi sottostanti potrebbero rintracciare questo problema: ogni volta che pensi che uno strumento sia troppo limitante, è possibile che tu non lo conosca abbastanza bene.
• Troppo strutturato - Personalmente, sono stato in situazioni in cui ho scoperto che lo strumento di modellazione era semplicemente troppo strutturato per permettermi di descrivere tutto ciò di cui avevo bisogno di descrivere. E una volta passato a disegnare alcune parti del modello al di fuori dello strumento, le cose si deteriorano rapidamente mentre le persone iniziano ad andare alla deriva fuori dallo 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 che cosa lo strumento riteneva giusto. So che dopo un po 'di giri, questo problema diminuisce, ma ciò significa che devi sopravvivere ai primi round. In generale ho sentito che stavamo giocando a whack un modello di mole - make - > genera codice - > codice di correzione - > aggiorna il modello - > correggi modello, risciacquo e amp; ripetere.
• Gestione della configurazione del modello - poiché il modello descrive grandi parti del progetto, a un certo livello il modello CM sarà più trasversale rispetto al codice costruito. Il compartimentalizzazione dei file di modellazione è un'arte in sé - fallo male e spesso finisci con lo stallo dello sviluppatore, o modelli scaduti, dato che le persone si arrendono e scendono al codice.
• time to market - Ho riscontrato problemi precisi in una situazione in cui era urgente la necessità di software di lavoro. Se il progetto e il team sono abbastanza piccoli, non vedo alcun motivo per perdere tempo in uno strumento di modellazione quando il tempo può essere impiegato per programmare e testare. Non tutti i progetti sono abbastanza grandi da richiedere tale investimento.
• Costo del fallimento - quando ho visto i progetti scappare dagli strumenti di modellazione, è a causa dell'elevato costo del fallimento - per utilizzare gli strumenti, è necessario coinvolgere tutti gli sviluppatori. Questo è un grande investimento nella formazione e nell'apprendimento, 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 - così tanti progetti non sopravvivono agli errori di modellazione abbastanza a lungo da realizzare i benefici.

È già stato citato, ma No Bullet d'argento indirizza il punto piuttosto bene:

The essence of a software entity is a construct of interlocking concepts: data sets, relationships among data items, algorithms, and invocations of functions. This essence is abstract in that such a conceptual construct is the same under many different representations. It is nonetheless highly precise and richly detailed.

I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation. We still make syntax errors, to be sure; but they are fuzz compared with the conceptual errors in most systems.

If this is true, building software will always be hard. There is inherently no silver bullet.

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

For almost 40 years, people have been anticipating and writing about "automatic programming," or the generation of a program for solving a problem from a statement of the problem specifications. Some today write as if they expect this technology to provide the next breakthrough.

Parnas implies that the term is used for glamour, not for semantic content, asserting, "In short, automatic programming always has been a euphemism for programming with a higher-level language than was presently available to the programmer."

He argues, in essence, that in most cases it is the solution method, not the problem, whose specification has to be given.

Fondamentalmente, direi che MDD è solo un altro eufemismo per programmare con un linguaggio di livello superiore rispetto a prima disponibile.

Questo non vuol dire che la programmazione in un linguaggio di livello superiore non possa essere di aiuto, anzi spesso lo è. Ma la essenza del problema rimane la stessa: non importa quanto grande sia uno strumento o quanto sia grande il linguaggio che usi, alla fine della giornata tu devi pensare attraverso tutti i problemi e risolvere i problemi. Il meglio che qualsiasi strumento o processo può fare è rimuovere il "fuzz" in modo che tu possa concentrarti sull'importante problema, che è, come ha detto Brooks, "la specifica , design e test di questo costrutto concettuale ".

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

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

Perché Modellazione! = Programmazione.

Perché il rapporto costi / benefici era troppo alto dal punto di vista dei costi e non abbastanza dal lato dei benefici. Questo probabilmente è cambiato dall'ultima volta che ho visto MDD, a quel punto dovresti pagare > $ 6000 / seat (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 i modelli ad alto livello e poi elaborano i dettagli con il codice. Vedete le cose in modo diverso nel codice di quanto non facciate nel software di modellazione.

Queste sono alcune delle ragioni 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:)

Quale tipo di sviluppo viene reso popolare ha molto a che fare con gli strumenti, il sostegno e l'evangelizzazione. È molto difficile sfondare con qualcosa senza avere un grande backer (Ruby on rails 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 così:

Ottenere tra un programmatore e il suo codice è molto costoso.

Se lo fai, devi compilare un compilatore / interprete appropriato, i generatori di codice generano un terribile flusso di lavoro e feedback terribili al programmatore (messaggi di errore e simili).

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

In definitiva la domanda è: perché i tuoi modelli non si adattano al codice? Se stai facendo uno sviluppo integrato e sei bloccato con C o hai bisogno di generare codice per piattaforme diverse, la generazione del codice potrebbe valerne il costo. Per tutti gli altri, un linguaggio di programmazione più potente e una migliore progettazione del codice sono in genere migliori rispetto alla progettazione del codice in qualcosa di diverso dal codice.

• Sembra una seccatura gigantesca per pochissimi benefici.
• Sembro sempre affogato con casi limite e cose strane, le cose magiche non sembrano mai funzionare correttamente.
• OO non è un proiettile d'argento; abbattere una metodologia generatrice di software su OO non la rende argento.

Ma non mi piacciono le soluzioni aziendali in generale.

Ho avuto la discussione e mi piacerebbe fare 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 parleremo più avanti.

Gli svantaggi di MDA sono, come so:

• Supporto per il refactoring mancante: suppongo di voler modellare le entità del mio datamodel con MDA (tipico numero di serie n. 1). Se ho il mio modello in, 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 con un nome migliore, ottengo un molti errori devo correggere manualmente.
• Supporto per il debug mancante: di solito le traduzioni da modello a codice avvengono avendo un linguaggio di trasformazione a portata di mano. Di solito non sarebbe 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 apparire buone, non il codice generato. Okey, possiamo benissimo 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 'teorico, ma è una delle ragioni contro la MDA)
• I modelli codificati sono semplici: 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 sofisticati file di configurazione, che potrebbero essere facilmente gestiti in fase di runtime.
• Le trasformazioni sono difficili da verificare: se si utilizzano le trasformazioni in un IDE specializzato, vengono eseguite dal "compilatore" degli IDE. Ma le trasformazioni devono essere viste come parte del codice dell'applicazione, e come tali dovrebbero anche essere sottoposte ai requisiti di test e di copertura del codice dell'app.

Quello che attualmente preferisco è "Valutazione del modello di runtime" (se qualcuno conosce un nome accettato per questo mi illumini). Le mie entità sono archiviate in normali classi Java e tutto ciò di cui ho bisogno per "modellare" è fatto dalle annotazioni che ho letto all'inizio dell'app. Nessuna trasformazione necessaria, era solo un po 'difficile ottenere il mio metamodello giusto.

Tutto il resto viene eseguito con file di proprietà o XML per i 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 speciale, che probabilmente dovrai anche scrivere, puoi anche creare un editor che funzioni anche in fase di esecuzione dell'app e rende l'app più configurabile di tutto ciò che potresti modellare.

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

Ma una delle ragioni per cui Brooks discute anche di questa complessità intrinseca è quella di confrontarlo con la grande quantità di tempo che normalmente impieghiamo a combattere con linguaggi, librerie e strumenti, cioè non affrontare la complessità intrinseca del problema che stiamo cercando di risolvere. Quindi questo è esattamente il punto in cui MDD brilla: tagliare tutto il fuzz e creare un linguaggio, un modello o un formalismo su misura per affrontare la vera complessità a portata di mano.

Quindi da questa prospettiva, No Silver Bullet è un'ottima ragione per investire in MDD. Cioè, se non fosse per il problema che credo ostacola l'adozione di MDD: l'effettivo sviluppo di un ambiente guidato dal modello che ti permette di concentrarti completamente sulla complessità intrinseca del problema che stai cercando di risolvere è molto più difficile di solo risolvendo direttamente il problema in una lingua generica. 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 un problema e gestire il cruft in un linguaggio generico, creare un ambiente MDD per altri sviluppatori richiede di scrivere fondamentalmente un programma che risolva tutti i possibili problemi relativi a cruft nello spazio del problema. È piuttosto impegnativo.

A mia conoscenza, MDE e MDA non rispondono in modo adeguato alle esigenze dello sviluppatore del controller integrato. I modelli possono certamente essere utilizzati 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 permettano di fare la stessa cosa.

Inoltre, in che modo uno sviluppatore può istruire il modello a implementare il codice come un HSM event-driven, o qualche altro modello di progettazione, su qualsiasi altro modello di progettazione (o anti-pattern)? Se il codice viene aggiornato manualmente per utilizzare uno schema di progettazione sconosciuto, il modello può esattamente raffigurarlo?

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 penso che il modello guidato sia una ricerca di martelli d'oro o di proiettili d'argento!

Mi piacerebbe andare oltre con la complessità; ci sono due tipi di complessità, che io chiamo complessità organica o naturale, complessità intrinseca al business e ai suoi processi, ma anche complessità cerimoniale.

Complessità che si insinua nelle istruzioni del sistema con istruzioni, giorno dopo giorno. La complessità cerimoniale - complessità non necessaria - emerge essenzialmente dalla manipolazione incontrollata del codice tecnico con il codice orientato al business, ma anche dalla mancanza di struttura e uniformità del sistema.

Oggi l'intera complessità che perseguita lo sviluppo dei sistemi di informazione e causa il fallimento e la vita è una complessità cerimoniale; complessità che può essere eliminata.

La complessità cerimoniale è uno spreco, uno spreco causato dal codice, un valore inferiore, un codice negativo invariante; codice che deve essere ridotto al minimo.

Come si fa? Semplice, non scriverlo e non generarlo, in primo luogo!

Codice tecnico necessario e invariante; codice che viene usato per leggere / scrivere, visualizzare, comunicare ... Ecco dove entrano 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, ciò che è necessario è un motore tecnico che gestisca gli aspetti invarianti del software dato un modello. Lo chiamo un motore AaaS (Architecture as a Service).

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

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

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

Credo che ci siano diversi motivi, ma uno è sicuro che MDD non è 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" spesso introduce 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 settori dell'ingegneria, come sviluppatori di hardware embedded o ingegneri di controllo, in cui gli studenti hanno un'esperienza diversa. Con strumenti come Simulink o Labview gli studenti possono disegnare un modello e quindi generare il codice, o almeno eseguirlo in simulazione.

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

Model Driven Development è un non senso perché si tratta di un approccio top-down al codice. È impossibile creare un'applicazione in esecuzione completa solo da un modello e quindi MDD è inutile !!

Quello che faccio è usare UML al massimo livello di astrazione per creare lo scheletro della mia applicazione. Voglio dire creare pacchetti, classi ecc ... quindi iniziare immediatamente a codificare in linguaggio Java.

Ho scoperto che la sincronizzazione live con strumenti come Togethersoft, Omondo erano davvero utili quando ho iniziato la modellazione per la prima volta nel 2004. Una nuova fase è stata recentemente introdotta da Omondo 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 a velocizzare il mio progetto e non sono più inutili: -)

MDD aggiunge un altro passo al processo di sviluppo, che è uno svantaggio in situazioni in cui non esiste un buon modello e la prima soluzione parziale al mercato, imprevedibile o quasi aleatoria, potrebbe vincere la maggior parte delle biglie.

È stato Holly Grail avere modelli di processi aziendali eseguibili. In teoria non avresti bisogno di programmatori per questo. La pratica dimostra, con MDE, che far funzionare il modello reale è altrettanto complicato della scrittura del codice.

Direi che per sviluppatori esperti sarebbe molto più facile compilare le classi generate da UML, piuttosto che occuparsi, ad esempio, di ExecutableUML. D'altro canto, per ExecutableUML è necessaria una notevole quantità di conoscenze informatiche, quindi non si può contare sul fatto che il manager aziendale lo crei da solo. In teoria avrebbe solo unire i 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 - L'ingegneria software basata su modello è il termine più pertinente.

Mettendo il problema dei vari strumenti che sono in effetti soluzioni a punti, 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 in modo efficace i requisiti da rivedere con gli stakeholder. Quindi è necessario trasformare il modello attraverso livelli sempre crescenti di raffinamento per generare il codice.

Quando i processi DSML e di trasformazione / generazione sono implementati completamente e correttamente, la generazione di risorse utente ha un costo molto basso. Ma fino a quando non si raggiunge quella fase di strumenti debug è molto doloroso.

La maggior parte delle storie di successo per MDD si trovano nell'area del 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 e generato il code out.

Hai scritto:

I also know there are a lot of problems... projects that just aren't right for model driven development (not enough repetition)

Se il tuo codice è ripetitivo, o hai scelto un linguaggio di programmazione scadente o lo stai usando male. Con lingue migliori, non c'è bisogno di ripetizioni. Considerare 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 i membri dati corrispondenti alle colonne della tabella. Una singola riga di codice collega una classe a una tabella.

Considero lo sviluppo basato sui modelli come una soluzione complessa e inefficiente per i linguaggi di programmazione deboli.