Universit a degli Studi di Padova - SIAGAS

Universita degli Studi di PadovaFacolta di Scienze Matematiche, Fisiche e Naturali

Corso di Laurea Triennale in Informatica

Profilatore di visitatori di siti Web

Tesi di Laurea Triennale in Informatica

Relatore: Prof. Tullio Vardanega

Laureando: Abramo Franchetti

Anno Accademico: 2010/11

Se gli ingegneri costruisserocome i programmatori programmano,basterebbe il volo di un picchioa distruggere l’intera civilta.

– Niklaus Wirth.

Ringraziamenti

Desidero ringraziare il Prof. Tullio Vardanega, che in qualita di relatore mi haaiutato a portare a termine la stesura di questo elaborato.

Voglio ringraziare anche Francesco Brunello, Alberto Veronese, Mirko Scognamiglio,Andrea Balzan, Attilio Salvaro, Daniele Lovato e tutti quelli che mi hanno aiutato

durante lo svolgimento dello stage.

Ringrazio l’azienda Sanmarco Informatica S.p.A. per la disponibilita e l’ottimorapporto instaurato con i dipendenti.

Un ringraziamento particolare a tutti gli amici e a chi mi e stato vicino durantequesti anni.

Infine ringrazio te, Paola. Senza di te niente di tutto questo sarebbe stato possibile.

pagina 2 di 83

Indice

1 L’azienda 71.1 Presentazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.2 partner Commerciali . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.3 Business Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.4 Project Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.5 Strumenti utilizzati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 Strategia Aziendale 112.1 Il Progetto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1.1 Scopo del progetto . . . . . . . . . . . . . . . . . . . . . . . . . 112.2 Collocazione all’interno dell’azienda . . . . . . . . . . . . . . . . . . . . 112.3 Ambiente di lavoro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.4 Descrizione del Progetto . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4.1 L’idea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.4.2 Elementi Chiave . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.5 Vincoli Progettuali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.6 Strumenti utilizzati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3 Lo Stage 193.1 Piano di Lavoro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1.1 Analisi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.1.2 Progettazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.1.3 Sviluppo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.1.4 Formazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2 Il Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.2.1 Paradigma di Programmazione . . . . . . . . . . . . . . . . . . 233.2.2 Vista Generale . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.2.3 Struttura del database . . . . . . . . . . . . . . . . . . . . . . . 243.2.4 Vista a livello package . . . . . . . . . . . . . . . . . . . . . . . 253.2.5 Diagrammi di sequenza e attivita . . . . . . . . . . . . . . . . . 273.2.6 Il convertitore . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.2.7 La classe Finder . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.2.8 La classe DBManager . . . . . . . . . . . . . . . . . . . . . . . . 353.2.9 La classe Registrator . . . . . . . . . . . . . . . . . . . . . . . . 363.2.10 L’interfaccia Exporter . . . . . . . . . . . . . . . . . . . . . . . 38

3

INDICE INDICE

3.2.11 Interfaccia Grafica . . . . . . . . . . . . . . . . . . . . . . . . . 393.2.12 Interfaccia da Riga di Comando . . . . . . . . . . . . . . . . . . 41

3.3 Fase di Ottimizzazione . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.3.1 Risultati della fase di Ottimizzazione . . . . . . . . . . . . . . . 43

3.4 Integrazione con Extractor . . . . . . . . . . . . . . . . . . . . . . . . . 453.5 Risultati finali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4 Conclusioni 474.1 Stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.2 Metodo di lavoro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.3 Universita . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

A Il database SQLite 51A.1 Caratteristiche e limitazioni . . . . . . . . . . . . . . . . . . . . . . . . 51

A.1.1 Vantaggi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51A.1.2 Svantaggi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

B Il framework Microsoft .NET 53B.1 Caratteristiche principali . . . . . . . . . . . . . . . . . . . . . . . . . . 53B.2 Il linguaggio C# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54B.3 Differenze con il C/C++ . . . . . . . . . . . . . . . . . . . . . . . . . . 54B.4 Differenze con Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

B.4.1 Package in C# . . . . . . . . . . . . . . . . . . . . . . . . . . . 55B.5 Confronto fra .NET e Java EE . . . . . . . . . . . . . . . . . . . . . . . 55

B.5.1 Gestione Dei Thread . . . . . . . . . . . . . . . . . . . . . . . . 56B.6 PLINQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57B.7 UI Data Bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

C QlikView 61

D Visual Studio 65D.1 Strumenti forniti da Visual Studio . . . . . . . . . . . . . . . . . . . . . 65

D.1.1 Analizzatore delle prestazioni . . . . . . . . . . . . . . . . . . . 66

E Sorgenti delle Informazioni 67E.1 IPINFODB.COM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67E.2 RIR (Regional Internet Registry) . . . . . . . . . . . . . . . . . . . . . 68

E.2.1 RIR NCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68E.2.2 ARIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

F XMLSchema 71F.1 Schema per la lista di IP . . . . . . . . . . . . . . . . . . . . . . . . . . 71F.2 Schema per IPINFODB.COM . . . . . . . . . . . . . . . . . . . . . . . 72

G MVC 73G.1 Struttura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

pagina 4 di 83

INDICE INDICE

H RPG (Linguaggio di Programmazione) 75H.1 Cenni Storici . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

I Mappa Dinamica Google MapsTM 77

J Agile Development 81J.1 Principi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81J.2 Pratiche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

pagina 5 di 83

INDICE INDICE

pagina 6 di 83

Capitolo 1

L’azienda

1.1 Presentazione

Sanmarco Informatica S.p.A e una Software House italiana avente sede a Grisig-nano di Zocco (VI).

Essa si rivolge alle organizzazioni (aziende private appartenenti a varie categoriemerceologiche) che necessitano di soluzioni software gestionali affidabili, performantie sopratutto personalizzabili secondo le loro esigenze.

Figura 1.1: Logo della Sanmarco Informatica S.p.A.

Sanmarco Informatica nasce negli anni ’80 come Software House specializzata negliapplicativi per aziende manifatturiere. Oggi si avvale di un capitale umano di oltre270 collaboratori diretti, conta tre filiali e 12 distributori sul territorio nazionale.

In questi anni la societa e in crescita e punta ad ampliare le proprie aree di com-petenza attraverso la specializzazione del proprio personale nei vari domini applicativinecessari allo sviluppo dei software richiesti dal mercato.

Sanmarco Informatica e molto impegnata anche nella formazione che si organizzaper il proprio personale e per i propri clienti, tramite numerosi corsi in aula e corsiautodidattici via web.

7

1.2. PARTNER COMMERCIALI CAPITOLO 1. L’AZIENDA

1.2 partner Commerciali

Sanmarco Informatica e partner commerciale di diversi vendor, i piu noti tra i qualisono IBM e Microsoft.

Sanmarco Informatica inoltre e da poco entrata nel programma Apple Autho-rized Reseller. Oltre all’opportunita di acquisto dei prodotti Apple direttamentein Sanmarco Informatica questo consente di offrire ai clienti dell’azienda soluzioniapplicative finalizzate a valorizzare questi dispositivi.

1.3 Business Unit

Le Business Unit (ovvero aree di specializzazione) aziendali sono:

- Project Management: e quella parte che si occupa di applicare le conoscenze,attitudini, tecniche e strumenti ritenute migliori alle attivita di un progetto alfine di conseguirne gli obiettivi;

- Web marketing: e l’insieme delle delle attivita di marketing dell’azienda chesfruttano il canale online per studiare il mercato e sviluppare i rapporti com-merciali (promozione/pubblicita, distribuzione, vendita, assistenza alla clientela,etc.) tramite il web;

- Configurazione di prodotto: e quel segmento aziendale che ha lo scopo diidentificare, tra i vari prodotti o le varie opzioni disponibili, quelle che megliorispondono alle sue richieste, anche nel caso in cui non siano mai state realizzateprima;

- Organizzazione di produzione: in quest’area Sanmarco si avvale dellemetodologie di Lean Production (produzione snella) – che e una filosofia indus-triale ispirata al Toyota Production System, che mira a minimizzare gli sprechifino ad annullarli – e Teoria dei Vincoli (TOC) che e una teoria di managementla cui filosofia prevede di identificare le debolezze e i vincoli insiti nel processo diproduzione e a ristrutturare il resto dell’organizzazione attorno alle esigenze diquesti ultimi;

- Controllo di qualita: e la parte della Gestione della qualita mirata a soddisfarei requisiti per la qualita;

- Controllo di gestione: e il sistema operativo volto a guidare la gestione versoil conseguimento degli obiettivi stabiliti in sede di pianificazione operativa;

- Workflow management: e una teoria di management la cui filosofia prevededi promuovere la gestione dei gruppi di lavoro collaborativi secondo il workflowmodel (modello processuale). Un processo consiste in una o piu attivita ognunadelle quali rappresenta un lavoro da svolgere per giungere a un obiettivo comune.

Al servizio di queste vi sono vari team di sviluppatori software, commerciali etecnici che si occupano di seguire via via i vari progetti che vengono presentati.

pagina 8 di 83

CAPITOLO 1. L’AZIENDA 1.4. PROJECT MANAGEMENT

1.4 Project Management

L’approccio generale di Project Management adottato per lo sviluppo di pro-getti e quello Agile (vedi appendice J).

Spesso e volentieri i progetti assegnati hanno requisiti instabili e in rapida evoluzione,e solo un approccio dinamico e in grado di coinvolgere il cliente si rivela adatto alleesigenze di sviluppo, data anche la generale complessita dei singoli progetti.

1.5 Strumenti utilizzati

Per quanto riguarda gli strumenti utilizzati dall’azienda, ve ne sono sia a licenzalibera sia di proprietari. Un breve elenco di questi e:

- HLL (High-Level programming Language): Java, C# e VB .NET sonoi tre linguaggi ad alto livello scelti da Sanmarco Informatica per competere nelmoderno mercato del software;

- LLL ( Low-Level programming Languages): RPG ILE e Visual RPG eil linguaggio su cui gira ancora una buona parte del software “storico” sviluppatonegli anni da Sanmarco Informatica (vedi appendice H);

- IDE (Integrated Development Environment): Eclipse e Visual Studiocome IDE di sviluppo del codice rispettivamente Java, C# e VB .NET;

- Strumenti di Versionamento : Subversion e SourceSafe per il versiona-mento del codice sorgente rispettivamente Java ,C# e VB .NET.

Per la collaborazione interna tra i dipendenti dell’azienda sono messi a disposizionenumerosi strumenti di comunicazione e condivisione, quali posta, calendario ed elencocontatti.

pagina 9 di 83

1.5. STRUMENTI UTILIZZATI CAPITOLO 1. L’AZIENDA

pagina 10 di 83

Capitolo 2

Strategia Aziendale

2.1 Il Progetto

Il progetto assegnatomi e stato chiamato “Profilatore di visitatori di siti Web”o piu brevemente, “Profilatore”. Si tratta di un progetto esplorativo ed e il primostep per un possibile sviluppo futuro di un’ applicazione piu complessa e sofisticata.

2.1.1 Scopo del progetto

Lo scopo del progetto assegnatomi e stato quello di creare un’applicazione stand-alone per ambiente WindowsTM che fosse in grado – a partire da un file di log degliaccessi di sito Web di un comune server web – di recuperare delle informazioni suivisitatori di tale sito, e di presentarle in un formato che permetta l’analisi dei datirecuperati (vedi figura 3.17).

Era inoltre richiesto che l’applicazione fornisse un’interfaccia grafica in grado diconsentire operazioni di filtraggio e ricerca dei dati, nonche l’esportazione di tali datiin vari formati tra cui PDF e almeno un formato tabellare (Microsoft ExcelTM o CSV).

L’applicazione doveva anche essere fornita di un sistema anti-copia che garantissel’utilizzo del prodotto solo a chi ne possiede la licenza (vedere paragrafo 3.2.9).

Un altro requisito era quello di poter distribuire l’applicazione attraverso un singolofile d’installazione come e tipico per le applicazioni Windows.

Una descrizione piu accurata di queste funzionalita verra data nel paragrafo 2.4.

2.2 Collocazione all’interno dell’azienda

La divisione dell’azienda nella quale e stato collocato il progetto di cui sopra el’area Web, anche se l’applicazione di per se stessa non tocca propriamente gli ambitidi lavoro tipici di tale area. In ogni caso per vari motivi, di cui parlero in seguito, estato opportuno che lo sviluppo complessivo del progetto fosse fatto in tale ambito.

11

2.3. AMBIENTE DI LAVORO CAPITOLO 2. STRATEGIA AZIENDALE

Il progetto in ogni caso non aveva una collocazione fissa ma doveva necessariamentevenire a contatto con piu segmenti aziendali.

Quindi oltre all’area web e gli sviluppatori di tale area dovevo interfacciarmi con itecnici dell’area di Configuarazione di prodotto per capire come il software dovevaessere modularizzato in maniera da poter essere il piu possibile personalizzato secondole esigenze del cliente;

dovevo relazionarmi con la parte commerciale e di Web Marketing per capirequali funzionalita andavano implementate e a che tipo di informazioni si desideravaarrivare;

inoltre dovevo essere in stretto contatto con il Project Management percheanche il mio progetto aveva necessita di essere gestito.

Profilatore e un progetto interno all’azienda, quindi non esiste un cliente finalevero e proprio. Il ruolo di committente e invece stato assunto dal tutor aziendaleFrancesco Magnaguagno.

L’intero progetto e stato seguito quasi esclusivamente dal sottoscritto, previo aiutonella fase di analisi e nelle prime fasi di sviluppo, in particolare nel setup di tutti glistrumenti software (e non) che sono stati utilizzati.

Egli inoltre mi ha seguito durante la progettazione architetturale e la scritturadel codice, aiutandomi dove trovavo difficolta e suggerendomi soluzioni di problemiparticolarmente complessi.

Con lui e anche con altri responsabili del mio reparto sono state programmatedurante tutto lo stage, a intervalli settimanali, delle riunioni di SAL(Stato di Avanza-mento dei Lavori) durante tutta la fase di sviluppo.

Inoltre sono stato aiutato da Mirko Scognamilio e Alberto Veronese che hannoassunto il ruolo di tester delle varie versioni intermedie dell’applicazione.

2.3 Ambiente di lavoro

Il lavoro e stato svolto interamente all’interno della sede dell’azienda ospitante,situata a Barbano, frazione di Grisignano di Zocco in provincia di Vicenza.

L’orario di lavoro e stato il normale orario di 8 ore giornaliere. Al mio arrivoin azienda era gia stata predisposta per me una postazione di lavoro, mi e statoconsegnato un computer portatile che e rimasto nelle mie mani per l’intera duratadello stage e che e quello che ho utilizzato per l’intero sviluppo del progetto.

L’ambiente lavorativo e stato ben piu che ospitale, e si e instaurato da subito unottimo rapporto con gli altri dipendenti, che si sono dimostrati da subito cordiali eprofessionali.

pagina 12 di 83

CAPITOLO 2. STRATEGIA AZIENDALE 2.4. DESCRIZIONE DEL PROGETTO

2.4 Descrizione del Progetto

In questo paragrafo verra descritto il progetto Profilatore nella sua visione com-plessiva, si parlera dei motivi che hanno portato al suo sviluppo, degli obiettivi che siintendeva raggiungere e di come l’idea di questo progetto di stage e nata.

2.4.1 L’idea

Il progetto e nato da un’idea di Alberto Veronese che desiderava uno strumentocomplementare a strumenti web quali, a titolo di esempio, Google AnalyticsTM perl’analisi delle visite di un sito web.

Quello a cui si puntava quindi non era tanto l’analisi del dato aggregato del numerodegli accessi, cosa che Analytics esegue gia egregiamente, bensı riuscire a recuperarequelle informazioni che il servizio di Google per vari motivi – in particolare le normesulla privacy – non puo offrire cioe il nome dell’utente e coordinate geografichelegate all’indirizzo IP che ha effettuato la visita.

L’idea nasce dal fatto che vi erano gia alcuni clienti Sanmarco che richiedevano untale tipo di servizio e alcuni di questi ultimi utilizzavano per loro conto dei sistemi perrecuperare tali informazioni.

Tuttavia questi sistemi erano inaffidabili, discontinui e non integrabili tra loro.In particolare le informazioni a cui si desiderava arrivare erano:

- Nome dell’organizzazione o ente che ha registrato l’indirizzo IP; Anche senon sempre questo corrisponde con il nome dell’utente finale (sopratutto nel casoquesto sia un privato), le aziende tendono ad registrare la rete con il proprionome.

Per un approfondimento su come e dove vengono reperite queste informazionivisionare l’appendice E.2.

- Stato/Regione/Citta da dove si presume che l’indirizzo IP sia localizzato.

- Latitudine/Longitudine del punto esatto dove si presume che l’indirizzo IPsia localizzato.

2.4.2 Elementi Chiave

Quello che si desiderava fornire era una soluzione che integrasse in un solo stru-mento tutte quelle utilita sopra descritte.

Gli elementi chiave dunque dovevano essere:

- l’integrazione,come detto sopra;

- la semplicita di utilizzo, cioe l’essere a portata di tutti, o perlomeno da chi giausa uno strumento di analisi delle visite;

- le performance, dato che il programma nasce con lo scopo di gestire potenzial-mente grandi quantita di dati e deve essere rapido nell’elaborarli;

pagina 13 di 83

2.4. DESCRIZIONE DEL PROGETTO CAPITOLO 2. STRATEGIA AZIENDALE

- la flessibilita, dato che le sorgenti dei dati online possono cambiare e quindi enecessario poter adattare velocemente l’applicazione.

Legato al tema dell’integrazione risulta la necessita dell’applicazione di riuscirea interfacciarsi con varie sorgenti di dati quali:

- Servizi Web;

- Database (SQL e XML);

- File tabellari (Excel e CSV)

- File di log in formato testuale (log degli accessi)

Per quanto riguarda invece la semplicita d’uso e evidente che un ruolo fonda-mentale e giocato dall’interfaccia grafica dell’applicazione. Questa doveva essere ilpiu possibile pulita e sopratutto simile a quelle applicazioni che l’utente medio e giaabituato a utilizzare.

Un’altra questione che tocca la questione della semplicita era il formato di dis-tribuzione del prodotto finale. L’installazione del prodotto doveva poter essere fat-ta dall’utente con assoluta semplicita e non richiedere configurazioni particolari daeffettuare in tale fase.

Il meccanismo attraverso il quale il sistema chiede informazioni all’utente e quellodelle user action. Profilatore infatti a seconda del formato degli ingressi decide qualiinformazioni richiedere all’utente per poter effettuare il corretto trattamento dei dati.Ad esempio il formato delle stringhe dei record dei file di log e variabile a seconda deltipo di server e della sua configurazione. Se l’applicazione non riesce a riconoscere ilformato, verranno richieste all’utente delle informazioni in modo da riuscire a effettuarecorrettamente il parsing del file.

Per quanto invece concerne le performance dell’applicazione, parte del lavoro estato fatto in fase di progettazione e un’altra parte e stata fatta in fase di scrittura delcodice e ne parlero ampiamente piu avanti (vedi il paragrafo 3.3 e l’appendice B.6).Brevemente e stato fatto tutto un lavoro di ricerca e analisi sul codice, seguendo unavecchia nozione del Software Enginering che recita: un programma passa il 90% deltempo nel 10% del codice; in modo da ottimizzare tutte quelle parti dove l’applicazionespende il maggior numero di cicli macchina.

Inoltre per quelle operazioni che necessitano “fisicamente” del tempo per essereportate a termine, e tale tempo non puo essere ridotto, si e avuto cura di fornire all’u-tente un riscontro grafico dello stato di avanzamento del lavoro tramite vari indicatorigrafici.

L’applicazione doveva anche essere in grado di persistere le informazioni in modoche queste fossero fruibili in un momento successivo a quello di reperimento e forniredelle funzionalita di esportazione in vari formati tabellari di facile consultazione (vediil paragrafo 3.2.3 e il paragrafo 3.2.10).

Per quanto riguarda la flessibilita sono stati implementati dei meccanismi checonsentono all’applicazione di variare il proprio comportamento in base a dei parametri

pagina 14 di 83

CAPITOLO 2. STRATEGIA AZIENDALE 2.5. VINCOLI PROGETTUALI

che non sono hard-coded ma sono scritti su file xml e quindi possono essere cambiatisenza dover ricompilare e ridistribuire l’applicazione.

Queste sono le caratteristiche desiderate dal sistema finale che sono emerse in fasedi analisi.

Requisiti

Riassumendo molto brevemente i requisiti sono:

- Il sistema deve essere in grado di accettare in input vari formati di file di log diaccessi (vedi 3.2.6);

- Il sistema deve essere in grado di recuperare le informazioni di profilazione desider-ate sugli indirizzi IP dati in input e salvarle in maniera persistente (vedi E.1,E.2e A);

- Il sistema deve permettere la gestione separata degli accessi di piu siti (vedi 3.2.3).

- Il sistema deve consentire l’esportazione delle informazioni memorizzate in prece-denza (vedi 3.2.10);

- Il sistema deve fornire una funzionalita di controllo che ne permetta l’utilizzo soloa chi possegga la licenza (vedi 3.2.9);

- Il sistema deve fornire un’interfaccia da riga di comando (vedi 3.2.12);

- Il sistema deve essere poter essere personalizzato (vedi 3.2.11);

- Il sistema deve essere performante nel trattamento di grandi moli di dati (vedi3.3).

2.5 Vincoli Progettuali

Pur lasciandomi un’ampia liberta d’azione, fin dal principio mi sono stati posti deivincoli su come avrei dovuto realizzare il progetto.

Tali vincoli sono stati:

- Scelta del linguaggio di codifica tra Java e C#;

- Sviluppo su sistema operativo Microsoft Windows 7 con Visual Studio come IDEnel caso avessi scelto C# e su sistema operativo Ubuntu 10.10 e IDE Eclipse nelcaso avessi scelto Java;

- Rilascio di una versione pienamente funzionante a conclusione dello stage;

- Uso della metodologia di sviluppo Agile (vedi appendice J);

- Stesura di una documentazione esaustiva del prodotto rilasciato;

pagina 15 di 83

2.6. STRUMENTI UTILIZZATI CAPITOLO 2. STRATEGIA AZIENDALE

2.6 Strumenti utilizzati

Anche se in parte sono gia stati presentati nelle sezioni precedenti, desidero ri-portare in questo paragrafo una lista degli strumenti che sono stati utilizzati per losviluppo dell’applicazione con una breve descrizione degli stessi.

- Il linguaggio di programmazione C# come linguaggio di programmazione. C#un linguaggio a oggetti ed e simile a Java per funzionamento e sintassi;

- Il framework .NET (vedi appendice B) e un l’ambiente per la creazione, ladistribuzione e l’esecuzione di tutti gli applicativi che supportano .NET;

- PLINQ (Parallel LINQ) e un’implementazione parallelizzata di LINQ. LINQe un sistema che permette di effettuare query su liste di oggetti con una sin-tassi SQL-Like. PLINQ aggiunge a quest’ultimo dei metodi per effettuare delleoperazioni parallele. Ne verra parlato piu approfonditamente nell’appendice B.6;

- Visual Studio e un IDE fornito da Microsoft per la scrittura di codice in varilinguaggi, tra cui C#, XHTML, HTML (vedi appendice D);

- Dotfuscator Software Services Community Edition e uno strumento perl’offuscamento del codice;

- Profiler per eseguire misurazioni sulle prestazione dell’applicazione;

- Progetto di Setup interno a Visual Studio per creare un file di installazione daridistribuire;

- Subversion e un strumento di versionamento del codice. Come sede del reposi-tory e stata usato uno dei server interni all’azienda;

- System.Data.SQLite e una libreria multipiattaforma che implementa un DatabaseEngine transazionale che non necessita di configurazione o di un server (vedi ilparagrafo 3.2.3 e l’appendice A);

- FireBug e una celebre e potente estensione del browser Mozilla Firefox chepermette di monitorare (e persino di modificare) l’HTML, il CSS, il DOM e ilcodice JavaScript di una pagina web. Il suo utilizzo e stato fondamentale pertutte quelle parti dello sviluppo in cui ho dovuto analizzare delle pagine web ecomprenderne il funzionamento;

- Qlik e un software proprietario di BI (Business Intelligence) ed utilizza un lin-guaggio simile a SQL dove pero e anche possibile manipolare oggetti grafici. Talestrumento e stato utilizzato per definire un’interfaccia grafica che permettesse dieffettuare operazioni di datamining sui dati estratti dalla mia applicazione. Neverra parlato piu approfonditamente nell’appendice C;

- Navicat e uno strumento che consente di operare su database SQLite;

- iTextSharp e un porting per C# della famosa libreria free e opensource iTextper manipolare PDF in Java; iTextScarp e scritta in C# e ha un codice sorgenteseparato, ma mantenuto sincronizzato ad ogni rilascio, da quello di iText;

pagina 16 di 83

CAPITOLO 2. STRATEGIA AZIENDALE 2.6. STRUMENTI UTILIZZATI

- Microsoft.Office.Interop.Excel 14.0.0.0 Tale libreria e distribuita con il pac-chetto Office che Microsoft ha sul mercato. Purtroppo tale libreria presentaalcune problematiche, prima fra tutte la questione prestazionale;

- HTMLAgilityPack 1.4.0 Tale libreria e stata utilizzata per il parsing HTMLdelle pagine web analizzate. Il reperimento di tale libreria nel web e stata unadelle prime priorita del progetto che verteva sopratutto sul parsing di pagineweb. Sul web sono presenti numerosi set di classi per il parsing html, ma lamaggior parte sono creati da liberi professionisti, funzionanti ma con numerosibug e funzionalita ristrette. Fra questi oltre a HTMLAgilityPack vi era ancheHTMLParser creato dalla Majestic che risultava essere un ottimo strumento, mala bassa conoscenza in rete, la scarsa presenza di esempi di utilizzo e l’assenza diuna guida veloce ha vincolato la scelta su HTMLAgilityPack.

Inoltre sono stati utilizzati, come precedentemente detto, anche dei servizi online.Tali servizi sono:

- IPINFODB.COM (vedi appendice E.1) offre un servizio di IP Location condelle API in XML;

- A.R.I.N. (American Registry for Internet Numbers) e RIR NCC (ReseauxIP Europeens Network Coordination Center) sono i 2 RIR. (Regional InternetRegistry) che sono stati utilizzati per reperire il nome dell’intestatario di unindirizzo IP (vedi appendice E.2). Questi forniscono un Web Service che consentedi risalire a tali informazioni a partire da un indirizzo IP;

- Google Map e un servizio di Google che consente di ottenere una mappa ge-ografica con dei marcatori, e fornisce delle API in diversi linguaggi. Nel mio casosono state usate quelle Javascript;

Per tracciare diagrammi e stendere la documentazione sono invece stati utilizzati:

- OpenOffice.org e il piu diffuso software open source per la produttivita per-sonale: con questa terminologia si indicano le applicazioni che permettono ad unutente di creare dei contenuti quali documenti di testo, presentazioni o grafici.E’ stato utilizzato per la stesura di tutta la documentazione;

- ArgoUML e BoUML Per la stesura dei diagrammi delle classi e di sequenzapresenti in questo documento e nella documentazione ufficiale depositata pressol’azienda sono stati utilizzati i tool open source ArgoUML e BoUML;

- GanttProject Per la stesura dei diagrammi di Gantt.

pagina 17 di 83

2.6. STRUMENTI UTILIZZATI CAPITOLO 2. STRATEGIA AZIENDALE

pagina 18 di 83

Capitolo 3

Lo Stage

3.1 Piano di Lavoro

Alla partenza dello stage e stato redatto un piano di lavoro settimanale, che miconsentisse di avere da subito chiari gli obiettivi da portare a termine e il tempoconcessomi per portarli a termine.

Le fasi che hanno segnato il ciclo di sviluppo dell’applicazione sono state:

- Analisi;

- Progettazione;

- Sviluppo;

- Formazione.

La fase di formazione si e svolta in modo parallelo alle prime due, in modo daportarmi alla fase di sviluppo con le capacita necessarie per portare a termine il lavoroassegnatomi.

Come detto in precedenza, si e scelto un approccio agile (vedi appendice J), quindile fasi di analisi e progettazione sono state fatte ad alto livello, per non perdersi nellacomplessita dei dettagli, mentre il grosso del lavoro e stato fatto in fase di sviluppo;come detto in precedenze essa consisteva in sessioni di lavoro di durata di una setti-mana seguita da una riunione di SAL (Stato di Avanzamento dei Lavori) per esporrequanto svolto e ricevere consigli su come continuare lo sviluppo.

Con questo tipo di approccio il cliente deve essere disposto a dedicare molto tempoal progetto (piu che con altri modelli di ciclo di vita).

Questo svantaggio della metodologia agile e stato mitigato dal fatto che nel miocaso il cliente era il mio tutor aziendale e non un cliente vero e proprio, quindi bendisposto a dedicare al progetto parte del suo tempo.

19

3.1. PIANO DI LAVORO CAPITOLO 3. LO STAGE

3.1.1 Analisi

Durante la fase di analisi, che e durata una settimana, si sono tenuti piu incontricon il committente al fine di capire in maniera dettagliata le caratteristiche che ilprodotto finale doveva avere. Sono state svolte da parte mia delle ricerca finalizzatea:

- effettuare un’analisi delle caratteristiche dei prodotti simili a quello che mi ac-cingevo a sviluppare, al fine di trovarne le potenzialita e i limiti;

- effettuare uno studio delle sorgenti delle informazioni disponibili in rete (con lequali mi dovevo interfacciare) per verificare le loro attendibilita e il grado diprecisione che queste offrivano.

Durante tale fase e stato deciso di sviluppare l’applicazione utilizzando il linguaggioC# e il framework .NET e di conseguenza di utilizzare come ambiente di sviluppoMicrosoft Visual Studio 2010. Sono inoltre stati definiti i requisiti minimi di sistema.

E’ stato anche deciso di utilizzare il database SQLite. Oltre che per tutti i motiviche si possono leggere nell’appendice A e nel paragrafo 3.2.3 tale database e statoscelto perche multipiattaforma e in previsione di un futuro porting dell’applicazionesu dispositivi Android e piu in generale sistemi basati su Linux tramite il tool diconversione MonoDroid e Mono (vedi B.5).

Un breve riassunto dei requisiti emersi durante la fase di analisi e presente nelparagrafo 2.4.2.

Risultati delle ricerca delle sorgenti delle informazioni

Come affermato precedentemente una parte importante della fase di analisi e stataquella di ricercare le varie sorgenti di informazioni disponibili in rete e confrontarleper scegliere quella piu adatta alle mie esigenze.

Il risultato delle ricerche e stato:

- IPINFODB.COM: e descritto nell’appendice E.1;

- Regional Internet Registry (RIR): sono descritti nell’appendice E.2;

- MaxMind.com: fornisce delle API in xml e altri formati. Fornisce ancheun database scaricabile cosı da non dovere avere necessariamente una connes-sione internet per recuperare i dati. Tutti i servizi di MaxMind.com sono pero apagamento e quindi sono stati scartati.

Alla fine i servizi che sono stati scelti sono i primi 2. Questo perche:

- Sono gratuiti;

pagina 20 di 83

CAPITOLO 3. LO STAGE 3.1. PIANO DI LAVORO

- Forniscono delle API di accesso ai dati in vari formati tra cui xml;

- Sono affidabili;

- Combinati assieme forniscono tutte le informazioni che si desiderava ottenere(nome dell’intestatario della rete e collocazione geografica).

I 2 servizi scelti comunque presentano dei vincoli (descritti in maniera dettagliatanell’appendice E.2 e E.1) che in sostanza riguardano il numero di richieste che sipossono effettuare per intervallo di tempo e le conseguenze del superamento di talelimite.

3.1.2 Progettazione

La fase di progettazione ha avuto la durata di due settimane. Tale fase e statadivisa in quattro parti:

- Progettazione della classe Finder, cioe quella incaricata di connettersi alle sor-genti di informazioni online, e di tutte le altre classi che dovevano interfacciarcicon servizi Web;

- Progettazione della classe Converter e di tutte quelle classi che vengono utilizzatedurante la fase di input dei dati nell’applicazione;

- Progettazione dell’interfaccia grafica. Tale parte e stata fatta molto ad alto liv-ello, data la mia scarsa conoscenza del sistema di progettazione di interfaccegrafiche con il framework .NET;

- Progettazione del sistema di controllo della licenza utente.

Infine con il tutor aziendale e stata svolta una revisione dell’attivita di proget-tazione ed e stato pianificato lo sviluppo.

3.1.3 Sviluppo

La fase di sviluppo ha avuto la durata di 6 settimane e queste sono state cosısuddivise;

- le prime due settimane sono state dedicate allo sviluppo di un prototipo funzio-nante (per quanto primitivo ed incompleto) dell’applicazione;

- le successive 3 settimane sono state dedicate al miglioramento di tale prototipo,dell’interfaccia grafica e dei servizi offerti;

- l’ultima settimana e stata dedicata all’ottimizzazione del codice, ai fini dellavelocita di esecuzione.

Durante tutta la fase di sviluppo sono stati anche redatti dei diagrammi UML delleclassi e di sequenza aggiornati.

Questa revisione dei diagrammi si e resa necessaria perche durante lo sviluppomolte delle soluzioni che erano state adottate in fase di progettazione sono state riviste,se non completamente cambiate. Questo e dovuto quasi totalmente al fatto che la miaconoscenza del framework .NET era molto limitata a quel tempo.

pagina 21 di 83

3.2. IL SISTEMA CAPITOLO 3. LO STAGE

Tali diagrammi sono stati consegnati all’azienda nella documentazione finale. In-oltre il codice prodotto e stato opportunamente commentato seguendo una sintassiXML per certi versi simile al JavaDoc, che ha permesso la generazione della documen-tazione del codice, alla quale i diagrammi sono stati allegati.

Parte di tali diagrammi sono visibili nelle figure 3.8, 3.9, 3.10, 3.11, 3.5, 3.12 e 3.13.

3.1.4 Formazione

La quasi totalita degli strumenti utilizzati mi era in principio sconosciuta, datoche nel mondo accademico vengono prediletti strumenti free come Java ed Eclipse, adesempio, a strumenti proprietari come C# e Visual Studio.

Per questo e stata una parte fondamentale del mio percorso di stage la formazionetecnologica.

Tale formazione si e svolta in modo parallelo alle altre fasi di sviluppo ed e stataportata avanti in maniera autonoma attraverso la consultazione di libri e manuali chemi sono stati forniti. Parte delle risorse utilizzate nello studio e citato nei riferimentibibliografici, consultabili alla fine del presente elaborato.

3.2 Il Sistema

In questa sezione verra descritta l’architettura del sistema, e il suo funzionamento.

Figura 3.1: Schema generale del funzionamento di Profilatore

pagina 22 di 83

CAPITOLO 3. LO STAGE 3.2. IL SISTEMA

Piu che mostrare in dettaglio tutta l’architettura del sistema, verranno mostratiquei particolare che ritengo piu significativi e quelle scelte implementative che ritengoessere di maggior impatto sul risultato finale.

3.2.1 Paradigma di Programmazione

Il paradigma di programmazione adottato, essendo l’applicazione che si andava agenerare basata su interfaccia grafica, e quello del Event-Driven Programming. Incio sono stato aiutato dall’IDE scelto per la scrittura del codice (vedi D) che fornivavarie funzionalita di generazione automatica del codice che consentiva di automatizzaretutti quei Task ripetitivi richiesti dal event handling.

E’ quindi stata una parte molto importante della progettazione tutto il controlloe la gestione degli eventi.

Vantaggi

Il vantaggio di tale metodo di programmazione e quello di consentire al program-matore di concentrarsi sul flusso di istruzioni che verra eseguito al generarsi di un datoevento, ed e molto pratico nella gestione delle interfacce grafiche.

Svantaggi

Lo svantaggio e che questo stile di programmazione e un terreno fertile per i bugper almeno 2 motivi: Poi si sceglie un numero primo

- Non e Thread Safe.

Per gestire tale condizione critica ed evitare errori durante la programmazione,.NET impone dei vincoli molto severi sulla generazione e gestione di nuovi Thread.A tal proposito vedere la sezione B.5.1;

- Puo portare il programmatore a scrivere codice direttamente all’interno del-l’event hanlder per ogni combinazione dei valori assunti dalle variabili del pro-gramma. Questo porta il codice ad essere ripetitivo e difficile da comprendere,moltiplicando le possibili sorgenti i errori.

Tale criticismo e stato tenuto sotto controllo in fase di progettazione, effettuandoun’accurata progettazione delle gestione degli eventi. Inoltre durante la fasedi codifica e stato utilizzato un tool integrato in Visual Studio per evitare lagenerazione di codice duplicato. A tal proposito vedere la sezione D.1.

3.2.2 Vista Generale

Come si vede nella figura 3.1, le parti principali del progetto sono:

- Il “convertitore” di file .log, vedi il paragrafo 3.2.6 che e il componente chesi occupa di convertire i vari formati di file di log nel formato xml accettatodall’applicazione (vedi F);

pagina 23 di 83


- Il “parser XML” che e il componente che si occupa di estrarre la lista di indirizziIP dal file XML;

- Il “finder” ossia quello che si occupa di reperire le informazioni sulla lista diindirizzi recuperata;

- Il “DBManager” ossia quello che si occupa di interagire con il DB;

Inoltre altre 2 componenti fondamentali sono:

- L’interfaccia Grafica (vedi 3.17);

- L’“Exporter” ossia quello che si occupa di esportare le informazioni (vedi 3.2.10).

3.2.3 Struttura del database

In fase di analisi e stata definita la seguente struttura per le tabelle del database.Si noti che nella tabella IP (vedi figura (3.2), che mantiene tutte le informazioni

di geolocalizzazione e di tracciamento per ogni IP la chiave e appunto l’indirizzo IP.L’unicita di tale campo e garantita dal fatto che l’IP e univoco per definizione.

Figura 3.2: Tabella IP

Nella tabella IPVISIT (vedi figura 3.3) invece viene tenuta traccia del numero divisite per ogni IP su ogni sito e della data di ogni visita. Cio e importante perchesuccessivamente e necessario poter filtrare le visite per data.

Si noti anche che il campo data nella tabella IP si riferisce invece alla data diprima immissione di tale indirizzo IP.

Figura 3.3: Tabella IP

pagina 24 di 83


Per ottenere quindi gli indirizzi IP e relative informazioni per un dato Sito esufficiente eseguire una JOIN delle due tabelle sulle chiavi.

Non e stato definito nessun vincolo di chiave esterna perche SQLite non supportala gestione di tali vincoli. Anche la definizione di campi con formati diversi da Stringe artificiosa. SQLite memorizza al suo interno i campi tutti in formato stringa. Peruna dissertazione piu dettagliata su SQLite vedere l’appendice A.

3.2.4 Vista a livello package

Visual Studio fornisce un modo peculiare con cui gestire i vari package (vediappendice B.4.1).

Essi vengono gestiti come “Project” separati all’interno della stessa “Solution”. Intale modo quando il progetto viene compilato vengono generate per ogni “Project”le relative dll. In questo modo quando si desidera distribuire un’aggiornamento delsoftware, non occorre ridistribuire tutto l’applicativo ma solo quelle dll che sono statemodificate. Quindi piu che di package in senso Java, si parla di Namespaces in sensoC++. Per un approfondimento di questo argomento vedere l’appendice D.

Nell’immagine 3.4 e mostrata l’architettura ad alto livello dell’applicazione. Sonostate volutamente tralasciate le varie classi Form dell’interfaccia grafica ad eccezionedei quella principale al fine di una maggiore chiarezza del grafico.

Figura 3.4: Vista a livello Package

pagina 25 di 83


Come si puo vedere e stato utilizzato il pattern architetturale MVC (vedi appendiceG). Tale pattern infatti ben si presta a progetti come quello in oggetto, che necessitanodi un’interfaccia grafica, che interagiscono con una base dati e devono in ogni casoeseguire elaborazioni sui dati in ingresso. Il rapporto tra le varie classi e mostrato infigura 3.5

Figura 3.5: Diagramma delle classi

Per le classi del package model (figura 3.6), che rappresentano rispettivamente leentita indirizzo IP e il corrispondente indirizzo IP completo di informazioni e statoscritto un override il metodo equals() in modo da risultare coerente con quantodefinito nel database (vedi sezione 3.2.3).

Figura 3.6: Package model

pagina 26 di 83


Figura 3.7: Package controller

3.2.5 Diagrammi di sequenza e attivita

Vengono di seguito riportati alcuni diagrammi di attivita e di sequenza che con-sentiranno di capire meglio il funzionamento di alcune delle parti fondamentali del-l’applicazione.

In particolare vengono riportati i diagrammi di attivita e sequenza per:

- l’avvio dell’applicazione (vedi figure 3.8 e 3.9);

- il processo di ricerca delle informazioni di un indirizzo IP dalle sorgenti di dationline (vedi figure 3.10 e 3.11);

- il processo di esportazione dei dati (vedi figure 3.12 e 3.13).

Avvio dell’applicazione

Figura 3.8: Diagramma delle attivita che descrive l’avvio dell’applicazione

pagina 27 di 83


Figura 3.9: Diagramma di sequenza che descrive l’avvio dell’applicazione

Ricerca delle informazioni

Figura 3.10: Diagramma delle attivita che descrive il processo di ricerca delleinformazioni

pagina 28 di 83


Figura 3.11: Diagramma di sequenza che descrive la ricerca dele informazioni

Esportazione

Figura 3.12: Diagramma delle attivita che descrive il processo di esportazione

pagina 29 di 83


Figura 3.13: Diagramma di sequenza che descrive il processo di esportazione

pagina 30 di 83


3.2.6 Il convertitore

Durante la fase di analisi e emerso che al fine di una piu facile gestione del codice,di una piu semplice gestione degli aggiornamenti futuri e per un maggior grado di per-sonalizzazione dell’applicazione sulle richieste di clienti futuri,conveniva destrutturareil progetto in moduli separati che fossero successivamente integrati.

In particolare si e deciso di implementare come un progetto separato da quello orig-inale quel componente che si occupa di convertire i vari formati di file di log nel formatoaccettato dall’applicazione. Questo perche tenendolo come un componente separato epiu semplice poter modificarlo e ridistribuirlo a un futuro cliente che necessita di unapersonalizzazione sul prodotto.

Quindi e stato creato un “Project” separato all’interno della “Solution” di VisualStudio per il convertitore (per una delucidazione vedere D) anche se, in pratica, tuttoil lavoro viene fatto da una solo classe.

In sostanza in questo modo il convertitore e un file eseguibile a se stante che puoessere redistribuito in maniera autonoma ed e del tutto indipendente dall’applicazioneprincipale.

Figura 3.14: Screenshot dell’interfaccia grafica del convertitore

Compito del convertitore

Il compito del convertitore e, come gia detto, quello di convertire i file di log in fileXML compatibili con l’applicazione. In sostanza il problema da risolvere era quelloche i vari tipi di server in commercio memorizzano un file di log degli accessi il cuiformato e diverso a seconda del tipo di server e il formato cambia anche in rapportoal setup scelto dal sistemista per tale server.

E’ stato quindi deciso che l’input dell’applicazione non sarebbe stato un file di log,ma un file XML, in un formato ben definito in precedenza.

Compito del convertitore e quello di convertire il file di log in tale formato XML.

pagina 31 di 83


Il convertitore e in grado di essere parametrizzato in base al tipo di file di log.

Implementazione

Un file di log di un server e un file di testo dove per ogni riga (da qui in avantirecord) sono state scritte delle informazioni riguardo a tale visita. Quelle di miointeresse sono l’indirizzo IP del visitatore e la data.

Un file di log puo raggiungere facilmente dimensioni mi centinaia di MiB e quindie necessario l’algoritmo di elaborazione sia molto efficiente.

Percio e stata effettuata un’implementazione concorrente utilizzando PLINQ (vediB.6). In questo modo non solo si e ottenuto in modo “gratuito” uno speedup notevolee si e resa questa parte dell’applicazione scalabile nel senso che su macchine con piuprocessori si avra automaticamente un miglioramento delle performance.

Concorrenza del convertitore L’implementazione concorrente del convertitore estata effettuata in questo modo:

- e concorrente sui file diversi: si possono selezionare contemporaneamente piu fileda convertire, in tal caso piu thread partono per processare piu file contempo-raneamente;

- e concorrente sul processo di conversione in oggetti di tipo MyIPAddress a partireda ogni riga del file di log. Cio significa che piu thread partiranno per processareogni singolo file;

- e concorrente sul conteggio delle visite: durante il processo di conversione avvieneil conteggio delle visite. Questo e fatto in maniera concorrente e non aspetta lafine del processo di conversione per avvenire.

Tutta questa concorrenza di sicuro fa nascere sicuramente alcune domande: quan-ti thread vengono eseguiti simultaneamente durante il processo di conversione? Chigestisce i meccanismi di lock?

La risposta e: dipende dal numero di processori che la macchina dove avvieneil processo di conversione possiede e i meccanismi di lock sono gestiti in manieraautomatica dal framework.

Come viene spiegato meglio nell’appendice B.6 usando plinq il numero di threadche vengono istanziati e deciso automaticamente e in modo dinamico in base al numerodi processori disponibili, in modo da portare l’attivita della CPU attorno al 100% edavere cosı il massimo di performance possibile.

pagina 32 di 83


Esempi

Un esempio di input e quello nel listato 3.1:

1 01/03/2011 08 : 46 : 40 INFO (6) : [ 2 1 2 . 1 0 3 . 1 9 4 . 1 6 2 ] − a s s i s t e n z a2 01/03/2011 08 : 47 : 13 INFO (6) : [ 2 1 2 . 1 0 3 . 1 9 4 . 6 6 ] − moda3 01/03/2011 08 : 49 : 35 INFO (6) : [ 2 1 2 . 1 0 3 . 1 9 4 . 1 6 2 ] − Base csv4 01/03/2011 08 : 50 : 21 INFO (6) : [ 2 1 2 . 1 0 3 . 1 9 4 . 6 6 ] − s i s t em i s t a5 01/03/2011 08 : 51 : 16 INFO (6) : [ 2 1 2 . 1 0 3 . 1 9 4 . 1 6 2 ] − a s s i s t e n z a6 01/03/2011 08 : 56 : 19 INFO (6) : [ 2 1 2 . 1 0 3 . 1 9 4 . 6 6 ] − s i s t em i s t a7 01/03/2011 08 : 59 : 25 INFO (6) : [ 2 1 2 . 1 0 3 . 1 9 4 . 1 6 2 ] − f a c t o ry con t r o l8 01/03/2011 09 : 07 : 43 INFO (6) : [ 2 1 2 . 1 0 3 . 1 9 4 . 1 6 2 ] − f a c t o ry con t r o l9 01/03/2011 09 : 08 : 08 INFO (6) : [ 2 1 2 . 1 0 3 . 1 9 4 . 6 6 ] − i−tech

10 01/03/2011 09 : 08 : 31 INFO (6) : [ 2 1 2 . 1 0 3 . 1 9 4 . 1 6 2 ] − qua l i t a11 01/03/2011 09 : 09 : 16 INFO (6) : [ 2 1 2 . 1 0 3 . 1 9 4 . 6 6 ] − amministratore12 01/03/2011 09 : 10 : 58 INFO (6) : [ 8 2 . 6 0 . 1 8 3 . 1 3 1 ] − s i s t em i s t a

Listing 3.1: Esempio di righe di file di log

Il file XML risultato della conversione e quello nel listato seguente 3.2.Per la validazione dell’xml e stato usato uno XMLSchema, che e possibile trovare

nell’appendice F.

1 < i p a d d r e s s l i s t>2 <i paddre s s date=”2011−03−01” v i s i t s=”27”>212 . 103 . 194 . 66</ ipaddre s s>3 <i paddre s s date=”2011−03−01” v i s i t s=”30”>212 . 103 . 194 . 162</ ipaddre s s>4 <i paddre s s date=”2011−03−01” v i s i t s=”1”>82 . 60 . 183 . 131</ ipaddre s s>5 <i paddre s s date=”2011−03−01” v i s i t s=”1”>81 . 114 . 144 . 171</ ipaddre s s>6 <i paddre s s date=”2011−03−01” v i s i t s=”1”>151 . 4 7 . 5 6 . 7 9</ ipaddre s s>7 <i paddre s s date=”2011−03−01” v i s i t s=”1”>81 . 114 . 244 . 126</ ipaddre s s>8 <i paddre s s date=”2011−03−01” v i s i t s=”4”>151 . 1 3 . 7 4 . 2 0</ ipaddre s s>9 <i paddre s s date=”2011−03−01” v i s i t s=”1”>78 . 1 4 . 6 2 . 3 5</ ipaddre s s>

10 <i paddre s s date=”2011−03−01” v i s i t s=”1”>89 . 1 89 . 3 4 . 7 0</ ipaddre s s>11 </ i p a d d r e s s l i s t>

Listing 3.2: Esempio di xml creato dalla conversione di un file di log

pagina 33 di 83


3.2.7 La classe Finder

La classe Finder e quella che contiene l’implementazione dei metodi che si occupanodi reperire le informazioni dai servizi online.

Nell’implementazione della classe e stato utilizzato il pattern singleton, dato chesi aveva la necessita che ci fosse un’unica istanza di tale classe. La classe contiene unriferimento ai vari parser (XML e HTML) dato che deve estrarre informazioni da talifonti.

In particolare per reperire le informazioni di localizzazione geografica e stato utiliz-zato il servizio fornito da IPINFODB.COM (vedere E.1). Per il nome dell’intestatariodell’indirizzo IP invece e stata fatta una chiamata al webservice del RIR europeo(vedere E.2).

Tali classi necessitano di parametri per impostare la connessione. E’ stato sceltodi salvare tali parametri in un file XML esterno, in modo da poter essere modificatiin un secondo momento.

Concorrenza della classe Finder

Ogni Web Request effettuata dalla classe finder e eseguita da un thread autonomo.In tal modo l’applicazione e in grado di eseguire piu richieste web contemporanea-mente. Il massimo numero di richieste concorrenti e inoltre a discrezione dell’utentefinale, che puo modificarlo come “opzione” dell’applicazione. Lo schema dell’imple-mentazione di tale concorrenza e visibile in figura 3.15.

Figura 3.15: Schema della concorrenza della classe finder

La concorrenza funziona in questo modo: alla pressione del pulsante cerca daparte dell’utente, il programma recupera la lista di IP su cui cercare le informazioni.

pagina 34 di 83


Quindi e avviato un timer, la cui frequenza di clock e regolata in base a quanto sceltodall’utente nelle opzioni.

Il timer e necessario perche i servizi online richiedono che il numero di richiesteweb per intervallo di tempo sia inferiore a una data soglia (vedi appendice E.1 e E.2).

A ogni scadenza del timer e generato un nuovo thread che si occupa di eseguire lawebrequest necessaria al reperimento delle informazioni per un indirizzo IP.

Per controllare la fine della ricerca, un thread si occupa di tenere sotto controllo ithread generati dal timer.

Inoltre solo un dato numero di thread puo eseguire richieste concorrenti. Quandoil limite viene raggiunto i nuovi thread generati allo scoccare del clock del timer ri-mangono in stato di wait() finche non ci si porta di nuovo sotto il numero massimodi richieste concorrenti.

Tale numero massimo (e la possibilita di annullare tale controllo) e impostabilenella schermate delle opzioni (vedi figura 3.18) dell’applicazione.

Quando la ricerca e completata sempre questo thread si occupa di attivare tuttequelle attivita necessarie alla visualizzazione e alla persistenza dei dati.

E’ stato quindi implementato all’interno della classe finder un sistema di gestionedella concorrenza per poter tener sotto controllo tutti i vari thread durante l’esecuzionedel programma. Particolare attenzione e stata posta al meccanismo di wait() e notify()e alla gestione dei lock.

In ogni caso un riferimento a ogni thread generato durante una ricerca e sempremantenuto in una lista. In questo modo si ha sempre il controllo e la possibilita diaccedere ad ogni thread.

3.2.8 La classe DBManager

La classe DBmanager e quella che si occupa di fornire un’interfaccia tra il databasee il resto dell’applicazione. Tale classe implementa l’interfaccia IDBManager.

L’interfaccia serve allo scopo di consentire un futuro passaggio ad altro tipo didatabase, cambiando solo l’implementazione dei metodi e mantenendone invariate lefirme.

In sostanza il compito di tale classe e quello di ricevere delle query sul database eritornare una lista di oggetti (Entita) valorizzata con i dati presenti all’interno del DBe viceversa. Anche in questo caso le dimensioni del database possono essere notevolie quindi e stato fatto tutto un lavoro di ottimizzazione in modo da aumentarne leperformance (vedere la sezione 3.3).

pagina 35 di 83


3.2.9 La classe Registrator

La classe Registrator e quella che si occupa di effettuare tutte quelle operazioniche consentono di verificare che l’utente sia in possesso di una licenza valida perl’applicazione.

Il metodo per registrare l’applicazione funziona in questo modo:

- L’utente deve fornire il MAC Address di una delle schede di rete del dispositivosu cui verra istallato il prodotto;

- Viene calcolata a partire dal MAC Address e consegnata all’utente la chiave diregistrazione;

- Ad ogni avvio l’applicazione controlla se la chiave di registrazione e stata inserita,altrimenti la richiede.

Strategia registrazione con chiavi di licenza

Al di fuori dei requisiti indicati precedentemente, al prodotto sono state aggiuntemolte caratteristiche di raffinamento. Tra le funzionalita sviluppate vi e il sistemaa chiave pubblica per l’utilizzo della versione completa del prodotto. Bisogna fareuna premessa, il prodotto nasce come applicazione venduta ai clienti Sanmarco chedesiderano usufruirne delle funzionalita. Si e deciso pero di pubblicare tale prodottosul catalogo web del sito Sanmarco, direttamente scaricabile da tutti i clienti.

Solamente i clienti che acquisteranno una chiave di licenza dall’azienda pero po-tranno usufruire appieno delle funzionalita di Profilatore. Infatti la versione scaricatadel prodotto e il pacchetto completo, che pero viene pesantemente limitato nell’utilizzoqualora lo si utilizzi in versione di prova.

Al primo avvio dell’applicazione verra presentata una finestra che chiede all’utentese desidera usufruire della versione di prova oppure di inserire il codice di registrazionedell’applicazione.

Versione di prova

Prima di tutto qualora non si registri la chiave per la versione completa vieneautomaticamente scritta sul registro di sistema una chiave per la versione di prova.

Questa chiave e necessaria poiche la versione di prova e solo temporanea, delladurata di 15 giorni, al di fuori di questa scadenza non sara piu possibile in alcun modoutilizzare la versione di prova.

E’ stato poi volutamente deciso che la chiave della versione di prova non vengarimossa alla disinstallazione del programma. Questa scelta contribuisce in negativo asporcare il registro di sistema con informazioni inutili, pero in positivo e l’unico modoper assicurarci che una volta scaduto il limite temporale la versione di prova non siapiu utilizzabile neppure installando e disinstallando il software.

Principalmente la versione di prova presenta una limitazione di visualizzazione disolo 5 dei risultati rivenuti, e l’impossibilita di esportare tali risultati in alcun formato.Inoltre il database delle informazioni e cancellato ad ogni riavvio.

pagina 36 di 83


Registrazione del prodotto

La registrazione del prodotto e stata progettata tramite un sistema di cifratura achiave pubblica, RSA.

Algoritmo RSA

L’algoritmo che e stato utilizzato per il sistema di cifratura e l’algoritmo RSA, ilcui acronimo deriva dalle iniziali del cognome dei 3 ricercatori del MIT che lo hannoinventato , Ronald Rivest, Adi Shamir e Leonard Adleman. Gli algoritmi a chiavepubblica nascono con la necessita di poter diffondere le chiavi di decifratura pubblica-mente, senza correre il rischio che questo comprometta l’intero sistema di criptaggio.Nel 1970 circa I sistemi di cifratura erano solidi ma tutti a chiave privata e una voltache la chiave veniva rubata l’intero sistema di cifratura era compromesso e dovevaessere cambiato.

L’algoritmo RSA si basa sulla complessita della fattorizzazione dei numeri primi.Funziona in questo modo:

Vengono scelti a caso 2 numeri primi abbastanza grandi ( p) e ( q), si calcolano poi:

n = p ∗ q

e

z = (p− 1) ∗ (q − 1)

Poi si sceglie un numero primo rispetto a z chiamato d, e infine si calcola un e taleche:

e ∗ d = 1mod(z)

La chiave pubblica che ci interessa e (n, e) mentre la chiave privata e (n,d).

Il parametro d e difficilmente calcolabile da e, proprio perche oltre a conoscere ne necessario conoscere z, che implicherebbe la fattorizzazione , ossia il calcolo di tuttiI divisori di n, operazione molto lunga e dispendiosa. Una volta ottenute le nostrechiavi pubbliche e private, e possibile criptare qualunque messaggio e fornire la chiavepubblica per la decifratura in questo modo: il messaggio viene cifrato con la chiavepubblica e ottenendo

c = memod(n)

Successivamente per la decifratura del messaggio si esegue lo stesso procedimentoma con la chiave privata d, ossia

m = cdmod(n)

pagina 37 di 83


All’interno del programma da me sviluppato il codice contenente la chiave pubblicae quello dell’applicazione che viene venduta, mentre il codice contenente la chiaveprivata e contenuto all’interno della soluzione che genera le chiavi di licenza e che eposseduta solo da Sanmarco.

Chiaramente la chiave non e univoca, altrimenti basterebbe la pubblicazione onlinedi una qualunque chiave di licenza del programma per permettere il funzionamento sualtri PC.

Abbiamo quindi deciso di scegliere come strategia alla base della chiave di licenzal’indirizzo MAC della macchina su cui sara installato il programma.

Il sistema e stato cosı progettato: un cliente che acquista una licenza per il softwaredovra comunicare alla Sanmarco l’indirizzo MAC della macchina su cui verra installatoil software.

L’azienda inserendo l’indirizzo MAC nel generatore di chiavi, utilizzera l’algoritmoRSA a chiave pubblica per cifrare il codice MAC. Il messaggio da cifrare e dunquel’indirizzo MAC del cliente, che viene inviato al centro clienti Sanmarco, viene cifratoe ritornato al cliente, che deve inserirlo nella form di registrazione per decifrarlo everificarne la validita. Vedi figura 3.16.

L’utilizzo dell’indirizzo MAC come parametro per la generazione delle chiavi fa sıche oltre ad essere sicuro la strategia di sicurezza sia unica per ognuna delle macchinesu cui si desidera installare l’applicativo.

Figura 3.16: Immagine del generatore di chiavi

3.2.10 L’interfaccia Exporter

L’interfaccia Exporter, e tutte le sue realizzazioni sono quelle che consentono diesportare in vari formati le informazioni memorizzate nel database dell’applicazione.

I formati di output consentiti sono:

- Tabella HTML. La tabella HTML e dotata di un foglio di stile per una visual-izzazione piu gradevole;

- XSLX, il formato di Microsoft Excel 2007 o superiore;

- CSV (Comma Separated Values) un formato compatibile con tutti i piu diffusifogli di calcolo

- PDF (Portable Document Format);

pagina 38 di 83


- Cartaceo. L’applicazione si interfaccia nativamente con le stampanti di sistemae produce la stampa della tabella su carta.

3.2.11 Interfaccia Grafica

Tutte le classi che rappresentano l’interfaccia grafica ereditano dalla classe “For-m” del framework .NET. L’interfaccia grafica e multithreaded, ossia la gestione deglieventi generati dall’interfaccia grafica e eseguita da un nuovo thread. Questo consenteall’interfaccia grafica di rimanere reattiva alle azioni dell’utente.

Per il disegno dell’interfaccia grafica e stato usato lo strumento Designer di VisualStudio, che si preoccupa di scrivere automaticamente tutto il codice necessario.

Uno screenshot dell’interfaccia grafica della versione finale dell’applicazione e visi-bile nella figura sottostante.

Figura 3.17: Schermata principale di Profilatore

Mappa interna per la localizzazione dei risultati

A prodotto ultimato e concluso, dopo una revisione con i committenti e lo staffcommerciale Sanmarco, uno dei soci anziani ha espresso la volonta di inserire (se

pagina 39 di 83


questo non fosse stato troppo oneroso in termini di tempo) una mappa all’interno delprogramma per la localizzazione geografica dei risultati ottenuti.

Per questo tipo di richiesta sono dovuto ricorrere all’utilizzo del servizio di local-izzazione piu conosciuto in rete, ossia quello offerto da Google Maps.

Da subito il mio interesse si e concentrato sulle Google Static Maps API, cheforniscono mappe statiche convertibili in immagini jpeg e sono estremamente rapide,l’ideale per inserirle all’interno di una form di un’applicazione Windows.

Il problema delle mappe statiche, a parte la loro staticita e l’impossibilita di effet-tuare zoom in real time, era che la conversione a jpeg e l’inserimento in una form nonsempre andavano a buon fine.

A questo punto si e optato per le Google Maps Javascript API, che fornivanomappe dinamiche molto piu interessanti rispetto a quelle statiche.

All’interno del Framework 4 .Net e presente una classe WebBrowser che permetterendere una form un browser per la navigazione in internet, e quindi anche permettedi interpretare il Javascript. E’ stato usato quest’ultimo per visualizzare la mappavisibile in figura 3.17.

Il codice javascritp necessario alla visualizzazione della mappa e visibile nell’ap-pendice I.

Schermata delle Opzioni

Come detto precedentemente uno dei requisiti del programma era di essere flessibilee personalizzabile.

Figura 3.18: Schermata delle opzioni

Per ottenere questo obiettivo si e dotato il programma di una schermata di im-postazione delle opzioni visibile in figura 3.18.

Queste opzioni sono:

- Il numero di connessioni temporanee: Come illustrato nella figura 3.15 vengonoeffettuate richieste web in maniera concorrente. Questo pone in limite al numeromassimo di thread simultanei;

- Frequenza di Richiesta: e l’intervallo di clock del timer nella figura 3.15;

pagina 40 di 83


- Valida XML: consente all’utente di validare gli input in formato xml con glischema riportati nell’appendice F;

- Metodo di ricerca nome organizzazione: Consente di variare lo sorgenti delleinformazioni: vedere appendice E.2.

3.2.12 Interfaccia da Riga di Comando

L’applicazione e stata datata di un’interfaccia da riga di comando. Questo percheera desiderabile che l’applicazione potesse operare in modalita batch, cioe che prenderedall’utente le informazioni come la cartella dove si trovano i file contenenti le liste diIP da cercare e la cartella di output dove si desidera venga scritto il file risultatodell’esportazione.

Una volta avviata l’applicazione procede automaticamente e l’operazione si con-clude con la scrittura di un file nel formato scelto precedentemente contente le infor-mazioni recuperate.

Un esempio di tale modalita operativa e visibile nelle figure 3.19 e 3.20.

Figura 3.19: “Help” da linea di comando

Figura 3.20: Schermata che appare dopo una ricerca da linea di comando

pagina 41 di 83

3.3. FASE DI OTTIMIZZAZIONE CAPITOLO 3. LO STAGE

3.3 Fase di Ottimizzazione

La fase di ottimizzazione e stata una delle ultime fasi dello sviluppo dell’appli-cazione. In questa fase si e utilizzato lo strumento di analisi delle prestazioni integratoin Visual Studio (vedi appendice D.1.1). Tramite questo strumento e stato possibileindividuare tutte quelle parti del codice critiche a livello di performance ed intervenireper migliorare la situazione.

Tale strumento fornisce diverse modalita di analisi (vedi appendice D.1.1) delleprestazioni. Quella che e stata utilizzata in questo caso e il calcolo della percentualedi utilizzo del processore.

Un esempio di una sessione di analisi delle prestazioni e visibile nella figura 3.21.

Figura 3.21: Schermata che appare dopo una sessione di analisi delle prestazioni

pagina 42 di 83

CAPITOLO 3. LO STAGE 3.3. FASE DI OTTIMIZZAZIONE

Come si puo vedere in figura 3.21 viene presentato un grafico che mostra la per-centuale di utilizzo del processore. E’ possibile ingrandire questo grafico nei puntidesiderati. In basso vengono mostrati i metodi impiegati in quel lasso di tempo e laloro percentuale di utilizzo della CPU. Un dettaglio della visualizzazione del consumoper metodo e visibile nell’immagine 3.22.

Figura 3.22: dettaglio della fase di analisi delle prestazioni

Cliccando su uno dei riquadri contenenti il nome di un metodo si verra portatiall’interno del codice del metodo e verra mostrato per ogni istruzione la percentualedi tempo utilizzata.

3.3.1 Risultati della fase di Ottimizzazione

In particolare, durante la fase di ottimizzazione sono state individuate 3 areecritiche nel codice dell’applicazione:

- Nel metodo che si occupava di inserire all’interno del database la lista di indirizziIP da ricercare. Alla fine questo si e rivelato essere un problema di utilizzo deldatabase. Con un piccolo studio delle modalita di connessione e del meccanis-mo delle transazioni di SQLite si e risolto il problema, arrivando a dei tempiaccettabili.

- Nel metodo che si occupava di eseguire la conversione del file .log nel forma-to XML. Il problema in questo caso si e rivelato essere un’errata gestione delmeccanismo delle eccezioni.

- Nel metodo che si occupava di generare il file Excel durante la fase di esportazionedei dati (vedi figura 3.13). In questo caso il problema era la complessita dell’algo-ritmo. Per un’errore di implementazione, una parte del metodo aveva complessitacubica (vi erano 3 cicli for innestati che scorrevano la stessa lista). Purtroppo tale

pagina 43 di 83

3.3. FASE DI OTTIMIZZAZIONE CAPITOLO 3. LO STAGE

componente non era stato realizzato dal sottoscritto. E’ stato quindi necessariouno studio approfondito della classe in questione, al fine di capire il meccanismodi generazione del file Excel. Alla fine si e giunti a una complessita lineare.

Una parte importante nella fase di ottimizzazione e stata l’utilizzo intensivo diPLINQ (vedi appendice B.6) per tutte le operazioni su liste di oggetti. Questo haportato a un’ulteriore speedup dell’applicazione in generale ma sopratutto ha resol’applicazione scalabile, nel senso che sara in grado di sfruttare al meglio la potenzafornita dalle moderne CPU multi-core.

pagina 44 di 83

CAPITOLO 3. LO STAGE 3.4. INTEGRAZIONE CON EXTRACTOR

3.4 Integrazione con Extractor

Parallelamente allo svolgimento del mio stage, alla Sanmarco veniva svolto unaltro stage, il cui progetto era la realizzazione di un software (denominato Extractor)in grado di collegarsi alle banche dati di vari elenchi telefonici online (es: PagineGialle,PagineBianche, 1254 . . . ) e estrarne i dati.

Dato che e stato ritenuto interessante che una volta recuperato il nome di unvisitatore si un sito web tramite l’applicazione da me sviluppata fosse possibile ricercalasugli elenchi suddetti, e stata eseguita un’integrazione con il software Extractor (vedifigura 3.23).

Fortunatamente tale integrazione e stata rapida e ottenuta con relativamente pocosforzo (nella programmazione).

L’integrazione e avvenuta in questo modo. Una volta selezionato il visitatore sulquale si desidera cercare le informazioni, tramite un menu contestuale e possibileavviare Extractor, che si occupa di effettuare la ricerca.

I parametri necessari alla ricerca sono passati da un applicazione all’altra attraversoargomenti su linea di comando.

Il sistema e certamente un po rudimentale ma ha permesso un rapido svolgimentodella fase di integrazione delle 2 componenti.

Figura 3.23: Screenshot dell’applicazione Extractor

pagina 45 di 83

3.5. RISULTATI FINALI CAPITOLO 3. LO STAGE

3.5 Risultati finali

Il risultato finale e stata un’applicazione pienamente funzionante. Tutti i requisitisono stati soddisfatti. L’applicazione si e mostrata affidabile, flessibile e performante,anche se appoggiandosi a servizi di terze parti potrebbe necessitare di alcuni updatefuturi per poter continuare a funzionare.

.NET si e rivelato essere uno strumento potente e intuitivo, che permetteva conrelativo poco sforzo di ottenere grandi risultati.

Anche Visual Studio si e mostrato uno strumento notevole, sopratutto per le suecapacita di code generation (in particolare vedi l’appendice D), che permettevano diconcentrarsi sui task effettivamente da svolgere e non perdere tempo sui dettagli dellaprogrammazione.

Anche la documentazione fornita e di una quantita e qualita impressionante. Lasi trova spesso tradotta in Italiano. Quando non e presente la traduzione la lingua el’Inglese.

Inoltre Ogni Classe, Metodo, Proprieta e Tecnologia all’interno del frameworke corredata da un numero impressionante di esempi e tutorial che rendono la vitaveramente facile al novizio nella programmazione .NET.

Una critica che puo essere rivolta all’intero sistema Microsoft, almeno per la partedi sviluppo software, e quella della scarsa attenzione alla compatibilita e retrocompat-ibilita, anche all’interno dei suoi stessi prodotti.

L’applicazione infatti, oltre a non essere portabile, in quanto eseguibile solamenteall’interno del sistema operativo proprietario di Microsoft, e difficilmente compatibilecon sistemi anche solo leggermente datati o comunque diversi da quelli dove e statacompilata l’applicazione.

Inoltre alcune (poche ma per certi versi fondamentali) librerie fornite all’internodel framework .NET sono non aggiornate e veramente poco performanti, obbligandolo sviluppare ad adottare soluzioni di terze parti esterne al framework, in perfettodisaccordo con la filosofia di Microsoft del “mondo chiuso in se stesso” secondo laquale bisognerebbe utilizzare solo i suoi prodotti.

pagina 46 di 83

Capitolo 4

Conclusioni

4.1 Stage

Il giudizio finale che do all’esperienza di stage e sicuramente molto positivo.

Inserirmi in una realta aziendale e stata per me un’esperienza incredibilmenteformativa ed emozionante. Mi sono ritrovato in un mondo pieno di stimoli e sopratut-to circondato da gente competente e disponibile, che ha sicuramente aiutato la miacrescita professionale e personale.

Certamente il dover discutere e confrontarsi con gli altri, il sottostare alle scadenzee alle direttive dei propri responsabili e una parte fondamentale dello sviluppo di unapersona.

A tale riguardo l’ambiente lavorativo della Sanmarco Informatica e sicuramente unambiente schietto, sincero e recettivo alle novita; inoltre l’aver lavorato fianco a fiancocon persone della mia stessa eta mi ha aiutato molto.

Ho imparato ad utilizzare Visual Studio e gli strumenti che offre il framework.NET, ho imparato a eseguire delle richieste web tramite un web-service e sono venu-to a conoscenza di nozioni che prima mi erano quasi del tutto estranee (Injection,Reflection, Servlet,. . . ).

Inoltre ho avuto modo di vedere come funzionano le altre aree dell’informatica,diverse dal puro sviluppo quali la progettazione ed il mantenimento di database, ilsystem management e la business intelligence.

4.2 Metodo di lavoro

All’inizio ero molto titubante e mostravo alcune perplessita sull’adozione dellametodologia di sviluppo Agile ,che conoscevo ben poco, sulla scelta di C# come lin-guaggio di programmazione e sopratutto sulla scelta di Microsoft Windows (e quindiVisual Studio) come ambiente di sviluppo.

47

4.2. METODO DI LAVORO CAPITOLO 4. CONCLUSIONI

Questi dubbi erano il retaggio delle precedenti esperienze universitarie di sviluppodi progetti, svolti per lo piu in ambiente Linux e con strumenti free e open source,quali a titolo esemplificativo Java ed Eclipse.

Ho dovuto presto ricredermi: non solo il framework .NET e potente e pieno dirisorse e C# un linguaggio a oggetti evoluto e flessibile, ma Visual Studio e un ambientedi sviluppo performante e innovativo sotto innumerevoli punti di vista.

Le due funzionalita che piu mi hanno impressionato (e di cui parlo in manieraapprofondita nell’appendice B) sono:

- l’incredibile capacita di databindig – ossia l’automazione che consente di vi-sualizzare su griglie e form le proprieta degli oggetti –fornita dal framework ecompletamente integrata nel designer di Visual Studio (vedi appendice B.7);

- la componente plinq che consente di sfruttare le moderne CPU multi-core inmaniera trasparente e senza sforzi aggiuntivi di gestione dei thread (vedi appen-dice B.6).

Anche grazie a questo i requisiti stilati in fase di analisi sono stati tutti pienamentesoddisfatti. L’obiettivo finale era di ottenere un’applicazione funzionante e pronta alrilascio e cio e avvenuto.

Mi preme sottolineare che lo sviluppo dell’applicazione di certo non si fermera qui,dato che il prodotto presto entrera nei canali di vendita della Sanmarco, e alcuni clientihanno gia richiesto delle personalizzazioni del prodotto.

Cio mi rende ancora piu felice del lavoro svolto perche ritengo che in fondo loscopo di ogni software e quindi lo scopo di tutto il lavoro di sviluppo che sta dietro larealizzazione di un programma e (al di la della semplice rimunerazione economica) ilsuo utilizzo. Senza questo il tutto rimane privo di significato.

Non c’e stato ritardo nei tempi previsti inizialmente; questo a indicare che il lavorosvolto in fase di analisi e stato accurato. Cosı il lavoro e potuto procedere in maniera(quasi) priva di intoppi.

Nonostante le mie perplessita iniziali la metodologia di sviluppo scelta (Agile) estata vincente e ha permesso di dominare la complessita del progetto. L’aver suddivisoil lavoro in piu step e le revisioni settimanali con i responsabili mi hanno permesso difissare obiettivi precisi e di portarli a termine con determinazione.

L’elemento chiave della riuscita dello stage e stata la mia iniziale motivazione equesto e stato certamente uno degli elementi chiave alla riuscita del progetto.

Fin dal primo giorno sono stato coinvolto nel processo di sviluppo e durante tuttol’arco di tempo dello stage, sono stato spinto a tirar fuori il meglio. La mia libertadi azione e stata molto ampia e mi e stato permesso di prendere molte delle scelteprincipali in autonomia.

pagina 48 di 83

CAPITOLO 4. CONCLUSIONI 4.3. UNIVERSITA

4.3 Universita

Quest’esperienza mi ha permesso di mettere alla prova quanto imparato durantegli studi universitari e di scontrarmi con un mondo, quello Microsoft, che mi era quasidel tutto sconosciuto.

Quanto appreso all’universita mi ha permesso di adattarmi velocemente e di im-parare in maniera rapida l’utilizzo di quei nuovi linguaggi di programmazione e stru-menti di configurazione e controllo necessari allo sviluppo.

Sono stato in grado di arrivare a padroneggiare relativamente in poco tempo illinguaggio C#, il framework Microsoft .NET e tutti gli strumenti necessari.

Cio a dimostrazione che la scelta di C++ e Java come linguaggi ad alto livellousati nei corsi universitari e vincente, in quanto permette di avere una chiara visionedei meccanismi principali di tutti i linguaggi ad oggetti.

Questo non toglie che il programma dei corsi deve rimanere sempre aggiornato enon adagiarsi sugli allori di linguaggi oramai affermati.

Uno scorcio su nuove prospettive non farebbe di certo male alla visione generaledello studente (cito a titolo di esempio Scala, un linguaggio relativamente recente e dicui si parla poco nell’ambito del corso di laurea triennale in informatica).

La distanza da quanto richiesto dallo stage e le conoscenze da me possedute allafine del mio percorso di studi e risultata piuttosto ampia ma questa era una cosa chemi aspettavo data la vastita del campo dell’informatica.

In ogni caso il mio tutor mi ha seguito e ha subito messo in atto una fase diformazione atta a colmare le lacune (inevitabili) della mia formazione universitaria.

Cio che a parer mio conta veramente, e che un corso di laurea prepari la personaad affrontare le sfide che inevitabilmente si trovera di fronte una volta entrato nelmodo del lavoro; deve insegnare il funzionamento “generale” delle cose (certamenteattraverso lo studio particolare di alcuni determinati strumenti) in modo da non las-ciare troppo “spiazzato” l’ex studente di fronte alle novita, che in un mondo comequello dell’informatica, che e in costante cambiamento, sono inevitabili.

Una parte dove sicuramente sono risultato essere carente (e che per fortuna mi eservita poco durante la mia attivita di stage) e quella relativa alla configurazione direti.

Ritengo che cio sia dovuto piu che altro a una carenza dell’insegnamento sul latopratico piu che su quello teorico. Infatti, la mancanza di laboratori e progetti sullagestione di reti di computer impatta negativamente sulla preparazione finale.

Certo la preparazione teorica e di fondamentale importanza: se non sai come fun-ziona un martello, non riuscirai a piantare un chiodo. Tuttavia senza l’adeguatapreparazione pratica, finirai inevitabilmente per schiacciarti un dito.

A tale proposito certamente sono stati fondamentali tutti i progetti che sono semprestati affiancati agli esami e mi sento in dovere di ringraziare tutti i professori che si

pagina 49 di 83

4.3. UNIVERSITA CAPITOLO 4. CONCLUSIONI

sono ingegnati per pensare progetti che fossero adatti alle nostre capacita e tuttaviafonte di stimolo per la scoperta e lo studio di nuovi strumenti.

Solo dovendo mettere in pratica la parte teorica dell’insegnamento ci si puo scon-trare veramente con le problematiche reali e apprezzare la differenza abissale cheintercorre tra il sapere e il saper fare.

Voglio ancora sottolineare l’importanza che ha la pratica in una disciplina come lanostra. Il mondo del lavoro abbisogna di persone che sono si preparate ma sopratutto,che sappiano dare risposte concrete ai problemi che vengono posti.

La stessa attivita di stage esterno e, ovviamente, un ottimo modo per agevolarel’inserimento degli studenti nel mondo del lavoro. Questo non solo nel caso in cui lostagista continui a collaborare con l’azienda ospitante, ma anche come pura formazionepersonale e professionale.

Concludendo, ritengo in particolare che gli esami di Basi di Dati, tutti quelli di Pro-grammazione – che partendo dai linguaggi procedurali di piu basso livello ci portanoa comprendere le piu complesse strutture della programmazione ad oggetti e di quellaconcorrente – e per ultimo, ma non ultimo, l’esame di Ingegneria del Software checonsentendo allo studente di scontrarsi con progetti proposti direttamente da aziende(una sorta di pre-stage) e con le problematiche reali dello sviluppo software svolge unaparte fondamentale nella formazione di uno studente al fine dell’inserimento in unarealta lavorativa.

Non manco di menzionare anche tutti gli esami che si discostano dall’informaticaintesa come puro sviluppo di software e che hanno avuto una trattazione piu teoricacome l’esame di Algoritmi e Automi e Linguaggi Formali e tutti gli studi prettamentescientifici come gli esami di Matematica e quello di Fisica.

Tutto questo contribuisce a formare un substrato fertile dove risulta facile per tuttequelle nozioni che e necessario imparare, per potersi inserire con successo nel mondodel lavoro e nella vita in generale, attecchire.

pagina 50 di 83

Appendice A

Il database SQLite

Figura A.1: System.Data.SQLite, un provider ADO.NET Open Source per SQLite

SQLite e una libreria software scritta in linguaggio C che implementa un DBMSSQL di tipo ACID incorporabile all’interno di applicazioni. Il suo creatore, D. RichardHipp, lo ha rilasciato nel pubblico dominio, rendendolo utilizzabile quindi senza alcunarestrizione. SQLite permette di creare una base di dati (comprese tabelle, query, form,report) incorporata in un unico file.

SQLite non e un processo stand-alone utilizzabile di per se, ma puo essere incor-porato all’interno di un altro programma. E utilizzabile con il linguaggio C/C++,ed esistono binding anche per altri linguaggi. Per quel che concerne il nostro caso epresente e distribuita gratuitamente una libreria per .NET (System.Data.SQLite) checonsente l’accesso al Database tramite stringhe di connessione.

A.1 Caratteristiche e limitazioni

Sebbene sia molto pratico, semplice da usare e il setup e praticamente istantaneo,SQLite presenta anche degli svantaggi legati alla sua natura di database stand-alonesu un solo file. Di seguito una breve lista dei vantaggi e degli svantaggi piu significativiper lo sviluppo del progetto in oggetto.

A.1.1 Vantaggi

La libreria offre molte interessanti caratteristiche:

- e compatta (meno di 500KB per l’intera libreria);

51

A.1. CARATTERISTICHE E LIMITAZIONI APPENDICE A. IL DATABASE SQLITE

- e molto veloce; in molti casi piu di MySQL e PostgreSQL;

- il codice sorgente e liberamente disponibile, chiaro e ben commentato;

- e in grado di interpretare stringhe SQL; a differenza di altre librerie simili,supporta buona parte dello standard SQL92;

- l’API e semplice da utilizzare;

- ha transazioni atomiche, consistenti, isolate e durabili (ACID), anche in caso dicrash di sistema o blackout;

- e multipiattaforma;

- include un programma di utilita a riga di comando [height=60mm]per accedereal database anche manualmente (come su MySQL, Postgresql e tanti altri DB) otramite scripting;

- il database consiste di un unico file, il cui formato interno e indipendente dallapiattaforma e dal relativo ordine dei byte;

- gestione flessibile dei tipi di dati: ogni campo puo contenere qualsiasi tipo didato.

A.1.2 Svantaggi

- non offre le stored procedure;

- non implementa il meccanismo di controllo sui vincoli di chiave esterna;

- non prevede la gestione dei permessi d’accesso, demandata al software con cui siinteragisce con il database e/o al meccanismo dei permessi del file system;

- non ha una vera gestione della concorrenza: le applicazioni che lo utilizzano, senecessario, devono implementarla;

- per garantire la coerenza del file del database sono usati i lock del file sys-tem, e quindi vi possono essere problemi qualora quest’ultimo non li implementicorrettamente, ad esempio con file system di rete (come NFS);

- non offre alcuna cache per le query (e non ne ha la possibilita, non esistendo unprocesso server centrale);

- non ha protocolli di rete, non essendo utilizzabile come programma a se; e possi-bile utilizzare un database remoto, ma solo tramite file system di rete del sistemaoperativo, con prestazioni difficilmente accettabili;

- non supporta alcuni importanti costrutti SQL quali RIGHT JOIN e FULL OUT-ER JOIN;

- non supporta le sottoquery variabili;

- non consente l’inserimento multiplo di righe, ma ogni riga deve essere inseritacon un’istruzione INSERT a se stante. Cio impatta molto sulle performancedelle istruzioni di INSERT.

pagina 52 di 83

Appendice B

Il framework Microsoft .NET

Figura B.1: Struttura ad alto livello del framework Microsoft .NET

La suite di prodotti .NET e un progetto all’interno del quale Microsoft ha creatouna piattaforma di sviluppo software, .NET, la quale e una versatile tecnologia diprogrammazione ad oggetti. La versione utilizzata nel progetto e la 4.

Microsoft ha sviluppato .NET come contrapposizione proprietaria al linguaggioJava (che e open source) e attribuisce un ruolo strategico al lancio di .NET comepiattaforma di sviluppo per applicazioni desktop e server.

B.1 Caratteristiche principali

La prima versione di .NET e stata rilasciata nel 2002. La sua caratteristica pecu-liare e di essere indipendente dalla versione operativa di Windows su cui e installata,

53

B.2. IL LINGUAGGIO C# APPENDICE B. IL FRAMEWORK MICROSOFT .NET

e di includere molte funzionalita progettate espressamente per integrarsi in ambi-ente internet e garantire il massimo grado di sicurezza e integrita dei dati. Utilizzain modo esteso il concetto di modularita dei componenti software (Component Ori-ented Programming), proponendosi cosı come evoluzione dell’esistente modello COM(Component Object Model).

La CLR (Common Language Runtime) e un insieme di librerie che, insieme allaclasse di librerie di base denominata FCL (Framework Class Library), e progettataper poter funzionare con qualsiasi sistema operativo.

Il compilatore Just In Time esegue un codice assembly denominato CIL (CommonIntermediate Language). E inoltre possibile: accedere a componenti scritti in altrilinguaggi; quando il sistema operativo sottostante e Microsoft Windows, accedere aisuoi servizi e alle sue API; accedere ai Servizi Web utilizzando il protocollo SOAP.

B.2 Il linguaggio C#

Il C# (si legge C sharp) e un linguaggio di programmazione object-oriented svilup-pato da Microsoft all’interno dell’iniziativa .NET, e successivamente approvato comestandard ECMA. La sintassi del C# prende spunto da quella del Delphi (hanno ilmedesimo autore, ovvero Anders Hejlsberg), del C++, di Java e di Visual Basic pergli strumenti di programmazione visuale e per la sua semplicita (meno simbolismorispetto a C++, meno elementi decorativi rispetto a Java).

B.3 Differenze con il C/C++

In confronto al C o al C++ il linguaggio ha subito una serie di modifiche volteprincipalmente ad evitare errori tipici e ambiguita della programmazione C:

- I puntatori possono essere utilizzati solo in particolari blocchi di codice marcaticome unsafe;

- In molte operazioni aritmetiche vengono controllati eventuali overflow;

- Gli oggetti dinamici non vengono deallocati esplicitamente; la loro rimozioneviene gestita automaticamente (implicitamente) dal garbage-collector quando nonesistono piu riferimenti a tali oggetti. Questa gestione evita i due problemi bennoti dei dangling pointer e del memory leak, anche se con un’ovvia riduzione delleprestazioni.

- Come in Java, e possibile ereditare da una sola classe (diversamente da quantoavviene in C++) ma e possibile implementare un numero indefinito di interfacce.

- Le sole conversioni implicite consentite sono quelle safe, ovvero che non espongonoal rischio di perdita di dati causata dalla diversa tipologia di dato. Ad esempionon sono consentite conversioni implicite fra integer e boolean o fra enumerati edinteger.

- C# non possiede i template (tipici del C++) ma nella versione 2.0 sono statiintrodotti i generic tipici di Java.

pagina 54 di 83

APPENDICE B. IL FRAMEWORK MICROSOFT .NET B.4. DIFFERENZE CON JAVA

B.4 Differenze con Java

Sebbene C# sia ritenuto simile a Java, esistono alcune importanti differenze fra idue linguaggi:

- Java non ha costrutti specifici per definire le proprieta di una classe (getter esetter);

- Java non permette blocchi di codice unsafe che consentono di gestire i puntatori;

- Java utilizza i commenti Javadoc-sintax per generare la documentazione dalcodice sorgente, mentre C# utilizza la sintassi XML nei commenti per lo stessoscopo;

- C# non obbliga la gestione delle eccezioni (handle or declare), in Java alcuni tipidi eccezioni, le checked exceptions vanno gestite;

- C# supporta gli indicizzatori ed i delegati;

- C# ha la possibilita di dichiarare i metodi virtual tramite l’apposita keywordvirtual; a differenza di Java, dove i metodi sono forzatamente virtual di default.

B.4.1 Package in C#

Come Java, C# ha i suoi package anche nel C# possiamo ritrovare una serie diclassi gia sviluppate per l’interazione con i vari ambienti, Front End, Database, XMLe altri. Tali package consistono di fatto nel .NET framework, del quale C# utilizzauna serie di librerie di classi che permettono l’accesso alle funzionalita del sistema.Quello che in Java e chiamato package in C# viene chiamato namespace o spazio dinomi.

Le classi sono organizzate all’interno di una serie di namespace che raggruppanole classi con funzionalita simili; ad esempio System.Windows.Forms per la gestionedelle finestre di tipo Forms, System.Xml per l’elaborazione di XML e System.Dataper l’accesso alle basi dati.

Un ulteriore livello di organizzazione e costituito dagli assembly. Un assemblypuo essere un singolo file o una serie di file linkati fra di loro. Un assembly puo avereal suo interno diversi spazi di nomi.

B.5 Confronto fra .NET e Java EE

Rispetto a Java, .NET e uno standard ISO riconosciuto (ISO 23270 e ISO 23271).e quindi non e possibile, da parte della casa madre, modificarne la sintassi (a meno didiscostarsi dal proprio stesso standard).

Il Common Language Runtime (CLR), il Common Intermediate Lan-guage (CIL) ed il .NET (C#) sono simili rispettivamente alla Java Virtual Ma-chine, al bytecode e al linguaggio Java della Oracle Corporation, con cui sono inforte concorrenza. Entrambi utilizzano un proprio bytecode intermedio.

pagina 55 di 83

B.5. CONFRONTO FRA .NET E JAVA EEAPPENDICE B. IL FRAMEWORK MICROSOFT .NET

Il bytecode di .NET e progettato per essere compilato al momento dell’esecuzione(just in time compilation detta anche JITting), come il bytecode di Java.

Al momento .NET e compatibile soltanto con le piattaforme Windows, mentreJava e disponibile per tutte le piattaforme. La Java EE (Java Platform, EnterpriseEdition) di Oracle fornisce funzionalita leggermente superiori ad altre tecnologie Mi-crosoft, come COM+ e MSMQ, che lavorano peraltro in modo integrato con i sistemioperativi Windows. .NET fa un uso estensivo ed astratto di tutte queste tecnologieormai consolidate. Inoltre il progetto Mono prevede la portabilita di .Net su sis-temi operativi non windows. Gia attualmente un applicativo compilato con il .Netframework puo funzionare sotto altri sistemi (per esempio Linux) con l’installazionedel framework Mono.

B.5.1 Gestione Dei Thread

La gestione dei thread in .NET differisce leggermete da quella di Java. Tutto vieneeffettuato tramite dei metodi marcati come delegate detti appunto metodi delegati.

In sostanza il framework obbliga il programmatore a scrivere del codice Thread Safeperche e necessario utilizzare i meccanismi di lock sulle risorse integrati nel framework.

Grande attenzione e stata posta all’implementazione Thread Safe dei componentigrafici. In sostanza un componente grafico non puo essere acceduto da un threaddiverso da quello che lo ha istanziato, se non tramite il meccanismo dei metodi delegati,e quindi in maniera intrinsecamente Safe.

Questo approccio se da una parte consente di evitare noiosi errori in fase di proget-tazione e implementazione, porta alla scrittura di codice lungo, ripetitivo e prolisso.Purtroppo l’IDE utilizzato, Visual Studio, ancora non fornisce una funzionalita digenerazione automatica del codice per questo frangente della scrittura del codice.

pagina 56 di 83

APPENDICE B. IL FRAMEWORK MICROSOFT .NET B.6. PLINQ

B.6 PLINQ

Figura B.2: Architettura della Programmazione Parallela .NET

PLINQ (Parallel LINQ) e una estensione parallelizzata del Linguaggio di Query In-tegrato LINQ. Assieme a TPL (Task Parallel Library) compone le Parallel Extensions,una libreria di concorrenza gestita sviluppata in collaborazione tra Microsoft Researche il CLR team. Le performance delle query PLINQ scalano automaticamente a secondadel grado di concorrenza supportato dal computer host.

LINQ e quindi anche la sua implementazione parallelizzata supporta l’inferenza ditipo, che semplifica ulteriormente la scrittura del codice consentendo al programmatoredi non specificare il tipo degli argomenti.

Un costrutto fornito da PLINQ molto usato e quello che opera su liste di oggetti eva a sostituire il tipico forEach(). Tale costrutto e il forAll() e il suo funzionamentoe ben illustrato nella figura B.3.

pagina 57 di 83

B.6. PLINQ APPENDICE B. IL FRAMEWORK MICROSOFT .NET

Figura B.3: ForAll vs. ForEach

Un esempio di utilizzo di tale costrutto e visibile nel listato B.1.

pagina 58 di 83

APPENDICE B. IL FRAMEWORK MICROSOFT .NET B.7. UI DATA BINDINGS

1

2

3 var query = from num in nums . AsPara l l e l ( )4 where num % 10 == 05 s e l e c t num;6

7 // Process the r e s u l t s as each thread completes8 // and add them to a System . Co l l e c t i o n s . Concurrent . ConcurrentBag (Of Int )9 // which can s a f e l y accept concurrent add ope ra t i on s

10 query . ForAll ( ( e ) => concurrentBag .Add(Compute ( e ) ) ) ;

Listing B.1: Esempio di query PLINQ

B.7 UI Data Bindings

Il databindig e una funzionalita dove .NET assieme a Visual Studio spicca perefficienza e semplicita.

Il databinding e il meccanismo automatico che consente di passare oggetti o listedi oggetti a dei componenti grafici (come griglie, tabelle o form) e fa in modo che leproprieta degli oggetti siano visualizzate in questi componenti grafici.

Inoltre una volta che questi elementi grafici vengono modificati tali modifiche siriflettono sugli oggetti sottostanti.

Questo semplifica molto la scrittura del codice ed evita il crearsi di bug difficili daeliminare.

pagina 59 di 83

B.7. UI DATA BINDINGS APPENDICE B. IL FRAMEWORK MICROSOFT .NET

pagina 60 di 83

Appendice C

QlikView

Figura C.1: QlikView

QlikView e un software di Business intelligence di QlikTech, una software companycon sede in Radnor, Pennsylvania.

Nell’ambito di questo progetto Qlik e stato utilizzato per effettuare operazioni dianalisi dei dati recuperati dall’applicazione principale. Il risultato e stato una piccolaapplicazione, scritta appunto nel linguaggio interno a Qlik, che si occupa di caricare idati delle visite presenti su un file in formato tabellare e di mostrarli in vari diagrammi.Tali dati possono essere filtrati secondo un range di date oppure secondo altri numerosiparametri.

Riporto di seguito alcune delle schermate che mostrano i grafici e le tabelle prodottedopo l’elaborazione dei dati.

61

APPENDICE C. QLIKVIEW

Figura C.2: Schermata di Qlik dove si mostra il grafico per % di visite

Come si puo vedere dalla figura si possono selezionare vari tipi di grafico che mostr-ero in figura C.3 e C.4. E’ inoltre possibile filtrare le informazioni per intervallo di datee dalla colonna di destra evidenziata in verde e possibile escludere alcuni nominatividal calcolo del grafico.

Figura C.3: Grafico delle visite per azienda

pagina 62 di 83


Figura C.4: Grafico delle visite per data

pagina 63 di 83


pagina 64 di 83

Appendice D

Visual Studio

Visual Studio e un ambiente di sviluppo integrato (Integrated development en-vironment o IDE) sviluppato da Microsoft, che supporta attualmente diversi tipi dilinguaggio, quali C, C++, C#, F#, Visual Basic .NET e ASP .NET, e che permettela realizzazione di applicazioni, siti web, applicazioni web e servizi web.

E inoltre un RAD (Rapid Application Development), ovvero una applicazioneatta ad aumentare la produttivita aiutando il programmatore con mezzi come l’In-telliSense,la quale permette di correggere eventuali errori sintattici (ed alcuni logici)senza compilare l’applicazione, un potente debugger interno per il rilevamento e la cor-rezione degli errori logici nel codice in runtime, fornisce diversi strumenti per l’analisiprestazionale e un designer visuale delle forms. Visual Studio e inoltre multipiattafor-ma: con esso e possibile realizzare programmi per server, workstation, pocket PC,smartphone e, naturalmente, per i browser.

Si integra nativamente con l’ambiente di sviluppo di gruppo Team FoundationServer e SourceSafe, il quale tra le altre cose permette di effettuare operazioni diversioning sul codice.

D.1 Strumenti forniti da Visual Studio

Riporto una lista degli strumenti forniti da Microsoft Visual Studio che sono statiutilizzati durante lo svolgimento del progetto.

- IntelliSense : E’ una funzionalita di Code Completation che permette di gener-are automaticamente parti di codice, non solo nomi di metodi e variabili, mainteri costrutti del linguaggio.

- Debugger : Visual Studio e fornito di un debugger sofisticato e completamenteconfigurabile.

- Windows Form Designer : Visual Studio incorpora al suo interno uno stru-mento per progettare in maniera grafica (tramite drag-n-drop e riposizionamen-to con il mouse) tutti i componenti dell’interfaccia grafica, velocizzando cosı losviluppo dell’applicazione. Inoltre il designer si occupa di scrivere tutto il codicenecessario per gestire gli handler degli eventi generati dai vari componenti grafici.

65

D.1. STRUMENTI FORNITI DA VISUAL STUDIO APPENDICE D. VISUAL STUDIO

- Class designer : e un componente che consente di creare una classe (inclusimembri e accessibilita degli stessi) tramite un diagramma UML. Dal diagrammaUML viene generato in modo automatico il codice sorgente.

- Dotfuscator Software Services Community Edition : e uno strumentoautomatico di offuscamento del codice.

- SourceSafe : e uno strumento di versionamento del codice per certi versi similea SVN.

- Profiling e uno strumento che consente di eseguire sessioni guidate di analisidelle prestazioni, secondo svariati parametri quali il consumo di CPU, il numerodi chiamate di metodo . . . Per un’approfondimento vedere il paragrafo D.1.1.

- Metrics : e uno strumento che calcola diverse metriche sul codice sorgente, efornisce un’interfaccia grafica di visualizzazione dei dati cosı calcolati.

D.1.1 Analizzatore delle prestazioni

pagina 66 di 83

Appendice E

Sorgenti delle Informazioni

E.1 IPINFODB.COM

Figura E.1: IPInfoDB

IPInfoDB e un’azienda di Geo targeting che tra le altre cose fornisce delle API xmlper l’accesso ai suoi dati. Le informazioni che gestisce sono localizzazione geograficadegli indirizzi IP.

L’accuratezza dei risultati, come dichiarato da IPINFODB e piu alta del 99.5% allivello di stato, e attorno al 60% di accuratezza per la citta, negli U.S.A, con un raggiodi 25 miglia.

L’affidabilita del servizio e alta, dato che la percentuale di uptime e superiore al99.99%.

Per quanto riguarda le limitazioni imposte dal servizio, e importante ricordare cheil limite fissato e quello di non superare le 2 richieste al secondo. Al superamento ditale quota non si garantisce piu l’affidabilita del servizio.

67

E.2. RIR (REGIONAL INTERNET REGISTRY)APPENDICE E. SORGENTI DELLE INFORMAZIONI

E.2 RIR (Regional Internet Registry)

E.2.1 RIR NCC

Figura E.2: Reseaux IP Europeens Network Coordination Center

Il RIPE (acronimo della locuzione francese Reseaux IP Europeensovvero Reti IPEuropee) e un forum collaborativo aperto a tutti i soggetti interessati alle tematicherelative alle reti IP WAN. Obiettivo del RIPE e quello di assicurare il necessariocoordinamento amministrativo e tecnico alle attivita relative ad Internet nella regionedi competenza. Le attivita del RIPE si estrinsecano, principalmente, in discussionisulle mailing list dei diversi working group che lo compongono ed in meeting periodici.Le decisioni sono prese in base al consenso.

Il servizio e affidabile, e l’accuratezza delle informazioni fornite e la massimaraggiungibile.

I limiti imposti dal servizio sono quelli di non superare il limite di una richiesta alsecondo.

E.2.2 ARIN

Figura E.3: American Registry for Internet Numbers

L’ARIN (acronimo di American Registry for Internet Numbers) e l’ente respons-abile per la gestione degli indirizzi IP nel Nord America e assieme agli altri 5 RegionalInternet Registry (RIR) esistenti in ambito IANA, si occupa della creazione/gestionedelle policies in ambito Internet.

Al contrario del RIPE ARIN fornisce delle API XML per il recupero delle infor-mazioni.

pagina 68 di 83

APPENDICE E. SORGENTI DELLE INFORMAZIONIE.2. RIR (REGIONAL INTERNET REGISTRY)

L’affidabilita del servizio e ottima, e l’accuratezza delle informazioni fornite e quellamassima raggiungibile.

pagina 69 di 83

E.2. RIR (REGIONAL INTERNET REGISTRY)APPENDICE E. SORGENTI DELLE INFORMAZIONI

pagina 70 di 83

Appendice F

XMLSchema

Per validare gli input in formato XML dell’applicazione, in particolare la lista diindirizzi IP e le informazioni recuperate da IPINFODB.COM (vedi appendice E.1)sono stati definiti degli XMLSchema, cosı da sfruttare il meccanismo automatico divalidazione fornito dal framework .NET.

F.1 Schema per la lista di IP

1 <?xml ve r s i on=” 1 .0 ” encoding=” i so −8859−1” ?> <xs:schema xmlns :xs=” ht tp ://www.w3 . org /2001/XMLSchema”

2 targetNamespace=” urn : ip−schema”3 xmlns=” urn : ip−schema”4 elementFormDefault=” q u a l i f i e d ”>5 < !−− i n i z i o d e l l a d e f i n i z i o n e d e g l i e l emnt i −−>6 <xs : e l ement name=” i p a d d r e s s l i s t ” type=” T ipadd r e s s l i s t ” />7 <xs:complexType name=” T ipadd r e s s l i s t ”>8 <xs : s equence>9 < !−− d e f i n i z i o n e elemento ipaddre s s −−>

10 <xs : e l ement name=” ipaddre s s ” type=”Tipaddress ” maxOccurs=”unbounded” minOccurs=”0”></ xs : e l ement>

11 </ xs : s equence>12 </xs:complexType>13 < !−− d e f i n i z i o n e t ipo ipaddre s s −−>14 <xs:complexType name=”Tipaddress ”>15 <xs : s impleContent>16 <x s : e x t en s i on base=” x s : s t r i n g ”>17 <x s : a t t r i b u t e name=”date ” type=” xs :da t e ” use=” requ i r ed ”></

x s : a t t r i b u t e>18 <x s : a t t r i b u t e name =” v i s i t s ” type=” x s : i n t e g e r ” use=” requ i r ed ”></

x s : a t t r i b u t e>19 </ x s : e x t en s i on>20 </ xs : s impleContent>21 </xs:complexType>22 </xs:schema>

Listing F.1: Schema per la lista di IP

71

F.2. SCHEMA PER IPINFODB.COM APPENDICE F. XMLSCHEMA

F.2 Schema per IPINFODB.COM

1 <?xml ve r s i on=” 1 .0 ” encoding=”utf−16”?>2 <xsd:schema attr ibuteFormDefau l t=” unqua l i f i e d ” elementFormDefault=”

q u a l i f i e d ” ve r s i on=” 1 .0 ”3 xmlns:xsd=” ht tp : //www.w3 . org /2001/XMLSchema”>4 <xsd :e l ement name=”Response” type=”ResponseType” />5 <xsd:complexType name=”ResponseType”>6 <xsd : sequence>7 <xsd :e l ement name=” statusCode ” type=” x s d : s t r i n g ” />8 <xsd :e l ement name=” statusMessage ” type=” x s d : s t r i n g ” />9 <xsd :e l ement name=” ipAddress ” type=” x s d : s t r i n g ” />

10 <xsd :e l ement name=”countryCode” type=” x s d : s t r i n g ” />11 <xsd :e l ement name=”countryName” type=” x s d : s t r i n g ” />12 <xsd :e l ement name=”regionName” type=” x s d : s t r i n g ” />13 <xsd :e l ement name=”cityName” type=” x s d : s t r i n g ” />14 <xsd :e l ement name=”zipCode” type=” x s d : s t r i n g ” />15 <xsd :e l ement name=” l a t i t u d e ” type=” xsd :dec ima l ” />16 <xsd :e l ement name=” long i tude ” type=” xsd :dec ima l ” />17 <xsd :e l ement name=”timeZone” type=” x s d : s t r i n g ” />18 </ xsd : s equence>19 </xsd:complexType>20 </xsd:schema>

Listing F.2: Schema per le API di IPINFODB.COM

pagina 72 di 83

Appendice G

MVC

Figura G.1: MVC

Model-View-Controller (MVC, talvolta tradotto in italiano Modello-Vista-Controllo)e un pattern architetturale molto diffuso nello sviluppo di interfacce grafiche di sistemisoftware object-oriented. Originariamente impiegato dal linguaggio Smalltalk, il pat-tern e stato esplicitamente o implicitamente sposato da numerose tecnologie moderne,come framework basati su PHP (Symfony, Zend Framework, CakePHP), su Ruby (Ru-by on Rails), su Python (Django, TurboGears, Pylons, Web2py), su Java (Swing, JSFe Struts), su Objective C o su .NET.

A causa della crescente diffusione di tecnologie basate su MVC nel contesto diframework o piattaforma middleware per applicazioni Web, l’espressione frameworkMVC sistema MVC sta entrando nell’uso anche per indicare specificamente questacategoria di sistemi.

73

G.1. STRUTTURA APPENDICE G. MVC

G.1 Struttura

Il pattern e basato sulla separazione dei compiti fra i componenti software cheinterpretano tre ruoli principali:

- il model fornisce i metodi per accedere ai dati utili all’applicazione;

- il view visualizza i dati contenuti nel model e si occupa dell’interazione con utentie agenti;

- il controller riceve i comandi dell’utente (in genere attraverso il view) e li at-tua modificando lo stato degli altri due componenti Questo schema, fra l’altro,implica anche la tradizionale separazione fra la logica applicativa (in questo con-testo spesso chiamata logica di business), a carico del controller e del model, el’interfaccia utente a carico del view.

I dettagli delle interazioni fra questi tre oggetti software dipendono molto dalletecnologie usate (linguaggio di programmazione, eventuali librerie, middleware e viadicendo) e dal tipo di applicazione (per esempio se si tratta di un’applicazione web, odi un’applicazione desktop).

pagina 74 di 83

Appendice H

RPG (Linguaggio diProgrammazione)

RPG oppure RPG IV e un linguaggio di programmazione nativo per minicomputerIBM della serie iSeries, denominata anche, piu comunemente, AS/400. La sua versionepiu recente comprende l’uso di prototipi di funzioni e procedure, binding statico edinamico dei dati, accesso a librerie di routine scritte in C, uso di funzioni contenutein DLL compilate a partire da altri linguaggi, e supporta totalmente codice dotato disintassi ricorsiva e rientrante.

H.1 Cenni Storici

L’RPG e uno dei pochi linguaggi creati al tempo dei primi calcolatori a schedeperforate che sono ancora oggi in uso. E stato originariamente sviluppato dall’IBMnel 1960 per il popolare calcolatore IBM 1401. All’inizio RPG era l’acronimo diReport Program Generator, descrizione che spiegava bene lo scopo per cui era statoprogettato: produrre report a partire da file di dati, compresa la funzione di ricercadi record e di calcolo di totali parziali.

A quel tempo i linguaggi alternativi disponibili erano il COBOL ed il Basic, ilprimo particolarmente ridondante, il secondo poco potente, cosı che l’RPG assunseuna posizione dominante in ambito IBM. In seguito l’RPG fu perfezionato, sempreda IBM, per equipaggiare la propria serie di mainframe, in particolare il modelloS390, prendendo il nome di RPG II. La sintassi dell ’RPG e nata per emulare laconfigurazione dei pannelli di programmazione a spinotti dei primi calcolatori; poicheil Sistema 3 e stato inizialmente sviluppato come successore di questi tipi di calcolatore,l’RPG II e stato adattato ai modelli System 3, System 32, System 34, e System 36,mentre una versione ulteriormente migliorata, l’RPG III, e stata creata appositamenteper il System 38 ed il suo successore AS/400, un minicomputer ora evolutosi a suavolta nelle serie E-Server ed iSeries. Questa versione e denominata anche RPG/400,dotata di una sintassi molto piu lineare e leggibile e di maggiore efficienza in letturadi file e database, e stata la base per lo sviluppo dell’AS 400, ed il suo editor esemplicemente basato sulla modifica delle linee di programma, con la presentazione

75

H.1. CENNI STORICI APPENDICE H. RPG (LINGUAGGIO DI PROGRAMMAZIONE)

immediata di template corrispondenti ai vari tipi di istruzioni da inserire. l’RPGIII e notevolmente piu evoluto rispetto alla versione iniziale, comprendendo costruttistrutturati di tipo piu moderno, come blocchi IF-ENDIF, loop inizializzati dal DO,e possibilita di scrivere subroutine. Nel 1998 e stato rilasciato l’RPG IV, conosciutoanche come RPG/LE oppure RPG/ILE. Notare come il nome del linguaggio ha persoil significato iniziale, come dichiarato ufficialmente dalla stessa IBM. Questa versioneoffre ai programmatori la possibilita di scrivere codice in formato piu libero, cioe nonvincolato da un rigido incolonnamento delle parole chiave, ed un set di istruzioni moltopiu ricco, definito Extended Calculation Specification. L’RPG e cosı strettamentecorrelato alle API del sistema operativo OS/400 che praticamente tutti gli oggettisoftware sono trattati come se fossero file (qualcosa di analogo alla filosofia alla basedi Unix). Il contenuto visualizzato sui display dei terminali, suddiviso in sotto-finestre,e aggiornato semplicemente scrivendo su un file, con un’istruzione tipo: *DISPLAY.

pagina 76 di 83

Appendice I

Mappa Dinamica Google MapsTM

Come visibile in figura 3.17, e stato utilizzato il servizio gratuito di mappe diGoogle, Google Maps.

Per accedere al servizio sono state usate le API in Javascript fornite dallo stesso.Un esempio del codice usato e:

1 var bounds ;2 var map ;3

4 f unc t i on i n i t i a l i z e ( ) {5

6 bounds = new goog l e . maps . LatLngBounds (new goog l e . maps .LatLng (40 ,12) ,new goog l e . maps . LatLng (41 ,13) ) ;

7

8 // moscow9 var l a t l n g = new goog l e . maps . LatLng (41 ,12) ;

10 var myOptions = {11 zoom : 4 ,12 cente r : l a t l ng ,13 mapTypeId : goog l e . maps .MapTypeId .HYBRID14 }15 map = new goog l e . maps .Map( document . getElementById ( ”

map canvas” ) , myOptions ) ; f unc t i on encodeAddress ( l a t , lng ,address , t i t l e , desc ) {

16

17

18 var l a t l n g = new goog l e . maps . LatLng ( la t , lng ) ;19

20 bounds . extend ( l a t l n g ) ;21 map . setCenter ( bounds . getCenter ( ) )22 map . f i tBounds ( bounds ) ;23

24 var contentSt r ing = ’<div id=”content ” s t y l e=”font−f ami ly: He lve t i ca”> ’+

25 ’<div id=”s i t eNo t i c e”> ’+26 ’<\/div> ’+27 ’<p id=”f i r s tHead ing ” c l a s s=”f i r s tHead ing”> ’ + t i t l e + ’

<\/p> ’+28 ’<p> ’+ address + ’<\/p> ’ +

77

APPENDICE I. MAPPA DINAMICA GOOGLE MAPSTM

29 ’<div id=”bodyContent” c l a s s=”bodyContent”> ’+30 ’<p><b> ’+ desc + ’<\/b><\/p> ’ +31 ’<\/div> ’+32 ’<\/div> ’ ;33

34 var infowindow = new goog le . maps . InfoWindow ({35 content : contentSt r ing36 }) ;37

38 goog l e . maps . event . addLis tener (marker , ’ c l i c k ’ , f unc t i on ( ){

39 infowindow . open (map, marker ) ;40 }) ;41

42 }43

44 }

Tale codice e poi stato inserito all’interno di una pagina HTML. Per dare un aspettografico piu gradevole, e stato anche aggiunto un foglio di stile inline.

Il codice della pagina HTML e:

1 < !DOCTYPE html PUBLIC ”−//W3C//DTD XHTML 1.0 Tran s i t i ona l //EN” ”http ://www.w3 . org /TR/xhtml1/DTD/xhtml1−t r a n s i t i o n a l . dtd”>

2 <html>3 <head>4 < t i t l e>Map</ t i t l e>5 <s t y l e type=” text / c s s ”>6 . f i r s tHead ing {7 font−f ami ly : Verdana ;8 font−s i z e : 12 ;9 font−weight : bold ;

10 }11

12 . bodyContent {13 c o l o r : #808080;14 font−f ami ly : Verdana ;15 font−s i z e : 8 ;16 }17 html , body18 {19 width :100%;20 he ight :100%;21 margin : 0 ;22 padding : 0 ;23 }24 #map canvas25 {26 po s i t i o n : r e l a t i v e ;27 width :100%;28 he ight :100%;29 }30 </ s t y l e>

pagina 78 di 83


31 <s c r i p t type=” text / j a v a s c r i p t ” s r c=”http ://maps . goog l e . com/maps/api / j s ? s enso r=true ”></ s c r i p t>

32 <s c r i p t type=” text / j a v a s c r i p t ”>33

34

35 var bounds ;36 var map ;37

38 f unc t i on i n i t i a l i z e ( ) {39

40 bounds = new goog l e . maps . LatLngBounds (new goog l e . maps .LatLng (40 ,12) ,new goog l e . maps . LatLng (41 ,13) ) ;

41

42 // moscow43 var l a t l n g = new goog l e . maps . LatLng (41 ,12) ;44 var myOptions = {45 zoom : 4 ,46 cente r : l a t l ng ,47 mapTypeId : goog l e . maps .MapTypeId .HYBRID48 }49 map = new goog l e . maps .Map( document . getElementById ( ”

map canvas” ) , myOptions ) ; f unc t i on encodeAddress ( l a t , lng ,address , t i t l e , desc ) {

50

51

52 var l a t l n g = new goog l e . maps . LatLng ( la t , lng ) ;53

54 bounds . extend ( l a t l n g ) ;55 map . setCenter ( bounds . getCenter ( ) )56 map . f i tBounds ( bounds ) ;57

58 var contentSt r ing = ’<div id=” content ” s t y l e=” font−f ami ly: He lve t i ca ”>’+

59 ’<div id=” s i t eNo t i c e ”>’+60 ’<\/ div>’+61 ’<p id=” f i r s tHead ing ” c l a s s=” f i r s tHead ing ”> ’ + t i t l e + ’<

\/p>’+62 ’<p>’+ address + ’<\/p> ’ +63 ’<div id=”bodyContent” c l a s s=”bodyContent”>’+64 ’<p><b>’+ desc + ’<\/b><\/p> ’ +65 ’<\/ div>’+66 ’<\/ div> ’ ;67

68 var infowindow = new goog l e . maps . InfoWindow ({69 content : contentSt r ing70 }) ;71

72 goog l e . maps . event . addLis tener (marker , ’ c l i c k ’ , f unc t i on ( ){

73 infowindow . open (map, marker ) ;74 }) ;75

76 }

pagina 79 di 83


77

78 }79

80 </ s c r i p t>81 </head>82 <body onload=” i n i t i a l i z e ( ) ; ”>83 <div id=”map canvas”></ div>84 </body>85 </html>

pagina 80 di 83

Appendice J

Agile Development

Nell’ingegneria del software, per metodologia agile (o leggera) si intende un par-ticolare metodo per lo sviluppo del software che coinvolge quanto piu possibile ilcommittente, ottenendo in tal modo una elevata reattivita alle sue richieste.

Il termine Metodologie Agili fu coniato nel 2001 quando il Manifesto Agile e statoformulato.

I firmatari dell’Agile Manifesto sono (in ordine alfabetico): Kent Beck, Mike Bee-dle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham (inventore di Wiki),Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, JonKern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland,Dave Thomas.

J.1 Principi

I principi su cui si basa una metodologia leggera che segua i punti indicati dall’AgileManifesto, sono solo quattro:

- le persone e le interazioni sono piu importanti dei processi e degli strumenti (ossiale relazioni e la comunicazione tra gli attori di un progetto software sono la migliorrisorsa del progetto);

- e piu importante avere software funzionante che documentazione (bisogna rilas-ciare nuove versioni del software ad intervalli frequenti, e bisogna mantenere ilcodice semplice e avanzato tecnicamente, riducendo la documentazione al minimoindispensabile);

- bisogna collaborare con i clienti al di la del contratto (la collaborazione direttaoffre risultati migliori dei rapporti contrattuali);

- bisogna essere pronti a rispondere ai cambiamenti piu che aderire al progetto(quindi il team di sviluppo dovrebbe essere autorizzato a suggerire modifiche alprogetto in ogni momento).

81

J.2. PRATICHE APPENDICE J. AGILE DEVELOPMENT

J.2 Pratiche

Le singole pratiche applicabili all’interno di una metodologia leggera sono decinee dipendono essenzialmente dalle necessita dell’azienda e dall’approccio del projectmanager. Quelle piu importanti sono:

- Comunicazione stretta - Per comunicazione stretta si intende la comunicazione in-terpersonale, fra tutti gli attori del progetto, cliente compreso. Cio serve ad avereuna buona analisi dei requisiti ed una proficua collaborazione fra programmatorianche in un ambito di quasi totale assenza di documentazione;

- Coinvolgimento del cliente;

- Progettazione e documentazione - Pensare che le metodologie leggere eliminino laprogettazione e la documentazione e un errore, in effetti non e cosı, le metodologieleggere introducono un’iterazione nel ciclo di vita del progetto; quanta proget-tazione fare e quanta documentazione produrre, escludendo i casi estremi, e unascelta lasciata a chi gestisce il progetto;

- Consegne frequenti - Effettuare rilasci frequenti di versioni intermedie del softwarepermette di ottenere piu risultati contemporaneamente;

- Gerarchia - La scelta di creare una struttura gerarchica all’interno del team disviluppo dipende molto dall’approccio del project manager;

- Programmazione di coppia - Programmare in coppia, ossia: due programmatori,due sedie, una scrivania, un computer, una tastiera ed un mouse; uno dei duescrive, l’altro verifica, entrambi scelgono la soluzione costruttiva migliore; e statodimostrato che i costi di questa scelta sono inferiori ai benefici che apporta, ma cisono esempi pratici che indicano come questa pratica possa essere insopportabileper alcuni programmatori e quindi controproducente;

- Semplicita - Uno dei punti chiave delle metodologie leggere, direttamente mutua-to dalla programmazione Object-Oriented, e la semplicita; semplicita nel codice,semplicita nella documentazione, semplicita nella progettazione, semplicita nel-la modellazione; i risultati cosı ottenuti sono una migliore leggibilita dell’interoprogetto ed una conseguente facilitazione nelle fasi di correzione e modifica;

- Controllo della versione - Una delle conseguenze dirette dell’iterazione nella pro-duzione e la necessita di introdurre un modello, un metodo, uno strumento, peril controllo delle versioni del software prodotto e rilasciato;

pagina 82 di 83

Bibliografia

[1] Microsoft Developer Network (MSDN) contenente la documentazione ufficialesul framework .NET : http://msdn.microsoft.com/

[2] Matias Bartoll, Nori Ahari, Oliver C. Moldez (2010) – Departement of ComputerScience Malardalen University Vasteras, Sweden – “Design Patterns in C#”

[3] Rob Miles (2009) – Departement of Computer Science University of Hull – “C#from Java”

[4] Rob Miles (2011) – Departement of Computer Science University of Hull – “C#Programming”

[5] Thuan Thay, Hoang Lawn (2010) – O’ Reilly editore - “Intrudicing the .NETFramework”

[6] Wikipedia, l’enciclopedia libera: http://www.wikipedia.org/

83

http://msdn.microsoft.com/

http://www.wikipedia.org/

Universit a degli Studi di Padova - SIAGAS

Documents

Transcript of Universit a degli Studi di Padova - SIAGAS