Quali sono i vantaggi dei sistemi software di modellazione e di fare tutto nel codice?

Il vantaggio dei sistemi software di modellazione rispetto a tutti nel 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 insegni il nostro sistema a nuovi codificatori, semplicemente non c'è alcun codice al livello di astrazione necessario che si adatta a una lavagna.

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

Questo non significa che non eseguirò uno schizzo UML ogni tanto. Ma non sarò mai il tipo che ti chiede di trasformare un documento UML prima di poterlo codificare. Potrei richiedere che tu prenda 5 minuti e trovi QUALCHE modo di spiegare cosa stai facendo perché non sopporto l'esistenza del codice che solo una persona comprende.

Fowler ha identificato diversi modi in cui le persone utilizzano 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 fai per codificare usando il mouse, ho visto molti provarci. Non ho visto nessuno farlo funzionare davvero. Se lo stai facendo per comunicare faresti meglio ad assicurarti che gli altri ti capiscano. Se lo stai progettando per te è meglio trovarlo e risolvere i problemi mentre lavori. Se tutto procede senza intoppi e la maggior parte del tempo viene speso rendendo le frecce un bell'aspetto, allora smettila e torna al lavoro.

Soprattutto, non produrre diagrammi che ritieni validi più di un giorno. Se in qualche modo puoi, hai fallito. Perché il software è pensato per essere soft. Non passare settimane a trovare gli schemi 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.

I am asking if it makes sense to use (non-code) documents that model the software as the primary source of truth about software design

No. Questo non ha mai senso. Il tuo codice è il tuo documento di progettazione principale, vale a dire "la fonte primaria di verità sulla progettazione del software". Solo il codice descrive esattamente che cosa fa l'applicazione mentre il compilatore prende quel disegno e crea l'applicazione da esso.

Utilizzare sempre diagrammi come documenti di progettazione supplementari, anche se se non vengono generati automaticamente dal codice, bisogna stare attenti a raccontare una storia diversa dal vero design. Se UML galleggia la tua barca, usa quella. Altrimenti, usa qualcos'altro.

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

"So, yes, diagrams can be inappropriate at times. When are they inappropriate? When you create them without code to validate them, and then intend to follow them. There is nothing wrong with drawing a diagram to explore an idea."

Se usi UML per esplorare un progetto, buttali via quando inizi a scrivere il codice. Scrivi un test, quindi scrivi del codice per farlo passare. Ripetere. In questo modo, finirai con un design convalidato. UML non può mai offrirti lo stesso livello di convalida del tuo design.

Most, if not all IT people I know believe that it is beneficial to model software with UML or other types of diagrams before coding.

Non sono d'accordo sul fatto che tutte le persone che conosci lo 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 le attività di progettazione e di codice. Nel 1992, Jack Reeves ha scritto che la codifica è la vera attività di progettazione (anche discussa sul Wiki C2 ).

Questo non significa che le persone abbiano provato a creare strumenti di sviluppo basati su modelli. Esistono strumenti che tentano di generare codice da modelli UML (e non solo diagrammi di classi, ma collegando tra loro vari tipi di diagrammi e generando codice da essi). Ma quelli non sono, almeno da quelli che ho visto, strumenti ampiamente usati.

Questo non significa nemmeno che dovresti andare direttamente dai requisiti alla scrittura del codice. Ci sono alcune decisioni progettuali che sono fondamentali per essere precoci e un certo livello di modellazione può essere utile per assicurarsi che tutti comprendano le opzioni, il loro impatto e possano comunicare. Alcune persone (me compreso) chiamano questa "architettura software" .

Code doesn't lie. It is checked by the compiler or interpreter. It hopefully has automated tests and needs to pass static code analysis. If a module does not interface correctly with another module, it is usually obvious in code because you get an error message.

Questo è davvero il cuore di alcuni aspetti di Agile Modeling, in particolare Specifiche eseguibili e 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) è l'unica fonte di verità è una buona idea.

Even if the diagrams themselves are consistent, you cannot be sure that the code actually implements them. Yes, there are code generators, but they never generate all of the code.

Penso che come regola generale, andare dal codice modello- > sia il modo 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 il testo attorno a loro. E questa generazione di modelli dal codice dovrebbe essere una parte integrante di un processo di generazione e rilascio.

Ci sono strumenti che, a vari livelli, supportano questo per varie lingue. Data la natura delle lingue e dei paradigmi, è più facile per alcuni rispetto ad altri.

I listed some disadvantages of this procedure that make me wonder why so many people (in my experience) consider it as the preferable way of doing software design.

Non penso che queste persone capiscano necessariamente l'ingegneria del software e la progettazione del software. Penso che queste persone stiano guardando ciò che fanno le altre discipline ingegneristiche e la mappano a cose che pensano che gli ingegneri del software dovrebbero fare. Ma stanno ignorando una delle principali differenze. Altre discipline ingegneristiche creano modelli e simulazioni in primo luogo perché è estremamente costoso e richiede molto tempo per costruire il prodotto reale. Nell'ingegneria del software, possiamo prendere pezzi del nostro design e produrre qualcosa che sia verificabile in un ambiente reale in pochissimo tempo e con costi minimi. L'economia è molto diversa.

What are the benefits of modeling software systems vs. doing it all in code?

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

I am asking if it makes sense to use (non-code) documents that model the software as the primary source of truth about software design. I do not have the case in mind where a significant portion of the code is automatically generated from these documents. If this was the case, I would consider the documents themselves as source code and not as a model.

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 dei requisiti, ma forse è troppo strong in tutti gli esempi che potrei dare. Ho usato PlantUML tramite PlantText.com per produrli.

• I diagrammi del caso d'uso possono mostrare le funzioni e le interazioni previste con utenti o sistemi esterni.

• Idiagrammidelleattivitàpossonomostrareiprocessiaziendalicheunsoftwaredevesupportare.

• Idiagrammidistatopotrebberomostrareladinamicaprevistasuunsitoweb:

• Imodellidigangoffourvengonopresentaticomemodellistaticiedinamici.Adesempio,Memento:
  
  

I listed some disadvantages of this procedure that make me wonder why so many people (in my experience) consider it as the preferable way of doing software design.

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, CA, USA, pp. 722-731.
• N. Mangano, T. D. LaToza, M. Petre e A. van der Hoek (2015). Come software progettisti interagiscono con schizzi alla lavagna . In: Transazioni IEEE sull'ingegneria del software, vol. 41, n. 2, pp. 135-156.
• Andrew Forward e Timothy C. Lethbridge. 2008. Problemi e opportunità per il modello-centrico rispetto a code-centric di sviluppo del software: un sondaggio di professionisti del software . In Atti del workshop internazionale 2008 su Modelli in ingegneria del software (MiSE '08). ACM, New York, NY, USA, 27-32.

Noi sviluppatori amiamo usare le immagini per spiegare il nostro mondo, quindi qui è uno con la produzione di una macchina:

• L'auto è il risultato della catena di produzione, come 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, succede spesso a quelli che concepiscono e fanno il documento di progettazione sono gli stessi di quello che produce il codice. Questo non è vero negli altri campi. Tuttavia ciò non significa che tu sia realmente in grado di ottenere lo stesso livello di qualità facendoli tutti insieme.

Rendendo tali documenti prima senza codifica (escludendo qualcosa come una dimostrazione di concetto per la fasabilità, ...):

• Sei sicuro di pensare prima di farlo, codifica 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: la progettazione, l'algoritmo / matematica è qualsiasi tranne che per uno scopo molto specifico (incorporato, in tempo reale, assemblaggio).
• Puoi delegare alle persone meno esperte una buona parte del processo di codifica, mentre le persone più esperte si concentrano solo sulla parte più critica che ha bisogno del livello delle loro abilità. Quelle persone meno esperte impareranno molto su questo.
• Puoi discutere con persone non IT attraverso l'immagine del tuo documento di design, mentre se avessi solo il codice dovresti estrarre un'immagine di ciò che hai fatto, con tutti i rischi 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 ciò che avrà un impatto.
• Il design renderà facile tagliare il tuo software e avere parte del tuo software sviluppato contemporaneamente.
• Scrivere quei dannati test delle unità di reberbazione sarà molto più facile quando non dovrai preoccuparti di dover coprire tutti i casi mentre li codifichi, in un approccio TDD che codifica il test prima che il codice sia facile.
• ...

Nota: quelle affermazioni suppongono che il codice sia davvero il riflesso del design e che siano entrambi aggiornati ...