Ha senso per le informazioni automatiche raccolte dal sistema legacy

2

Ho un sistema legacy di cui ho bisogno per pianificare una migrazione. È sviluppato principalmente in Ingres + 4GL (un vecchio sistema di form basato su Ingres).

Ho le seguenti informazioni:

  • Strutture dati (relazioni tra database e loro relazioni)
  • Tutti i programmi che accedono alla struttura dati Ingres sottostante

Ho codificato un parser per i programmi Ingres e 4GL usando ANTLR4 e utilizzando di ciò ho estratto anche le seguenti informazioni:

  • Quale programma accede alle strutture dati (tabelle)
  • Quale programma esegue quale stored procedure
  • Quale accesso memorizzato alla procedura con strutture dati (tabelle)
  • A quali tabelle si accede insieme (dagli stessi programmi)
  • Quali tabelle hanno l'accesso READ e / o WRITE da quali programmi

La mia domanda è:

Che cosa posso usare per rappresentare graficamente tutte queste relazioni? C'è un software / standard che può aiutarmi in questo?

Stavo pensando di eseguire un algoritmo di clustering sui dati raccolti per vedere se ci sono dei cluster che potrebbero essere migrati insieme?

    
posta Pablo Santa Cruz 27.11.2017 - 18:02
fonte

2 risposte

1

Cosa hai e cosa puoi fare

Un primo sguardo suggerisce che hai un grafico piacevole:

  • Programmi, stored procedure e strutture dati, sono tutti una sorta di nodi. I primi sono i nodi di elaborazione, i secondi sono nodi di archiviazione
  • Leggi e scrivi relazioni, sono i bordi diretti che mostrano il flusso di dati tra i nodi.

Con un grafico di questo tipo, puoi già:

  • analizzare i potenziali impatti di un cambiamento in un nodo, guardando a valle, semplicemente seguendo la direzione dei bordi.
  • analizza i requisiti di migrazione, andando verso il basso e verso monte (ignora la direzione del bordo).
  • calcola set di chiusura per identificare i "cluster" che dovrebbero essere migrati insieme.

Come rappresentare i tuoi dati?

Ci sono molti standard grafici che puoi usare. Tuttavia, in sostanza, quello che hai è un flusso di dati grafico, e il modo più semplice per immaginarlo, sarebbe mostrare un diagramma del flusso di dati (DFD). Due rappresentazioni popolari sono Yourdon e Demarco e Gane & Sarson: entrambi i DFD mostrano poca differenza e fondamentalmente hanno nodi del processore, note di archiviazione e bordi del flusso, esattamente quello che hai.

I diagrammi DFD sono un po 'obsoleti al giorno d'oggi. Questo perché rappresentano una visione procedurale del mondo, separando i dati passivi dai processi attivi. Questo è certamente il motivo per cui non esiste un vero equivalente in UML che sia basato sul paradigma orientato agli oggetti. Il diagramma di flusso delle informazioni UML è una buona approssimazione (anche se in realtà non ha negozi). Il diagramma di comunicazione UML è un'altra approssimazione, se si considerano i programmi e le singole tabelle come istanze di oggetto.

Addendum: anche il diagramma del componente UML (vedi la risposta di Doc Brown) è un'approssimazione valida, se si considerano i propri dati passivi come un componente attivo (dopotutto, il suo funzionamento è assicurato dal motore RDBMS). Tuttavia i connettori di interfaccia di cui avrai bisogno (almeno uno per una lettura e uno per una scrittura, se non vuoi perdere la direzione dei bordi), lo renderanno meno leggibile e più difficile da disegnare.

Cosa può mancare nel tuo set di strumenti?

Non conosco INGRES. Ma se si tratta di un RDBM con procedure memorizzate, viene posta la domanda se esiste un meccanismo di integrità referenziale (ad esempio procedure nascoste che potrebbero causare la cancellazione e le modifiche a cascata) o qualsiasi chiave esterna che potrebbe fornire una migliore comprensione di come le tabelle sono correlate tra loro. Questo potrebbe aiutarti ad analizzare ulteriormente la mesh prendendo in considerazione le dipendenze non ovvie.

    
risposta data 27.11.2017 - 19:44
fonte
1

Un diagramma dei componenti UML è probabilmente la soluzione migliore se stai cercando una sorta di notazione grafica standard per mostrare il le dipendenze tra componenti come programmi, stored procedure o tabelle. Gli accessi di lettura e scrittura possono essere espressi come sterotipi per le relazioni di dipendenza.

Se, tuttavia, questo rimane leggibile e comprensibile, dipende pesantemente dalla dimensione del sistema e dal numero di componenti coinvolti (ma probabilmente non è un errore della notazione UML, ma un problema con qualsiasi notazione grafica che sceglierai) .

    
risposta data 27.11.2017 - 18:25
fonte

Leggi altre domande sui tag