Entità intrinsecamente deboli

In molti casi una stessa entità può essere “forte” in un certo modello Entità-Relazioni, “debole” in un altro. Queste differenze rispecchiano sia i differenti modelli di business dai quali i modelli E-R sono stati derivati, sia un certo margine di soggettività da parte di chi definisce il modello E-R.

Sui modelli E-R ci sono inevitabili margini di soggettività, dovuti al fatto che sia l’utente che definisce la sua visione del business, sia l’analista che definisce il modello E-R, sono “umani”, quindi possono avere visioni differenti, soggettive, di una stessa realtà.

Esistono però diversi esempi di entità “intrinsecamente deboli”, cioè entità che sono

“predestinate” ad essere “deboli” in qualunque modello E-R. Si tratta delle entità che già nel mondo reale devono necessariamente essere identificate per mezzo di altre entità.

Ecco alcuni esempi.

CAP, Via e NumeroCivico. Tutti sappiamo, quando ad esempio scriviamo una cartolina, che il solo numero civico del destinatario non basta, da solo, a individuarlo: sono necessari anche il Codice di Avviamento Postale (CAP) e la via. A sua volta, anche la via non può essere individuata, in modo univoco, senza il CAP.
In qualunque modello E-R che contenga degli indirizzi, Numero Civico sarà un’entità “debole”, dipendente dalle entità CAP e Via. Anche l’entità Via sarà un’entità “debole”, dipendente da CAP.

Specie e Genere. Nella “classificazione binomiale” delle specie viventi, introdotta da Linneo, le varie specie sono identificate da un genere (ad esempio, Homo) e dal nome della specie stessa (ad esempio, Sapiens). Il nome di una specie (ad esempio, Homo Sapiens) non basta, da solo, a identificare una specie: infatti esistono (rari) casi di specie con lo stesso nome appartenenti a generi diversi.
In qualunque modello E-R, l’entità Specie sarà, inevitabilmente, un’entità debole: per essere identificata, avrà bisogno della chiave dell’entità sovrastante, il Genere.

Titolo e Cedola. Nel mondo della finanza, le obbligazioni (bonds) sono individuate da un codice univoco (codice ISIN). Le cedole (coupons) sono individuate dal codice dell’obbligazione e da un progressivo. Le cedole sono un’entità intrinsecamente debole: non hanno, nel mondo reale, una chiave che le identifichi in maniera univoca indipendentemente dal codice dell’obbligazione a cui appartengono. Questa situazione sarà inevitabilmente rispecchiata da qualunque modello E-R che rappresenti le entità Obbligazione e Cedola.

Riassumendo: alcuni concetti del mondo reale possono essere associati, in un modello E-R, a entità “deboli” o “forti”, a seconda della visione di chi definisce il modello. Ad esempio, abbiamo visto in un esempio precedente, che le entità Impiegato e Figlio possono essere rappresentate, in un modello E-R, in modo diverso. Altre entità (ad esempio, il numero civico di un indirizzo postale sono “intrinsecamente deboli”: in qualunque modello E-R, l’entità Numero Civico sarà sempre dipendente dall’entità Via e dall’entità CAP.

Il significato delle chiavi in un modello E-R

Il modello concettuale dei dati (modello E-R) deve rispecchiare, per definizione, la visione dei dati che ha l’utente finale dell’applicazione, senza alcun vincolo di tipo “tecnico”. In quest’ottica, le chiavi delle entità del modello hanno un ruolo fondamentale. Il fatto che un analista definisca due entità del modello E-R con la stessa chiave non può essere una scelta casuale, perché deve rispecchiare il significato, il valore semantico, che le entità hanno per l’utente finale.

Dire che due entità sono in gerarchia IsA implica che, nel modello, le due entità debbano avere la stessa chiave. Viceversa, il fatto che, in un modello E-R-, due entità del modello abbiano la stessa chiave, non può essere casuale: deve rispecchiare il fatto che, nella visione dell’utente, le due entità partecipano alla stessa gerarchia IsA, oppure una è attributiva dell’altra.

Se, come nella figura precedente, l’analista decide che due entità partecipano ma una gerarchia IsA (Impiegato IsA Dipendente, Dirigente IsA Dipendente) allora le due entità dovranno avere, nel modello E-R, la stessa chiave. In questo esempio, il nome della chiave comune alle due entità Impiegato e Dirigente potrebbe essere, ad esempio, (CodiceDipendente).

Si noti che, nella fase di realizzazione di un modello E-R ci sono notevoli margini di soggettività. Partendo dagli stessi business requirements, analisti diversi potrebbero creare modelli E-R diversi che li rappresentino. Ad esempio, si può immaginare un modello E-R dove Impiegato e Dirigente non partecipino nella stessa gerarchia IsA. Ma, in questo caso, l’analista dovrà scegliere, per le due entità, due chiavi differenti: ad esempio, (CodiceImpiegato) e (Codice Dirigente).

Ricapitolando: se l’analista del modello E-R decide che due entità (Impiegato e Dirigente) devono far parte di una stessa gerarchia IsA, nel modello E-R dovrà necessariamente dare alle due entità la stessa chiave.

Passiamo ora a un altro concetto: il significato delle chiavi nella rappresentazione della dipendenza tra due entità del modello. Le entità di un modello E-R che dipendono da altre entità si dicono “entità deboli”. In molti casi, il concetto di dipendenza, o “debolezza”, è relativo: una stessa entità può essere indipendente da altre entità (ovvero, “forte”) in un certo modello E-R, e invece essere dipendente da altre entità (ovvero, “debole”) in un altro modello E-R.

Vediamo un esempio: le entità Impiegato e Figlio (dell’impiegato) memorizzate in un modello E-R per un’applicazione aziendale. L’analista dell’applicazione ha diverse scelte per individuare le chiavi primarie delle due entità. Ad esempio, l’entità Impiegato potrebbe avere la chiave primaria (CodiceImpiegato), e l’entità Figlio potrebbe avere la chiave primaria (CodiceFiscale). In questo caso, le due entità sarebbero indipendenti tra loro, e la rappresentazione del legame tra un impiegato ed i suoi figli richiederebbe un relazione “molti a molti” con chiave (CodiceImpiegato, CodiceFiscaleFiglio).

Una seconda possibilità è quella di dare alle due entità Impiegato e Figlio la stessa chiave primaria, ad esempio (CodiceFiscale). Anche in questo caso, le due entità sarebbero indipendenti, ma farebbero parte di una stessa gerarchia IsA, che possiamo, ad esempio, chiamare Persona. In questo caso, la rappresentazione del legame tra impiegato e figlio richiederebbe una relazione “molti a molti”

riflessiva tra Persona e Persona, la cui chiave si potrebbe chiamare (CodiceFiscalePadre, CodiceFiscaleFiglio).

Una terza possibilità è quella di individuare l’impiegato con la chiave (CodiceImpiegato), ed i figli con una chiave dipendente da quella di Impiegato: ad esempio, (CodiceImpiegato, ProgressivoFiglio). In questo caso, basandosi sulla relazione di inclusione tra le chiavi delle due entità Impiegato e Figlio,

Figlio sarebbe, per definizione, un’entità debole.

Riassumendo, in molti casi è possibile disegnare modelli E-R che rappresentano le stesse entità (ad esempio, Impiegato e Figlio) in modi differenti. E un’entità (in questo caso, Figlio) può essere “debole” o “forte”, secondo le scelte fatte da chi definisce il modello E-R.

Documento "Pensare in Function Points - Le funzioni di tipo dati" (bozza del 17.12.2009)

Il documento contiene indicazioni, suggerimenti e spunti di discussione sul conteggio delle "funzioni di tipo dati" secondo la versione 4.2 del Manuale di Conteggio IFPUG.

L'ultima bozza del documento può essere scaricata da uno dei seguenti links:

Pensare in Function Points: le “funzioni di tipo dati” - bozza del 17.12.2009

Pensare in Function Points: le “funzioni di tipo dati” - bozza del 17.12.2009

Ancora su entità "forti" ed entità "deboli"

Parliamo ancora di "entità forti" ed "entità deboli". Pensiamo al modello E-R associato ad una ”Anagrafica Titoli”. Due entità del modello saranno sicuramente “Titolo” e “Cedola”.



Per rappresentare questi oggetti “materiali” su un sistema informatico, dobbiamo introdurre delle chiavi. Ad esempio, le chiavi potrebbero essere:


K ( Titolo ) = ( NomeEmittente, DataEmissione )
K ( Cedola ) = ( NomeEmittente, DataEmissione, NumeroCedola )

Passiamo ora agli insiemi degli attributi chiave.


KS ( Titolo ) = { NomeEmittente, DataEmissione }
KS ( Cedola ) = { NomeEmittente, DataEmissione, NumeroCedola }

Possiamo osservare che


{ NomeEmittente, DataEmissione } ⊆ { NomeEmittente, DataEmissione, NumeroCedola }

cioè


KS ( Titolo ) ⊆ KS ( Cedola )

In base alle definizioni precedenti, “Cedola” è un’entità debole, e dipende da “Titolo”.
La figura precedente rappresenta un’obbligazione, con le relative cedole, emessa nel 1863, durante la Guerra Civile, dagli Stati Confederati d’America. Questa figura permette di fornire un chiarimento su una “definizione informale”, un po’ troppo generica, che a volte si sente dare per le “entità deboli per esistenza”. Secondo questa definizione, un’entità “debole per esistenza”, dipendente da un’altra entità “forte”, “perde di significato” se l’entità “forte” scompare dal modello E-R.
E’ chiaro che la definizione di “entità debole per esistenza” va applicata alle chiavi di un modello E-R, non alla realtà. Se prendiamo l’obbligazione della figura precedente, emessa dagli Stati Confederati nel 1863, poi con un paio di forbici ritagliamo il foglio dell’obbligazione e lo distruggiamo, lasciando solo le cedole, queste ultime non “perdono di significato”. Se l’obbligazione non fosse scaduta, forse potremmo anche andare in banca per riscuoterle.
Allo stesso modo, se nel nostro modello E-R ”Anagrafica Titoli” cancelliamo l’entità Titolo, l’entità Cedola non “perde di significato”. Per applicare in maniera corretta la definizione di “entità debole per esistenza”, bisogna quindi seguire solo fino ad un certo punto i concetti “divulgativi”, ed è meglio affidarsi alle definizioni “formali”. Nel caso del modello E-R ”Anagrafica Titoli” del nostro esempio, l’entità Cedola è “debole per esistenza” per definizione, perché vale la relazione:

{ NomeEmittente, DataEmissione } ⊆ { NomeEmittente, DataEmissione, NumeroCedola }
cioè

KS (Titolo ) ⊆ KS ( Cedola )
Cercare di spiegare il concetto di “dipendenza per esistenza” tra le entità a parole, senza usare una notazione formale, è un po’ come cercare di spiegare la meccanica quantistica nei programmi TV divulgativi, come fa a volte il fisico Antonino Zichichi. E’ divertente, interessante, ma credo che ognuno di quelli che lo ascoltano (a parte i fisici) si sia fatto una sua, personale, visione della meccanica quantistica (io comunque ancora non l’ho capita). Ed è probabile che queste visioni personali siano in contrasto tra loro.
Il linguaggio formale dell’insiemistica, invece, è universale, e non dà luogo ad incomprensioni. Nel caso delle “entità deboli per esistenza”, poi, per usarlo basta davvero poco: i concetti di base dell’insiemistica, insegnati da decine d’anni anche nelle scuole elementari.

Riferimenti esterni
§ http://en.wikipedia.org/wiki/Relational_model

Entità "forti" ed entità "deboli"

Una volta costruito il modello E-R di un’applicazione, si può passare ad analizzarlo. Uno dei tanti concetti usati nell’analisi dei modelli E-R è in concetto di “entità debole” (o “entità debole per esistenza”), contrapposto al concetto di “entità forte” (“entità forte per esistenza”).
Prima del 2001, il concetto di “entità debole per esistenza” non appariva nei manuali IFPUG per il conteggio dei Function Points. Nel 2001, con la pubblicazione dell’”Addendum” al Manuale di Conteggio IFPUG 4.1.1, si è scoperto che classificare le entità del modello concettuale di un’applicazione come “deboli”, piuttosto che come “forti”, aveva significative ripercussioni sul conteggio degli ILF associati dell’applicazione. Da allora, i dibattiti sul concetto di “entità debole” si sono ampliati a tutta la vasta e variegata comunità degli informatici che hanno a che fare con i Function Points.
Ma cosa sono le “entità deboli”? Si tratta di entità di un modello E-R la cui chiave dipende dalla chiave di un’altra entità del modello. Ad esempio, se in modello E-R ci sono le entità Fattura {NumeroFattura} e RigaFattura {NumeroFattura, Numero Riga}, l’entità RigaFattura si dice “debole”, perché la sua chiave dipende da quella di Fattura.

Ecco una definizione formale.

In un modello E-R, si dice “entità debole per esistenza” un’entità la cui la cui chiave dipende da quella di un’altra entità del modello.Le entità la cui chiave non dipende da quella di nessun’altra entità del modello si dicono, invece, “entità forti”.
Ecco un esempio preso dal web.



In questo sottoinsieme di modello E-R abbiamo due entità: Movie e MovieCopy. Forse il modello E-R proviene da una delle prime fasi dell’analisi del sistema informatico di un negozio BlockBuster. Ora rappresentiamo le due entità con la notazione "formale" introdotta in precedenza.


Entity: Movie { MovieNumber, Title }
Entity: Movie { MovieNumber, CopyNumber, ShelfLocation }

L'insieme degli attributi chiave dell'entità Movie è, ovviamente, {MovieNumber}; l'insieme degli attributi chiave dell'entità MovieCopy è, invece, {MovieNumber, CopyNumber}.
La chiave dell'entità MovieCopy dipende da quella dell'entità Movie; MovieCopy è, per definizione, un’entità “debole per esistenza”. La chiave di Movie, invece, non dipende da nessuna altra chiave all’interno del modello. Movie è quindi, per definizione, un’entità “forte per esistenza”.
Il concetto di dipendenza tra chiavi può essere espresso in modo molto sintetico usando la notazione "insiemistica" introdotta in precedenza: l'insieme degli attributi chiave di un’entità "debole" deve comprendere l'insieme degli attributi di un’altra entità del modello. Usando la notazione "insiemistica", gli insiemi degli attributi chiave delle due entità Movie e MovieCopy sono:


KS ( Movie ) = { K ( Movie ) } = { MovieNumber }
KS ( MovieCopy ) = { K ( MovieCopy )} = { MovieNumber, CopyNumber }

E’ facile osservare che l'insieme degli attributi chiave di Movie, { K ( Movie ) }, è un sottoinsieme degli attributi chiave di MovieCopy, { K ( MovieCopy ) }:


{ MovieNumber } ⊆ { MovieNumber, CopyNumber }

cioè


{ K ( Movie ) } ⊆ { K ( MovieCopy ) }

oppure (le due notazioni sono equivalenti):


KS ( Movie ) ⊆ KS ( MovieCopy )

L’insieme degli attributi chiave di MovieCopy è un superinsieme proprio dell’insieme degli attributi chiave di Movie. E’ possibile generalizzare questo esempio, e dare una definizione "insiemistica" per le chiavi delle entità "deboli per esistenza".


Def. Dato un modello E-R con due entità A e B, ed i rispettivi insiemi degli attributi chiave KS(A) e KS(B), si dice che B è un’entità “debole per esistenza” rispetto ad A se

KS(B) ⊆ KS(A)

Cioè se l’insieme degli attributi chiave di B è un superinsieme proprio dell’insieme degli attributi chiave di B.


Riferimenti esterni
http://en.wikipedia.org/wiki/Relational_model

Un esempo di notazione "formale" per i modelli E-R

Basta fare un “giro” sul web per vedere che ci sono letteralmente centinaia di diverse notazioni formali per i diagrammi E-R ed i diagrammi relazionali.

Per i modelli relazionali c’è addirittura un vero e proprio linguaggio standard: lo SQL ANSI Standard. Lo SQL standard è sicuramente completo, ma un po’ troppo verboso. La notazione qui sotto, presa dal web, si fa invece apprezzare per la sua sinteticità.

Customer(Customer ID, Tax ID, Name, Address, City, State, Zip, Phone)

Order (Order No, Customer ID, Invoice No, Date Placed, Date Promised, Terms, Status)

Order Line(Order No, Order Line No, Product Code, Qty)

Invoice (Invoice No, Customer ID, Order No, Date, Status)

Invoice Line(Invoice No, Invoice Line No, Product Code, Qty Shipped)

Product(Product Code, Product Description)

Nell’esempio precedente, il nome di ogni tabella del modello relazionale è seguito dall’elenco delle sue colonne. Le colonne chiave sono in neretto. E’ facile verificare che questa notazione “funziona” anche per rappresentare le entità e le relazioni di un modello E-R.

Il diagramma E-R qui sotto è interessante perché “suggerisce” una notazione simbolica molto simile a quella precedente.

Partiamo da questo esempio per introdurre un esempio di notazione "formale" per un modello E-R.

Entity: Titolo( CodiceISIN, DescrizioneTitolo, CodiceEmittente, AnnoEmissione, Scadenza, Importo )

In questo esempio, l’entità Titolo è seguita dall’elenco degli attributi. Gli attributi chiave sono in grassetto. Di solito, l’elenco degli attributi racchiuso tra parentesi sta ad indicare una notazione posizionale, o "vettoriale". In questo tipo di notazione si ha:

(a, b) ≠ (b, a)

Introduciamo ora una notazione differente, insiemistica, nella quale gli oggetti di un elenco non hanno un ordine predefinito. Cioè:

{ a, b } = { b, a }

Applichiamo ora la notazione “insiemistica” per rappresentare l’insieme degli attributi di un’entità o una relazione. Ecco un esempio.

Entity: Titolo { CodiceISIN, DescrizioneTitolo, CodiceEmittente, AnnoEmissione, Scadenza, Importo }

In questa seconda rappresentazione dell’entità Titolo, gli attributi sono racchiusi tra parentesi graffe, come si usa per gli insiemi, in modo da sottolineare che il loro ordine non è importante. Gli attributi chiave (in questo caso, CodiceISIN) sono sottolineati. Ecco un altro esempio delle due notazioni (posizionale ed insiemistica).

Entity: Cedola( CodiceISIN, ProgressivoCedola, Scadenza, Importo )

Entity: Cedola{ CodiceISIN, ProgressivoCedola, Scadenza, Importo }

I due attributi chiave della cedola (CodiceISIN, ProgressivoCedola) sono sottolineati.

Nel seguito useremo tutte e due queste notazioni: quella con le parentesi "tonde" ("posizionale") e quella con le parentesi "graffe" ("insiemistica"). In questo modo sarà facile chiarire, nelle varie situazioni, se l’ordine degli attributi di una entità o relazione è importante o meno.

Osserviamo che, cambiando l’ordine degli attributi, con le due notazioni si hanno risultati differenti:

Cedola( CodiceISIN, ProgressivoCedola, Scadenza, Importo ) ≠ Cedola(ProgressivoCedola, CodiceISIN, Scadenza, Importo )

Mentre gli insiemi degli attributi, anche cambiano il loro ordine, sono coincidenti. Cioè

Cedola{ CodiceISIN, ProgressivoCedola, Scadenza, Importo} = Cedola{ ProgressivoCedola, CodiceISIN, Scadenza, Importo}

Introduciamo ora altre due notazioni per indicare identificare i soli attributi chiave di un’entità. Data un’entità E con attributi chiave K1, K2, … Kn ed attributi non chiave A1, A2 … Am:

E ( K₁, K₂, … K_n; A₁, A₂, … A_m )

indichiamo con K(E) la n-upla ordinata con i soli attributi chiave di E:

K(E) = ( K₁, K₂, … K_n )

ed indichiamo con { K(E) }, o con KS(E), l’insieme dei soli attributi chiave di E:

{ K(E) } = KS(E) = { K₁, K₂, … K_n }

Ecco alcuni esempi.

Entity: Titolo ( CodiceISIN, Scadenza, Importo )

K(Titolo) = ( CodiceISIN )

{ K(Titolo) } = KS(Titolo) = { CodiceISIN }


Entity: Cedola ( CodiceISIN, ProgressivoCedola,Scadenza, Importo )

{ K(Cedola) } = KS(Cedola) = { CodiceISIN, ProgressivoCedola } = { ProgressivoCedola, CodiceISIN }

Ovviamente, detta E un’entità, vale sempre la relazione:

{ K(E) } ⊆ { E }

cioè l'insieme degli attributi chiave dell'entità è un sottoinsieme dei suoi attributi. Ad esempio:

{ K(Titolo) } ⊆ { Titolo }

Riferimenti esterni

§ http://en.wikipedia.org/wiki/Relational_model

Notazioni grafiche e "formali" per i modelli E-R

Il “Modello Entità-Relazioni (E-R)” per la rappresentazione e l’analisi dei dati è ancora un “modello di riferimento” per l’analisi dei dati. I cosiddetti “Class Diagram”, usati nel linguaggio UML (Uniform Modeling Language), sono un’evoluzione dei diagrammi E-R: ma i concetti fondamentali restano gli stessi.
Ci sono diverse “notazioni grafiche”, o “dialetti”, per rappresentare graficamente i diagrammi E-R.
Ecco qui sotto un esempio di diagramma E-R preso dal web.




Praticamente in tutte le “notazioni” per i diagrammi E-R, le entità sono rappresentate con dei rettangoli, le relazioni con dei rombi. Sulle linee che connettono le entità e le relazioni ci sono le “cardinalità” delle relazioni. Le cardinalità più comuni sono "0..1" (opzionale), "1" (obbligatoria), "1.. n" (uno a molti obbligatoria), "0.. n" (uno a molti opzionale).
I diagrammi E-R, così come quelli relazionali, possono essere rappresentati usando una notazione matematica, formale, basata su semplici concetti di teoria degli insiemi. Nella figura qui sotto c’è qualche esempio di definizioni fornite da Chen in un suo articolo sul modello E-R.



La possibilità di rappresentare le entità e le relazioni usando un linguaggio matematico, formale, permette ai “CASE tools” usati per l’analisi ed il disegno dei dati di rappresentare i diagrammi E-R all’interno dei computers. Forse qualche manager potrebbe restare sorpreso scoprendo che i coloratissimi diagrammi E-R creati dal “CASE tool” che ha appena acquistato per la sua azienda non sono in formato JPEG nativo, e per modificarli non è necessario un software di "fotoritocco".

Riferimenti esterni
§ Peter P. Chen , Entity-Relationship Modeling: Historical Events, Future Trends, and Lessons Learned.
§ All for One, One for All, by C. J. Date, May 31st, 2006

I modelli dei dati all’epoca dell’”invenzione” dei Function Points.

Per capire come sono nati gli ILF, è necessario tornare ai tempi pionieristici della nascita dei Function Points: alla fine degli anni ‘70, ai tempi dei computer mainframe e delle schede perforate.
A quell’epoca, quasi tutte le applicazioni si basavano, per i loro dati, su “files piatti”. I databases DL/1, che da qualche anno l’IBM ha abbandonato, negli anni ’70 erano strumenti d’avanguardia. Il modello relazionale dei dati, che oggi domina incontrastato nel mondo del software, era stato studiato e proposto da Edgar F. Codd, nel 1969. Ma i databases relazionali erano al massimo un oggetto di studio accademico.
Un tema molto interessante per gli studiosi d’informatica era quello di scegliere il “modello dei dati” più adatto per rappresentare i dati del mondo reale all’interno delle applicazioni software.



Il “modello relazionale” era estremamente “potente” e basato su solidi concetti matematici, ma un po’ astratto.



Nel 1975 Peter Chen, uno studioso americano, propose il “Modello Entità-Relazioni (E-R)” per la rappresentazione e l’analisi dei dati. Il modello E-R, come anche il modello relazionale, sono modelli astratti, indipendenti dalla tecnologia, un pò come la “macchina di Turing”. Per questo, mentre i computers del 1975 sono oggetti da museo, il modello E-R ed il modello relazionale sono ancora modelli di riferimento per l’analisi dei dati.
Il modello E-R è, da un punto di vista logico, ancora più astratto del modello relazionale. Ma i diagrammi E-R sono, di solito, molto più comprensibili agli “umani” rispetto ai diagrammi relazionali. In altre parole, anche se i due modelli veicolano le stesse informazioni, il modello E-R è il più valido dal punto di vista “semantico”.
Per questo, il modello E-R è diventato il “modello principe” per l’analisi dei dati fatta dagli “umani”, mentre il modello relazionale è il modello più diffuso per la rappresentazione dei dati sui computers.



Al di là delle apparenze, il modello E-R ed il modello relazionale sono molto simili. Per tutti e due i modelli, è possibile passare dai diagrammi ad una notazione matematica, formale, basata su semplici concetti di teoria degli insiemi. Tutti e due i modelli, essendo basati su concetti matematici, sono indipendenti dalla tecnologia, e quindi, in qualche modo, “eterni”.
Man mano che si passa dalla realtà “umana”, fatta di concetti, alla realtà dei computers, fatta di bits, i concetti perdono il loro significato semantico e diventano sempre più astratti. La figura che segue rappresenta la gerarchia tra i modelli dei dati usati nel mondo dell’informatica.



Il “modello concettuale” è quello più vicino alla realtà “umana”. Ci sono diversi tipi di modelli concettuali, ma il “modello concettuale” per antonomasia è il modello E-R di Chen.
Al di sotto del modello concettuale, un po’ più vicino al computer, c’è il “modello logico” dei dati. Il “modello logico” imperante nei nostri giorni è quello “relazionale”, introdotto da Edgar F. Codd nel 1969. In passato, ai tempi del mainframe, c’era anche un altro “modello logico” molto in voga: il “modello gerarchico”, che corrispondeva al modo in cui il DL/1, il più diffuso tipo di database che c’era all’epoca, rappresentava i dati sui computer. Il “modello gerarchico” non ha mai avuto successo tra gli accademici, perché corrispondeva ad un modo troppo limitato, troppo vincolato, di rappresentare la realtà. Un “modello logico” più recente, che però non è riuscito a soppiantare il “modello relazionale”, è il modello “object oriented”.
Il “Modello Fisico” corrisponde al modo in cui il modello logico è rappresentato fisicamente sul computer. Nel caso di un modello logico relazionale, il modello fisico corrisponde al DDL (Data Definition Language) che definisce, in SQL (il “linguaggio standard” del mondo relazionale) la struttura delle tabelle, le chiavi, gli indici, ecc.
Qual è il “migliore” tra il modello E-R di Chen, ed il modello relazionale di Codd? Credo che la polemica tra Chen e gli “eredi” di Codd (in particolare, Chris Date) sia tuttora in corso; ma di solito, quando bisogna fare il primo passo nell’analisi dei dati per una nuova applicazione, la maggior parte degli analisti usano quadratini, rombi e linee (cioè il modello E-R). Quando le idee di base sono state chiarite, si passa a disegnare dei rettangoli con un po’ di righe e colonne dentro, collegandoli con delle linee (cioè tabelle: il modello relazionale).
Tutti e due i modelli sono quindi molto validi, anche se di solito sono usati in fasi diverse dell’analisi. Ed è possibile rappresentare tutti e due i modelli usando delle notazioni sintetiche, di tipo “formale”.

Riferimenti esterni
§ http://en.wikipedia.org/wiki/Relational_model
§ Peter P. Chen , Entity-Relationship Modeling: Historical Events, Future Trends, and Lessons Learned.
§ All for One, One for All, by C. J. Date, May 31st, 2006

Cosa sono (esattamente) ILFs ed EIFs?

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:

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.

Un po’ di storia: l’evoluzione del Function Point

L’idea di “misurare” le funzionalità di un’applicazione software solo dal punto di vista dell’utente finale, senza tener conto degli aspetti “tecnici”, “implementativi”, appare affascinante a chiunque abbia avuto a che fare con lo sviluppo di software.
L’”inventore” dei Function Points, Allan Albrecht, ha pubblicato per la prima volta le sue idee nel 1979, nella lontana epoca dei computer mainframe. Albrecht suggeriva di misurare un’applicazione solo sulla base delle funzionalità visibili dall’esterno, come se fosse una “scatola nera”. Il termine “black box” era molto di moda in quegli anni, agli albori dell’ingegneria del software, quando i computers erano “macchine misteriose”.
Le idee di Albrecht furono presto “sponsorizzate” da diversi gruppi di “utenti” di applicazioni software, che diedero vita, nel 1986, all’IFPUG (International Function Point Users Group). L’IFPUG ha sviluppato ed arricchito le idee di Albrecht, pubblicando vari documenti, ed in particolare, un “Manuale di Conteggio” (Counting Practices Manual, CPM), che è oggi arrivato alla versione 4.2.
Alcune delle idee iniziali di Albrecht sono state migliorate, altre abbandonate. Ad esempio, la versione 3.2 del Manuale di Conteggio IFPUG, pubblicata nei primi anni ’90, conteggiava l’invio di messaggi all’utente finale di un’applicazione come un EO indipendente. Quest’idea è stata abbandonata con la versione 4.0 del Manuale, nel 1994.
Una versione successiva del Manuale di Conteggio, la 3.4, aveva introdotto un concetto un pò fantasioso per la misura degli ILF: il cosiddetto “Super File”. In base alla regola del “Super File”, un singolo ILF poteva arrivare a “cubare” anche piu’ di 50 FP, contro i 15 di un ILF “standard”. Anche il “Super File” è stato abbandonato nella versione 4.0 del Manuale.
Dall’IFPUG sono nate diverse associazioni nazionali “dedicate” ai Function Points. In Italia, nel 1990, è stato costituito il GUFPI (Gruppo Utenti Function Point Italia), che ha pubblicato vari documenti interpretativi sui Function Points, ed ha tradotto in italiano tutte le versioni del Manuale di Conteggio, a partire dalla 4.0.
La versione 4.0 del Manuale di Conteggio IFPUG, pubblicata nel 1994, è abbastanza simile a quelle attuali. Facendo un paragone “storico”, mentre le versioni precedenti potrebbero essere viste come il “Medioevo del Function Point”, con la versione 4.0 si può parlare tranquillamente di “Rinascimento”, se non già di “Illuminismo”.
La versione 4.1.1 del Manuale di Conteggio IFPUG, pubblicata nell’aprile 2000, è molto simile alla versione attuale, la 4.2. Dopo aver pubblicato la versione 4.1.1, l’IFPUG si è resa conto di alcune ambiguità insite nella definizione di ILF ed EIF, ed ha rimediato pubblicando, nel settembre 2001, un “Addendum al Manuale di Conteggio 4.1.1”. In pratica, si trattava di una sorta di “Errata Corrige”, che chiariva diversi dubbi riguardo all’interpretazione di ILF ed EIF.
La versione attuale del Manuale di Conteggio IFPUG, la 4.2, è stata pubblicata nel 2004. Si tratta in realtà della versione 4.1.1 integrata con l’”Addendum” sugli ILF già pubblicato nel 2001.
Con la versione 4.2 del Manuale di Conteggio, possiamo dire di essere entrati a pieno titolo nell’”Era Moderna” del Function Point. Le definizioni fornite per l’individuazione ed il conteggio di ILF, EIF e transazioni sono così precise da poter essere “formalizzabili”. Non è difficile immaginare un tool che, partendo da una definizione formalizzata del modello dei dati e delle transazioni di un’applicazione (ad esempio, partendo dal modello prodotto con un CASE Tool per il disegno di applicazioni), sia in grado di generare automaticamente il “Modello Funzionale” dell’applicazione, ed il relativo conteggio in FP.

Riferimenti

§ A. J. Albrecht, “Measuring Application Development Productivity,” Proceedings of the Joint SHARE, GUIDE, and IBM Application Development Symposium, Monterey, California, October 14-17, IBM Corporation (1979), pp. 83-92
§ Charley Tichenor, “Recommendations For Further Function Point Research”, http://www.softwaremetrics.com
§ IFPUG, International Function Points User Group, http://www.ifpug.com
§ GUFPI, Gruppo Utenti Function Point Italia, http://www.gufpi.org/

Che cosa sono i Function Points?

I Function Points si basano su un’idea affascinante: “misurare” le funzionalità di un’applicazione software solo dal punto di vista dell’utente finale, senza tener conto degli aspetti “tecnici”, implementativi dell’applicazione. Quest’idea appare tanto affascinante, quanto utopistica, a chiunque abbia a che fare con lo sviluppo di software.
La tecnica dei Function Points richiede la "traduzione" dei Requisiti Funzionali di un'applicazione in un cosiddetto “Modello Funzionale”, che è formato dai seguenti elementi:

- Funzioni di tipo dati (ILF ed EIF): sono una rappresentazione logica degli archivi usati dall'applicazione; sono di due tipi: Internal Logical Files (ILF) ed External Interface Files (EIF); gli ILF sono gli archivi interni dell’applicazione; gli EIF sono archivi esterni;

- Funzioni di tipo transazione (EI, EQ ed EO): sono una rappresentazione logica delle transazioni dell'applicazione; tutte le transazioni dell’applicazione vanno classificate e ridotte a questi tre tipi; gli External Inputs (EI) acquisiscono informazioni dall'esterno dell'applicazione; invece gli External Inquiries e gli External Outputs (EQ ed EO) mandano informazioni fuori dal confine dell'applicazione.

Ad ognuna di queste cinque tipologie di funzioni, la tecnica dei Function Points assegna un livello di complessità ("Alto", "Medio", "Basso"), basandosi su caratteristiche quali, ad esempio, il numero di campi per gli ILF, oppure il numero di ILF acceduti per gli EI.

Ad ogni funzione, in base al suo livello di complessità, è assegnato un valore in Function Points (spesso abbreviato in FP); questo valore è la "misura" della funzione stessa. Ad esempio, la misura in FP per un EI può variare da 3 FP (bassa complessità) a 6 FP (alta complessità).

La misura in Function Points di un'applicazione è la somma delle misure in Function Points delle funzioni che la compongono.