• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
OMARI TESI
 

OMARI TESI

on

  • 1,722 views

SVILUPPO DI UN SOFTWARE GESTIONALE BASATO SU DECRETI EUROPEI PER IL MONITORAGGIO DI STABILIMENTI ADIBITI ALLA PRODUZIONE DI MERCI DI ORIGINE ANIMALE

SVILUPPO DI UN SOFTWARE GESTIONALE BASATO SU DECRETI EUROPEI PER IL MONITORAGGIO DI STABILIMENTI ADIBITI ALLA PRODUZIONE DI MERCI DI ORIGINE ANIMALE

Statistics

Views

Total Views
1,722
Views on SlideShare
1,722
Embed Views
0

Actions

Likes
0
Downloads
6
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    OMARI TESI OMARI TESI Document Transcript

    • 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 Laureando Prof. Fulvio Sbroiavacca Aleš Omari Anno Accademico 2009 / 2010 5
    • 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 6
    • 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 7
    • Ringraziamenti Un grazie particolare alla mia famiglia per avermi dato fiducia e la possibilità di fare tutto questo. 8
    • 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. 9
    • 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. 10
    • 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. 11
    • Capitolo1 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 12
    • 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 13
    • 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; 14
    • 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 15
    • 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 16
    • Capitolov2 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 17
    • 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. 18
    • Capitolov3 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 19
    • 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 20
    • 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. 21
    • 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. 22
    • 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 = 23
    • 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, 24
    • 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. 25
    • 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 26
    • 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à. 27
    • 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 28
    • 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. 29
    • 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. 30
    • 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. 31
    • 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: 32
    • 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 33
    • 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 34
    • 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. 35
    • 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. 36
    • 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. 37
    • Capitolo 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: 38
    • 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. 39
    • 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 . 40
    • 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. 41
    • 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. 42
    • 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. 43
    • 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. 44
    • 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 45
    • 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. 46
    • 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. 47
    • 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. 48
    • Capitolo 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, 49
    • 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", 50
    • "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. 51
    • 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. 52
    • 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. 53
    • 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. 54
    • 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 55
    • APPENDICE Schema relazionale della base di dati “OBRATI” 56