• Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,375
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
12
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Università degli Studi di Trieste Facoltà di Ingegneria Tesi di Laurea Triennale in Ingegneria Informatica Studio e Realizzazione di un SW per la gestione dei profili e delle versioni di applicazioni web in ambiente JEE.Relatore: Laureando:Prof. Maurizio FERMEGLIA Francesco FERONT Anno Accademico: 2009/2010
  • 2. Pag. 1/39A me stesso.Fanculo tutti!
  • 3. 1 - Introduzione Pag. 2/39Indice generale1 - Introduzione.................................................................................................................42 - Sommario.....................................................................................................................53 - Analisi...........................................................................................................................6 3.1 - Maven...................................................................................................................6 3.1.1 - Struttura dei file Pom.xml.............................................................................7 3.1.2 - SCM, Software Configuation Management..................................................8 3.1.3 - Repository.....................................................................................................8 3.1.4 - Property e Filtraggio delle Risorse..............................................................10 3.1.5 - Profili...........................................................................................................11 3.2 - Gestione delle Versioni.......................................................................................12 3.2.1 - SVN, Subversion..........................................................................................13 3.3 - Continuous Integration.......................................................................................13 3.3.1 - Apache Continuum......................................................................................14 3.4 - FTP, Modalità di Rilascio.....................................................................................15 3.5 - Stesura dei Requisiti............................................................................................16 3.6 - Realizzazione modello Concettuale E-R..............................................................18 3.6.1 - Stesura dei Requisiti del Sistema Informativo............................................18 3.6.2 - Glossario dei Termini...................................................................................19 3.6.3 - Schema concettuale E-R..............................................................................204 - Realizzazione...............................................................................................................22 4.1 - Interazione tra Sistemi e Ruolo degli Attori........................................................22 4.2 - Diagrammi di sequenza.......................................................................................23 4.3 - Progettazione Logica e Fisica della base dati......................................................25 4.4 - Implementazione................................................................................................27 4.5 - Tecnologie e Framework utilizzati.......................................................................28 4.5.5 - Hibernate e Gestione della Persistenza......................................................29 4.6 - Definizione dei Servizi.........................................................................................30 4.6.1 - ScmService..................................................................................................30 4.6.2 - CisService....................................................................................................31 4.7 - Interfaccia...........................................................................................................32 4.7.1 - Installazione e Configurazione....................................................................32 4.7.2 - Esempio duso.............................................................................................34 4.8 - Configurazione delle Applicazioni da Gestire.....................................................365 - Conclusioni.................................................................................................................386 - Riferimenti..................................................................................................................39
  • 4. 1 - Introduzione Pag. 3/391 - INTRODUZIONEIn questo lavoro di tesi si tratterà delle tematiche relative alla gestione dei rilasci diapplicazioni web, basate sullambiente Java, da parte di una software house. Inparticolare si affronta la questione delle personalizzazioni, dette anche profili, chedebbono essere realizzate sulle diverse applicazioni per venire incontro alle esigenze ealle specifiche configurazioni dei clienti.Tali personalizzazioni, alle volte anche significative, diventano un problema per lesoftware house che devono gestire i propri applicativi mantenendo al tempo stesso lepersonalizzazioni già effettuate per i clienti. Il rischio in cui si incorre in assenza di unadeguato sistema di tracciatura dei rilasci è di imbattersi in incongruenze, possibili buge disagi per le nuove implementazioni. Inoltre, la difficoltà che si riscontra nellainstallazione di applicazioni fortemente personalizzabili, diviene tale da rendereimpossibile una netta separazione tra gli sviluppatori e gli addetti al cosiddetto“deploy”, ovvero la procedura di messa in produzione, che necessiterannoinevitabilmente di aiuti.Come scopo finale, si vorrebbe realizzare una applicazione che permetta di gestire daun lato la possibilità di definire un profilo di compilazione specifico per il dato cliente edallaltro mantenere traccia di quanto viene rilasciato e in che contesto.Attualmente, soluzioni software che permettano la gestione dei profili esistono soloallinterno di specifici ambienti di sviluppo, ovvero necessitano delladozione distandard tecnologici e di implementazioni forzate nella realizzazione delle applicazioni.Tale situazione implica che, la scelta di adottare una soluzione esistente, viene adessere subordinata allattuale contesto di sviluppo della software house.Per realizzare questo lavoro si è dunque proceduto alla analisi della situazione attualedi una grossa azienda di produzione software, nello specifico INSIEL MERCATO (InsielMercato S.p.A. con unico socio, località Padriciano 99 - AREA Science Park - 34149Trieste). Lazienda è impegnata nello sviluppo di applicazioni per la pubblicaamministrazione e per la sanità, e fornisce i propri applicativi a diversi clienti per i qua liè necessario effettuare delle differenziazioni anche notevoli. Il reparto tecnologico chesi è preso in considerazione è quello delle applicazioni web basate su ambiente javaJEE. Successivamente si è analizzato linsieme di tecnologie utilizzate per gli sviluppidelle suddette applicazioni, e tra queste si è ricercato il contesto comune chepermettesse la possibilità di realizzare delle personalizzazioni con una modalitàfacilmente adottabile da tutti gli applicativi attualmente in rilascio, con il minimo sforzodi adattamento. Il passo finale ha consistito nel realizzare una applicazione che sioccupasse di tenere traccia di tali personalizzazioni.
  • 5. 1 - Introduzione Pag. 4/39In concomitanza con la redazione di tale tesi, lazienda stava procedendoallintroduzione di Maven, strumento dichiarativo per la gestione dei progetti Java intermini di compilazione del codice, distribuzione, documentazione e collaborazione delteam di sviluppo. Luso di questo supporto è dunque diventato un vincolo di progetto.2 - SOMMARIOLa seguente trattazione illustrerà lanalisi effettuata per la comprensione della tematicache si intende affrontare con successiva elaborazione dei dati risultanti. • Raccolta delle informazioni sulla situazione corrente della azienda per conto della quale si sta operando; • Identificazione di Maven come principale punto in comune tra i diversi prodotti realizzati dalla azienda, avente le possibilità di gestire in modo opportuno i profili; • Studio di Maven e delle modalità con cui questo effettua il filtraggio delle risorse statiche e di come tale operazione venga influenzata dalla definizione di un profilo; • Interazione con sistemi di subversion; • Studio dei concetti e delle possibilità offerte dai sistemi di Continuous Integration; • Analisi del prodotto Apache Continuum e del suo utilizzo da remoto; • Studio della possibilità di realizzazione di plugin personalizzati per Maven; • Studio delle tecnologie necessarie alla realizzazione della interfaccia dellapplicativo; • Studio del diagramma ER (Entità/Relazione) della base dati;In un secondo tempo, verranno descritti i modi in cui tali considerazioni entrano ingioco per lo sviluppo concreto dellapplicativo nella sua parte di business logic. • Modellazione dellapplicativo ed integrazione con sistemi esterni; • Definizione dei diversi moduli che compongono lo strato di Service; • Progettazione logica della base dati e implementazione di Hibernate; • Identificazione dei flussi applicativi, con particolare attenzione ai ruoli previsti per gli utenti; • Modifiche richieste alle applicazioni che verranno interessate dal sistema di rilascio.Una breve sezione riguarderà limplementazione dellindispensabile interfaccia perlinterazione con lutente. • Sviluppo di una applicazione web per linterazione tra utente e sistema; • Illustrazione delle modalità di installazione e configurazione della applicazione;
  • 6. 2 - Sommario Pag. 5/39 • Delucidazione sui casi duso più comuni per la applicazione.Infine trovano posto le conclusioni tecniche-oggettive e personali raggiunte al terminedello sviluppo. Per le note informative che esulano da questa trattazione si èpredisposta una appendice di approfondimento cui si fa svariate volte riferimento.3 - ANALISIPrima di procedere con la progettazione e la successiva realizzazione del progetto,occorre stabilire a priori quelli che sono i requisiti che si vuole vengano rispettati nellosviluppo. Per poter tracciare un ben definito elenco di requisiti è indispensabileeffettuare una analisi approfondita della problematica che si vuole affrontare, dellostato dellarte, delle tecnologie che sono disponibili al momento e delle possibilisoluzioni che vengono offerte da queste.Il punto centrale da cui inizia questa analisi è il tool di sviluppo Maven. Tale strumentoè presente in tutti i progetti che si vuole gestire con il futuro applicativo e permette dicontrollare un gran numero di funzionalità.In questa analisi si cercherà dunque di analizzare Maven, mettendo in risalto lemodalità con cui questo tool riesce a interagire con gestione delle versioni, uso deiprofili e modalità di rilascio.3.1 - MavenMaven, può essere considerato principalmente come uno strumento per la gestione diprogetti software Java, in termini di compilazione del codice, testing, distribuzione,documentazione e collaborazione del team di sviluppo. Si tratta dunque di un tentativodi applicare pattern ben collaudati allinfrastruttura del build dei progetti cercando dicoprirne tutti gli ambiti.Si tratta di promuovere la comprensione e la produttività del team coinvolto nellosviluppo, fornendo un percorso chiaro allutilizzo di best practice. Per questo motivoMaven è definito, sinteticamente, tool per la gestione e comprensione dei progetti.Esso è quindi contemporaneamente un insieme di standard, una struttura di repositorye unapplicazione che servono alla gestione e alla descrizione di progetti software. Essodefinisce un ciclo di vita standard per il building, il test e il deployment di file didistribuzione Java.Le caratteristiche di Maven fanno sì che diverse persone, anche inizialmente estraneeal progetto, possano lavorare insieme produttivamente senza dover trascorrere molto
  • 7. 3 - Analisi Pag. 6/39tempo per comprendere la struttura del progetto, il suo funzionamento, il processo dibuild, etc. Tutti coloro che si sono trovati, almeno una volta nella loro vita, a doverintervenire in progetti di grandi dimensioni in corso dopera, sicuramente conoscono lafrustrazione causata da dover capire rapidamente linterazione delle varie parti delprogetto, lordine e le dipendenze del processo di build, etc.Le aree prese in considerazione da Maven sono: build, documentazione, reportistica,gestione delle dipendenze, SCMs (Software Configuration Management), rilascio edistribuzioni di nuove versioni. In effetti tutti i progetti, indipendentemente dal lorodominio, dalla loro estensione e dalla tecnologia impiegata, presentano una serie dinecessità standard, quali ad esempio: • la conversione dei sorgenti in codici "eseguibili" (build); • la verifica (test); • lassemblaggio; • la documentazione; • eventualmente il "dispiegamento" e la relativa configurazione (deployment).3.1.1 - Struttura dei file Pom.xmlUno dei principali componenti di Maven è il file pom.xml (Project Object Model,modello ad oggetti del progetto). Esso mantiene i meta-dati del progetto memorizzatiutilizzando il formato xml.Il file POM presenta una struttura piuttosto articolata e complessa. Tuttavia la maggiorparte delle funzionalità vengono implementate di base con un comportamento didefault che risulta essere perfettamente compatibile con la maggioranza dei progetti.Inoltre un file POM personalizzato per un dato progetto può essere facilmenteriutilizzato per i successivi, con variazioni minime.La complessità del POM che può inizialmente spaventare chi non è praticodellambiente, offre al tempo stesso un punto di forza per chi volesse alterare ilcomportamento di Maven. Questa elevata versatilità sarà il punto di partenza per losviluppo di questo progetto.Tralasciando la struttura generica del POM, che esula da questa trattazione, neiparagrafi successivi si affrontano con più attenzione, le parti che hanno una relazionecon quanto si discute in questa analisi. Si vedranno dunque le modalità di filtraggiodelle risorse, la definizione di property, la gestione dei profili e dei riferimenti a serverSCM e di rilascio.
  • 8. 3 - Analisi Pag. 7/393.1.2 - SCM, Software Configuation ManagementIl software per la gestione della configurazione, detto in inglese Software ConfiguationManagement o più semplicemente con lacronimo SCM, è il software dedicato allagestione dei file sorgenti e risolvono il problema del Version Control.Per la connessione con i sistemi SCM, Maven utilizza un proprio plug-in: Maven SCM.Questo fornisce uninterfaccia comune per accedere alle diverse implementazioni SCM(CVS, Subversion, IBM ClearCase, etc.).<project>... <scm> <connection>scm:svn:https://scmsever.com/myPrj/trunk/</connection> <developerConnection> scm:svn:https://subversion.scmsever.com/svn/myPrj/trunk/ </developerConnection> <tag>trunk</tag> <url>scm:svn:https://scmsever.com/myPrj/trunk/myPrj</url> </scm>...</project>Gli elementi SCM (listato appena visto) sono: • connection e developerConnection permettono di definire le diverse modalità di connessione al sistema di controllo del versionamento attraverso Maven. In particolare, mentre la connessione utilizzata da Maven (connection) richiede un accesso di sola lettura necessaria per permettere a Maven di localizzare e leggere il codice sorgente, la connessione degli sviluppatori (developerConnection), invece, richiede un accesso in lettura/scrittura. Per la connessione con i sistemi SCM, Maven utilizza un proprio plug-in: Maven SCM. Questo fornisce uninterfaccia comune per accedere alle diverse implementazioni SCM (CVS, Subversion, IBM ClearCase, etc.). Questa interfaccia è basata su una API ispirata al seguente formato URL: scm:[provider]: [provider_specific]. Nel listato riporato sopra è presente una configurazione contenente una connessione protetta (HTTPS) al server Subversion. • tag permette di specificare letichetta (la radice dellSCM) dalla quale è possibile accedere al progetto. • url, permette di specificare lindirizzo URL che permette di navigare il repository3.1.3 - RepositoryMentre le sezioni repository del POM permettono di specificare le posizioni e lemodalità con cui Maven è in grado di effettuare il download dei vari manufattinecessari al POM, questa sezione, allinterno dellelemento distributionManager,
  • 9. 3 - Analisi Pag. 8/39permette di specificare dove e come memorizzare i manufatti del progetto, in fase dideployment, allinterno del repository. Qualora la sezione snaposhotRepository non siadefinita, le impostazioni dellelemento repository sono utilizzati anche per ladistribuzione di tipo snapshot. Ecco il listato che illustra le sezioni snapshotRepository eRepository allinterno della sezione distributionManagement.<project>... <distributionManagement> <repository> <uniqueVersion>false</uniqueVersion> <id>corp1</id> <name>Corporate Repository</name> <url>scp://repo1/maven2</url> <layout>default</layout> </repository> <snapshotRepository> <uniqueVersion>true</uniqueVersion> <id>propSnap</id> <name>Propellors Snapshots</name> <url>sftp://propellers.net/maven</url> <layout>legacy</layout> </snapshotRepository> ... </distributionManagement>...</project>Gli elementi di queste sezioni sono: • id, name: entrambi i campi servono per identificare il repository. Mentre il campo id è un identificatore univoco, il nome serve per rendere il campo leggibile. • uniqueVersion: è un attributo di carattere booleano il cui valore true serve ad incaricare Maven del versionamento dei vari manufatti pubblicati (generazione di un numero di versione univoco da associare ai manufatti memorizzati nel repository). Il valore false invece indica che la versione è definita come parte dellindirizzo. • url: come lecito attendersi rappresenta linformazione principale dellelemento repository. Il formato URL, permette di specificare sia lubicazione sia il protocollo di trasporto da utilizzare per il trasferimento dei manufatti generati dal processo di build. • layout: come visto in precedenza permette di specificare la struttura del repository. In particolare: default indicata la struttura introdotta con Maven 2, mentre legacy rappresenta la struttura precedente.
  • 10. 3 - Analisi Pag. 9/393.1.4 - Property e Filtraggio delle RisorsePer filtraggio delle risorse si intende la sostituzione di variabili sui file di configurazionecostituenti il nostro progetto.Per far si che le risorse vengano filtrate occorre abilitare il filtering nel tag resources. Seil filtraggio delle risorse è attivo, prima di qualsiasi operazione di compilazione, ilframework si preoccupa di controllare tutti i file di risorsa (di default si trovano nellacartella /src/main/resources) e di sostituirne le variabili con alcuni valori preimpostati.Tali valori possono essere definiti come properties del progetto generico oppure, comesi vedrà in seguito, definiti a livello di profilo.<project>... <properties> <jdbc.driverclassname>com.mysql.jdbc.Driver</jdbc.driverclassname> <jdbc.url>jdbc:mysql://localhost:3306/development_db</jdbc.url> <jdbc.username>dev_user</jdbc.username> <jdbc.password>s3cr3tw0rd</jdbc.password> </properties> ... <build> <resources> <resource> <directory>src/main/resources</directory> <filtering>true</filtering> </resource> </resources> </build>Come esempio si consideri un file di properties, facente parte di un dato progetto, incui vengono specificati i parametri di connessione verso la base dati. Tale file deveessere configurato in modo differente in base al contesto di compilazione (macchinalocale dello sviluppatore, server di sviluppo, clienti). Il file che si troverà nei sorgenti delprogetto, sarà dunque formattato come indicato di seguito:driver=${jdbc.driverclassname}url=${jdbc.url}username=${jdbc.username}password=${jdbc.password}Si può vedere che il file non è valorizzato ma, in fase di compilazione, verrannoutilizzate le properties definite nel POM del progetto per sostituire i placeholderdefiniti da ${<chiave>}.
  • 11. 3 - Analisi Pag. 10/393.1.5 - ProfiliUna caratteristica introdotta a partire dalla versione 4.0 dei POM sono i profili. Questesezioni permettono di variare opportune impostazioni in funzione dellambiente dibuild. Ciascun profilo include sia una sezione opzionale dedicata allattivazione (unasorta di trigger per un profilo) sia un insieme di variazioni da apportare al POM qualorail relativo profilo venga attivato. Un esempio classico consiste nel far in modo che unprogetto realizzato per eseguire determinati test faccia riferimento ad un diversodatabase a seconda dellambiente di esecuzione. Un altro esempio consiste nel far sìche il sistema, a seconda della versione del JDK utilizzata, prelevi opportuneimpostazione da diversi repository.<project>... <profiles> <profile> <id>test</id> <activation>...</activation> <build>...</build> <modules>...</modules> <repositories>...</repositories> <pluginRepositories>...</pluginRepositories> <dependencies>...</dependencies> <reporting>...</reporting> <dependencyManagement>...</dependencyManagement> <distributionManagement>...</distributionManagement> </profile> </profiles></project>Gli elementi del profilo permettono di ridefinire elementi già presenti allinterno delPOM, pertanto ne ricopiano la struttura, come si può vedere nel precedente listato.E possibile riunire le possibilità di filtering delle risorse e gestione dei profili ottenendola possibilità di valorizzare differentemente determinate risorse statiche mediante lusodei profili. Il risultato è un listato simile al seguente.<project>... <properties> <jdbc.driverclassname>com.mysql.jdbc.Driver</jdbc.driverclassname> <jdbc.url>jdbc:mysql://localhost:3306/development_db</jdbc.url> <jdbc.username>dev_user</jdbc.username> <jdbc.password>s3cr3tw0rd</jdbc.password> </properties> ... <build> <resources> <resource> <directory>src/main/resources</directory>
  • 12. 3 - Analisi Pag. 11/39 <filtering>true</filtering> </resource> </resources> </build> ... <profiles> <profile> <id>production</id> <properties> <jdbc.driverclassname> oracle.jdbc.driver.OracleDriver </jdbc.driverclassname> <jdbc.url>jdbc:oracle:thin:@proddb01:1521:PROD</jdbc.url> <jdbc.username>prod_user</jdbc.username> <jdbc.password>s00p3rs3cr3t</jdbc.password> </properties> </profile> </profiles></project>3.2 - Gestione delle VersioniSi definisce controllo delle versioni, la gestione di versioni multiple di un insieme diinformazioni. Viene usato prevalentemente nello sviluppo di progetti informatici pergestire la continua evoluzione dei documenti digitali come il codice sorgente delsoftware. Le modifiche a questi file sono identificate incrementando un numero o uncodice associato ad essi, denominato "numero di versione", "etichetta di versione", osemplicemente "versione", e sono etichettate con il nome della persona che haapportato la modifica.Gli strumenti software per il controllo versione sono sempre più riconosciuti esserenecessari per la maggior parte dei progetti di sviluppo software.Nellingegneria del software, il controllo delle versioni è costituito da qualunque praticache tenga traccia e permetta di controllare i cambiamenti al codice sorgente. Glisviluppatori software talvolta usano il controllo versione software anche per i file didocumentazione e di configurazione, oltre che per il codice sorgente. In teoria, ilcontrollo versione può essere applicato a qualunque tipo di registrazione diinformazioni.Riassumendo, lobiettivo fondamentale di tutti i software che si occupano del controllodi versione è permettere a diversi sviluppatori di lavorare contemporaneamente sudiversi file o addirittura sullo stesso file, automatizzando compiti come: • tenere traccia di chi sta modificando che cosa; • unire le modifiche una volta complete; • segnalare eventuali conflitti; • tenere una copia di ogni precedente versione e fare in modo che sia facilmente recuperabile.
  • 13. 3 - Analisi Pag. 12/393.2.1 - SVN, SubversionSubversion (noto anche come SVN, che è il nome del suo client a riga di comando) è unsistema di controllo versione progettato da CollabNet Inc. con lo scopo di essere ilnaturale successore di CVS, oramai considerato superato.Rispetto a CVS, Subversion introduce: • versionamento delle directories: con CVS il controllo di versione era applicato solo ai file, quindi le operazioni di copia e spostamento tra diverse directory non era gestito adeguatamente. Con Subversion viene tenuta traccia anche del contenuto di ogni singola directory e quindi lo spostamento di un file è a tutti gli effetti considerata una modifica, quindi rintracciabile e reversibile. • commits atomici: una serie di modifiche viene applicata solo in blocco – se anche solo una di esse crea errori, non viene applicata nessuna delle modifiche inviate. Questo evita la creazione di versioni incomplete che dovrebbero poi essere corrette a mano. • versionamento dei metadati: è possibile assegnare a file e directory delle proprietà personalizzate – dei veri e propri metadati – e mantenere lo storico anche delle modifiche a queste proprietà. • astrazione dal livello di rete: laccesso dal client al repository (cioè al deposito centralizzato dei files) può avvenire attraverso il protocollo HTTP (sfruttando un apposito modulo di Apache), attraverso un apposito server standalone (SVNServe), o direttamente attraverso il filesystem (ma solo nel caso in cui il repository sia situato sulla stessa macchina). In tutti questi casi, i comandi e le operazioni fondamentali non cambiano, così come non cambia la struttura del repository e delle copie di lavoro locali.3.3 - Continuous IntegrationCon il termine Continuous Integration si intende una pratica di sviluppo software in cuii membri di un team devono integrare il proprio lavoro con la linea di sviluppo
  • 14. 3 - Analisi Pag. 13/39principale. Con elevata frequenza si considera almeno una integrazione al giorno perogni membro del team. Tali integrazioni vengono verificate da una compilazioneautomatica (che comprende anche lesecuzione di test) per rilevare errori diintegrazione il più rapidamente possibile. Molti team trovano che questo approccioporta a ridurre significativamente i problemi di integrazione e permette di svilupparesoftware più rapidamente.I sistemi che eseguono la integrazione continua, come Cruise Control, ApacheContinuum, TeamCity, e così via, sono ormai presenti in ogni progetto che si rispetti. Sitratta di sistemi che, su richiesta, o ad intervalli predefiniti (ogni ora, durante le orenotturne) eseguono il processo di build dellintero progetto.3.3.1 - Apache ContinuumApache Continuum è uno dei principali applicativi open source per lintegrazionecontinua progettato per build java. Una caratteristica che lo distingue da altri strumentisimilari è la gestione della sicurezza basata sui ruoli. Questa funzione fornisce ilcontrollo su quali aspetti della compilazione possono essere visti e gestiti dai diversiutenti. Nel complesso, le caratteristiche principali sono simili a quelle appartenenti adaltri applicativi di build management come Hudson e Cruise Control (gestione deirilasci, notifica e-mail, integrazione con i più diffusi strumenti di compilazione,integrazione con Maven e integrazione con sistemi di SCM come SVN o CVS).Lo strumento di interfaccia utente è web based, e dopo che il server è stato avviato sipuò accedere da browser con un collegamento a http://localhost:8080/continuum.Apache Continuum offre inoltre la possibilità di accedere alle proprie funzionalitàanche da remoto mediante un client XML-RPC. Il client è accessibile mediante uncollegamento a http://localhost:8080/continuum/xmlrpc.
  • 15. 3 - Analisi Pag. 14/393.4 - FTP, Modalità di RilascioIl File Transfer Protocol (protocollo di trasferimento file o FTP), è un Protocollo per latrasmissione di dati tra host basato su TCP. Gli obiettivi principali di FTP descritti nellasua RFC ufficiale sono: • Promuovere la condivisione di file (programmi o dati); • Incoraggiare luso indiretto o implicito di computer remoti; • Risolvere in maniera trasparente incompatibilità tra differenti sistemi di stoccaggio file tra host; • Trasferire dati in maniera affidabile ed efficiente.E stato necessario interessarsi al protocollo FTP perché questo metodo di distribuzioneviene utilizzato per effettuare i rilasci in Insiel Mercato così come in moltissime altreaziende ed è una delle principali modalità con cui vengono effettuati i trasferimenti difile di grosse dimensioni.Per permettere a Maven di interagire con un repository FTP, è necessario utilizzare unaparticolare estensione del plugin wagon (utilizzato per prelevare e memorizzare file inserver remoti).<project> ... <build> ... <extensions> <extension> <groupId>org.apache.Maven.wagon</groupId>
  • 16. 3 - Analisi Pag. 15/39 <artifactId>wagon-ftp</artifactId> <version>1.0-alpha-3</version> </extension> </extensions> ... </build> ...</project>3.5 - Stesura dei RequisitiNei paragrafi precedenti, si sono esaminate le tecnologie comuni alle applicazioniattualmente sviluppate dalla azienda Insiel Mercato, e su queste si sono esaminate lecaratteristiche che sembrano poter offrire la soluzione al problema della gestione diprofili e versioni.Il risultato dellanalisi si riassume nelle seguenti note: • Il tool Maven offre la possibilità di gestire dei profili in modo tale che, in fase di compilazione del progetto, gli attributi che vengono definiti nel file POM dei progetti, siano sovrascrivibili o comunque modificabili. • Un particolare punto di interesse nella nota precedente è costituito dalle properties, associazioni tra chiavi e valori configurabili da profilo, che possono essere utilizzate come placeholder allinterno delle risorse statiche dei progetti; • I profili maven, così come le properties, possono trovarsi anche esternamente al POM, ed essere iniettati durante la fase di compilazione. • Ad ogni versione di un progetto Maven, corrisponde un tag su SVN. Considerando che un tag non rappresenta una linea di sviluppo ma un punto (è dunque non è modificabile), non si può pensare di modificare i sorgenti del progetto per poter integrare il profilo allinterno del pom del progetto stesso. • Sulla base della nota precedente, si comprende come sia necessario che i profili vengano definiti allinterno di un sistema che sia indipendente dal gestore del versionamento. Tale sistema dovrà essere in grado, non solo di memorizzare i profili, ma anche di crearli e di poterli associare ai clienti. • Si riscontra che sia possibile utilizzare un sistema di Continuous Integration per eseguire delle operazioni Maven, che questi abbiano delle interfacce remote, e che Maven consenta di effettuare il deploy di un compilato su di un server FTP.Le note sopra esposte definiscono non solo il risultato della analisi ma anche ildocumento dei requisiti che lapplicativo che si vuole realizzare dovrà essere in grado disoddisfare. In particolare, sulla base di quanto appena illustrato si vuole realizzare unaapplicazione che sia in grado di: • creare dei profili di compilazione per progetti Maven in base alle configurazioni dei clienti; • memorizzare i suddetti profili, e le relazioni con progetti e clienti, in un archivio locale; • utilizzando i profili creati, far eseguire ad un motore di Continuous Integration il
  • 17. 3 - Analisi Pag. 16/39 rilascio dellapplicazione per il dato cliente su di un server FTP.Dalla rielaborazione delle note e delle considerazioni appena esposte, si possonoenunciare i seguenti requisiti di progetto. • Lapplicazione dovrà essere in grado di distinguere la figura dello sviluppatore da quella delladdetto alla messa in produzione e per ciascuno di essi fornire le funzionalità strettamente necessarie allesercizio delle proprie funzioni. In tal modo si riusciranno ad isolare le responsabilità e meglio definire gli standard di esecuzione. • Deve essere possibile, allinterno della applicazione, gestire le connessioni verso i build manager o continuous integration system, verificandone la corretta raggiungibilità e permettendo limportazione di progetti da essi. • Devono essere registrabili e modificabili le definizioni dei clienti. • Deve essere possibile importare progetti dal sistema di integrazione continua e registrarli allinterno dellapplicativo oppure, viceversa, da questo, dopo aver inserito i parametri fondamentali, effettuare un export verso in sistema esterno. • Lapplicativo deve possedere, per ogni progetto, i riferimenti al posizionamento su di un sistema SCM. • Dai riferimenti SCM di ogni progetto deve essere possibile effettuare il checkout dei sorgenti e da questi ricavare un template di definizione dei profili, caratteristico del progetto che si sta profilando. • Sulla base dei template dei profili ed in associazione con progetto e cliente, deve essere possibile per lutente, inserire i parametri che caratterizzano il profilo e salvare questultimo nella base dati. • Lapplicazione deve poter far eseguire, ad un sistema di Continuous Integration remoto, un comando maven di compilazione di un progetto, in base al profilo voluto. • Il risultato del comando di build indicato precedentemente deve avere come esito positivo, il deploy del compilato del progetto su di un server FTP. Tale compilato deve contenere la configurazione definita nel profilo. • In seguito al deploy eseguito con successo, deve essere registrata lesecuzione del rilascio per il dato cliente. • Con una ulteriore interrogazione del sistema SCM, si preleva un secondo template che specifica le informazioni importanti che occorre registrare per il dato progetto. • Sulla base del template sopra esposto, deve essere possibile registrare le informazioni ottenute dal cliente sullambiente specifico di installazione. • Lapplicativo deve permettere ricerche esaustive sulla base di progetti, versioni e clienti.
  • 18. 3 - Analisi Pag. 17/393.6 - Realizzazione modello Concettuale E-REssendo necessario lutilizzo di una base dati per immagazzinare le informazionirelative a progetti, clienti, profili e rilasci, si rende indispensabile effettuare unacorretta progettazione della stessa. Un errore durante questa fase si ripercuoterebbesullintero progetto, mentre una base di dati ben progettata risulterebbe invece piùefficiente e semplificherebbe lo sviluppo delle applicazione.Il procedimento per la progettazione di una base di dati segue i seguenti passi: • Stesura dei requisiti del sistema informativo in linguaggio naturale; • Glossario ed identificazione delle entità; • Realizzazione del Modello ER.Nel capitolo relativo alla realizzazione, vengono effettuati ulteriori elaborazioni delloschema E-R fino a giungere allo schema logico e fisico.3.6.1 - Stesura dei Requisiti del Sistema InformativoSi produce una prima versione dei requisiti in linguaggio naturale, raggruppando frasidescrittive relative a categorie diverse di dati.Frasi riguardanti i progetti: • Un Continuous Integration System viene utilizzato per il testing dei progetti. • I progetti vengono compilati da un Continuous Integration System. • I progetti sono versionati su un gestore di versioni SCM. • Gli sviluppatori depositano i progetti su SCM e Continuous Integration System.Frasi relative ai Profili: • Il profilo è la definizione della personalizzazione di un progetto. • Ogni cliente può volere uno o più profili dello stesso progetto. • Ogni compilazione viene eseguita con un certo profilo. • Il template del profilo viene preso dai sorgenti versionati del progetto. • I deployer sono incaricati della realizzazione dei profili.Frasi relative al build: • Il build viene fatto dal Continuous Integration System. • Tutti i progetti sono gestiti dal Continuous Integration System. • Il Continuous Integration System riceve i profili dallapplicazione rudra. • Un build riuscito può essere rilasciato al cliente. • I deployer installano i progetti dai clienti.Frasi relative al cliente: • Il cliente richiede il rilascio di un progetto;
  • 19. 3 - Analisi Pag. 18/39 • Il progetto rilasciato viene configurato per il cliente. • Al cliente viene installato il prodotto richiesto.Frasi relative ai rilasci: • Se un build da esito positivo può essere installato. • Ad ogni installazione corrisponde un buildn di un progetto. • Le installazioni vengono fatte dai deployer.Frasi relative agli sviluppatori: • Ogni progetto ha uno o più sviluppatori. • Gli sviluppatori utilizzano il server SCM per versionare i progetti. • Gli sviluppatori monitorano i progetti con i CIS.Frasi relative ai deployer: • I deployer creano i profili per i progetti. • Una installazione corrisponde allintervento di un deployer su un progetto.3.6.2 - Glossario dei TerminiAnalizzando le frasi espresse in linguaggio naturale, raggruppate per categoria di dati, sipossono identificare dei termini ricorrenti e tra questi delle relazioni. Termine Descrizione CollegamentiProgetto Prodotto venduto dalla azienda Sviluppatore, Profilo, CIS, SCM, BuildProfilo Personalizzazione del progetto per il cliente Deployer, Progetto, Cliente, BuildCliente Colui a cui si vende il progetto personalizzato Installazione, ProfiloSviluppatore Sviluppa i Progetti ProgettoDeployer Crea i profili e installa i progetti compilati Profilo, InstallazioneBuild Rappresenta il processo con cui si crea il Progetto, Profilo, compilato e i suoi risultati InstallazioneCIS Continuous Integration Systema ProgettoInstallazione Installazione del progetto compilato presso il Deployer, Cliente, Build clienteSCM Sistema di versionamento Progetto
  • 20. 3 - Analisi Pag. 19/393.6.3 - Schema concettuale E-RTraducendo il glossario in uno schema concettuale basato su Entità e Relazioni siottiene lo schema indicato di seguito. Questo è lo schema scheletro dal quale si partecon lanalisi che condurrà alla realizzazione dello schema E-R vero e proprio.Dallo schema precedente si può immediatamente evincere che le entità Sviluppatore eDeployer possono essere considerate delle specializzazioni della figura del Dipendente.Inoltre dalla comprensione delle frasi in linguaggio naturale e dalla analisi del contestocostituito dal sistema informativo che si vuole realizzare, è possibile definire sia gliattributi che le singole entità (e nel caso, anche le relazioni) debbano avere, sia lacardinalità con cui le entità entrano in relazione tra loro. Questa analisi è difondamentale importanza per lo sviluppo dello schema logico e fisico che si andrà asvolgere nel capitolo relativo alla realizzazione della base dati.
  • 21. 3 - Analisi Pag. 20/39Di seguito viene quindi esposto lo schema Entità-Relazione su cui si è strutturata labase dati del progetto Rudra.
  • 22. 4 - Realizzazione Pag. 21/394 - REALIZZAZIONEIn considerazione del fatto che lapplicativo in realizzazione necessiterà di essereutilizzato da diverse figure professionali (sviluppatori, addetti alla messa in produzione,project manager, ecc..) e in diversi contesti (tutti però localizzabili allinternodellazienda), si è deciso di realizzare una applicazione web. Tale scelta permette unamaggiore semplicità duso ed è ottimizzata per luso intranet. Essa viene inoltregiustificata dagli stretti legami con altri applicativi ad uso intranet come sistemi dicontinuous integration, repository per il controllo delle versioni, repository maveninterni, server ftp per i rilasci, server ldap per le autenticazioni e sistemi di issuetracking.4.1 - Interazione tra Sistemi e Ruolo degli AttoriSi vuole realizzare una applicazione capace di gestire un elenco di progetti posti in unsistema di Continuous Integration. Di tali progetti deve essere possibile ricavare iriferimenti al server di versionamento SCM da cui a sua volta si estraggono leinformazioni necessarie alla compilazione di un profilo. Successivamente, in base alleinformazioni appena fornite dal sistema SCM, si procede alla creazione di un nuovoprofilo per il dato cliente associandolo al progetto stesso allinterno del databasedellapplicazione Rudra. Tale profilo viene poi utilizzato per la generazione del progettopersonalizzato da parte del sistema di continuous integration che provvederà al deploydel compilato finale su di un server FTP per la distribuzione. Inoltre si vuole registrareloperazione di rilascio, arricchendola di informazioni specifiche del progetto e delcliente, allinterno del database.In tutto questo processo, gli utenti che compiono le diverse attività possono esserecategorizzati in due attori principali, ovvero: • Sviluppatore: Colui che sviluppa e mantiene i progetti. Stabilisce i rilasci delle versioni e in concomitanza con questi eventi si occupa di realizza i tag sul sistema di versionamento e porre lapplicazione appena versionata su un sistema di continuous integration. • Deployer: Colui che si occupa della messa in produzione degli applicativi. Non ha competenze riguardo al funzionamento dei progetti o delle tecnologie con cui questi sono stati realizzati. Si occupa di ricavare dai clienti le informazioni sul contesto in cui le applicazioni si troveranno ad operare, a configurarle adeguatamente realizzando un profilo, e a porre in produzione il compilato che potrà ricavare dal server FTP.
  • 23. 4 - Realizzazione Pag. 22/39Come si può facilmente vedere dallo schema precedente, grazie allintroduzione diquesto meccanismo di rilascio, non esistono punti in comune tra la figura dellosviluppatore e quella del deployer.4.2 - Diagrammi di sequenzaI due attori principali che interagiranno con il progetto Rudra saranno dunque ideployer e gli sviluppatori. Per ciascuno di essi sono stati realizzati i seguenti diagrammidi sequenza.Per la figura dello sviluppatore si hanno le seguenti operazioni: • registrazione di un sistema di Continuous Integration; • richiesta del progetti importabili dal CIS; • importazione di un progetto.
  • 24. 4 - Realizzazione Pag. 23/39Per la figura del deployer si hanno le seguenti operazioni: • richiesta form per creazione del profilo; • salvataggio profilo; • richiesta rilascio; • salvataggio dettaglio rilascio.
  • 25. 4 - Realizzazione Pag. 24/394.3 - Progettazione Logica e Fisica della base datiNon esistono DBMS in grado di operare direttamente sui concetti di schemi E-R. Risultaquindi necessario tradurli in altri schemi di dati chiamati logico relazionali. Questatraduzione può essere eseguita in modo semi-automatico seguendo una determinataserie di operazioni da eseguire.Il progetto logico presenta in generale una soluzione standard determinabile in modosemplice e diretto. A seconda dei casi, sono però disponibili anche soluzionialternative, che possono rivelarsi più o meno convenienti. In queste occasioni si devetenere conto dell’efficienza dello schema logico risultante e delle operazioni daeffettuare (derivanti da flussi e processi).
  • 26. 4 - Realizzazione Pag. 25/39Per ottenere lo schema logico della base dati è necessario dunque procedere atrasformazioni e traduzioni dello schema E-R seguendo le fasi indicate di seguito: • Eliminazione delle generalizzazioni; • Identificazione delle chiavi primarie; • Traduzione di entità e associazioni in schemi di relazioni.Durante la realizzazione di queste fasi, si devono compiere le seguenti valutazioni, chepermettono una ottimizzazione dello schema logico risultante dalla interpretazionedello schema E-R: • Previsioni sulla natura e la frequenza delle operazioni; • Valutazioni quantitative sui volumi di dati (entità, associazioni, percentuali di copertura di gerarchie, percentuali di valori nulli).In tutti quei casi in cui sono possibili scelte alternative, occorre prestare la dovutaattenzione alle seguenti considerazioni, molto spesso intuitive: • Le proprietà logiche sono comunque primarie rispetto ai motivi di efficienza; • Tenere sulla stessa entità informazioni che verranno di frequente consultate insieme; • Tenere su entità separate informazioni che verranno consultate separatamente; • Limitare l’incidenza di valori nulli per attributi opzionali.Lapplicazione delle regole e delle considerazioni precedenti, porta alla stesura delleseguenti trasformazioni da applicare allo schema E-R: • la relazione esistente tra CIS e Progetto ha cardinalità 1,1 sulla seconda entità, e su questa viene accorpata; • vista la cardinalità 1,1 della relazione tra SCM e Progetto, la prima entità viene completamente accorpata nella seconda (questa soluzione facilita anche la gestione dei progetti e della interfaccia.); • gli argomenti del Profilo, essendo molteplici, vengono estratti dallentità Profilo e posizionati in una tabella a parte di cui il profilo è chiave esterna (tabella Profile_Property); • le dipendenze aggiuntive che possono essere richieste da un Profilo possono essere molteplici, quindi vengono estratte dallentità Profilo e posizionate in una tabella a parte di cui lidentificativo del profilo è chiave esterna (tabella Profile_Dependency); • gli argomenti della Installazione, essendo molteplici, vengono estratti dallentità Installazione e posizionati in una tabella a parte di cui lidentificativo del profilo è chiave esterna (tabella Release_Property); • in tutti i casi in cui la cardinalità con cui una entità entra in relazione è 1,1, la relazione viene accorpata alla entità stessa; • lidentificazione delle chiavi primarie segue le indicazioni già fornite nello schema E-R realizzato.Allinterno degli applicativi sviluppati da Insiel Mercato, la gestione di autenticazioni edautorizzazioni degli utenti, viene svolta da un kernel di funzionalità, condiviso tra tuttele applicazioni, che utilizza una base dati condivisa. Trattandosi dunque di una
  • 27. 4 - Realizzazione Pag. 26/39soluzione già esistente e proprietaria, essa non viene trattata in questo studio.Il risultato di tutte queste considerazioni, applicate sullo schema entità-Relazione che èstato elaborato nella fase di Progettazione di questa tesi, ha prodotto lo schema logicoche ha come prodotto il seguente schema fisico.4.4 - ImplementazioneLapplicazione web che si intende sviluppare presenterà tre diversi strati software.Il primo, ovvero lo stato dei controller sarà recettivo delle richieste http inviate dalbrowser dellutente. Si occuperà dunque di verificare autenticazioni ed autorizzazioni edi fornire successivamente una risposta in base a ciò che verrà restituito dai servizi cheverranno di volta in volta richiamati.Il secondo strato è uno strato di servizi che rispettano il pattern meglio noto comeFacade. Tali servizi permettono di nascondere la complessità delle operazioni aicontroller o agli altri servizi chiamanti. In tal modo la complessità di certe operazionicomplesse viene ad essere concentrato in un punto, ed essendo i servizi realizzati nelmodo più generico e astratto possibile, il codice sviluppato è estremamente riusabile.
  • 28. 4 - Realizzazione Pag. 27/39Il terzo strato è quello dedicato alla persistenza. Tale livello non è sempre presente.Grazie allutilizzo di un motore di persistenza come Hibernate, non sarebbe necessariorealizzare uno strato che si occupi delle operazioni di scrittura e lettura sulla base dati,ma in quei casi in cui le operazioni di lettura e scrittura possono essere più complesse emagari ricorrenti allinterno dei diversi servizi, allora si preferisce estrarre il codicerelativo e posizionarlo in una classe di appoggio.Linterazione con i servizi di versionamento SCM e di Continuous Integration CIS sonogestiti da appositi servizi.4.5 - Tecnologie e Framework utilizzatiPer la realizzazione dellapplicazione web si è scelto di utilizzare il framework Spring.Spring è un framework open source per lo sviluppo di applicazioni che rappresenta almomento il tentativo più riuscito per semplificare lo sviluppo di applicazioni"enterprise" di una certa complessità nellambito Java. Spring interpreta nel modomigliore i nuovi modelli di programmazione definiti dallIoC e dallAOP e permette diraggiungere un livello di disaccoppiamento degli strati applicativi impedito invece dallanatura "invasiva" della tecnologia EJB.Si prestano molto bene alla realizzazione del progetto anche alcuni sotto-framework dispring, quali Spring MVC (per la miglior gestione del pattern Model-View-Control) eSpring Security (per la gestione di autenticazioni e autorizzazioni).Le view che vengono restituite agli utenti sono generate grazie alle JSP la cuicomposizione viene realizzata dal framework Tiles 2. Tiles permette agli sviluppatori di
  • 29. 4 - Realizzazione Pag. 28/39definire frammenti di pagine jsp che possono essere assemblate in una paginacompleta in fase di esecuzione. Questi frammenti possono essere utilizzati comesemplice include, al fine di ridurre la duplicazione degli elementi di pagina comuni oincorporato in altri frammenti al fine di sviluppare una serie di modelli riutilizzabili.4.5.5 - Hibernate e Gestione della PersistenzaHibernate (talvolta abbreviato in H8) è una piattaforma middleware open source per losviluppo di applicazioni Java che fornisce un servizio di Object-relational mapping(ORM), ovvero che gestisce la rappresentazione e il mantenimento su databaserelazionale di un sistema di oggetti Java.Lobiettivo di Hibernate è quello di esonerare lo sviluppatore dallintero lavoro relativoalla persistenza dei dati. Hibernate si adatta al processo di sviluppo del programmatore,sia se si parte da zero sia se da un database già esistente. Hibernate genera le chiamateSQL e solleva lo sviluppatore dal lavoro di recupero manuale dei dati e dalla loroconversione, mantenendo lapplicazione portabile in tutti i database SQL. Hibernatefornisce una persistenza trasparente per "Plain Old Java Object".In questa tesi sono state utilizzate le annotazioni JAXB per personalizzare la mappaturatra oggetti java, i cosiddetti POJO, e tabelle e altri costrutti SQL. Di seguito si riporta unesempio di classe di modello mappata con hibernate....@SuppressWarnings("serial")@Entity@Table(name = "project", uniqueConstraints = {@UniqueConstraint(columnNames={"group_id","artifact_id","version"})})public class Project implements Serializable { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) protected Long id; @Column(name = "group_id", nullable = false) protected String groupId; @Column(name = "artifact_id", nullable = false) protected String artifactId; @Column(name = "version", nullable = false) protected String version; @Column(name = "scm_url", nullable = false) protected String scmUrl; @Column(name = "scm_username", nullable = false) protected String scmUsername; @Column(name = "scm_password", nullable = false)
  • 30. 4 - Realizzazione Pag. 29/39 protected String scmPassword; @ManyToOne(cascade = CascadeType.ALL) protected ContinuousIntegrationSystem cis; @Column(name = "cis_project_id") protected Long cisProjectId; @Column(name = "invalidate", nullable = false) protected Boolean invalidate = false;...// getter e setter per gli attributi della classeLannotazione @Entity permette ad Hibernate di riconoscere la classe comereferenziata su di una tabella, lannotazione @Id ne riconosce la chiave primaria elannotazione @ManyToOne permette di definire una chiave esterna con unaltraentità.4.6 - Definizione dei ServiziCome già detto,4.6.1 - ScmServicePer interagire con il sistema di versionamento è necessario lutilizzo di librerie esterne.Dopo una ricerca a riguardo si è scelto, per la particolare implementazione del servizioverso un sistema SVN, di utilizzare il progetto SVNKit. Tale libreria, tra laltro, è ancheutilizzata dallo stesso IDE Eclipse utilizzato per la realizzazione del progetto.Per importare la libreria nel progetto occorre definire nel POM la seguente dipendenza...<dependency> <groupId>org.tmatesoft.svnkit</groupId> <artifactId>svnkit</artifactId> <version>1.3.5</version></dependency>...Per poter effettuare delle operazioni sul server SVN occorre conoscerne i riferimenti. Siriporta un esempio della connessione vai codice effettuata nel servizio....DAVRepositoryFactory.setup();SVNUpdateClient client = new SVNUpdateClient( SVNWCUtil.createDefaultAuthenticationManager(
  • 31. 4 - Realizzazione Pag. 30/39 project.getScmUsername(), project.getScmPassword()), SVNWCUtil.createDefaultOptions(true));client.doCheckout(SVNURL.parseURIDecoded(scmUrl), outputFolder, SVNRevision.UNDEFINED, SVNRevision.HEAD, SVNDepth.INFINITY, true);...4.6.2 - CisServicePer connettersi remotamente ad una istanza di Continuum, occorre utilizzare il jarcontinuum-xmlrpc-client. Tale libreria può essere aggiunta come dipendenza al file pomdel progetto.... <dependency> <groupId>org.apache.continuum</groupId> <artifactId>continuum-xmlrpc-client</artifactId> <version>1.4.0</version> </dependency>...Per connettersi a Continuum con il client xml-rpc indicato è necessario utilizzare laclasse ContinuumXmlRpcClient, ilcui costruttore ha 3 parametri: • url, lurl a cui risponde il listener xmlrpc (http://host:port/continuum/xmlrpc); • user, lusername dellutente di Continuum; • password, la password dellutente.Per ottenere listanza del client nel codice java:...URL url = new URL( "http://localhost:8080/continuum/xmlrpc" );ContinuumXmlRpcClient client = new ContinuumXmlRpcClient( url, username, password );...Per ottenere la lista dei progetti:...List<ProjectSummary> ps = client.getProjects( projectGroupId );...Per richiamare il build di un progetto:...client.buildProject( project.getId(), buildDefinitionId );...
  • 32. 4 - Realizzazione Pag. 31/394.7 - InterfacciaLinterfaccia dellapplicativo è stata realizzata per permettere una facile interazione conlutente. I contesti in cui si possono eseguire le operazioni sono rappresentati come deiTab nella parte alta dellinterfaccia. Per ognuno di essi è presente un sotto menu chepermette lesecuzione delle varie operazioni. Un barra di navigazione permette ditenere traccia della posizione in cui ci si trova durante la navigazione della applicazione.4.7.1 - Installazione e ConfigurazioneLinstallazione dellapplicativo Rudra è piuttosto semplice. La sola cosa da fare è creareuno schema di database vuoto (in questa tesi si è utilizzata una base dati postgres, macon pochissimi accorgimenti si può utilizzareq ualsiasi altro RDMS di uso comune) eindicarne i riferimenti nel file:rudraWEB-INFapplication-configpersistence-config.xml...<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close"> <property name="driverClassName" value="org.postgresql.Driver" /> <property name="url" value="jdbc:postgresql:rudra" /> <property name="username" value="rudra" /> <property name="password" value="rudra" /></bean>...Una volta mandato in esecuzione lapplication server (in questo caso si è utilizzatoTomcat), hibernate si occuperà di realizzare lo schema della base dati sulla base deglioggetti di modello che sonos tati mappati con le annotazioni JAXB.Per poter configurare lapplicazione in modo corretto, lamministratore o uno deglisviluppatori deve accedere alla applicazione effettuando il login.
  • 33. 4 - Realizzazione Pag. 32/39La prima operazione che deve essere eseguita è lassociazione di un sistema diContinuous Integration. In questa schermata devono essere inseriti i parametri relativialla connessione remota.Una volta associato il CIS, occorre importare i progetti da voler rilasciare. Questivengono selezionati da una lista di tutti i progetti attualmente disponibili sul sistemaCIS precedente mente associato.La pressione del tasto importa, permette di registrare i progetti sulla base dati e digestirli dal progetto Rudra.
  • 34. 4 - Realizzazione Pag. 33/394.7.2 - Esempio dusoLe seguenti schermate indicano le operazioni che normalmente vengono eseguite dalgruppo degli addetti ai rilasci. Una volta eseguito il login, essi verificano lesistenza delcliente oppure, in caso contrario, lo inseriscono.Si procede dunque alla generazione del profilo richiesto indicando esplicitamente ilprogetto che si vuole rilasciare e il relativo cliente.Una volta che viene eseguita la registrazione del profilo, si procede con il checkout delprogetto dal repository SCM su cui esse viene versionato, e se ne estrae il template didefinizione dei placeholder.
  • 35. 4 - Realizzazione Pag. 34/39Il template ottenuto contiene le indicazioni relative ai nomi delle chiavi dei placeholdere la descrizione di che cosa indicano. Tali template e tali note descrittive note sonostate preventivamente indicati dagli sviluppatori prima di effettuare il tag del progetto.Il deployer si occupa dunque di compilare il form per limmissione dei dati del profiloaiutato in questa operazione dalla descrizione. Successivamente vedrà lelenco deiprofili, indicato di seguito, dal quale potrà richiedere la compilazioen remota e il deploysul server di rilascio FTP.Nellarco di pochi secondi o pochi minuti a seconda della dimensione dle progetto edelle performance della rete intranet, sarà possibile interrogare il server FTP sul qualesi troverà il file compilato richiesto.
  • 36. 4 - Realizzazione Pag. 35/394.8 - Configurazione delle Applicazioni da GestireAffinché un progetto gestito tramite Maven possa usufruire del sistema descritto inquesta tesi, esso deve necessariamente: • avere i propri file sorgenti versionati su di un sistema SCM raggiungibile; • i file sorgenti sopra indicati debbono essere sottoposti ad un sistema di Continuous Integration raggiungibile; • avere nella root dei sorgenti, la definizione dei template che permettono la definizione dei Profili e dei Rilasci;Per poter utilizzare la generazione dei profili in Rudra, è necessario che i progetti dagestire abbiano al loro interno un file di definizione dei placeholder da sostituire in fasedi compilazione. Il file viene posto nella root del progetto a pari livello del pom.xml e sichiama:/rudra-profile-template.propertiesIn questo file sono presenti le coppie di chiave/descrizione, come illustratonellesempio:
  • 37. 4 - Realizzazione Pag. 36/39rudra.db.driver=Se si utilizza un database Oracle, utilizzare il driver Oracle Thin JDBC: "oracle.jdbc.driver.OracleDriver". rudra.db.url=Contiene il nome della sorgente di dati nella forma "jdbc:oracle:thin:@<server_name>:<db_port>:<SID>". Il valore server_name è lindirizzo IP o il nome assegnato dalladmin del sistema al server di database. Il valore SID è lidentificatore del sistema di database. Se sullo stesso sistema sono in esecuzione più database Oracle, usare SID per distinguerli. Ad esempio, se il server si chiama Aristotle, la porta del database è la 1343 e su tale server è stato definito un SID di database di nome patients, immettere il seguente valore: "jdbc:oracle:thin:@Aristotle:1343:patients".rudra.db.username=Nome utente per laccesso alla base dati.rudra.db.password=Password dellutente.Nel file pom devono essere presenti le seguenti sezioni. Tali modifiche vengonoeseguite per poter utilizzare le modalità di deploy effettuate tramite il plugin wagon.Definizione del repository per il deploy:<distributionManagement> <repository> <id>ftp-repository</id> <url>ftp://192.168.1.104/home/ftp-user</url> </repository></distributionManagement>Estensione del plugin Wagon:<extensions> <extension> <groupId>org.apache.maven.wagon</groupId> <artifactId>wagon-ftp</artifactId> <version>1.0-beta-6</version> </extension></extensions>NB: Nello sviluppo di questo progetto si è deciso di utilizzare il plugin wagon di Mavenper il deploy degli artefatti compilati sul server FTP, mediante lestensione del plugin.Tale soluzione è efficace e stabile, in quanto wagon è un plugin intrinseco di Maven.Si consideri però che lutilizzo un plugin così specifico, può causare dei fastidi nelmomento in cui si volessero effettuare delle modifiche alle modalità di deploy. Bastipensi al caso in cui si volesse far deployare il file compilato in una determinata cartellacon allegati altri documenti, come guida allinstallazione, o file connessi che comunquenon riguardano il build in se stesso.In tal caso la soluzione che si consiglia di adottare è di realizzare un pluginpersonalizzato di Maven da far in seguito inglobare in tutti i POM dei progetti gestititramite Rudra.
  • 38. 4 - Realizzazione Pag. 37/395 - CONCLUSIONILobiettivo di questo lavoro di tesi era la realizzazione di una sistema software chepermettesse di tenere traccia dei rilasci degli applicativi java web prodotti da unaazienda di sviluppo software, con particolare attenzione alla gestione dei profili. Taleobiettivo si può dire pienamente raggiunto. Inoltre, grazie al fatto che i progetti dellaazienda erano gestiti con il tool Maven, si è potuto, non solo tenere traccia dei profilidei vari clienti, ma anche crearli direttamente nellapplicativo, grazie a dei templatepredefiniti. La successiva interazione con un sistema di Continuous Integration ha poipermesso che la generazione dei compilati da rilasciare avvenisse in modoassolutamente automatico e trasparente per il personale incaricato della messa inproduzione.Il progetto realizzato vanta una quasi immediata integrazione allinterno di un sistemapreesistente, se dotato di gestione delle versioni (Subversion) e testing mediantemeccanismi di continuous integration (Apache Continuum). Ciò significa che è possibileadottarlo senza incorrere nella necessità di dover riscrivere parti di applicazionipreesistenti o di dover modificare ambienti di lavoro. Il suo sviluppo ha richiestonotevole studio delle tecnologie disponibili e una buona conoscenza degli ambienti edelle meccaniche aziendali. La realizzazione vera e propria del progetto ha comportatoalcuni mesi. Grazie al fatto che il codice è stato strutturato a moduli tra loroindipendenti, e che questi sono stati resi il più generici possibile, una buona parte delcodice sviluppato nella parte di “business intelligence” può essere facilmenteriutilizzato per altre applicazioni che ne debbano aver bisogno.Personalmente, ritengo che tale progetto si possa definire di grande utilità per leaziende di produzione software, sia per quanto riguarda lorganizzazione e lareperibilità dei dati relativi a clienti ed installazioni, sia in termini di tempi e costi dovutiad installazione, sviluppo e manutenzione dei prodotti. Nel caso specifico, ritengo cheladozione di questo applicativo allinterno di Insiel Mercato, permetterà grandievoluzioni nella fase di “deploy” dei prodotti, evitando i vari disagi in cui spesso capitadi incorrere. Consentirà inoltre di aumentare velocità ed efficacia della manutenzione edi nuovi sviluppi, avendo sottomano una chiara mappatura della situazione delladistribuzione dei progetti tra i clienti.Il progetto realizzato verrà ulteriormente sviluppato nel corso dei prossimi mesi ed èprevista la sua entrata in produzione presso il laboratorio tecnico di sviluppo per lapubblica amministrazione di Insiel Mercato, nel mese di settembre. Prima del suo usoeffettivo, se ne vogliono aumentare le caratteristiche, integrandovi il sistema digestione di autenticazioni e autorizzazioni presente nellazienda, fornendo linterazionecon JIRA (un sistema di issue tracking, ovvero un software che ha il compito diraccogliere e mantenere organizzate tutte le informazioni e le segnalazioni relative agestione, sviluppo e programmazione di una applicazione), un servizio di invio notifiche
  • 39. 5 - Conclusioni Pag. 38/39tramite posta digitale e personalizzare maggiormente quello che è al momento ilcomportamento dellapplicativo nella fase di deploy del compilato sul server ftp.A completamento di questo lavoro di tesi vengono considerati i sorgenti del softwarerealizzato, nonché i documenti specifici della applicazione, consistenti nella guida diinstallazione e configurazione.6 - RIFERIMENTI[1] Maven,http://maven.apache.org/[2] Luca Vetti Tagliati, Mokabyte"Maven: best practice applicate al processo di build e rilascio di progetti Java. "[3] Apache Continuum,http://continuum.apache.org/[4] SVNKit, subversion for java,http://svnkit.com/[5] Maven Wagon FTP,http://maven.apache.org/wagon/wagon-providers/wagon-ftp/[6] Martin Fowler, “Continuous Integration”,http://martinfowler.com/articles/continuousIntegration.html[7] Controllo Versioni,http://it.wikipedia.org/wiki/Controllo_versione[8] Guida Subversion, Francesco Abeni, programmazione.html.it[9] The Best Continuous Integration Tools,Vlad Kofmanhttp://www.developer.com/[10] Hibernate, Wikipediahttp://it.wikipedia.org/wiki/Hibernate[11] Hibernate, Referencehttp://docs.jboss.org/hibernate/core/3.6/reference/en-US/html_single/