Sto cercando il tipo corretto di diagramma in cui posso vedere tutte le dipendenze tra le funzioni, le classi e i file del mio programma Python (più file). È per scopi di pulizia.
Quindi la mia domanda è: quale schema dovrei usare? Ho pensato a Class Diagram, ma non ci sono dipendenze tra le funzioni (quale funzione usa quale funzione, quale classe o file usa le funzioni da quale classe o file, ecc.).
Una volta ho partecipato a un progetto Python in cui dovevamo impiegare alcune fasi di elaborazione dei dati piuttosto lunghe e confuse. Per mantenere la modularità minima, abbiamo sviluppato un sistema in cui i dati passerebbero da una classe all'altra attraverso una catena molto lunga. Ogni collegamento a catena avrebbe solo bisogno di conoscere l'interfaccia di chiamata del "prossimo" passo della catena. In questo modo abbiamo potuto testare il processo generale testando le interazioni tra i collegamenti adiacenti (classi e / o moduli) e ad ogni "link" solo la logica di elaborazione necessaria e specifica. Si noti che il "flusso lungo" era in realtà una logica / requisito di dominio.
In pochissimo tempo questa struttura ha portato a un codice molto, molto intrattabile. Il problema era che la catena del flusso era troppo lunga, rendendo impossibile interpretare la logica di elaborazione da una prospettiva più elevata (cioè il quadro generale). Sebbene fossimo in grado di comprendere chiaramente i passaggi di adiacenza, non siamo riusciti a vedere come i dati venivano elaborati / modellati lungo tutta la catena.
Abbiamo quindi deciso di utilizzare un diagramma di attività, in cui abbiamo provato a mappare i diversi flussi di programma, le decisioni, le chiamate ai metodi, eccettera. Abbiamo scelto un diagramma di attività per il fatto che ti consente di passare dal livello di dettaglio interno alla procedura a livello di classe o livelli di comunicazione / interazione. Potremmo astrarre quando necessario e potremmo immergerci nella logica dell'algoritmo quando necessario.
Abbiamo usato le corsie di nuoto per rappresentare classi / moduli, e al loro interno abbiamo raffigurato tutti i dettagli necessari di ciò che questa classe avrebbe effettivamente fatto. Le linee che scorrono da una corsia ad un'altra ci permettono di capire come le classi effettivamente comunicano, e le linee all'interno della corsia stessa, come quella classe specifica farebbe il proprio lavoro.
Alla fine non era il Diagramma di attività più formale, ma in realtà era abbastanza buono da garantire che avremmo potuto cogliere il processo da una prospettiva più elevata. Questo ci ha permesso di comprendere meglio come il nostro sistema ha interagito e migliorarlo, riducendo in particolare la lunghezza della catena.
Dopo aver refactoring il codice e ripulito la struttura a catena, in realtà dovevamo gettare via il Diagramma, poiché era completamente diverso e il suo mantenimento avrebbe causato molto lavoro senza molti vantaggi. Preferiremmo crearne uno nuovo ogni volta che ne sentivamo il bisogno, usavamo i diagrammi come uno strumento di comunicazione piuttosto che come documentazione.
Indipendentemente dal fatto che il design originale a catena fosse adeguato sarebbe un'altra questione. Comunque, dopo questa esperienza, ritengo che gli Activity Diagram siano un buon punto di partenza se non si desidera avere una visione migliore del proprio sistema / codice per scopi di "pulizia". Il principale svantaggio è che è difficile avere una struttura del programma (gerarchie, relazioni, eccettera) del codice.