Il Manuale IFPUG 4.2: i criteri per l’individuazione degli ILF

Il Manuale IFPUG 4.2 contiene una sezione (Parte 2: Prassi di Conteggio) con una notevole mole di informazioni su come ricavare il modello Entità-Relazioni di un’applicazione esistente, e su come individuare e aggregare i RET corrispondenti alle entità del modello.

Sintetizziamo qui le attività della procedura di conteggio indicata dall’IFPUG per arrivare all’individuazione dei RET, e i criteri di aggregazione dei RET in ILF:

· costruire il modello Entità-Relazioni dell’applicazione, escludendo i cosiddetti “dati di decodifica” (tabelle “tecniche”, non significative per l’utente finale dell’applicazione);

· identificare e aggregare i File Logici (ILF/EIF):

. identificare i potenziali RET partendo dai processi elementari (EI, EO, EQ): in pratica, ogni archivio usato (letto o scritto) da un processo elementare è un potenziale RET;

. applicare ai potenziali RET i seguenti criteri di aggregazione/disaggregazione:

- individuare i RET corrispondenti a entità “deboli”, e aggregarli con i RET dell’entità da cui dipendono;

- individuare i RET corrispondenti a relazioni “molti a molti”; salvo rare eccezioni, le relazioni “molti a molti” saranno associate a ILF indipendenti da quelli delle entità collegate dall’associazione;

- individuare i RET corrispondenti a entità “attributive”, e aggregarli con i RET dell’entità da cui dipendono;

- individuare i RET corrispondenti a sottotipi di entità (gerarchie IsA), e aggregarli con i RET delle altre entità della gerarchia

Il processo precedente permette di aggregare tra loro alcuni dei RET dell’applicazione, mentre altri RET resteranno indipendenti. Ad ognuno dei sottoinsiemi di RET definiti dal processo dovrà corrispondere un ILF separato (o un EIF separato, nel caso che tutti i dati dell’insieme di RET siano read only).

 
La fase di individuazione dei potenziali RET dell’applicazione partendo dalle transazioni (EI, EQ, EO) dell’applicazione potrebbe presentare un certo margine di soggettività. Anche la fase successiva (definizione di un modello Entità-Relazioni associato ai potenziali RET) può presentare dei margini di soggettività. Ma è chiaro che, una volta definito completamente il modello Entità-Relazioni (chiavi delle entità, chiavi delle relazioni, ecc.), le operazioni successive (aggregazione dei RET per le entità deboli e le gerarchie IsA, ecc.) non presentano alcun margine di soggettività.

Riassumendo, la costruzione della parte dai del modello funzionale di un’applicazione, fatta secondo le indicazioni del CPM IFPUG 4.2, può essere suddivisa in due macrofasi:

• creazione di un modello Entità-Relazioni dell’applicazione completo delle chiavi delle entità e delle relazioni; questa attività presenta dei margini di soggettività;
• individuazione dei RET e degli ILF/EIF corrispondenti, secondo le regole IFPUG 4.2, al modello Entità-Relazioni; questa attività, basata sull’analisi delle chiavi del modello definite nella fase precedente, non dovrebbe presentare alcun margine di soggettività.

Le regole e gli esempi forniti dal CPM IFPUG 4.2 per l’individuazione dei RET e la loro aggregazione in ILF/EIF sembrano coprire tutte le casistiche previste in un modello E-R (entità deboli, gerarchie IsA, ecc.) senza lasciare alcun margine di interpretazione o ambiguità.