Embed Size (px)
DESCRIPTION
SVILUPPO DI UN SOFTWARE GESTIONALE BASATO SU DECRETI EUROPEI PER IL MONITORAGGIO DI STABILIMENTI ADIBITI ALLA PRODUZIONE DI MERCI DI ORIGINE ANIMALE
Citation preview
5
UNIVERSITÀ DEGLI STUDI DI TRIESTE
FACOLTÀ DI INGEGNERIA
Corso di Laurea Triennale in Ingegneria Informatica
SVILUPPO DI UN SOFTWARE GESTIONALE BASATO SU DECRETI EUROPEI
PER IL MONITORAGGIO DI STABILIMENTI ADIBITI ALLA PRODUZIONE DI
MERCI DI ORIGINE ANIMALE
Relatore Prof. Fulvio Sbroiavacca
Laureando Aleš Omari
Anno Accademico 2009 / 2010
6
INDICE
INDICE ..................................................................................................................................................6
Ringraziamenti ...............................................................................................................................9 Introduzione.................................................................................................................................10
Obiettivo della tesi ...............................................................................................................10
Capitolo 1.............................................................................................................................................12 I DECRETI EUROPEI............................................................................................................12
1.1 Regolamento CE 88/2006 Acquicolture ..................................................................12 1.2 Decreto 1774/2004 CE Sottoprodotti di origine animale....................................13 1.3 Regolamento 183/2005 Igiene dei mangimi ...........................................................14 1.4 Decreto 853/2004 Alimenti di origine animale .......................................................15
Capitolo 2.............................................................................................................................................17 CHI È IL VURS – VARS ........................................................................................................17
Capitolo 3.............................................................................................................................................19 L’APPLICAZIONE “VURS OBRATI” ...............................................................................19
3.1 LA GESTIONE DEGLI UTENTI E DEI DIRITTI........................................21 3.1.1 La verifica degli utenti.........................................................................................23
3.2 IL MODULO PER L’INSERIMENTO DEGLI STABILIMENTI...............26 3.3 IL MODULO DEI REPORT ..................................................................................28 3.4.1 Creazione del report ...........................................................................................30
3.4 IL MODULO DELL’ AMMINISTRATORE......................................................34 3.4.1 La gestione dei registri........................................................................................36 3.4.2 Visualizzazione di informazioni degli utenti connessi..................................37 3.4.3 L’inserimento del comunicato ..........................................................................37
Capitolo 4.............................................................................................................................................38
LE BASE DI DATI...................................................................................................................38 4.1. PANORAMICA DEGLI ARCHIVI ......................................................................40
4.1.1 L’ARCHIVIO OBRATI ...................................................................................40 La tabella OBR_PLANTS......................................................................................41 La tabella OBR_REG_DEF..................................................................................43 La tabella OBR_PLANTS_REG..........................................................................41 La tabella OBR_REGISTRY ................................................................................41 La tabella OBR_REGITRY_ACT .......................................................................41 La tabella OBR_ACTIVITIES..............................................................................42 La tabella OBR_APPLOG ....................................................................................42
4.1.2 LO SCHEMA “HK_DIST_IN”.....................................................................44 F_FISH_FARMS.....................................................................................................44
7
F_FISH_FARM_COORDINATES ...................................................................44 F_FISH_FARM_CONTACTS ............................................................................44 F_FISH_FARM_FISH...........................................................................................45 F_FISH_FARM_TANKS .....................................................................................45 F_FISH_FARM_PURPOSES..............................................................................45 F_PURPOSES .........................................................................................................45 F_FISH......................................................................................................................45 F_TANK_TYPES...................................................................................................45 F_TANK_MATERIALS.......................................................................................46 F_WATER_SOURCE_TYPE .............................................................................46 F_WATER_SOURCES.........................................................................................46 F_WATER_TYPE..................................................................................................46
4.1.3 LO SCHEMA “HK” .........................................................................................46 HKV_SUBJ...............................................................................................................47 HKV_KMG..............................................................................................................47 HHV_KMG_SUBJ .................................................................................................47 HKV_ADDRESSES ..............................................................................................47 HKV_ZIP_CODES ...............................................................................................47
4.1.4 LO SCHEMA “SM” ..........................................................................................48 Tabella SM_USERS.................................................................................................48 Tabella SM_PRIVILEGES....................................................................................48 Tabella SM_US_PRIVILEGES............................................................................48 Tabella ORGANIZATIONS................................................................................48
Capitolo 5.............................................................................................................................................49
IL MODULO DELLE ACQUICOLTURE................................................................49 5.1 Inserimento degli impianti delle acquicolture ...................................................49
CONCLUSIONI ........................................................................................................................54 RIFERIMENTI BIBLIOGRAFICI.......................................................................................55 APPENDICE..............................................................................................................................56
8
Ringraziamenti
Un grazie particolare alla mia famiglia
per avermi dato fiducia e la possibilità
di fare tutto questo.
9
RINGRAZIAMENTI
Sono molte le persone che devo ringraziare per questo lavoro. È stata anche la loro presenza e
i loro consigli che mi hanno permesso di raggiungere questo traguardo importante. Desidero
ringraziare la mia famiglia perché mi ha dato la disponibilità di studiare e mi è stata vicina
durante questo periodo. Dal punto di vista del lavoro devo ringraziare per la pazienza e la
disponibilità tutti coloro che hanno collaborato con me. Desidero esprimere un sentito
ringraziamento al mio relatore, professore Fulvio Sbroiavacca per l'aiuto nella stesura di questo
documento, la cui conoscenza delle esigenze e delle idee si è rivelata di estremo aiuto nella fase
di programmazione del presente lavoro. Infine, un ringraziamento al Vurs il quale mi ha dato la
possibilità di stesura di tale tesi.
10
INTRODUZIONE
In relazione alle misure preventive adottate sul territorio nazionale sloveno in particolare nel
settore dell’ alimentazione umana ed animale, l’Unione europea per la sicurezza degli alimenti,
ha emanato una serie di norme tese a garantire la sanità pubblica. Tali regolamenti hanno lo
scopo di istituire una procedura comunitaria che stabilisce i principi e i requisiti generali della
legislazione alimentare per assicurare un sistema di sorveglianza attiva che consenta
l'individuazione delle conformità volte a prevenire, eliminare o ridurre a livelli accettabili i
rischi per gli esseri umani e per gli animali.
Obiettivo della tesi
Alla luce di queste disposizioni normative predisposte dal Unione europea, le autorità
competenti hannmo l’obbligo di tenere registri appositi, dove registrare le attività svolte dagli
stabilimenti e lo storico dello stato di salute di essi. Essendo un dipendente dell’ azienda ORIA
d.o.o. vincitrice del bando di gara, mi è stato attribuito il compito di collaborare nello sviluppo
dell’ applicazione e di seguire le eventuali modifiche future.
La presente tesi riguarda lo sviluppo di una applicazione software per la gestione e la
memorizzazione di tali stabilimenti operanti nella produzione di prodotti e sotto prodotti di
origine animale e mangimi, commissionato dal Ministero delle Politiche Agricole, Alimentari e
Forestali della repubblica Slovenia (MKGP), dopo l’esito favorevole della procedura di gara per
la realizzazione di un software gestionale atto a gestire tali stabilimenti.
Il software si basa su una piattaforma realizzata in azienda che implementa il framework open-
source Struts. Struts è un'implementazione Java server-side del design pattern MVC (Model
View Controller). Per automatizzare le procedure di salvataggio su base di dati si è scelto il
uno strato di middleware chiamato Hibernate il quale automatizza le procedure per le
operazioni cosiddette CRUD (Create, Read, Update, Delete) dei database.
11
La creazione dell’ applicazione è stata suddivisa in due fasi. La prima fase prende in
considerazione la creazione base del software per la gestione di stabilimenti per la produzione
di alimenti di origine animale, la produzione di mangimi per animali e la gestione di sotto
prodotti animali. La seconda fase comprende l’aggiunta di un nuovo modulo per la gestione di
stabilimenti di acquicolure e maricolture.
12
C a p i t o l o 1
I DECRETI EUROPEI
La creazione di questa applicazione è fondamentalmente basata sull’attuazione di una serie di
decreti e regolamenti della Comunità Europea. Qui di seguito sono descritte specificatamente
tali normative, attuate dalle Nazioni Comunitarie, per la gestione, il mantenimento ed il
controllo dello stato di salute degli animali e degli uomini.
1.1 Regolamento CE 88/2006 Acquicolture
La presente direttiva prende in considerazione le specie animali d’acquacoltura e le condizioni
ambientali che possono influire sullo stato sanitario di tali specie. In linea generale, le
disposizioni della presente direttiva vanno applicate agli animali acquatici in quanto animali vivi
come pesci, molluschi e crostacei laddove la situazione ambientale possa pregiudicare lo stato
sanitario degli animali d’acquacoltura.
Tale direttiva europea prevede l’introduzione di un sistema di autorizzazione per le imprese di
acquacoltura. Tale autorizzazione consente alle autorità competenti di definire un quadro
completo del settore dell’acquacoltura, utile ai fini della profilassi, del controllo e dell’
eradicazione delle malattie degli animali acquatici. Inoltre, grazie a tale autorizzazione è
possibile fissare prescrizioni specifiche che le imprese di acquacoltura. Pertanto, il regolamento
stabilisce misure minime di profilassi della malattia e di contenimento dei rischi da applicarsi
all’intera catena produttiva dell’acquacoltura, dalla fertilizzazione all’attecchimento delle uova
fino alla trasformazione degli animali d’acquacoltura per il consumo umano, incluso il
trasporto.
Al fine di migliorare la prevenzione dell’insorgenza e della diffusione delle malattie di cui
all’allegato IV della direttiva 2006/88/CE, ogni stato membro deve mettere a disposizione per
13
via elettronica le informazioni relative alle imprese del settore dell’acquacoltura e agli
stabilimenti di trasformazione riconosciuti, con particolare riferimento alle specie detenute e al
loro stato sanitario. Nell’allegato I, II e III della direttiva sono specificate le informazioni da
annotare nel registro ufficiale delle imprese e di stabilimenti riconosciuti che detengono
reciprocamente pesci, molluschi e crostacei.
1.2 Decreto 1774/2004 CE Sottoprodotti di origine animale
Il regolamento (CE) n. 1774/2004 costituisce la pietra migliare della nuova legislazione
europea in materia di sicurezza alimentare. Adottando l'approccio "dai campi alla tavola" e
facendo ricorso ai pareri scientifici più recenti, intende assicurare un livello elevato di salute e
sicurezza lungo tutta la catena alimentare. Il decreto si applica per la raccolta, il trasporto, il
magazzinaggio, la manipolazione, la trasformazione e l’uso o l’eliminazione dei sottoprodotti di
origine animale al fine di evitare i rischi che tali prodotti potrebbero comportare per la salute
pubblica o degli animali, l’immissione sul mercato e, in taluni casi specifici, l’esportazione e il
transito di sottoprodotti di origine animale e dei prodotti da essi derivati.
I sottoprodotti di origine animale sono definiti quali corpi interi o parti di animali o prodotti
di origine animale non destinati al consumo umano. Essi corrispondono a più di 15 milioni
di tonnellate di carne, prodotti caseari e altri prodotti, tra cui il letame. Tali materie sono
successivamente eliminate o trasformate e riutilizzate in numerosi settori, tra cui il settore
cosmetico o farmaceutico come anche per altri usi tecnici.
In seguito alle crisi alimentari degli anni '90 come l'epidemia di encefalopatia spongiforme
bovina (BSE), è stato evidenziato il ruolo di questi sottoprodotti nella propagazione di
malattie animali. Il Comitato scientifico direttivo è giunto alla conclusione che i prodotti
provenienti da animali dichiarati inadatti al consumo umano non devono entrare nella catena
alimentare. Inoltre, la somministrazione a qualsiasi animale di proteine ottenute da cadaveri
14
della stessa specie, il cosiddetto cannibalismo può costituire un rischio supplementare di
propagazione di malattie.
Ogni stato membro è obbligato a mettere a disposizione agli altri Stati membri e al pubblico
elenchi aggiornati di impianti approvati ai sensi dell’ articolo 26, paragrafo 4, del regolamento
(CE) n. 1774/2002 ("impianti approvati"). Pertanto ogni autorità competente deve predisporre
un sito web contenete l’elenco degli stabilimenti approvati.
Il presente regolamento stabilisce le norme sanitarie e di polizia sanitaria per:
• la raccolta, il trasporto, il magazzinaggio, la manipolazione, la trasformazione e l'uso o
l'eliminazione dei sottoprodotti di origine animale;
• l'immissione sul mercato e, in taluni casi specifici, l'esportazione e il transito dei
sottoprodotti di origine animale e dei prodotti da essi derivati.
1.3 Regolamento 183/2005 Igiene dei mangimi
A livello comunitario il regolamento stabilisce condizioni e disposizioni atte ad assicurare la
rintracciabilità dei mangimi fin dalla produzione primaria dei prodotti agricoli (coltivazione e
raccolto) coinvolgendo tutti gli attori in tutte le fasi della produzione, a partire dalla produzione
primaria dei mangimi, fino a e compresa l'immissione dei mangimi sul mercato.
Il regolamento prevede controlli necessari per assicurare il rispetto di standard accettabili di
sicurezza. Il sistema nazionale prevede dei controlli necessari per assicurare il rispetto di
standard accettabili di sicurezza nel campo dell'alimentazione animale comprende attività in
tutte le fasi del settore:
� autorizzazione degli stabilimenti produttori di mangimi e additivi;
� controlli nelle fasi di produzione;
15
� controlli nella fase di commercializzazione;- controlli sui prodotti finiti e sul loro uso
nell'alimentazione animale;
Tali attività vengono svolte da diversi organi di controllo, centrali e periferici, che agiscono sui
vari livelli in maniera sinergica, al fine di garantire la sicurezza dei mangimi e il loro corretto
uso nell'alimentazione animale.
Per ottenere il riconoscimento o la registrazione, le imprese nel settore dei mangimi devono
soddisfare diverse condizioni pertinenti alle loro operazioni per quanto concerne strutture,
attrezzature, personale, produzione, controllo di qualità, stoccaggio e documentazione, per
garantire sia la sicurezza dei mangimi sia la rintracciabilità del prodotto. È consentito agli Stati
membri di concedere un riconoscimento condizionato degli stabilimenti qualora dalla visita in
loco risulti che lo stabilimento soddisfa tutti i requisiti relativi alle infrastrutture e alle
attrezzature. Il decreto predispone la sospensione temporanea, la modifica o la revoca della
registrazione o del riconoscimento qualora gli stabilimenti cambino o cessino le loro attività o
non soddisfino più le condizioni che si applicano alle loro attività. L’autorità competenti hanno
l’obbligo di iscrivere ed i mantenere tali infrastrutture in elenchi nazionali come previsto dall’
articolo 9 del su detto decreto.
1.4 Decreto 853/2004 Alimenti di origine animale
Il presente regolamento stabilisce norme specifiche in materia di igiene per gli alimenti di
origine animale, destinate agli operatori del settore alimentare. Essa si applicano ai prodotti di
origine animale trasformati e non. In materia di salute pubblica, tali norme contengono principi
comuni, in particolare in relazione alle responsabilità dei fabbricanti e delle autorità competenti,
requisiti strutturali, operativi e igienici degli stabilimenti, procedure di riconoscimento degli
stabilimenti, requisiti per magazzinaggio e trasporto e bolli sanitari. Gli obiettivi principali del
regolamento sono di assicurare un livello elevato di tutela dei consumatori per quanto attiene
alla sicurezza degli prodotti, in particolare assoggettando gli operatori del settore alimentare in
tutta la Comunità alle medesime norme, e di garantire il corretto funzionamento del mercato
16
interno dei prodotti di origine animale, in tal modo contribuendo al conseguimento degli
obiettivi della politica agricola comune.
Gli operatori del settore alimentare immettono sul mercato prodotti di origine animale
fabbricati nella Comunità europea solo se sono stati preparati e manipolati esclusivamente in
stabilimenti che soddisfano i pertinenti requisiti del presente regolamento e altri pertinenti
requisiti della legislazione alimentare. Questi stabilimenti vengono registrati ed in seguito ad
accertamenti riconosciuti idonei presso l'autorità competente.
Il presente decreto non prende in considertazione gli stabilimenti che effettuano
esclusivamente:
1. Produzione primaria
2. Operazioni di trasporto
3. Magazzinaggio di prodotti che non richiedono installazioni termicamente controllate
4. Operazioni di vendita al dettaglio
17
C a p i t o l o v 2
CHI È IL VURS – VARS
L'Amministrazione Veterinaria della Repubblica di Slovenia (VURS), ovvero Veterinary
Administration of the Republic of Slovenija (VARS), svolge i compiti amministrativi, di
ispezione e di controllo nel settore veterinario. In aggiunta alle funzioni amministrative, VURS
controlla e sorveglia l'attuazione delle disposizioni legislative, regolamentari e disposizioni
amministrative e degli accordi internazionali.
I compiti più importanti di amministrazione sono:
� Gestire il registro degli animali e delle strutture a livello regionale e nazionale, in
conformità con i regolamenti;
� Attuare ed organizzare il monitoraggio dei prodotti alimentari per gli animali, nei
prodotti di origine animale e nei mangimi per animali;
� Prevedere l'attuazione di analisi annuale dei risultati del monitoraggio, la valutazione
dei rischi per la salute pubblica e degli animali e gli effetti sull'ambiente, e la redazione
delle relazioni annuali;
� Organizzare laboratori autorizzati e laboratori nazionali di riferimento nell'ambito del
VURS per la gestione dei registri dei laboratori;
� Organizzazione e gestione di azioni volte a prevenire, reprimere e debellare le malattie
degli animali e delle zoonosi;
Il VURS comprende dieci uffici regionali e di sei posti di ispezione frontaliera (POI). L’attività
propria dei POI è volta ad accertare la reale presenza, alle condizioni e modi stabiliti dalla
normativa comunitaria, dei requisiti per l’ importazione sul suolo comunitario di partite di
animali vivi o prodotti di origine animale, sulla base delle informazioni desunte dalla
certificazione allegata. Gli Uffici regionali (ROS) sono unità VURS competenti per l'attuazione
dei controlli ufficiali e dei compiti amministrativi a livello regionale, coprendo in tal modo
18
l'intero territorio della Repubblica di Slovenia.Gli uffici regionali sono diretti da direttori, che
sono responsabili per la pianificazione, organizzazione, direzione e controllo delle operazioni
effettuate all'interno di ciascun ufficio regionale competente, stabilendo lo svolgimento di
complessi compiti professionali nell'ambito dei rispettive unità organizzative per le procedure
avviate su richiesta dei clienti.
Figura : Le filiali di confine
Figura : Zone coperte dagli uffici ragionali POI.
19
C a p i t o l o v 3
L’APPLICAZIONE “VURS OBRATI”
L’applicazione si propone di armonizzare i diversi flussi informativi che attualmente
caratterizzano la gestione anagrafica e di alcune informazioni relative alle attività degli
stabilimenti adibiti al trattamento di prodotti di origine animale e simili. L’intervento ha
consentito la costituzione di una base dati corredata di relative funzioni software, dislocata a
livello centrale del VURS ed accessibile per consultazione dagli utenti degli uffici veterinari
periferici del Ministero (POI e ROS). La scelta dell’architettura tecnica (tipo di data-base,
interfaccia grafica) è stata effettuata in sintonia con le strategie di sviluppo previste per
l’architettura complessiva del Sistema Informativo Centrale (SIC) presente al VURS.
Il sistema è sviluppato in ambiente WEB ed è progettato per veicolare le informazioni
attraverso la rete HKOM. La rete HKOM è la rete privata ad alta velocità e capacità che
collega gli enti statali e l'amministrazione pubblica della Repubblica Slovenia. HKOM collega
più di 1600 reti locali sul territorio sloveno. Gli utilizzatori finali della rete sono Comuni,
Ministeri, unità amministrative, i quali accedono a vari servizi in maniera del tutto sicura.
L’applicazione è sviluppata in linguaggio Java sostenuta da un framework basato sull’
architettura Model View Controller (MVC). Nell’ ambito della comunità open-source si
trovano innumerevoli tool, ed è molto complicato valutare la reale validità di tali strumenti
ed integrarli insieme all’ interno di una singola applicazione. La complessità e la difficoltà di
gestione delle applicazioni Java web based, portato alla necessità di appoggiarsi ad una serie
di strumenti come il package utilizzato dall’applicazione, che facilitino il compito dei
programmatori. Il framework utilizzato si propone come un framework di integrazione che
ha come obiettivo la semplificazione di alcune delle operazioni fondamentali nella creazione
di una applicazione.
Per mantenere l'applicazione portabile in tutti i database SQL si è scelto l’utilizzo della
piattaforma middleware Hibernate. Hibernate è un motore di persistenza, utilizzato per
20
realizzare il mapping di tabelle preesistenti in forma di oggetti. Il framework Hibernate
genera le chiamate SQL e toglie lo sviluppatore dal lavoro di recupero manuale dei dati e
dalla loro conversione. Le annotazioni ORM descrivono come le entità devono essere rese
persistenti, l’interfaccia EntityManager invece si occupa di rendere persistenti le entità e di
effettuare operazioni CRUD (Create, Read, Update e Delete) su di esse. L’interfaccia
EntityManager costituisce un ponte tra il mondo Object-Orient ed equello relazionale.
Quando noi richiediamo la creazione di un’entità, l’EntityManager traduce l’entità in un
nuovo record nel database, se richiediamo l’aggiornamento di un’entità esso preleva i dati
relazionali corrispondenti e li aggiorna, se inevece ne richiediamo la cancellazione
l’EntityManager provvede a rimuoverne il record. Viceversa quando richiediamo un’entità
presente nel database, l’EntityManager crea l’entity bean, lo popola con i dati relazionali e lo
restituisce indietro.
Si è scelto Java come linguaggio di programmazione perchè rappresentala scelta ideale per la
progettazione di un’architettura server-side. La portabilità è uno dei suoi punti fondamentali.
La possibilità di avere un linguaggio che sia portabile su ogni tipo di piattaforma di sviluppo
rappresenta un enorme vantaggio poichè uno sviluppatore può scrivere il componente un’
unica volta e renderlo utilizzabile su ogni tipo di ambiente server-side esistente.
Nell’ ambito della comunità open-source traviamo innumerevoli tool, ed è molto complicato
valutare la reale validità di tali strumenti ed integrarli insieme all’ interno di na applicazione. La
complessità e difficoltà di gestione delle applicazioni Java web based, ha portato alla necessità
ad appoggiarsi ad una serie di strumenti che facilitino il compito dei programmatori. Il
framework utilizzato si propone come un framework di integrazione che ha come obiettivo la
semplificazione di alcune delle operazioni fondamentali nella creazione di una applicazione.
L’applicazione è suddivisa in quattro moduli indipendenti che comprendono:
� L’inserimento degli impianti
� La revisione ed editing degli impianti
� La creazione di report specifici
21
� La console di amministrazione
� Il modulo del Help
Tramite questi moduli l’applicazione permette la gestione completa degli stabilimenti. Con
l’ausilio di appositi form, l’utente a seconda dei propri privilegi ha la possibilità di
inserimento e aggiornanento dei dati riguardanti gli stabilimenti.
3.1 LA GESTIONE DEGLI UTENTI E DEI DIRITTI
La soluzione scelta per la gestione delle identità ottimizza e semplifica il processo di gestione
delle identità degli utenti in qualsiasi tipo di infrastruttura informatica o ambiente applicativo.
L’applicazione è composta da una parte visibile a tutti gli utenti e da una sezione privata che
può essere acceduta soltanto dagli amministratori dell'applicazione attraverso le opportune
credenziali di autenticazione.
Per garantire il rispetto delle normative, l’applicazione per la gestione delle identità fornisce
un controllo e una visibilità centralizzata dei privilegi di accesso. I privilegi utlizzati nell’
applicazione sono:
� Privilegio OBR_LOGIN
Per accedere alla applicazione ogni utente deve avere almeno il privilegio di login. In
questo in questo caso l'utente può solo consultare i dati e creare i rapporti.
� Privilegio OBR_EDIT
L'utente ha la possibilità di modificare e impostare tutte le caratteristiche generali
degli stabilimenti e di associarne i registri, e visualizzare lo storico.
22
� Privilegio OBR_FISHSTATUS
Con questo diritto l’utente ha la possibilità di cambiare lo stato delle malattie presenti
negli impianti adibiti ad acquiculture e mariculture.
� Privilegio OBR_ADMIN
L'utente amministratore ha i massimi privilegi, può modificarne i dati tramite la
console dedicata e gestire i registri, visualizzare gli utenti loggiati e tramite lo storico
visualizzare i cambianti apportati sugli impianti.
Tutti i quattro i privilegi sono mappati come parametri nel file di configurazione interno dell’
applicazione. Il file di configurazione contiene tutte le informazioni e le impostazioni di
configurazione interne relative alla web application alla quale fa riferimento. La sua presenza
permette di rendere molto più leggero il processo di configurazione di certi parametri. Tutte
queste impostazioni di configurazione sono memorizzate sottoforma di un documento di
testo con estensione ”.conf”.
Essendo il sitema di autenticazione un sistama centralizzato con il quale vengono gestiti gli
utenti e i loro prvilegi per un gruppo di applicazioni, tutti i privilegi vengono mappati nello
schema “SM”. Il valore del parametro rappresenta il numero identificativo del diritto. I valori
di questi parametri vengono utilizzati in seguito per il conferimento di tali diritti agli utenti.
integration.privs.OBR_LOGIN.id = 105
integration.privs.OBR_EDIT.id = 106
integration.privs.OBR_ADMIN.id = 107
integration.privs.OBR_FISHSTATUS.id = 299
Parte del file di configurazione.Mappaggio privilegi con il reltivo codice.
23
3.1.1 LA VERIFICA DEGLI UTENTI
L’accesso all’applicazione è consentito solo tramite autenticazione. Alla richiesta di accesso
alle risorse del sistema, se non esiste già una sessione attiva, l’utente digita sul form
UserLogin il suo username e la sua password con cui egli accede all’applicazione. Queste
informazioni inserite sono indirizzate al modulo di autenticazione che verifica l’autenticità
dei dati inseriti. La verifica dei dati inseriti è eseguita tramite una pagina di elaborazione. La
validazione delle credenziali avviene mediante la classe EpiDB.
L’applicazione utilizzando le credenziali fornite dall’ utente, lo riconosce ed è quindi in grado
di associargli un certo tipo di autorizzazioni. In pratica l’ utente viene associato a un preciso
profilo che lo autorizza a specifiche funzionalità e rende disponibili determinate funzionalità.
I privilegi disponibili corrispondono in genere ai diversi attori dell'attività manutentiva: chi
inserisce e aggiorna i dati, chi sovrintende al complesso delle attività e alla gestione
dell’applicazione.
L’applicazione adopera un meccanismo molto semplice per la verifica degli utenti basato su
delle chiamate di stored procedures. Le stored procedures facilitano l'implementazione della
sicurezza dei dati del database e separano l'applicazione dalla sottostante struttura dati,
semplificando la scrittura del codice, aumentando la stabilità e la scalabilità dell'applicazione.
Per essere utilizzate, le stored procedure vengono mappate in un file di configurazione dell’
applicazione, per poi essere utilizzate nei metodi :
integration.stored.passwd_encrypt =
begin? : = sm.sm_util_api.fv_passwd_encrypt (?, ?); end;
integration.stored.valid_user =
begin? : = sm.sm_util_api.fn_valid_user (?, ?); end;
integration.stored.user_privileged =
begin? : = sm.sm_util_api.fn_user_privileged (?, ?, ?); end;
integration.stored.fn_alter_user_pass =
24
begin? : = sm.sm_util_api.fn_alter_user_pass (?, ?, ?, ?); end;
Come si nota le procedure che andiamo a chiamare sono contenute nel package
“sm_util_api” dello schema denominato “SM”. L’utente per la connessione verso i database
“OBRATI“, ha solamente l’autorizzazione EXECUTE sul package “sm_util_api”.
All’ inserimento delle credenziali di accesso utente, lo username e la password vengono
passati come valori alla prima stored prodecure fv_passwd_encrypt(?, ?). La procedura elabora i
due parametri e ritorna una stringa, che rappresenta la password criptata. Il valore restituito
viene passato insieme allo username alla seconda stored procedura “fn_valid_user(?,?)”. La
procedura verifica se le credenziali inserite sono corrette, restituendo il referent number dell’
utente. Con il Uid valido instanziamo un nuovo oggetto ObratiUser il quale rappresenterà
l’utente durante l’intera sessione. In caso di fallimento la procedura ritorna il valore -1 e
viene visualizzato a schermo un messaggio d’errore. Creato cosi l’utente, esso è ancora privo
di privilegi. L’assegnazione dei privilegi procede sempre tramite chiamate stored procedure.
Per ogni privilegio mappato nel file di configurazione viene chiamata la procedura
“fn_user_privileged(?,?,?)”. La preocedura verifica se l’utente, ovvero se al proprio numero di
identificazione è associato il codice del privilegio. Ogni utente deve disporre almeno del
privilegio di login, senza il quale gli viene negato l’accesso all’applicazione.
I privilegi ricavati vengono aggiunti all’oggetto ObratiUser in un Set deniminato flags.
Questo Set contiene tutti i privilegi attributi all’utente. Quando un utente tenta di eseguire
un’azione che richiede determinati privilegi, il sistema controlla il flag dell'utente per
verificare che l'utente in questione disponga dei privilegi necessari e, in caso affermativo, che
tali privilegi siano abilitati. In caso contrario l'utente non può eseguire l' operazione.
Per permettere all’utente di autenticarsi una sola volta e garantire quindi il passaggio di dati
tra una pagina e l’altra dell’applicazione si utilizza un oggetto Java chiamato sessione,
rappresentato attraverso la classe HttpSession. Una volta creato un oggetto di tipo sessione,
25
questo può essere utilizzato tramite i suoi metodi per memorizzare qualsiasi tipo di
informazione; esso rimane valido finché non viene invalidato con l’apposito
metodo(session.invalidate()) richiamato quando si clicca sul link Log-out. La creazione di una
sessione comporta in pratica la predisposizione di un’area di memoria per la gestione delle
informazioni.
Ogni qualvolta un utente tenta di loggarsi al sistema, per motivi di sicurezza viene salvato
nella tabella “APP_LOG” la data in cui ha eseguito l’operazione di login, l’indirizzo IP, il
tipo di operazione eseguita e lo username. Se il login non è andato a buon fine viene
evidenziato anche il motivo del fallimento (l’utente non ha accesso all’applicazione, le
credenziali sono errate, ecc.). Lo stesso accade quando l’utente esce dalla applicazione
facendo il logout o in caso di scadenza della sessione.
26
3.2 IL MODULO PER L’INSERIMENTO DEGLI STABILIMENTI
L’applicazione permette di definire tutti gli elementi che vengono gestiti in uno stabilimento.
Oltre a quelli di base, l’utente stesso può inserire l’appartenza del impianto a un certo registro e
stabilirne le attività svolte al suo interno e in base ai controlli effettuati in loco determinare lo
stato di registrazione.
L’ inserimento degli stabilimenti, tranne per i stabilimenti delle acquaculture i quali vengono
inseriti con l’ausilio di metodi automatici schedulati(descriti nel capitolo “Il modulo delle
acquaculture”), avvienne tramite appositi form di inserimento dati.I dati comuni che
caratterizzano gli impianti sono stati suddivisi in tre sottoinsiemi.
La prima parte riguarda l’anagrafica dello stabilimento (scheda stabilimento). Il campo
principale del form è il numero identificativo della persona fisica o giuridica. Con questo
numero è possibile ricavare i restanti dati. Inserendo un identificativo corretto, i restanti
campi del form, tramite una richiesta asincrona, vengono riempiti dai rispettivi dati.
Scheda stabilimento - sezione nominativo.
La seconda sezione del form è dedicato alla raccolta di informazioni che riguardano lo
stabilimento. Ogni stabilimento è identificato tramite il numero univoco detto G-MID. Per
27
ciascun stabilento è neccessario inserire informazioni aggiuntive, come la denominazione, la
persona di contatto ed il responsabile , il numero di telefono e di fax.
Scheda stabilimento - sezione dati del stabilimento.
La terza sezione comprende un elenco di registri attivi precedentemente caricati in tabella.
Ogni stabilimento può appartenere ad uno o più registri. La scelta di almeno un registro è
obbligatoria. Scegliendo un registro viene resa attiva la relativa scheda del registro (scheda
attività) che riguarda le lavorazioni e le attività associate, (es. Impianto per la produzione di
latte crudo) identificazione dei prodotti e dei sottoprodotti. L’elenco in base alle disposizioni
descritte nei relativi decreti viene popoloato con dati prestrutturati già presenti in tabella. L’
utente scegliendo un registro ha l’obbligo di scelta di almeno una attività.
28
Scheda registri - Dati della registrazione, lista attività correlate al registro..
3.3 IL MODULO DEI REPORT
Uno dei requisiti del progetto era la creazione di report prestrutturati. Per migliorare
l’organizzazione dei controlli, per tutelare il benessere animale e per risalire ad eventuali
inadempienze, le autorità veterinarie comunitarie sono tenute a comunicarsi ogni rilievo
riscontrato, affidandosi ai mezzi telematici a disposizione. Per facilitare lo scambio delle
29
suddette informazioni, ogni normativa prevede la creazione di report specifici per ogni
tipologia di produzione. Ogni decreto o regolamento interno dello stato membro elenca una
lista di dati necessari atti a descrivere le caratteristiche degli impianti. Sotto è riportato un
esempio di report tratto dal decreto europeo.
Figura : esempio intestazione report.
Il cliente richiedeva tre principali requisiti per la creazione dei report:
1) L’elenco deve essere restituito in forma di documento PDF
2) Il file PDF deve essere scaricabili attraverso un browser web
3) L’elenco completo deve essere visualizzato a schermo
Avendo già creato applicazioni web J2EE, ma avendo poca esperienza con i documenti in
formato PDF, avevo il bisogno di trovare una libreria Java pura che poteva produrre
documenti PDF. Dopo un' attenta ricerca, imbatttendomi in iText ho trovato una soluzione
che mi permettesse di generare programmaticamente un documento PDF, soddisfacente le
nostre esigenze.
iText è una libreria java per la generazione e modifica dinamica di documenti PDF
direttamente dal codice dell'applicazione. Con essa è possibile creare molto velocemente e
facilmente report anche complessi contenenti tabelle ed altri tipi di formattazione.
30
3.3.1 CREAZIONE DEL REPORT
Come si evince dall'immagine sottostante l’utente ha a disposizione due possibilità tra le quali
scegliere. Le informazioni all’interno dei report sono visualizzate utilizzando il modello
verticale di tabella. Nelle tabelle le celle di intestazione, definite dalle relative direttive, sono
visualizzate nella parte superiore della tabella, mentre i dati corrispondenti sono visualizzati
all’interno di colonne.
Essendo l’intestazione dei report e di conseguenza i dati sottostanti diversi a seconda dei dati
richiesti, sono stati creati appositi metodi che vengono chiamati in base al report richiesto.
Questi metodi, in base alla lingua scelta (sloveno oppure inglese), impostano l' header con le
appropriate diciture e riempiono la tabella con tutti gli oggetti restituiti della query.
Figura : I report possino essere in formato html oppure in file con estensione pdf.
La creazione del report, in entrambi i casi, sia per il report in PDF che per il report in
HTML, segue lo stesso metodo. La fase in cui i due report differiscono è l’ impostazione del
contentType dell’ oggetto response. Inizialmente come prima cosa bisogna istanziare un
oggetto della classe Document che si trova nel package com.lowagie.text.
31
Figura : Settaggio delle proprietà del Document
L’oggetto Document il quale rappresenta il nostro report è attualmente vuoto privo di ogni
formattazione e di dati. Come prima cosa vengono istanziati oggetti di stile Font, i quali
verranno utilizzati in seguito da altri oggetti. Al Document vengono aggiunte apposite
caratteristiche di stile, come la grandezza della pagina, i bordi, il titolo. Per aggiungere i veri
contenuti al nostro documento basta utilizzare gli svariati metodi add messi a disposizione
dalla libreria iText. Il miglior metodo per l’inserimento dei dati è la creazione di una struttura
primaria che contenga i dati. In questo caso utilizziamo l’oggetto Table al quale vengono
aggiunti altri oggetti di tipo Cell, che formattati propriamente contengono i dati che
verranno visualizzati nel file pdf.
32
Figura : Iterazione e riempimento delle celle con i dati.
Generata la lista contenete gli oggetti che rappresentano i dati, essi vengono inseriti a
rotazione, nelle apposite celle. Alle celle viene aggiunto uno dei Font già in precenda creati.
La chiamata al metodo PdfWriter.getIstance() avrà il compito di scrivere sull’oggetto
da serializzare le informazioni che dovranno essere contenute all’interno del nostro
documento.
Creato il PDF in memoria , e non per motivi di sicurezza nel file system ,per poter visualizzare
sul browser il documento creato, bisogna settare il giusto content-type nella response,
scriveremo infatti:
33
response.setContentType(“application/pdf”) per salvare il file come allegato pdf,
oppure
response.setContentType(“text/html”) per visualizzare il contenuto a schermo come
html.
Figura : settaggio dell’ogetto HttpServletResponse
34
3.4 IL MODULO DELL’ AMMINISTRATORE
Alla sezione dell’ amministratore è possibile accedere solamente con il privilegio
“OBR_ADMIN”. In questa sezione l’amministratore di solito solo un utente con questi
privilegi, ha a disposizione una serie di strumenti per la gestione dei registri, il monitoraggio
delle azioni degli utenti, l’inserimento di comunicati.
3.4.1 VISUALIZZAZIONE DEGLI ERRORI E DELLE AZIONI DETTAGLIATE
Uno strumento fondamentale per una applicazione che necessità di un controllo approfondito
del suo stato di vita è il logging delle azioni. Una delle funzioni più importanti per un
amministratore è la visualizzazione dei log, ovvero registri che tracciano informazioni sulle
azioni che gli utenti compiono nel sistema. L'attività di logging consiste nel registrare
automaticamente eventi che vengono generati dal programma in modo da fornire una traccia
che permetta di ricostruire e diagnosticare eventuali problemi.
L’applicazione è strutturata in modo, che segua tutte le attività più salienti. Nel log vengono
tracciate tutte le operazioni effettuate dagli utenti, dal login fino alla uscita dalla applicazione.
Ogni metodo che esegue, su un qualunque oggetto un’ operazione di inserimento e/o di
aggiornamento o richiede la generazione di report, racchiude l’ apposito codice per effettuare
l’inserimento in tabella del log.
log.info("PlantsDB.validateDatabase(): spremenjena aktivnost " + t_id + " (" + t_sl + ")");
Il log tiene traccia anche delle operazioni schedulate, memorizzando eventuali mal
funzionamenti.
Il record di log hanno un tracciato contente le seguenti informazioni:
� La data di inserimento,
� Il numero identificativo ed il nome dell’utente
35
� L’indirizzo IP (dell’ utente)
� Il livello del messaggio
� Il testo libero di log
Figura : Lista degli log.
L’amministratore dell’applicazione ha la possibilità di visualizzare a schermo il log. Agendo
sugli apposti filtri disponibili nel form. Il filtraggio è possibile con la scelta di una finestra
temporale, l’identificativo dell’ utente, il livello del messaggio e il messaggio .
I livelli di log sono:
1. Info per i messaggi di tipo "verbose".
2. Warn per i messaggi di "warning".
3. Error per i messaggi di errore.
36
3.4.2 LA GESTIONE DEI REGISTRI
Questa sottosezione permette di modificare disabilitare e inserire nuovi registri. I registri
presenti nell’applicazione si suddividono in due gruppi. Il primo gruppo comprende registri e
di conseguenza le relative attività, dette build-in. Essendo queste elencate nelle nomate
nazionali, ed avendo una struttura di attività articolata sono già presenti nella struttura dati
dell’ applicativo. Il secondo gruppo raggruppa registri aggiunti in seguito con una struttura
prpria delle attività, lineare senza nodi ovvero sotto attività. I registri non possono essere
rimossi direttamente dall'interfaccia web, questo per mantenere l'associazione tra gli
stabilimenti e i registri. L’utente ha la possibilità la funzione di disabilitazione. I registri
disabilitati non sono più visibili nel form per la scelta del registro. Le associazioni già
presenti tra gli stabilimenti e i registri vengono mantenuti dal sistema nelle relative tabelle.
37
3.4.1 VISUALIZZAZIONE DI INFORMAZIONI DEGLI UTENTI CONNESSI
L'elenco identifica tutti gli utenti collegati e logati all’applicazione con l’applicazione . la lista
include il nime dell’utente, la data e il tempo della’ avvenuta connessione, l’indirizzo IP, se la
connessione è sicura (SSL), l’ulitma azione richiesta.
Figura : Lista degli utenti attualmente logati.
3.4.3 INSERIMENTO DEL COMUNICATO
La sezione compende un semplice form per l’insermento di uno o più comunicati. Questi
comunicati vengono inseriti tabella e ad ogni login utente vengono visualizzati a schermo. I
comunicati contengono informazioni riguardanti i cambimenti fatti all’applicazione.
38
C a p i t o l o 4
LE BASE DI DATI
Oracle Database 10g Enterprise Edition (EE) è la versione di Oracle utilizzata attualmente al
Vurs. Oracle offre la possibilità di gestire le transazioni e la concorrenza. Per consentire
l’utilizzo in contemporanea degli stessi dati da parte di più utenti o applicazioni fornisce un
servizio di blocco dei dati in modifica (lock). Ogni transazione inizia implicitamente con il
primo statement SQL (Structure Query Language) e termina con un COMMIT (conferma) o
con un ROLLBACK. Effettuato il COMMIT o il ROLLBACK i dati variati vengono
confermati e non è più possibile agire sulle transazioni precedenti.
L’applicazione si appoggia ad serie di basi di dati. La base di dati principale dell’ applicazione
è lo schema “OBRATI”. In essa vengono memorizzati tutti i dati che rigurdano gli
impianti. I dati inseriti in questo archivio comprendono informazioni relative alle proprietà
dell’ impianto, l’ubicazione un elenco di tutte le attività svolte da esso e un insieme specifico
di informazioni per ogni categoria(registro) di appartenenza.
Per assicurarne la coerenza dei dati contenuti, l’applicazione è integrata con la più ampia
architettura del sistema informativo del Ministero per i mercati agricoli e lo sviluppo rurale.
In base alle disposizioni vigenti ogni persona giuridica o persona fisica che è attinente alle
attività gestite dalla MKGP deve essere inserita in un apposito archivio denominato ESUB.
Tutte le imprese slovene sono tenute all'iscrizione nel registro delle imprese (PRS), che
costituisce la fonte primaria di certificazione dei loro dati costitutivi, così come i dati dei
cittadini sono archiviati nella anagrafe centrale (CRP). I dati da questi due archivi tramite l’
applicazione di appositi filtri e di procedure schedulate, ogni 15 minuti vengono replicati
nella base di dati ESUB. Il database, nell'insieme complessivo delle tabelle che lo
costituiscono è composto dalle seguenti parti:
39
1. Insieme delle tabelle destinate a contenere le informazioni relative all’ imprese e alle
persone fisiche.
2. Insieme delle tabelle destinate a contenere le informazioni relative al ubicazione,
localizzazione.
3. Insieme delle tabelle di decodifica utilizzate comunemente in ogni contesto.
Essendo la base di dati ESUB un’archivio con un grande mole di dati, da essa vengono
estratti i dati relativi delle persone fisiche e degli impianti per poi essere inseriti nell’ arhivio
“HK”.
Figura: La base di dati ESUB.
Un secondo archivio denominato “HK_DIST_IN” è adibito a dati riguardanti gli impianti
di acquicolture o maricolture. I dati vengono, tramite apposite funzioni, copiate in viste
materializzate, da archivi ubicati presso il MKGP al server del VURS. In questo modo si
eliminano le parti ridondanti e disomogenee che caratterizzata le gestioni dei dati in modo
disgiunto.
40
Un ultimo archivio, ma non meno importante, che con esso vengono gestiti gli utenti e le
autorizzazioni di accesso all’ applicazione. L’archivio “SM” è utilizzato da un svariato
insieme di applicazioni. L’archivio è composto da tabelle destinate a contenere informazioni
degli utenti e le relative autorizzazioni ed uffici regionali associati ad essi. In modo da
assicurare la sicurezza dei dati, l’accesso per l’autorizzazione degli utenti viene rilasciata
tramite chiamate a stored procedures.
Figura: Lo user “obrati”, con le relative basi dai dati.
4.1. PANORAMICA DEGLI ARCHIVI
4.1.1 L’ARCHIVIO OBRATI
La base di dati a disposizione dell’ applicazione è una base di dati di tipo relazionale
denominata Obrati. Lo schema si compone di 9 tabelle .
41
La tabella OBR_PLANTS
È la tabella principale per l’applicazione, contenente i dati elementari degli impianti. La
chiave primaria è il campo REC_ID che identifica il record ma non l’impianto. Esso viene
identificato tramite il campo ID. In questa tabella viene memorizzato anche lo storico dei
cambiamanti per ogni record. Ad ogni azione di aggiornamento, si crea una nuovo record
incrementando il campo REC_VERSION e ponendo il vecchio record inattivo, impostando
il campo REC_ACTIVE a false. In questo modo e possibile rintracciare un dato stabilimento
con il relativo storico dei cambiamenti.
La tabella OBR_PLANTS_REG
Rappresenta la tabella di congiunzione tra le tabelle OBR_PLANTS e
OBR_REGISTRY.Ogni impianto può appartenere ad uno o a più registri elencati nella
tabella dei registri. Per esempio può appartenere al registro dei mangimi e alla coltura dei
pesci. In questa tabella si evidenzia l’appartenenza dell’impianto ai registri, lo stato della
registrazione oppure approvazione da parte dell’ veterinario. La tabella è costituita da due
sole colonne, una per l’identificativo dell’impianto ed una per l’identificativo del registro della
tabella OBR_REGISTRY.
La tabella OBR_REGISTRY
Ogni impianto può appartenere ad uno o più registri (per esempio al foodReg ed al feedReg).
La tabella memorizza i dati relativi del registro dell’ impianto, elencati nella tabella
OBR_REG_DEF. In esso è possibile identificare il tipo di registro d’appartenenza lo stato di
riconoscimento o della registrazione del impianto determinati dalla soddisfazione dei
requisiti relativi alle infrastrutture e alle attrezzature, il codice dell’approvazione.
La tabella OBR_REGITRY_ACT
Ad ogni registro sono associate un serie di proprietà come attività, prodotti e servizi.
42
La tabella contiene l’elenco delle attività( elenacate nella tabelle OBR_ACTIVITIES) scelte
dall’utentetramite ilo form, appartenenti ad un registro.
La tabella OBR_ACTIVITIES
La tabella contiene tutte le possibili attività realive ai registri attualmente presenti nella tabella
OBR_REG_DEF. I dati archiviati creano una struttura a forma di albero. Il campo
ACT_TYPE contiene informazioni che stabiliscono il collegamento gerarchico fra i nodi. Il
livello dell’ labero è di tre livelli ognuno segnalati con caratteri.
S Sezione - primo livello
P Attività - secondo livello
A Tipo di animale - terzo livello
La tabella raffiura i tre livelli dell’albero
La tabella OBR_APPLOG
Nella tabella si memorizzano informazioni relative alle attività svolte durante l’utilizzo
dell’applicazione. Nella tabella si registrano non soltanto le informazioni relative all'accesso,
ma anche gli eventuali errori dell’applicazion, messaggi di varia natura. In base della gravità
dell’errore o del messaggio i log vengono caratterizati da un codice.
Ad ogni messaggio di log è associato un Level, che come detto corrisponde più o meno
all'importanza e all'urgenza del messaggio.
1 Info 2 Warning 3 Error
La tabella raffigura i vari livelli di messaggi.
43
La tabella OBR_REG_DEF
La tabella contiene la lista dei registri. Per mantenere l’applicazione multilingue nel record
comprende per ogni lingua la possibilità d’inserimento di un testo breve e di un testo lungo.
Chiaramente ogni record è identificato tramite una chivae primaria e da un sigla comune per
ogni lingua
I registri attualmente inseriti sono:
foodReg Alimenti di origine animale - impianto registrato
foodApp Alimenti di origine animale - impianto approvato
feedReg Mangimi - impianto registrato
feedApp Mangimi - impianto approvato
abpApp Sottoprodotti di origine animale - impianti approvati
abpCol Sottoprodotti di origine animale - centri di raccola
abpSpc Sottoprodotti di origine animale - utilizzatori speciali
abpTra Sottoprodotti di origine animale - traportatori registrati
fish Acquicoltura di pesci
crab Acquicoltura di crostacei
moll Acquicoltura di molluschi
La tabella OBR_SETTING
La tabella contiene dati di settaggio per l’applicazione. La tabella è composta da due colonne
,una per la chiave e una per il testo.
44
4.1.2 LO SCHEMA “HK_DIST_IN”
Nello schema HK_DIST_IN vengono inserite le viste relative alle acquicolture. Ogni tabella
che contenga dati relativi alla acquacoltura, in essa è presente il codice identificativo dello
stabilimento.
F_FISH_FARMS
La tabella contiene le informazioni generali, legate all’ impianto. Il dato più importante è il
codice identificativo dell’impianto ovvero il GMID. Il GMID insieme con la chiave primaria
della tabella, vengono inserite nelle tabelle sottostanti come chiave esterna. Nella tabella sono
riportate altre informazioni, tra qui le due più rilevanti sono il numero del permesso e la
presenza del diritto all’approvvigionamento dell’acqua.
F_FISH_FARM_COORDINATES
Come gia indicato dal nome della tabella, in essa vengono inserite i dati riguardanti le
coordinate legate agli impianti. Le coordinate sono espresse in coordinate Gauss–Krüger.
Ogni impianto viene caratterizzato dalle coordinate :
� L’ubicazione geografica dell’impianto
� I dati relativi all’ approvvigionamento dell’ acqua e del suo scarico (per allevamenti di
pesce, per centri di spedizione, e per stabilimenti di lavaggio a terra)
� I dati del centro dell’ allevamento F_FISH_FARM_CONTACTS
In essa vengono memorizzare i nominativi con le relative informazioni di contatto, come il
numero di telefono e l’indirizzo della mail, della persona di riferimento per ogni impianto.
45
F_FISH_FARM_FISH
La tabella contiene l’elenco per ogni allevamento delle specie ittiche, molluschicole e di
crostacei allevate. La colonna ID_FISH è la chiave esterna che rappresenta il reference number
per il tipo di specie allevata.
F_FISH_FARM_TANKS
Gli allevamenti possono essere a mare o a terra. In entrambi i casi vengono tenuti i dati relativi
per i tipi di bacini di allevamento. Le proprietà caratteristiche degli impianti inserite in tabella
sono la quantità dei bacini, la superficie acquea, la cubatura acquea, la velocità della corrente (in
caso di vasche con acqua corrente), la capacita di allevamento.
F_FISH_FARM_PURPOSES
Nella tabella vengono elencati il tipo oppure lo scopo dell’ allevamento. Per esempio la
tipologia dell’ allevamento, impianto, gabbie stagni.
F_PURPOSES
Ogni allevamento prevede un fine : allevamto di
F_FISH
La tabella contiene l’elenco delle specie ittiche, molluschicole e di crostacei. Tutte le specie che
sono elencate in questa tabella sono identificate tramite un identificatore univoco denominato
ID_FISH.
F_TANK_TYPES
La tabella contiene le varie tipologie di vasche o bacini utilizzate per le colutura. Le specie
vengono allevate utilizzando principalmente vasche scavate in terra o realizzate in cemento o
46
altri materiali artificiali. Per maricolture l’ allevamento avviene in gabbie galleggianti,
utilizzando le risorse idriche naturali, compresi i loro parametri chimico-fisici, con un notevole
risparmio energetico ed economico a favore degli allevatori. Ogni contenitore è individuato
tramite la sua chiave primaria “ID_TANK_TYPE”. La Colonna “ID_SPECIES” identifica
l’appartenenza del contenitore alla relativa specie coltivata (4 per i pesci, 5 per i molluschi e 6
per i crostacei).
F_TANK_MATERIALS
La tabella rappresenta un elenco di tutti i materiali di costruzione utilizzati per i bacini di
allevamento(cemento, platica....).
F_WATER_SOURCE_TYPE
La tabella definisce i codici che identificano se l’acqua all’interno dei bacini è stagnante oppure
stazionaria.
F_WATER_SOURCES
Definisce le fonti dell’ acqua all’interno dell’ allevamento. (mare, acqua di superficie, acque
sotterranee).
F_WATER_TYPE
Definisce la tipologia di acqua utilizzata(acqua dolce, acqua salmastra).
4.1.3 LO SCHEMA “HK”
Lo schema HK è un archivio replicato dal registro delle imprese e l’anagrafe statale.
Comprende un insieme di viste materializzate contenete le relazioni tra i soggetti e i
stabilimenti direttamente e indirettamente gestiti dal MKGP. Le tabelle vengono ripopolate
con dati aggiornati ogni 15 minuti da apposite procedure. L’utente “obrati”, su queste tabelle è
assegnato il privilegio (grant) di oggetto SELECT.
47
HKV_SUBJ
La tabella contiene l’archivio delle persone fisiche e delle imprese. I dati vengono riportati dalla
anagrafe centrale (CRP) e al registro delle imprese (PRS). Ogni persona fisica all’ interno della
base di dati è individuata dal identificatore numerico “ID_SUBJ”. I dati che caratterizzano il
soggetto sono il nome, il cognome, il codice fiscale, il numero di registrazione unico (EMSO),
l’identificativo dell’indirizzo del domicilio (“HS_MID”), ed l’eventuale numero di partita iva.
HKV_KMG
Nella tabella vengono memorizzate i dati relativi agli stabilimenti di produzione. Ogni
stabilimento è individuato tramite il numero identificativo “KMG_MID”. La posizione del
stabilimento è riferita tramite la chiave esterna “HS_MID”.
HHV_KMG_SUBJ
Rappresenta la tabella di collegamento tra i soggetti della tabella HKV_SUBJ e i stabilimenti
presenti nella tabella HKV_KMG. Ogni record contiene l’identificativo dell’ soggetto e
l’identificativo del stabilimento e la chiave primaria “ID_KMG_SUBJ”.
HKV_ADDRESSES
E' un registro nel quale si elencano i beni immobili, con l'indicazione del luogo, il nome della
via, il numero civico, l’identificatore della città e del comune di appartenenzae le coordinate
(Gauss Boaga). Ogni immobile è identificato tramite un identificatore univoco numerico
“HS_MID”.
HKV_ZIP_CODES
La tabella contiene l’elenco dei codici di avviamento postale per ogni località nello stato
sloveno.
48
4.1.4 LO SCHEMA “SM”
Lo schema SM contiene le inforamazioni rigurdanti gli utenti, i loro privilegi e l’appartnenza
ad una organizzazione. L’archvio è un archivio “centrale” usato da varie applicazioni presenti
negli server presso il Vurs, usato per gestire gli utenti e per attribuire ai relativi utenti le
credenziali e i permessi. Da notare che i privilegi vengono mappati utente per utente e non per
gruppi.
Tabella SM_USERS
Nella tabella vengono mappati tutti gli utenti che hanno la possibilita di accedere ad una
applicazione presso il Vurs. In esso sono riportati il nome dell’utente, l’id dell’organizzazione di
apparteneza, lo username e la password. La password per motivi di sicurezza e inserita criptata.
Durante la verifica dell’utente la password viene tramite aposite store proceudre decriptata e
verificata.
Tabella SM_PRIVILEGES
La tabella contiene l’elenco di tutte i privilegi. Ogni privilegio è caratterizzato dal un id
univoco e dal nome del privilegio.
Tabella SM_US_PRIVILEGES
In questa tabella vengono attribuiti al utenti presenti nella tabella SM_USERS i relativi
permessi elencati nella tabella SM_PRIVILEGES.
Tabella ORGANIZATIONS
La tabella contiene un elenco di tutti gli istituti, enti nazionali e uffici appartenete al MKGP. I
dati più importanti nella tabella sono dopo l’ id univoico, il nome , l’ id (hs_mid) dell’
indirizzo.
49
C a p i t o l o 5
IL MODULO DELLE ACQUACOLTURE
All’ interno della applicazione per la gestione di impianti è inserito il modulo per la gestione
di stabilimenti per le acquicolture a terra e a mare. Con il termine “acquicoltura” vengono
considerate tutte le attività umane finalizzate alla produzione di organismi acquatici, tali
attività vengono realizzate in acque marine dolci e salmastre e comprendono le pratiche di
allevamento ittico di tipo estensivo, semiestensivo ed intensivo. Con il termine “maricoltura”
si intendono invece tutte quelle pratiche di allevamento che vengono svolte in mare e che
trovano la loro maggiore applicazione nella molluschicoltura offshore, nella pescicoltura in
gabbie e nelle barriere artificiali sommerse.
5.1 INSERIMENTO DEGLI IMPIANTI DELLE ACQUICOLTURE
La normativa n°8463 impone che ogni operatore dei settori su descritti, ha l’obbligo di
presentare l’appropriato modulo descritto nel paragrafo IV del regolamento, all’ apposito
ufficio locale di competenza del Servizio di Identificazione e Registrazione degli animali in
seguito SIR. All’avvenuta consegna del modulo, lo stabilimento viene dichiarato come
registrato e pronto per essere inserito nell’ apposito registro. Presso l’uffici del SIR l’impianto
viene inserito, tramite un applicazione creata con OracleForms nella apposita base di dati e
verificata la veridicità delle informazioni inserite. I dati così raccolti sono collocati in una
base di dati la cui “proprietà” è dello SIR.
L’applicazione in se, per questo tipo di stabilimenti acquatici non prevede l’inserimento del
impianto direttamente tramite il classico form di inserimento. Non dovendo gestire dei
conflitti tra i due data base ed essendo il tipo dell’ applicazioni parzialmente disconnessa,
50
ossia quella che deve continuare ad operare anche se soggetta a periodiche ed impreviste
cadute della connessione di rete, si è deciso di creare una replica del data base delle
acquaculture.
Il server che contiene la replica è allocato presso il Vurs. I dati vengono inseriti non in
tabelle ma in viste materializzate. Le viste materializzate sono delle tabelle fisiche, i
cambiamenti, gli aggiornamenti delle righe avvengono quando si verificano cambiamenti
nella tabella sottostante. Le viste sono collocate nello schema “HK_DIST_IN”.I due server
ovvero le due basi di dati sono entrambe collegate tramite la rete denominata HKOM.
La sincronizzazione dei dati dal Sir al Vurs viene schedulata in modo che ogni tabella venga
replicata. La replica comprende sia le tabelle contenete dati relativi all’ impianto e sia le
tabelle di supporto, come possono essere tabelle con codici. Per ovviare al problema della
perdita della consistenza delle due basi di dati, i dati ivi contenuti vengono aggiornati
automaticamente a intervalli regolari di 10 minuti eseguendo un fast refresh. In questa
modalità solamente i cambiateti della tabella sottostante vengono apportati alla view. Per
fare questo lavoro la view richiede l’uso di apposite strutture di appoggio. Ad ogni vista
materializzata viene associata una tabella di log. Su questa tabella di log vengono registrati
tutte le variazioni relative della tabella “sorgente”.
CREATE MATERIALIZED VIEW F_FISH_VIEW
FAST START WITH SYSDATE NEXT SYSDATE + 5/1440
AS
SELECT "F_FISH"."ID_FISH" "ID_FISH",
"F_FISH"."ID_SPEC_CATEGORY" "ID_SPEC_CATEGORY",
"F_FISH"."ID_WATER_TYPE" "ID_WATER_TYPE",
"F_FISH"."D_INSERT" "D_INSERT",
"F_FISH"."ID_INSERTER" "ID_INSERTER",
"F_FISH"."ACTIVITY" "ACTIVITY",
"F_FISH"."VALID_TO" "VALID_TO",
51
"F_FISH"."ID_SESSION" "ID_SESSION",
"F_FISH"."NAME_SCI" "NAME_SCI",
"F_FISH"."AUTHOR" "AUTHOR",
"F_FISH"."ID" "ID"
FROM "AKVA"."F_FISH";
CREATE MATERIALIZED VIEW LOG ON "HK_DIST_IN"."F_FISH";
Sql per l’aggiornamento della vista materializzata.
Una volta trasferiti i dati presso le basi di dati dello Vurs, questi dati non sono ancora
disponibili all’ applicazione. La struttura delle tabelle e delle viste non sono compatibili tra
loro. L’applicazione già precedentemente creata non gestiva impianti adibiti alle acquaculture.
Per fare ciò abbiamo bisogno di rendere queste informazioni disponibili all’applicazione in
modo che possa gestire questa tipologia di impianti. Una soluzione scelta è di eseguire un
parziale inserimento degli impianti delle acquaculture costruendo entità nuove rappresentanti
gli impianti presenti nelle viste. L’impianti appartenenti alle acquaculture hanno un set di dati
più ricco dal resto degli impianti. Questo set di dati come possono essere le coordinate
dell’impianto, la capacità degli colture, la presenza si malattie e altri dati resteranno nelle
viste. Tali dati vengono esplicitamente recuperati dalle viste e messi a disposizione dell’utente
che desidera verificare l’impianto o effettuate semplicemente una visura di questi dati.
La creazione dell’impianto all’interno della nostra applicazione non viene eseguita come in
precedenza dal DBMS, ma in maniera programmatica della applicazione stessa. Il progetto
prevede l’uso di uno scheduler. Java offre metodi nativi per poter supportare lo scheduling
dei processi e delle azioni. Le classi deputate a tali compiti sono Timer e TimerTask. La
classe TimerTask dovrà contenere il codice che vogliamo sia eseguito. Per far ciò, occorrerà
sviluppare una nuova classe che estenda TimerTask.
52
TimeTask implementa Runnable e per poterla utilizzare occorre importare il package
java.util.TimerTask. Implementata la nostra classe erede di TimerTask, occorrerà schedulare i
nostri job all’interno del metodo principale, per far ciò ricorreremo all’oggetto Timer.
Il metodo privato executeTask()ad ogni intervallo di tempo esegue un specifico job o task,
ovvero richiama il metodo generatePlant() appartenete alla classe FishDB. Il metodo
generatePlant() come primo compito crea una lista di oggetti FFishFarm, che rappresentano
gli impianti delle acquaculture. Per e prima dell’ inserimento verifica se tutti i dati realtivi
agli impianti sono nelle tabelle.
Il metodo esegue una prima verifica :
1. La presenza di almeno un tipo di acquacoltura (4 - colture di pesci, 5-molluschi, 6 -
crostacei )
2. La presenza di una persona di contatto associata al impianto
3. la presenza dell’ impianto all’ interno delle tabelle contenete i soggetti.
4.
In caso che queste sono incomplete la creazione dell’impianto viene momentaneamente
interrotta, creando un messaggio di errore nella tabella dei log, per poi elaborare le entità che
seguono. Nella tabella di log viene inserito un messaggio di errore, di non avvenuta creazione
dell’ impianto, inserendo il tipo dell’errore, il codice identificativo univoco dell’ impianto e
l’ora della avvenuto errore. L’utente con il privilegio dell’ amministratore potrà in seguito
visualizzare l’ errore dalla console dedicata.
Passata la prima verifica si passa alla seconda verificando chiamano il metodo
isPlantPresentActive(), il quale come dato torna un boolean. Se il risultato è false viene
istanziato un nuovo oggetto Plant. A questo oggetto vengono settate le varie proprietà
caratterizzanti e associati i registri opportuni. L’entità così creata, viene resa persistente
chiamando il metodo storePlant(). In caso contrario, che il metodo isPlantPresentActive()
tornasse false, dall’oggetto FishFarm viene ricavato il gmid. Essendo il gmid un codice
univoco per ogni impianto, con esso istanziamo l’oggetto Plant che rappresenta l’impianto.
53
Figura : Schema logico per l’inserimento e/o aggiornamento di un impianto.
All’oggetto vengono settate i nuovi dati e viene effettuato l’update dell’oggetto nella base di
dati. Per tenere traccia dei cambiamenti di tutti i stabilimenti aggiornati, nella tabella di log
viene inserito un nuovo record.
54
CONCLUSIONI
Questa tesi ha voluto trattare la creazione di una applicazione software per la gestione e la
memorizzazione di stabilimenti operanti nella produzione di prodotti e sotto prodotti di
origine animale e mangimi. Dopo mesi di programmazione per un complessivo di 70 classi,
tutte le specifiche previste sono state implementate. Il software creato viene attualmente usato
come strumento di lavoro giornaliero dagli ispettori del Ministero delle Politiche Agricole,
Alimentari e Forestali della repubblica Slovenia. La creazione dell’applicativo per la gestione di
tali stabilimenti permette di eliminare i punti deboli dell’ attuale organizzazione cartacea del
lavoro, quali la ridondanza delle informazioni e perdita dei dati.
Un possibile futuro dell’applicativo è legato principalmente a due fattori chiave. Uno di questi
due punti riguarda l’aggiunta di nuovi moduli e funzionalità volute dal cliente per migliorare il
lavoro con questa applicazione, come può essere la creazione di un nuovo modulo per l’import
di dati da un file. L’altro fattore che potrebbe portare a una nuova versione è l’adeguamento
dell’ attuale applicativo alle nuove leggi e normative; come possono essere l’aggiunta di nuovi
tipi di stabilimenti o di attività legate ad essi.
55
RIFERIMENTI BIBLIOGRAFICI
Java2 Tutto& Oltre, J. Jaworski, SAMS Publishing - APOGEO
Struts: the complete reference, James Holmes - McGraw-Hill 2004
Oracle Database 10g: The Complete Reference, Kevin Loney – Osborne ORACLE Press
Series 2004
Il pattern MVC, S.Rossini e L.Dozio – MokaByte 2003
Sito ufficiale della Sun - http://java.sun.com
Sito ufficiale di Oracle - http://www. oracle.org
Sito ufficiale del progetto Hibernate - http://www.hibernate.org
Sito ufficiale del progetto Struts - http://struts.apache.org
Manuale pratico di Java vol. 1 e 2, Andrea Gini - www.mokabyte.it
56
APPENDICE
Schema relazionale della base di dati “OBRATI”
