Quali sono i vantaggi della modellazione di sistemi software rispetto a fare tutto nel codice?

La maggior parte, se non tutte le persone IT che conosco, ritengono che sia utile modellare il software con UML o altri tipi di diagrammi prima della codifica. (La mia domanda non riguarda UML in particolare, potrebbe essere una descrizione grafica o testuale del design del software.)

Non ne sono così sicuro. Il motivo principale è: il codice non mente. Viene controllato dal compilatore o dall'interprete. Si spera che abbia test automatizzati e debba passare l'analisi del codice statico. Se un modulo non si interfaccia correttamente con un altro modulo, di solito è evidente nel codice perché viene visualizzato un messaggio di errore.

Tutto ciò non può essere fatto con diagrammi e altri documenti. Sì, ci sono strumenti che controllano UML, ma tutto ciò che ho visto finora è molto limitato. Pertanto questi documenti tendono ad essere incompleti, incoerenti o semplicemente falsi.

Anche se i diagrammi stessi sono coerenti, non si può essere sicuri che il codice li implementi effettivamente. Sì, ci sono generatori di codice, ma non generano mai tutto il codice.

A volte mi sembra che l'ossessione per la modellazione derivi dall'ipotesi che il codice debba inevitabilmente essere un pasticcio incomprensibile che architetti, designer o altre persone ben pagate che ottengono il quadro generale non dovrebbero avere a che fare. Altrimenti sarebbe troppo costoso. Pertanto, tutte le decisioni di progettazione devono essere allontanate dal codice. Il codice stesso dovrebbe essere lasciato agli specialisti (scimmie di codice) che sono in grado di scriverlo (e forse leggerlo) ma non devono occuparsi di nient'altro. Questo probabilmente aveva senso quando l'assemblatore era l'unica opzione, ma i linguaggi moderni consentono di codificare a un livello molto alto di astrazione. Quindi non vedo più la necessità di modellare.

Quali argomenti per la modellazione dei sistemi software mi mancano?

A proposito, credo che i diagrammi siano un ottimo modo per documentare e comunicare alcuni aspetti della progettazione del software, ma ciò non significa che dovremmo basare la progettazione del software su di essi.

Una precisazione:

La domanda è stata sospesa in quanto poco chiara. Pertanto, vorrei aggiungere qualche spiegazione:

Sto chiedendo se abbia senso usare documenti (non codificati) che modellano il software come fonte primaria di verità sulla progettazione del software. Non ho in mente il caso in cui una parte significativa del codice viene generata automaticamente da questi documenti. Se così fosse, considererei i documenti stessi come codice sorgente e non come modello.

Ho elencato alcuni svantaggi di questa procedura che mi fanno pensare al motivo per cui così tante persone (nella mia esperienza) lo considerano il modo preferibile di progettare il software.

Il vantaggio di modellare i sistemi software rispetto a tutto il codice è: posso adattare il modello su una lavagna.

Sono un grande sostenitore della magia di comunicare su un foglio di carta. Se provassi a mettere il codice sulla lavagna, quando insegnavo il nostro sistema a nuovi programmatori, semplicemente non c'era nessun codice al livello necessario di astrazione che si adatta a una lavagna.

Conosco l'ossessione per la modellazione a cui ti stai riferendo. Le persone fanno le cose perché è così che sono state fatte prima, senza pensare al perché. Sono venuto per chiamarlo formalismo. Preferisco lavorare in modo informale perché è più difficile nascondere la stupidità dietro la tradizione.

Ciò non significa che non tirerò fuori uno schizzo UML di tanto in tanto. Ma non sarò mai il tipo che ti chiede di consegnare un documento UML prima di poter scrivere il codice. Potrei richiedere che tu impieghi 5 minuti e trovi ALCUNI modi per spiegare cosa stai facendo perché non sopporto l'esistenza di codice che solo una persona capisce.

Fowler ha identificato diversi modi in cui le persone usano UML che ha chiamato modalità UML . La cosa pericolosa con tutti loro è che possono essere usati per nascondersi dal fare un lavoro utile. Se lo stai facendo per programmare usando il mouse, ho visto molti provare. Non ho visto nessuno farlo funzionare davvero. Se lo stai facendo per comunicare, è meglio assicurarsi che gli altri ti capiscano. Se lo stai facendo per progettare, è meglio trovare e risolvere i problemi mentre lavori. Se tutto procede senza intoppi e la maggior parte del tuo tempo viene impiegato per rendere belle le frecce, buttalo giù e torna al lavoro.

Ancora più importante, non produrre diagrammi che ritieni validi per più di un giorno. Se in qualche modo puoi, hai fallito. Perché il software è pensato per essere morbido. Non passare settimane a ottenere i diagrammi giusti. Dimmi solo cosa sta succedendo. Se devi, usa un tovagliolo.

Detto questo, preferisco i programmatori che conoscono il loro UML e i loro modelli di progettazione. Sono più facili da comunicare. Finché sanno che produrre diagrammi non è un lavoro a tempo pieno.

Sto chiedendo se abbia senso usare documenti (non codificati) che modellano il software come fonte primaria di verità sulla progettazione del software

No. Questo non ha mai senso. Il tuo codice è il documento di progettazione principale, ovvero "la principale fonte di verità sulla progettazione del software". Solo il codice descrive esattamente cosa fa l'applicazione mentre il compilatore prende quella progettazione e crea l'applicazione da essa.

Sicuramente usa i diagrammi come documenti di progettazione supplementari, anche se se non sono generati automaticamente dal codice, fai attenzione a raccontare una storia diversa al progetto reale. Se UML fa galleggiare la tua barca, usalo. Altrimenti, usa qualcos'altro.

Alcune persone trovano utile abbozzare il loro pensiero in forma di diagramma prima di iniziare a scrivere codice. Ma ricorda cosa ha detto lo zio Bob in materia:

" Quindi, sì, a volte i diagrammi possono essere inappropriati. Quando sono inappropriati? Quando li crei senza codice per convalidarli, e poi intendi seguirli. Non c'è nulla di sbagliato nel disegnare un diagramma per esplorare un'idea. "

Se usi UML per esplorare un disegno, gettali via quando inizi a scrivere codice. Scrivi un test, quindi scrivi del codice per farlo passare. Ripetere. In questo modo, finirai con un design validato. UML non potrà mai offrirti lo stesso livello di convalida del tuo progetto.

La maggior parte, se non tutte le persone IT che conosco, ritengono che sia utile modellare il software con UML o altri tipi di diagrammi prima della codifica.

Non sono d'accordo sul fatto che tutte le persone che conosci ci credano, ma non penso che sia necessariamente comune su tutta la linea. Nel 1970, Winston Royce sapeva che lo sviluppo del software aveva un certo livello di iterazione tra attività di progettazione e codice. Nel 1992, Jack Reeves ha scritto che la programmazione è la vera attività di progettazione ( discussa anche sul Wiki C2 ).

Ciò non significa che le persone abbiano cercato di creare strumenti di sviluppo basati sui modelli. Esistono strumenti che tentano di generare codice dai modelli UML (e non solo diagrammi di classe, ma che collegano insieme vari tipi di diagrammi e generano codice da essi). Ma quelli non sono, almeno da quello che ho visto, strumenti ampiamente usati.

Questo non significa anche che dovresti passare dai requisiti alla scrittura del codice. Ci sono alcune decisioni di progettazione che sono fondamentali per arrivare subito e un certo livello di modellazione può essere utile per assicurarsi che tutti comprendano le opzioni, il loro impatto e possano comunicare. Alcune persone (incluso me stesso) la chiamano "architettura software" .

Il codice non mente. Viene controllato dal compilatore o dall'interprete. Si spera che abbia test automatizzati e debba passare l'analisi del codice statico. Se un modulo non si interfaccia correttamente con un altro modulo, di solito è evidente nel codice perché viene visualizzato un messaggio di errore.

Questo è davvero il cuore di alcuni aspetti della modellazione agile, in particolare delle specifiche eseguibili e della singola fonte di informazioni . Non sono necessariamente d'accordo con TDD, ma l'idea di avere il tuo codice e i test associati (dall'unità ai test di accettazione, preferibilmente catturati come test automatici) sia l'unica fonte di verità è una buona idea.

Anche se i diagrammi stessi sono coerenti, non si può essere sicuri che il codice li implementi effettivamente. Sì, ci sono generatori di codice, ma non generano mai tutto il codice.

Penso che come regola generale, passare dal codice modello-> sia sbagliato. Invece, il codice dovrebbe generare modelli. Cioè, gli strumenti dovrebbero essere in grado di esaminare il codice e generare rappresentazioni grafiche e tabulari che possono essere ulteriormente migliorate mentre gli ingegneri scrivono del testo attorno a loro. E questa generazione di modelli dal codice dovrebbe essere parte integrante di un processo di compilazione e rilascio.

Esistono strumenti che, a vari livelli, lo supportano in varie lingue. Data la natura delle lingue e dei paradigmi, per alcuni è più facile di altri.

Ho elencato alcuni svantaggi di questa procedura che mi fanno pensare al motivo per cui così tante persone (nella mia esperienza) lo considerano il modo preferibile di progettare il software.

Non penso che queste persone capiscano necessariamente l'ingegneria del software e la progettazione del software. Penso che queste persone guardino cosa fanno le altre discipline ingegneristiche e lo mappino su cose che pensano che gli ingegneri del software dovrebbero fare. Ma stanno ignorando una grande differenza. Altre discipline ingegneristiche creano prima modelli e simulazioni perché è estremamente costoso e richiede tempo per costruire il prodotto reale. Nell'ingegneria del software, possiamo prendere pezzi del nostro design e produrre qualcosa che è testabile in un ambiente reale in pochissimo tempo e con costi molto bassi. L'economia è molto diversa.

Quali sono i vantaggi della modellazione di sistemi software rispetto a fare tutto nel codice?

Quando hai un sistema software estremamente complesso, avere modelli significa avere qualcosa che è più facile da capire. È un diverso livello di astrazione, qualcosa che aiuta le persone a comprendere le varie sfaccettature del sistema. È uno dei motivi per cui ci sono così tanti linguaggi di modellazione diversi e diversi tipi di modelli consentiti da ogni linguaggio di modellazione o notazione - per consentire alle diverse parti interessate di comprendere, concettualmente, il sistema software in modo rapido e semplice.

Sto chiedendo se abbia senso usare documenti (non codificati) che modellano il software come fonte primaria di verità sulla progettazione del software. Non ho in mente il caso in cui una parte significativa del codice viene generata automaticamente da questi documenti. Se così fosse, considererei i documenti stessi come codice sorgente e non come modello.

Molti documenti non di codice sono utili come progetti . Cioè, la "verità" del design dovrebbe seguire questa direzione. È un modo per modellare elementi che un design deve soddisfare. Potresti chiamarli documenti di requisiti, ma forse è troppo forte in tutti gli esempi che potrei dare. Ho usato PlantUML tramite PlantText.com per produrli.

• I diagrammi dei casi d'uso possono mostrare le funzionalità e le interazioni previste con utenti o sistemi esterni.

• I diagrammi di attività possono mostrare i processi aziendali che un software deve supportare.

• I diagrammi di stato potrebbero mostrare la dinamica desiderata su un sito Web:

• I modelli di design Gang of Four sono presentati come modelli statici e dinamici. Ad esempio, Memento:
  
  

Ho elencato alcuni svantaggi di questa procedura che mi fanno pensare al motivo per cui così tante persone (nella mia esperienza) lo considerano il modo preferibile di progettare il software.

Se sei interessato ad alcune informazioni reali sull'uso di UML al di fuori della tua esperienza, ci sono alcuni studi che sono stati fatti (ho cercato di trovare collegamenti ad articoli non paywall):

• Petre, Marian (2013). UML in pratica . In: 35a Conferenza internazionale sull'ingegneria del software (ICSE 2013), 18-26 maggio 2013, San Francisco, California, USA, pagg. 722–731.
• N. Mangano, TD LaToza, M. Petre e A. van der Hoek (2015). In che modo i progettisti di software interagiscono con gli schizzi alla lavagna . In: Transazioni IEEE sull'ingegneria del software, vol. 41, n. 2, pagg. 135-156.
• Andrew Forward e Timothy C. Lethbridge. 2008. Problemi e opportunità per lo sviluppo di software incentrato sul modello e incentrato sul codice: un sondaggio tra professionisti del software . In Atti del seminario internazionale 2008 sui modelli nell'ingegneria del software (MiSE '08). ACM, New York, NY, USA, 27-32.

A noi sviluppatori piace usare le immagini per spiegare il nostro mondo, quindi eccone uno con la produzione di un'auto:

• L'auto è il risultato della catena di produzione, lo stesso per il codice (aggiungere ovviamente il processo di distribuzione).
• Il documento di progettazione dell'auto è lo stesso del documento di progettazione del software.

Nei nostri mondi, accade spesso che coloro che concepiscono e realizzano il documento di progettazione siano gli stessi di quelli che producono il codice. Questo non è vero negli altri campi. Tuttavia, ciò non significa che sei davvero in grado di ottenere lo stesso livello di qualità facendoli tutti insieme.

Creando prima quel documento senza codifica (escludendo qualcosa come una prova di concetto per la fattibilità, ...):

• Sei sicuro di pensare prima di fare, programmare una volta che sai cosa devi fare è FACILE.
• Sei in grado di mettere le persone più esperte a concentrarsi sulla parte più difficile del tuo software: progettazione, algoritmo / matematica è qualsiasi tranne per scopi molto specifici (incorporato, tempo reale, assemblaggio).
• Puoi delegare a persone meno esperte una buona parte del processo di codifica, mentre le persone più esperte si concentrano solo sulla parte più critica che necessita del livello delle loro competenze. Quelle persone meno esperte impareranno molto al riguardo.
• Puoi discutere con persone non IT attraverso l'immagine del tuo documento di progettazione, mentre se avessi solo il codice dovresti estrarre un'immagine di ciò che hai fatto, con il rischio di dimenticare qualcosa (un ascoltatore dimenticato da qualche parte ...). Vedi la risposta di CandiedOrange per ulteriori aspetti sulla comunicazione.
• Quando devi far evolvere il tuo software, puoi anticipare meglio quale sarà l'impatto.
• Il design semplifica la riduzione di parte del software e lo sviluppo simultaneo di parte del software.
• Scrivere quei dannati test unitari reberbativi sarà molto più facile quando non devi avere mal di testa per essere in grado di coprire tutti i casi mentre li codifichi, in un approccio TDD codificare il test prima che il codice sia facile.
• ...

Nota: queste affermazioni suppongono che il codice rispecchi davvero il design e che entrambi si tengano aggiornati ...