Qual è lo standard per la modellazione di applicazioni moderne prima dello sviluppo?

a current modern consensus

La verità è: al momento, questo è qualcosa che manca al moderno sviluppo del software: un consenso sulla modellazione. L'UML sembra essere una sorta di più piccolo divisore comune, ma in realtà c'è solo consenso sulla notazione, non sulla semantica. Esistono dozzine di opinioni diverse su come interpretare UML per creare codice (forse puoi trovare un'interpretazione che va bene per la tua squadra).

D'altra parte, c'è una guerra santa in corso tra quelle persone "agili" che dicono "non fanno modelli formali, meglio scrivono codice funzionante" e quelle persone "BDUF" (design in grande stile) che stanno pensando strumenti come "MDA" (model driven architecture) sono la soluzione.

Altre persone (ri) hanno scoperto la programmazione basata sul flusso per la progettazione di software moderni come alternativa a UML. Leggi qui e < a href="http://geekswithblogs.net/theArchitectsNapkin/archive/2011/03/20/flow-design-cheat-sheet-ndash-part-ii-translation.aspx"> qui per saperne di più riguardo a questo.

I want my team to model the entire ASP.NET MVC C# application before we even tap out one line of code

Il problema che di solito trovo con un simile approccio è che la mia comprensione della soluzione è sempre incompleta all'inizio. È solo attraverso il perfezionamento come procede il lavoro che vengo a una soluzione finale.

Cercando di progettare l'intera app in anticipo, prima che qualsiasi codice (in tutto tranne le app più semplici) di solito è follia.

Credi davvero di poter disporre in anticipo ogni classe, metodo e struttura dati in dettaglio?

I just want to know some good modeling solutions.

Per quanto riguarda gli strumenti reali per creare modelli, ne ho provati alcuni e finisco sempre con Microsoft Visio.

Di tutti i prodotti che ho provato sembra il più semplice e, in effetti, stabile (la mia esperienza con gli strumenti di modellazione è che sono molto buggy). Per essere onesti, faccio pochissime modellazioni, quindi prendi questa raccomandazione con un pizzico di sale.

EDIT: In realtà, dovrei dire che la maggior parte della mia modellazione è fatta su un blocco note che si trova sulla mia scrivania. Perché faccio piccoli modelli, cerco di tenerlo leggero e al punto. Disegnare un diagramma con carta e penna è molto più efficiente per me che usare il software.

Potresti trovare diagrammi scritti a mano utili per formare le tue idee, prima di metterle in un software di diagrammi.

What type of diagrams should be used and what would the documentation look like?

La maggior parte di ciò che modifico in questi giorni sono diagrammi di interazione. Ancora una volta, non faccio molto la modellazione - proprio dove sento davvero che l'esercizio del disegno del modello aiuta a cementare la mia comprensione.

UML sono un buon punto di partenza, ci sono molti modi semplici per farlo con software gratuiti oa pagamento. Un semplice esempio di uno strumento per creare un UML è qualcosa come i disegni di Google Documenti, i pacchetti più avanzati sarebbero Visio o OmniGraffle.

EDIT: come già detto da molti, se dovessi seguire il percorso UML, ciò non significa che devi modellare completamente tutto, ma puoi arrivare a un consenso su ciò che stai modellando, e in che modo dettagliato i modelli devono essere. Semplici diagrammi UML possono spesso aiutare a definire il codice prima di scriverlo e chiarire alcuni potenziali problemi prima che si presentino.

Come suggerito da @Brett, i diagrammi UML sono i migliori. Con UML è buono avere diagrammi di classe e diagrammi di flusso di lavoro. Questi due coprirebbero la maggior parte delle esigenze di progettazione.

Con il diagramma delle classi puoi modellare i membri di ciascuna entità, il loro livello di sicurezza ecc.

Con il diagramma di flusso di lavoro, puoi modellare quale chiamata di metodo quali chiamate, quali sono il risultato del flusso di lavoro e quale eccezione potrebbe essere visualizzata.

Mentre credo strongmente nel fare alcuni disegni architettonici di base prima di scrivere il codice, penso che fare un disegno dettagliato di tutta l'app sia troppo lavoro.

Di solito creo alcune immagini di contorno in Visio, spesso usando i blocchi predefiniti del "diagramma di flusso" per visualizzare cosa intendo. L'uso di UML spesso si sente formalizzato e invita a troppi dettagli. I disegni di Visio mostrano i blocchi di base dell'applicazione e il tipo di funzionalità che va dove. Se stai usando il framework MVC, per lo più fai semplicemente un esempio disegnando dal web e copiandolo.

Una buona idea è fare alcuni disegni da altri punti di vista. Invece di disegnare tutto, spesso preferisco prendere una funzione specifica del sistema e quindi visualizzarla come:

• Usa diagramma del caso (UML)
• Diagramma di flusso o UML Swim-lane (livello molto alto)
• Panoramica dei componenti architettonici.

Quindi iniziamo la codifica. Durante la codifica sto utilizzando doxygen con l'integrazione di punti per ottenere diagrammi di classe "on-the-fly", ereditarietà, ecc. La visualizzazione della panoramica generata da doxygen è spesso un ottimo modo per vedere la struttura del codice.