Sviluppo Di Un Modulo Per Il Disegno Di Planimetrie

UNIVERSITÀ DEGLI STUDI DI PADOVA

Facoltà di scienze MM. FF. NN. - Corso di laurea in informatica

Tesi di Laurea SVILUPPO DI UN MODULO PER IL DISEGNO DI PLANIMETRIE

Relatore: Dott. Francesco Ranzato Laureando: Matteo Di Liberto Gasparin

Anno Accademico 2012/2013 Indice

1.Presentazione dello stage...... 1 1.1 L'azienda...... 2 1.2 Configuratore di prodotto...... 2 1.3 TCE...... 3 1.4 Obiettivi dello stage...... 4 2.Formazione e analisi dei requisiti...... 5 2.1 Formazione...... 5 2.2 Le richieste dell'azienda...... 6 2.3 Casi d'uso...... 7 2.4 Requisiti...... 8 2.5 Ciclo di vita...... 9 3.Sviluppo...... 11 3.1 Tecnologie utilizzate...... 11 3.1.1 .NET Framework 2.0...... 11 3.1.2 Windows Forms...... 12 3.1.3 OpenGL...... 12 3.1.4 OpenTK...... 13 3.1.5 Visual Studio 2008 Professional...... 13 3.2 Architettura dell'applicazione...... 14 3.3 Rappresentazione degli oggetti...... 14 3.4 Interfaccia grafica...... 15 3.5 Comandi...... 20 3.6 Persistenza ed esportazione...... 20 3.7 Difficoltà implementative riscontrate...... 22 3.8 Pattern software utilizzati...... 24 3.8.1 State pattern: implementazione dei comandi utente...... 24 3.8.2 Command pattern: annulla/ripeti operazione...... 29 4.Verifica e validazione...... 31 4.1 Analisi statica...... 32 4.1.1 Code review...... 32 4.2 Analisi dinamica...... 32 4.2.1 Uso di asserzioni...... 32 4.2.2 Test di unità e di integrazione...... 33 4.3 Strumenti di analisi...... 34 5.Considerazioni conclusive...... 35 5.1 Lavoro svolto...... 35 5.2 Consuntivo delle attività...... 35 5.3 Conoscenze applicate e nuove conoscenze acquisite...... 36 5.4 Conclusioni...... 37 6.Glossario...... 39 Indice delle illustrazioni

Illustrazione 1: Diagramma dei casi d'uso del Modulo Planimetrie...... 7 Illustrazione 2: Ciclo di vita a cascata...... 9 Illustrazione 3: Il modulo Planimetrie all'apertura dell'applicazione.....18 Illustrazione 4: Selezione di un profilo...... 19 Illustrazione 5: Transizioni di stato iniziali...... 27 Illustrazione 6: Inserimento di una polilinea (diagramma di stato)...... 28 Illustrazione 7: Inserimento di un'apertura in una parete (diagramma di stato)...... 28 Illustrazione 8: Classi coinvolte nel meccanismo undo/redo...... 30 Illustrazione 9: Consuntivo delle attività...... 36 Presentazione dello stage

1. Presentazione dello stage

Il presente documento ha lo scopo di illustrare il lavoro svolto nell'ambito dell'esperienza di stage prevista dal corso di laurea in informatica, effettuata presso l'azienda Sanmarco Informatica Spa.

Sono venuto a conoscenza dello stage che ho svolto tramite “Stage-IT”, l'evento organizzato dall'Università degli studi di Padova e la Camera di Com mercio di Padova, pensato come luogo d'incontro tra aziende e studenti. Tra i vari colloqui tenuti, ho fatto la mia scelta principalmente per l'ambito del progetto, infatti argomenti inerenti la visualizzazione grafica vettoriale e i si stemi di manipolazione di geometrie sono sempre stati una mia fonte d'inte resse.

L'obiettivo dell'esperienza di stage che si è svolto presso il Centro Sviluppo è stata quella di progettare e sviluppare un modulo aggiuntivo per il configu ratore di prodotto proprietario di Sanmarco Informatica denominato TCE (Ten der Configuration Engine).

La trattazione si sviluppa fondamentalmente in cinque sezioni:

• nel resto di questo capitolo verrà introdotto il contesto in cui lo stage si è svolto, presentando brevemente l'azienda e fornendo le conoscenze minime necessarie alla comprensione degli obiettivi prefissati;

• nel secondo capitolo sarà discusso il periodo di formazione e le caratte ristiche e i requisiti inerenti al progetto;

• il terzo capitolo si addentrerà nella fase di sviluppo, esponendo con la dovuta precisione le scelte di progettazione e gli aspetti tecnici più in teressanti inerenti il funzionamento del sistema;

• il quarto capitolo tratterà le attività di verifica e collaudo eseguite;

• nel quinto capitolo verranno esposte le conclusioni tratte dall'esperien za di stage;

1 Presentazione dello stage

Inoltre, al fine di una maggiore chiarezza, il capitolo 6 contiene un glossario dei termini tecnici. La prima istanza, nel resto del documento, di ogni termi ne presente nel glossario è stata evidenziata in questo modo.

1.1 L'azienda

Sanmarco Informatica SPA è un'azienda con sede a Grisignano di Zocco (VI) con filiali in Emilia Romagna, Friuli Venezia Giulia e Lombardia. È nata negli anni '80 come software house specializzata nello sviluppo di applicazioni ge stionali in ambienti IBM.

Lo scopo dell'azienda è quello di affiancare il cliente nel processo di miglio ramento del business, fornendo soluzioni ERP e una gamma di servizi globali.

Il suo prodotto di punta è il software gestionale Galileo ERP, che rappresen ta una soluzione completa per aziende e professionisti, e che attualmente conta più di 50000 utenze in circa 2000 installazioni.

L'ecosistema che ha come punto di partenza Galileo ERP contiene anche molti altri moduli, dedicati alla gestione delle situazioni più diverse, come per esempio valutazione delle business strategy, gestione e archiviazione dei do cumenti e configurazione di prodotti.

1.2 Configuratore di prodotto

Un configuratore di prodotto è un particolare sistema software, che per mette, basandosi su certi criteri, di definire un prodotto che soddisfi una de terminata combinazione di componenti, caratteristiche e funzioni.

Questo genere di software è richiesto da tutte le realtà che offrono prodot ti in molte varianti, tali da rendere necessaria una notevole interazione con il cliente allo scopo di identificare, tra le varie opzioni disponibili, quelle che meglio rispondono alle sue esigenze, anche nel caso in cui una certa combina zione di opzioni non sia mai stata richiesta e realizzata prima.

2 Presentazione dello stage

Un tipico esempio di caso d'uso di questo genere di software, si ha nell'industria degli infissi, in cui per esempio ogni cliente può scegliere una di versa combinazione di tipo e colore del legno di intelaiatura, tipo di vetro nel caso si tratti di una finestra o anche presenza o meno del vetro nel caso di una porta, ecc.; inoltre possibilmente la dimensione dell'infisso stesso dev'essere personalizzata in base alla dimensione di un'apertura preesistente nel muro. Ognuna di queste combinazioni può comportare costi e tempi di at tesa diversi da notificare al cliente, e certe combinazioni possono avere dei vincoli tali da impedirne la realizzazione. Il software di configurazione di pro dotto dev'essere in grado di gestire tutte queste diverse situazioni.

1.3 TCE

TCE è il prodotto proprietario di Sanmarco Informatica, a supporto dell'area tecnica e commerciale, che risponde al problema della configurazione di pro dotto. Le prime versioni distribuite risalgono alla fine degli anni '90.

È un configuratore generico, per cui non è dedicato a nessun particolare ambito della produzione e viene usato indifferentemente nell'industria mecca nica, degli infissi, ecc.

Oltre a ciò, tra le sue peculiarità si ricordano l'interfaccia web e il visualiz zatore (TCE3D) che consente di avere un'anteprima tridimensionale dell'ogget to configurato.

Il prodotto dello stage va a inserirsi nel processo il cui scopo è di mostrare non solo il singolo risultato di una configurazione, ma anche una composizione spaziale di diversi oggetti configurati, disposti all'interno dell'edificio dove sa ranno effettivamente collocati, e consiste in un editor di piantine di edifici, progettato e sviluppato da zero, a sua volta con la possibilità di visualizzare in 3D ciò che si sta disegnando.

3 Presentazione dello stage

1.4 Obiettivi dello stage

La scelta di svolgere lo stage presso un'azienda esterna, e la scelta di que sto progetto in particolare, deriva dal desiderio personale di entrare in con tatto con nuove tecnologie e soprattutto di confrontarmi con un ambiente di lavoro reale. Grazie a questa esperienza di stage ho avuto modo di:

• familiarizzare con tecniche e tecnologie per me nuove: un mio partico lare interesse era quello di sperimentare tecnologie proprietarie come il .NET Framework e Visual Studio, che non sono sfruttate nel corso di studi ma sono molto utilizzate nei contesti aziendali. L'esperienza di stage mi ha consentito di toccare con mano questi strumenti e utiliz zarli in un progetto concreto, consentendomi di mettere in pratica va rie tecniche, sia nuove, sia conosciute durante il corso di studi.

• Lavorare allo sviluppo di un editor: spesso, soprattutto nell'ambito del la programmazione grafica, ci si ritrova ad aver bisogno di creare dei contenuti su cui sia possibile provare l'efficacia o l'applicabilità di algo ritmi che crediamo utili. Ci si rende conto che nessuna applicazione at tualmente disponibile è in grado di soddisfare la particolare richiesta di informazioni, per cui, tipicamente, ci si costruisce un editor personaliz zato. Grazie all'esperienza di stage ho avuto modo di capire cosa signi fichi costruire un editor effettivamente utilizzabile, e quali sono i mec canismi e le scelte che si devono adottare per fare in modo che questo tipo di applicazione sia mantenibile ed espandibile anche nel lungo ter mine.

• Entrare in contatto con la realtà aziendale: lo stage presso un'azienda esterna mi ha consentito di confrontarmi con le situazioni e le proble matiche tipiche della realtà quotidiana di un'azienda che sviluppa soft ware.

4 Formazione e analisi dei requisiti

2. Formazione e analisi dei requisiti

Come introdotto nel capitolo 1, l'obbiettivo dello stage è la realizzazione di un'applicazione per il disegno di planimetrie, le quali saranno successiva mente riutilizzate all'interno del modulo TCE3D per la contestualizzazione di oggetti configurati.

2.1 Formazione

Per lo sviluppo del modulo Planimetrie è stato imposto l'uso del linguaggio C# e dell'ambiente di sviluppo Visual Studio 2008. Non avendo mai program mato usando questi strumenti è stato necessario un periodo di apprendimento del linguaggio, fortunatamente reso semplice dalla somiglianza con i linguaggi Java, già studiato durante il corso di laurea, e C++, di cui ritengo di avere una buona esperienza.

Oltre a ciò, mi è stato introdotto il software TCE, senza però entrare trop po nei dettagli rispetto a meccanismi di funzionamento e architettura del si stema, in quanto l'idea iniziale era che il modulo Planimetrie fosse un pro gramma da chiamare esternamente da TCE, e che quindi dovesse mantenere la propria indipendenza.

Infine, mi sono stati introdotti a grandi linee i requisiti che il nuovo modulo avrebbe dovuto soddisfare. Ho quindi potuto approfittare di questo periodo per fare alcune esplorazioni su possibili tecnologie complementari a quelle ri chieste, dato che non mi erano stati dati vincoli in tal senso, e scrivere brevi programmi di esempio che mi consentissero di controllarne le possibilità, ap prendendo nel frattempo le caratteristiche salienti del nuovo linguaggio. Per un elenco dettagliato delle tecnologie utilizzate nello sviluppo, si veda il capi tolo 3.1.

5 Formazione e analisi dei requisiti

2.2 Le richieste dell'azienda

Già dall'inizio del periodo di formazione sono state esposte le richieste sulle caratteristiche che il modulo Planimetrie avrebbe dovuto soddisfare:

• disegnare, modificare e cancellare planimetrie o parti di esse mediante i tipici strumenti offerti da un moderno programma per il disegno vet toriale;

• specificare lo spessore di ogni singola parete in modo indipendente;

• specificare il posizionamento e le dimensioni di finestre e altre apertu re su ogni parete;

• visualizzare la costruzione in 3D per controllare il corretto posiziona mento delle aperture;

• consentire l'interruzione e il recupero di una sessione di lavoro (persi stenza);

• esportare il modello costruito in modo che sia leggibile da TCE3D;

Inoltre sull'applicazione sono stati posti i seguenti vincoli non funzionali:

• linguaggio utilizzato: C#;

• semplicità d'uso, tale da poter essere utilizzato da personale senza background avente a che fare con il disegno tecnico o con il disegno as sistito da computer.

Sorprendentemente non è stata avanzata nessuna richiesta in merito all'integrazione del nuovo modulo all'interno di TCE. In realtà questa scelta è stata motivata anche dal fatto che il prodotto dell'esperienza di stage sia un passo verso la riscrittura, utilizzando tecnologie più moderne, di tutto il pac chetto software, attualmente scritto in Visual Basic 6, con alcune parti (come il modulo TCE3D) che utilizzano il linguaggio Delphi.

6 Formazione e analisi dei requisiti

2.3 Casi d'uso

Attraverso il caso d'uso dell'illustrazione 1 vediamo le funzionalità offerte dal Modulo Planimetrie.

Attori coinvolti: utente Modulo Planimetrie.

7 Formazione e analisi dei requisiti

Scopo del diagramma: descrivere le funzionalità messe a disposizione dell'utente per quanto riguarda la visualizzazione, la modifica e la persistenza di una planimetria.

Precondizioni: il programma è installato correttamente e avviato.

Descrizione: l'utente può modificare una planimetria utilizzando i vari stru menti a disposizione, aggiungendo nuovi profili, rimuovendoli, unendoli trami te un'operazione booleana, spostarli, aggiungere aperture; può visualizzare la planimetria in due dimensioni, dall'alto, o tridimensionalmente; nel caso della visualizzazione 2D può manipolare il viewport spostandolo, o ridimensionando lo; può salvare il suo lavoro e ricaricarlo successivamente, o esportarlo in altri formati.

Postcondizioni: l'utente ha la possibilità di modificare una planimetria, o anche solo di osservarne una già disegnata.

2.4 Requisiti

L'ultimo dei requisiti non funzionali enumerati nella sezione 2.2, ovvero as sicurare la massima semplicità d'uso anche per gli utenti privi di background attinente al disegno, è stato espresso in termini piuttosto vaghi, per cui è sta ta necessaria un'ulteriore fase di identificazione dei requisiti mediante inter vista, al termine della quale è stato esploso nei seguenti vincoli derivati:

• Offrire un'interfaccia che non ostruisca il modo di lavorare dell'operato re che sta disegnando;

• Fornire, nell'interfaccia, gli aiuti necessari a fare in modo che l'utente riesca a portare a termine le operazioni con la minima probabilità di aver commesso errori;

• Consentire di annullare l'ultima operazione.

Nel loro insieme, i vincoli imposti al Modulo Planimetrie sono riassunti nella tabella 1.

8 Formazione e analisi dei requisiti

ID Descrizione Consentire inserimento, modifica e rimozione di planimetrie da un 1 documento 2 Consentire la specifica dello spessore di ogni singola parete Consentire la specifica di posizione e dimensione di ogni singola 3 apertura nelle pareti 4 Visualizzazione in 3D del documento 5 Consentire di salvare e caricare i documenti 6 Esportazione documenti in formato non proprietario 7 Usare linguaggio C# 8 Costruire un'interfaccia grafica non ostrusiva 9 Aggiungere aiuti per il disegno 10 Implementare funzionalità di annulla/ripeti operazione Tabella 1: Requisiti individuati

2.5 Ciclo di vita

Le particolari caratteristiche del progetto di stage mi hanno permesso di scegliere, come modello di ciclo di vita, il modello a cascata, nonostante gli ovvi e conosciuti problemi che lo affliggono (rigidità delle fasi, assenza di cicli di feedback), in quanto:

• il progetto è di dimensioni contenute;

9 Formazione e analisi dei requisiti

• l'ambito applicativo è ben conosciuto, ed i requisiti individuati sono ap parsi subito a tutte le parti coinvolte necessari e sufficienti al corretto proseguimento del progetto;

• anche le tecniche implementative mi sono apparse fin da subito chiare.

Date queste premesse il modello di ciclo di vita a cascata mi ha consentito di proseguire nel progetto in modo comunque conciso ed efficace.

10 Sviluppo

3. Sviluppo

3.1 Tecnologie utilizzate

3.1.1 .NET Framework 2.0

Il .NET Framework è un framework software sviluppato da Microsoft dall'inizio del 2002 e che viene usato principalmente su Windows (nonostante esista un'implementazione compatibile e multipiattaforma di quasi tutte le sue parti all'interno del progetto Mono). Include una vasta libreria e fornisce interoperabilità tra i vari linguaggi del framework. Le applicazioni scritte per .NET vengono eseguite in un ambiente software chiamato CLR (Common Language Runtime), implementazione proprietaria del concetto di Common Language Infrastructure (CLI), ovvero una application virtual machine che for nisce servizi tra i quali sicurezza, gestione della memoria e gestione delle ec cezioni.

Il modulo Planimetrie è costruito sulla versione 2.0 del framework, nono stante quando sia stato svolto lo stage fosse già disponibile la versione 3.5; è stato reputato che le tecnologie offerte dalle versioni successive alla 2.0 fos sero superflue o addirittura controproducenti.

L'applicazione è stata programmata tramite il linguaggio C#, uno dei dialet ti della Common Language Infrastructure messi a disposizione dal framework. Questo linguaggio si è rivelato efficace per lo svolgimento del progetto, dato il numero di facilitazioni offerte (es. gestione automatica della memoria) che consentono di procedere rapidamente nello sviluppo. L'uso di C# è stato impo sto per uniformità con altre parti di TCE basate su .NET (tipicamente ASP.NET) e nell'ottica di una modernizzazione di tutto il pacchetto basata sulla riscrit tura dello stesso usando tecnologie e linguaggi più moderni di quelli attual mente usati.

11 Sviluppo

3.1.2 Windows Forms

Windows Forms (WinForms) è il nome dato all'API inclusa nel framework .NET dedicata alla costruzione di interfacce grafiche, e fornisce accesso all'API nativa di Microsoft Windows incapsulando le chiamate all'interno di co dice gestito.

Con il rilascio del .NET Framework 3.0 Microsoft ha rilasciato il successore di Windows Forms chiamato WPF (Windows Presentation Foundation) insieme a un linguaggio dichiarativo basato su XML per la costruzione delle sue inter facce grafiche chiamato XAML. Comunque, il fatto che Windows Forms e WPF offrano funzionalità comparabili non significa che WinForms sia diventata ob soleta, piuttosto è diventata un altro strumento per la costruzione di interfac ce grafiche Windows che continuerà a esistere in parallelo a WPF.

L'uso di Windows Forms è stato dettato dalla volontà di usare la libreria OpenTK e il suo componente GLControl all'interno del progetto, componente di cui l'implementazione basata su WPF era ancora incompleta. Ciò nonostan te l'impatto di questa decisione è stato minimo, in quanto durante la fase di analisi si è preferito fare in modo che gli elementi propri dell'interfaccia grafi ca di Windows abbiano un ruolo marginale all'interno del workflow tipico aspettato del modulo Planimetrie.

3.1.3 OpenGL

Si tratta di una specifica che definisce una API per il rendering di computer grafica a due e tre dimensioni, e viene tipicamente utilizzata per interagire con una GPU ottenendo il cosiddetto rendering accelerato. OpenGL è stata sviluppata all'inizio degli anni '90 dalla Silicon Graphics Inc. ed è ampiamente utilizzata in ambiti CAD, realtà virtuale, visualizzazione scientifica, visualizza zione delle informazioni, simulazioni di volo e nei videogames (in cui, su piat taforma Microsoft Windows compete con DirectX). È lo standard di fatto per la computer grafica 3D in tutti i sistemi operativi diversi da Microsoft Windows.

12 Sviluppo

Questa tecnologia è stata scelta data la necessità di avere una rappresenta zione tridimensionale del modello planimetrico disegnato e per la mia prece dente ed estensiva esperienza con essa.

3.1.4 OpenTK

OpenTK è una libreria grafica foss scritta in C# che costituisce un thin wrapper di librerie, come OpenGL, OpenCL e OpenAL, dedicate alla visualiz zazione grafica ad alte prestazioni e al mondo del gaming. È multipiattaforma e utilizzabile da tutti i linguaggi .NET/Mono.

Tra le caratteristiche di interesse di questo progetto si rilevano la conformi tà al modello del codice gestito tipico del framework .NET, la facilità di inseri mento all'interno di applicazioni facenti uso dei più diversi toolkit grafici (Windows Forms, GTK#, WPF), una libreria che copre gli aspetti matematici collegati alla grafica bi- e tridimensionale, l'accesso completo a tutto l'ecosi stema OpenGL (quindi anche alle librerie GLU, di cui è stato fatto uso) e una licenza di tipo MIT che ne consente l'utilizzo in applicazioni open e commer ciali.

Nonostante le caratteristiche favorevoli sopracitate, l'adozione di questa li breria è stata forzata, dato che durante lo svolgimento dello stage era l'unica disponibile liberamente che consentisse un collegamento tra il linguaggio C# e OpenGL.

3.1.5 Visual Studio 2008 Professional

Per lo svolgimento del progetto mi è stata fornita una postazione di lavoro già equipaggiata con Visual Studio 2008 Professional, l'ambiente offerto da Microsoft per lo sviluppo di applicazioni basate sul .NET Framework. Si tratta di un IDE che fornisce tutti gli strumenti per lo sviluppo, la verifica e la distri buzione di applicazione per il sistema operativo Windows.

13 Sviluppo

Di particolare valore l'implementazione dell'autocompletamento offerta dall'ambiente di sviluppo (IntelliSense) e il debugger integrato, che con la sua pervasività rende semplice la ricerca degli errori nel codice.

3.2 Architettura dell'applicazione

L'architettura del modulo Planimetrie è basata sul pattern Model-View-Con troller (MVC), che separa i compiti tra i componenti software che interpretano i tre ruoli principali:

• Model: fornisce i metodi necessari all'accesso agli oggetti gestiti per conto dell'utente;

• View: visualizza i dati del model;

• Controller: attua i comandi dell'utente (che arrivano attraverso la view) modificando lo stato di view e model;

In particolare, il model sarà descritto maggiormente nella sezione 3.3, l'interfaccia grafica e la view nella sezione 3.4, e l'implementazione del con troller attraverso una macchina a stati sarà dettagliata nella sezione 3.8.1.

3.3 Rappresentazione degli oggetti

Nonostante la prassi per il disegno architettonico ereditata tipicamente da AutoCAD consenta l'utilizzo di forme generiche (dal segmento alla forma geo metrica complessa) si è scelto un approccio più simile a quello sfruttato dai programmi CAD meccanici, come Autodesk Inventor, che si basano sull'utilizzo esclusivo di forme geometriche chiuse – i profili - che hanno una rappresenta zione concreta come facce di oggetti tridimensionali e quindi transitano natu ralmente nell'ambiente 3D.

All'interno del modulo Planimetrie i profili sono implementati tramite la classe BasicProfile che, essenzialmente, contiene una lista di vertici (im plementati a loro volta dalla classe OpenTK.Math.Vector3), una lista di indi ci dei vertici che percorsa dall'inizio alla fine consente di disegnare il contor

14 Sviluppo no del profilo e alcuni altri dati necessari alla sua rappresentazione grafica; inoltre ogni oggetto BasicProfile contiene alcuni metodi di pertinenza pret tamente geometrica (es.: pointOnVertex che permette di capire se un dato punto si trova nei pressi di un vertice del profilo, o pointOnSide che permet te di capire se un dato punto si trova su un segmento del profilo) che tra le al tre cose sono necessari per l'interazione tra vista e modello, e un metodo (fi nish) da chiamare subito dopo la fine delle interazioni utente per eliminare i piccoli problemi che possono sorgere durante l'input e che di solito compro mettono i calcoli geometrici che vengono svolti successivamente (vertici du plicati o infinitesimamente vicini, ecc.).

I profili finora discussi, in tre dimensioni, si visualizzano come dei prismi potenzialmente concavi e possono essere utilizzati nel contesto della planime tria per rappresentare pareti separatrici interne alle stanze, gradini, ecc.; per rappresentare le pareti esterne di una planimetria occorre utilizzare un co mando apposito che crea una rappresentazione per la cinta muraria esterna e che consente successivamente di inserirvi le aperture richieste. A livello im plementativo, all'atto della generazione della cinta muraria l'oggetto di tipo BasicProfile viene promosso ad un oggetto di classe WallProfile, che de riva da BasicProfile e aggiunge una lista delle aperture del profilo e la lista dello spessore delle pareti.

3.4 Interfaccia grafica

Tenendo conto del requisito di massimizzare la semplicità dell'interfaccia grafica del programma si è scelto di combinare quelli che sono stati ritenuti i punti forti di tre programmi ben conosiciuti:

• Autodesk Inventor: si tratta di un modellatore solido parametrico svi luppato per l'ambito meccanico. La modellazione si basa principalmen te sulla costruzione di profili bidimensionali chiusi che vengono poi estrusi lungo percorsi lineari o curvi e sulla successiva aggiunta di “fea tures”, per esempio protrusioni che vengono modellate di nuovo dise

15 Sviluppo

gnando profili bidimensionali su una faccia del solido originale e succes sivamente estrusi. Inoltre, come in ogni modellatore parametrico, ogni modello disegnato tiene traccia di tutti i vincoli di disegno e di tutte le dimensioni del modello stesso, con la possibilità di modificarle interat tivamente e rigenerare di conseguenza il modello.

Questo software è stato ritenuto interessante perché fin dalle prime versioni, per rimediare il problema di sovraffollamento di comandi che ha sempre storicamente afflitto l'interfaccia grafica di altri programmi come AutoCAD, è stato utilizzato l'espediente di situazionalizzare l'ope ratività dell'utente, permettendo quindi di vedere solo i comandi “sen sati” nel contesto dell'operazione che l'utente sta svolgendo.

• Autodesk AutoCAD: è stato il primo software progettato per il disegno tecnico generico. Inizialmente solo bidimensionale, nel tempo si è evo luto per supportare anche oggetti 3D. Il prezzo della sua genericità è che AutoCAD non ha nessuna nozione di “correttezza” di un disegno o di relazioni tra primitive, che sono in questo senso “semplici”, non an dando oltre il mero simbolo grafico (per esempio, una polilinea è solo l'insieme dei suoi segmenti, e non esiste nessuna relazione persistente che indichi il fatto che il vertice finale di un segmento corrisponda al vertice iniziale di quello successivo).

L'elemento che è stato ritenuto interessante nell'interfaccia di questo software, che altrimenti nella sua associazione di toolbar di comando e area di disegno è piuttosto triviale, è la presenza di una console di co mando utile non solo per lanciare i comandi e immettere valori numeri ci senza staccare le mani dalla tastiera, ma soprattutto per descrivere lo stato dell'operazione in corso e le possibili opzioni per il prosieguo della stessa.

• Blender: forse il più famoso e completo software open source per la modellazione tridimensionale generica/organica. Nonostante non abbia praticamente nessuna funzionalità simile a quella di un software di di

16 Sviluppo

segno tecnico, e, ancor meno, parametrico, lo sviluppo della sua inter faccia grafica è sempre stato attento ad osservare gli interessanti prin cipi illustrati nel paper “The Evolution of Blenders User Interface” (Wil liam Reynish, 2008)1:

“[...] these key decisions were part of the original Blender design:

• It should be as non-modal as possible, and let the user access any part of the application instantly - optimal for solo artists and small studios who need to multitask.

• It should employ non-overlapping windows in a subdivision-based structure, to free the artists from moving windows around on the screen, and covering up content.”

Quindi, riassumendo, per soddisfare i requisiti che concernono l'interfaccia grafica e l'esperienza dell'utente si è scelto di fare in modo che:

• i comandi disponibili all'utente siano il più possibile contestualizzati;

• l'esecuzione di un comando composto non sia impegnativa per l'inter faccia stessa (nel senso in cui non sia necessario portare a termine un comando prima di poterlo annullare);

• esista un modo comune per annullare qualsiasi comando in corso d'ese cuzione;

• la necessità di avere finestre modali sia ridotta al minimo o annullata.

Inoltre sono stati inseriti vari ausili per l'utente durante il processo di dise gno; ispirandomi di nuovo ad AutoCAD ho implementato le funzionalità di gri glia, snap (ovvero il fatto che il cursore di disegno si sposti solo di determinati intervalli), e una barra di stato che enunci la prossima operazione che il pro gramma si aspetta dall'utente in un determinato momento e le coordinate di posizionamento attuale del cursore di disegno; durante le operazioni di dise

1 reperibile all'indirizzo http://download.blender.org/documentation/bc2008/evolution_of_blenders_ui.pdf

17 Sviluppo gno, poi viene visualizzato un tooltip che informa l'utente della distanza e dell'angolo del cursore rispetto all'ultimo punto inserito.

Di seguito possiamo vedere alcune immagini del risultato finale dell'imple mentazione di queste idee.

Nell'illustrazione 3 è rappresentata l'applicazione subito dopo l'apertura; si notano nell'area centrale la griglia (visualizzata come punti), e gli assi del si stema di riferimento che ne indicano l'origine e la scala; nella toolbar princi pale oltre ai comandi di creazione dei profili (rispettivamente Rettangolo, Po lilinea, Poligono regolare; vedere il paragrafo 3.5) e di misurazione, si vedono i pulsanti per attivare e disattivare griglia e snap, impostare i rispettivi inter valli, e passare alla visualizzazione tridimensionale.

18 Sviluppo

Nell'illustrazione 4 vediamo il risultato della contestualizzazione dei co mandi: alla selezione di un profilo appena inserito viene mostrata la toolbar contestuale che consente alcune semplici operazioni, come l'inserimento di un nuovo vertice all'interno di un segmento, lo spostamento del profilo, ecc. I vertici del profilo selezionato vengono evidenziati per consentire all'utente di spostarli con facilità.

Per la rappresentazione del lavoro dell'utente si è scelto di utilizzare il con trollo GLControl della libreria OpenTK, che consente di inserire un controllo in grado di ospitare un contesto di rendering di OpenGL in un'applicazione basata su Windows.Forms. Inoltre si è deciso di gestire manualmente lo z-order per quanto riguarda il rendering bidimensionale, disabilitando le scritture sul dep th buffer offerto da OpenGL.

19 Sviluppo

3.5 Comandi

I comandi disponibili all'utente sono stati suddivisi in comandi di creazione e di modifica; inizialmente l'interfaccia consente la visualizzazione dei soli co mandi di creazione dei profili, che sono:

• disegna rettangolo

• disegna poligono regolare

• disegna polilinea chiusa

Con la selezione della forma, appaiono i comandi di modifica, che sono:

• elimina

• unione booleana (è stato richiesto l'implementazione della sola unione, ma sarebbe stato semplice aggiungere anche sottrazione e intersezio ne)

• costruzione/eliminazione delle pareti del profilo

• inserisci/modifica apertura, nel caso in cui il profilo sia dotato di pareti

• elimina apertura, nel caso in cui al profilo ne siano state aggiunte

• spostamento dei vertici del profilo, che è sempre implicitamente possi bile dopo aver selezionato un profilo

• inserimento di un vertice all'interno di un segmento esistente

• spostamento del profilo nell'area di disegno

• modifica dell'altezza del profilo

3.6 Persistenza ed esportazione

La persistenza avviene tramite dei semplici file XML, il cui DTD è mostrato nel riquadro seguente:

20 Sviluppo

Come si può vedere esaminando la definizione, il documento è composto da una radice chiamata “structure” che contiene al suo interno uno o più “profi le” che ovviamente rappresentano i profili della planimetria; ogni profilo ha come attributo l'elevazione, che nel caso di profili con pareti diventa l'altezza delle pareti, e opzionalmente un materiale assegnato alla superficie orizzon tale.

Ogni profilo contiene il suo contorno, ovvero la lista ordinata dei vertici specificata dall'insieme dei tag di tipo “x”, e opzionalmente un materiale as segnato alle superfici verticali.

Nel caso in cui il profilo sia dotato di pareti l'elemento “profile” conterrà anche una serie di elementi “opening” i quali hanno come attributi il numero del lato del profilo a cui sono applicati e le misure sinistra, destra, sopra e sotto che ne descrivono il posizionamento all'interno della parete.

Infine, gli elementi di tipo “x”, che normalmente contengono solo le coor dinate di un vertice, nel caso in cui il profilo di cui fanno parte sia dotato di pareti, hanno come attributo lo spessore della parete il cui lato comincia dal vertice stesso.

21 Sviluppo

Per l'esportazione si è scelto di utilizzare il formato Wavefront .OBJ, in gra do di rappresentare solamente geometria statica, ovvero posizioni dei vertici, coordinate texture e normali delle superfici. Le caratteristiche di spicco per la sua adozione sono state la semplicità di lettura e scrittura e la sua ormai universale diffusione.

Da notare che nei file esportati in questo modo vengono esportate anche le coordinate delle texture, che vengono calcolate in modo che per ogni profilo all'interno della planimetria la superficie mappata appaia sempre contigua. L'unità di esportazione è stata sviluppata nel contesto dell'applicazione senza l'ausilio di alcuna libreria esterns.

3.7 Difficoltà implementative riscontrate

Sicuramente l'attività più difficile da portare a termine e più gravosa in ter mini di tempo è stata quella di scegliere ed implementare la triangolazione/scomposizione delle superfici complesse che costituiscono i profili delle piantine, passo necessario per la loro rappresentazione; sono sta te esaminate ed è stata eseguita una implementazione di tentativo di varie tecnologie, tra cui:

– Il paper "On the time bound for convex decomposition of simple poly gons" (M. Keil, J. Snoeyink)2 e la relativa applet java di esempio. La tra duzione da linguaggio Java a C# è stata quasi immediata data la somi glianza dei due linguaggi, ma purtroppo l'implementazione dell'algorit mo non gestisce situazioni particolari come punti sovrapposti, poligoni autointersecanti, poligoni con buchi (che provocavano regolarmente problemi di memoria e la chiusura dell'applicazione di esempio riscritta in C#). È stato fatto un tentativo di studio del paper per poter modifi care i comportamenti dell'applicazione o eventualmente per implemen tarlo da zero, ma questa attività si è presto rivelata troppo lunga e complicata da portare a termine.

2 reperibile all'indirizzo http://www.cs.unc.edu/~snoeyink/demos/convdecomp/MCDDemo.html

22 Sviluppo

– Il tessellatore della libreria libtess della OpenGL Utility Library (GLU). Questo tessellatore è piuttosto flessibile ed è stato pensato per gestire in modo robusto casi particolari o non del tutto corretti, quindi gestisce naturalmente i casi in cui l'utente inserisce un input errato. Il fattore che ne ha ritardato l'integrazione nel prodotto è stato il fatto che il codice era ovviamente scritto in C e che il binding a GLU offerto da OpenTK comportava l'utilizzo di componenti e metodi deprecati dal le versioni moderne di OpenGL e da OpenTK stesso. Questa situazione mi è apparsa tecnicamente inspiegabile, dato che la libreria GLU non dovrebbe essere strettamente collegata a OpenGL, in quanto si tratta di un set di funzioni di ambito computazionale il cui output non deve avere necessariamente un'interpretazione grafica e normalmente non comportano l'interfacciamento diretto con la GPU, onde per cui dovreb be poter essere sfruttata in linea di principio anche in ambienti privi di interfaccia grafica. Si è quindi pensato di reimplementare la libreria libtess in C# ma anche questa possibilità è stata velocemente scarta ta vista la quantità di codice da tradurre e la sua stretta dipendenza dall'aritmetica dei puntatori, che avrebbe incrementato ulteriormente la difficoltà dell'impresa.

Si è scelto di usare il binding a GLU offerto dalla libreria OpenTK.Compati bility. Questa decisione non è stata però priva di conseguenze negative, in quanto ci si è dovuti scontrare con la gestione dei puntatori di C#, un argo mento non privo di questioni difficili da risolvere soprattutto per chi, come me, si è avvicinato da poco al linguaggio. D'altra parte, tutte le altre soluzioni utilizzabili, sia per motivi di licenza che di facilità di integrazione, non riusci vano ad elaborare i poligoni nei quali fossero presenti dei fori, condizione as solutamente necessaria per la riuscita del progetto, dato che il poligono fora to è la tipica entità che rappresenta la superficie superiore della muratura che circonda una planimetria.

23 Sviluppo

3.8 Pattern software utilizzati

3.8.1 State pattern: implementazione dei comandi utente

L'utilizzo di comandi avanzati per il disegno, come quelli per inserire o mo dificare le aperture in una parete, richiede l'immissione di un certo numero di parametri, sicuramente in numero superiore a quelli esprimibili usando sola mente il mouse. Tipicamente si risolverebbe il problema in maniera semplice - dal punto di vista dello sviluppo - sfruttando una finestra di dialogo (o, even tualmente, un wizard) nella quale inserire i valori necessari, ma si è ritenuto fattibile avere un sistema che non introduca passi forzati o dove questi si pos sano comunque svolgere in maniera naturale e intuitiva.

Per questo motivo si è scelto di implementare l'architettura di esecuzione dei comandi come una macchina a stato (utilizzando quindi il pattern ingegne ristico “state”), con una modalità simile a quella già usata da AutoCAD: alla selezione di un comando il sistema offre inizialmente un insieme di scelte pos sibili (l'inserimento di queste scelte avviene di solito, in AutoCAD, tramite console) e successivamente una serie di passi, ognuno dei quali prevede l'inse rimento di un valore o la selezione di parti dell'area di disegno.

Ognuno di questi passi può essere visto come uno stato di una macchina a stati, la cui implementazione semplifica e aiuta a organizzare il codice, of frendo nel contempo benefici quali:

• la possibilità di guidare facilmente l'utente nello svolgimento di un compito (nella fattispecie tramite dei messaggi che appaiono nella bar ra di stato dell'applicazione);

• donare flessibilità allo svolgimento di un comando, permettendo scelte diverse durante l'inserimento dei suoi parametri (per esempio, per inse rire un'apertura in un muro si può decidere di misurarne le dimensioni in altezza partendo dal pavimento o dal soffitto, e la misura successiva può essere relativa a quella appena presa o assoluta, di nuovo, rispetto al pavimento o al soffitto).

24 Sviluppo

Per il secondo punto, in particolare, sono stati utilizzati dei “sub-stati”, che all'interno del codice non sono rappresentati da alcuna classe ma sono im plementati tramite semplici istruzioni di controllo (quindi tramite “switch” o “if”). All'interno dell'applicazione si passa da un sub-stato a quello successivo tramite la pressione della barra spaziatrice.

Gli stati individuati per il funzionamento dell'applicazione sono individuati nella tabella seguente.

Nome Attiv.3 Scopo Stato iniziale; l'applicazione si trova in stato Select1 P pronto; nessun profilo è attualmente selezionato È stato selezionato un profilo, che viene Select2 P evidenziato; viene mostrata la toolbar contestuale Scegliere il lato di un profilo su cui si andrà ad AddOpening1 C inserire un'apertura Indicare il punto, sul lato selezionato, da cui far AddOpening2 P partire l'apertura AddOpening3 P Indicare il punto in cui far finire l'apertura AddOpening4 P Indicare l'altezza iniziale dell'apertura AddOpening5 P Indicare l'altezza finale dell'apertura Scegliere un lato del profilo in cui inserire un BreakSegment C nuovo vertice DeleteOpening C Scegliere l'apertura da eliminare Scegliere una parete del profilo selezionato per EditDepth1 C modificarne lo spessore EditDepth2 P Indicare lo spessore della parete EditHeight C Indicare la nuova altezza del profilo Indicare il primo punto di una polilinea da FreePolygon1 M aggiungere al documento FreePolygon2 P Indicare i punti successivi della polilinea 3 Attivazione: M = attivato direttamente dalla toolbar principale; C = attivato direttamente dalla toolbar contestuale; P = attivato indirettamente da un altro stato;

25 Sviluppo

Nome Attiv. Scopo Indicare il punto iniziale dello spostamento per il MoveProfile1 C profilo corrente Indicare il punto finale dello spostamento per il MoveProfile2 P profilo corrente Indicare il punto in cui posizionare il vertice che si PullVertex P sta trascinando Indicare il punto iniziale della diagonale del Rectangle1 M rettangolo Indicare il punto finale della diagonale del Rectangle2 P rettangolo RegularPolygon1 M Indicare il punto centrale di un poligono regolare Indicare il punto finale del raggio di un poligono RegularPolygon2 P regolare Scegliere una superficie su cui applicare una Select3D P texture Union2 C Scegliere il profilo con cui unire il profilo corrente

26 Sviluppo

Di seguito possiamo vedere alcuni esempi delle transizioni più interessanti.

l'illustrazione 5 mostra, per esempio, gli stati in cui si può arrivare senza usare nessuno dei pulsanti della toolbar principale e di quella contestuale.

27 Sviluppo

L'illustrazione 6 mostra invece le transizioni necessarie all'inserimento di una polilinea all'interno del documento (per chiarezza sono stati omessi tutti gli stati e le transizioni già inserite nell'illustrazione 5).

28 Sviluppo

Infine, vediamo attraverso il diagramma 7 l'inserimento di un'apertura in una parete. Anche qui, per maggior chiarezza, sono stati omessi tutti gli stati e le transizioni non direttamente necessari allo svolgimento dell'operazione.

La compartimentazione delle proprietà di ogni singolo stato garantita dall'implementazione di questo pattern consente di interrompere un'operazio ne non ancora completata con la certezza che non ci sia nessuna variabile di stato globale che resti valorizzata in modo inappropriato, creando bug spesso difficili da scoprire.

Per lo stesso meccanismo è anche possibile, con un'unica azione, annullare l'operazione corrente per passare direttamente ad un'altra; per esempio, uno dei comportamenti supportati è l'interruzione dell'inserimento di una polilinea per passare all'inserimento di un rettangolo, o di un poligono regolare.

Inoltre in questo modo è stato implementato il pulsante ESC come pulsante di “reset” dello stato.

3.8.2 Command pattern: annulla/ripeti operazione

Il meccanismo di annulla/ripeti delle modifiche è stato implementato tra mite il pattern command, utilizzando una classe base astratta chiamata Un doAction. Da questa classe derivano quattro classi concrete:

• UndoActionCreate: annulla la creazione di un profilo; contiene un ri ferimento al profilo creato.

• UndoActionDelete: annulla la cancellazione di un profilo; contiene un riferimento al profilo eliminato.

• UndoActionBoolean: annulla un'operazione booleana tra due oggetti; contiene i riferimenti agli oggetti di origine (che vengono eliminati dal documento immediatamente) e a quelli creati in seguito all'operazione stessa.

• UndoActionModify: è la classe di annullamento per tutte le altre ope razioni di modifica che avvengono su un profilo. Anziché fare considera

29 Sviluppo

zioni sulla natura della modifica, per semplicità si limita a ricordare la versione precedente del profilo e a ripristinarla secondo necessità.

Il meccanismo di undo/redo è basato su due stack di oggetti UndoAction contenute nel documento (rappresentato dalla classe Document), una per gli annullamenti (S1) e una per i rifacimenti (S2). Quando un comando viene por tato a termine, viene costruito un oggetto della classe corrispondente all'azio ne eseguita e inserito in cima a S1. Nel caso in cui si voglia annullare l'ultima operazione, viene chiamato il metodo undo() dell'oggetto in cima alla pila, dopodiché questo viene ricollocato in cima a S2. Nel caso in cui si voglia inve ce rifare l'ultima operazione, viene chiamato il metodo redo() dell'oggetto in cima a S2 che viene successivamente ricollocato in cima a S1. Quando viene aggiunto un nuovo elemento a S1, S2 viene ripulita.

30 Verifica e validazione

4. Verifica e validazione

Durante lo sviluppo del progetto, i maggiori fattori di rischio di inserimento di errori nel codice sono stati:

• poca esperienza con le tecnologie usate: non avendo una conoscenza approfondita delle tecnologie usate si è portati a scelte implementati ve spesso subottimali;

• presenza di un unico sviluppatore: avere un unico sviluppatore che si occupa di un progetto comporta che egli debba svolgere sia le attività di codifica che quelle di verifica; questa situazione si traduce normal mente in una verifica inefficace, in quanto di solito il programmatore interagisce con il sistema usando lo stesso ordine delle operazioni che ha sempre seguito e che di solito corrisponde all'ordine con cui ha im plementato le feature, tralasciando magari percorsi alternativi che do vrebbero portare allo stesso risultato e invece falliscono;

• poca documentazione: soprattutto per quanto riguarda la libreria OpenTK e alcune caratteristiche all'apparenza “esotiche”, ma assoluta mente necessarie per la riuscita del progetto, la documentazione è scarsa o addirittura assente. Questo allunga lo sviluppo del progetto in troducendo ore in cui l'implementazione deve procedere per tentativi ed errori e al cui termine non si può essere certi che il codice risultante funzioni in tutti i casi previsti.

Si è adottata quindi la strategia di applicare tecniche di analisi statica e di namica sistematicamente e fin dal principio, assicurandosi che l'inserimento di ogni nuova caratteristica fosse il più possibile esente da errori nel codice.

31 Verifica e validazione

4.1 Analisi statica

Con l'espressione analisi statica ci si riferisce all'insieme delle tecniche uti lizzate per esaminare il codice sorgente di un programma senza la necessità di eseguirlo.

4.1.1 Code review

La code review consiste nell'esame del codice sia da parte di chi l'ha scritto che da altre persone, con lo scopo di arrivare ad un consenso comune sulla qualità e validità dei sorgenti esaminati.

Sono anche un buon modo per consentire ai programmatori di minore espe rienza di imparare nuove e migliori tecniche di sviluppo.

Nella fattispecie, si sono utilizzati gli strumenti di livello basilare forniti dall'IDE, in grado di trovare codice irraggiungibile, variabili inutilizzate o non inizializzate e, grazie alla disponibilità offerta dal tutor aziendale, sono state condotte fin da subito delle review sistematiche per evidenziare immediata mente i possibili errori e le carenze del codice scritto.

4.2 Analisi dinamica

Al contrario dell'analisi statica, l'analisi dinamica intende esaminare il codi ce durante l'esecuzione, attraverso l'applicazione di una serie di casi di test.

4.2.1 Uso di asserzioni

Un'asserzione è una dichiarazione posta in un programma per indicare una condizione che viene ritenuta dallo sviluppatore, in una data situazione, sem pre verificata.

L'uso delle asserzioni è stato un prezioso aiuto per testare il codice e rile vare errori magari banali ma comunque sfuggenti a una prima revisione, so prattutto nelle parti che hanno a che fare maggiormente con algoritmi (es. costruzione della rappresentazione tridimensionale). Le asserzioni, inoltre,

32 Verifica e validazione hanno contribuito alla documentazione del codice mettendo in evidenza pre condizioni e postcondizioni delle parti in cui la sintassi diventa maggiormente basata su operatori che su termini più discorsivi (come chiamate a metodi); questa situazione si ritrova facilmente nell'uso di librerie dedicate all'elabora zione matematica o geometrica, qual'è per esempio la libreria OpenTK.Math, che si occupa delle operazioni vettoriali e matriciali alla base di OpenTK.

4.2.2 Test di unità e di integrazione

Per la verifica dinamica del software sviluppato sono state costruite delle planimetrie di varia complessità e dimensione, sia dall'interno del programma che “artificialmente” usando un editor di testo per creare dei file ad hoc di planimetria in formato XML.

I test si sono concentrati sulle seguenti unità:

• interfaccia grafica, per verificare che i passaggi di stato previsti dalla specifica siano rispettati e che ogni comando si comporti in maniera corretta;

• algoritmi di geometria computazionale, utilizzati nelle interazioni tra interfaccia grafica e modello dati sottostante;

• modifica del modello, utilizzando ripetutamente tutte le tecniche per inserire e rimuovere elementi nelle planimetrie;

• salvataggio e caricamento delle planimetrie;

• esportazione delle planimetrie in formato Alias Wavefront;

• funzionalità undo / redo, per controllare che tutti i comandi vengano annullati e ripetuti correttamente;

In seguito sono stati eseguiti i test di integrazione, componendo varie se quenze di utilizzo che facessero interagire le varie unità. Il sistema in tal sen so si è dimostrato robusto, in quanto tra le varie unità (e possibilmente anche all'interno delle unità stesse, come spiegato alla fine del capitolo 3.8.1) vi è

33 Verifica e validazione una netta compartimentazione delle variabili di stato, quindi l'interazione è piuttosto limitata e le possibilità di interferenza sono minime.

4.3 Strumenti di analisi

Principalmente per effettuare i test si è utilizzato il debugger integrato in Visual Studio, molto veloce e flessibile nell'applicare breakpoint anche condi zionati, sorprendente per la capacità di modificare al volo il codice e prose guirne l'esecuzione.

Sono stati usati anche gli strumenti interni all'IDE per la costruzione dei test automatizzati, che nonostante la limitata applicabilità per il forte orien tamento all'interazione tramite interfaccia grafica, hanno permesso di verifi care efficacemente le parti riguardanti la persistenza e l'esportazione delle planimetrie.

34 Considerazioni conclusive

5. Considerazioni conclusive

5.1 Lavoro svolto

Lo scopo del progetto di stage era di sviluppare da zero, portandolo ad uno stadio perlomeno vicino a quello di pre-produzione, in cui cioè le caratteristi che fossero ben definite e implementate ad un livello di maturità sufficiente a garantire un'esperienza d'uso ragionevolmente stabile e funzionale.

A fronte di tali obbiettivi, e del collaudo finale effettuato insieme al tutor aziendale, Massimo Dal Toso, si può affermare che l'esperienza di stage abbia avuto esito positivo, raggiungendo gli scopi prefissati. Dal Toso si è dichiarato soddisfatto del lavoro svolto.

Verso la fine del periodo di sviluppo è stato nominato un nuovo requisito per l'applicazione, ovvero la possibilità di prelevare le texture direttamente dal server di TCE. L'implementazione di questo requisito avrebbe permesso al modulo Planimetrie di integrarsi in maniera molto migliore con TCE, ma avrebbe possibilmente richiesto una revisione architetturale del programma per cui, data anche l'approssimarsi della fine dell'esperienza, lo sviluppo di questo requisito è stato ignorato.

5.2 Consuntivo delle attività

Lo stage ha avuto una durata di 40 giorni lavorativi per un totale di 320 ore. La pianificazione iniziale ipotizzata dopo i colloqui preliminari con il tutor aziendale è esposta nel diagramma di GANTT in figura 9 ed è stata sostanzial mente rispettata.

35 Considerazioni conclusive

Formazione

Analisi

Progettazione

Codifica

Verifica

0 5 10 15 20 25 30 35 40 Giorni

Illustrazione 9: Consuntivo delle attività 5.3 Conoscenze applicate e nuove conoscenze acquisite

Lo stage è stata una buona occasione per mettere alla prova le conoscenze acquisite durante il corso di studi e quelle accumulate durante le mie espe rienze personali e per avere una sostanziosa introduzione a nuove tecnologie e strumenti.

Le conoscenze pregresse che mi sono state utili, oltre ovviamente ad una buona padronanza della programmazione a oggetti, indispensabile per lo svi luppo di un'applicazione moderna e per la costruzione corretta dei pattern software, sono state: alcune nozioni di geometria computazionale, la pro grammazione grafica tramite OpenGL (di cui ho maturato un'estesa conoscen za nonostante non abbia seguito il corso dedicato durante gli studi), il meta linguaggio XML usato per l'esportazione dei documenti e ovviamente lo studio dell'ingegneria del software per il riconoscimento e l'applicazione dei pattern ingegneristici.

Le conoscenze che ho acquisito riguardano soprattutto l'utilizzo degli stru menti di sviluppo Microsoft, mai affrontati durante il corso di studi, come la

36 Considerazioni conclusive libreria .NET e il linguaggio C#, utilizzati frequentemente nel mondo lavorati vo odierno, e l'ambiente di sviluppo Visual Studio.

5.4 Conclusioni

Riguardo gli obbiettivi personali e formativi presentati nel capitolo intro duttivo, considero l'esperienza di stage compiuta in modo decisamente positi vo: mi sono state date le possibilità di lavorare in un ambiente produttivo rea le e di confrontarmi con i problemi che ne derivano, di mettere a frutto gli in segnamenti e le nozioni assimilate durante il corso di studi e di familiarizzare con strumenti diffusamente sfruttati nel mondo del lavoro ma mai approfondi ti dal corso di laurea per motivi pratici, di pensiero e di tempo.

Inoltre, la soddisfazione del tutor aziendale nell'avere un prodotto funzio nante, praticamente completo e dotato di un'interattività accattivante ha te stimoniato l'efficacia del processo di sviluppo nella sua interezza.

Concludendo, personalmente considero lo stage svolto presso un'azienda esterna uno strumento estremamente potente e utile per avere una visione in troduttiva della realtà lavorativa, e un'esperienza interessante e a suo modo divertente che può quasi certamente contribuire ad arricchire il bagaglio cul turale di chi la vive.

37 Glossario

6. Glossario

API: acronimo di Application Program Interface (interfaccia di programmazio ne applicazioni); insieme di procedure messe a disposizione del programmato re da un'applicazione o da una libreria.

Application virtual machine: applicazione che permette di eseguire altri pro grammi, in genere su sistemi operativi diversi, astraendo i dettagli della mac china o del sistema operativo sottostante.

Breakpoint: punto di interruzione nel codice di un programma, inserito dallo sviluppatore a scopo di debug.

CAD: acronimo di Computer Aided Design (progettazione assistita dal calcola tore); indica l'insieme dei programmi creati per il disegno tecnico ee la produ zione industriale.

Codice gestito: codice che può essere eseguito solamente all'interno di una application virtual machine.

Coordinate texture: vedere Texture.

Depth buffer: durante il rendering di una scena tridimensionale, area di me moria che contiene i valori di profondità di ogni singolo pixel.

39 Glossario

ERP: acronimo di Enterpise Resource Planning, letteralmente “pianificazione delle risorse di impresa”, è un sistema informativo che integra tutti i processi di business di un'azienda.

Foss: acronimo di free and open source software (software libero e i cui sor genti sono disponibili).

Framework: piattaforma software riusabile utilizzata per lo sviluppo di appli cazione.

GLU: OpenGL Utility Library, libreria di supporto allo sviluppo di applicazioni OpenGL.

ICT: acronimo di Information and Communication Technology. Identifica l'insieme di sviluppo, gestione e utilizzo dei sistemi informativi computerizza ti, con particolare accento sul ruolo della comunicazione unificata e l'integra zione di telecomunicazioni, software studio, progettazione, sviluppo, imple mentazione, supporto e gestione dei sistemi informativi computerizzati, con particolare attenzione alle applicazioni software ed ai componenti hardware che le ospitano.

Linguaggio dichiarativo: linguaggio che permette di specificare un program ma o parte di esso senza descrivere il suo flusso di controllo.

40 Glossario

Rendering: vedere Rendering accelerato

Rendering accelerato: generazione di immagini a partire da un insieme di re gole o descizioni. Il termine “accelerato” indica che la generazione avviene su dispositivi hardware specifici (schede video).

Stack: struttura dati che permette solo le operazioni di inserimento ed estra zione, in cui il primo elemento estratto è anche l'ultimo inserito.

Tessellatore: applicazione in grado trasformare figure geometriche complesse in figure più semplici basandosi su determinati criteri.

Texture (mapping): applicazione di un'immagine su una superficie.

Thin wrapper: letteralmente “involucro sottile” indica una procedura il cui scopo principale è di richiamare un'altra procedura.

Wizard: tipo di interfaccia utente che presenta all'utente una serie di finestre di dialogo che conducono l'utente attraverso una sequenza di passi ben defini ta.

Z-order: vedere Depth buffer