Le sigle “ILF (Internal Logical File)” ed “EIF (External Interface File)” sono sempre state un po’ misteriose per i non “addetti ai lavori”. Queste sigle, “inventate” da Albrecht, lo “scopritore” dei Function Points, indicano praticamente la stessa cosa: un archivio utilizzato dall’applicazione che si sta “misurando”.
L’ILF è un archivio che l’applicazione può sia leggere sia aggiornare. L’EIF, invece, è un archivio “read only”: l’applicazione che stiamo "misurando" può leggerlo, ma non aggiornarlo. Per il resto, non ci sono differenze tra le due sigle.
Gli ILF (e gli EIF) non corrispondono esattamente agli archivi fisici dell'applicazione: essi corrispondono, invece, alla visione degli archivi dell’applicazione che ha l’"utente finale". Ad esempio, gli ILF di un’applicazione bancaria che gestisce i titoli potrebbero chiamarsi “Anagrafica Titoli” (l’insieme di tutti gli archivi dell’applicazione che servono a gestire i titoli), oppure “Anagrafica Conti Titoli” (l’insieme di tutti gli archivi per la gestione anagrafica dei conti in titoli), e cosi’ via.
Nei manuali IFPUG c’è una forte attenzione a rendere il concetto di ILF (e di EIF) indipendente dalla tecnologia. Per fare un esempio, il fatto che un'applicazione usi, per le sue "anagrafiche", archivi DB2, o Microsoft SQL, o semplici “file piatti”, non ha importanza: gli ILF che rappresentano le “anagrafiche” devono essere esattamente gli stessi.
In passato (almeno prima del 2001) c’era una forte tendenza ad associare ogni tabella fisica dell’applicazione che si stava misurando ad un diverso ILF (o EIF). Ma di solito non è cosi’. Infatti, gli ILF (e gli EIF) sono aggregati di RET (Record Element Types). Un RET è un gruppo di dati significativo per l’utente finale dell’applicazione. Di solito i RET corrispondono, in un database relazionale normalizzato, alle singole tabelle fisiche. Ma spesso, in un database relazionale normalizzato, a diverse tabelle fisiche può corrispondere un solo ILF.
Ad esempio, l’ILF “Titolo” può essere composto da due RET: “Dati Titolo” (codice, anno di emissione, emittente, ecc.) e “Cedola” (numero cedola, importo, data di pagamento, ecc.).
A loro volta, i RET sono composti da DET (Data Element Types). Si tratta di tipi di dati semplici (ad esempio, CodiceTitolo, DescrizioneTitolo, DataEmissione, ecc.).
Gli “aggregati ultimi”, le “particelle elementari” degli ILF sono quindi i DET.
E’ possibile rappresentare la gerarchia tra ILF, RET e DET usando la classica notazione insiemistica.
Un ILF è un insieme di RET:
Un RET è un insieme di DET:
Al momento, la ricerca functionpointologica non è riuscita a scomporre ulteriormente gli ILF in “particelle” più piccole dei DET.
Uno stesso archivio non può essere sia un EIF sia un ILF. In alcuni casi, uno stesso archivio può contenere due diversi RET, uno dei quali è aggiornato dall’applicazione che stiamo misurando, mentre l’altro è “read only”. In questo caso, l’intero archivio va contato come un solo ILF con due RET.
L’ILF è un archivio che l’applicazione può sia leggere sia aggiornare. L’EIF, invece, è un archivio “read only”: l’applicazione che stiamo "misurando" può leggerlo, ma non aggiornarlo. Per il resto, non ci sono differenze tra le due sigle.
Gli ILF (e gli EIF) non corrispondono esattamente agli archivi fisici dell'applicazione: essi corrispondono, invece, alla visione degli archivi dell’applicazione che ha l’"utente finale". Ad esempio, gli ILF di un’applicazione bancaria che gestisce i titoli potrebbero chiamarsi “Anagrafica Titoli” (l’insieme di tutti gli archivi dell’applicazione che servono a gestire i titoli), oppure “Anagrafica Conti Titoli” (l’insieme di tutti gli archivi per la gestione anagrafica dei conti in titoli), e cosi’ via.
Nei manuali IFPUG c’è una forte attenzione a rendere il concetto di ILF (e di EIF) indipendente dalla tecnologia. Per fare un esempio, il fatto che un'applicazione usi, per le sue "anagrafiche", archivi DB2, o Microsoft SQL, o semplici “file piatti”, non ha importanza: gli ILF che rappresentano le “anagrafiche” devono essere esattamente gli stessi.
In passato (almeno prima del 2001) c’era una forte tendenza ad associare ogni tabella fisica dell’applicazione che si stava misurando ad un diverso ILF (o EIF). Ma di solito non è cosi’. Infatti, gli ILF (e gli EIF) sono aggregati di RET (Record Element Types). Un RET è un gruppo di dati significativo per l’utente finale dell’applicazione. Di solito i RET corrispondono, in un database relazionale normalizzato, alle singole tabelle fisiche. Ma spesso, in un database relazionale normalizzato, a diverse tabelle fisiche può corrispondere un solo ILF.
Ad esempio, l’ILF “Titolo” può essere composto da due RET: “Dati Titolo” (codice, anno di emissione, emittente, ecc.) e “Cedola” (numero cedola, importo, data di pagamento, ecc.).
A loro volta, i RET sono composti da DET (Data Element Types). Si tratta di tipi di dati semplici (ad esempio, CodiceTitolo, DescrizioneTitolo, DataEmissione, ecc.).
Gli “aggregati ultimi”, le “particelle elementari” degli ILF sono quindi i DET.
E’ possibile rappresentare la gerarchia tra ILF, RET e DET usando la classica notazione insiemistica.
Un ILF è un insieme di RET:
ILF = { RET1, RET2, … RETn }
Un RET è un insieme di DET:
RET = { DET1, DET2, … DETm }
Al momento, la ricerca functionpointologica non è riuscita a scomporre ulteriormente gli ILF in “particelle” più piccole dei DET.
Uno stesso archivio non può essere sia un EIF sia un ILF. In alcuni casi, uno stesso archivio può contenere due diversi RET, uno dei quali è aggiornato dall’applicazione che stiamo misurando, mentre l’altro è “read only”. In questo caso, l’intero archivio va contato come un solo ILF con due RET.
Riferimenti
§ IFPUG CPM 4.2, Parte 2 – Prassi di Conteggio, Cap. 3 – Dati Condivisi, Scenario 7: Aggiornamento dello stesso archivio.
Nessun commento:
Posta un commento