Mi piace pensare che tutto ciò che ci circonda possa essere rappresentato, in un modo o nell'altro, attraverso un diagramma. Anche se è solo un diagramma lineare che rappresenta la transizione tra gli stati di un particolare oggetto nel tempo (come un essere vivente, attraversando un certo numero di stati dalla nascita alla morte). Uso i diagrammi per definire i miei pensieri e le mie idee per l'implementazione effettiva. Improvviso parecchio.
Pertanto, i miei diagrammi sono per lo più a un livello molto alto e sembrano mappe mentali .
Per fare alcuni esempi, questa è in realtà una mappa di eredità di classe (una che è stata tagliata) nel mio gioco in cui Interactive Object è il tipo di base.
Questo è un diagramma FSM ( macchina a stati finiti ) per una trappola a spike (quelle trappole fantastiche su cui calpesti e che spuntano picchi da terra).
Questo è un diagramma del manuale (chiamato in questo modo perché è destinato a tornare al diagramma spesso ) che ho disegnato di recente. Descrive i componenti di un gioco e aiuta anche a raccogliere le risorse necessarie, poiché puoi vedere immediatamente ciò che è necessario e ciò che non lo è. Raccomando questi su piccoli progetti, in quanto diventano piuttosto grandi su quelli grandi. Tuttavia, possono essere ulteriormente ampliati, in modo da poter risolvere le cose.
Quando vado a un livello inferiore, di solito è perché devo pianificare gli aspetti più complessi della mia architettura, e di solito mi occupo di UML. Non mi concentro mai sulla produzione di UML assolutamente pulito e corretto. Ho adottato ciò che mi è piaciuto di più della convenzione UML e l'ho trasformato in un simpatico UML mindmap. È semplice e fa il lavoro per me, ma non andrei con esso in un ambiente in cui ci si aspetta UML reale, per ovvi motivi.
Un'altra situazione in cui devo passare a un livello inferiore è quando devo descrivere algoritmi reali. Uso quelli che chiamo diagrammi di flusso . È un formato ispirato ai diagrammi utilizzati nei test su scatola bianca .
Un esempio per la trappola a punta che ho disegnato in questo momento sarebbe simile a questo:
Questo è normalmente lo strato finale tra i diagrammi e le implementazioni effettive dell'algoritmo. Se si presenta la necessità, dettagliamo ulteriormente i diagrammi di flusso (con ulteriori istruzioni eseguite), deducendo o stimando la complessità e costruendo casi di test accurati. Preferisco anche diagrammi rispetto allo pseudocodice.
Non legato allo sviluppo del gioco, ho anche un bel formato per descrivere le schermate in un'app multi-schermo, la funzionalità che l'utente può attivare su ciascuna schermata e la relazione tra le schermate. Normalmente li costruisco prima di iniziare lo sviluppo reale e si comportano come una mappa durante tutto il processo di sviluppo. Se è per un cliente, il diagramma dello schermo è ancora più utile! Mi aiuta a seguire tutto il progetto, dall'inizio alla fine, e prendere in considerazione tutte le funzionalità di cui avrà bisogno. Pertanto, è prezioso fornire una stima accurata dei costi e dei tempi.
Quindi sì, ho sicuramente diagramma tutto e tutto. Se ho un'idea, posso e sicuramente disegnerò un diagramma per questo. Se in qualche modo inizio un progetto senza almeno un diagramma molto ampio per supportarmi, mi sento paralizzato.