Visualizzazione di un'applicazione software complessa [chiusa]

Mi piace usare le lavagne bianche nel mio ufficio e disegnare tutto, questo permette un montaggio rapido perché ti dimenticherai delle cose la prima volta. Le lavagne bianche non sono necessariamente necessarie, è possibile utilizzare la carta o qualsiasi altra cosa sulla parete.

Assicurati di incapsulare tutti i tuoi oggetti / variabili in una forma unica coerente (aiuta in seguito). Inoltre, non è necessario essere dettagliati nella descrizione di variabili / funzioni / classi, ottenere il concetto generale e lasciare che la mente mantenga il resto.

Una volta estratto il diagramma (o almeno quello che si adatta), scattare una foto e salvarla sul mio computer. Una volta che ho fatto l'intera applicazione, apro tutte le immagini in un editor di immagini e ritagliamo tutti i diversi concetti e cosa no nelle singole immagini e le salviamo in una directory.

Esistono diversi strumenti di mind mapping e anche strumenti UML gratuiti che consentono di utilizzare le proprie immagini. puoi costruire flussi complessi che capirai perché utilizza le tue immagini.

Inoltre, per tenere in considerazione l'intera applicazione nella mia testa, in genere ho solo bisogno di un punto di riferimento per ricordare intere sezioni del codice di un'applicazione, quindi questo aiuta davvero a cambiare lo scope.

UML è probabilmente lo strumento meglio standardizzato e comunemente usato per questo. Alcuni dei diagrammi e dei documenti che possono essere generati in UML possono essere estremamente grandi o complessi se usati per documentare sistemi più grandi; tuttavia, alcuni di essi potrebbero essere utili se si desidera raggiungere un equilibrio valore / sforzo (cioè documento sufficiente per avere un buon punto di riferimento senza superare la linea della documentazione diventando più di ostacolo che aiuto).

Mi piace molto il concetto del 4 + 1 Architectural View Model , che suddivide un'architettura in diversi "viste" o prospettive.

Soprattutto per scopi di documentazione interna, è possibile determinare una granularità e un livello di dettaglio per le viste su cui si desidera concentrarsi e per quanto specificamente si desidera documentare una determinata parte del proprio sistema. Cercherò di approfondire le diverse considerazioni che ritengo dovrebbero essere tenute a mente.

Documentazione per diversi livelli

A mio parere, l'approccio migliore tende ad utilizzare la documentazione di livello superiore per l'intero sistema e ad eseguire il drill-down con documenti più dettagliati e specifici quando necessario.

• Potresti voler esaminare i diagrammi di System Architecture (o Communication) per una panoramica di alto livello dei componenti (e usando una buona etichettatura, questo può davvero diventare davvero utile).

• Inoltre, per esaminare la struttura statica del progetto, i diagrammi dei pacchetti sono utili (ti dicono come è strutturato il tuo codice). Questi diagrammi, penso, ti aiuteranno a trovare facilmente le interazioni, riducendo al contempo la quantità di confusione se disponi di sistemi di grandi dimensioni.

• Per essere più specifici, potresti voler generare diagrammi di attività (che sono molto simili ai diagrammi di flusso), per specificare i diversi processi nel tuo sistema. Consiglierei di farlo solo per processi specifici in cui è necessario avere una comprensione molto chiara di ciò che sta accadendo. Inoltre, idealmente, i processi non dovrebbero cambiare molto dopo che sono stati progettati, quindi puoi evitare il problema di sincronicità della documentazione.

• Infine, per i progetti complessi, è possibile esaminare Class e / o Diagrammi dei componenti o una loro variazione, in cui è possibile mappare l'interazione tra diversi pezzi di codice. Ancora una volta, a meno che tu non abbia una qualche forma di generazione automatica del diagramma, a mio parere tende a richiedere molto tempo per sincronizzare il codice e la documentazione.

Pensa a ciò di cui hai bisogno

• Questo non significa "non farlo perché significa più lavoro" significa "non essere stupido e farlo quando non ne hai bisogno, potrebbe essere doloroso in seguito". Perdere tempo a creare documentazione che non si manterrà e i cui benefici non saranno realmente sfruttati non è ciò che si desidera.

• A volte, ciò che aiuta di più è disegnare (lo faccio su carta, sulla scrivania proprio accanto al mio computer) semplici diagrammi che specificano come le cose "comunicano". Creare contenitori e vedere la logica della comunicazione può essere utile - e questo è, in sostanza, ciò che fanno i diagrammi di comunicazione. Vorrei consigliare KISS (Keep It Stupid Simple) e concentrarmi solo sulle parti essenziali quando lo ritieni necessario.