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

Sto affrontando la mia prima applicazione a livello aziendale e desidero che il mio team modelli l'intera applicazione ASP.NET MVC C # prima ancora di scrivere una riga di codice.

AGGIORNAMENTO: non si intendeva una discussione filosofica su quando documentare / modellare un'applicazione. Fornisci solo risposte per "come" documentare / modellare.

La verità è che ho sempre risparmiato in questo reparto e non ho mai veramente modellato un'applicazione prima. Qual è il modo standard per farlo? Che tipo di diagrammi dovrebbero essere usati e che aspetto avrebbe la documentazione? Sono apprezzati collegamenti a diagrammi di esempio e documentazione.

Durante la ricerca riesco a trovare numerose cose in rete, ma volevo vedere se esiste un consenso moderno attuale su come procedere.

Grazie in anticipo!

Dichiarazione di chiusura

Non avevo idea che fosse un argomento così appiccicoso. Grazie a tutti voi che potreste mettere da parte l'evidente controversia e fornire risposte utili. È stata una discussione interessante per non dire altro :)

Un altro link utile che ho scoperto è questo: /programming/61487/do-you-use-uml-in-agile-development-practices/61519#61519

un consenso moderno attuale

La verità è che attualmente manca qualcosa allo sviluppo di software moderno: un consenso sulla modellazione. UML sembra essere una specie 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 il tuo team).

D'altra parte, c'è una guerra santa in corso tra quelle persone "agili" che dicono "non fare modelli formali, meglio scrivere codice di lavoro" e quelle persone "BDUF" (grande design in primo piano) che pensano strumenti come " MDA "(architettura guidata dal modello) sono la soluzione.

Altre persone (ri) hanno scoperto la programmazione basata sul flusso per la progettazione di software moderna come alternativa a UML. Leggi qui e qui per saperne di più.

Voglio che il mio team modelli l'intera applicazione ASP.NET MVC C # prima ancora di scrivere una riga di codice

Il problema che di solito trovo con un tale approccio è che la mia comprensione della soluzione è sempre incompleta all'inizio. È solo attraverso la raffinatezza man mano che il lavoro procede che giungo a una soluzione finale.

Cercare di progettare l'intera app in anticipo, prima che qualsiasi codice (in tutte le app tranne la più semplice) sia di solito folle.

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

Voglio solo conoscere alcune buone soluzioni di modellazione.

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 realtà, stabile (la mia esperienza con gli strumenti di modellazione è che sono molto corretti). Per essere onesti, faccio pochissima modellazione, quindi prendo questa raccomandazione con un granello di sale.

EDIT: In realtà, dovrei dire che la maggior parte della mia modellazione viene eseguita su un blocco note che si trova sulla mia scrivania. Poiché faccio poca modellazione, cerco di mantenerla leggera e precisa. Disegnare un diagramma con carta e penna è molto più efficiente per me rispetto all'utilizzo del software.

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

Che tipo di diagrammi dovrebbero essere usati e che aspetto avrebbe la documentazione?

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

I diagrammi 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 documenti Google, pacchetti più avanzati sarebbero Visio o OmniGraffle.

MODIFICA: Come indicato da molti, se dovessi seguire il percorso UML, ciò non significa che devi modellare completamente tutto, ma puoi raggiungere un consenso su ciò che stai modellando e su come i modelli devono essere dettagliati essere. I diagrammi UML semplici possono spesso aiutare a disporre il codice prima di scriverlo e chiarire alcuni potenziali problemi prima che si verifichino.

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

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

Con il diagramma del flusso di lavoro, è possibile modellare quale metodo chiama quali chiamate, qual è il risultato del flusso di lavoro e quale sarebbe un'eccezione che potrebbe eventualmente essere visualizzata.

Mentre credo fermamente nel fare alcuni disegni architettonici di base prima di scrivere codice, penso che fare un disegno dettagliato dell'intera app sia troppo lavoro.

Di solito creo alcune immagini di contorno in Visio, spesso usando i blocchi "diagramma di flusso" per visualizzare ciò che intendo. L'uso di UML sembra spesso formalizzato e invita a troppi dettagli. I disegni di Visio mostrano i componenti di base dell'applicazione e quale tipo di funzionalità va dove. Se si utilizza il framework MVC, la maggior parte viene eseguita semplicemente prelevando un campione dal Web e copiandolo.

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

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

Quindi iniziamo a programmare. Durante la codifica sto usando doxygen con l'integrazione dei punti per ottenere diagrammi di classe al volo, ereditarietà ecc. La visualizzazione della panoramica generata da doxygen è spesso un ottimo modo per vedere la struttura del codice.