Università degli Studi di Torino Facoltà di Scienze M.F.N...

Università degli Studi di TorinoFacoltà di Scienze M.F.N.

Corso di Laurea in Matematica

TESI DI LAUREA

Matematica creativa in

“Rich Internet Applications” (RIA)

Relatore:

Prof.ssa Catterina Dagnino

Candidato:

Walter Bugliarelli

ANNO ACCADEMICO 2007-2008

Indice

Introduzione v

1 Applicazioni Internet e Web 1

1.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Applicazioni Internet . . . . . . . . . . . . . . . . . . . . . . . 1

1.3 Il modello client-server . . . . . . . . . . . . . . . . . . . . . . 2

1.4 Problemi di installazione . . . . . . . . . . . . . . . . . . . . . 3

1.5 Applicazioni Web . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.6 Le principali tecnologie utilizzate . . . . . . . . . . . . . . . . 5

1.7 Le Rich Internet Application . . . . . . . . . . . . . . . . . . 7

2 Lo stato dell’arte delle RIA e Adobe Flex 3 11

2.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2 Sicurezza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3 Aspetti economici . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4 Tipi di RIA e confronti . . . . . . . . . . . . . . . . . . . . . . 15

2.5 Adobe Flex 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 Testo 3D 20

3.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2 Modello matematico . . . . . . . . . . . . . . . . . . . . . . . 20

3.3 Applicazioni possibili . . . . . . . . . . . . . . . . . . . . . . . 27

3.4 Analisi del codice . . . . . . . . . . . . . . . . . . . . . . . . . 32

4 Simulatore 3D di urti elastici 36

4.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

ii

INDICE iii


4.3 Interfaccia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43


4.5 Il modello di gestione degli eventi . . . . . . . . . . . . . . . . 46

4.6 Analisi del codice . . . . . . . . . . . . . . . . . . . . . . . . . 48

5 Disegno di curve 55

5.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.2 Funzionamento . . . . . . . . . . . . . . . . . . . . . . . . . . 56



5.5 Struttura del codice . . . . . . . . . . . . . . . . . . . . . . . 64

5.5.1 Classi astratte e polimorfismo . . . . . . . . . . . . . . 64

5.5.2 Classe DrawingTarget . . . . . . . . . . . . . . . . . . 67

5.5.3 Classe DrawingObject . . . . . . . . . . . . . . . . . . 68

5.5.4 Le classi Line e Polygon . . . . . . . . . . . . . . . . . 69

5.5.5 La classe BSpline . . . . . . . . . . . . . . . . . . . . . 70

5.6 La gestione degli eventi del mouse all’interno dell’applicazione 75

6 La distribuzione sul Web: confronto tra Flex e Matlab 79

6.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

6.2 Distribuire un’applicazione MATLAB in formato eseguibile

attraverso il web . . . . . . . . . . . . . . . . . . . . . . . . . 80

6.3 Il MATLAB Component Runtime . . . . . . . . . . . . . . . . 82

6.4 Matlab e Java . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

6.5 Costruzione di un’applicazione Java . . . . . . . . . . . . . . . 83

6.5.1 MATLAB e le servlet Java . . . . . . . . . . . . . . . . 85

6.6 Confronto tra i due pacchetti . . . . . . . . . . . . . . . . . . 88

6.7 Considerazioni . . . . . . . . . . . . . . . . . . . . . . . . . . 90

Appendice 92

A Flex ed alcune caratteristiche della programmazione orien-

tata agli oggetti 92

INDICE iv

Glossario 96

Bibliografia e sitografia 100

Introduzione

Questa tesi è iniziata presso la EBIT Projects di Torino, azienda in cui

ho svolto uno stage sotto la guida dell’Ing. Franco Chiesa, che è stato il mio

referente, e che desidero ringraziare per la disponibilità e competenza.

Durante lo stage sono entrato in contatto con le “Rich Internet Applica-

tion”, o più semplicemente RIA. Le RIA sono particolari ed innovative ap-

plicazioni Web che portano numerosi vantaggi rispetto a quelle tradizionali,

tra cui una maggior interattività, un “Look & Feel” più intuitivo e appetibile

e, infine, un notevole aumento in termini di reattività del software.

L’azienda si avvantaggia delle potenzialità di questa nuova tecnologia per

creare moduli software altamente interattivi, atti a fornire nuove funzionalità

ai siti Web delle aziende clienti. Durante lo stage ho avuto la possibilità di

entrare nel ciclo produttivo di una di queste applicazioni, cosa che mi ha

permesso di padroneggiare l’uso di “Adobe Flex 3”, il pacchetto di riferimento

usato in Azienda per la progettazione ed implementazione di RIA.

Flex 3 è un software molto versatile che permette di creare applicazioni

non solamente di tipo aziendale, ma anche rivolte alla creatività, alla pub-

blicità e alla didattica. Sempre sotto la guida dell’Ing. Chiesa, ho pertanto

sviluppato tre applicazioni di esempio che mostrano sia la versatilità di Flex

3 sia le potenzialità delle RIA nel portare sul Web contenuti innovativi.

La parte iniziale del lavoro spiega che cosa è un’applicazione Web classica

e perché le RIA ne rappresentino l’evoluzione.

Viene successivamente presentato l’attuale stato dell’arte di queste nuova

tipologia di software e si focalizza l’attenzione su alcuni aspetti economici

riguardanti sia gli sviluppatori sia gli utenti delle RIA, su alcuni aspetti a

proposito dei parametri di sicurezza che le tecnologie per la costruzione di

RIA devono rispettare e su alcune limitazioni di cui soffre questo tipo di

applicazioni. Si considerano, infine, alcune tecnologie preposte allo sviluppo

di RIA, in particolare Flex.

Nelle sezioni successive si descrivono tre applicazioni, che sono state svi-

luppate in Flex, che ne dimostrano le potenzialità. In esse la matematica ha

un ruolo creativo.

La prima visualizza un campo di testo che fluttua nello spazio in ba-

INTRODUZIONE vi

se a formule parametriche, ed è interessante perché presenta un ambiente

tridimensionale nonostante Flex non disponga di librerie per il disegno 3D.

La seconda mostra un cubo con delle sferette che si scontrano l’un l’al-

tra in un un susseguirsi di urti totalmente elastici, l’interfaccia permette di

ruotare il cubo a piacere e di cambiare i parametri di massa e dimensione di

ogni singola pallina per vederne il comportamento.

La terza presenta un piccolo programma di grafica vettoriale nel quale si

possono disegnare alcune forme con un approccio diverso da quello di altri

pacchetti di disegno. Il codice di ognuna di queste applicazioni, inoltre, è

basato su concetti matematici e fisici appresi nel corso di Laurea in Mate-

matica. Questo aspetto mostra la fattibilità, dal punto di vista didattico,

di illustrare nozioni, anche complesse, sul Web, con applicazioni altamente

interattive.

L’ultimo capitolo riguarda le possibilità fornite dal pacchetto “Matlab”

per portare le applicazioni scritte nel proprio linguaggio sul Web oltre a

presentare alcuni confronti tra Matlab stesso e Flex.

In appendice vengono richiamati i fondamenti della programmazione ad

oggetti.

Capitolo 1

Applicazioni Internet e Web

1.1 Introduzione

1 In questo capitolo si vuole ripercorrere sommariamente l’evoluzione

delle applicazioni informatiche accessibili da remoto. Pertanto, viene dap-

prima introdotto il modello client-server, dominatore incontrastato dell’era

pre-Internet, successivamente vengono illustrate le principali tecnologie uti-

lizzate nella costruzione di applicazioni Web fino all’ultima frontiera di que-

st’ultime: le “Rich Internet Application” (RIA). Per ogni passaggio evolutivo,

vengono spiegate le limitazioni delle tecnologie utilizzate precedentemente ed

i vantaggi delle successive.

1.2 Applicazioni Internet

Le applicazioni Internet sono software più o meno interattivi fra due o più

computer che utilizzano Internet come network di comunicazione. Pertanto

sono, in realtà, costituite da due parti differenti: la prima è quella delegata a

permettere all’utente di controllare l’applicazione stessa e che ne rappresenta

l’interfaccia, la seconda è il cuore vero e proprio del software ed è installata

e funzionante su una macchina remota (server).

Un esempio di applicazione Internet è la posta elettronica: l’interfaccia

al servizio è rappresentata da uno dei tanti software di posta elettronica (Mi-1Nota al testo: I termini seguiti da (*), e.g. “Intranet*”, sono definiti nel Glossario.

1

CAPITOLO 1. APPLICAZIONI INTERNET E WEB 2

crosoft Outlook, Mozilla Thunderbird etc.) che, opportunamente installato e

configurato con i parametri dell’account*, ci permette di connetterci al server

di posta del “provider*”, accedere alla nostra casella e “scaricare*” sul nostro

computer le e-mail che verranno poi archiviate, organizzate e conservate dal

programma di posta stesso.

1.3 Il modello client-server

Molto prima dell’avvento di Internet e del relativo concetto di rete delle

reti e di rete globale, l’idea di applicazioni accessibili tramite una rete di col-

legamento tra computer, si concretizzava mediante il modello “client-server”.

Con il termine client si intende il programma che gira sulla macchina

locale utilizzando, per la propria elaborazione, delle risorse che risiedono

sul server. Il server è un computer o un sistema di computer interallacciati

(cluster), che, in partizione di tempo (time-sharing) o in parallelo, forniscono

“servizi” ai client che li richiedono. I servizi partizionati possono essere:

basi di dati, potenza di calcolo, connettività etc che i diversi client possono

utilizzare come se fossero propri. Per molti anni questa fu l’architettura

predominante e anche oggigiorno è ampiamente utilizzata. Il successo è

stato decretato dal fatto che il terminale (o client), la macchina su cui gira il

software client, può essere limitata nella prestazioni e quindi economica, fatto

questo determinante nei primi anni dell’era informatica. La poca potenza

richiesta dai terminali era dovuta al fatto che il software lato-server risiedeva

su un mainframe* ed era progettato per soddisfare contemporaneamente le

richieste di più terminali.

Il maggior problema di questa soluzione è che una qualsiasi miglioria

apportata all’applicazione sul server richiede generalmente di installare su

ogni client una nuova versione del software lato-client con un conseguente

aumento dei costi di manutenzione e rallentamento di produttività.

Non bisogna pensare che questo modello sia in disuso. Un esempio ce-

lebre di architettura client-server è l’“X Window System”. Originariamente

sviluppato al MIT nel 1984, l’X Window System è una tecnologia che per-

mette a dei cosiddetti “X terminal ”, computer economici ma comunque con

delle capacità grafiche, di visualizzare ed utilizzare una GUI* demandando


il lavoro di calcolo dovuto al disegno e al movimento delle finestre e alla ge-

stione del mouse e della tastiera ad un server (“X Server”) che è in grado di

fornire questo servizio a più terminali contemporaneamente. Questo modello

è implementato su tutti i sistemi UNIX* e UNIX-like (Linux, Solaris etc.)

ancora oggi, anche se ormai il software lato server è anch’esso installato sulla

macchina locale in quanto i moderni computer non hanno più difficoltà a

gestire GUI complete da soli.[1]

1.4 Problemi di installazione

Le difficoltà di aggiornamento suddette e relative alla configurazione dei

client non rappresentano un problema quando l’area di utilizzo dell’applica-

zione è quello di una azienda, anche grossa, o di un’università: generalmente,

infatti, in questi ambiti è previsto personale adibito alla manutenzione dei

terminali e ad istruire il personale o gli studenti alle nuove funzionalità. Con

l’avvento di Internet e del World Wide Web2 si è creata la possibilità di

sviluppare ed utilizzare software che comunicassero con server, o semplice-

mente con altri PC come nel caso delle applicazioni “peer to peer*”, locati

in qualsiasi parte del globo. Oggi utilizziamo applicazioni che si avvalgono

di un collegamento ad Internet in continuazione: forum, webmail, blog, aste

on-line etc. Si può facilmente capire i problemi di dover installare sulla pro-

pria macchina programmi client che permettano di interfacciare tutti questi

servizi.

Elenchiamone i principali. Prima di tutto il produttore del software do-

vrebbe rilasciare una versione del client compatibile con il maggior numero di

sistemi operativi possibile, l’utente, di conseguenza, dovrebbe essere in gra-

do di “scaricare”, dal sito web di supporto, la versione giusta per il proprio

PC e saperla installare; operazioni queste non sempre banali soprattutto su

sistemi UNIX-like, in particolare Linux. Inoltre, mentre risulta accettabile2Non bisogna confondere Internet con il Web: con il primo termine si intende una rete

telematica mondiale costituita da diverse sotto-reti locali non compatibili l’una con l’altra

ma che comunicano mediante una serie di protocolli comuni, con il secondo si intende una

rete libera di documenti multimediali collegati l’un l’altro da collegamenti ipertestuali

incorporati nei documenti stessi e basata su Internet


installare software lato-client per i principali strumenti di lavoro di una po-

stazione, non è immaginabile pensare di dover preoccuparsi di configurare il

computer per tutte quelle applicazioni che necessitano di accedere ad Inter-

net sia perché sono moltissimi i servizi basati sulla Rete sia perché molti di

questi vengono usati saltuariamente e non giustificano quindi il tempo perso

per l’eventuale manutenzione dei client. Questi problemi vengono in larga

parte risolti dalle “applicazioni Web”

1.5 Applicazioni Web

Le applicazioni Web sono particolari applicazioni Internet. L’interfaccia

non è più demandata ad un software installato sul client ma viene fornita

dal server stesso che la invia all’utente non appena questo la richieda recan-

dosi mediante un qualunque browser* alla pagina web preposta al controllo

dell’applicazione stessa.

Un esempio in tal senso è la “webmail ”. L’utente non deve più procurarsi,

installare ed aggiornare un software client di posta elettronica ma si reca alla

pagina web preposta e il browser visualizzerà un’interfaccia, generalmente

intuitiva, comprendente tutte le funzionalità necessarie alla gestione della

casella.

I vantaggi di questa soluzione, oltre alla comodità del fruitore del ser-

vizio di non dover installare l’applicativo client, sono parecchi. Prima di

tutto la casella di posta sarà facilmente raggiungibile da qualsiasi PC con

una connessione Internet, ad esempio da un “Internet-Point* ”, posto dove

non è proponibile l’idea di installare e configurare programmi per le esigenze

del singolo individuo per ovvi motivi. In secondo luogo il produttore dei pro-

grammi necessari non dovrà più scrivere versioni specializzate dei client per

ogni sistema operativo perché, come vedremo, utilizzerà tecnologie standar-

dizzate che, salvo relativamente piccoli problemi di incompatibilità dovute

alle varie versioni dei browser, forniscono all’utente la garanzia di ritrovarsi

la medesima interfaccia su ogni tipo di macchina e ai programmatori di scri-

vere una sola versione della medesima. Un terzo motivo, non trascurabile,è

dovuto al fatto che queste interfacce visualizzate nei browser sono general-

mente progettate ed implementate per integrarsi al meglio con i comandi


tipici dei browser; l’utente troverà quindi un ambiente subito famigliare con

pulsanti per sfogliare le varie pagine, con comandi per ingrandire il testo, per

visualizzare il programma a “tutto schermo” etc.. Il più delle volte, quindi,

le funzionalità classiche fornite dai browser forniscono ai produttori dei soft-

ware la possibilità di risparmiare ore e ore di lavoro che sarebbero necessarie

per costruire un’applicazione standard con una ovvia riduzione dei costi.

1.6 Le principali tecnologie utilizzate

Quando scriviamo un indirizzo web nella apposita barra3 di un browser

questo invia una richiesta ad un server web per ottenere, come risposta da

questo, la pagina da visualizzare. La risposta inviata dal server al browser è

costituita da un testo semplice codificato secondo le specifiche del linguaggio

di “mark-up”4 HTML/XHML5 che descrive il contenuto logico e lo stile6

per la formattazione della pagina. Ora la pagina HTML visualizzata nel

browser è “statica” cioè non fornisce una interattività in tempo reale né a

livello dell’interfaccia né al livello di comunicazione col server. Poter creare

pagine che dialoghino con il web-server è fondamentale per offrire all’utente

la possibilità di avvalersi di applicazioni web.

La prima tecnologia ideata per tale scopo fu la “Common Gateway Inter-

face” (C.G.I.), un protocollo [2] che definisce uno standard di comunicazione

fra il web-server, uno o più programmi installati su questo e il browser. Ap-

prossimativamente il tutto funziona così: l’utente raggiunge, mediante il bro-

wser, un URL* del tipo http://www.example.com/software.cgi, quindi il

web-server attiva il programma corrispondente che provvederà a formattare

una pagina HTML che verrà inviata al browser richiedente come risposta.

Il protocollo CGI definisce anche come il browser possa inviare al server i3La barra degli indirizzi è un campo del browser dove si può immettere manualmente

l’indirizzo Internet della pagina desiderata4vedere Glossario per la definizione5 consultare http://www.w3.org/TR/html401/ per ulteriori approfondimenti6É prassi consolidata utilizzare i cosiddetti “fogli di stile” per definire l’aspetto delle

pagine lasciando al codice HTML/XHML il compito di definirne la struttura. Vedere

http://www.w3.org/Style/CSS/

http://www.example.com/software.cgi

http://www.w3.org/TR/html401/

http://www.w3.org/Style/CSS/


dati dei “form* ” permettendo, di fatto, di ottenere risposte personalizzate

in relazione ai parametri immessi.

Gli applicativi CGI possono essere scritti in qualsiasi linguaggio di pro-

grammazione ma utilizzarne uno “interpretato* ” non è una scelta performan-

te perché il web-server carica in memoria ed inizializza l’interprete del lin-

guaggio ad ogni richiesta dell’applicazione CGI creando un collo di bottiglia

notevole, ovviamente questo inconveniente non si presenta se si utilizzano lin-

guaggi che generano codice direttamente eseguibile come il C/C++ che però

comportano tempi più lunghi in fase di progettazione ed implementazione.

Alcune nuove tecnologie riducono di molto l’inconveniente e permettono

l’utilizzo di linguaggi di “scripting* ”, lato-server, integrati nel codice HTML.

I più celebri sono PHP e ASP7.

Ne spieghiamo in breve il funzionamento facendo riferimento a PHP del

tutto analogo al caso ASP.

Le pagine PHP sono delle pagine HTML avente all’interno del codice

PHP che rende la pagina “dinamica”. Una pagina web dinamica è una pa-

gina web il cui contenuto è, in tutto o in parte, generato sul momento dal

server e può essere quindi diversa ogni volta che viene richiamata. Quan-

do il browser richiede una pagina PHP, il web-server la fa interpretare ad

un modulo che rimane sempre caricato in memoria (eliminando il collo di

bottiglia descritto precedentemente): durante questo processo il codice PHP

viene esaminato ed elaborato dal modulo-interprete del server, dopo di che

la pagina viene inviata all’utente. Generalmente il codice PHP “scrive” a sua

volta del codice HTML, che verrà visualizzato dal browser e che rappresenta

il risultato dell’elaborazione del software. In ogni caso il server invierà sola-

mente una pagina HTML senza codice PHP al suo interno e quindi tutto il

processo è nascosto agli occhi dell’utente.

Anche sul versante client si sono sviluppate tecnologie per rendere vive

e dinamiche le pagine web, JavaScript è una delle più celebri. Si tratta di

un linguaggio di scripting integrato nel codice HTML ma che, a differen-

za del PHP, non viene interpretato dal server bensì raggiunge immodificato

il browser dell’utente ed è quest’ultimo a processare ed elaborare il codice.7In realtà ASP è il nome di una tecnologia sviluppata da Microsoft, i linguaggi usati

sono JScript e VBScript sempre prodotti da Microsoft


Il codice JavaScript si interfaccia, attraverso il “DOM*”, agli elementi che

compongono il codice HTML permettendo di creare pagine web interatti-

ve. JavaScript apporta due grossi vantaggi. Il primo consiste nel fatto che,

potendo accedere al codice e quindi agli elementi costituenti di una pagina

web attraverso il DOM, si possono creare interfacce dinamiche che siano coe-

renti con la situazione del momento; sullo schermo appariranno solamente i

bottoni, i campi di testo e l’impaginazione adatta all’operazione che si deve

svolgere creando pagine pulite ed intuitive. Il secondo è che molti compi-

ti spettanti tradizionalmente al server possono essere svolti da JavaScript e

quindi dal browser, garantendo l’immediatezza del risultato.

L’esempio classico è la convalida dei dati immessi dall’utente in un form:

quando si preme sul tipico bottone “Invia! ” il codice JavaScript controlla

che i dati immessi siano corretti e ben formattati in modo che il software

lato-server riceva sempre dati coerenti e non debba assumersi l’onere del

controllo. Inoltre, in caso di errore, la segnalazione è immediata e non si ha

l’impegno del processo di comunicazione con il server.

Un altro vantaggio è che il server, al posto di inviare i dati della risposta

formattata staticamente in HTML, può fornirli ad una funzione JavaScript

di impaginazione, e quindi personalizzati dal punto di vista grafico dal codice

lato-client; così facendo il software sul server può essere progettato in modo

più generico e servire le esigenze di diversi siti web.

Recentemente sta facendosi largo una nuova frontiera nel campo delle

applicazioni Web: le “Rich Internet Application” o , brevemente, RIA.

1.7 Le Rich Internet Application

Come abbiamo visto, il codice JavaScript può rendere l’interfaccia più

dinamica, intuitiva ed ordinata ma non risolve il maggior problema delle

applicazioni Web tradizionali, ossia permane il fatto che il browser debba

inviare dati verso il server, aspettare la risposta e caricare la pagina da vi-

sualizzare contenente la risposta. Purtroppo, sebbene le tecnologie illustrate

precedentemente risolvano molti dei problemi dell’architettura client-server

classica, non risolvono tale inconveniente. Questo ciclo non si ripete solo

quando l’utente richiede l’elaborazione di dati notevoli, ad esempio l’inseri-


mento del proprio nominativo in un database* o la richiesta di visualizzare la

mappa di una zona geografica, ma anche quando chiede di accedere ad una

diversa sezione dell’applicazione. Tutto questo porta ad avere molti tempi

di attesa ed una interfaccia poco reattiva.

Le RIA si avvalgono di uno strato software che viene scaricato dal web pri-

ma dell’inizio dell’applicazione oppure, come il più delle volte accade, scari-

cato ed installato, una sola volta, per essere utilizzato anche successivamente,

generalmente come “plugin” per il proprio tipo di browser.

Due esempi notevoli sono Java e Flash. Java prevede che l’utente esegua

il download8 del “Java Runtime Environment” un client engine (cioè quello

strato software che funge da supporto per le applicazioni client citato poc’an-

zi) che permette a sua volta di scaricare ed eseguire del software lato-client

sulla macchina dell’utente sia stand-alone*, cioè come se fosse una norma-

le applicazione Desktop, sia nella forma di Applet, software ad interfaccia

grafica contenuto all’interno delle pagine web visualizzate da un browser.

Flash funziona analogamente: il client engine, in questo caso, si chiama

Flash Player ma, a differenza di Java, viene quasi esclusivamente usato per

creare siti dotati di una interfaccia notevolmente migliore rispetto a quella

del Web tradizionale. Adobe ha recentemente sviluppato “AIR” un “Runtime

Environment” studiato appositamente per realizzare applicazioni Desktop

mediante numerose tecnologie tra cui Flash.

Le RIA superano due dei grossi problemi del Web dinamico classico:

lo scarso appeal grafico di un’interfaccia lontana dal look & feel dei soft-

ware Desktop e la mancanza di reattività dell’applicazione per i continui

cicli di ricarica delle pagine. Vediamo perché le RIA superano questi proble-

mi. Abbiamo parlato del client engine, questo è un programma che gira in

background sulla macchina dell’utente e svolge due funzioni. In primo luo-

go fornisce una “API*” standard che, oltre a permettere la compatibilità del

software, da questa derivato, su qualsiasi sistema operativo per cui esista una

versione del client engine, fornisce una famiglia di “widget* ” molto più vasta,

flessibile e graficamente appetibile rispetto a quella del Web tradizionale e

consente una gestione degli eventi e dell’interattività molto più sofisticata e8vedi voce “scaricare” nel Glossario


Client

JRE o Flash Player

Browser

Server

Java Class file oSwf file

InternetL‘applicazione comunicacon il server attraverso ilRuntime Environment

Figura 1.1: Schema di funzionamento di una RIA scritta in Java o Flex


di semplice realizzazione (ad esempio il “drag&drop”, cioè il cliccare su un

oggetto trascinarlo e depositarlo in un’altra posizione, è spesso macchinoso

da implementare e gestire con il solo ausilio di HTML e JavaScript). In

secondo luogo l’applicazione client risiede già totalmente, o quasi, sul client

pertanto l’utente non deve più aspettare l’interazione col server con i suoi

tempi di attesa per l’invio e la ricezione dei dati; l’interfaccia risulta più

reattiva in quanto le sue componenti sono già presenti in locale e non si deve

comunicare al server quale sezione si vuole utilizzare. Inoltre il trasferimento

di dati avverrà solo più per operazioni che, ovviamente, non possono essere

risolte lato-client, ad esempio l’inserimento di informazioni su un database.

Il client-engine, che come abbiamo detto funziona in background durante

l’esecuzione dell’applicazione vera e propria, compie operazioni di “comuni-

cazione asincrona” che permettono al software di scambiare dati col server

mentre il flusso delle elaborazioni o il colloquio del software con l’utente pro-

segue. Più precisamente mentre si sta lavorando con l’applicazione, questa è

in grado di anticipare quali potrebbero essere i prossimi dati di cui potrebbe

aver bisogno da parte del server e scaricarli prima della richiesta effettiva,

velocizzando la risposta del programma. Questo scambio di dati asincrono

permette anche alle RIA di aggiornare dati in tempo reale, cosa che nelle

applicazioni Web tradizionali comporta una noiosa ricarica della pagina da

parte del browser con evidente perdita di tempo. Tutte queste caratteristiche

illustrano il termine “Rich” delle RIA.

Capitolo 2

Lo stato dell’arte delle RIA e

Adobe Flex 3

2.1 Introduzione

In questo capitolo si illustrano tre aspetti delle RIA che, a causa della

diversa tecnologia alla base di queste, presentano delle differenze rispetto alle

applicazioni Web classiche. Verranno analizzati il problema della sicurezza,

alcuni aspetti economici e le limitazioni di questo tipo di applicazioni.

Per finire si darà uno sguardo d’insieme ad Adobe Flex, lo strumento con

cui sono state scritte le applicazioni d’esempio.

2.2 Sicurezza

In una RIA l’utente, raggiungendo via Browser l’url dell’applicazione,

scarica sulla propria macchina un software di cui non conosce nulla se non il

sito di provenienza ed, eventualmente, la reputazione del fornitore dell’appli-

cazione stessa. Pertanto è necessario in primo luogo che l’applicazione non

abbia accesso indiscriminato alle risorse del PC. Inoltre, siccome il software

deve scambiare dati con il server o con altre risorse su Internet deve essere

garantita la sicurezza delle comunicazioni.

Per garantire la sicurezza sulla macchina dell’utente, il client engine prov-

vede a far girare la RIA in una cosiddetta “sandbox ”. Una sandbox è un

11

CAPITOLO 2. RIA E ADOBE FLEX 3 12

meccanismo di sicurezza, una sorta di “macchina virtuale” che ospita l’ap-

plicazione fornendole dello spazio temporaneo nella memoria principale e sul

disco rigido.

Generalmente un sistema operativo non si preoccupa della sicurezza del-

l’applicativo, è l’utente che deve fare attenzione ad eseguire sulla macchina

software affidabile ricorrendo, al limite, a tool esterni come un antivirus.

La sandbox, quindi, limita le operazioni che l’applicazione può eseguire e

soprattutto non permette che questa possa accedere del tutto alle risorse lo-

cali (file sul disco rigido o una videocamera, ad esempio) oppure richiedendo

l’autorizzazione dell’utente.

Le sandbox, sono tipicamente progettate per caricare il software diretta-

mente in memoria cercando di scrivere sul disco rigido meno dati possibili

e comunque in zone predeterminate e che verranno ripulite alla fine delle

operazioni o ad una scadenza fissata. Se l’applicazione necessita di accede-

re a dei file su disco (ad esempio in un programma di fotoritocco l’utente

potrebbe voler modificare immagini già presenti sulla macchina) la sandbox

non permette che questi vengano selezionati e letti senza l’assenso dell’uten-

te. Inoltre non permette al programma ospitato di accedere ad hardware

particolare come microfoni e webcam senza permesso.

Riguardo alla sicurezza delle comunicazioni client-server la maggior parte

delle tecnologie RIA prevede la cifratura di ogni messaggio inviato e ricevuto.

Un altro controllo praticato dalla sandbox è quello sul “dominio* ” di appar-

tenenza del codice eseguito: se si sta eseguendo un’applicazione scaricata

da un certo sito, tutto le istruzioni del programma devono provenire dallo

stesso dominio, in altre parole non è possibile, salvo dietro autorizzazione,

che il software in esecuzione prelevi ed esegua del codice fornito da siti terzi,

all’insaputa dell’utente.

Altre requisiti delle RIA per ottenere buoni livelli di sicurezza non dipen-

dono comunque dal client engine e dalla relativa sandbox. Due aspetti sono

particolarmente importanti. Innanzitutto i controlli lato server, che devono

garantire che nessun malintenzionato possa alterare il software che verrà in-

viato all’utenza. In secondo luogo la possibilità di poter esaminare il codice

dell’applicazione stessa. Nelle applicazioni web standard il codice HTML e

JavaScript raggiunge il client come un semplice file di testo, questo permette


alla comunità informatica di esaminare l’applicazione e di segnalare even-

tuali falle nella sicurezza. Molte tecnologie RIA prevedono che il software

venga inviato in un formato compilato*, interpretato dal client engine1, che

non è direttamente esaminabile. Tuttavia esistono tool, a volte sviluppati

e distribuiti dalla stessa casa produttrice della tecnologia RIA in questione,

che permettono di ricostruire il codice sorgente* da quello compilato.[8]

2.3 Aspetti economici

Le RIA rappresentano una notevole evoluzione nel mondo delle appli-

cazioni web il che porta ad effettuare alcune considerazioni sui costi di

produzione, gestione ed utilizzo di tali applicazioni.

Fra i vantaggi annoveriamo un abbassamento dei costi di produzione delle

applicazioni, un minor consumo di banda* da parte del server e una miglior

distribuzione dei carichi di lavoro computazionale tra client e server.

La diminuzione dei costi di produzione è dovuta al fatto che le RIA

utilizzano nuovi linguaggi di programmazione che semplificano di molto lo

sviluppo delle medesime. Un esempio notevole è il linguaggio Java. Java

è un linguaggio che viene compilato in un formato chiamato “bytecode” che

viene interpretato da una macchina virtuale, il già citato Java Runtime En-

vironment, di cui esistono versioni per tutti i sistemi operativi più diffusi.

Pur offrendo prestazioni inferiori rispetto ai linguaggi che vengono compilati

in formati eseguibili permettono agli sviluppatori di creare applicazioni che

funzioneranno identicamente su qualsiasi piattaforma riducendo i costi di

produzione. La minor velocità di esecuzione è comunque irrilevante rispetto

ai tempi di attesa che si verificano nelle applicazioni Web durante le comu-

nicazioni col server anche se le RIA, come abbiamo visto, riducono questo

problema.

Bisogna notare che i linguaggi del calibro di Java non devono essere visti

come semplici linguaggi di scripting per lo più utilizzati per rendere maggior-

mente interattive le pagine Web con poche righe di codice ma permettono

di creare complesse applicazioni. Sono provvisti di tutte le caratteristiche di

linguaggi di elezione come il C++, come ad esempio l’essere totalmente ad1L’utilizzo di un formato compilato è dovuto a motivi di migliori performance


“oggetti*”, con l’aggiunta di funzionalità di “garbage collection* ” e, di notevo-

le importanza, la possibilità di sfruttare vaste librerie di codice già presente

sulla macchina (generalmente comprese nel Runtime Environment scaricato

ed installato in precedenza) riducendo i tempi di download dell’applicazione.

Per quel che riguarda il consumo di banda da parte del server si deve

considerare che questo deve fornire assistenza, in termini di scambio dati e

potenza di calcolo, ad ogni client che sta utilizzando l’applicazione. Siccome

le RIA non necessitano di un continuo scambio di dati con il server, questo

risulterà meno stressato ed inoltre la banda necessaria affinché questo pos-

sa rispondere a tutte le istanze dell’applicazione risulterà ridotta con ovvie

riduzioni dei costi di gestione.

Infine consideriamo la miglior distribuzione dei carichi computazionali

fra client e server. Nelle applicazioni Web classiche il computer client de-

ve solamente far girare un browser che visualizzerà una manciata di widget

pertanto il potenziale di un qualsiasi computer recente verrà scarsamente

utilizzato; nelle RIA invece la stessa macchina deve far funzionare una appli-

cazione con grafica ed interfaccia realistica del tutto analoga ad applicazione

Desktop anche molto complessa. Di conseguenza il modello RIA sposta il

carico di lavoro dal server ai client ma mentre il primo è generalmente obe-

rato di lavoro i secondi sono tendenzialmente inoperosi. In una azienda i cui

dipendenti utilizzino delle applicazioni RIA in una “Intranet*” questo è un

aspetto da considerare insieme al fatto che i dipendenti saranno costretti a

minori perdite di tempo necessari ai continui ricaricamenti delle pagine web

del Web dinamico classico.

Uno dei punti chiave del successo delle RIA, ovvero il fatto che la maggior

parte dei componenti dell’applicazione vengano scaricati e fatti girare sul

client, porta però un inconveniente.

Il risiedere dell’applicazione sul client rappresenta un problema agli occhi

del produttore perché inevitabilmente la proprietà intellettuale del software

sarà esposta. Inoltre il codice è il più delle volte chiaramente leggibile o facil-

mente decompilabile con degli appositi strumenti. Bisogna tenere conto però

che le parti veramente sensibili dell’applicazione, come ad esempio algoritmi

particolari il cui sviluppo ha comportato investimenti onerosi, possono rima-

nere al riparo da occhi indiscreti sul server. Inoltre molte delle tecnologie


create per sviluppare RIA sono “open source* ”. Questo ha portato alla na-

scita di comunità di appassionati in tutto il mondo che sviluppano e mettono

a disposizione di tutti librerie e framework* che fungono da base per nuovi

software i cui costi di produzione si riducono notevolmente con conseguente

diminuzione di prezzo per il cliente finale.[3, 4]

2.4 Tipi di RIA e confronti

Esistono tre tipologie di RIA. La prima è quella la cui tecnologia rap-

presentante principale è “AJAX ”. Si tratta del connubio tra JavaScript e

XML, un linguaggio di mark-up, che fornisce un oggetto software chiamato

“XMLHttpRequest” (la cui implementazione non è ancora standardizzata e

varia a seconda del browser) utilizzato dagli sviluppatori per fornire comu-

nicazioni asincrone col server.[5] Alcune famose applicazioni sono basate su

questa tecnologia, la più celebre delle quali è Google Maps2. Questo tipo di

RIA ha il pregio di utilizzare tecniche estranee a quelle del Web classico so-

lamente per le comunicazioni asincrone, quindi l’applicazione non necessita

di plugin da installare e, proprio per questo motivo, assomiglia alle pagine

Web tradizionali risultando spesso più familiare all’utente pur non offrendo

le potenzialità grafiche delle RIA basate su client engine esterni. I problemi

di questo approccio sono quelli già visti per le applicazioni Web tradiziona-

li cioè le incompatibilità dei vari browser, delle relative implementazioni del

DOM e dell’interprete JavaScript, senza contare che quest’ultimo deve essere

attivato nelle impostazioni del browser.

La seconda tipologia di RIA è costituita da quei software che vengono

gestiti da un plugin per il tipo specifico di browser e che, tramite questo,

vengono visualizzati. Per fare funzionare queste applicazioni bisogna otte-

nere e installare il plugin adatto. Generalmente però appena raggiunta la

pagina dell’applicazione, tramite poche linee di codice JavaScript, il browser

ci invierà automaticamente alla pagina di download del plugin sul sito del

produttore senza contare che l’installazione deve essere effettuata una sola

volta ed è, di norma, indolore. L’applicazione vera e propria deve essere

scaricata pressoché per intero e questo può essere un processo lento per gli2consulta http://maps.google.it/ per ulteriori approfondimenti

http://maps.google.it/


utenti che non dispongono di una connessione a banda larga. Il plugin si

occupa generalmente di informare l’utente sull’avanzamento dell’operazione

di download visualizzando a schermo una barra di progresso*, ma questo

potrebbe comunque scoraggiarsi ed abbandonare la pagina prima della fine.

Bisogna dire che i plugin possono essere impostati per conservare il software

nella “cache* ” del browser per velocizzare l’avvio nelle sessioni successive al-

la prima. Inoltre i programmatori possono progettare l’applicazione in modo

che venga visualizzata l’interfaccia principale in tempi ragionevoli e solo suc-

cessivamente scaricare il resto, in modo da incoraggiare l’utenza ed offrire

velocemente le funzionalità basilari.

Le applicazioni basate su tecnologie simili ad AJAX non sono soggette a

tali limitazioni.

Un altro problema, anche se marginale,è rappresentato dalla confusione

che viene a generarsi tra i comandi dell’interfaccia della RIA e quelli del bro-

wser: l’utente di una applicazione di fotoritocco potrebbe premere il bottone

di stampa del browser e, invece di ricevere su carta la foto appena editata, ot-

tenere la stampa della pagina Web contenente l’interfaccia della applicazione

stessa, oppure premere il pulsante Indietro sempre del browser ed uscire del

tutto dalla pagina del software pensando invece di tornare alla schermata

precedentemente usata.

Una limitazione di questa seconda tipologia è la perdita di visibilità nei

motori di ricerca* , infatti questi, mediante software appositi, scandagliano in

continuazione l’intero World Wide Web per indicizzare le pagine analizzando

il codice HTML (o XML) ma non il contenuto delle RIA. Questo problema

è però superabile aggiungendo del testo HTML nelle pagine web contenti

l’applicazione che ne illustri le funzionalità oppure sfruttare appositi “tag”

del codice HTML come <title> come illustrato in [10]. I software sviluppati

con la tecnologia AJAX non presentano questo problema.

L’ultima famiglia è quella delle applicazioni che non hanno bisogno di

essere ospitate all’interno di un browser. L’utente trova il software che gli

interessa navigando il Web, clicca un “ link ” che comanda al client engine di

scaricare il programma che verrà poi utilizzato stand-alone senza l’ausilio del

browser come se fosse una normale applicazione Desktop. Anche in questo

caso il software può essere conservato in una directory* del disco rigido per


velocizzare la partenza nelle successive sessioni o per essere utilizzato offline*

per quelle operazioni che non richiedono servizi da parte del server. Inoltre

una volta scaricata l’applicazione per la prima volta è possibile avviarla usan-

do le icone del proprio Desktop[6], esempi di tecnologie che permettono lo

sviluppo di tali applicazioni sono “Java Web Start” e “Adobe AIR” (cono-

sciuto anche come “Apollo”). Questo approccio evita la confusione di avere

a schermo sia l’interfaccia del browser sia quella della RIA.

Un problema condiviso da tutte tre le tipologie deriva proprio da una

delle caratteristiche principali delle RIA: lo scambio di dati asincrono fra

client e server. Negli applicativi Web tradizionali basati su CGI o pagine

PHP o ASP l’utente deve sempre fare richiesta esplicita di inviare dati al

server; generalmente compila un form, invia i dati premendo un bottone e

aspetta la risposta con l’inevitabile caricamento di una nuova pagina. In ogni

caso sa che deve aspettare una risposta. Nelle RIA invece lo scambio di dati è

trasparente agli occhi dell’utente; se però qualcosa non funziona a dovere e i

dati non vengono ricevuti, l’applicazione può risultare congelata suggerendo

a chi sta usando il software che ci sia qualche errore di programmazione al

posto di un banale e momentaneo disservizio.

2.5 Adobe Flex 3

Flex 3 di Adobe è una linea di prodotti integrati utili allo sviluppo di RIA.

L’ambiente di sviluppo è costituito da una versione modificata di Eclipse, un

“IDE* ” open source, che comprende un editor* , un “debugger* ” e componen-

ti per la costruzione visuale del layout e per la gestione dei file del progetto.

Flex permette lo sviluppo di codice che verrà compilato in bytecode, il quale

verrà interpretato e trasformato in formato eseguibile per mezzo del “Flash

Player runtime”, il client engine utilizzato da questa tecnologia. Adobe stima

che ll Flash Player runtime sia attualmente installato su più del 97% dei PC

connessi ad Internet.

Il modello di sviluppo si basa su MXML e ActionScript (versione 3.0).

MXML è un linguaggio di mark-up utilizzato per la descrizione dei compo-

nenti e della struttura dell’interfaccia. Le specifiche di MXML definiscono

tag che forniscono un collegamento fra gli elementi della GUI con i dati e gli


algoritmi dell’applicazione. Pertanto il codice MXML risulterà di più facile

lettura perché il codice responsabile del comportamento dei widget e delle

procedure di calcolo, e i dati, che dovranno essere visualizzati ed elaborati,

sono contenuti in altri file. A parte le istruzioni relative all’aspetto estetico

dei componenti della GUI che di norma, ma non obbligatoriamente, sono con-

tenuti nei cosiddetti fogli di stile, il nucleo del software viene programmato

tramite codice ActionScript.

ActionScript è un linguaggio di programmazione orientato agli oggetti

basato, come Javascript del resto, su ECMAScript, un linguaggio standar-

dizzato dall’European Computer Manufacturers Association. Con Action-

Script si sviluppa tutta la logica della parte client dell’applicazione. Questo

comprende il comportamento dell’interfaccia, cioè cosa deve fare il program-

ma quando si clicca su un bottone o quando si trascinano oggetti col mouse

(drag&drop), e le varie operazioni per cui il software è preposto come, ad

esempio, il calcolo delle rate di un mutuo o la visualizzazione di una mappa

etc..

Inoltre è possibile rendere l’interfaccia dinamica, cioè si può, ad esempio,

far vedere un bottone solo quando è possibile e logico premerlo per pren-

dere una decisione. Questa possibilità è ottenibile o mediante appositi tag

MXML che definiscono come debba presentarsi l’interfaccia in ben deter-

minati momenti dell’applicazione, oppure per via programmatica, mediante

ActionScript, impostando la proprietà “visible” dei componenti interessati al

valore “true” o “false” a seconda che questi debbano risultare visibili o meno.

Flex fornisce una ricca API che permette varie operazioni, tra cui il di-

segno di primitive grafiche, la creazione di contenitori, cioè widget in grado

di ospitarne altri al loro interno, e la gestione del comportamento di que-

st’ultimi in seguito all’interazione con l’utente o al verificarsi di determinati

eventi. Questi caratteristiche consentono allo sviluppatore di estendere la

libreria dei widget con elementi totalmente personalizzati nel design e nelle

funzionalità. Questi nuovi elementi, al pari di quelli predefiniti, possono es-

sere aggiunti alla GUI dell’applicazione mediante un tool visuale di Flex che

permette di disegnare l’interfaccia intuitivamente con pochi click di mouse e

notevole risparmio di tempo.

Un altro componente di Flex è il “Flex Data Services” uno strato software,


risiedente sul server, che si occupa di ottimizzare lo scambio di dati col client,

ma soprattutto di integrare le tecnologie già presenti sul server in modo che

siano sfruttabili dall’applicazione ed, eventualmente, di permettere a questa

di comunicare anche con altri server e altri client su Internet.[7]

Capitolo 3

Testo 3D

3.1 Introduzione

Come prima applicazione di Adobe Flex introduciamo un’applicazione

grafica scritta originariamente da Pavel Kaluzhny per il pacchetto software

Flash con il linguaggio ActionScript 2.0 (vedi [24]). Nello svolgimento della

tesi l’applicazione è stata portata in ActionScript 3.0 per poter funzionare in

Flex 3, ciò ha comportato alcuni cambiamenti dovuti a modifiche apportate

da Adobe alle librerie di base del linguaggio e all’aggiunta di righe di codice

atte a sostituire quelle operazioni che in Flash si possono eseguire con gli

strumenti di posizionamento, dimensionamento ecc. presenti nell’interfaccia

ma che sono assenti in Flex.

Il programma visualizza un campo di testo i cui caratteri si muovono in

un ambiente tridimensionale indipendentemente l’uno dall’altro. La disposi-

zione dei caratteri è tale da ricreare l’effetto lenzuolo, il testo sembra essere

scritto su una tela invisibile che viene sventolata (vd. Figura 3.1).

3.2 Modello matematico

Le librerie standard di disegno di Flex (cioè quelle fornite insieme al

pacchetto e non prodotte da terzi) non prevedono funzioni di disegno 3D,

questa applicazione pertanto simula l’ambiente tridimensionale proiettando

gli oggetti sul piano OXY come se osservati da una telecamera posta nel

20

CAPITOLO 3. TESTO 3D 21


Figura 3.1: Alcuni frame dell’animazione del testo.

punto (0, 0, V Pf)1. V Pf è un numero arbitrario ma sufficientemente grande

(in valore assoluto) da permettere un’ inquadratura ragionevole del piano

proiettivo.

Il testo da visualizzare viene scomposto nei singoli caratteri, ad ognuno

di questi viene assegnata una celletta quadrata virtuale che lo contiene. Le1Le proiezioni trasformano punti da uno spazio n-dimensionale ad uno spazio di dimen-

sioni inferiori ad n. Nella grafica computerizzata si fa larghissimo uso di trasformazioni

di proiezione dal 3D al 2D. La proiezione di un oggetto 3D è definita da un insieme di

rette di proiezione, chiamate proiettori, aventi origine comune in un punto detto centro di

proiezione o punto di vista. I proiettori passano attraverso tutti i punti dell’oggetto 3D e

quindi intersecano un piano di proiezione formando la proiezione vera e propria. Grazie

al fatto che la proiezione di un segmento è a sua volta un segmento, non è necessario pro-

iettare tutti gli infiniti punti rappresentanti gli oggetti di una scena ma, al solito, risulta

sufficiente proiettare i vertici dei segmenti di rappresentazione degli oggetti stessi. Questa

classe di proiezioni prende il nome di proiezioni geometriche piane in quanto i proiettori

sono linee rette e il codominio bidimensionale è il piano. Le proiezioni geometriche piane

possono essere classificate in proiezioni prospettiche e proiezioni parallele. La distinzione

risiede nella relazione esistente tra centro e piano di proiezione. Si parla di proiezione

prospettica nel caso in cui la distanza tra il centro ed il piano di proiezione sia finita; al

contrario, nel caso di distanza infinita si parla di proiezione parallela.(citazione da [14])


cellette sono contigue e i vertici di queste giacciono sul piano di coordinate

(u, v), inoltre il lato ha lunghezza 1 (vd. Figura 3.2).

H le l o ,h va e a

n ci ed ya !

u

v (0,0) (1,0) (2,0) (6,0)

(0,1)

(0,2) (1,2) (4,2)

(5,3)

Figura 3.2: etichettatura dei vertici delle celle contenenti i caratteri, le etichettesono le coordinate dei vertici nel piano (u, v)

Per ogni carattere si passano alla funzione makeShape2, come parame-

tri, le coordinate (u, v) di tre dei quattro vertici della cella corrispondente.

La funzione in questione assegna ad ogni vertice le coordinate (x, y, z) dello

spazio tridimensionale. La scelta di quali coordinate assegnare ad ogni ver-

tice è completamente libera ma siccome la posizione della cella, e quindi del

carattere, deriva dal posizionamento dei tre vertici nello spazio, per ottenere

effetti gradevoli è necessario che le formule usate per l’assegnamento godano

di una certa regolarità. Ovviamente la disposizione relativa di una cella con

le confinanti viene mantenuta.

Ad ogni frame dell’animazione la celletta si dispone nello spazio tridi-

mensionale in modo differente rispetto al frame precedente, creando così il

movimento del carattere. Possiamo vedere alcuni screenshot del movimento

di una lettera in Figura 3.3.

Il passo successivo è proiettare i tre punti di ogni cella sul piano OXY .2Il codice della funzione makeShape viene presentato nel paragrafo 3.4


Figura 3.3: Movimento di una singola lettera in alcuni frame dell’animazione.


O

(0,0,VPf )

(x,y,z)

(x’,y’,0)

(x’,0,0)

(x,0,z)

y x

z

Figura 3.4: Proiezione della coordinata x sul piano 0XY

Indicato con (x′, y′) la proiezione del punto (x, y, z) sul piano OXY , in Fi-

gura 3.4 possiamo notare che il triangolo di vertici O, (0, 0, V Pf) e (x′, 0)

e quello di vertici (0, 0, z), O e (x, 0, z) sono omotetici pertanto vale la pro-

porzione V Pf/x′ = (V Pf − z)/x e pertanto x′ = (V Pf · x)/(V Pf − z).Discorso analogo per la proiezione della coordinata y (vedi [14]). Questa

operazione viene svolta dalla funzione projectPoint3.

A questo punto si applicano delle trasformazioni affini al disegno dei sin-

goli caratteri in modo che questi sembrino scritti sulla celletta immersa nello

spazio 3D. L’applicazione, proiettati i tre punti di ogni cella che chiameremo

P0, P1 e P2, crea un oggetto Sprite contenente all’interno un oggetto Text-

Field. Successivamente posiziona a schermo l’oggetto Sprite alle coordinate

di P0. Siamo, a questo punto nella situazione iniziale di Figura 3.5. Nell’at-

tuale versione di ActionScript è possibile applicare ad ogni oggetto grafico

delle matrici di trasformazione che lavorano in coordinate omogenee (vedi

[22]).3Il codice della funzione projectPoint viene presentato nel paragrafo 3.4


P₀ºP’₀

P₂

P₁

A

P‘₂

P‘₁

la

lp

(1)

(2)

(3)

(4) AP₀ºP’₀

P₂ºP’₂

P₁ºP’₁

lp

P₀ºP’₀

P₂

P₁

A P‘₂

P‘₁

la

lp

P₀ºP’₀

P₂

P₁

A

P‘₂

P‘₁

Figura 3.5: Trasformazione affine della cella contenente il carattere per disporsicoerentemente ai vertici proiettati


Le matrici sono della forma:

M =

a b 0

c d 0

tx ty 1

(3.1)

Per capire meglio il procedimento ricordiamo che dalla teoria delle tra-

sformazioni affini conosciamo il significato geometrico di ogni elemento della

matrice indicata in 3.1: a e d rappresentano i parametri di scaling rispetto

a x e y, b e c quelli della deformazione di taglio rispettivamente in direzione

dell’asse y e dell’asse x mentre tx e ty sono i parametri di traslazione che qui

non interessano perchè le trasformazioni, come detto precedentemente, sono

fatte rispetto all’oggetto contenitore Sprite già posizionato in P0.

I punti trasformati di coordinate (x′, y′, 1) si ottengono ponendo (x′, y′, 1) =

(x, y, 1) ·M . Si vuole fare in modo che i vertici del TextField contenente il

carattere P ′0, P ′1, P ′2 combacino, tramite trasformazione affine, con i rispetti-

vi punti proiettati. Col posizionamento dello Sprite nel punto P0 si ottiene

P ′0 ≡ P0. Siccome qualsiasi trasformazione affine viene calcolata rispetto

all’origine dell’oggetto contenitore, cioè rispetto al punto (0, 0) dello Sprite,

le trasformazioni applicate al TextField risulteranno applicate rispetto a P0

come voluto. Il codice calcola gli angoli α e φ ed applica uno scaling non

uniforme al TextField di parametri cosφ · lp rispetto all’asse x e cosα · lprispetto all’asse y dove lp è la lunghezza del segmento P2P0 e la è la lun-

ghezza del segmento P1P0. A questo punto il TextField è scalato in modo

tale che i punti P ′1 e P1 abbiano la stessa ordinata e i punti P ′2 e P2 la

stessa ascissa. Siamo pertanto giunti al passo (2) di Figura 3.5. Adesso è

necessario “shiftare” la coordinata y di P ′2 e la coordinata x di P ′1 in modo

che si sovrappongano rispettivamente a P2 e P1. Ciò si ottiene applicando

una deformazione di taglio di parametro sinφ · lp rispetto all’asse y e uno

di parametro sinα · la rispetto all’asse x. Queste due operazioni ci portano

rispettivamente ai punti (3) e (4) di Figura 3.5 ([23]).

3.3 Applicazioni possibili

Quale può essere il significato di un’applicazione di questo tipo? Con

l’avvento delle varie tecnologie di banda larga, le pagine web sono diventate


sempre più ricche di immagini ed animazioni. Si sono create tecnologie per

visualizzare applet, java in primis, che eseguendo le istruzioni di disegno

del proprio codice permettono di scaricare e visualizzare animazioni senza

ricorrere a grossi file gif* o in altri formati bitmap. Teoricamente nulla

impedisce di applicare lo stesso principio per la grafica 3D.

Dal lato pratico però esiste una certa carenza di librerie per la gestione di

contenuti 3D per le applicazioni web fruibili via browser. Vediamo il perchè.

La grafica 3D è usata in diversi campi. Per quel che riguarda il campo

videoludico le aziende sviluppatrici di giochi si affidano a tecnologie quali

OpenGL, Microsoft DirectX o ancora Mesa3D library, cioè a delle librerie

che riescono ad accedere a memoria e chip delle schede grafiche usando come

interfaccia i driver che vengono forniti dai produttori dell’hardware stesso.

In questo modo le applicazioni risultano fluide nonostante l’enorme mole

computazionale della grafica tridimensionale.

Questa è generalmente la scelta obbligata per tutti i software in cui ve-

locità, numero elevato di frame per secondo e alta qualità delle immagini si

rendono necessari, si pensi ad applicazioni mediche o militari o ai sistemi

di CAD. Abbiamo detto che una applicazione web deve essere fruibile da

un’utenza il più possibile vasta e soprattutto accessibile dal browser. I fra-

mework appena descritti sono progettati per i linguaggi C/C++ e per creare

eseguibili specifici per un certo hardware e per un certo sistema operativo.

Inoltre librerie come le DirectX sono disponibili solo per la famiglia di sistemi

operativi Microsoft Windows.

Accedere all’hardware specializzato per la grafica, disponibile sulla mac-

china, è indispensabile per ottenere certe prestazioni ma sviluppare una

tecnologia indipendente dalla piattaforma per il web non è semplice.

Java 3D è una API per grafica tridimensionale per la piattaforma Ja-

va. Funziona appoggiandosi a DirectX o OpenGl (dipendentemente dalla

piattaforma) fornendo pertanto prestazioni “hardware-accelerated”. Inoltre

è strutturata con uno stile object-oriented. Quest’ultimo fatto rappresenta

un piccolo collo di bottiglia per le prestazioni insieme al fatto che il codice

compilato deve essere interpretato in real-time dalla macchina virtuale Java.

Le prestazioni sono comunque ottime e le applicazioni possono girare

all’interno del browser come applet o vere e proprie RIA.


A dimostrazione di quanto sia impegnativo per un’azienda creare e man-

tenere un simile progetto, basti pensare alla storia di Java 3D4: inizialmente

sviluppato da quattro aziende del calibro di: Intel, Silicon Graphics, Apple e

Sun; lo sviluppo e mantenimento del framework venne interrotto per un paio

d’anni (2003-2004), successivamente ne venne rilasciato il codice in modo da

combinare il lavoro di numerosi volontari con quello di Sun.

Adobe non ha rilasciato nessuna libreria per grafica e animazioni tridi-

mensionali né per Flash né per Flex, molto probabilmente perché non esiste

una forte richiesta in questo senso da parte dell’utenza di questi strumenti di

sviluppo. Inoltre Adobe produce Director, pacchetto che permette di portare

sul web applicazioni e giochi 3D ma che purtroppo non ha preso molto piede

per la dimensione del plug-in necessario alla visualizzazione dei contenuti5 e

che vede la sua ultima versione datata all’anno 2004.

Esiste tuttavia il promettente progetto Papervision3D6, una libreria open

source scritta in ActionScript 3.0 che consente la gestione di scene 3D con

buone prestazioni nonostante la totale mancanza di accesso alle potenzialità

hardware delle schede grafiche.

Data la carenza, o addirittura mancanza, di tool ufficiali, chi vuole svi-

luppare piccoli effetti grafici 3D o piccoli giochi o limitate applicazioni tri-

dimensionali a scopi didattici è portato a sviluppare da sé un motore 3D

personalizzato per non appoggiarsi a codice di terze parti che molte volte è

a pagamento o privo di documentazione e supporto o il cui mantenimento

potrebbe essere interrotto in qualsiasi momento.

Questa applicazione del testo 3D permette di mappare un campo di te-

sto su una qualsiasi superficie tridimensionale ed è molto versatile. In molti

siti di informazione sono presenti dei piccoli riquadri dove le notizie o della

pubblicità scorre in verticale verso l’alto con le prime righe che scompaiono

all’uscita del riquadro e quelle nuove che compaiono sul fondo. Come ve-

dremo nel paragrafo 3.4, editando opportunamente la funzione makeShape,

si può ottenere un effetto analogo ma con il testo che si perde pian piano4vedi Bibliografia [15]5vedi Bibliografia [16]6vedi Bibliografia [16]


nello spazio come i titoli di di una famosa saga di film di fantascienza7 (vd.

Figura 3.6).

Figura 3.6: Effetto con il testo che si perde nello spazio.

Sempre con opportune modifiche alla funzione makeShape possiamo map-

pare il testo su qualsiasi tipo di superficie ottenendo vari effetti. In Figura 3.7

vediamo il testo scritto sopra una supeficie che simula l’ondulazione di una

bandiera, mentre in Figura 3.8 i caratteri appaiono scritti sulla superficie

laterale di un cilindro.

Figura 3.7: Il testo sembra essere stampato su una bandiera mossa dal vento.

7Star Wars, tutti gli episodi


Figura 3.8: I caratteri del testo possono essere mappati su una qualsiasisuperficie. In questo caso un cilindro che ruota rispetto al suo asse di simmetria.


L’idea di fondo può risultare utile anche per portare su web contenuti

televisivi. L’attuale sigla di apertura di Tgcom, rubrica informativa televisi-

va, sfrutta un effetto del tutto simile a questo, visualizzando del testo che si

muove in ambiente 3D. Si possono utilizzare applicazioni analoghe a questa

per portare sul sito, magari come “intro”, la stessa sigla evitando però di

sovraccaricare la pagina con filmati pesanti da scaricare. Infatti il codice

compilato da Flex risulta enormemente più piccolo in termini di byte di un

qualsiasi filmato raster.

3.4 Analisi del codice

Abbiamo detto che la funzione makeShape è quella che determina co-

me verrà visualizzato il testo nell’ambiente 3D. Analizziamo il codice della

funzione nel primo caso visto, cioè quello di Figura 3.1 :

private function makeShape(u:Number, v:Number, p:Object):void {

p.x = (u - 8) * 20;

p.y = (4 - v) * 14 + Math.cos(Math.sqrt((u - 8) * (u - 8)

+ (3 - v) * (3 - v)) / 2 + timer / 4) * 36;

p.z = (v - 4) * 20;

}

Ricordiamo che i punti verranno proiettati sul piano OXY e che la tele-

camera è posta in (0, 0, V Pf) con, in questo esempio, V Pf = 260. L’og-

getto p rappresenta un punto in R3 e ha le proprietà x, y e z. Al cre-

scere di v corrisponde un aumento della coordinata z del punto, pertan-

to le lettere della prime righe appariranno più lontane delle ultime e lo

stesso varrà anche i singoli caratteri. Per la coordinata x non c’è niente

di particolare da segnalare mentre per la y si può notare che il termine

Math.cos(Math.sqrt((u− 8) ∗ (u− 8) + (3− v) ∗ (3− v))/2 + timer/4) ∗ 36

crea un effetto ondulatorio concentrico. Il parametro timer “fa muovere”

il fronte dell’onda in quanto viene incrementato di un’unità ad ogni frame

dell’animazione.

Vediamo adesso come si può editare il corpo della funzione makeShape

per ottenere il testo mappato sulle superfici degli esempi successivi.


Per il caso di Figura 3.6 abbiamo:

p.x = (u - 8) * 20 ;

p.y = (4 - v) * 20 +timer;

p.z = (v - 4) * 20 -timer;

Per quello di Figura 3.7:

p.x = (u - 8) * 20;

p.y = (4 - v) * 14 + Math.cos(u+timer/10)*20;

p.z = (v - 4) * 20;

mentre, per l’esempio di Figura 3.8 si è usato questo codice:

if ( timer < 0 ) {

p.x = (u - 8)*11.5;

p.y = (4-v)*12;

p.z = 0;

}

else if ( timer <= 20 ) {

p.x = (u - 8)*11.5;

p.y = (4-v)*12;

p.z = -timer*10- (4-v)*timer;

}


var x:Number;

var z:Number;

x = (u - 8)*11.5;

p.y = (4-v)*12;

z = -(4-v)*20;

p.x = x * Math.cos((timer-21)/6) - z * Math.sin((timer-21)/6);

p.z = -200 + x * Math.sin((timer-21)/6) + z * Math.cos((timer-21)/6);

}


p.x = (8-u)*11.5*(60-timer)/20 + (timer-40)/20*70*Math.sin((8-u)/6);

p.y = (4-v)*12;

p.z = -200 + (4-v)*(60-timer) - (timer-40)*3.5*Math.cos((8-u)/6);


}

else {

x = 70*Math.sin((8-u)/6);

p.y = (4-v)*12;

z = -70*Math.cos((8-u)/6);

p.x = x * Math.cos((timer-61)/6) - z * Math.sin((timer-61)/6);

p.z = -200 + x * Math.sin((timer-61)/6) + z * Math.cos((timer-61)/6);

}

p.z=p.z+200;

dove i vari controlli sul valore della variabile timer, che viene incrementata

di una unità ad ogni frame, fanno sì che l’animazione sia composta da diversi

“momenti”. Quello finale dimostra come il testo possa essere mappato su una

superficie solida, in questo caso un cilindro.

Vediamo adesso la funzione projectPoint che proietta i vertici delle cel-

lette da R3 sul piano proiettivo:

private function projectPoint(p:Object):void {

p.x = p.x * VPf / (VPf - p.z);

p.y = -p.y * VPf / (VPf - p.z);

}

A questa funzione viene passato l’oggetto p che rappresenta un punto in R3

ed essa provvede a calcolare le coordinate x e y sul piano OXY le quali

vengono assegnate a p stesso.

In conclusione osserviamo il codice della funzione setPos:

public function setPos (p0x:Number, p0y:Number,

p1x:Number, p1y:Number, p2x:Number, p2y:Number):void {

x=p0x;

y=p0y;

graphics.clear();

var alpha:Number=Math.atan2(p1x-p0x,p1y-p0y);


var phi:Number=Math.atan2(p2y-p0y,p2x-p0x);

var transfMatrix:Matrix = new Matrix();

var la:Number=Math.sqrt((p1x-p0x)*(p1x-p0x)+(p1y-p0y)*(p1y-p0y));

var lp:Number=Math.sqrt((p2x-p0x)*(p2x-p0x)+(p2y-p0y)*(p2y-p0y));

transMatrix.a=lp*Math.cos(phi)/24;

transMatrix.b=lp*Math.sin(phi)/24;

transMatrix.c=la*Math.sin(alpha)/24;

transMatrix.d=la*Math.cos(alpha)/24;

tf.transform.matrix=transMatrix;

}

La funzione setPos è un metodo della classe Char3D che è una sottoclas-

se della classe Sprite. A questa funzione vengono passate come argomenti

le coordinate dei punti P0, P1 e P2. All’interno della classe vi è la proprie-

tà tf di tipo TextField. L’oggetto Char3D (che, ricordiamo, è uno Sprite)

viene posizionato alle coordinate di P0, dopo di che viene cancellato il dise-

gno del frame precedente dell’animazione. Vengono poi calcolati gli angoli

α e φ mediante la funzione atan2 della classe Math, questo metodo calcola

e restituisce l’angolo del punto y/x in radianti, misurato in senso antiora-

rio a partire dall’asse x di un cerchio centrato nell’origine (citazione dalla

documentazione ufficiale di Flex 2). Viene quindi creato un oggetto Matrix

che rappresenta una matrice di trasformazione. Questo oggetto gode delle

proprietà a, b, c, d e queste vengono impostate come descritto nel paragrafo

3.2. Si noti che le proprietà a, b, c, d vengono divise per una costante (24

nel nostro caso) che dipende dal font scelto e dalla dimensione inizialmente

scelta per quest’ultimo. Infine la matrice di trasformazione viene applicata

all’oggetto TextField.

Capitolo 4

Simulatore 3D di urti elastici

4.1 Introduzione

Sempre inizialmente sviluppata da Pavel Kaluzhny, questa applicazione

visualizza un cubo che ruota nello spazio rispetto a due degli assi coordinati

con delle sferette costrette al suo interno. Queste sfere, fornite inizialmente

di massa e velocità casuali, continuano a muoversi e scontrarsi l’un l’altra

con urti perfettamente elastici in un ambiente inerziale. L’energia cinetica

complessiva del sistema rimane immutata e pertanto le sferette continuano

a muoversi all’infinito. Anche in questo caso l’applicazione è stata portata

da Flash e ActionScript 2.0 a Flex con ActionScript 3.0.

Sempre nello svolgimento della tesi, all’applicazione è stata aggiunta

una GUI mediante la quale si possono controllare i parametri di massa e

dimensione di ogni sfera e la rotazione del cubo.

Il codice originario prevedeva un espediente tale da ottenere la corretta

visualizzazione degli spigoli del cubo solamente per il movimento rotatorio,

preimpostato, dato da alcuni angoli prefissati. Con l’aggiunta di coman-

di nell’interfaccia in grado di regolare a piacimento la rotazione del cubo

rispetto agli assi x e y si è reso necessario un cambiamento del codice.

Anche per quel che riguarda le collisioni tra le sfere il codice di Kaluzhny

non corrispondeva ad un modello fisico realistico ma solamente ad una ap-

prossimazione di questo. È stato pertanto necessario riscrivere l’algoritmo

relativo.

36

CAPITOLO 4. SIMULATORE 3D DI URTI ELASTICI 37

Figura 4.1: Screenshot del simulatore.


Ad ogni vertice del cubo vengono assegnati delle coordinate nello spazio

tridimensionale in modo tale che il baricentro del medesimo sia centrato

nell’origine. Inizialmente ogni spigolo ha lunghezza uno, valore che viene

controllato da un’altra variabile per poter gestire la dimensione del cubo con

più semplicità. Ad ogni frame dell’animazione il cubo viene ruotato rispetto

all’asse x e all’asse y pertanto una funzione calcola le nuove coordinate dei

vertici del cubo in seguito alle due rotazioni.

La classe Line, che nel codice rappresenta uno spigolo del cubo, importa

il disegno vettoriale di una linea originariamente disegnata in Flash e prov-

vede a posizionarla sullo schermo in modo coerente con la proiezione sul

piano OXY dei due vertici corrispondenti. Il procedimento è il seguente.

Ogni oggetto Line ha come proprietà le coordinate dei due vertici. Il codice

provvede a calcolarne le due rotazioni. Successivamente viene calcolata la

proiezione prospettica del primo vertice sul piano proiettivo OXY dal pun-

to di osservazione (0, 0, V Pf). La linea viene posizionata sullo schermo in

corrispondenza di questo punto, quindi, un vertice della linea coincide con la


z

x

y

ay

ax

(0,0,VPf )

(1,1,1)

(1,-1,1)

(-1,-1,1)

(-1,-1,-1)

(-1,1,-1)

(1,1,-1)

(-1,1,1)

(1,-1,-1)

O

Piano

proiettivo

Figura 4.2

proiezione del primo vertice dello spigolo mentre il secondo è fuori posizione.

Siccome il disegno della linea è importato da un file esterno e non è dise-

gnata mediante il codice, deve essere scalata in modo che anche il secondo

vertice coincida col corrispondente vertice dello spigolo. Vengono pertanto

calcolate le rotazioni e la proiezione del secondo vertice dello spigolo e il di-

segno della linea viene scalato con fattori shx = (p2.x − p1.x)/imagewidthe shy = (p2.y − p1.y)/imageheight dove shx è il fattore di scala rispetto

all’asse x, shy è il fattore di scala rispetto all’asse y, pk.x e pk.y k = 1, 2 sono

le coordinate dei due vertici dello spigolo e imagewidth e imageheight sono

larghezza e altezza dell’immagine. Immagine che raffigura la linea col primo

vertice nell’angolo in alto a sinistra e il secondo nell’angolo in basso a destra

(l’immagine vettoriale importata ha larghezza e altezza pari a 100 pixel). A

questo punto anche il secondo vertice della linea coincide col secondo vertice

dello spigolo in questione (vedi Figura 4.3). Siccome l’immagine della linea

è importato da un file di Flash in formato vettoriale lo scaling dell’immagine

non comporta perdita di qualità.

Le sfere vengono disegnate come dei cerchi colorati mediante le funzioni

di disegno della libreria standard di ActionScript con l’accorgimento di ap-


file immagine punti proiettati su OXY

p1

p2

p1

p2

primo passo - posizionamento

p1

p2

secondo passo - scaling

Figura 4.3: Posizionamento dell’immagine contenente il disegno di una linea inmodo che coincida con lo spigolo del cubo sul piano proiettivo

plicare un “gradiente”, cioè una particolare sfumatura sul bianco, per fornire

l’illusione di una sfera che rifletta la luce di una sorgente luminosa sulla sua

superficie. Il disegno della sfera viene scalato opportunamente, rispettando

le formule della proiezione.

Ad ogni frame dell’animazione il vettore posizione della sfera viene sommato

a quello della velocità (ricordiamo che ogni sfera è dotato inizialmente di

una certo vettore velocità casuale), successivamente si controlla se la nuova

posizione della sfera esce fuori dal cubo come se questo fosse ancora nella

posizione iniziale senza aver subito rotazioni ed infine si applicano al centro

della sfera le stesse rotazioni del cubo. Così facendo, se si verificano urti

contro una parete del cubo è sufficiente cambiare di segno l’opportuna coor-

dinata (urto elastico contro parete, la parete è intesa come oggetto di massa

infinita).

Per quel che riguarda invece le collisioni tra le sfere il codice di Kaluzhny

non corrispondeva ad un modello fisico realistico ma solamente ad una ap-

prossimazione di questo. È stato pertanto necessario riscrivere l’algoritmo

relativo. Ricordiamo che in un urto perfettamente elastico, tra due sfere si


conservano la quantità di moto e l’energia cinetica totali. Da questo princi-

pio si ottiene che in un urto centrale (cioè quando la velocità relativa dei due

corpi è diretta secondo la retta che unisce i due centri di massa) la velocità

di avvicinamento prima dell’urto è opposta alla velocità di allontanamento

dopo l’urto. Chiamate con v1,v2,vfin1 ,vfin

2 ,m1,m2 rispettivamente le compo-

nenti delle velocità delle due sfere prima e dopo l’urto e le masse delle stesse,

si ottengono le equazioni:

vfin1 =

(m1 −m2)v1 + 2m2v2m1 +m2

(4.1)

vfin2 =

(m2 −m1)v2 + 2m1v1m1 +m2

(4.2)

In ambiente tridimensionale le cose sono più complesse.Indichiamo con P1

e P2 i centri delle due sfere. Il codice, che vedremo nel paragrafo 4.6, calcola

il vettore P1P2, la sua norma e quindi il versore risultante P1P2/∥∥P1P2

∥∥. Ilversore trovato è ortogonale al piano di collisione. Successivamente calcola

la componente ortogonale al piano di collisione di v1. A questo punto ottiene

anche la componente parallela al piano semplicemente come differenza di v1con la componente ortogonale. Le stesse operazioni vengono svolte anche per

v2. In un urto non centrale le componenti tangenti al piano non subiscono

variazioni dopo l’urto mentre le velocità scalari nelle direzioni ortogonali

al piano obbediscono alle 4.1 e 4.2. Infine i nuovi vettori delle velocità

sono uguali alla somma delle componenti ortogonali appena trovate e quelle

parallele al piano di collisione che rimangono, come detto sopra, inalterate.1.

Quando in Flex si aggiungono elementi grafici sul monitor bisogna set-

tare l’indice relativo alla display list dell’oggetto contenitore dell’elemento

in questione. Flex sovrappone i vari elementi in base alla display list nel

senso che gli oggetti risulteranno come disegnati su fogli trasparenti posti

uno sopra l’altro nell’ordine dettato dall’indice di ogni elemento. Questi fo-

gli sono impilati a partire dall’indice 0 a crescere, per cui un oggetto con un

certo indice può risultare sovrapposto ad uno di indice inferiore ma non il

contrario.

Nella nostra applicazione dobbiamo decidere quando una sfera “sta da-

vanti” ad un’altra e fare lo stesso con gli spigoli del cubo. Per quel che1vedi Bibliografia [11, 12]


I vettori delle velocità vengono scomposti in componente ortogonale e parallela

Le componenti ortogonali subiscono una variazione, quelle parallele rimangonoimmutate

Figura 4.4: I nuovi vettori velocità sono la composizione della componenteparallela e della nuova componente ortogonale


riguarda le sfere si nota facilmente che una sferetta nasconde, parzialmen-

te o meno, tutte quelle che sono più distanti dal centro di proiezione. Ad

ogni frame una routine assegna l’indice di profondità ad ogni elemento da

disegnare in base al valore che viene impostato alla proprietà, di tipo nume-

rico, zposition. Per gli oggetti rappresentanti una sfera il codice assegna alla

proprietà zposition la distanza del suo centro dal centro di proiezione.

Siccome le sfere sono contenute nel cubo si deduce che un qualsiasi spi-

golo sta davanti a tutte le sfere oppure dietro a tutte. Il cubo è un poliedro

convesso pertanto una faccia, se intendiamo il cubo solido e non con le facce

trasparenti, o è totalmente visibile o non lo è per niente. Queste due osser-

vazioni ci permettono di affermare che se si riesce a stabilire che una faccia

è visibile allora tutti gli spigoli della medesima devono essere disegnati di

fronte alle sfere e viceversa.

Dato il particolare centro di proiezione (0, 0, V Pf), per stabilire se una

faccia è visibile è sufficiente trovare l’intersezione del piano che la contiene

con la retta di equazioni: {x = 0

y = 0.

L’intersezione trovata è ovviamente un punto sull’asse z. Se il punto

trovato ha come coordinata un valore compreso tra 0 e V Pf la faccia è

visibile altrimenti no.

Il codice funziona in questo modo. Ad ogni oggetto Line viene passato

un ulteriore punto appartenente ad una delle due facce a cui appartiene il

relativo spigolo. A questo punto si possono calcolare i parametri direttori

del piano, cioè i parametri a,b,c,d dell’equazione ax + by + cz + d = 0, in

quanto si conoscono le coordinate di tre punti non allineati.

Ricordiamo che, indicati i punti con (xk, yk, zk) k = 1, 2, 3, tali coefficienti

si ottengono mediante l’equazione:∣∣∣∣∣∣∣∣x− x1 y − y1 z − z1x2 − x1 y2 − y1 z2 − z1x3 − x1 y3 − y1 z3 − z1

∣∣∣∣∣∣∣∣ = 0.

L’intersezione con la retta si trova semplicemente con z = −d/c.


La soluzione si trova assegnando alla variabile zposition dell’oggetto Line

una costante di valore assoluto maggiore della massima distanza possibile di

una sfera dal centro di proiezione e di segno positivo se la faccia contenente

lo spigolo risulta visibile, di segno negativo altrimenti.

La variabile zposition risulta pertanto impostata per ogni oggetto ed una

routine, ad ogni frame, provvede a inserire tutti questi valori in un array,

ad ordinarlo in modo crescente, e ad assegnare ad ogni oggetto, come indice

all’interno della display list, l’indice che il relativo valore occupa nell’ar-

ray. Così facendo sia gli spigoli del cubo sia le sfere verranno visualizzate

correttamente.

Notiamo che uno spigolo appartiene contemporaneamente a due distinte

facce del cubo e che noi calcoliamo l’equazione di una delle due facce, quella

contente il terzo punto passato all’oggetto. Questo non crea problemi per-

ché se uno spigolo appartiene contemporaneamente ad una faccia visibile ed

una invisibile allora le sferette e lo spigolo in questione non possono essere

intersecate da uno stesso proiettore e pertanto non si presentano problemi

di sovrapposizione erronea della sfera sulla linea o viceversa.

Il procedimento illustrato è una semplice variante del “backface culling” o

“backface removal” mediante i quali si stabilisce che una faccia di un poliedro

convesso è visibile se l’angolo tra il vettore normale alla faccia applicato in

un punto qualsiasi di questa e il proiettore di tale punto è compreso tra i 90

e −90 gradi.

Indicato con→n la normale e con

→e il proiettore, la condizione di visibilità

risulta essere→e · →n≥ 0. Se il poliedro non è convesso o se sulla scena vi è più

di un oggetto può capitare che alcune facce siano solo parzialmente visibili,

pertanto il “backface culling” non è sufficiente. In ogni caso viene sovente

utilizzato come primo passo in modo da evitare procedimenti più costosi dal

punto di vista computazionale per quelle facce che sono totalmente invisibili.2

4.3 Interfaccia

A parte mostrare alcuni dei numerosi widget disponibili in Flex per la

costruzione dell’interfaccia di un’applicazione, si sono create due classi che2vedi Bibliografia [13]


ne estendono le funzionalità; esse sono totalmente riutilizzabili e non hanno

dato segno di instabilità nel corso della stesura della presente.

La prima è contenuta nel file “AdvancedPanel.as” ed è una sottoclasse

della classe Panel di Flex. Estende il Panel di Flex nel senso che colma due

grosse lacune che non sono presenti in altri toolkit per interfacce. Permette

infatti di ridimensionare la finestra creata dalla classe Panel in modo inte-

rattivo cliccando sull’apposito talloncino in basso a destra e, cliccando sulla

“barra del titolo” e trascinando il mouse, di spostare la finestra nella posizione

desiderata come si è soliti fare in ambiente Desktop. Durante l’operazione di

trascinamento della finestra il puntatore del mouse assume la caratteristica

forma a croce. Il widget Panel è presente nel tool visuale di disegno di Flex

pertanto anche AdvancedPanel, essendo un suo derivato, è stato presente

in tale tool. Ora il programmatore in fase di sviluppo può aggiungere ta-

le widget nell’interfaccia semplicemente trascinandolo e posizionandolo nella

finestra di disegno dell’applicazione.

La seconda classe è contenuta nel file “tentWrapper.as”. La libreria di

Flex fornisce dei meccanismi per mostrare o nascondere i widget dell’interfac-

cia con degli effetti vari. Quando l’utente seleziona una sfera per modificarne

i parametri, si apre, con un effetto a tendina, un riquadro apposito contente

i parametri stessi e i widget necessari per poterli modificare. L’obiettivo era

quello di ottenere che, quando l’utente seleziona una nuova sfera per modifi-

carne i parametri, il riquadro si chiudesse con un nuovo effetto a tendina e si

riaprisse visualizzando i parametri della nuova sfera. Siccome l’effetto a ten-

dina che chiude il riquadro dura una certa frazione di tempo, le istruzioni che

aggiornano i dati del riquadro non possono essere eseguite immediatamente

dopo l’istruzione che avvia l’effetto di chiusura, ma l’aggiornamento dei dati

deve avvenire solamente a riquadro chiuso perchè altrimenti si scorgerebbero

i dati della nuova sfera prima della completa chiusura dello stesso. Creato

un oggetto tentWrapper si assegna alla proprietà visualElement di questo un

qualsiasi widget dell’interfaccia e alla proprietà toDo un oggetto funzione,

cioè un puntatore ad una funzione che svolge le attività di aggiornamento

dei dati o qualsiasi altra cosa l’utente desideri succeda in mezzo ai due ef-

fetti. Il codice creato, provvede in modo trasparente ad eseguire la funzione

referenziata da toDo solamente quando finisce il primo effetto e ad iniziare il


secondo alla fine delle operazioni di tale funzione. La classe fornisce i metodi

show, close dal significato autoesplicativo e update che è una combinazione

dei due. Anche gli effetti possono essere personalizzati e i metodi della classe

possono essere applicati ad ogni oggetto UIComponent cioè ad ogni widget

dell’interfaccia.


Dopo un’indagine sui principali motori di ricerca l’autore è riuscito a tro-

vare solamente una piccola applicazione simile a questa3 che, pur sfruttando

il motore 3D di Microsoft Silverlight4, non appare molto fluida (15-16 frame

per secondo mentre il simulatore qui descritto non presenta nessun problema

a 30 o più fps a parità di macchina) a testimonianza di quanto sia ostico

portare nelle pagine web contenuti 3D.

Le limitazioni del nostro simulatore sono le stesse di altre simulazioni

(2D) esistenti: solamente due sfere possono scontrarsi allo stesso tempo e se

lo scontro avviene simultaneamente fra tre o più sfere il codice lo considera

come due o più collisioni tra due sfere; inoltre il rilevamento del momento

esatto degli urti non è precisissimo, basandosi unicamente sulla verifica della

distanza tra i centri di due sfere. Tali semplificazioni sono però usuali anche

in software che vengono utilizzati a scopo di simulazione in ambito univer-

sitario e non per illustrare le possibilità di una tecnologia RIA come può

essere la nostra applicazione. Ad esempio la facoltà di scienze atmosferiche

dell’università dell’Illinois usa un modello fisico analogo per una serie di pro-

grammi Java utili allo studio di comportamenti atmosferici dove gli scontri

fra particelle giocano un ruolo importante.5

In effetti la principale applicazione di un software simile è quello di illustrare

concetti fisici.

I comandi dell’interfaccia permettono di selezionare il numero di sfere e3http://bubblemark.com/3d/silverlight1.1.htm4SilverLight è una tecnologia progettata per lo sviluppo di RIA. È molto simile a Flex

nelle intenzioni ed è un diretto concorrente di Adobe in questo senso5vedi http://www.atmos.uiuc.edu/courses/atmos100/userdocs/3Dcollisions.

html per una descrizione del modello fisico e http://www.atmos.uiuc.edu/courses/

atmos100/all_programs.html per una lista di applicativi in cui è utilizzato tale modello

http://bubblemark.com/3d/silverlight1.1.htm

http://www.atmos.uiuc.edu/courses/atmos100/userdocs/3Dcollisions.html

http://www.atmos.uiuc.edu/courses/atmos100/userdocs/3Dcollisions.html

http://www.atmos.uiuc.edu/courses/atmos100/all_programs.html

http://www.atmos.uiuc.edu/courses/atmos100/all_programs.html


di cambiarne i parametri di dimensione e massa. Se l’utente seleziona una

singola sfera e ne riduce al minimo la massa, può osservare che, ad ogni scon-

tro con le altre, la sua velocità aumenta di molto; se poi reimposta la massa

al valore di partenza avrà aumentato la quantità di moto del sistema e potrà

verificarne visivamente l’effetto complessivo. La possibilità di modificare la

dimensione delle sfere e la loro massa può introdurre il concetto di densità di

un corpo. Similmente si potrebbero implementare comandi per gestire forze

esterne o urti anelastici.

In ambito informatico, tale applicazione è stata utilizzata per dimostrare

la velocità di calcolo che l’applicazione RIA, sviluppata in Flex, con il motore

Flash Player, è in grado di realizzare su qualsiasi browser, anche su PC di

potenza non elevata.

4.5 Il modello di gestione degli eventi

Il sistema di gestione degli eventi di Flex permette al programmatore

di far reagire l’applicazione agli input che l’utente invia ad essa attraverso

l’interfaccia grafica. Il modello, che aderisce ad uno standard de facto6, è

per lo più analogo a quello di altre tecnologie orientate alla programmazione

web. Rimandando alla documentazione ufficiale per una trattazione detta-

gliata, vediamo i principi base di tale modello. Con il termine “evento” si

intende il verificarsi di una qualsiasi delle possibili interazioni tra l’utente ed

uno dei widget dell’applicazione. Si vuole che una certa porzione di codice

venga eseguita automaticamente a seguito dell’evento. Vediamo le operazio-

ni necessarie prendendo come widget di esempio un “NumericStepper”, un

elemento della GUI che permette di specificare un valore numerico da un

insieme ordinato mediante inserimento diretto, cioè cliccando col mouse sul

campo contenente il numero e editandolo con la tastiera, o mediante due

pulsantini laterali (vedi Figura 4.5). Vediamo e commentiamo un esempio

minimale:

myNumericStepper.addEventListener...

...(NumericStepperEvent.CHANGE,listeningFunction);

6Document Object Model (DOM) Level 3 Events Specification


Figura 4.5: Un NumericStepper

.........

public function listeningFunction(event:NumericStepperEvent):void{

trace("Il valore scelto è: "+ event.value);

}

L’istanza della classe NumericStepper è rappresentata dalla variabile di no-

me “myNumericStepper”. Si deve chiamare, tramite myNumericStepper, il

metodo “addEventListener” che permette di specificare una funzione che

verrà automaticamente eseguita al verificarsi dell’evento. Questo metodo

richiede pertanto due parametri. Il primo è il tipo di evento per cui de-

sideriamo una risposta da parte dell’applicazione e che, nel nostro caso, è

“NumericStepperEvent.CHANGE”. Questo parametro è una stringa costan-

te, ogni classe rappresentante gli eventi di un widget definisce una di queste

stringhe per ogni tipo di evento. Il secondo parametro è il riferimento alla

funzione (“Listener”) che deve essere eseguita come risposta all’interazione

dell’utente con il NumericStepper. Quando l’utente cambia il valore del Nu-

mericStepper, Flex confeziona un oggetto “NumericStepperEvent”, contenen-

te numerose informazioni sull’evento stesso, e lo invia come parametro alla

funzione listener. La firma della funzione listener, public function listening-

Function(event:NumericStepperEvent):void, deve dichiarare come parametro

proprio l’oggetto NumericStepperEvent che Flex gli passerà in automatico.

Il corpo della nostra funzione listener, listeningFunction, scrive il valore in-

dicato nel NumericStepper a dimostrazione che l’oggetto “event” contiene

le informazioni dell’evento. Nel nostro caso l’unica informazione rilevante

dell’evento è proprio il valore contenuto nel widget.

Una caratteristica importante degli eventi è il cosiddetto “flusso degli

eventi”. Ipotizziamo una situazione in cui un widget è contenuto in un


pannello. Il pannello a sua volta è contenuto nello “Stage”, oggetto che

rappresenta l’area principale di ogni applicazione Flex, cioè il contenitore di

tutti i componenti dell’interfaccia. Quando si verifica un evento a livello del

widget (ad esempio un click del mouse), il Flash Player genera un oggetto

che lo rappresenta, e fa compiere a tale oggetto un percorso che parte dallo

Stage, giunge fino al widget e ritorna allo Stage. Il tragitto dallo Stage

al widget viene chiamato “fase di cattura”, quando l’evento è al livello del

widget siamo invece nella “fase di target”, infine il viaggio di ritorno verso lo

Stage è la “fase di bubbling”

Stage

Panel

Widget

Figura 4.6: Flusso degli eventi

Non tutti gli eventi partecipano a tutte e tre le fasi del tragitto, inoltre,

di default, i widget dell’interfaccia non possono “ascoltare” un evento nella

sua fase di cattura a meno che non siano stati esplicitamente impostati per

questo.

Nel prossimo paragrafo vedremo un esempio in cui questa caratteristica

viene messa in risalto.

4.6 Analisi del codice

Nella sezione 4.3 abbiamo presentato la AdvancedPanel, che fornisce un

pannello spostabile e ridimensionabile. Vediamone il codice:


package MyLibrary{

import flash.display.DisplayObjectContainer;

import flash.events.MouseEvent;

import flash.geom.Point;

import mx.containers.Panel;

import mx.events.FlexEvent;

import mx.managers.CursorManager;

public class AdvancedPanel extends Panel{

public function AdvancedPanel(){

super();

addEventListener(FlexEvent.CREATION_COMPLETE, init);

}

private function init(event:FlexEvent):void {

Container= parent as DisplayObjectContainer;

addEventListener(MouseEvent.MOUSE_DOWN, checkResize);

addEventListener(MouseEvent.MOUSE_DOWN, thisOverAll);

titleBar.addEventListener(MouseEvent.MOUSE_DOWN, startMove);

titleBar.addEventListener(MouseEvent.MOUSE_UP, resetCursor);

titleBar.addEventListener(MouseEvent.MOUSE_OUT, manageMouseOut);

titleBar.addEventListener(MouseEvent.MOUSE_MOVE, manageMouseOut);

}

private function manageMouseOut(event:MouseEvent):void{

if(!event.buttonDown)

resetCursor();

}

public function resetCursor(event:MouseEvent=null):void{

CursorManager.removeCursor(cursorID);

}

public function startMove(event:MouseEvent):void{

oldMouseX=event.stageX;

oldMouseY=event.stageY;

cursorID = CursorManager.setCursor(moveCursorSymbol);

Container.addEventListener(MouseEvent.MOUSE_MOVE, doMove);

}


public function doMove(event:MouseEvent):void{

var newMouseX:Number;

var newMouseY:Number;

newMouseX=event.stageX;

newMouseY=event.stageY;

if(event.buttonDown ){

x+=newMouseX-oldMouseX;

y+=newMouseY-oldMouseY;

oldMouseX=newMouseX;

oldMouseY=newMouseY;

}

else Container.removeEventListener(MouseEvent.MOUSE_MOVE, doMove);

}

public function checkResize(event:MouseEvent):void{

if(event.target!= this)

return;

if( event.localX > width-8 && event.localY > height-8)

this.stage.addEventListener(MouseEvent.MOUSE_MOVE,doResize);

}

public function doResize(event:MouseEvent):void{

var globalCoord:Point=this.localToGlobal(new Point(0,0));

var newWidth:Number=event.stageX-globalCoord.x;

var newHeight:Number=event.stageY-globalCoord.y;

if(event.buttonDown ){

if ((width>minWidth || newWidth>width) && newWidth>minWidth)

width=newWidth;

if ((height>minHeight || newHeight>height) && newHeight>minHeight)

height=newHeight;

}

else

this.stage.removeEventListener(MouseEvent.MOUSE_MOVE,doResize);

}


private function thisOverAll(event:MouseEvent):void{

Container.setChildIndex(this,Container.numChildren-1);

}

public function draw():void{

graphics.clear();

graphics.lineStyle(2);

graphics.moveTo(width - 6, height - 1)

graphics.curveTo(width - 3, height - 3, width - 1, height - 6);

graphics.moveTo(width - 6, height - 4)

graphics.curveTo(width - 5, height - 5, width - 4, height - 6);

}

protected override function updateDisplayList(...

...unscaledWidth: Number, unscaledHeight:Number):void {

super.updateDisplayList(unscaledWidth, unscaledHeight);

draw();

}

private var Container:DisplayObjectContainer;

private var oldMouseX:Number;

private var oldMouseY:Number;

private var cursorID:Number = 0;

[Embed(source="/assets/move.png")]

private var moveCursorSymbol:Class;

}

}

Commentiamone i metodi più significativi.

Il costruttore “AdvancedPanel” chiama il costruttore della superclasse e

fa in modo che si avvi la funzione “init” solamente quando il Flash Player ha

completato le operazioni di inizializzazione interne al componente. Il meto-

do “init” memorizza il contenitore del nostro AdvancedPanel nella variabile

Container, la proprietà “parent” è impostata correttamente proprio perché

la funzione “init” si avvia quando Flash Player ha terminato alcune opera-

zioni di start-up del componente. Successivamente vengono registrate alcune

funzioni come Listener di quegli eventi del mouse che servono a spostare il


pannello e a ridimensionarlo.

Cominciamo col vedere i metodi preposti allo spostamento del pannello.

Il metodo “startMove”, che viene chiamato quando l’utente clicca la barra del

titolo del pannello per spostarlo, registra le coordinate del medesimo al mo-

mento del click e comincia ad ascoltare l’eventuale movimento del mouse per

l’operazione di trascinamento vera e propria. Il metodo “doMove” si occupa

di muovere effettivamente il pannello. Per prima cosa registra le coordinate

del mouse, successivamente controlla se l’utente sta ancora tenendo premu-

to il pulsante del mouse oppure se l’ha rilasciato. Nel primo caso muove

effettivamente il pannello decidendo la direzione di movimento in base alla

differenza tra le coordinate del mouse al momento del click sulla barra del

titolo e quelle attuali. Nel secondo caso smette di registrare i movimenti del

mouse perché si è conclusa l’operazione di trascinamento.

Vediamo ora i metodi che permettono il ridimensionamento del pannello.

“checkResize” è il Listener che risponde ai click dell’utente sul pannello. Se

il click è avvenuto sull’angolo in basso a destra il codice imposta un nuovo

Listener, “doResize”, per registrare i movimenti del mouse e ridimensiona-

re il pannello, se il click è avvenuto in un’altra zona non effettua nessuna

operazione. Si noti l’istruzione

if(event.target!= this)

return;

all’inizio del metodo. Ipotizziamo che all’interno del pannello sia posizionato

un widget. Un eventuale click sul widget fa sì che il Flash Player chiami il

metodo “checkResize” quando l’evento è in fase di bubbling. Le istruzioni

appena viste controllano che il click sia stato fatto proprio sul pannello e

non su uno dei widget contenuti all’interno di questo. Se il click è stato fatto

su un widget interno al pannello la funzione termina. Questo controllo è

necessario perché se l’evento viene raccolto in fase di bubbling dal pannello,

le informazioni sulle coordinate del punto su cui si è fatto click sono rela-

tive al widget e non al pannello, provocando ovvi problemi nelle operazioni

successive. Il metodo “doResize” ridimensiona la finestra facendo attenzione

che questa non diventi più piccola delle dimensioni minime impostate.


Concludiamo il paragrafo presentando il segmento di codice responsabile

della computazione dei nuovi vettori delle velocità di due sfere in seguito ad

un urto. Si può notare come le istruzioni seguano passo passo il modello

presentato nel paragrafo 4.2:

// versore ortogonale al piano di collisione

var versore:Object=new Object;

versore.x=ball2.px-px;

versore.y=ball2.py-py;

versore.z=ball2.pz-pz;

//la norma per ottenere il versore

var norma:Number=Math.sqrt(versore.x*versore.x+

+versore.y*versore.y+versore.z*versore.z);

// normalizzo versore

versore.x=versore.x/norma;

versore.y=versore.y/norma;

versore.z=versore.z/norma;

// componente ortogonale di v1

var v1n:Number=(vx*versore.x+vy*versore.y+vz*versore.z);

// vettore ortogonale di v1

var vett1n:Object=new Object;

// calcolo vettore ortogonale di v1

vett1n.x=v1n*versore.x;

vett1n.y=v1n*versore.y;

vett1n.z=v1n*versore.z;

// vettore parallelo di v1

var vett1p:Object={x:vx-vett1n.x,y:vy-vett1n.y,z:vz-vett1n.z};

// componente ortogonale di v2

var v2n:Number=(ball2.vx*versore.x+ball2.vy*versore.y+ball2.vz*versore.z);

// vettore ortogonale di v2

var vett2n:Object=new Object;

// calcolo vettore ortogonale di v2

vett2n.x=v2n*versore.x;

vett2n.y=v2n*versore.y;


vett2n.z=v2n*versore.z;

// vettore parallelo di v2

var vett2p:Object=...

...{x:ball2.vx-vett2n.x,y:ball2.vy-vett2n.y,z:ball2.vz-vett2n.z};

// nuova componente ortogonale di v1

var v1nfin:Number=...

...(v1n*(mass-ball2.mass)+2*ball2.mass*v2n)/(mass+ball2.mass);

// nuova componente ortogonale di v2

var v2nfin:Number=(v2n*(ball2.mass-mass)+2*mass*v1n)/(mass+ball2.mass);

// nuovo vettore ortogonale di v1

var vett1nfin:Object=...

...{x:v1nfin*versore.x,y:v1nfin*versore.y,z:v1nfin*versore.z};

// nuovo vettore ortogonale di v2

var vett2nfin:Object=...

...{x:v2nfin*versore.x,y:v2nfin*versore.y,z:v2nfin*versore.z};

// nuove velocità per questa sfera

vx=vett1p.x+vett1nfin.x;

vy=vett1p.y+vett1nfin.y;

vz=vett1p.z+vett1nfin.z;

// nuove velocità per ball2

ball2.vx=vett2p.x+vett2nfin.x;

ball2.vy=vett2p.y+vett2nfin.y;

ball2.vz=vett2p.z+vett2nfin.z;

Capitolo 5

Disegno di curve

5.1 Introduzione

Questo programma permette il disegno di segmenti di linea retta e di

forme chiuse delimitate da linee miste. L’idea chiave dell’applicazione è

quella di poter disegnare linee miste chiuse semplicemente posizionando sul

monitor dei punti di controllo. Ricordato che una linea mista è una linea in

parte spezzata e in parte curva, i punti di controllo corrispondenti alla parte

spezzata della linea coincidono con i vertici dei relativi segmenti mentre i

punti di controllo corrispondenti alla parte curva della linea sono i punti di

controllo di una curva B-Spline. In Figura 5.1 vediamo un esempio. I punti

P1, P6, P8, P10 separano un tratto curvo da un tratto di linea spezzata, il

punto P7 è semplicemente un punto interno di una parte spezzata, i punti

da P1 a P6 sono i punti di controllo di una curva B-Spline come lo sono i

punti P8, P9, P10.

Chiamiamo duri quei punti di controllo che sono vertici di un segmento

di una parte spezzata della linea e morbidi i punti di controllo delle B-Spline

che disegnano le parti curve.

I tratti curvilinei possono avere un numero qualsiasi di punti di control-

lo e l’utente può modellare la curva semplicemente spostandoli col mouse.

Questo rappresenta un approccio diverso da quello di molti software per la

creazione di illustrazioni basati sul disegno vettoriale come Adobe Illustrator

55

CAPITOLO 5. DISEGNO DI CURVE 56

P₁

P₂

P₃

P₄ P₅

P₆

P₇

P₈

P₉P₁₀

Figura 5.1: Esempio di forma delimitata da linea mista chiusa

o Corel Draw1, dove le linee curve sono aggiunte a schermo posizionando il

primo e ultimo punto di controllo di una curva di Bezier e impostando la

direzione tangente in corrispondenza di questi due punti (vedi [18]). Inoltre,

sempre nella tipologia di software sopra citata, per creare curve composte,

è necessario collegare manualmente curve singole, e per ottenere una cer-

ta regolarità, impostare, sempre manualmente, le direzioni tangenti di ogni

sottocurva.

5.2 Funzionamento

L’applicazione presenta due pannelli, il primo di questi contiene i vari

tool di disegno mentre il secondo contiene la “tela” su cui si aggiungeran-

no le linee e le forme volute. Entrambi i pannelli appartengono alla classe

AdvancedPanel (vedi paragrafo 4.3) pertanto sono trascinabili col mouse e

ridimensionabili.

Il pannello dei comandi contiene i seguenti controlli:

• Bottone “Draw lines”, per disegnare linee1Si intendono quei software rivolti a grafici per illustrazioni artistiche, e non pacchetti

rivolti alla progettazione industriale o software CAD


Figura 5.2: Screenshot dell’applicazione

• Bottone “Draw polygons”, per disegnare poligoni

• Bottone “Select objects”, per selezionare e spostare oggetti all’interno

dell’area di disegno.

• Bottone “Select ctrl points”, per selezionare i punti di controllo di linee

e forme e spostarli all’interno dell’area di disegno.

• Bottone “Soften edges”, con cui è possibile cliccare su un punto di

controllo per renderlo morbido o, se già lo fosse, duro. (punti rispetti-

vamente di colore verde e blu in Figura 5.1).

• Due ColorPicker, con cui è possibile selezionare il colore delle linee o

del bordo e del riempimento delle forme.

• Un ComboBox, mediante il quale si può cambiare lo spessore di una

linea o del bordo di una forma.

• Due NumericStepper, tramite cui è possibile scalare gli oggetti sullo

schermo.


Figura 5.3: Pannello con gli strumenti per disegnare


È possibile selezionare un solo bottone per volta.

Si possono disegnare linee e poligoni selezionando i rispettivi tool, ognuno

col proprio pulsante. Per disegnare una linea è sufficiente cliccare due volte

nell’area di disegno per impostare la posizione dei due vertici del segmento.

Per disegnare un poligono, si deve cliccare sull’area almeno tre volte per

ottenere un triangolo, ad ogni ulteriore click si ottiene un poligono con un

lato in più. Per terminare il disegno del poligono si preme il tasto Esc. Il tasto

Esc può essere premuto anche quando si è impostato solamente il primo punto

di un segmento o non si è ancora cliccato per la terza volta per ottenere un

triangolo, abbandonando così l’operazione e potendo ricominciare da capo.

Per spostare i punti di controllo di un oggetto, per cambiare la “morbi-

dezza” di un punto o ancora per scalare o cambiare i colori di un oggetto

è necessario prima selezionare l’oggetto desiderato con l’apposito tool. Per

selezionare un oggetto si clicca sul bottone “Select objects” e successivamen-

te sull’oggetto di interesse. L’oggetto verrà contornato da una cornice rossa

che ne indica lo stato di selezione e si porrà automaticamente in primo piano

sovrapponendosi agli altri oggetti.

In fondo al pannello contenente il disegno vero e proprio è presente un

check box che, quando spuntato, crea degli effetti di colori e di trasparenze

tra gli eventuali oggetti sovrapposti sull’area di disegno. Inoltre, sempre in

fondo al pannello, è presente il bottone di stampa.


Le sezioni curvilinee delle forme chiuse sono rappresentate da curve B-

Spline. Ricordiamo che l’equazione di una curva B-Spline di ordine k2 e

punti di controllo {P0, . . . , Pn} è:

P(t) =n∑

i=0

Ni,k(t)Pi, tk−1 ≤ t ≤ tn+1 (5.1)

dove la successione {tj} è una sequenza non decrescente di valori denominati

nodi e le Ni,k(t) sono particolari funzioni di miscelamento, polinomiali a

tratti di grado k − 1, dette “funzioni B-Spline”.2L’ordine k di una curva B-Spline è uguale al grado della curva polinomiale a tratti

più uno.


Le curve B-Spline utilizzate sono di tipo Open in modo che interpolino

il primo e l’ultimo punto di controllo delle sezioni curvilinee di una forma,

facendo sì che questa risulti chiusa (vedi [19]).

Quando l’utente seleziona il tool “Soften edges”, può cliccare sui punti

di controllo per ammorbidirli. Al primo punto cliccato ci troviamo nella

situazione di Figura 5.4, otteniamo una curva di grado due3 con tre punti di

controllo4, indicati con P0, P1 e P2, di cui P0 e P2 sono considerati duri anche

se sono rispettivamente il primo e l’ultimo punto di controllo della curva

mentre il punto P1, quello su cui si è cliccato, diventa un punto morbido.

Ora, se si clicca su P2, la curva guadagna un punto di controllo come si vede

P₀P₁

P₂

Figura 5.4: I punti di controllo della curva sono tre. Il grado della curva è due.

in Figura 5.5. La curva B-Spline così ottenuta cresce di grado e diventa una3Grado due è il più alto possibile con tre soli punti di controllo4In letteratura i punti di controllo vengono generalmente indicizzati a partire da zero.

Si è qui mantenuta tale convenzione differentemente da quanto visto in Figura 5.1


P₁P₀

P₂

P₃

Figura 5.5: I punti di controllo della curva sono quattro. Il grado della curva ètre.


cubica5. Se si continua a cliccare sul primo o sull’ultimo punto di controllo

di una curva si ottiene una nuova curva con un punto di controllo in più ma

sempre di grado tre, che, pertanto, rappresenta il massimo grado previsto

(vedi Figura 5.6).

P₃

P₁P₀

P₂

P₄

Figura 5.6: I punti di controllo della curva sono cinque. La curva rimane semprecubica.

Vediamo come è definita la sequenza dei nodi, necessaria per la costru-

zione di una curva B-Spline, nel caso specifico di questa applicazione. Dati

i punti di controllo {P0, P1, . . . , Pn} e l’ordine k della curva, la sequenza dei

nodi T = {ti}n+ki=0 è costruita secondo questi accorgimenti:

1. la sequenza è non decrescente6

2. il valore più piccolo è assunto uguale a zero

3. la sequenza è composta da n+ k + 1 elementi5Grado tre è il più alto possibile con quattro punti di controllo6Proprietà comune ad ogni tipo di curva B-Spline


4. k vale tre se n = 2 o quattro se n ≥ 3

5. i valori costituiscono una parametrizzazione sugli interi, ossia sono

maggiori di una unità rispetto al precedente tranne il primo (zero)

e ultimo valore che sono ripetuti k volte7

Ricapitoliamo. Al primo punto reso morbido, indicati con P0, P1 e P2 i punti

di controllo, la curva avrà grado due e sequenza dei nodi T = {0, 0, 0, 1, 1, 1}.Se aggiungo un punto di controllo allo stesso segmento curvo, come detto

precedentemente, la curva diventa cubica, cioè di grado tre, con sequenza

dei nodi T = {0, 0, 0, 0, 1, 1, 1, 1}. Se si continua a cliccare sul punto iniziale

o finale di una curva, aumentandone così il numero di punti di controllo, il

grado rimane tre ma la sequenza dei nodi varia in questo modo:

5 punti di controllo, n = 4, k = 4 −→ T = {0, 0, 0, 0, 1, 2, 2, 2, 2}6 punti di controllo, n = 5, k = 4 −→ T = {0, 0, 0, 0, 1, 2, 3, 3, 3, 3}7 punti di controllo, n = 6, k = 4 −→ T = {0, 0, 0, 0, 1, 2, 3, 4, 4, 4, 4}8 punti di controllo, n = 7, k = 4 −→ T = {0, 0, 0, 0, 1, 2, 3, 4, 5, 5, 5, 5}. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Inizialmente si erano scelte le curve di Bezier per disegnare i contorni delle

forme. Purtroppo questa scelta presentava parecchi svantaggi. Col crescere

dei punti di controllo, infatti, cresce anche il grado della curva polinomiale.

Ciò comporta un pesante rallentamento in tutte quelle operazioni in cui

la curva deve essere ridisegnata di continuo ed in tempo reale, ad esempio

quando si spostano i punti di controllo della medesima con l’apposito tool.

L’utilizzo di curve di Bezier composte risolve il problema del grado alto ma,

per ottenere una certa regolarità della curva, si richiede, da parte dell’utente

o di una procedura automatica, di posizionare con un certo criterio i punti

di controllo sacrificando di molto la flessibilità.


Le curve B-Spline sono più intuitive e più facili da controllare, mediante

il posizionamento dei punti di controllo, rispetto alle curve di Bezier. Nono-

stante ciò sono raramente implementate nei programmi di grafica 2D, mentre7Il primo e ultimo valore ripetuti k volte caratterizzano le B-Spline di tipo Open


sono uno standard nella grafica tridimensionale (vedi [18]). La scelta delle

B-Spline per la nostra applicazione, permette di avere curve cubiche indi-

pendentemente dal numero di punti di controllo; ciò permette un compor-

tamento uniforme da parte di ogni sezione curvilinea delle forme disegnate

sullo schermo. Inoltre l’utente non deve preoccuparsi di collegare più sezioni

di curve composte per ottenere una certa regolarità della curva, problema

che si presenterebbe con le curve di Bezier.

Questo approccio fa sì che il nostro applicativo, magari con l’implemen-

tazione di qualche altra funzionalità8, rappresenti un valido tool di disegno

per bambini magari da aggiungere come gadget all’interno di siti web per

l’infanzia.

Vedremo nel paragrafo 5.5.2 come questa applicazione sia stata progetta-

ta in modo che fosse facile integrare le operazioni di disegno in altri software.

Si potrebbe pertanto utilizzare la funzionalità di disegnare forme chiuse mi-

ste del nostro programma, per aggiungere ad un software di fotoritocco uno

strumento intuitivo e versatile per scontornare immagini. Ad esempio, l’u-

tente potrebbe disegnare una forma che ricopra la parte dell’immagine che

si vuole mantenere e premere un bottone che cancelli il resto. Siccome le

curve B-Spline permettono di avere molti punti di controllo senza appesan-

tire l’applicazione, l’utente può posizionare, in fase di creazione del poligono

iniziale, molti punti di controllo sul contorno desiderato in modo che questi

siano relativamente vicini l’uno all’altro. Dopo di che può ammorbidire i

punti di interesse per quelle parti dell’immagine che sono curvilinee. Data

la vicinanza dei punti di controllo le curve sembreranno interpolare i punti

stessi consentendo di scontornare l’immagine con precisione.

5.5 Struttura del codice

5.5.1 Classi astratte e polimorfismo

Nell’Appendice A si illustrano i fondamenti del paradigma della program-

mazione ad oggetti. Approfondiamo qui l’aspetto del polimorfismo, introdu-8Possibilità di disegnare primitive (cerchi, quadrati...), di cancellare oggetti etc.


cendo il concetto delle classi astratte e dei metodi virtuali perché il codice

dell’applicazione fruisce di queste caratteristiche.

Nell’architettura di un programma possono esistere classi che rappresen-

tano entità aventi un comportamento simile. In letteratura è tipico l’esempio

di classi che rappresentano alcuni tipi di animali. Si avranno pertanto la clas-

se “Cane”, “Gatto”, “Lupo” ecc.. Ognuna di queste classi, ad esempio, avrà

il metodo “emetti_verso” che stamperà a video le onomatopee dei versi dei

vari animali. Sempre nell’esempio classico tutte queste classi condivideranno

la stessa superclasse che chiameremo “Animale”. Per sfruttare il concetto di

polimorfismo dobbiamo definire un metodo “emetti_verso” anche in questa

classe. In questo modo, se definiamo una variabile di tipo “Animale” ed

assegnamo a questa il riferimento ad una istanza di una delle classi rappre-

sentanti un animale, possiamo chiamare il metodo “emetti_verso” attraverso

questa variabile ed ottenere la stampa del verso corrispondente all’istanza.

Vediamo un esempio in pseudo-codice:

\\ creo una variabile di tipo Animale

\\ e assegno a questa il riferimento ad un oggetto di tipo Cane

var myPet:Animale=new Cane;

\\ chiamo il metodo emetti_verso tramite la variabile myPet

myPet.emetti_verso();

\\ Stampa a video:

\\ "Bau Bau"

Come possiamo implementare le istruzioni del corpo del metodo “emet-

ti_verso” all’interno della classe “Animale”? Questa classe è talmente gene-

rale per quel che riguarda il metodo in questione, che non ha semplicemente

senso scrivere delle istruzioni all’interno del metodo. L’unica cosa importan-

te è che si possa invocare il metodo “emetti_verso” attraverso una variabile

di tipo “Animale” in modo che tutte le istanze delle varie sottoclassi abbiano

una interfaccia comune. Ovviamente le sottoclassi “Cane”, “Gatto”, “Lupo”

devono fare l’“override” di questo metodo implementando le istruzioni per

la stampa a video del verso corretto. In gergo informatico il metodo “emet-


ti_verso”, a livello della classe “Animale”, viene chiamato metodo virtuale.

Le classi aventi metodi virtuali vengono indicate come classi astratte.

In ActionScript è sufficiente non includere alcuna istruzione nel corpo

del metodo “emetti_verso” a livello della classe “Animale”, è necessario co-

munque lasciare le due parentesi graffe che delimitano il blocco di istruzioni

(vuoto) del metodo. Il metodo deve essere invece contrassegnato con la

parola chiave override nelle varie sottoclassi.

ActionScript ha qualche forma di controllo in meno e qualche limitazione

rispetto a linguaggi come Java e C++, vediamo in che senso. Se avessimo

programmato la classe “Animale” in Java avremmo dovuto dichiarare i me-

todi senza corpo con la parola chiave “abstract” togliendo del tutto il corpo

della funzione cioè anche le due parentesi graffe prive di codice al loro in-

terno, allo stesso modo avremmo dovuto dichiarare abstract anche l’intera

classe. Inoltre il compilatore Java non permetterebbe la creazione diretta

di oggetti “Animale”, cosa questa che porta maggiore chiarezza all’interno di

software molto complessi.

In ActionScript se un metodo di una classe derivata ha lo stesso nome di

un metodo della superclasse deve essere per forza contrassegnato con la pa-

rola chiave override ed è pertanto soggetto al meccanismo del polimorfismo.

C++ è più flessibile: senza scendere nei particolari diciamo solamente che

un metodo è polimorfico solamente se è contrassegnato con la parola chiave

“virtual” nella classe base, altrimenti una classe derivata può implementare

un metodo con lo stesso nome ma questo si comporterà semplicemente come

un altro metodo e non permetterà il meccanismo del polimorfismo.

Il linguaggio C++ è molto apprezzato e versatile ma molti utenti non

ne usano tutte le potenzialità perché portano facilmente a degli errori di

programmazione, inoltre molti compilatori non sono del tutto compatibili

con lo standard ANSI proprio per la grande complessità del linguaggio.

Bisogna comunque dire che C++ e Java appartengono alla categoria dei

cosiddetti linguaggi di “sistema”, cioè quei linguaggi nati per costruire ap-

plicazioni molto grosse ed (eventualmente) “da zero”, cioè senza il supporto

di framework esterni, al contrario dei linguaggi di “scripting” progettati per

fare da collante fra diverse applicazioni o per far comunicare diversi tipi di

tecnologie. I linguaggi appartenenti alla prima categoria sono generalmente


più difficili da imparare, più verbosi e meno espressivi, ma obbligano a strut-

turare di più e meglio il codice impedendo al medesimo di diventare troppo

complesso da gestire. I linguaggi della seconda categoria sono caratterizzati

da una ripida curva di apprendimento, sono molto versatili e permettono

di condensare complesse operazioni in pochissime righe di codice, ma sono

progettati per costruite macro funzionanti all’interno di altre applicazioni,

per aiutare gli amministratori di sistemi nei compiti ripetitivi o ancora per

far dialogare software diversi che magari utilizzano protocolli di comunica-

zione incompatibili fra loro. Alcuni di questi sono Python, Perl, Tcl e Ruby.

Secondo l’autore, ActionScript, a dispetto del nome, si colloca a metà strada

tra queste due categorie.

Vedremo, nei prossimi paragrafi, come sono strutturate le classi principali

della nostra applicazione.

5.5.2 Classe DrawingTarget

La classe DrawingTarget funge da regista per ogni operazione di questa

applicazione. Il codice si avvale delle facilitazioni della programmazione ad

oggetti ma si è preferito mantenere la logica principale del codice raccolta in

un blocco singolo per facilitare l’integrazione di questa limitata applicazione

di disegno, in software di più ampio respiro. Nella classe DrawingTarget è

presente la proprietà drawingArea di tipo UIComponent (vedi Appendice A)

che contiene il riferimento al componente su cui l’utente andrà a disegnare.

La scelta del tipo di drawingArea permette di poter includere le funzionalità

di disegno su qualsiasi elemento visuale di Flex. Chiaramente tali funzioni

possono essere utili all’interno di quei widget dotati di un’area predisposta a

visualizzare un contenuto principale, tipo pannelli (classe Panel), tele (clas-

se Canvas) o qualsiasi loro derivato come la nostra classe AdvancedPanel

(vedi 4.3). Pertanto, aggiunti in un altro progetto i widget dell’interfaccia

e i file della nostra applicazione, è sufficiente creare un’istanza della classe

DrawingTarget e passare a tale oggetto il riferimento del componente su cui

si vuole poter disegnare.


5.5.3 Classe DrawingObject

La classe DrawingObject è la superclasse di tutte le classi rappresentanti

quegli oggetti che possono essere disegnati sull’apposita area della nostra

applicazione. Linee e poligoni, che nella versione attuale del software sono

gli unici elementi a poter essere aggiunti sullo schermo, sono rappresentati

dalle classi Line e Polygon che sono sottoclassi di DrawingObject. La classe

DrawingObject, pertanto, fornisce un’interfaccia comune ad ogni elemento

sull’area di disegno e può essere considerata come classe base per altri tipi

di oggetti grafici in future implementazioni.

Nella classe DrawingObject possiamo notare la dichiarazione di metodi

il cui corpo non contiene istruzioni. Questi, come detto precedentemente,

sono metodi virtuali. DrawingObject è, pertanto, una classe astratta.

Il principale tra questi, il metodo draw, è quello preposto a disegnare

l’oggetto sullo schermo. Le sottoclassi di DrawingObject, come vedremo,

fanno l’ovverride di questo metodo implementando le operazioni di disegno

vere e proprie, in particolare la classe Line provvede a disegnare una linea e

la classe Polygon un poligono.

Questa struttura semplifica la scrittura del codice. Ad esempio, duran-

te l’esecuzione dell’applicazione, il software mantiene un’array contenente i

riferimenti di tutti gli oggetti disegnati dall’utente. Questi riferimenti sono

variabili di tipo DrawingObject a cui sono state assegnate degli oggetti Line

o Polygon. Si possono chiamare quei metodi senza corpo della classe Dra-

wingObject per tutti gli elementi dell’array e, grazie al polimorfismo, per

ogni elemento verrà invocato il metodo corrispondente all’effettiva classe di

appartenenza.

La classe DrawingObject ha altri metodi senza corpo, virtuali, oltre a

draw. calcBaricenter è preposto al calcolo delle coordinate del baricentro9.

Siccome le classi Line e Polygon, come vedremo nel pargarfo 5.5.4, implemen-

tano in modo diverso i punti di controllo, il metodo calcBaricenter non è in

grado di calcolare il baricentro di tali punti a livello della classe DrawingOb-9Inteso come “media” dei punti di controllo. L’uso del baricentro come punto rispetto a

cui applicare trasformazioni affini quando non diversamente specificato dall’utente è una

scelta seguita in applicativi simili a questo. Vedi http://www.disi.unige.it/person/

MagilloP/GRAFICA04/sugger2D.html

http://www.disi.unige.it/person/MagilloP/GRAFICA04/sugger2D.html

http://www.disi.unige.it/person/MagilloP/GRAFICA04/sugger2D.html


ject. Esso rimane quindi virtuale in tale contesto mentre nelle sottoclassi ne

viene fatto l’override specificando nei rispettivi corpi le istruzioni specifiche.

Quando l’utente attiva il tool di selezione, potrebbe avere delle difficoltà

a muovere il mouse esattamente sopra una linea o una qualsiasi forma mol-

to allungata avente uno spessore di pochi pixel. DrawingObject estende la

classe Sprite, tale classe contiene una proprietà di nome hitArea, sempre di

tipo Sprite, che funge da area sensibile agli eventi del mouse nel senso che se

l’utente fa scorrere il mouse sopra tale sprite, viene generato un “messaggio”

recepibile dall’oggetto che si vuole selezionare. Tale area, nel caso di una

linea, sarà uguale alla linea stessa solamente di spessore tale da permetterne

la selezione mentre, nel caso di una forma chiusa, avrà lo stessa forma del

confine di questa ma, anche qui, con spessore maggiorato10. Il metodo add-

SelectionHitArea si occupa di disegnare la hitArea. La hitArea deve essere

disegnata per ogni tipo di oggetto, ma il modo con cui questo effettivamente

avviene dipende dal tipo di oggetto, pertanto anche questo metodo rimane

virtuale nella classe DrawingObject. Gli ultimi due metodi che permettono

ad ogni elemento disegnabile di avere un’interfaccia comune ma di non poter

essere implementati nella loro comune classe base sono: doScaling, che per-

mette lo scaling dell’oggetto selezionato, rispetto al baricentro, mediante gli

appositi widget dell’interfaccia e drawGrid, che disegna una cornice attorno

all’oggetto selezionato.

5.5.4 Le classi Line e Polygon

Le classi Line e Polygon sono sottoclassi di DrawingObject.

Queste due classi implementano in modo diverso i punti di controllo

mediante i quali vengono disegnati i corrispondenti oggetti. La classe Li-

ne, ovviamente, contiene delle proprietà con le coordinate dei due estremi

del segmento. La classe Polygon. invece contiene un array con i punti di

controllo della forma chiusa delimitata da una linea mista. Come detto pre-

cedentemente questi punti possono essere morbidi o duri. Nell’esempio di10Tale area sarà ovviamente invisibile perché si tratta solamente di un accorgimento

tecnico


Figura 5.1 i punti P1, P6, P7, P8 e P10 sono duri mentre i punti P2, P3, P4, P5

e P9 sono morbidi.

Queste due classi fanno l’override dei metodi virtuali di DrawingObject:

draw, calcBaricenter, addSelectionHitArea, doScaling e drawGrid. Ad esem-

pio, all’interno della classe Line, è finalmente possibile e sensato scrivere il

corpo del metodo calcBaricenter proprio perché tale classe ha nozione delle

coordinate degli estremi del segmento e, pertanto, è possibile calcolarne il

baricentro come punto di mezzo.

Il metodo draw della classe Line semplicemente disegna un segmento

di linea in corrispondenza dei due estremi mentre il discorso per la classe

Polygon è più complesso e viene descritto nella prossimo paragrafo.

5.5.5 La classe BSpline

Vediamo ora come è organizzato il codice responsabile del disegno dei

tratti curvilinei delle nostre forme chiuse. La classe mediante la quale si ge-

stiscono questi tratti è la classe BSpline. Questa è abbastanza specializzata,

nel senso che è progettata per creare curve BSpline con tutte le caratteri-

stiche viste nel paragrafo 5.3, ciononostante non prevede nessun metodo di

disegno. Il disegno effettivo della curva è demandato a metodi esterni alla

classe e, nel nostro caso, alla classe Polygon. Quando l’utente, dopo aver se-

lezionato il tool “Soften edges”, clicca su un vertice di un oggetto Polygon per

renderlo morbido viene invocato il metodo createBSplineObjects della classe

Polygon che crea un oggetto BSpline per ogni tratto curvo della forma su

cui si sta operando. Ad esempio se l’utente avesse appena cliccato sul punto

P5 giungendo così alla situazione di Figura 5.1, il metodo createBSplineO-

bjects avrebbe creato due oggetti BSpline e ne avrebbe salvato i riferimenti

nell’array BSplineObjects della classe Polygon. Ovviamente il metodo non

crea solamente le istanze della classe BSpline ma inizializza opportunamente

tali oggetti. Ovvero setta la proprietà n, cioè il numero meno uno dei punti

di controllo della curva, e la proprietà k, l’ordine della curva. Inoltre per

ogni oggetto BSpline invoca il metodo computefdmValuesArray che svolge le

seguenti operazioni:

1. crea, e salva nella proprietà di tipo Array splineKnots, il vettore con-


tenente la sequenza dei nodi costruita con il criterio illustrato prece-

dentemente

2. crea, e salva nella proprietà di tipo Array knots, una sequenza di valori,

formante una partizione uniforme dell’intervallo di definizione della

curva [tk−1, tn+1]. Il numero di elementi di splineKnots è quality · (n−k+2), dove “quality” è una proprietà di tipo numerico impostata in fase

di creazione dell’oggetto BSpline mediante il relativo “costruttore”11.

3. crea una matrice, o meglio un Array contenente a sua volta Array12, di

nome fdmValues, contenente, per ogni valore del vettore knots, i cor-

rispondenti k valori delle funzioni B-Spline (funzioni di miscelamento)

che danno un contributo nella 5.1.

La funzione createBSplineObjects esamina, uno ad uno, i punti di con-

trollo dell’oggetto Polygon nello stesso ordine con cui sono stati posizionati

sull’area di disegno e crea gli oggetti BSpline man mano che incontra seg-

menti curvi13. Quindi, riferendoci sempre al caso della Figura 5.1, crea come

primo oggetto BSpline quello relativo alla curva_

P1P6 e successivamente quel-

lo relativo alla curva_

P8P10. Le proprietà dei due oggetti BSpline vengono

quindi impostate in questa maniera14:11Il “costruttore” è un metodo che ha lo stesso nome della classe di appartenenza. Viene

invocato automaticamente durante la creazione di un oggetto e, generalmente, è utilizzato

per inizializzare alcune o tutte le proprietà di una classe.12Esiste, nella libreria di Flex, la classe Matrix, ma questa non rappresenta una matrice

generica ma solamente matrici 3x3 utilizzate per le trasformazioni affini di oggetti visuali.13Se il primo punto dell’oggetto Polygon considerato è morbido allora gli oggetti BSpline

vengono creati a partire dalla curva successiva a quella contenente tale punto.14In questo esempio la proprietà quality dei due oggetti BSpline è impostata col valore

20.


Curva:_

P1P6

n: 5

k: 4

splineKnots: {0, 0, 0, 0, 1, 2, 3, 3, 3, 3}knots: {0, .05, .1, . . . , 1, . . . , 2, . . . , 2.90, 2.95, 3} 60 valori

fdmValues:

1 0 0 0

... ... ... ...

0 0 0 1

60 righe

Curva:_

P8P10

n: 2

k: 3

splineKnots: {0, 0, 0, 1, 1, 1}knots: {0, .05, .1, . . . , 0.9, 0.95, 1} 20 valori

fdmValues:

1 0 0

... ... ...

0 0 1

20 righe

Notiamo la forma delle due matrici fdmValues. Il numero delle righe coin-

cide con il numero di elementi del vettore knots, cioè per ogni valore del

parametro t ogni riga contiene i k valori di quelle funzioni Ni,k(t) che forni-

scono un contributo alla sommatoria a secondo membro dell’equazione 5.1.

Ad esempio, la prima riga della matrice fdmValues relativa alla curva_

P1P6

è {1, 0, 0, 0} perchè per il valore del parametro t = 0 le funzioni B-Spline che

portano un contributo sono Nj,4(t), j = 0, 1, 2, 3 che, calcolate appunto in

t = 0, restituiscono i valori {1, 0, 0, 0}.Si sarà notato che fino ad ora non sono stati inviati agli oggetti BSpline

informazioni sulle coordinate dei punti di controllo. Il codice calcola i valori

delle funzioni B-Spline mediante la formula di ricorrenza di Cox - de Boor

(vedi [19]). Nella equazione 5.1 la valutazione delle funzioni di miscelamen-

to nei punti del vettore knots è, dal punto di vista computazionale, molto

onerosa. Siccome gli array splineKnots, knots e l’array di array fdmValues di-

pendono unicamente dal numero di punti di controllo, e non dalle coordinate

degli stessi, possono essere settati ogni volta che un punto viene reso morbido


e lasciati inalterati quando invece si spostano alcuni punti di controllo15 op-

pure l’intero oggetto16. I riferimenti ai punti di controllo delle curve, con le

relative coordinate, verranno passati agli oggetti BSpline nel codice del me-

todo draw. Quando si clicca su un punto di controllo per renderlo morbido,

il codice, come abbiamo visto, invoca il metodo createBSplineObjects per

creare ed impostare gli oggetti BSpline e, successivamente, il metodo draw

per disegnare effettivamente la curva. Il metodo draw, a sua volta, chiama

il metodo “computeCurve” che svolge i calcoli della equazione 5.1 avvalen-

dosi però dei dati contenuti nella proprietà fdmValues, cosa che velocizza

esponenzialmente il calcolo. Siccome quando si rende morbido un punto il

metodo draw viene chiamato una volta sola, l’overhead dovuto alla creazio-

ne degli oggetti BSpline è trascurabile. Quando invece si effettuano quelle

operazioni sulle curve di un oggetto o sull’oggetto intero che comportano il

ridisegno dell’oggetto in rapida successione, il fatto che il metodo draw debba

soltanto eseguire una sommatoria numerica, e non il calcolo delle funzioni di

miscelamento, consente di ottenere un applicativo fluido e leggero.

Per ogni elemento del vettore knots, il metodo “computeCurve” esegue

la sommatoria di 5.1 sostituendo a Pi le coordinate dei punti di controllo e

usando gli elementi della matrice fdmValues per i valori delle funzioni Ni,k.

Inoltre salva i risultati negli array “xValues” e “yValues”. Il metodo draw

disegna la curva unendo, con dei piccoli segmenti, uno dopo l’altro i punti

(xValues[n],yValues[n]), cioè i punti aventi come prima coordinata un ele-

mento del vettore xValues e come seconda un elemento di yValues, entrambi

presi con lo stesso indice all’interno dei rispettivi vettori. Siccome il nu-

mero di elementi di knots è uguale a quello dei vettori xValues e yValues,

e, siccome un maggior numero di elementi di questi due vettori implica un

aspetto più “liscio” della curva disegnata, si deve trovare un valore del para-

metro quality che assicuri una grafica gradevole senza sacrificare la fluidità

dell’applicazione. Si noti che il vettore knots ha un numero di elementi diret-

tamente proporzionale non solo al parametro quality ma anche al numero di

nodi compresi nell’intervallo di definizione. Pertanto le curve “lunghe”, cioè

con un alto numero di punti di controllo, avranno la stessa qualità grafica di15Mediante l’apposito tool “Select ctrl points”.16Mediante l’apposito tool “Select objects”.


Click su punto di controllocon tool “Soften Edges”

createBSplineObjects

Oggetto BSpline 1

● fdmValues

Oggetto BSpline 2

● fdmValues

Oggetto BSpline 3

● fdmValues

Crea...

draw

computeCurve computeCurve computeCurve

Usa

Usa

Usa

Figura 5.7: Diagramma riassuntivo delle operazioni svolte dal codice in rispostaal click su un punto di controllo mediante il tool “Soften edges”.


quelle “corte”.

5.6 La gestione degli eventi del mouse all’interno

dell’applicazione

Nell’implementare la nostra applicazione si è presentata ladifficoltà di

gestione degli eventi del mouse.

A disposizione dell’utente esiste il tool “Select ctrl points”, che permette

di selezionare i punti di controllo dell’oggetto selezionato, e di muoverli a

piacimento all’interno dell’area di disegno, per modificarne la forma.

Quando l’utente muove il mouse sopra un punto, questo si colora di giallo

per indicarne la selezione e, se l’utente clicca sul punto, questo può essere

trascinato.

La gestione degli eventi di questa operazione era inizialmente organizzata

nella maniera seguente. I punti sono impostati per reagire agli eventi “Mou-

seEvent.MOUSE_OVER” e “MouseEvent.MOUSE_OUT”, cioè quando il

puntatore del mouse passa sopra un punto o ne esce fuori.

Quando l’utente passa sopra un punto, il codice lo colora di giallo e lo

considera selezionato (impostando a “true” apposite proprietà della classe

ControlPoint rappresentante i punti di controllo). Se l’utente clicca sul pun-

to, l’applicazione inizia a registrare il movimento del mouse per muovere il

punto (evento “MouseEvent.MOUSE_MOVE”) e si interrompe l’ascolto de-

gli eventi MOUSE_OVER e MOUSE_OUT17 perché, trascinando il mou-

se con una certa velocità, il puntatore può uscire e rientrare sul punto di

controllo ma non si vuole che questo venga continuamente deselezionato e

riselezionato.

Appena si inizia a muovere il punto, il codice ascolta il momento in cui

l’utente rilascerà il pulsante del mouse (evento “MouseEvent.MOUSE_UP”).

Il rilascio del mouse può avvenire col puntatore fuori dal punto (movimen-

to veloce del mouse), allora il codice provvede a deselezionare il punto e a

riattivare l’ascolto degli eventi MOUSE_OVER e MOUSE_OUT. Se inve-17Mediante il metodo “removeEventListener”, il cui utilizzo è analogo a quello di

addEventListener ma interrompe l’ascolto dell’evento specificato.


ce il rilascio avviene col puntatore all’interno del punto il codice ricollega

semplicemente l’ascolto degli eventi MOUSE_OVER e MOUSE_OUT alle

funzioni di selezione e deselezione dei punti di controllo.

Quanto esposto descrive gli aspetti principali della logica con cui era

inizialmente implementata l’operazione di selezione e movimento dei punti

di controllo dell’oggetto selezionato. Si presenta però un problema nella

situazione in cui l’utente ha selezionato un punto, ha cliccato sopra questo

ed ha iniziato a spostarlo trascinando il mouse, poi rilascia il pulsante del

mouse con il puntatore posizionato sul punto di controllo.

Seguendo lo schema di Figura 5.8, si vede che non si attiva la funzione di

deselezione del punto di controllo. Nonostante ciò dovrebbe riattivarsi l’a-

scolto dell’evento MOUSE_OUT sul punto mosso e, all’uscita del puntatore

dal punto, questo dovrebbe deselezionarsi. Se l’utente, dopo il rilascio del

pulsante, esegue immediatamente un movimento repentino col mouse, il pun-

tatore potrebbe uscire dal punto prima che l’applicazione cominci a registrare

l’evento MOUSE_OUT. In questo caso il punto non verrebbe deselezionato

compromettendo, ovviamente, la consistenza interna dell’applicazione.

Come si vede la gestione degli eventi del mouse è delicata e porta facil-

mente a sottili errori di programmazione.

Una soluzione è quella di assegnare una hitArea al punto di controllo ap-

pena ci si clicca sopra per muoverlo. Questa hitArea può essere, ad esempio,

l’elemento più grande nel quale il punto può muoversi18.

Un’altra soluzione, probabilmente più elegante, è quella di separare com-

pletamente le operazioni di selezione e deselezione dei punti da quelle ne-

cessarie al movimento di questi. Per fare ciò, non si disattiva l’ascolto degli

eventi MOUSE_OUT e MOUSE_OVER quando si clicca sul punto da muo-

vere ma si salva in una nuova variabile il riferimento del punto che l’utente

intende muovere; in questo modo i punti verranno selezionati e deselezionati

senza i problemi esposti sopra. Inoltre, fino a quando l’utente non rilascia

il mouse, l’applicazione conosce quale punto deve spostare qualunque sia la18Nell’applicazione si tratta di un oggetto “Canvas” contente l’area di disegno e che

funge da cornice atta a contenere eventuali punti morbidi di un oggetto che fuoriescono

da questa.


Selezionato tool “Select ctrl points”

Click su un puntodi controllo

Fine ascolto MOUSE_OVER

Fine ascolto MOUSE_OUT

MOUSE_MOVE sul punto selezionato

MOUSE_UP sul punto selezionato

Seleziona punto

MOUSE_OUT Deseleziona punto

MOUSE_OVER

L‘utente muove il mousee poi rilascia

Al momento del rilascio il puntatore è dentro il

punto di controllo?

SÌ

STOP

SÌ

NO

Deseleziona il punto di controllo

NO L‘utente deseleziona tool

“Select ctrl points”?

Figura 5.8: Sequenza logica seguita dal codice per muovere i punti di controllo


posizione del puntatore, mettendosi al riparo da eventuali movimenti bruschi

da parte dell’utente.

Capitolo 6

La distribuzione sul Web:

confronto tra Flex e Matlab

6.1 Introduzione

Durante il corso di Laurea sono entrato in contatto con diversi pacchetti

software. Uno di questi è MATLAB, di cui ho potuto approfondire le po-

tenzialità e che, in ambiente accademico, riveste un ruolo importante tra gli

strumenti di sviluppo di applicativi.

Finora si sono viste le potenzialità di Flex per portare contenuti alta-

mente dinamici ed interattivi sul web. I linguaggi e gli standard su cui è

basato Flex però sono stati progettati per rendere possibile la realizzazione

delle più diverse tipologie di software e non sono specializzati verso il calcolo

scientifico e numerico o verso ambiti ingegneristici. Il pacchetto MATLAB

è invece prettamente rivolto al calcolo numerico, offre la possibilità di crea-

re applicazioni, anche dotate di GUI, molto rapidamente ed è corredato da

numerosi “Toolbox”, pacchetti aggiuntivi che ne estendono le capacità e sono

rivolti ad ambiti scientifici ed ingegneristici.

Avendo avuto la possibilità di utilizzare questi due ambienti di svilup-

po, MATLAB e Flex, ho voluto dapprima approfondire le possibilità che il

primo offre per distribuire le proprie applicazioni sul web e successivamente

presentare i dovuti confronti tra i due software tenendo conto dei principali

aspetti del ciclo di sviluppo di un’applicazione: la scrittura del codice e la

79

CAPITOLO 6. MATLAB PER IL WEB 80

distribuzione dell’applicativo stesso.

Nei prossimi paragrafi, pertanto, vedremo alcune opzioni, offerte da MA-

TLAB stesso, per portare sul web le applicazioni con esso costruite. Una di

queste è quella di trasformare una applicazione MATLAB in una applicazio-

ne stand-alone che, come vedremo, sarà direttamente eseguibile dal compu-

ter dell’utente. Con questo approccio il web viene impiegato semplicemente

come veicolo per distribuire l’applicativo stesso.

MATLAB inoltre fornisce la possibilità di interfacciare il proprio codice

con varie tecnologie, tra le quali la piattaforma .NET e l’applicativo Excel

di Microsoft e il linguaggio Java. Esamineremo cosa offre la cooperazione

tra i linguaggi MATLAB e Java sempre nell’ottica di permettere all’utente

di accedere al software realizzato con MATLAB attraverso il web.

Infine presenteremo un confronto tra Flex e MATLAB soprattutto evi-

denziando per quale tipologia di applicazioni sia meglio scegliere l’uno o

l’altro come ambiente di sviluppo.

6.2 Distribuire un’applicazione MATLAB in forma-

to eseguibile attraverso il web

Questa possibilità ci viene offerta dal MATLAB Compiler, strumento

compreso nel pacchetto, che converte il codice MATLAB in codice C/C++

e lo compila creando un eseguibile. In alternativa, il Compiler può creare

delle librerie che possono essere usate per implementare applicazioni scritte

in C/C++. È possibile, inoltre, utilizzare il “deploytool”, che permette di

compilare il proprio codice mediante la GUI di MATLAB senza usare il

compilatore dalla riga di comando.

Per testare il tutto si è considerata una piccola applicazione MATLAB,

dotata di GUI, che visualizza una curva spline, parametrica, interpolante

tre punti (in corrispondenza dei valori del parametro 0, 1/2 e 1) e tangente

ad una retta passante per il primo punto1. Mediante la GUI l’utente può

specificare le coordinate dei tre punti e la direzione della retta (vedi Figura1Reperibile qui: http://www.pitchup.com/tinyprojects/3pointsspline/spline.

htm

http://www.pitchup.com/tinyprojects/3pointsspline/spline.htm

http://www.pitchup.com/tinyprojects/3pointsspline/spline.htm


6.1). Il test ha dato esito positivo, è sufficiente indicare a MATLAB quale m-

Figura 6.1: Applicazione per testare il MATLAB Compiler

file compilare e selezionare l’opzione “applicazione stand-alone” per ottenere

un eseguibile di pochi kilobyte. Tutto il linguaggio MATLAB è compilabile,

esistono però delle limitazioni riguardanti alcuni toolbox e le GUI predefinite

del pacchetto.

A questo punto l’eseguibile ottenuto può essere distribuito fornendo un link

al file appena creato all’interno di una pagina web. In questo modo però non

abbiamo un’applicazione Internet vera e propria ma utilizziamo il web come

strumento per distribuire la nostra applicazione.

Ottenuto il file eseguibile l’utente può avviare l’applicazione anche su

un computer che non include MATLAB nel proprio parco software a patto

che su tale macchina sia installato il “MATLAB Component Runtime” di cui

tratteremo nel prossimo paragrafo.


6.3 Il MATLAB Component Runtime

Il MATLAB Component Runtime è l’insieme di librerie a link dinami-

co necessarie al funzionamento delle applicazioni create con il MATLAB

Compiler su computer che non hanno MATLAB installato.

Il MATLAB Component Runtime si installa con il tool “MCRInstaller”

che automatizza il tutto. Questo però occupa 171 megabyte di spazio su

disco2, rendendone ostico l’eventuale download dal web in mancanza di una

connessione performante. Inoltre, le applicazioni che si vogliono distribuire,

funzioneranno solo se la piattaforma su cui sono state compilate coincide

con quella della macchina target. Pertanto un utente con sistema operativo

Gnu/Linux non potrà far funzionare applicazioni compilate su un computer

con Windows anche con il MCR installato.

Molte Università forniscono sul proprio sito web un link per il download

del MCRInstaller e i link per le vari applicazioni sviluppate in MATLAB. La

distribuzione del MCR è legale e gratuita.

6.4 Matlab e Java

Sempre compreso in MATLAB, troviamo il MATLAB Builder for Java.

Questo tool trasforma il codice MATLAB in una o più classi Java e, ad ogni

funzione MATLAB, corrisponde un metodo Java che può essere invocato da

un’altra applicazione Java. Infatti questo strumento non prevede la creazione

di applicazioni stand-alone, ma solamente di componenti Java che fungono da

librerie per altre applicazioni. In ogni caso è sufficiente scrivere un minuscolo

frammento di codice Java per chiamare i metodi delle classi creati dal Builder

per ottenere un’applicazione eseguibile.

L’“m-file” contente il codice dell’applicazione di test usata poc’anzi è di

tipo function. I parametri che questa funzione MATLAB accetta in input

servono per specificare delle opzioni della GUI mentre, quelli restituiti in

output, servono per poter controllare tale interfaccia da codice esterno, en-

trambi, pertanto, non sono fondamentali. Il MATLAB Compiler, istruito per2Nella sua versione per la famiglia di sistemi operativi Windows, questa dimensione è

pressoché analoga a quella delle altre piattaforme.


creare un’applicazione stand-alone, generava, nell’esempio precedente, il co-

dice necessario per invocare la funzione “spl” senza parametri in input. Que-

sto è possibile perchè il parametro in input della funzione è di tipo ”varargin”

e pertanto la funzione può essere invocata senza parametri obbligatori.

6.5 Costruzione di un’applicazione Java

Vediamo adesso le operazioni necessarie per creare un’applicazione Java

in quanto, con tale linguaggio, come si vedrà in seguito, è possibile sfruttare

un’altra possibilità per portare contenuti MATLAB sul web.

Anche per il MATLAB Builder for Java è disponibile una GUI per non ri-

correre alla riga di comando. Si adopera questo tool per indicare a MATLAB

di convertire il m-file “spl.m” in codice Java.

Creiamo un progetto di nome “spl” e aggiungiamo a questo il file spl.m,

dopo di che clicchiamo sul bottone preposto alla trasformazione del codice.

Il Builder genera anche dei comodi file HTML con la documentazione delle

classi e dei metodi Java appena creati. A questo punto editiamo questo file

Java che chiameremo “wrapper.java”:

import com.mathworks.toolbox.javabuilder.*;

import spl.*;

public class wrapper{

public static void main(String[] args){

try{

splclass instance = new splclass();

instance.spl(0);

}

catch (Exception e){

System.out.println("Exception: " + e.toString());

}

}

}

Le prime due righe sono obbligatorie e servono ad importare classi e metodi

necessari alla creazione dell’applicazione; la prima riga corrisponde al codice


contenuto nell’archivio “javabuilder.jar” fornito insieme al pacchetto, mentre

la seconda si riferisce all’archivio “spl.jar” ottenuto grazie al Builder for Java.

Analizzando la documentazione HTML generata dal Builder si vede co-

me, nel nostro caso, dobbiamo instanziare la classe “splclass” e, tramite

l’oggetto creato, chiamare il metodo “spl”. La ”firma” di spl è:

public java.lang.Object[] spl(int nargout,

java.lang.Object... rhs)

throws com.mathworks.toolbox.javabuilder.MWException

Spl richiede pertanto un parametro in input (“nargout”) di tipo “int” (nu-

mero intero) indicante il numero di elementi restituiti dalla funzione MA-

TLAB, siccome la funzione in MATLAB restituisce solamente un “handle”

per manipolare la GUI possiamo passare il valore 0.

Il secondo parametro (“rhs”) di tipo “java.lang.Object...” rappresenta

un array a lunghezza variabile equivalente al “varargin” di MATLAB, nel

nostro caso non passiamo nessun valore dato che questi parametri settano

semplicemente delle opzioni della GUI.

Si notino i blocchi try/catch, sono indispensabili in quanto sia il costrut-

tore della classe splclass sia il metodo spl possono sollevare eccezioni.

La documentazione ufficiale descrive la API “MWArray” che permette di

gestire nel codice Java i vari tipi di matrici di MATLAB.

Se non è stato fatto in precedenza si deve scaricare il Java Development

Kit (JDK) dal sito http://java.sun.com, il compilatore Java, per compilare

il file wrapper.java.

Dopo averlo installato compiliamo col comando3:

javac -classpath javabuilder.jar;spl.jar wrapper.java

Per eseguire l’applicazione utilizziamo invece il comando4:

java -classpath .;javabuilder.jar;spl.jar wrapper

3Si assume che i file javabuilder.jar e spl.jar siano nella stessa cartella del file

wrapper.java e che la directory corrente coincida con la cartella contenente questi file.4Alternativamente è possibile creare un archivio eseguibile “jar”, con l’omonimo tool

fornito insieme al JDK, in modo da ottenere un singolo file avviabile con un semplice click.

http://java.sun.com


Anche in questo caso, per far girare l’applicazione, è necessario che sulla

macchina sia installato MATLAB o il MCR.

Inoltre non è prevista la possibilità di creare applet o applicazioni com-

patibili con la tecnologia “Java Web Start”.

Questa limitazione, come anche nel caso precedente in cui si creava un

programma C/C++, non ci consente di sviluppare delle applicazioni web

vere e proprie ma solamente di permettere il download di queste da un sito

web.

Il vantaggio di usare Java è quello di poter scrivere programmi con un

linguaggio più semplice del C/C++ e che, rispetto a questo, ha una libreria

standard che permette la creazione di ogni genere di applicazione senza dover

ricorrere ad API di sistema o a codice di terze parti.

Pertanto è possibile scrivere in Java tutte quelle funzionalità in cui MA-

TLAB non eccelle, in quanto non rappresentanti l’obiettivo principe del

pacchetto, per costruire, ad esempio, software altamente interattivo e gra-

ficamente appetibile sfruttando magari il bagaglio di algoritmi MATLAB

sviluppati precedentemente.

6.5.1 MATLAB e le servlet Java

Si è approfondito come interfacciare Java con MATLAB anche per un

altro motivo, ossia per utilizzare la tecnologia delle “Servlet” Java, le quali

sono dei programmi lato-server che permettono di generare contenuto dina-

mico nelle pagine web, rientrando di diritto nel campo delle applicazioni web

e non più nella semplice distribuzione di software mediante il web.

Con questa tecnologia, analoga alla CGI (vedi 1.6), l’utente, raggiunta

l’apposita pagina, compila un modulo con i dati di input, l’invia al server che

calcola la risposta, con l’ausilio del codice MATLAB trasformato in Java, e

la invia, formattata come pagina HTML, all’utente.

Per verificare le potenzialità si è seguito il demo “VarArgServlet” suggerito

dalla documentazione MATLAB, per il quale è necessario disporre di un web

server5 predisposto alle Servlet Java (ad esempio “Tomcat” in quanto open5Un web server è un programma (e, per estensione, il computer) che si occupa di fornire,

su richiesta del browser, una pagina web (spesso scritta in HTML). Le informazioni inviate

dal web server viaggiano in rete trasportate dal protocollo HTTP. L’insieme di webserver


source, affidabile e facile da configurare).

Mentre le funzioni MATLAB possono rimanere pressocché invariate, è

necessario creare almeno un file Java che svolga le operazioni di lettura

dell’input inviato dall’utente e di formattazione della pagina HTML.

Dopo aver seguito le istruzioni di compilazione del codice e aver posi-

zionato i file nelle giuste directory del webserver, questo è pronto a ricevere

l’input dell’utente tramite la pagina web contenente il modulo (vedi Figura

6.2).

Figura 6.2: Pagina contenente il form per inviare i dati al web server

L’applicazione sul server riceve i valori immessi dall’utente e restituisce

una pagina HTML contenente i dati di media e deviazione standard oltre ad

un grafico con il “plot” dei valori stessi (vedi Figura 6.3). Sopra il plot pos-

siamo notare dei comandi, questi servono per ingrandire, spostare o ruotare

in 3D il grafico e sono offerti dalla funzionalità “WebFigures” di MATLAB,

pertanto, questi strumenti, non devono essere programmati a parte ma sono

disponibili per tutti i grafici.

presenti su Internet forma il World Wide Web (WWW), uno dei servizi più sfruttati della

Grande Rete (citazione da [17]).


Figura 6.3: La risposta dal web server


Se si salva la pagina web di Figura 6.3 possiamo vedere che questa è

costituita da codice HTML, file immagine contenti il grafico e file con codice

Javascript, che registrano le richieste dell’utente mediante i tool forniti da

WebFigures e richiedono alla Servlet l’immagine aggiornata.

Siccome sia la pagina per l’invio dei dati, sia gli elementi costituenti quella

ottenuta in risposta, sono quelli del web classico, il browser non ha bisogno

di nessun plug-in per visualizzare il tutto, inoltre, dato che la Servlet gira sul

web server, l’utente non deve nemmeno installare il MCR né, tanto meno,

MATLAB.

6.6 Confronto tra i due pacchetti

Prima di illustrare le differenze tra MATLAB e Flex è necessario fare

una precisazione. Due prodotti così evoluti, complessi e di successo come

quelli che andremo a paragonare possiedono un numero di funzionalità tal-

mente elevato da coprire pressoché qualsiasi esigenza un utente possa avere.

MATLAB, ad esempio, è nato come come strumento per il calcolo numerico

eppure include due toolbox (il “Symbolic Math Toolbox” e il “Extended Sym-

bolic Math Toolbox”) per la matematica simbolica e, come abbiamo visto,

diverse possibilità per distribuire le proprie applicazioni sul web. D’altra

parte Flex rappresenta una evoluzione di Adobe Flash. Entrambi i prodotti,

infatti, creano delle applicazioni che funzionano mediante lo stesso runtime

environment, ma mentre Flash è più orientato verso l’animazione grafica ed

è carente dal versante della creazione di RIA, Flex colma questa lacuna pur

mantenendo molte delle caratteristiche di disegno ed animazione vettoriali di

Flash, sia mediante la programmazione diretta di queste attraverso le proprie

librerie sia permettendo l’importazione dei file creati con Flash. Nonostante

ciò Flex e MATLAB mantengono i loro punti di forza negli ambiti per cui

sono stati inizialmente progettati ed un confronto tra i due deve tenere conto

di questo aspetto.

Iniziamo a considerare le differenze tra i linguaggi dei due pacchetti. In-

dicheremo con “linguaggio Matlab” il linguaggio di programmazione di MA-

TLAB non avendo questo un suo nome proprio. Esistono letteralmente cen-

tinaia di linguaggi di programmazione. Per confrontarne due si dovrebbe


valutare la semantica, la sintassi e l’implementazione interna di ciascuno e

ciò va ben oltre le conoscenza dell’autore e lo scopo di questo documento. Si

possono però fare alcune osservazioni di carattere generale.

Il linguaggio Matlab è interpretato, questa caratteristica permette a MA-

TLAB di fornire un ambiente di sviluppo interattivo dove l’utente può im-

mettere comandi nell’apposita “command window” ed ottenere una risposta

immediata senza dover prima compilare il codice. Inoltre, nonostante sia pos-

sibile la programmazione orientata agli oggetti, tale linguaggio viene quasi

sempre utilizzato in maniera procedurale per svariati motivi tra cui il fatto

che l’utente di MATLAB è generalmente interessato all’aspetto scientifico del

codice che sta scrivendo e meno alla struttura del medesimo ma soprattutto

perché le prime versioni del linguaggio non prevedevano tale paradigma di

programmazione e pertanto tale possibilità viene generalmente vista come

una caratteristica aggiuntiva, come in effetti è, di secondaria importanza

(vedi [20, 21]).

Il linguaggio Matlab inoltre è imperniato sul concetto di matrice, nel

senso che permette di creare e manipolare matrici di varie dimensioni con

grande facilità. Questa caratteristica porta dei vantaggi in vari campi e

caratterizza decisamente il linguaggio.

ActionScript è un linguaggio molto differente. Mentre il linguaggio Ma-

tlab può decisamente essere considerato un linguaggio di scripting e molto

specializzato, ActionScript, a dispetto del nome, ha un carattere molto più

generale e assomiglia per numerosi aspetti ad un linguaggio di sistema. Pri-

ma di tutto è un linguaggio compilato e ciò non permette di utilizzarlo in

un ambiente interattivo. In secondo luogo il processo di scrittura, compi-

lazione, debug è molto più lento rispetto a MATLAB proprio per questa

caratteristica di essere un linguaggio compilato.

ActionScript, a differenza del linguaggio Matlab, nasce ad oggetti anche

se il paradigma di programmazione si è evoluto nel corso delle tre versioni

del linguaggio. Il programmatore ActionScript è più propenso ad utilizzare

la programmazione orientata agli oggetti perché la documentazione e la let-

teratura in generale indirizzano in tale direzione fin dai primi rudimenti del

linguaggio.

Mentre il linguaggio Matlab è indirizzato al calcolo numerico e alla mani-


polazione di matrici, ActionScript non ha una sua pecularietà, anzi è molto

simile ad altri linguaggi come Java. Ciò comporta la scrittura di molte più

righe di codice nel caso di algoritmi numerici e scientifici rispetto a MA-

TLAB. Anche per questo motivo, ossia per l’alto numero di righe di codice

necessario per fare qualcosa di minimamente interessante, rende necessaria

una solida e rigorosa struttura del codice e, pertanto, altamente indicata la

programmazione orientata agli oggetti.

6.7 Considerazioni

In questo capitolo abbiamo visto alcune possibilità di portare applicazioni

MATLAB sui computer non aventi questo pacchetto installato anche se le

opzioni offerte non si limitano a quelle presentate in questa trattazione.

Flex, ovviamente, è molto più specializzato sotto questo aspetto, in quan-

to non solo permette di distribuire applicazioni sul web che potranno essere

installate sul computer dell’utente come i normali programmi Desktop grazie

al runtime Air, ma permette di creare componenti visualizzabili all’interno

dei browser a tutta pagina o integrati in pagine HTML esistenti.

Per scegliere quale dei due software sia il miglior ambiente di sviluppo

per le proprie applicazioni bisogna valutare alcuni aspetti.

Questi includono il considerare cosa si vuole ottenere, quale tipologia di

applicazione si vuole costruire e quanto tempo si ha a disposizione.

Se l’applicazione comprende molto calcolo numerico o ingegneristisco,

MATLAB permette un tempo di sviluppo molto più rapido di Flex per le

caratteristiche dei linguaggi interni appena viste. Se l’applicazione, magari

sempre di stampo scientifico, non comprende codice per il quale il linguaggio

o i toolbox di MATLAB possano essere di aiuto probabilmente Flex è la

scelta migliore.

Se l’obiettivo primario invece è quello di creare software il più possibile

fruibile dall’utente via web attraverso il browser allora la scelta di Flex è

altamente consigliata.

Se invece si vuole semplicemente distribuire l’applicazione permettendo

il download di questa attraverso un link in una pagina web allora, come

abbiamo visto, MATLAB offre più possibilità in questo senso. Bisogna in


ogni caso considerare che il Flash Player e il MATLAB Component Runtime,

ossia i runtime environment necessari per l’esecuzione delle applicazioni sui

computer degli utenti, hanno dimensioni molto differenti. In particolare il

MCR è molto più pesante del runtime di Flex e non tutti gli utenti potrebbero

permettersi di scaricarlo in mancanza di una connessione a banda larga.

Infine molte Facoltà dispongono di ingenti quantità di codice scritte per

MATLAB. In questo caso probabilmente la scelta migliore potrebbe essere

quella di interfacciare il codice MATLAB con Java o con la piattaforma

.NET per sfruttare le caratteristiche di tali tecnologie senza dover rinunciare

al codice preesistente.

Appendice A

Flex ed alcune caratteristiche

della programmazione

orientata agli oggetti

Il motivo principale della nascita e dello sviluppo della programmazione

orientata agli oggetti, avvenuta intorno agli anni ’60, risiede nella necessi-

tà di trovare un paradigma che permettesse di gestire software sempre più

complessi.

Quando scriviamo un programma Flex, anche banale, con pochi controlli e

un’interfaccia limitata, in realtà creiamo un qualcosa la cui complessità è

paragonabile a molte migliaia di righe di codice scritte in linguaggi quali il C

col solo ausilio della libreria standard di tale linguaggio e le Api del sistema

operativo. Questo è dovuto al fatto che il livello di astrazione dello strato

software fornito dal Runtime Environment di Flex e delle sue librerie di base

(cioè fornite col pacchetto stesso) è ben differente e molto più alto di quello

delle Api di un sistema operativo. Flex permette allo sviluppatore di creare

velocemente applicazioni comprensive di interfaccia grafica, di stampare, di

creare disegni vettoriali, di interfacciarsi con i vari protocolli di comunicazio-

ne di Internet, di gestire database e comunicazioni lato server e soprattutto

di, vero punto di forza, creare una fruttuosa sinergia tra un linguaggio di pro-

grammazione vero e proprio e le tecnologie regine dello sviluppo web quali

xml/xhtml, fogli di stile ma anche altri linguaggi come Java, Javascript e

92

APPENDICE A. LE CARATTERISTICHE DELLA OOP 93

Php. Ognuna di queste possibilità è accessibile tramite la libreria di Flex in

modo molto intuitivo e, velocemente, se ne possono utilizzare le principali

caratteristiche.

Al programmatore professionista deve però essere data la possibilità di

personalizzare al massimo ogni caratteristica e di poter accedere al livello

di astrazione più basso di ogni tecnologia con cui ci si può interfacciare; ad

esempio è possibile usare il protocollo http in maniera del tutto trasparente

per accedere a risorse sul web eppure la classe HTTPService permette di

gestire ogni più piccola caratteristica di questo fondamentale protocollo.

Il paradigma della programmazione orientata agli oggetti1 permette di

organizzare una libreria enorme come quella di Flex in modo che appaia

ordinata ed intuitiva allo sviluppatore. Le quattro caratteristiche di tale

paradigma sono la modularità, l’incapsulamento dei dati, l’ereditarietà e il

polimorfismo. Data la complessità di tale libreria, questa si rivela un ottimo

strumento per illustrare questi concetti.

La modularità si basa sul concetto di classe che è l’elemento fondamenta-

le di un linguaggio OOP: una classe è l’unione di un insieme di dati, chiamati

proprietà, e di alcune funzioni, chiamate metodi. Una classe è lo “stampo”

con cui vengono creati gli oggetti. Gli oggetti sono istanze delle rispettive

classi. Ad esempio la classe Button, che in Flex permette aggiungere un pul-

sante nell’interfaccia, possiede svariati proprietà fra cui le coordinate della

posizione del pulsante stesso e il testo dell’eventuale etichetta posta sopra

di esso. Ogni oggetto Button ha pertanto le proprietà delle coordinate della

posizione, impostati col valore della propria posizione e col campo del testo

impostato con la stringa del proprio testo visualizzato. I metodi sono nor-

mali funzioni che però operano generalmente sul singolo oggetto tramite il

quale vengono invocati. Ad esempio se si ha un Button di nome “Pippo” e

si invoca il metodo “move”, che prende in input due numeri e si occupa di

spostare il pulsante nelle nuove coordinate, questo sposterà solamente il pul-

sante Pippo nella nuova posizione e aggiornerà le proprietà delle coordinate

sempre limitatamente all’oggetto in questione.

Per ogni proprietà e ogni metodo di una classe si può specificare uno1d’ora in poi OOP da Object-Oriented programming


“specificatore di visibilità”, cioè un attributo che specifica se l’utente (inte-

so come programmatore) della classe può avere accesso alla risorsa. Questi

specificatori possono variare da linguaggio a linguaggio sia come nomi sia in

numero ma i principali sono due e, in ActionScript come nella quasi totalità

dei linguaggi OOP, sono chiamati private e public. Se una proprietà o un

metodo è dichiarato public allora l’utente può accedervi da ogni parte del co-

dice. Gli elementi public rappresentano l’interfaccia della classe cioè i servizi

che la classe mette a disposizione dell’utenza. Ogni classe ragionevolmente

complessa avrà però proprietà e metodi utili unicamente al proprio meccani-

smo interno e che, quindi, non solo non offrono direttamente servizi all’utente

ma non devono essere alterati inavvertitamente, pena errori nel codice molto

difficili da scovare in progetti di grosse dimensioni. Questi elementi saran-

no quindi dichiarati come private e non saranno accessibili dall’esterno della

classe. Se apriamo la documentazione di Flex e analizziamo la guida di riferi-

mento di una qualsiasi classe, notiamo che le proprietà e i metodi privati non

sono documentati proprio perché riguardano l’implementazione interna della

classe e non sono utili all’utente. Gli specificatori di visibilità permettono il

cosiddetto incapsulamento dei dati.

Con ereditarietà si intende la possibilità di creare classi che ereditano le

proprietà e i metodi di un’altra classe che chiameremo superclasse. La classe

che eredita viene chiamata sottoclasse. Oltre ad ereditare caratteristiche e

comportamenti la sottoclasse ne introduce di nuovi o modifica alcuni metodi

della superclasse. La sottoclasse sarà pertanto una versione più specializzata

della superclasse. Ogni sottoclasse può avere, a sua volta, altre sottoclassi

che ereditano da questa. Viene a crearsi una struttura ad albero avente come

radice la classe Object, la classe base di qualsiasi tipo di oggetto in Flex.

Ritorniamo alla nostra classe Button. Questa è una sottoclasse della

classe UIComponent, la classe base per tutti i componenti visuali, interattivi

o meno. Ad esempio le proprietà di tipo numerico height e width, rappresen-

tanti rispettivamente altezza e larghezza del componente, hanno significato

per qualsiasi elemento visuale e sono pertanto ereditati da tutte le sottoclas-

si di UIComponent. Anche molti metodi vengono ereditati come il metodo

move appena visto. Esiste inoltre la possibilità di dichiarare un metodo con

la parola chiave “override”. Tali metodi rimpiazzano quelli della superclas-


se. Ovviamente, per coerenza, dovrebbero (nonostante non sia obbligatorio)

svolgere la stessa funzione logica del metodo della superclasse di cui si vuole

fare l’override. Se creiamo una classe SpecialButton che eredita da Button,

e vogliamo un metodo move che lasci una scia tra la vecchia posizione del

bottone e quella nuova, possiamo fare l’override di tale metodo.

Abbiamo detto che tutti gli elementi visuali in Flex sono sottoclassi della

classe UIComponent. Siccome la classe UIComponent implementa il metodo

move, tutte le classi derivate dispongono di questo metodo, o, ereditato

direttamente da UIComponent, o ridefinito mediante override. Supponiamo

di voler scrivere una funzione che prende in input un valore numerico e un

un riferimento ad un qualsiasi elemento visuale e trasli orizzontalmente verso

destra l’elemento di un numero di pixel pari al primo parametro. La nostra

funzione potrebbe essere:

public function trasl(numOfPix:Number, visEl:UIComponent):void{

visEl.move(visEl.x+numOfPix,visEl.y);

}

L’esempio è minimale, inoltre, per ottenere lo stesso risultato, basterebbe

invocare il metodo move direttamente mediante l’oggetto interessato alla

traslazione, in ogni caso è sufficiente ad illustrare il principio del polimorfi-

smo. È possibile passare come secondo parametro del metodo “trasl” qualsiasi

oggetto di tipo UIComponent o di qualsiasi tipo derivato da tale classe. Il

metodo move che verrà invocato sarà il metodo move relativo alla classe

dell’oggetto pertanto, se l’oggetto fosse uno SpecialButton di cui sopra, il

metodo move invocato sarebbe quello più specializzato che disegna una scia

tra le due posizioni dell’elemento. Nei linguaggi “tipati”, cioè in quei linguag-

gi in cui per ogni variabile deve esserne dichiarato il tipo, tradizionalmente

era necessario scrivere codice diverso per ogni tipo di parametro. Nel nostro

caso una funzione diversa per ogni tipo di elemento visuale di cui si vuole

ottenere la traslazione. La caratteristica del polimorfismo permette di scri-

vere un solo frammento di codice valido per qualsiasi oggetto appartenente

ad una classe derivante da UIComponent pur mantenendo la caratteristica

di linguaggio tipato.

Glossario

account: Iscrizione registrata su un server che permette, tramite l’inseri-

mento di una userid e di una password, di accedere alla rete e/o ai

servizi, 2

API: (Acronimo: Application Programming Interface, interfaccia di pro-

grammazione delle applicazioni) Insieme di convenzioni che il program-

matore segue affinché il proprio software possa avvalersi dei servizi del

sistema operativo o di librerie esterne, 8

banda: (larghezza di) Quantità di dati per unità di tempo che può passare

su una connessione, e che viene poi divisa tra i vari utenti, 13

barra di progresso: Componente dell’interfaccia grafica usato per segnalare

lo stato di avanzamento di una operazione, 16

browser: Programma per la visualizzazione dei documenti multimediali che

costituiscono il World Wide Web, 4

cache: Zona di memoria (principale o secondaria) adibita a contenere prov-

visoriamente dati di frequente utilizzo allo scopo di consentirne un

rapido riutilizzo, 16

compilatore: programma che traduce un file di testo, contenente le istru-

zioni di un programma, in un formato (compilato) eseguibile da un

computer o da un apposito programma interprete , 13

database: Archivio elettronico in cui sono raccolte e organizzate delle in-

formazioni e consultabili o modificabili in base alle proprie esigenze,

8

96

GLOSSARIO 97

debugger: Software che semplifica l’individuazione e la correzione di errori

di programmazione, 17

directory: Una directory è un’area su disco per l’immagazzinamento dei

file. Le directory sono composte da file a altre subdirectory, 16

DOM: (Acronimo Document Object Model) É una interfaccia standard in-

dipendente dal linguaggio usato che permette a degli script di accedere,

modificare o creare elementi che costituiscono le pagine web (bottoni,

campi di testo, colori, dimensione del testo etc.) rendendo le pagine

web dinamiche ed interattive, 7

dominio: Parte dell’indirizzo Internet che ne stabilisce l’appartenenza ad

una categoria di sistemi o ad una area geografica, 12

editor: Software per redigere file di testo, 17

form: Modulo virtuale da compilare on line che viene inviato al server, 6

framework: Software che vengono progettati per diventare l’intelaiatura e

le fondamenta di altri programmi, 15

garbage collection: Funzionalità di un linguaggio di programmazione che

provvede automaticamente a rilasciare al sistema operativo il controllo

delle aree di memoria non più utilizzate dal codice del programma, 14

gif: (Acronimo: Graphics Interchange Format) è un formato per immagini

di tipo bitmap molto utilizzato nel World Wide Web, sia per immagini

fisse che per le animazioni, 28

GUI: Acronimo: Graphical User Interface, interfaccia grafica utente, 2

IDE: (Acronimo Integrated development environment) Ambiente di svilup-

po integrato, un software ad interfaccia grafica comprendente tutti i

tool necessari allo sviluppo di un programma organizzati in modo da

risultare facilmente accessibili, 17

Internet-Point: Luogo in cui si può accedere ad Internet generalmente con

una tariffa a tempo, 4

GLOSSARIO 98

interpretato: (Linguaggio) Linguaggio di programmazione di alto livello

il cui codice non è direttamente eseguito dal sistema operativo della

macchina ma viene interpretato da un secondo software che genera il

codice eseguibile, 6

Intranet: Rete privata che utilizza gli stessi protocolli di Internet, 14

mainframe: Un mainframe è un computer grande e dotato di elevata capa-

cità di elaborazione, 2

mark-up: (linguaggio di) Metodo di formattazione di un testo in cui, gene-

ralmente, si usano dei comandi delimitati da coppie di virgolette <co-

mando> (mark o tag) e </comando>, usato per terminare il comando

stesso, mediante i quali i contenuti all’interno vengono impaginati e

formattati di conseguenza, 5

motore di ricerca: Strumento per ricercare informazioni su Internet in base

all’argomento, dopo aver inserito una parola o una frase-chiave, 16

offline: Letteralmente “non il linea”, scollegati da Internet, 17

open source: software il cui codice viene rilasciato con una licenza che

permette a chiunque di analizzarlo e modificarlo, 15

peer to peer: (oppure p2p) Applicazione che non comunica con un server

centrale ma permette di creare reti composte da nodi (peer) che si

comportano contemporaneamente da client e server verso gli altri nodi

del network, 3

plugin: Modulo software che interagisce con un altro programma per am-

pliarne le funzioni, 8

programmazione ad oggetti: La programmazione orientata agli oggetti è un

paradigma di programmazione, che prevede di raggruppare in un’unica

entità (la classe) sia le strutture dati che le procedure che operano su di

esse, creando per l’appunto un “oggetto” software dotato di proprietà

(dati) e metodi (procedure) che operano sui dati dell’oggetto stesso

(citazione da [9] ), 14

GLOSSARIO 99

provider: Fornitore dei servizi Internet, 2

scaricare: (o download) Prelevare un file da internet e salvarne una copia

sulla macchina locale, 2

scripting: (Linguaggio di) Linguaggio di programmazione di alto livello,

interpretato e generalmente potente e facile da imparare, 6

sorgente: file di testo, contenente le istruzioni di un software, che verrà in

seguito compilato, 13

stand-alone: In questa trattazione con il termine si intende un software che

funziona come una normale applicazione Desktop e non all’interno di

un Browser, 8

UNIX: Sistema operativo per computer, 3

URL: Formato standard per identificare una risorsa Internet accessibile

tramite Word Wide Web, il modo universale di definire un indirizzo

Internet, 5

widget: Elemento dell’interfaccia utente, 8

Bibliografia e sitografia

[1] Daniel Manrique, X Window System Architecture,

Overview HOWTO, 2001

[2] National Center for Supercomputing Applications presso

l’Università dell’Illinois, The Common Gateway Interfa-

ce, specification v. 1.1, URL: http://hoohoo.ncsa.uiuc.

edu/cgi/

[3] Marco Casario, Il Ritorno d’investimento (ROI)

di una RIA, pubblicato da Augitaly, URL:

http://www.augitaly.com/flexgala/index.php?

cmd=newsreader&id=50, 2007

[4] Dana Moore, Raymond Budd and Edward Benson, Pro-

fessional Rich Internet Applications: AJAX and Beyond,

pubblicato da Wiley Publishing, Inc., 2007

[5] Andrea Giammarchi, Guida AJAX: Descrizione tecni-

ca e teorica, URL: http://javascript.html.it/guide/

lezione/2565/descrizione-tecnica-e-teorica/

[6] JAVATMWEB START OVERVIEW, White Paper, SUN

Microsystems, 2005

[7] Adobe Flex 2, Technical white paper, Adobe Inc., 2006

[8] Mike Chambers, Macromedia Flash MX Security,

pubblicato da Macromedia Inc., 2002

100

http://hoohoo.ncsa.uiuc.edu/cgi/

http://hoohoo.ncsa.uiuc.edu/cgi/

http://www.augitaly.com/flexgala/index.php?cmd=newsreader&id=50

http://www.augitaly.com/flexgala/index.php?cmd=newsreader&id=50

http://javascript.html.it/guide/lezione/2565/descrizione-tecnica-e-teorica/

http://javascript.html.it/guide/lezione/2565/descrizione-tecnica-e-teorica/

BIBLIOGRAFIA E SITOGRAFIA 101

[9] Wikipedia, the free encyclopedia, voce Programmazione

orientata agli oggetti, URL: http://it.wikipedia.org/

wiki/Programmazione_orientata_agli_oggetti, 2007

[10] Jeff Kamerer, Making Flash websites searchable ,

URL: http://www.adobe.com/devnet/flash/articles/

flash_searchability.html, 2006

[11] Sergio Rosati, Fisica Generale 2◦ ed, pubblicato da Casa

Editrice Ambrosiana Milano, 1994

[12] Thomas Smid, Elastic Collision in Three Dimen-

sions, URL: http://www.plasmaphysics.org.uk/

collision3d.htm

[13] John David N. Dionisio, Hidden Surface Removal, URL:

http://myweb.lmu.edu/dondi/share/cg/hsr.pdf

[14] Riccardo Scateni, Paolo Cignoni, Claudio Montani, Ro-

berto Scopigno, Fondamenti di grafica tridimensionale

interattiva, pubblicato da McGraw-Hill, 2005

[15] Wikipedia, the free encyclopedia, voce Java 3D, URL:

http://en.wikipedia.org/wiki/Java_3D, 2008

[16] Davide Beltrame, Introduzione a Papervi-

sion3D, pubblicato da Html.it, URL: http:

//flash.html.it/articoli/leggi/2213/

introduzione-a-papervision3d/, 2007

[17] Wikipedia, the free encyclopedia, voce Web server, URL:

http://it.wikipedia.org/wiki/Web_server, 2008

[18] Microsoft Developer Network, articolo Anatomy of a pa-

th, URL: http://msdn.microsoft.com/en-us/library/

cc294864.aspx

[19] Carl de Boor, A Practical Guide To Splines, Revised

Edition, pubblicato da Springer, 2001

http://it.wikipedia.org/wiki/Programmazione_orientata_agli_oggetti

http://it.wikipedia.org/wiki/Programmazione_orientata_agli_oggetti

http://www.adobe.com/devnet/flash/articles/flash_searchability.html

http://www.adobe.com/devnet/flash/articles/flash_searchability.html

http://www.plasmaphysics.org.uk/collision3d.htm

http://www.plasmaphysics.org.uk/collision3d.htm

http://myweb.lmu.edu/dondi/share/cg/hsr.pdf

http://en.wikipedia.org/wiki/Java_3D

http://flash.html.it/articoli/leggi/2213/introduzione-a-papervision3d/



http://it.wikipedia.org/wiki/Web_server

http://msdn.microsoft.com/en-us/library/cc294864.aspx

http://msdn.microsoft.com/en-us/library/cc294864.aspx

BIBLIOGRAFIA E SITOGRAFIA 102

[20] The MathWorks, MATLAB R© 7 Getting Started Guide,

11◦edizione, 2008

[21] The MathWorks, MATLAB R© 7 Classes and Object-

Oriented Programming, 2008

[22] Adobe, Programming ActionScript 3.0, 2008

[23] Dagnino Catterina, Lamberti Paola, Elementi di Ma-

tematica Numerica per la Grafica, Levrotto&Bella,

2008

[24] Lifaros , David Hirmes, JD Hooge, Ken Jokol, Pavel Ka-

luzhny, Ty Lettau, Jamie McDonald, Gabriel Mulzer, Kip

Parker, Keith Peters, Paul Prudence, Glen Rhodes, Man-

ny Tan, Jared Tarbell, Brandon Williams, Flash Math

Creativity, second edition, Friends Of Ed, 2004

Università degli Studi di Torino Facoltà di Scienze M.F.N...

Documents

Transcript of Università degli Studi di Torino Facoltà di Scienze M.F.N...