• Non ci sono risultati.

Algoritmo 2 Aggregate Input: F(D, σ)

5.3 Architettura logica del sistema

Logicamente il sistema di Detection `e stato suddiviso in quattro moduli o package:

• Patterns

Questo modulo contiene le principali classi per rappresentare i dati in input come Pattern e Item. Si `e ritenuto opportuno separarlo nel contesto perch`e possiamo vederlo come il contenitore delle strutture base del sistema. Oltre a queste classi, il modulo incapsula la classe DPattern che serve per rappresentare i pattern dedotti con l’ultimo algoritmo esaminato nel precedente capitolo.

• Lattices

Questo modulo contiene un insieme di classi per rappresentare l’insieme degli itemset σ frequenti dati in input al sistema.

• Detector

Questo modulo contiene tutti gli algoritmi necessari per eseguire la Detection sull’insieme degli itemset in input.

• Domain

Infine, l’ultimo modulo, permette di rappresentare la conoscenza di dominio degli attributi in input.

La figura ?? mostra una rappresentazione di come sono organizzati i moduli sopra elencati. Secondo la notazione UML le freccie tratteggiate equivalgono alla relazione di dipendenza <<usa>>. Come `e possibile notare, vediamo

Figura 5.1: Archittettura Logica di sistema di Detection: grafo delle dipendenze

che il modulo Patterns `e il fulcro principale nelle relazioni di dipendenza tra moduli.

Assumendo che il sistema di Detection sia ad esempio una libreria, possiamo considerare un ulteriore modulo ”Main” che funge da cliente nei sui confronti. Il modulo cliente fornisce al sistema di Detection i dati di unput, letti da un file e, processa il risultato finale scrivendolo su un file di output.

5.3.1

Patterns

• Classe Item

Nella nostra rappresentazione, l’oggetto che sta nel gradino pi`u basso `e l’item. Gli item ci permettono di rappresentare tutti i valori che pos- sono assumere tutti gli attributi in input. La classe Item ha uno stato relativamente semplice che `e rappresentato da due tipi String che sono rispettivamente value e domainName. Essi rappresntano il valore e il dominio dell’attributo. Per interrogare lo stato dell’oggetto vengono forniti i metodi di getvalue():String e getDomainName():String.

• Classe Pattern

La classe Pattern permette di rappresentare un’ insieme di item. Essa, mediante l’uso di tipi di dato parametrici, incapsula un Vector<Item> items che tiene traccia di tutti gli item che compongono un pattern.

Tra i servizi pi`u importanti che offre tale classe citiamo:

– commonsPattern(p:Pattern):Pattern

Questo metodo ritorna un pattern contenente tutti gli item co- muni all’oggetto Pattern che ha invocato il metodo e, il Pattern p passato per parametro.

– notCommonsPattern(p:Pattern):Pattern Svolge la funzione opposta.

– Match(p:Pattern):Boolean

Fa il match tra l’oggetto Pattern invocante e il Pattern p passato per parametro. Ritorna true se il match va a buon fine.

– subSet(seed:Pattern):Vector<Pattern>

Il metodo calcola l’insieme dei possibili sottoinsiemi di un Pattern. L’insieme viene calcolato sulla base di un pattern che rappresenta il seme comune a tutti i sottoinsiemi calcolabili.

Questo insieme viene ritornato utilizzando un vettore parametrico di tipo Pattern.

Figura 5.2: Schema UML delle Classi Item e Pattern

Poich`e queste due classi saranno soggette a molti confronti, entrambe estenderanno la classe Comparator implementando il metodo ”com- pare”.

• Classe DPattern

La classe DPattern modella un insieme di pattern aggregati, tali pattern rappresentano una regione di pattern del database. Lo stato della classe `e un vettore parametrico di pattern Vector<Pattern> patterns e un valore di tipo int sup che indica il supporto complessivo di tutti i pattern che l’oggetto contiene.

Secondo l’ultima versione dell’algoritmo elaborato, questo oggetto viene creato quando si esegue la fase di espansione della conoscenza.

Figura 5.3: Schema UML della Classe DPattern

La classe contiene tre metodi privati che consentono di trasformare, a seconda dei ”connettivi” con cui sono legati gli item contenuti, un pattern espandendo l’informazione contenuta in esso.

Essi sono:

– andWor(common:Pattern, items:Vector<Item>):Vector<String> La procedeura prende in input un Pattern che rappresenta la parte in comune (gli item non negati) e un Vector<Item> che sono tutti gli item negati in AND(∧). Sfuttando la conoscenza di dominio sostituisce tutti gli item in AND(∧) con i rispettivi itemes connessi in OR(∨) rispettando gli opportuni vincoli.

– -disgiuntiveForm(form:Vector<String>):Vector<String>

La procedura prende in input l’output di andWor e distribuisce l’OR(∨) sull’ AND(∧) per tutti gli item in input.

– -buildPattenrs(dform:Vector<String>):Vector<Pattern>

Quest’ultima procedura costruisce lo stato della classe DPattern scandendo tutti gli item che sono in forma normale disgiuntiva. Alla fine del processo costruisce un Vector<Pattern>.

Un altro metodo interessante che mette a disposizione la classe `e filterOnOr(): String che pu`o essere utilizzato nella fase di output per ricompattare un pattern eliminando gli item in OR(∨) e sostituendoli con gli equivalenti in AND(∧) ma negati.

La figura ?? riassume l’organizzazione delle classi per il modulo Patterns. Per una questione di comodit`a le classi Pattern e DPattern estendono la classe astratta NkPattern.

Infatti per gestire in output l’insieme dei pattern non k-anonimi si `e scelto di far ereditare tale classe astratta in modo da poter scorrere l’insieme dei pattern non k-anonimi utilizzando un unico contenitore che contiene le due tipologie di pattern i cui supporti sono minori di k.

Figura 5.4: Diagramma delle classi per il modulo Patterns

Inoltre in figura ?? possiamo notare le relazioni di dipendenza di tipo <<usa>> tra le varie classi.

5.3.2

Lattices

Prima di introdurre le classi che fanno parte di questo modulo facciamo una breve parentesi su una scelta implementativa che ci sembra doverosa riportare.

Nel capitolo che trattava il modello di Detection per database binari avevamo introdotto le definizioni di itemset chiusi, essi sono una rappresentazione compatta dell’insieme degli itemset σ frequenti che consentono di ridurre il costo di ricerca dei pattern k-anonimi.

Nel capitolo riguardante il modello di Detection per database inter-attributo abbiamo supposto che l’algoritmo lavorasse sull’insieme non compatto, adesso, nella fase di implementazione, ci `e sembrato opportuno utilizzare tale rap- presentazione per ridurre i costi di ricerca.

Il modulo `e organizzato nelle seguenti classi:

• Interfaccia ILattice

E’ un interfaccia con i seguenti metodi :

– frequents():Vector<Pattern>

Ritorna tutti gli itemset contenuti nell’insieme degli itemset σ frequenti.

– closed():Vector<Pattern>

Ritorna tutti gli itemset in forma compatta.

– maximal(closed:Vector<Pattern> ):Vector<Pattern>

Ritorna tutti gli itemset in forma compatta che sono massimi.

• Classe Tools

E’ la classe che in realt`a implementa le operazioni richieste dall’inter- faccia ILattice. Tali operazioni sono implementate con metodi stati- ci, affinch`e tutte le classi che implementano l’interfaccia possano ac- cerdervi senza istanziare nessun nuovo oggetto.

• Lattice

E’ la classe base per rappresentare un insieme di itemset σ frequen- ti. L’insieme viene creato al momento dell’istanziazione utilizzando il metodo privato buildFI.

• Classe ExLattice

Questa classe rappresenta l’insieme dei pattern costruiti espandendo l’insieme dei pattern in input rappresentati dall’oggetto Lattice. L’espansione avviene scandendo l’insieme degli itemset σ frequenti e applicando il principio di inclusione-esclusione.

Per tutti i pattern derivabili che non hanno supporto nullo viene creato un oggetto DPattern. Ad ogni scansione ogni nuovo DPattern viene aggiunto allo stato che `e rappresentato dal vettore Vector <DPattern> patterns.

Nello stato della classe ExLattice inoltre `e presente un vettore Vector< String > patJustEx che rappresenta tutti i DPattern gi`a espansi, com- pattati come stringhe. Durante la fase di espansione, utilizzando patJus- tEx, si controlla che l’algoritmo non creei nuovi DPattern che in realt`a siano delle ridondanze in quanto gi`a aggiunti in precedenza.

Figura 5.5: Schema UML delle Classe ExLattice

Documenti correlati