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.
Il chiarimento del GUFPI sull’interpretazione dei RET dà due criteri “oggettivi” per l’aggregazione dei RET a partire da un modello Entità-Relazioni:
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:
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”.
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
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.
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, … } )
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