Le Linee Guida GUFPI 4.0: i criteri per l’individuazione degli ILF

Cercheremo ora di analizzare l’evoluzione dei criteri di individuazione degli ILF dalla versione 4.0 alla 4.2 del CPM IFPUG. Il CPM IFPUG 4.0 era un pò vago per quanto riguarda i criteri d’individuazione degli ILF, e dava spazio ad ampi margini d’interpretazione. Basandosi solo sui criteri indicati nei CPM 4.0, senza fa ricorso a “linee guida” esterne, era possibile classificare tutte, o quasi, le tabelle di un database relazionale come ILF indipendenti. In realtà, il CPM IFPUG 4.0 dava per scontato, senza però scriverlo esplicitamente, che la visione corretta per il modello dei dati dell’applicazione fosse basata sul modello Entità-Relazioni. Infatti, quasi tutti gli esempi di conteggio della versione 4.0 del manuale contengono i classici diagrammi “Entità-Relazioni”: nella versione 4.0 del manuale, per l’analisi dei dati si usava il modello Entità-Relazioni; ma in nessun punto del manuale questo modello veniva dichiarato esplicitamente come il “modello di riferimento”.


All’epoca del CPM IFPUG 4.0, un gran numero di conteggi in Function Points classificava tutte, o quasi, le tabelle di un modello relazionale come ILF diversi tra loro. Ognuno di questi ILF era composto da un solo RET: la tabella stessa. Ma esistevano anche conteggi “virtuosi”, basati sul modello Entità-Relazioni e non su quello relazionale, che tendevano a individuare pochi ILF, ognuno composto da un aggregato di diversi RET. In definitiva, nella versione 4.0 del CPM IFPUG esistevano delle ambiguità, per quanto riguarda le definizioni degli ILF, che lasciavano ampi margini all’interpretazione soggettiva.







In realtà, anche se le regole generali di individuazione degli ILF fornite dal CPM IFPUG 4.0 non erano molto precise, gli esempi di conteggio erano estremamente esplicativi. La figura precedente contiene un esempio di modello Entità-Relazioni preso dal CPM IFPUG 4.0. Guardando questo esempio, la “visione IFPUG 4.0” su entità, entità attributive e sottotipi di entità sembra molto chiara, e identica a quella attuale.

Dopo la diffusione del CPM IFPUG 4.0, diverse organizzazioni “nazionali”, tra cui il GUFPI (Gruppo Utenti Function Point Italia) si preoccuparono di studiare e pubblicare delle “linee guida” per l’interpretazione del manuale. Le “Linee Guida 4.0” del GUFPI, ancora disponibili sul web, contengono oltre un centinaio di precisazioni e chiarimenti sull’interpretazione di diversi aspetti del Manuale IFPUG 4.0. I criteri per l’individuazione degli ILF sono ancora oggi particolarmente sintetici ed efficaci. In realtà le versioni successive del Manuale IFPUG, la 4.1.1 e la 4.2, hanno incorporato e reso più precisi questi criteri, ma non li hanno modificati.

Alcuni criteri d’individuazione degli ILF pubblicati dal GUFPI per il CPM IFPUG 4.0 sono i seguenti.

83	Gruppo di dati: file logico o RET?
	Codice: LFS.I.199901 Impatto: Importante
Questione:	Quali criteri si possono utilizzare per stabilire se un raggruppamento logico di dati è un file logico a sé stante oppure un RET di un altro file logico più esteso?
Risposta:	Sia i file logici che i RET sono gruppi logici di dati. Più precisamente, il RET è definito come sottogruppo logico dei dati di un file logico. Nel CPM 4.0 non sono, però, chiariti i criteri da utilizzare per decidere se un gruppo logico è autonomo o è subordinato ad un altro file logico, e quindi rappresenta un RET di quest’ultimo. È però chiaro, ricordando la significatività per l’utente, che è necessario fare riferimento alla semantica del contesto in cui si opera più che ai rapporti di tipo strutturale tra i dati. Se per una certa applicazione un gruppo di dati è attributivo di una entità forte del contesto applicativo, in quanto meglio specifica e caratterizza tale entità, questo gruppo di dati è fortemente candidato ad essere un RET dell’entità altrimenti è candidato ad essere un file logico autonomo. Per questo motivo una gerarchia ISA può generare potenziali RET, ma non potenziali ILF, come nell’esempio sottostante. Nel caso delle entità FORNITORE e ARTICOLO, queste sono candidati file logici distinti in quanto descrivono elementi della realtà fortemente distinti tra loro. Un ultimo esempio dovrebbe chiarire ulteriormente il punto di vista da adottare. Supponiamo che una ditta abbia rapporti con rappresentati commerciali che non sono dipendenti diretti della società. Ogni venditore potrà usare una automobile per gli spostamenti legati al lavoro svolto. L’azienda vuole mantenere sia le informazioni relative ai venditori (anagrafica, accordi commerciali, fatturato etc.) che quelle relative alle automobili (marca, tipo, rimborso chilometrico etc.). La domanda è: i dati delle automobili sono RET dell’ILF Venditori o sono un ILF a sé stante? La risposta è che gli stessi dati possono essere ora l’uno ora l’altro a seconda dello specifico contesto applicativo. In particolare saranno RET dell’ILF Venditore qualora le automobili siano di proprietà dei venditori ed i loro dati servano solo per meglio specificare i rapporti economici intercorrenti tra azienda e venditori stessi. Gli stessi dati potranno costituire un ILF autonomo se le automobili sono invece di proprietà dell’azienda e questa ne vuole fare una gestione autonoma di patrimonio mobiliare in termini di manutenzione, ammortamenti, etc. Come si vede da questo esempio, i dati sono fondamentalmente gli stessi, ma cambia il punto di vista applicativo su di essi. Appare allora consistente con l’impostazione della Function Point Analysis che la seconda situazione corrisponda ad un maggior valore numerico in Function Point.

Il chiarimento del GUFPI sull’interpretazione dei RET dà due criteri “oggettivi” per l’aggregazione dei RET a partire da un modello Entità-Relazioni:

• tutte le entità in una stessa gerarchia IsA (Impiegato IsA Dipendente, Dirigente IsA Dipendente) devono corrispondere a RET di uno stesso ILF;
• le entità “deboli”, cioè le entità che, nel modello E-R, dipendono da un’altra entità (Automobile, dipendente da Venditore) devono essere associate a RET dell’entità da cui dipendono.

Il secondo esempio, quello relativo alle due possibili classificazioni delle entità Automobile e Venditore, spiega come una stessa entità (Automobili) possa essere rappresentata, nei modelli E‑R, in modi diversi.
Se le auto devono essere, nella visione dell’utente, legate al venditore, allora nel modello E-R l’entità Automobile sarà rappresentata come entità “debole”. Ogni auto sarà collegata da una relazione “1 a 1” a un venditore, e sarà identificabile, nel modello E‑R, solo partendo dall’entità Venditore. Ad esempio, usando la notazione ERFN, avremo:

• Entity: Venditore { Matricola, Nome, Cognome, … }
• Entity: Automobile { Venditore.Matricola, Targa, Modello, Colore, …}
• Relationship Usa( E(Venditore), E(Automobile), { Targa, DataAssegnazione, … } )

Nell’esempio precedente, per identificare un’auto sarà necessario far riferimento alla matricola del venditore. Si noti che la targa, che da sola basterebbe a identificare l’auto, viene indicata come attributo non chiave. La relazione tra Venditore e Auto sarà “1 a 1”, se c’è un auto per ogni venditore, o anche “1 a molti”, se un venditore può disporre di più auto.

Se invece le auto non devono essere, nella visione dell’utente, legate al venditore, allora nel modello E-R l’entità Auto non ci sarà nessun legame tra le chiavi delle due entità, e il legame tra auto e venditore dovrà essere espresso da una relazione “molti a molti”.

• Entity: Venditore { Matricola, Nome, Cognome, … }
• Entity: Automobile { Targa, Modello, Colore, …}
• Relationship Usa( E(Venditore), E(Automobile), { DataAssegnazione, … } )

Le Linee Guida GUFPI 4.0 per l’individuazione dei RET non parlano delle chiavi delle entità da analizzare; ma i concetti espressi possono essere facilmente riformulati in termini di analisi delle chiavi delle entità coinvolte.

I due concetti di base per l’aggregazione dei RET (classificazione di relazioni IsA e di entità “deboli”) sono stati approfonditi e sviluppati in un documento integrativo al Manuale CPM 4.1.1, pubblicato dall’IFPUG nel 2001. Gli stessi concetti sono stati poi integrati nella versione 4.2 del Manuale.

© Copyright by Nicola La Monaca, 2010

All rights reserved