Analisi e sviluppo di un framework per supportare ... - Cs.unipa.it
Analisi e sviluppo di un framework per supportare ... - Cs.unipa.it
Analisi e sviluppo di un framework per supportare ... - Cs.unipa.it
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
FACOLTA’ DI SCIENZE MM.FF.NN<br />
Corso <strong>di</strong> Laurea Specialistica in Scienze dell'Informazione<br />
_______________________________________________________________________<br />
<strong>Analisi</strong> e <strong>sviluppo</strong> <strong>di</strong> <strong>un</strong> <strong>framework</strong> <strong>per</strong> <strong>supportare</strong><br />
modelli <strong>di</strong> programmazione visuale e iconica<br />
Tesi <strong>di</strong> Laurea Specialistica <strong>di</strong><br />
Dott. Guido Averna<br />
Matricola: 0528662<br />
ANNO ACCADEMICO 2011 - 2012<br />
1<br />
Relatore<br />
Ch. Prof. Domenico Tegolo
Ringraziamenti<br />
Questo lavoro è frutto dei suggerimenti e dei tanti sp<strong>un</strong>ti <strong>di</strong> riflessione ricevuti nel corso degli stu<strong>di</strong>.<br />
Un ringraziamento sent<strong>it</strong>o va al Professore Domenico Tegolo, fonte <strong>di</strong> ispirazione e preziosa guida<br />
l<strong>un</strong>go le linee portanti della ricerca e a coloro che mi hanno sostenuto l<strong>un</strong>go il <strong>per</strong>corso, e a tutti i<br />
Professori del Corso <strong>di</strong> Laurea Specialistica,che mi hanno <strong>per</strong>messo <strong>di</strong> vivere questa splen<strong>di</strong>da<br />
es<strong>per</strong>ienza.<br />
2
C'è <strong>un</strong>a forza motrice più forte del vapore,<br />
dell'elettric<strong>it</strong>à e dell'energia atomica: la volontà.<br />
3<br />
Albert Einstein
Introduzione<br />
In<strong>di</strong>ce<br />
Cap<strong>it</strong>olo I Linguaggi <strong>di</strong> programmazione visuale:<br />
stato dell’arte pag. 8<br />
1.1 Ragioni del linguaggio visuale pag. 9<br />
1.2 Scopo della ricerca dei linguaggi <strong>di</strong> programmazione iconica pag. 11<br />
1.3 Aspetti cogn<strong>it</strong>ivi pag. 12<br />
1.3.1 Manipolazione <strong>di</strong>retta pag. 13<br />
1.3.2 Visualizzazione delle informazioni pag. 13<br />
1.3.3 Visualizzazione del software pag. 14<br />
1.3.4 Rappresentazione e ragionamento <strong>di</strong>agrammatico pag. 14<br />
1.4 Problemi nella rappresentazione iconica pag. 15<br />
1.4.1 Icone e simboli pag. 16<br />
1.4.2 Semantica e sintassi pag. 17<br />
1.4.3 Caratteristiche complesse pag. 17<br />
1.4.3.1 Concretezza pag. 18<br />
1.4.3.2 Imme<strong>di</strong>atezza pag. 18<br />
1.4.3.3 Chiarezza pag. 19<br />
1.4.3.4 Imme<strong>di</strong>ato feedback visuale pag. 19<br />
1.5 Esempi <strong>di</strong> software <strong>di</strong> programmazione visuale pag. 19<br />
1.5.1 Labview pag. 20<br />
1.5.2 UML pag. 23<br />
Cap<strong>it</strong>olo II Principali costru<strong>it</strong>ti, tipi, array e<br />
strutture dati pag. 28<br />
4
2.1 Definizione <strong>di</strong> costrutto pag. 28<br />
2.2 Costrutti principali pag. 29<br />
2.2.1 Dichiarazione <strong>di</strong> Costanti pag. 30<br />
2.2.2 Dichiarazione <strong>di</strong> Variabili pag. 31<br />
2.2.3 Assegnazione pag. 32<br />
2.2.4 Con<strong>di</strong>zione pag. 33<br />
2.2.5 Sequenze pag. 36<br />
2.2.6 Cicli pag. 37<br />
2.2.6.1 Ciclo For pag. 37<br />
2.2.6.2 Ciclo While pag. 38<br />
2.2.6.3 Ciclo Repeat .. Until e Do .. While pag. 39<br />
2.2.6.4 Considerazioni sui cicli pag. 40<br />
2.2.7 If .. Then .. Else pag. 41<br />
2.2.8 Break, Continue e Return pag. 42<br />
2.2.8.1 Break pag. 43<br />
2.2.8.2 Continue pag. 43<br />
2.2.8.3 Return pag. 43<br />
2.2.9 Sw<strong>it</strong>ch .. Case pag. 44<br />
2.2.10 Procedure e F<strong>un</strong>zioni pag. 47<br />
2.2.10.1 Procedura pag. 48<br />
2.2.10.2 F<strong>un</strong>zione pag. 50<br />
2.3 Tipi pag. 52<br />
2.3.1 Tipi prim<strong>it</strong>ivi pag. 53<br />
2.3.2 Tipi <strong>di</strong> enumerazioni pag. 54<br />
2.3.3 Array pag. 57<br />
2.3.4 Strutture pag. 58<br />
2.4 <strong>Analisi</strong> finale pag. 59<br />
5
Cap<strong>it</strong>olo III Sviluppo <strong>di</strong> <strong>un</strong> linguaggio <strong>di</strong><br />
programmazione iconico pag. 60<br />
3.1 Sviluppo del Framework pag. 60<br />
3.2 Sviluppo del linguaggio iconico dal p<strong>un</strong>to <strong>di</strong> vista concettuale pag. 62<br />
3.2.1 Implementazione concettuale del flusso pag. 62<br />
3.2.2 Rappresentazione visiva dei costrutti principali pag. 65<br />
3.2.2.1 Colore del contorno pag. 65<br />
3.2.2.2 Colore del riempimento pag. 67<br />
3.2.2.3 Forme delle icone pag. 67<br />
3.2.2.4 Testo delle icone pag. 70<br />
3.3 Esplic<strong>it</strong>azione del co<strong>di</strong>ce sorgente me<strong>di</strong>ante l’uso delle icone pag. 71<br />
3.4 Integratore iconico con <strong>un</strong> Parser XML pag. 72<br />
3.5 In<strong>di</strong>cizzatore <strong>di</strong> librerie generiche pag. 73<br />
3.5.1 Regular Expression pag. 73<br />
3.6 <strong>Analisi</strong> finale pag. 78<br />
Cap<strong>it</strong>olo IV Implementazione del linguaggio <strong>di</strong><br />
programmazione iconico pag. 80<br />
4.1 Sviluppo del Linguaggio pag. 80<br />
4.1.1 Cenni sull’ere<strong>di</strong>tarietà e sul polimorfismo pag. 81<br />
4.1.2 Cenni <strong>di</strong> caratteristiche avanzate del linguaggio Delphi pag. 82<br />
4.1.3 Gli Eventi pag. 83<br />
4.1.4 Sovrascr<strong>it</strong>tura delle f<strong>un</strong>zioni e procedure ere<strong>di</strong>tate pag. 84<br />
4.1.5 Visibil<strong>it</strong>à <strong>di</strong> proprietà e meto<strong>di</strong> e semplici tecniche <strong>di</strong> Hacking pag. 86<br />
4.2 Implementazione del Framework Iconico pag. 89<br />
4.2.1 Classe TForme pag. 89<br />
4.2.2 Classe TFigura_Start pag. 99<br />
4.2.3 Classe TFigura_Dato pag.100<br />
6
4.2.3.1 Classe TTipo_Dato pag.102<br />
4.2.3.2 Classe TDato_Matrice pag.104<br />
4.2.4 Classe TFigura_Ciclo pag.106<br />
4.2.4.1 Classe TCon<strong>di</strong>zione pag.108<br />
4.2.5 Classe TFigura_If_Then_Else pag.109<br />
4.2.6 Classe TFigura_Blocco pag.110<br />
4.2.7 Classe TFigura_Break_Continue_Ex<strong>it</strong> pag.111<br />
4.2.8 Classe TFigura_Sw<strong>it</strong>ch pag.112<br />
4.2.9 Classe TFigura_Assegnazione pag.113<br />
4.2.10 Classe TFigura_F<strong>un</strong>zione pag.115<br />
4.2.11 Classi TFigura_Label, TFigura_Goto, TFigura_Return,<br />
TFigura_Begin, TFigura_End pag.116<br />
4.3 Implementazione del flusso grafico: classe TLinker pag.116<br />
4.4 Integrazione del parser XML pag.119<br />
4.4.1 Classe TXML_Progetto pag.119<br />
4.4.2 Classe TXML_File pag.121<br />
4.4.3 Classe TXML_F<strong>un</strong>zione pag.123<br />
4.5 Implementazione sintetica dell’in<strong>di</strong>cizzatore <strong>di</strong> librerie pag.124<br />
4.5.1 Classe TC_Sorgente pag.125<br />
4.5.2 Classe TC_Meto<strong>di</strong> pag.126<br />
4.6 Implementazione del Text E<strong>di</strong>tor pag.128<br />
4.7 Implementazione delle caratteristiche del <strong>framework</strong> pag.131<br />
Conclusioni pag.134<br />
Bibliografia pag.135<br />
7
Introduzione<br />
Dallo scorso secolo, si è palesato <strong>un</strong> crescente interesse riguardo<br />
all’interazione Uomo-Macchina. Questo ha portato a <strong>un</strong>a maggiore attenzione<br />
circa la possibil<strong>it</strong>à <strong>di</strong> programmare le macchine e sviluppare nuovi software<br />
attraverso <strong>un</strong> linguaggio iconico, ci si è quin<strong>di</strong> domandati quale potesse essere<br />
<strong>un</strong>a rappresentazione iconico in grado <strong>di</strong> sfruttare i p<strong>un</strong>ti <strong>di</strong> forza delle immagini<br />
al fine <strong>di</strong> sviluppare algor<strong>it</strong>mi e programmi.<br />
In questo lavoro si analizzeranno, d<strong>un</strong>que, gli aspetti chiave, utili a<br />
comprendere quali icone possano meglio essere comprensibili, fornendo<br />
<strong>un</strong>’imme<strong>di</strong>ata associazione tra loro e con i principali costrutti e dati del<br />
linguaggio <strong>di</strong> programmazione C.<br />
Si analizzerà la <strong>di</strong>chiarazione <strong>di</strong> tali strutture ponendo le basi <strong>per</strong><br />
implementare <strong>un</strong> <strong>framework</strong> iconico. Verrà poi sviluppato concettualmente il<br />
<strong>framework</strong> stesso, soffermandosi sui vari aspetti, e sulle caratteristiche grafiche<br />
che le icone dovrebbero possedere affinché mostrino <strong>un</strong> chiaro linguaggio, che<br />
possa essere utilizzato dai professionisti ma al contempo anche dai principianti.<br />
Me<strong>di</strong>ante l’uso del linguaggio Delphi si svilup<strong>per</strong>anno, infine, le classi e gli<br />
oggetti che rendono <strong>di</strong>sponibile tale linguaggio, soffermandosi sui dettagli<br />
implementativi e spiegando come tali classi interagiscano tra loro. Si gi<strong>un</strong>gerà<br />
alla conclusione analizzando l’o<strong>per</strong>ato del processo, e la molteplic<strong>it</strong>à dei suoi<br />
possibili utilizzi pratici.<br />
8
Cap<strong>it</strong>olo I<br />
LINGUAGGI DI PROGRAMMAZIONE<br />
VISUALE: STATO DELL’ARTE<br />
1.1 Ragioni del linguaggio visuale<br />
Il linguaggio, in generale, può essere defin<strong>it</strong>o come <strong>un</strong>a formalizzazione <strong>di</strong><br />
schemi concettuali e <strong>di</strong> pensieri che l’essere umano riesce ad elaborare. Questi<br />
schemi o pensieri vengono riconosciuti ed interpretati dal cervello, e converti in<br />
rappresentazioni visuali. Molte volte queste rappresentazioni sono talmente<br />
ra<strong>di</strong>cate nella mente da associarsi irrime<strong>di</strong>abilmente ad immagini (Arnheim,<br />
1969) e ad essere associati a linguaggi visuali od iconici. La facil<strong>it</strong>à <strong>di</strong><br />
comprendere le rappresentazioni iconiche è <strong>un</strong> fattore significativo nell’area dei<br />
linguaggi visuali (Blackwell, 1996). Tuttavia, vi è <strong>un</strong>a notevole <strong>di</strong>fficoltà a<br />
formalizzare i linguaggi visuali a causa <strong>di</strong> svariate variabili in gioco. La<br />
progettazione e l'analisi <strong>di</strong> linguaggi <strong>di</strong> programmazione sono sempre stati<br />
guidati da questioni <strong>di</strong> elastic<strong>it</strong>à e <strong>di</strong> efficienza, non dall'usabil<strong>it</strong>à o la<br />
comprensibil<strong>it</strong>à. Inoltre, le proprietà cogn<strong>it</strong>ive <strong>di</strong> <strong>un</strong>a linguaggio sono in genere<br />
verificate solo dopo la loro progettazione e il loro uso. Il ruolo centrale dei<br />
9
linguaggi visivi consiste nell’affermare il proprio ruolo come strumento <strong>per</strong> la<br />
com<strong>un</strong>icazione e l'interazione, fornendo inoltre <strong>un</strong>’interfaccia Uomo –<br />
Macchina. Ciò implica che la teoria dei linguaggi visivi richiede <strong>un</strong>a conoscenza<br />
più ampia rispetto alla teoria dei linguaggi <strong>di</strong> programmazione e in generale alla<br />
teoria dei linguaggi. Il motivo principale dell’uso dei linguaggi iconici è dovuta<br />
all’interazione del linguaggio visivo Uomo – Macchina comprendendo <strong>un</strong>a vasta<br />
classe <strong>di</strong> approcci che sono stati oggetto <strong>di</strong> ricerca della com<strong>un</strong><strong>it</strong>à scientifica.<br />
Tali linguaggi facil<strong>it</strong>ano la costruzione <strong>di</strong> immagini mentali e inoltre <strong>per</strong>mettono<br />
<strong>un</strong>a più facile ed imme<strong>di</strong>ata formalizzazione cogn<strong>it</strong>iva. La visualizzazione<br />
conduce, inev<strong>it</strong>abilmente, a <strong>di</strong>versificare l’uso grafico dei simboli e dei<br />
linguaggi in <strong>di</strong>versi campi:<br />
I linguaggi visivi: sono tutti quei linguaggi dati dalla rappresentazione<br />
visuale a<strong>di</strong>b<strong>it</strong>i alla interfaccia Uomo – Uomo o Uomo – Macchina. In questi<br />
linguaggi rientrano i linguaggi naturali e iconici.<br />
La programmazione testuale: usata <strong>per</strong> com<strong>un</strong>icare dati, istruzioni ed<br />
o<strong>per</strong>azioni al computer. In questo gruppo <strong>di</strong> linguaggi rientrano i ben noti e<br />
consolidati linguaggi C e Pascal e le rispettive estensioni.<br />
I linguaggi <strong>di</strong> programmazione iconica: nei quali le immagini, o icone,<br />
rappresentano visivamente le ent<strong>it</strong>à, l’alfabeto o i simboli del linguaggio, e ad<br />
ogn<strong>un</strong>o <strong>di</strong> essi viene associato <strong>un</strong> particolare significato o <strong>un</strong>a ben determinata<br />
azione. In questa famiglia <strong>di</strong> linguaggi ricadono Labview e l’UML, Unified<br />
Modeling Language. Tali linguaggi sono anche conosciuti come VPL, Visual<br />
Programming Language.<br />
Software <strong>di</strong> visualizzazione: i quali servono a raffigurare visivamente<br />
rappresentazioni atte a trasmettere all’uomo <strong>un</strong>’insieme <strong>di</strong> proprietà statiche o<br />
10
<strong>di</strong>namiche <strong>di</strong> software, inclusi co<strong>di</strong>ci, dati e algor<strong>it</strong>mi. Esempi <strong>di</strong> questi software<br />
sono ambienti <strong>di</strong> <strong>sviluppo</strong> software o IDE, Integrated Development<br />
Environment.<br />
Algor<strong>it</strong>mo <strong>di</strong> animazione: i quali altro non sono che immagini <strong>di</strong>namiche<br />
e visive che riproducono il f<strong>un</strong>zionamento degl’algor<strong>it</strong>mi sui vari dati.<br />
Rappresentazioni <strong>di</strong>agrammatiche: raffigurazioni che forniscono<br />
informazioni descr<strong>it</strong>tive senza rappresentare <strong>un</strong>a vera e propria ent<strong>it</strong>à. Un<br />
esempio è la ben nota rappresentazione concettuale tram<strong>it</strong>e i Diagrammi a<br />
blocchi, <strong>un</strong>iversalmente conosciuta ed ampiamente usata.<br />
Nel prosieguo si riferirà ai linguaggi visuali come ai linguaggi <strong>di</strong><br />
programmazione visuale.<br />
1.2 Scopo della ricerca dei linguaggi <strong>di</strong> programmazione iconica<br />
La ricerca della teoria dei linguaggi visuali tenta <strong>di</strong> liberare i programmatori e<br />
gli utenti finali dai vincoli della programmazione testuale e simbolica, fornendo<br />
<strong>un</strong> insieme <strong>di</strong> strumenti iconici utili, intu<strong>it</strong>ivi e facilmente utilizzabili. Durante<br />
gli anni, si sono sviluppati svariati e <strong>di</strong>versi linguaggi iconici, ogn<strong>un</strong>o seguendo<br />
<strong>un</strong>a propria e <strong>di</strong>fferente filosofia atta a formalizzare <strong>un</strong> appropriato campo <strong>di</strong><br />
stu<strong>di</strong>o. Ad esempio i fisici, al fine <strong>di</strong> ottenere <strong>un</strong>a facile comprensione del<br />
fenomeno descr<strong>it</strong>to, usano i Diagrammi <strong>di</strong> Feynman, che <strong>per</strong>mettono <strong>di</strong> tradurre<br />
<strong>un</strong>a interazione in <strong>un</strong> semplice schema; i matematici usano i Diagrammi<br />
Commutativi, ovvero dei <strong>di</strong>agrammi che comprendono svariate ent<strong>it</strong>à e<br />
11
morfismi tra <strong>di</strong> loro tali che <strong>per</strong> ogni coppia <strong>di</strong> oggetti ogni <strong>per</strong>corso che li<br />
collega produce la stessa applicazione finale; gli informatici usano <strong>di</strong>agrammi<br />
iconici rappresentanti strutture dati tra loro collegate attraverso delle frecce, <strong>per</strong><br />
in<strong>di</strong>care le relazioni che intercorrono tra le varie strutture ed ent<strong>it</strong>à.<br />
1.3 Aspetti cogn<strong>it</strong>ivi<br />
I linguaggi visuali offrono <strong>un</strong> approccio completamente <strong>di</strong>fferente alla classica<br />
programmazione. Ciò porta a concepire <strong>un</strong> nuovo modo <strong>di</strong> programmare, e a<br />
nuovi aspetti cogn<strong>it</strong>ivi che derivano da questo approccio. In base al tipo <strong>di</strong><br />
approccio iconico utilizzato <strong>per</strong> la programmazione o la progettazione dei vari<br />
algor<strong>it</strong>mi, l’utente finale sfrutta <strong>un</strong> modo <strong>di</strong> pensare che non segue<br />
necessariamente l’impostazione classica. Gli approcci possono essere <strong>di</strong> tipo:<br />
Manipolazione <strong>di</strong>retta<br />
Visualizzazione delle informazioni <strong>di</strong>fferente<br />
Visualizzazione delle software <strong>di</strong>fferente<br />
Rappresentazione e ragionamento <strong>di</strong>agrammatico<br />
Simulazioni grafiche<br />
12
1.3.1 Manipolazione <strong>di</strong>retta<br />
Questo genere <strong>di</strong> approccio fornisce agli utenti degli strumenti atti ad eseguire<br />
delle azioni <strong>di</strong>rettamente sulle strutture dati, interagendo in maniera visuale con<br />
gli oggetti. Un esempio classico è lo spostamento <strong>di</strong> <strong>un</strong> file da <strong>un</strong>a cartella ad<br />
<strong>un</strong>’altra trascinando il file. Con tale approccio si creano e si innescano schemi<br />
cogn<strong>it</strong>ivi atti a fornire <strong>un</strong>a rappresentazione dell’azione <strong>di</strong>retta su <strong>un</strong>a struttura<br />
dati, fornendo benefici <strong>di</strong> imme<strong>di</strong>atezza delle esecuzioni delle istruzioni ed<br />
<strong>un</strong>’associazione tra immagine-azione.<br />
1.3.2 Visualizzazione delle informazioni<br />
Per l’uomo, la rappresentazione visuale <strong>di</strong> <strong>un</strong>a struttura dati è maggiormente<br />
comprensibile rispetto alla tipizzazione testuale classica <strong>di</strong> <strong>un</strong>a struttura dati. Gli<br />
oggetti iconici descrivono i dati in <strong>un</strong> modo maggiormente comprensibile e<br />
familiare all’uomo, sebbene la descrizione testuale sia tecnicamente equivalente.<br />
Tale metodologia, <strong>per</strong>mette <strong>di</strong> sottolineare e rendere maggiormente visibile<br />
quelle rappresentazioni dei dati che sono nascoste, fornendo <strong>un</strong>a chiara ed<br />
imme<strong>di</strong>ata rappresentazione del concetto o azione da esprimere. Ad esempio, si<br />
consideri il linguaggio HTML. L’Hy<strong>per</strong> Text Markup Language, seppur <strong>un</strong><br />
linguaggio <strong>di</strong> formattazione, se usato in concom<strong>it</strong>anza con <strong>un</strong> qual<strong>un</strong>que<br />
browser fornisce <strong>un</strong>’interazione con l’utente veramente notevole. Ad esempio,<br />
l’uso del suo oggetto, o tag, “IMG”, in versione testuale fornisce<br />
13
<strong>un</strong>’informazione scarsamente comprensibile all’utente, ma tradotto in maniera<br />
visuale, dal browser, fornisce come oggetto <strong>un</strong>’immagine, la quale offre<br />
<strong>un</strong>’informazione maggiore, se non, ad<strong>di</strong>r<strong>it</strong>tura, completamente <strong>di</strong>fferente.<br />
1.3.3 Visualizzazione del software<br />
La visualizzazione del software risulta essere maggiormente comprensibile, in<br />
quanto le strutture dati e il flusso del programma appaiono defin<strong>it</strong>e attraverso<br />
grafi e <strong>di</strong>agrammi <strong>di</strong> flusso, i quali forniscono imme<strong>di</strong>atamente ed<br />
intu<strong>it</strong>ivamente il comportamento del programma e delle sue strutture. Tale<br />
metodo, è l’inverso dell’analisi <strong>di</strong> <strong>un</strong> linguaggio <strong>di</strong> programmazione visuale.<br />
Così si genera <strong>un</strong>a rappresentazione che fornisce visivamente le stesse<br />
informazioni circa la sintassi e la semantica utilizzate, ma in <strong>un</strong> modo più<br />
comprensibile all’occhio umano tale da rende l’imme<strong>di</strong>atezza della sua struttura<br />
logica.<br />
1.3.4 Rappresentazione e ragionamento <strong>di</strong>agrammatico<br />
In molti casi, nella programmazione testuale, è richiesta <strong>un</strong>a maggiore analisi<br />
del programma quando bisogna definire le relazioni e le proprietà delle strutture<br />
dati. Talvolta, queste relazioni sono talmente implic<strong>it</strong>e da richiedere<br />
estremamente dettagliata la quale richiede tempi tecnici eccessivamente onerosi<br />
14
<strong>per</strong> l’utente. Nella rappresentazione <strong>di</strong>agrammatica, le relazioni e le proprietà<br />
vengono esplic<strong>it</strong>ate (Larkin, Simon, 1987). Le rappresentazioni visuali<br />
forniscono <strong>un</strong> più intu<strong>it</strong>ivo ragionamento, acuendo la conoscenza <strong>di</strong> base<br />
(Narayanan, Suwa, Motoda, 1994). Questo rende più facile la comprensione<br />
delle implicazioni logiche tra le varie icone (Larkin, 1989). Inoltre, questo<br />
migliora la comprensione circa la possibile mo<strong>di</strong>fica <strong>di</strong> queste proprietà e dei<br />
loro effetti sugli oggetti fisici (Narayanan, Suwa, Motoda, 1995), ovvero delle<br />
istanze delle ent<strong>it</strong>à. In questa maniera, è più facile immaginare l’effetto delle<br />
mo<strong>di</strong>fiche sul sistema simulando preventivamente il loro comportamento<br />
grafico.<br />
1.4 Problemi nella rappresentazione iconica<br />
La <strong>di</strong>fferenza tra icone e simboli è <strong>di</strong> importanza fondamentale nello <strong>sviluppo</strong><br />
<strong>di</strong> <strong>un</strong> linguaggio visivo, in quanto <strong>per</strong>sone <strong>di</strong> <strong>di</strong>fferenti nazional<strong>it</strong>à che parlano<br />
<strong>di</strong>verse lingue hanno necess<strong>it</strong>à <strong>di</strong> sfruttare <strong>un</strong>o strumento che possa essere<br />
compreso <strong>un</strong>iversalmente. Inoltre, ulteriori problemi sono sia lo stile dal p<strong>un</strong>to<br />
<strong>di</strong> vista grafico che i meccanismi <strong>di</strong> composizione tra gli oggetti.<br />
15
1.4.1 Icone e simboli<br />
Charles Peirce caratterizzò, nel 1955, la <strong>di</strong>fferenza sostanziale che intercorre<br />
tra le icone e i simboli: “Un’icona è <strong>un</strong> segno che si riferisce ad <strong>un</strong> oggetto il<br />
quale denota meramente la virtù dei propri caratteri” e “Un simbolo è <strong>un</strong> segno<br />
che si riferisce ad <strong>un</strong> oggetto il quale denota la virtù <strong>di</strong> <strong>un</strong> processo, usualmente<br />
<strong>un</strong>’associazione <strong>di</strong> idee generali” (Peirce in Buchler, 1955). In altre parole, il<br />
significato cogn<strong>it</strong>ivo <strong>di</strong> <strong>un</strong>’icona e in<strong>di</strong>pendente dalla <strong>per</strong>sona che la vuole<br />
interpretare. Questa in<strong>di</strong>pendenza è la caratteristica che rende il linguaggio<br />
visuale <strong>un</strong>iversalmente utilizzato. Ma vi sono varie <strong>di</strong>fficoltà e lim<strong>it</strong>azioni <strong>per</strong><br />
relazionare rappresentazioni iconiche a significati complessi. Gli psicologi<br />
trovarono <strong>di</strong>verse <strong>di</strong>pendenze culturali anche a livello <strong>per</strong>cettivo. Le <strong>per</strong>sone<br />
hanno <strong>un</strong>a <strong>di</strong>fferente <strong>per</strong>cezione dei simboli e in alc<strong>un</strong>i contesti non riconoscono<br />
gli oggetti allo stesso modo. La <strong>per</strong>cezione <strong>di</strong>pende dal contesto oltre che<br />
dall’immagine, e il ruolo che possiede <strong>un</strong> particolare segno, icona o simbolo,<br />
<strong>di</strong>pende dalla sua relazione con interpretazione ed è affine alla sua caratteristica<br />
intrinseca (ad esempio <strong>un</strong> colore o <strong>un</strong>a forma). Inoltre è associata alla relazione<br />
del mondo reale con l’oggetto, ed <strong>un</strong>’associazione artificiale, come può essere<br />
<strong>un</strong>a convenzione linguistica. Molto spesso è plausibile creare <strong>un</strong>a successione<br />
sempre più stilizzata dei segni, cominciando con <strong>un</strong>’immagine realistica e<br />
finendo con <strong>un</strong> simbolo astratto, che <strong>per</strong>mette <strong>di</strong> comprendere <strong>un</strong>’associazione<br />
simbolica astratta. Inoltre, in alc<strong>un</strong>i casi <strong>un</strong>a rappresentazione iconica può essere<br />
presa come <strong>un</strong>’estrema rappresentazione teorica, e i concetti astratti possono<br />
essere com<strong>un</strong>icati me<strong>di</strong>ante l’uso <strong>di</strong> poche icone. Ad esempio i vari linguaggi<br />
usati dagl’uomini si sono evoluti continuamente: <strong>un</strong>o <strong>di</strong> questi è il linguaggio<br />
16
cinese che si è evoluto da <strong>un</strong>a rappresentazione figurativa esplic<strong>it</strong>a ad <strong>un</strong>a<br />
raffigurazione altamente stilizzata, così anche le icone possono cambiare forma<br />
da immagini dettagliate a simboli astratti sui computer, ma con tempistiche<br />
estremamente più veloci.<br />
1.4.2 Semantica e sintassi<br />
Un secondo problema è lo <strong>sviluppo</strong> <strong>di</strong> <strong>un</strong>a semantica e <strong>di</strong> <strong>un</strong>a sintassi dei<br />
linguaggi visivi che siano idonee ed adeguate, oltre alla manipolazione <strong>di</strong>retta<br />
degli oggetti. Questo non è <strong>un</strong> modo <strong>di</strong> programmare dei linguaggi tra<strong>di</strong>zionali,<br />
e a secondo del <strong>framework</strong> implementato, può essere più o meno ostico e poco<br />
intu<strong>it</strong>ivo realizzare caratteristiche del linguaggio iconico atte a <strong>supportare</strong> tali<br />
f<strong>un</strong>zional<strong>it</strong>à. La ricerca, che p<strong>un</strong>ta a <strong>supportare</strong> i meccanismi implementativi<br />
necessari <strong>per</strong> lo <strong>sviluppo</strong> <strong>di</strong> tali caratteristiche dei linguaggi non tra<strong>di</strong>zionali, è<br />
ancora, <strong>per</strong>ò, poco praticata e <strong>di</strong>ffusa.<br />
1.4.3 Caratteristiche complesse<br />
Un linguaggio visuale deve avere caratteristiche complesse da sviluppare,<br />
quali la concretezza, l’imme<strong>di</strong>atezza, la chiarezza, e <strong>un</strong> imme<strong>di</strong>ato feedback<br />
visuale. Tali caratteristiche devono essere implementate <strong>per</strong> sviluppare <strong>un</strong><br />
linguaggio visuale.<br />
17
1.4.3.1 Concretezza<br />
La concretezza esprime specifici aspetti del programma, usando istanze<br />
prestabil<strong>it</strong>e, al fine <strong>di</strong> esplic<strong>it</strong>are i tratti semantici che delineano il<br />
comportamento che si intende produrre. E' <strong>un</strong> processo che avviene tram<strong>it</strong>e<br />
l'utilizzo <strong>di</strong> determinati oggetti o valori scelti <strong>per</strong> l'imme<strong>di</strong>ata corrispondenza<br />
ideologica.<br />
1.4.3.2 Imme<strong>di</strong>atezza<br />
In termini implementativi, questa caratteristica può essere descr<strong>it</strong>ta come <strong>un</strong>a,<br />
breve, <strong>di</strong>stanza che intercorre <strong>un</strong>o scopo e l’azione proposta <strong>per</strong> ottenere lo<br />
scopo, ma questa è <strong>di</strong>rettamente collegata alla manipolazione <strong>di</strong>retta degli<br />
oggetti. Come p<strong>un</strong>tualizzano Green e Petre, la programmazione richiede <strong>un</strong>a<br />
mappatura tra <strong>un</strong> problema reale e problema computazionale, più vicino è il<br />
problema computazionale al problema reale, più facilmente lo si potrà risolvere.<br />
Un esempio è il manipolare <strong>un</strong> oggetto <strong>per</strong> specificare il suo cambiamento <strong>di</strong><br />
posizione, ovvero usare il movimento <strong>per</strong> specificare il movimento, invece <strong>di</strong><br />
usare <strong>un</strong>a f<strong>un</strong>zione sulle coor<strong>di</strong>nate dello schermo <strong>per</strong> specificarlo da esempio.<br />
18
1.4.3.3 Chiarezza<br />
Alc<strong>un</strong>i aspetti della semantica sono esplic<strong>it</strong>ati solo se sono <strong>di</strong>rettamente<br />
affermati, sia testualmente che visivamente, senza <strong>un</strong>a richiesta dello<br />
sviluppatore. Un esempio è la capac<strong>it</strong>à <strong>di</strong> <strong>un</strong> linguaggio visuale <strong>di</strong> fornire<br />
visivamente le relazioni del flusso dei dati me<strong>di</strong>ante l’uso <strong>di</strong> archi tra gli oggetti<br />
del programma. In <strong>un</strong> linguaggio testuale, questo è solo <strong>un</strong>o strumento esterno<br />
all’ide che può essere utilizzato, mentre in <strong>un</strong> linguaggio visuale può essere<br />
parte della sintassi o <strong>un</strong>a caratteristica automatica dell’ambiente <strong>di</strong> <strong>sviluppo</strong>.<br />
1.4.3.4 Imme<strong>di</strong>ato feedback visuale<br />
Questa si riferisce alla visualizzazione automatica degli effetti dei programmi<br />
<strong>di</strong> linguaggi testuali. Tanimoto creò il termine v<strong>it</strong>al<strong>it</strong>à, che cataloga<br />
l’imme<strong>di</strong>atezza del feedback semantico che è automaticamente forn<strong>it</strong>o durante il<br />
processo <strong>di</strong> e<strong>di</strong>ting <strong>di</strong> <strong>un</strong> programma. Un esempio è la caratteristica <strong>di</strong> ricalcolo<br />
automatico <strong>di</strong> <strong>un</strong> foglio <strong>di</strong> calcolo.<br />
1.5 Esempi <strong>di</strong> software <strong>di</strong> programmazione visuale<br />
Negli anni sono stati implementati svariati linguaggi visuali, sia software che<br />
standard <strong>di</strong> linguaggi visuali. Di segu<strong>it</strong>o vengono forn<strong>it</strong>i due casi, <strong>un</strong>o <strong>di</strong> <strong>un</strong><br />
19
software <strong>di</strong> fama internazionale e l’altro <strong>di</strong> <strong>un</strong> linguaggio <strong>di</strong>venuto <strong>un</strong>o standard<br />
<strong>per</strong> molti casi.<br />
1.5.1 Labview<br />
Il LabVIEW (abbreviazione <strong>di</strong> Laboratory Virtual Instrumentation<br />
Engineering Workbench) è <strong>un</strong> ambiente <strong>di</strong> <strong>sviluppo</strong> integrato <strong>per</strong> il linguaggio<br />
<strong>di</strong> programmazione iconico creato dalla National Instruments. A causa <strong>di</strong> tale<br />
particolar<strong>it</strong>à, questo linguaggio grafico viene chiamato Linguaggio G, Graphic<br />
Language. Un programma o sottoprogramma G, denominato VI (Virtual<br />
Instrument), non esiste sotto forma <strong>di</strong> testo, ma può essere salvato solo come <strong>un</strong><br />
file binario, opport<strong>un</strong>amente co<strong>di</strong>ficato, visualizzabile e compilabile solo da<br />
LabVIEW. La definizione <strong>di</strong> strutture dati ed algor<strong>it</strong>mi avviene con icone e altri<br />
oggetti grafici, ogn<strong>un</strong>o dei quali contiene e fornisce f<strong>un</strong>zioni <strong>di</strong>verse, <strong>un</strong><strong>it</strong>i da<br />
linee <strong>di</strong> collegamento (wire), in modo da formare <strong>un</strong>o schema che si avvicina<br />
molto ad <strong>un</strong> <strong>di</strong>agramma <strong>di</strong> flusso. Tale linguaggio viene defin<strong>it</strong>o dataflow<br />
(flusso <strong>di</strong> dati) in quanto la sequenza <strong>di</strong> esecuzione è defin<strong>it</strong>a e rappresentata dal<br />
flusso dei dati stessi attraverso gli archi <strong>di</strong>rezionali che collegano i blocchi<br />
f<strong>un</strong>zionali. Poiché i dati possono anche scorrere in parallelo attraverso blocchi e<br />
archi non consecutivi, il linguaggio realizza spontaneamente il mult<strong>it</strong>hrea<strong>di</strong>ng<br />
senza bisogno <strong>di</strong> esplic<strong>it</strong>a gestione da parte del programmatore. Il progetto<br />
LabVIEW nasce nel 1983 dalla necess<strong>it</strong>à della National Instruments <strong>di</strong> <strong>di</strong>sporre<br />
<strong>di</strong> <strong>un</strong> software grafico, con il quale testare rapidamente gli apparati hardware<br />
prodotti da tale industria stat<strong>un</strong><strong>it</strong>ense.<br />
20
Già nel 1986 è resa pubblica la versione 1 del software compatibile con i<br />
sistemi Macintosh. Nel gennaio del 1990 viene pubblicata la versione 2, gli<br />
aggiornamenti sul software rendono la veloc<strong>it</strong>à <strong>di</strong> esecuzione della versione 6<br />
paragonabile ai programmi compilati in Ansi C. Il mese successivo in virtù<br />
dell'innovativ<strong>it</strong>à dell'approccio grafico alla programmazione, viene pubblicato il<br />
brevetto dal US Patent Office. Infine nel settembre 1992 ne viene sviluppata <strong>un</strong>a<br />
versione multipiattaforma, cioè <strong>per</strong> Microsoft Windows, Mac OS e S<strong>un</strong>OS. In<br />
segu<strong>it</strong>o venne supportato anche Linux.<br />
La versione 8.0, pubblicata nel 2005, introduce <strong>per</strong> la prima volta anche il<br />
supporto <strong>per</strong> la programmazione a oggetti. Nell'ambiente <strong>di</strong> <strong>sviluppo</strong>, i VI<br />
(Virtual Instruments) constano <strong>di</strong> tre componenti principali:<br />
il pannello frontale<br />
lo schema a blocchi<br />
il riquadro connettori<br />
Il pannello frontale cost<strong>it</strong>uisce l’interfaccia utente, dove è possibile inserire<br />
variabili, costanti, stringhe, array, controlli ed in<strong>di</strong>catori, pulsanti, termometri ed<br />
altri oggetti f<strong>un</strong>zionali e facilmente identificabili. Questi cost<strong>it</strong>uiscono la parte<br />
visiva degli oggetti. Questi oggetti rappresentano delle vere e proprie classi<br />
visuali che, durante la storia <strong>di</strong> <strong>sviluppo</strong> del programma, forniscono all’utente<br />
molteplici caratteristiche più o meno complesse.<br />
Lo schema a blocchi rappresenta il vero e proprio lato f<strong>un</strong>zionale del<br />
linguaggio. Con esso è possibile fornire associazioni tra gli oggetti ed<br />
implementare la logica <strong>di</strong> f<strong>un</strong>zionamento del progetto o dell’applicativo che si<br />
21
intende realizzare. Per l’implementazione vengono messi ulteriori oggetti che<br />
identificano sia istruzioni della logica <strong>di</strong> implementazione classica, sia f<strong>un</strong>zioni<br />
e procedure già implementate, che in molti casi fanno si che si possa abbattere il<br />
tempo <strong>di</strong> <strong>sviluppo</strong> del programma oltre a fornire <strong>un</strong> valido aiuto <strong>per</strong><br />
implementare f<strong>un</strong>zioni più o meno complesse.<br />
Oltre ad essere <strong>un</strong> ambiente integrato, Labview è anche <strong>un</strong> compilatore a 32 e<br />
64 b<strong>it</strong>. Si possono d<strong>un</strong>que creare eseguibili e DLL, Dynamic Link Library. Per<br />
usare tali eseguibili e DLL non occorre <strong>un</strong>'installazione <strong>di</strong> LabVIEW, ma è<br />
necessario che sul computer <strong>di</strong> destinazione sia installato almeno il r<strong>un</strong>-time<br />
engine <strong>di</strong> LabVIEW.<br />
22
1.5.2 UML<br />
Fig. 1.1 Esempio <strong>di</strong> pannello frontale e schema a blocchi in LabView<br />
L’UML, ovvero l’Unified Modelling Language, è <strong>un</strong> linguaggio grafico basato<br />
sul concetto dei <strong>di</strong>agrammi a flussi. Si tratta <strong>di</strong> <strong>un</strong> linguaggio <strong>di</strong> modellazione<br />
usato <strong>per</strong> capire e descrivere le caratteristiche <strong>di</strong> <strong>un</strong> nuovo sistema o <strong>di</strong> <strong>un</strong>o<br />
23
esistente e quin<strong>di</strong> atto alla rappresentazione degli shcemi. Il p<strong>un</strong>to <strong>di</strong> forza<br />
dell’Unified Modeling Language consiste nel fatto che il processo <strong>di</strong> <strong>di</strong>segno del<br />
sistema può essere effettuato in modo tale che i clienti, gli analisti, i<br />
programmatori e chi<strong>un</strong>que altro sia coinvolto nel sistema <strong>di</strong> <strong>sviluppo</strong> possa<br />
capire ed esaminare in modo efficiente il sistema e prendere parte alla sua<br />
costruzione in modo attivo. L’UML nasce in segu<strong>it</strong>o all’evoluzione dei<br />
linguaggi e approcci alla modelazione object oriented. In quel <strong>per</strong>iodo, furono<br />
implementati svariati modelli e si sviluppò <strong>un</strong>a vera e propria "guerra dei<br />
meto<strong>di</strong>" tra progettisti, sviluppatori e organizzazioni che tentarono <strong>di</strong> imporre il<br />
proprio modello <strong>di</strong> <strong>sviluppo</strong>, in quanto non era stato accettato alc<strong>un</strong> modello<br />
quale standard <strong>un</strong>iversale <strong>per</strong> la modellazione dei software. Nel 1994 due es<strong>per</strong>ti<br />
<strong>di</strong> modellazione della Rational Software Corporation, Grady Booch e James<br />
Rumbaugh,<strong>un</strong>ificarono i propri meto<strong>di</strong>, Booch e OMT (Object Management<br />
Technique), , entrambi ricercatori presso Rational Software. Nel 1995, il gruppo<br />
si allargò includendo anche Ivar Jacobson con il suo OOSE (Object Oriented<br />
Software Engineering), in segu<strong>it</strong>o alla ven<strong>di</strong>ta della sua compagnia Objectory<br />
alla Rational. l'OMG raccolse tutti i principali metodologisti del settore in <strong>un</strong><br />
incontro internazionale <strong>per</strong> <strong>di</strong>scutere della notazione <strong>un</strong>ificata.. Nel 1996,<br />
Booch, Rumbaugh e Jacobson furono incaricati da Rational <strong>di</strong> <strong>di</strong>rigere la<br />
creazione dell’Unified Modeling Language.In quest’anno i tre sviluppatori<br />
rilasciarono le versioni 0.9 e successivamente 0.91 dell’UML, quest’ultima fu<br />
ben accolta dalla com<strong>un</strong><strong>it</strong>à internazionale e dall’OMG (Object Management<br />
Group), e al progetto e gran<strong>di</strong> organizzazioni si <strong>un</strong>irono a Rational <strong>per</strong><br />
proseguirlo, ad esempio Dig<strong>it</strong>al, Hewlett-Packard, IBM, Microsoft, Oracle e<br />
24
Unisys.. Nel 1997, a segu<strong>it</strong>o della formazione <strong>di</strong> questo grande gruppo, nacque<br />
l’UML versione 1.0.<br />
Un modello UML è cost<strong>it</strong>u<strong>it</strong>o da:<br />
Viste: mostrano i <strong>di</strong>versi aspetti del sistema <strong>per</strong> mezzo <strong>di</strong> <strong>un</strong> insieme <strong>di</strong><br />
<strong>di</strong>agrammi.<br />
Diagrammi: <strong>per</strong>mettono <strong>di</strong> descrivere graficamente le viste logiche.<br />
Elementi del modello: concetti che <strong>per</strong>mettono <strong>di</strong> realizzare vari <strong>di</strong>agrammi,<br />
ad esempio: classi, packages, oggetti, etc.<br />
Lo strato più esterno dell’UML è cost<strong>it</strong>u<strong>it</strong>o dalle seguenti viste:<br />
Use Case View , o Vista dei casi d'uso, utilizzata <strong>per</strong> analizzare i requis<strong>it</strong>i<br />
utente. Obiettivo <strong>di</strong> questo livello <strong>di</strong> analisi è stu<strong>di</strong>are il sistema<br />
considerandolo come <strong>un</strong>a scatola nera.<br />
Design View, o Vista <strong>di</strong> progettazione, descrive come le f<strong>un</strong>zional<strong>it</strong>à del<br />
sistema devono essere realizzate; in altre parole analizza il sistema<br />
dall'interno (scatola trasparente).<br />
Implementation View, o Vista <strong>di</strong> implementazione, descrive i packages, le<br />
classi e le reciproche <strong>di</strong>pendenze.<br />
Process View, o Vista dei processi, in<strong>di</strong>vidua i processi e le ent<strong>it</strong>à che li<br />
eseguono sia <strong>per</strong> <strong>un</strong> utilizzo efficace delle risorse, sia <strong>per</strong> poter stabilire<br />
l'esecuzione parallela degli oggetti.<br />
25
Deployment View, o Vista <strong>di</strong> <strong>sviluppo</strong>, mostra l'arch<strong>it</strong>ettura fisica del<br />
sistema e definisce la posizione delle componenti software nella struttura<br />
stessa.<br />
I <strong>di</strong>agrammi sono <strong>di</strong> svariati tipi, ogn<strong>un</strong>o dei quali descrive concetti <strong>di</strong>versi<br />
dagl’altri. A t<strong>it</strong>olo esemplificativo:<br />
Class Diagram, o Diagramma <strong>di</strong> Classe, consente <strong>di</strong> descrivere tipi <strong>di</strong><br />
ent<strong>it</strong>à, con le loro caratteristiche e le eventuali relazioni fra questi tipi.<br />
Object Diagram, o Diagramma d’Oggetto, descrive <strong>un</strong> sistema in<br />
termini <strong>di</strong> oggetti e relative relazioni.<br />
Statechart Diagram, o Diagramma <strong>di</strong> Stato, descrive il comportamento<br />
<strong>di</strong> ent<strong>it</strong>à o <strong>di</strong> classi in termini <strong>di</strong> stato, ovvero <strong>un</strong> automa a stati fin<strong>it</strong>i.<br />
Activ<strong>it</strong>y Diagram, o Diagramma <strong>di</strong> Attiv<strong>it</strong>à, definisce le attiv<strong>it</strong>à da<br />
svolgere <strong>per</strong> realizzare <strong>un</strong>a data f<strong>un</strong>zional<strong>it</strong>à.<br />
Sequence Diagram, o Diagramma <strong>di</strong> Sequenza, desacrive <strong>un</strong>o scenario,<br />
ovvero <strong>un</strong>a sequenza <strong>di</strong> azioni in cui tutte le scelte sono state già<br />
effettuate<br />
Comm<strong>un</strong>ication Diagram, o Diagramma <strong>di</strong> Com<strong>un</strong>icazione, descrive<br />
l'interazione fra più partecipanti alla realizzazione <strong>di</strong> <strong>un</strong>a certa<br />
f<strong>un</strong>zional<strong>it</strong>à.<br />
Component Diagram, rappresenta la struttura interna del sistema<br />
software modellato in termini dei suoi componenti principali e delle<br />
relazioni fra <strong>di</strong> essi.<br />
26
Deployment Diagram, descrive <strong>un</strong> sistema in termini <strong>di</strong> risorse<br />
hardware, dette no<strong>di</strong>, e <strong>di</strong> relazioni fra <strong>di</strong> esse.<br />
Compos<strong>it</strong>e Structure Diagram, consente la rappresentazione della<br />
struttura interna <strong>di</strong> classi e altri componenti software.<br />
Gli elementi del modello sono le icone utilizzate nei vari <strong>di</strong>agrammi.<br />
L’UML è <strong>un</strong> linguaggio molto più complesso e sofisticato <strong>di</strong> quanto detto,<br />
anche in ragione dell’apporto <strong>di</strong> tutte le gran<strong>di</strong> organizzazioni che hanno<br />
partecipato al progetto.<br />
Fig 1.2 Esempio <strong>di</strong> State Chart Diagram<br />
27
Cap<strong>it</strong>olo II<br />
PRINCIPALI COSTRUTTI, TIPI, ARRAY<br />
2.1 Definizione <strong>di</strong> costrutto<br />
E STRUTTURE DATI<br />
Ogni linguaggio <strong>di</strong> programmazione, sia esso testuale sia iconico, presenta <strong>un</strong>a<br />
serie <strong>di</strong> costrutti fondamentali e non, tipi e strutture dati. E’ noto che i linguaggi<br />
e le scr<strong>it</strong>ture sono basate su <strong>un</strong> sistemi iconici. Le icone d<strong>un</strong>que rappresentano<br />
le micro strutture della macro struttura con cui è strutturato <strong>un</strong> linguaggio. Il<br />
costrutto, d<strong>un</strong>que, è la struttura che si da ad <strong>un</strong>'idea <strong>per</strong> renderla esprimibile<br />
attraverso <strong>un</strong> sistema iconico.<br />
Un prototipo <strong>di</strong> linguaggio <strong>di</strong> programmazione testuale presenta <strong>un</strong>a propria<br />
formalizzazione del costrutto. Ad esempio, <strong>un</strong>a tipica assegnazione <strong>di</strong> <strong>un</strong><br />
metalinguaggio<br />
A B + C<br />
28
è <strong>un</strong> costrutto che assegna ad <strong>un</strong>a variabile A il risultato <strong>di</strong> <strong>un</strong> o<strong>per</strong>atore<br />
somma tra altre due variabili B e C, ovvero il simbolo A è legato ed associato al<br />
risultato dell’o<strong>per</strong>atore somma <strong>di</strong> altrettanti due simboli B e C.<br />
2.2 Costrutti principali<br />
I principali costrutti presenti nei linguaggi <strong>di</strong> programmazione, sia testuale che<br />
iconico sono:<br />
Dichiarazione <strong>di</strong> Variabili e Costanti<br />
Assegnazione<br />
Espressione e Con<strong>di</strong>zione<br />
Cicli: For, While, Repeat .. Until e Do .. While<br />
If .. Then .. Else<br />
Break, Continue, Return<br />
Sw<strong>it</strong>ch .. Case<br />
Il richiamo <strong>di</strong> Procedure e F<strong>un</strong>zioni<br />
Nel prosieguo si <strong>di</strong>scuterà sulla formalizzazione dei costrutti in maniera<br />
generica, su <strong>un</strong> metalinguaggio e basato sul linguaggio C, Delphi o Pascal e <strong>di</strong><br />
<strong>un</strong> linguaggio <strong>di</strong> programmazione iconica.<br />
29
2.2.1 Dichiarazione <strong>di</strong> Costanti<br />
La costante è <strong>un</strong> simbolo a cui è legato, generalmente, <strong>un</strong> valore fissato nel<br />
tempo. Ogni costante, o variabile, deve essere <strong>di</strong>chiarata prima <strong>di</strong> poter essere<br />
usata, questo in quanto il simbolo rappresentato dalla costante, o variabile, deve<br />
essere conosciuto precedentemente dal compilatore e, quin<strong>di</strong>, dall’applicativo<br />
stesso.<br />
Una tipica <strong>di</strong>chiarazione <strong>di</strong> <strong>un</strong> generico metalinguaggio è del tipo:<br />
const tipo_<strong>di</strong>_dato A espressione<br />
dove la parola chiave const identifica che il simbolo A è <strong>un</strong>a costante,<br />
tipo_<strong>di</strong>_dato è il tipo <strong>di</strong> dato al quale A afferisce, ovvero A è <strong>un</strong>a istanza <strong>di</strong><br />
tipo_<strong>di</strong>_dato, infine espressione è il valore che sarà assegnato ad A, questo può<br />
anche essere <strong>un</strong>’espressione molto articolata.<br />
Nel linguaggio C la <strong>di</strong>chiarazione è molto simile, cambia solo la sintassi:<br />
const tipo_<strong>di</strong>_dato A espressione<br />
Questa <strong>di</strong>chiarazione può essere inser<strong>it</strong>a in qual<strong>un</strong>que sezione <strong>di</strong> <strong>un</strong>a f<strong>un</strong>zione<br />
del linguaggio C o anche al <strong>di</strong> fuori delle f<strong>un</strong>zioni. Essa può anche essere<br />
inser<strong>it</strong>a come parametro ad <strong>un</strong>a f<strong>un</strong>zione.<br />
Nel linguaggio Delphi la <strong>di</strong>chiarazione <strong>di</strong> <strong>un</strong>a costante non può essere inser<strong>it</strong>a<br />
in qual<strong>un</strong>que parte del sorgente, ma trova la sua locazione o tra la specifica delle<br />
30
<strong>un</strong><strong>it</strong>à utilizzate e le istruzioni da eseguire oppure si trova tra la <strong>di</strong>chiarazione <strong>di</strong><br />
<strong>un</strong>a f<strong>un</strong>zione e l’inizio delle stesse.<br />
Un linguaggio <strong>di</strong> programmazione iconica deve essere in grado <strong>di</strong> poter<br />
<strong>di</strong>chiarare <strong>un</strong>a costante, inserendo opport<strong>un</strong>amente la <strong>di</strong>chiarazione all’interno<br />
del co<strong>di</strong>ce.<br />
2.2.2 Dichiarazione <strong>di</strong> Variabili<br />
Sia in <strong>un</strong> metalinguaggio che in C la <strong>di</strong>chiarazione <strong>di</strong> <strong>un</strong>a variabile avviene<br />
similmente come nella <strong>di</strong>chiarazione <strong>di</strong> <strong>un</strong>a costante. Quin<strong>di</strong>, la variabile può<br />
essere oltre che <strong>di</strong>chiarata anche inizializzata con <strong>un</strong> valore.<br />
Nel linguaggio Delphi la <strong>di</strong>chiarazione <strong>di</strong> <strong>un</strong>a variabile avviene sempre<br />
similmente alla <strong>di</strong>chiarazione <strong>di</strong> <strong>un</strong>a costante cambiando la keyword da const a<br />
var. Tuttavia, <strong>un</strong>a variabile non può essere inizializzata all’interno <strong>di</strong> <strong>un</strong>a<br />
procedura o f<strong>un</strong>zione, ma la si può solo <strong>di</strong>chiarare come tipo. Se la <strong>di</strong>chiarazione<br />
avviene all’interno <strong>di</strong> <strong>un</strong>a procedura o f<strong>un</strong>zione, la variabile deve essere<br />
inizializzata all’interno della procedura o f<strong>un</strong>zione.<br />
Un linguaggio iconico deve essere in grado <strong>di</strong> essere il più flessibile possibile,<br />
ciò significa che deve essere in grado anche <strong>di</strong> poter inizializzare le variabili<br />
anche in fase <strong>di</strong>chiarativa, come <strong>per</strong> le costanti.<br />
31
2.2.3 Assegnazione<br />
L’assegnazione ha la stessa struttura dell’inizializzazione nella fase <strong>di</strong><br />
<strong>di</strong>chiarazione. Il costrutto esprime <strong>un</strong> legame tra la variabile a sinistra<br />
dell’uguaglianza e il risultato dell’espressione alla destra dell’uguaglianza.<br />
Oltre all’assegnazione normale, esiste <strong>un</strong> particolare tipo <strong>di</strong> assegnazione<br />
defin<strong>it</strong>a ‘aumentata’. Questo tipo <strong>di</strong> assegnazione utilizza la variabile che la<br />
chiama implic<strong>it</strong>amente all’interno dell’espressione, senza <strong>un</strong> esplic<strong>it</strong>o<br />
inserimento. Un metalinguaggio esprimerebbe tale costrutto come <strong>di</strong> segu<strong>it</strong>o<br />
i +:= 1<br />
questo equivale a<br />
i := i + 1<br />
Oltre all’o<strong>per</strong>atore somma è possibile utilizzare <strong>un</strong> altro tipo <strong>di</strong> o<strong>per</strong>atore. Nel<br />
linguaggio C l’assegnazione aumentata è molto simile<br />
i += 1<br />
Oltre a questo genere <strong>di</strong> assegnazione, sia in C che in <strong>un</strong> metalinguaggio,<br />
esiste <strong>un</strong> altro tipo <strong>di</strong> assegnazione aumentata: quella anticipata e posticipata:<br />
32
posticipata i++<br />
anticipata ++i<br />
il risultato finale è identico, tuttavia a seconda dei contesti in cui tale costrutto<br />
è inser<strong>it</strong>o assume <strong>un</strong> contesto nettamente <strong>di</strong>fferente. Infatti, in <strong>un</strong> contesto in cui<br />
la variabile ‘i’ è usata come variabile <strong>di</strong> controllo all’interno <strong>di</strong> <strong>un</strong> ciclo, il<br />
valore <strong>di</strong> tale variabile è <strong>di</strong>fferente a seconda se è posticipata o anticipata.<br />
In Delphi, non esiste <strong>un</strong> costrutto simile. Si fa <strong>un</strong> uso esplic<strong>it</strong>o<br />
dell’assegnazione, richiamando nell’espressione la variabile da assegnare.<br />
L’<strong>un</strong>ica alternativa è l’uso <strong>di</strong> alc<strong>un</strong>e f<strong>un</strong>zioni, quale<br />
Inc(i)<br />
In generale, in C l’assegnazione usa il semplice simbolo ‘=’, mentre in Delphi<br />
si usano i due simboli ‘:=’;<br />
Un metalinguaggio <strong>di</strong> programmazione iconica deve prevedere l’uso<br />
dell’assegnazione aumentata ai soli linguaggi che la prevedono.<br />
2.2.4 Con<strong>di</strong>zione<br />
Una con<strong>di</strong>zione esprime il concetto <strong>di</strong> Ver<strong>it</strong>à o Fals<strong>it</strong>à <strong>di</strong> <strong>un</strong> pre<strong>di</strong>cato. Un<br />
pre<strong>di</strong>cato è <strong>un</strong> costrutto elementare, o espressione elementare, che può assumere<br />
soltanto <strong>un</strong> valore booleano. D<strong>un</strong>que, la con<strong>di</strong>zione è cost<strong>it</strong>u<strong>it</strong>a da <strong>un</strong>o o più<br />
33
pre<strong>di</strong>cati elementari. Quando vi sono più pre<strong>di</strong>cati, questi vengono relazionati<br />
tra loro attraverso o<strong>per</strong>atori logici o <strong>di</strong> confronto.<br />
Gli o<strong>per</strong>atori <strong>di</strong> confronto esprimono <strong>un</strong> valore su <strong>un</strong> confronto tra due<br />
elementi, espressioni o pre<strong>di</strong>cati.<br />
Sono elencati <strong>di</strong> segu<strong>it</strong>o alc<strong>un</strong>i esempi:<br />
=, uguaglianza<br />
, <strong>di</strong>verso<br />
=, maggiore uguale<br />
Gli o<strong>per</strong>atori <strong>di</strong> confronto sono uguali a quelli <strong>di</strong> sopra, sia in C che in Delphi.<br />
L’<strong>un</strong>ica <strong>di</strong>fferenza consiste che in C il significato <strong>di</strong> <strong>di</strong>verso è forn<strong>it</strong>o con i<br />
simboli ‘!=’ e l’uguaglianza con i simboli ‘==’.<br />
Gli o<strong>per</strong>atori logici esprimono <strong>un</strong> pre<strong>di</strong>cato più complesso a partire da<br />
pre<strong>di</strong>cati elementari. Dipendendo dai valori booleani dei singoli pre<strong>di</strong>cati e da<br />
gli o<strong>per</strong>atori logici, il pre<strong>di</strong>cato complessivo assume <strong>un</strong> particolare valore che si<br />
trova in <strong>un</strong>a ipotetica tabella <strong>di</strong> ver<strong>it</strong>à che, in fase <strong>di</strong> esecuzione. Gli o<strong>per</strong>atori<br />
logici si <strong>di</strong>vidono in duali o <strong>un</strong>ari. Si <strong>di</strong>ce duali quando l’o<strong>per</strong>atore crea il<br />
risultato tra due pre<strong>di</strong>cati. L’<strong>un</strong>ico o<strong>per</strong>atore logico <strong>un</strong>ario è la negazione. Di<br />
segu<strong>it</strong>o gli o<strong>per</strong>atori logici:<br />
34
And<br />
Or<br />
Not<br />
Gli o<strong>per</strong>atori logici in C usano simboli <strong>di</strong>versi<br />
&&, and<br />
||, or<br />
!, not<br />
In Delphi si usano gli stessi o<strong>per</strong>atori del metalinguaggio precedentemente<br />
descr<strong>it</strong>to.<br />
Forn<strong>it</strong>e le basi, <strong>un</strong> esempio <strong>di</strong> <strong>un</strong>a con<strong>di</strong>zione in <strong>un</strong> metalinguaggio è<br />
A and (B or C) >= (D or (C and A)).<br />
la quale è del tutto simile al C e al Delphi.<br />
Un metalinguaggio iconico dovrebbe essere in grado <strong>di</strong> rendere quanto più<br />
semplice possibile la visualizzazione <strong>di</strong> <strong>un</strong>a con<strong>di</strong>zione, anche complessa<br />
soprattutto quando vi sono più pre<strong>di</strong>cati.<br />
35
2.2.5 Sequenze<br />
La sequenza è <strong>un</strong> particolare tipo <strong>di</strong> costrutto che serve ad in<strong>di</strong>care <strong>un</strong> blocco<br />
<strong>di</strong> istruzioni nel flusso del programma. Tipicamente, viene utilizzato in<br />
concom<strong>it</strong>anza con i cicli o con i costrutti decisionale If..Then..Else e Case.<br />
In <strong>un</strong> metalinguaggio, è possibile usare la forma<br />
Begin<br />
istruzioni/costrutti<br />
End<br />
La quale risulta coincidente con il linguaggio Delphi.<br />
Nel linguaggio C, si usano simboli <strong>di</strong>versi<br />
{<br />
Istruzioni/costrutti<br />
}<br />
Un linguaggio iconico dovrebbe fornire tale costrutto all’utente.<br />
36
2.2.6 Cicli<br />
I Cicli sono costrutti molto importanti nei linguaggi <strong>di</strong> programmazione,<br />
attraverso essi si possono eseguire <strong>un</strong> numero <strong>di</strong> volte indefin<strong>it</strong>o <strong>un</strong>a serie <strong>di</strong><br />
o<strong>per</strong>azioni che altrimenti dovrebbero essere esplic<strong>it</strong>ate. Attraverso i cicli, si<br />
possono anche creare multiple <strong>di</strong>ramazioni nel ciclo <strong>di</strong> v<strong>it</strong>a del programma, in<br />
quanto all’interno <strong>di</strong> essi <strong>di</strong>verse variabili, dette variabili <strong>di</strong> controllo del ciclo,<br />
possono stravolgere l’andamento del flusso o<strong>per</strong>ativo a seconda del valore che<br />
esse acquisiscono. Inoltre, si fa spesso uso dei cicli quando si voglia mo<strong>di</strong>ficare<br />
più porzioni <strong>di</strong> <strong>un</strong>a variabile <strong>di</strong> tipo array mono o multi <strong>di</strong>mensionale.<br />
In generale i linguaggi contengono al loro interno tre tipi <strong>di</strong> ciclo:<br />
For<br />
While<br />
Repeat<br />
2.2.6.1 Ciclo For<br />
Il costrutto For <strong>per</strong>mette <strong>di</strong> <strong>it</strong>erare, <strong>un</strong> numero <strong>di</strong> volte ben defin<strong>it</strong>o, <strong>un</strong> insieme<br />
<strong>di</strong> istruzioni. Il numero <strong>di</strong> ripetizioni viene esplic<strong>it</strong>ato in fase <strong>di</strong> richiamo del<br />
costrutto. Un esempio in <strong>un</strong> metalinguaggio è<br />
For variabile = valore_iniziale a valore_finale istruzione/costrutto<br />
37
Variabile è la variabile <strong>di</strong> controllo che fa si che lim<strong>it</strong>a l’esecuzione del ciclo.<br />
Il ciclo ha termine nel momento che la variabile assume il valore <strong>di</strong> valore<br />
finale.<br />
In C, il For ha <strong>un</strong> costrutto <strong>di</strong>verso<br />
For (valore_iniziale, con<strong>di</strong>zione_<strong>di</strong>_test, incremento) istruzione/costrutto<br />
Come si evince, in C fornisce <strong>un</strong>a maggiore flessibil<strong>it</strong>à. Il ciclo viene esegu<strong>it</strong>o<br />
fin quando viene verificata la con<strong>di</strong>zione <strong>di</strong> test, e ad ogni ciclo l’incremento, o<br />
anche decremento, è <strong>un</strong>a espressione. Esempi <strong>di</strong> espressioni <strong>per</strong> il For in C sono<br />
‘i++’ o ‘i*2’.<br />
In Delphi, il costrutto è simile al metalinguaggio, la <strong>di</strong>fferenza consiste solo<br />
nel simbolo <strong>di</strong> assegnazione, infatti dove nel metalinguaggio è riportato il<br />
simbolo ‘=’, in Delphi è ‘:=’.<br />
2.2.6.2 Ciclo While<br />
Il costrutto While è molto simile, a livello concettuale, al For. La <strong>di</strong>fferenza è<br />
che in questo costrutto le istruzioni sono ripetute fin quando la con<strong>di</strong>zione del<br />
While è vera. E’ molto importante far si che vi sia almeno <strong>un</strong> caso in cui la<br />
con<strong>di</strong>zione del While assuma <strong>un</strong> valore false, altrimenti il ciclo sarà infin<strong>it</strong>o e il<br />
programma non avrà mai termine. D<strong>un</strong>que, bisogna prestare molta attenzione<br />
circa le variabili incluse nella con<strong>di</strong>zione del While.<br />
In <strong>un</strong> metalinguaggio il costrutto While assume la seguente forma<br />
38
While ( con<strong>di</strong>zione) do istruzione/costrutto<br />
Nel C il costrutto è assume la seguente forma<br />
While ( con<strong>di</strong>zione ) istruzione/costrutto<br />
In Delphi, il costrutto è identico all’esempio del metalinguaggio.<br />
2.2.6.3 Ciclo Repeat .. Until e Do .. While<br />
I costrutti Do .. While e Repeat .. Until sono due costrutti che eseguo <strong>un</strong><br />
blocco <strong>di</strong> co<strong>di</strong>ce almeno <strong>un</strong>a volta e soltanto dopo aver esegu<strong>it</strong>o il blocco <strong>di</strong><br />
co<strong>di</strong>ce, verificano se la con<strong>di</strong>zione è vera o falsa.<br />
In <strong>un</strong> metalinguaggio questo ciclo assume la seguente struttura<br />
Do<br />
While ( con<strong>di</strong>zione)<br />
Nel linguaggio C il costrutto è quasi simile la <strong>di</strong>fferenza consiste nel sost<strong>it</strong>uire<br />
‘BEGIN’ con il simbolo ‘{‘ ed ‘END’ con il simbolo ‘}’<br />
39
Do<br />
While ( con<strong>di</strong>zione)<br />
In Delphi vengono utilizzate le parole ‘REPEAT’ e ‘UNTIL’ <strong>per</strong> sost<strong>it</strong>uire,<br />
rispettivamente, ‘DO’ e ‘WHILE’<br />
REPEAT<br />
UNTIL ( con<strong>di</strong>zione)<br />
2.2.6.4 Considerazioni sui cicli<br />
Non tutti i cicli vengono realizzati dai linguaggi <strong>di</strong> programmazione. Spesso<br />
sono presenti solo i primi due cicli proposti. Tuttavia, è necessario solo <strong>un</strong>a<br />
tipologia <strong>di</strong> ciclo poiché gli altri tipi si possono ottenere da <strong>un</strong>o solo, anche se,<br />
generalmente, i linguaggi <strong>di</strong> programmazione <strong>di</strong> basso livello usano i 3 cicli<br />
suddetti. Ad esempio, con il ciclo For e il ciclo While possono essere sost<strong>it</strong>u<strong>it</strong>i<br />
dal ciclo While.<br />
Un linguaggio <strong>di</strong> programmazione iconica deve possedere la capac<strong>it</strong>à <strong>di</strong> poter<br />
rappresentare tutti i cicli presentati. Per maggior chiarezza e comprensione è<br />
anche utile che abbia <strong>un</strong>a sola icona che rappresenti il concetto <strong>di</strong> ciclo, ma che<br />
fornisca la possibil<strong>it</strong>à <strong>di</strong> scegliere all’utente quale scegliere, tra i vari cicli.<br />
40
2.2.7 If .. Then .. Else<br />
Un altro costrutto molto importante è l’If .. Then .. Else. Con tale struttura si<br />
ha la possibil<strong>it</strong>à <strong>di</strong> <strong>di</strong>scriminare <strong>un</strong>a con<strong>di</strong>zione eseguendo, a seconda del<br />
risultato <strong>di</strong> quest’ultima, <strong>un</strong> blocco <strong>di</strong> co<strong>di</strong>ce oppure <strong>un</strong> altro. Tale costrutto può<br />
anche essere annidato fornendo <strong>un</strong>a maggiore compless<strong>it</strong>à <strong>di</strong> <strong>di</strong>ramazioni al<br />
ciclo <strong>di</strong> v<strong>it</strong>a del programma.<br />
Un metalinguaggio ha <strong>un</strong>a struttura simile alla seguente<br />
If ( con<strong>di</strong>zione) Then<br />
istruzione/costrutto<br />
Else<br />
istruzione/costrutto<br />
Se la con<strong>di</strong>zione è vera allora il ciclo <strong>di</strong> v<strong>it</strong>a del programma continuerà nel<br />
primo blocco <strong>di</strong> co<strong>di</strong>ce, saltando il blocco che è sub<strong>it</strong>o dopo Else. Se la<br />
con<strong>di</strong>zione è falsa allora il programma non terrà conto del primo blocco <strong>di</strong><br />
co<strong>di</strong>ce, ma passerà <strong>di</strong>rettamente al secondo blocco, continuando poi<br />
normalmente.<br />
Ad esempio<br />
If ((a>10) and (a
istruzione/costrutto<br />
ovvero: se ‘a’ è maggiore <strong>di</strong> 10 ed ‘a’ è minore <strong>di</strong> 50 allora si prende in<br />
considerazione il primo blocco non tenendo conto del secondo. Altrimenti, si<br />
procede col secondo blocco, saltando il primo.<br />
In Delphi il costrutto coincide con l’esempio del metalinguaggio.<br />
In C il costrutto si <strong>di</strong>fferenzia in quanto manca l’uso della keyword ‘Then’ e<br />
dalla <strong>di</strong>chiarazione del blocco del co<strong>di</strong>ce.<br />
Un linguaggio <strong>di</strong> programmazione visuale deve essere in grado <strong>di</strong> fornire con<br />
chiarezza sia la costruzione della con<strong>di</strong>zione usata nel costrutto sia le sue<br />
<strong>di</strong>ramazioni, facendo si che l’utente abbia chiaro il significato delle icone al fine<br />
<strong>di</strong> ev<strong>it</strong>are <strong>un</strong> uso improprio del costrutto.<br />
2.2.8 Break, Continue e Return<br />
I costrutti Break, Continue e Return sono anch’essi molto importanti sul ciclo<br />
<strong>di</strong> v<strong>it</strong>a <strong>di</strong> <strong>un</strong> programma. Ogn<strong>un</strong>o <strong>di</strong> essi è a<strong>di</strong>b<strong>it</strong>o ad <strong>un</strong>a ben specifica f<strong>un</strong>zione.<br />
Sono inclusi sia nei metalinguaggi, sia in C che in Delphi, e dovrebbero essere<br />
inclusi anche in <strong>un</strong> linguaggio iconico. Le keyword Break e Continue sono<br />
uguali sia nei metalinguaggi, che in C e in Delphi.<br />
42
2.2.8.1 Break<br />
Break è <strong>un</strong>’istruzione che <strong>per</strong>mette <strong>di</strong> uscire da <strong>un</strong> ciclo senza uscire dalla<br />
f<strong>un</strong>zione o procedura. Può essere associato ad <strong>un</strong> costrutto If all’interno <strong>di</strong> <strong>un</strong><br />
ciclo, e bisogna utilizzarlo con attenzione.<br />
2.2.8.2 Continue<br />
Questo costrutto <strong>per</strong>mette ad <strong>un</strong> ciclo <strong>di</strong> saltare tutto ciò che vi è nel blocco<br />
del co<strong>di</strong>ce facendo ricominciare la ripetizione del blocco, ma con l’incremento<br />
della variabile <strong>di</strong> controllo come se si fosse completato il precedente ciclo.<br />
2.2.8.3 Return<br />
Return è <strong>un</strong> costrutto che <strong>per</strong>mette alle f<strong>un</strong>zioni <strong>di</strong> rest<strong>it</strong>uire <strong>un</strong> valore ben<br />
defin<strong>it</strong>o in accordo col tipo <strong>di</strong>chiarato della f<strong>un</strong>zione. Sia in <strong>un</strong> metalinguaggio<br />
che in C, Return è segu<strong>it</strong>o da <strong>un</strong>a espressione. Quando Return viene inser<strong>it</strong>o<br />
all’interno <strong>di</strong> <strong>un</strong>a procedura allora Return può non precedere alc<strong>un</strong>a espressione<br />
o al massimo il valore ‘0’ (zero). Return viene usato come il seguente<br />
Return A+B<br />
43
In Delphi, solo <strong>di</strong> recente si è forn<strong>it</strong>o alla keyword Ex<strong>it</strong> la possibil<strong>it</strong>à <strong>di</strong> uscire<br />
da <strong>un</strong>a f<strong>un</strong>zione fornendo il valore <strong>di</strong> <strong>un</strong>’espressione. In Delphi, tipicamente, <strong>per</strong><br />
rest<strong>it</strong>uire il valore <strong>di</strong> <strong>un</strong>a f<strong>un</strong>zione si procede in due mo<strong>di</strong>: o si richiama la<br />
keyword Result e a questa si assegna il valore <strong>di</strong> <strong>un</strong>’espressione oppure si<br />
richiama il nome della f<strong>un</strong>zione stessa assegnandole <strong>un</strong> valore <strong>di</strong> <strong>un</strong>’espressione.<br />
Ad esempio se la f<strong>un</strong>ziona si chiama Mia_f<strong>un</strong>zione, in Delphi si usa la seguente<br />
sintassi<br />
Mia_f<strong>un</strong>zione := 5 oppure Result := 5 oppure Ex<strong>it</strong>(5)<br />
E’ utile sottolineare, che in Delphi la keyword Ex<strong>it</strong> <strong>per</strong>mette <strong>di</strong> uscire<br />
dall’esecuzione <strong>di</strong> <strong>un</strong>a f<strong>un</strong>zione senza fornire <strong>un</strong> valore, ma tra parentesi tonde,<br />
come nell’esempio <strong>di</strong> sopra, vi è <strong>un</strong> valore in accordo con il tipo della f<strong>un</strong>zione,<br />
allora Ex<strong>it</strong> oltre ad uscire dalla f<strong>un</strong>zione fornisce anche il valore come risultato.<br />
Un linguaggio <strong>di</strong> programmazione visuale necess<strong>it</strong>a <strong>di</strong> possedere tale<br />
costrutto.<br />
2.2.9 Sw<strong>it</strong>ch .. Case<br />
Tale costrutto è forn<strong>it</strong>o da quasi tutti i linguaggi <strong>di</strong> programmazione. In <strong>un</strong><br />
metalinguaggio, esso ha la seguente struttura<br />
44
Sw<strong>it</strong>ch (espressione)<br />
{<br />
Case elem1:<br />
Blocco_<strong>di</strong>_co<strong>di</strong>ce1<br />
break;<br />
Case elem2:<br />
Blocco_<strong>di</strong>_co<strong>di</strong>ce2<br />
break;<br />
…<br />
Case elemn:<br />
Blocco_<strong>di</strong>_co<strong>di</strong>cen<br />
break;<br />
Default:<br />
Blocco_<strong>di</strong>_co<strong>di</strong>ce<br />
break;<br />
}<br />
Dalla sua struttura si evince la sua grande util<strong>it</strong>à. Esso <strong>per</strong>mette <strong>di</strong> poter<br />
scegliere quale blocco <strong>di</strong> co<strong>di</strong>ce verrà preso in considerazione in base al valore<br />
che espressione assume. La keyword case in<strong>di</strong>ca i possibili valori da tenere in<br />
considerazione e che sono specificati dagli elementi. Essi, inoltre, sono dello<br />
stesso tipo del valore che assume l’espressione. La parola chiave default è<br />
opzionale e fa in modo che il costrutto case scelga il suo blocco <strong>di</strong> co<strong>di</strong>ce nel<br />
45
caso in cui ness<strong>un</strong>o degli elementi corrispondono al valore dell’espressione.<br />
Inoltre, l’istruzione Break è inser<strong>it</strong>a poiché alc<strong>un</strong>i linguaggi <strong>di</strong> programmazione,<br />
come il C, dopo aver esegu<strong>it</strong>o il blocco <strong>di</strong> co<strong>di</strong>ce identificato dall’elemento,<br />
continuano a verificare se il valore <strong>di</strong> espressione è verificato <strong>per</strong> altri casi.<br />
Questo in quanto è possibile mo<strong>di</strong>ficare il valore assegnato all’espressione se<br />
questa è <strong>un</strong>a variabile.<br />
Questo costrutto può essere pensato come <strong>un</strong>a serie <strong>di</strong> costrutti If i quali sono<br />
o annidati tra <strong>di</strong> loro o messi in successione. L’util<strong>it</strong>à <strong>di</strong> questo costrutto è<br />
rimarchevole e quasi tutti i programmi, semplici o complessi, lo usano almeno<br />
<strong>un</strong>a volta.<br />
Nel linguaggio C, tale costrutto trova la stessa forma come nel caso del<br />
metalinguaggio sopra specificato.<br />
In Pascal, il costrutto assume <strong>un</strong>a forma <strong>di</strong>versa, ma cogn<strong>it</strong>ivamente simile<br />
Case (espressione)<br />
Begin<br />
elem1:<br />
Blocco_<strong>di</strong>_co<strong>di</strong>ce1<br />
elem2:<br />
Blocco_<strong>di</strong>_co<strong>di</strong>ce2<br />
…<br />
elemn:<br />
Blocco_<strong>di</strong>_co<strong>di</strong>cen<br />
Else<br />
Blocco_<strong>di</strong>_co<strong>di</strong>ce<br />
46
End<br />
Si nota che la parola Sw<strong>it</strong>ch viene sost<strong>it</strong>u<strong>it</strong>a da Case e Case non figura prima<br />
dei valori del dominio dell’espressione. Inoltre, la parola Deafault viene<br />
sost<strong>it</strong>u<strong>it</strong>a da Else e non viene segu<strong>it</strong>o dal simbolo ‘:’. Da notare che in Pascal, il<br />
costrutto Case non fa uso della parola Break, questo in quanto il costrutto stesso<br />
quando identifica il valore dell’elemento esegue solo il blocco <strong>di</strong> co<strong>di</strong>ce legato<br />
al valore dell’espressione.<br />
Un linguaggio <strong>di</strong> programmazione iconica deve prevedere l’uso <strong>di</strong> tale<br />
costrutto e deve anche provvedere ad <strong>un</strong>a chiara e <strong>di</strong>stinta identificazione <strong>di</strong> ogni<br />
valore che l’espressione può assumere, fornendo quin<strong>di</strong> all’utente <strong>un</strong> modo<br />
imme<strong>di</strong>ato <strong>per</strong> comprendere le possibili scelte.<br />
2.2.10 Procedure e F<strong>un</strong>zioni<br />
Particolari costrutti sono le Procedure e le F<strong>un</strong>zioni. Una Procedura o<br />
F<strong>un</strong>zione è <strong>un</strong> blocco <strong>di</strong> co<strong>di</strong>ce isolato. Tale blocco <strong>di</strong> co<strong>di</strong>ce deve essere<br />
identificato con <strong>un</strong> nome <strong>per</strong> poter essere richiamato dal resto del programma.<br />
Questo approccio <strong>per</strong>mette <strong>di</strong> strutturare meglio la compless<strong>it</strong>à <strong>di</strong> <strong>un</strong> programma<br />
delegando a parti <strong>di</strong> co<strong>di</strong>ce <strong>un</strong> suo f<strong>un</strong>zionamento. Inoltre, esse <strong>per</strong>mettono <strong>di</strong><br />
<strong>di</strong>minuire la ridondanza <strong>di</strong> co<strong>di</strong>ce all’interno del programma, in quanto spesso,<br />
durante il ciclo <strong>di</strong> v<strong>it</strong>a <strong>di</strong> <strong>un</strong> applicativo, occorre che si eseguano più volte<br />
porzioni <strong>di</strong> co<strong>di</strong>ce o quando si vuole ottenere <strong>un</strong> risultato <strong>di</strong> <strong>un</strong> qualche tipi<br />
47
attraverso le f<strong>un</strong>zioni, o si vuole ottenere <strong>un</strong> cambiamento nel programma<br />
attraverso le procedure. La <strong>di</strong>fferenza essenziale tra <strong>un</strong>a procedura ed <strong>un</strong>a<br />
f<strong>un</strong>zione è che <strong>un</strong>a f<strong>un</strong>zione r<strong>it</strong>orna <strong>un</strong> valore o, in modo equivalente, la<br />
f<strong>un</strong>zione assume il valore del risultato del blocco <strong>di</strong> co<strong>di</strong>ce che rappresenta,<br />
mentre <strong>un</strong>a procedura non rest<strong>it</strong>uisce alc<strong>un</strong> risultato.<br />
2.2.10.1 Procedura<br />
Un metalinguaggio utilizza la seguente struttura<br />
Procedure Mia_Procedura(Param1, Param1, … , Paramn)<br />
Begin<br />
…<br />
End<br />
La parola Procedura in<strong>di</strong>ca che si sta <strong>di</strong>chiarando <strong>un</strong>a procedura ed il nome<br />
che ne segue Mia_Procedura è il nome che si utilizzerà <strong>per</strong> richiamarla. I<br />
Parametri tra le parentesi tonde significa che la procedura, <strong>per</strong> essere chiamata,<br />
necess<strong>it</strong>a <strong>di</strong> <strong>un</strong>a serie <strong>di</strong> parametri in ingresso. Questi parametri possono essere<br />
passati <strong>per</strong> valore, o <strong>per</strong> referenza che significa passare ‘fisicamente’ <strong>un</strong>a istanza<br />
<strong>di</strong> <strong>un</strong> tipo alla procedura stessa in modo che essa lo possa manipolare. E’<br />
possibile anche inizializzare <strong>un</strong>o o più parametri qualora si preveda <strong>un</strong> valore <strong>di</strong><br />
default <strong>di</strong> alc<strong>un</strong>i parametri. Infine il blocco <strong>di</strong> co<strong>di</strong>ce tra Begin ed End<br />
48
cost<strong>it</strong>uisce tutto il co<strong>di</strong>ce a cui ci si riferisce quando si chiama la<br />
Mia_Procedura.<br />
In C il costrutto della Procedura è come segue<br />
Void Mia_Procedura(Param1, Param1, … , Paramn)<br />
{<br />
…<br />
}<br />
In C, quin<strong>di</strong>, non vi è <strong>un</strong>a esplic<strong>it</strong>a <strong>di</strong>chiarazione della Procedura, in quanto in<br />
realtà non esiste la <strong>di</strong>versificazione netta tra procedura e f<strong>un</strong>zione. Questa viene<br />
compresa dal fatto che il tipo Void è <strong>un</strong> tipo nullo che se forn<strong>it</strong>o ad <strong>un</strong>a f<strong>un</strong>zione<br />
la si <strong>di</strong>chiara automaticamente come procedura. Per concludere, in C <strong>un</strong>a<br />
procedura non necess<strong>it</strong>a del return, in quanto non r<strong>it</strong>orna alc<strong>un</strong> valore, sebbene<br />
l’inserimento <strong>di</strong> tale keyword è <strong>per</strong>messo.<br />
In Pascal, il costrutto della Procedura è del tutto simile all’esempio del<br />
metalinguaggio riportato. E’ da notare che tra la <strong>di</strong>chiarazione della procedura e<br />
la parola Begin è possibile definire <strong>di</strong>verse costanti, variabili, tipi, etichette, ecc.<br />
Queste non sono i parametri richiesti dal programma ma sono istanze <strong>di</strong> costrutti<br />
i quali possono essere utilizzati soltanto all’interno della Procedura che li<br />
<strong>di</strong>chiara, e quin<strong>di</strong> non in qual<strong>un</strong>que altra porzione dell’applicativo. Questa<br />
particolar<strong>it</strong>à viene chiamata Visibil<strong>it</strong>à Locale, in quanto tali costrutti sono ‘visti’<br />
solo dalla procedura che li istanzia. Esiste anche <strong>un</strong>a Visibil<strong>it</strong>à Globale, in<br />
qual<strong>un</strong>que linguaggio <strong>di</strong> programmazione che significa che le istanze <strong>di</strong>chiarate<br />
49
sono accessibili da qual<strong>un</strong>que porzione dell’applicativo, anche da qual<strong>un</strong>que<br />
f<strong>un</strong>zione o procedura.<br />
Un linguaggio <strong>di</strong> programmazione iconica necess<strong>it</strong>a <strong>di</strong> rappresentare tale<br />
costrutto, in quanto essenziale alla <strong>di</strong>versificazione del flusso logico del<br />
programma che si sviluppa. D<strong>un</strong>que, oltre a fornire <strong>un</strong>a rappresentazione<br />
iconica, tale linguaggio, deve essere in grado <strong>di</strong> mostrare visivamente anche il<br />
suo contenuto, con i dovuti accorgimenti.<br />
2.2.10.2 F<strong>un</strong>zione<br />
Il costrutto F<strong>un</strong>zione è molto simile a quello della Procedura, <strong>un</strong>ica <strong>di</strong>fferenza<br />
è che in fase <strong>di</strong>chiarativa deve essere assegnato <strong>un</strong> tipo <strong>di</strong> dato che la F<strong>un</strong>zione<br />
deve rest<strong>it</strong>uire. Di segu<strong>it</strong>o la forma del costrutto in <strong>un</strong> metalinguaggio<br />
Tipo Mia_F<strong>un</strong>zione(Param1, Param1, … , Paramn)<br />
Begin<br />
…<br />
Return( Risultato)<br />
End<br />
Il tipo <strong>di</strong> dato può essere <strong>un</strong> qual<strong>un</strong>que tipo <strong>di</strong> dato che può assumere<br />
qual<strong>un</strong>que variabile o costante. I parametri seguono lo stesso cr<strong>it</strong>erio della<br />
Procedura, così come il Blocco <strong>di</strong> Co<strong>di</strong>ce. La parola Return è fondamentale <strong>per</strong><br />
50
fornire, alla porzione del co<strong>di</strong>ce che richiama la F<strong>un</strong>zione, il Risultato dei calcoli<br />
della f<strong>un</strong>zione. Un esempio tipico <strong>di</strong> <strong>un</strong>a f<strong>un</strong>zione è<br />
Int Somma( Int a, Int b)<br />
Begin<br />
Return (a + b);<br />
End;<br />
Dove Int è il tipo <strong>di</strong> dato Intero e definisce che il risultato, o il valore ass<strong>un</strong>to<br />
dalla f<strong>un</strong>zione alla fine del suo ciclo <strong>di</strong> v<strong>it</strong>a, è <strong>di</strong> tipo Intero. Somma è il nome<br />
della f<strong>un</strong>zione, è può essere richiamata dal porgramma con la seguente sintassi<br />
Somma(a, b)<br />
Dove ‘a’ e ‘b’ sono due variabili o costanti che hanno <strong>un</strong> qualsiasi valore<br />
nell’insieme dei numeri interi.<br />
In C il costrutto è simile<br />
Int Somma( Int a, Int b)<br />
{<br />
}<br />
Return (a + b);<br />
51
In Pascal, il costrutto è molto simile, tuttavia la <strong>di</strong>chiarazione del tipo della<br />
f<strong>un</strong>zione è forn<strong>it</strong>a alla fine della <strong>di</strong>chiarazione del nome e dei suoi parametri. Di<br />
segu<strong>it</strong>o <strong>un</strong> esempio<br />
F<strong>un</strong>ction Somma( Integer a; Integer b): Integer;<br />
Begin<br />
Result := a + b;<br />
End;<br />
Un linguaggio iconico <strong>di</strong> programmazione deve prevedere l’uso <strong>di</strong> tale<br />
costrutto e deve essere in grado <strong>di</strong> fornire <strong>un</strong>a sua rappresentazione iconica.<br />
Inoltre, sia <strong>per</strong> la F<strong>un</strong>zione che <strong>per</strong> la Procedura, tale linguaggio deve eseguire<br />
<strong>un</strong> controllo preventivo sui tipi <strong>di</strong> dati in ingresso, al fine <strong>di</strong> guidare l’utente nel<br />
costruire <strong>un</strong> co<strong>di</strong>ce sicuro e, quin<strong>di</strong>, ev<strong>it</strong>are errori in fase <strong>di</strong> compilazione.<br />
2.3 Tipi <strong>di</strong> dato<br />
Nei linguaggi <strong>di</strong> programmazione esistono vari tipi <strong>di</strong> dati prim<strong>it</strong>ivi forn<strong>it</strong>i. Un<br />
tipo <strong>di</strong> dato altro non è che <strong>un</strong>a caratteristica che fornisce il significato e il<br />
comportamento <strong>di</strong> <strong>un</strong>a variabile, costante o f<strong>un</strong>zione. I tipi si <strong>di</strong>stinguono in<br />
prim<strong>it</strong>ivi e <strong>di</strong> enumerazione.<br />
52
2.3.1 Tipi prim<strong>it</strong>ivi<br />
I tipi prim<strong>it</strong>ivi, essenzialmente, sono i seguenti<br />
Void<br />
Char<br />
Int<br />
Short<br />
Long<br />
Float<br />
Double<br />
A questi si <strong>un</strong>iscono le seguenti due definizioni <strong>di</strong> range <strong>per</strong> i numeri<br />
Signed<br />
Unsigned<br />
In particolare, nella definizione dei tipi numerici, qualora non venga<br />
specificato il range, il tipo <strong>di</strong> dato viene considerato in automatico ‘Signed’.<br />
Void serve essenzialmente <strong>per</strong> <strong>di</strong>chiarare <strong>un</strong>a f<strong>un</strong>zione come <strong>un</strong>a procedura.<br />
Tuttavia, in alc<strong>un</strong>i contesti, viene usato come tipo <strong>per</strong> i p<strong>un</strong>tatori, <strong>per</strong> il quale si<br />
richiede <strong>un</strong> uso intensivo <strong>di</strong> tecniche <strong>di</strong> ‘Type Casting’ forn<strong>it</strong>i dai vari linguaggi.<br />
53
Il tipo Char viene considerato come <strong>un</strong> byte ma anche come <strong>un</strong> singolo<br />
carattere, in quanto nel co<strong>di</strong>ce Ascii esteso i caratteri possibili rientrano nel<br />
range che spazia tra 0 e 255.<br />
Nella tabella 2.1 viene presentata <strong>un</strong>a rassegna dei tipi prim<strong>it</strong>ivi numerici nel<br />
linguaggio C<br />
2.3.2 Tipi <strong>di</strong> enumerazioni<br />
TIPO Dimensione in<br />
Signed Char<br />
Unsigned Char<br />
Byte 1<br />
1<br />
Signed Short 2<br />
Unsigned Short 2<br />
Signed Int 4<br />
Unsigned Int 4<br />
Signed Long 8<br />
Unsigned Long<br />
8<br />
Float<br />
Long<br />
Double<br />
4<br />
8<br />
Tabella 2.1 Tipi numerici in C<br />
I tipi enumerativi sono dei tipi appartenenti ad <strong>un</strong> insieme ben defin<strong>it</strong>o,<br />
generalmente forn<strong>it</strong>o dallo sviluppatore. Il costrutto prende forma come nella<br />
seguente<br />
Enum Nome_Insieme(Elem1, Elem2, … , Elemn)<br />
54
Enum <strong>di</strong>chiara che si sta creando <strong>un</strong> insieme <strong>di</strong> dati, che contiene elementi ben<br />
specificati. Nome Insieme identificherà l’insieme. Gli elementi cost<strong>it</strong>uiscono i<br />
valori che l’insieme contiene. Questi vengono interpretati dal compilatore come<br />
dei valori numerici, sebbene agli elementi possiamo dare <strong>un</strong> interpretazione<br />
<strong>di</strong>versa. Ad esempio<br />
Enum Colori (Blu, Verde, Rosso)<br />
Significa che si sta creando <strong>un</strong> insieme chiamato Colori e gli elementi <strong>di</strong><br />
questo insieme sono: Blu, Verde e Rosso, che assumono in default i valori,<br />
rispettivamente, 0, 1 e 2. E’ possibile specificare i valori che gli elementi<br />
assumono, fornendo <strong>un</strong> valore iniziale agli elementi, ad esempio<br />
Enum Colori (Blu= 1, Verde, Rosso)<br />
In<strong>di</strong>ca che Blu assume il valore 0, e gli altri elementi seguiranno da questo,<br />
quin<strong>di</strong>, Verde sarà uguale ad 1 e Rosso a 2. Le enum ci vengono incontro<br />
quando abbiamo a che fare, quin<strong>di</strong>, con <strong>un</strong>a lista <strong>di</strong> valori. Questo significa<br />
poter astrarre i valori numerici a interpretazioni soggettive. Un utile esempio è il<br />
seguente<br />
55
Case (espressione)<br />
{<br />
Case Blu:<br />
Blocco_<strong>di</strong>_co<strong>di</strong>ce1<br />
Case Verde:<br />
Blocco_<strong>di</strong>_co<strong>di</strong>ce2<br />
…<br />
Case Giallo:<br />
}<br />
Blocco_<strong>di</strong>_co<strong>di</strong>cen<br />
il co<strong>di</strong>ce sopra fa si che quando espressione assume il valore <strong>di</strong> <strong>un</strong> elemento<br />
del tipo Colori allora eseguirà il rispettivo blocco <strong>di</strong> co<strong>di</strong>ce in<strong>di</strong>cato. Cambiare<br />
l’or<strong>di</strong>ne del costrutto Case o gli elementi dell’insieme Colori non varia il<br />
comportamento logico del programma.<br />
In Pascal, le enumerazioni assumono la stessa forma ma vengono<br />
esplic<strong>it</strong>amente <strong>di</strong>chiarate come tipi.<br />
Un linguaggio <strong>di</strong> programmazione visuale deve assicurare l’esistenza delle<br />
enumerazioni potendo, così, fornire <strong>un</strong> potente strumento <strong>di</strong> programmazione<br />
<strong>per</strong> la gestione degli insiemi.<br />
56
2.3.3 Array<br />
Sia i tipi prim<strong>it</strong>ivi che le strutture sono dei tipi <strong>di</strong> dati generici.<br />
Precedentemente si è accennato all’esistenza <strong>di</strong> <strong>un</strong> particolare tipo <strong>di</strong> struttura,<br />
gli Array. Un array può essere defin<strong>it</strong>o come <strong>un</strong>a “collezione organizzata <strong>di</strong><br />
oggetti”. Il concetto <strong>di</strong> “collezione” implica che tali oggetti siano dello stesso<br />
tipo, così, prendendo sp<strong>un</strong>to dal mondo reale, potremmo definire <strong>un</strong> array <strong>di</strong><br />
Persone, che, quin<strong>di</strong> non può contenere ness<strong>un</strong> “oggetto animale”; <strong>un</strong> array in C<br />
è <strong>un</strong>a collezione <strong>di</strong> variabili dello stesso tipo.<br />
“Organizzata” implica che sia possibile identificare <strong>un</strong>ivocamente tutti gli<br />
oggeti dell’array in modo sistematico; questo in C viene fatto tram<strong>it</strong>e l’uso <strong>di</strong><br />
in<strong>di</strong>ci numerici che, in <strong>un</strong> array <strong>di</strong> <strong>di</strong>mensione N, vanno da 0 ad N-1. In C, <strong>un</strong><br />
array viene <strong>di</strong>chiarato nella seguente forma<br />
Tipo Mio_array[N]<br />
dove Tipo specifica il tipo <strong>di</strong> dato che tutti gli elementi dell’array avranno,<br />
Mio_Array è il nome della variabile o costante, ed N identifica il numero <strong>di</strong><br />
elementi che l’array conterrà.<br />
In Pascal, <strong>un</strong> array viene <strong>di</strong>chiarato come segue<br />
Mio_Array: Array[N] of Tipo<br />
E’ fondamentale che <strong>un</strong> linguaggio <strong>di</strong> programmazione visuale abbia tale tipo<br />
<strong>di</strong> struttura, in quanto essenziale in ogni linguaggio <strong>di</strong> programmazione<br />
57
2.3.4 Strutture<br />
Un altro importante oggetto, che viene considerato l’antenato <strong>di</strong> molte altre<br />
strutture, come le Classi, è la Struttura. Una struttura o Record è <strong>un</strong> tipo <strong>di</strong> dato<br />
capace <strong>di</strong> incapsulare più elementi <strong>di</strong>stinti all’interno <strong>di</strong> esso. Concettualmente,<br />
è <strong>un</strong> dato eterogeneo cost<strong>it</strong>u<strong>it</strong>o da più variabili e strutture <strong>di</strong>verse. Le strutture<br />
sostanzialmente <strong>per</strong>mettono l’aggregazione <strong>di</strong> più variabili, in modo simile a<br />
quella degli array, ma a <strong>di</strong>fferenza <strong>di</strong> questi non or<strong>di</strong>nata e non omogenea (<strong>un</strong>a<br />
struttura può contenere variabili <strong>di</strong> tipo <strong>di</strong>verso). Per denotare <strong>un</strong>a struttura si<br />
usa la parola chiave struct segu<strong>it</strong>a dal nome identificativo della struttura, che è<br />
opzionale. In C, si usa la seguente forma <strong>per</strong> definire <strong>un</strong>a struttura<br />
Struct Persona<br />
{<br />
}<br />
char Nome[100];<br />
char Cognome[50];<br />
int Altezza;<br />
Il co<strong>di</strong>ce <strong>di</strong> sopra in<strong>di</strong>ca che si è creato <strong>un</strong>a struttura chiamata Persona che ha<br />
tre variabili: Nome, <strong>un</strong> array <strong>di</strong> 100 caratteri; Cognome <strong>un</strong> array <strong>di</strong> 50 caratteri;<br />
Altezza, <strong>un</strong>a variabile <strong>di</strong> tipo intero. Per poter istanziare <strong>un</strong>a variabile <strong>di</strong> tipo<br />
struttura <strong>di</strong> tipo Persona si usa la seguente sintassi<br />
Struct Persona Guido<br />
58
Le strutture servono <strong>per</strong> poter dare <strong>un</strong>a migliore lettura del co<strong>di</strong>ce e <strong>un</strong>a<br />
migliore usabil<strong>it</strong>à del co<strong>di</strong>ce, fornendo allo sviluppatore <strong>un</strong>o strumento che gli<br />
<strong>per</strong>metterà <strong>di</strong> comprendere a livello logico e concettuale l’uso delle variabili.<br />
2.4 <strong>Analisi</strong> finale<br />
Si è <strong>di</strong>scusso dei principali Costrutti, dei tipi, degli array e delle strutture <strong>di</strong><br />
dati che ogni linguaggio <strong>di</strong> programmazione, <strong>di</strong> basso o alto livello, dovrebbe<br />
avere, fornendo chiari esempi <strong>per</strong> comprendere la maggior parte delle<br />
caratteristiche che ogn<strong>un</strong>o <strong>di</strong> questi elementi possiede.<br />
Nel cap<strong>it</strong>olo successivo si analizzerà lo <strong>sviluppo</strong> <strong>di</strong> <strong>un</strong> <strong>framework</strong> <strong>di</strong><br />
programmazione iconica.<br />
59
Cap<strong>it</strong>olo III<br />
SVILUPPO DI UN LINGUAGGIO DI<br />
PROGRAMMAZIONE ICONICA<br />
3.1 Sviluppo del Framework<br />
Lo <strong>sviluppo</strong> <strong>di</strong> <strong>un</strong> <strong>framework</strong> deve seguire cr<strong>it</strong>eri ben precisi, dalla facil<strong>it</strong>à <strong>di</strong><br />
comprensione del <strong>framework</strong> alla facil<strong>it</strong>à <strong>di</strong> utilizzo dello stesso. Ci si è chiesto<br />
quale potesse essere <strong>un</strong> modello visuale da utilizzare <strong>per</strong> facil<strong>it</strong>are sia la<br />
comprensione logica della stesura <strong>di</strong> <strong>un</strong> generico programma sia la facil<strong>it</strong>à nel<br />
sviluppare applicativi. Tra i vari modelli possibili si è scelto <strong>di</strong> utilizzare <strong>un</strong><br />
modello che più si avvicina a quello dei <strong>di</strong>agrammi a blocchi, <strong>per</strong> varie ragioni:<br />
E’ <strong>un</strong> chiaro modello <strong>di</strong> implementazione concettuale circa il<br />
comportamento <strong>di</strong> <strong>un</strong> algor<strong>it</strong>mo<br />
E’ <strong>un</strong> modello utilizzato da tutte le aziende <strong>per</strong> rappresentare i processi<br />
logici dei vari algor<strong>it</strong>mi<br />
E’ <strong>un</strong> modello facilmente mo<strong>di</strong>ficabile qualora si volessero apportare<br />
miglioramenti al co<strong>di</strong>ce iconico.<br />
60
E’ <strong>un</strong> tipo <strong>di</strong> schema nel quale le icone forniscono <strong>un</strong> imme<strong>di</strong>ato feedback<br />
intu<strong>it</strong>ivo, atto a identificare i processi dell’algor<strong>it</strong>mo.<br />
Ogni icona del <strong>di</strong>agramma a blocchi rappresenta <strong>un</strong> tipo particolare <strong>di</strong> dato,<br />
<strong>un</strong>’istruzione oppure <strong>un</strong>a f<strong>un</strong>zione. Ogni icona è già standar<strong>di</strong>zzata in base a ciò<br />
che deve rappresentare, quin<strong>di</strong> risulta essere estremamente intu<strong>it</strong>ivo l’uso del<br />
<strong>framework</strong>.<br />
Inoltre, l’uso del <strong>di</strong>agramma a blocchi garantisce l’aspetto cogn<strong>it</strong>ivo del flusso<br />
dei dati, proprio come viene sviluppato <strong>un</strong> co<strong>di</strong>ce all’interno <strong>di</strong> <strong>un</strong> qual<strong>un</strong>que<br />
IDE. Questo fornisce sia <strong>un</strong>’attenta leggibil<strong>it</strong>à del co<strong>di</strong>ce sia <strong>un</strong>a corretta<br />
<strong>per</strong>cezione comportamento logico dell’algor<strong>it</strong>mo che si sviluppa.<br />
Una rappresentazione iconica <strong>di</strong> questo genere favorisce <strong>un</strong> tipo <strong>di</strong><br />
programmazione attiva: i dati vengono manipolati <strong>di</strong>rettamente, e si ha la<br />
sensazione <strong>di</strong> implementare il co<strong>di</strong>ce anche se questo non è realmente così.<br />
Un linguaggio <strong>di</strong> programmazione iconica, come quelli classici, necess<strong>it</strong>a<br />
anche <strong>di</strong> <strong>un</strong> parser. Nel segu<strong>it</strong>o si descriverà tale oggetto.<br />
Inoltre, tale rappresentazione formula <strong>un</strong> meta linguaggio visuale, facilmente<br />
esportabile in qual<strong>un</strong>que altro linguaggio <strong>di</strong> programmazione classico. Così<br />
facendo, è possibile implementare qual<strong>un</strong>que linguaggio <strong>di</strong> programmazione<br />
oltre al C: C++, Pascal, Delphi, Php, Java, Javascript, Ruby, ecc. In quanto, il<br />
<strong>framework</strong> stesso costruisce anche il co<strong>di</strong>ce testuale dell’algor<strong>it</strong>mo che si sta<br />
costruendo.<br />
61
3.2 Sviluppo del linguaggio iconico dal p<strong>un</strong>to <strong>di</strong> vista concettuale<br />
Nel segu<strong>it</strong>o verranno forn<strong>it</strong>e le logiche <strong>di</strong> implementazione <strong>per</strong> lo <strong>sviluppo</strong> <strong>di</strong><br />
<strong>un</strong> linguaggio iconico. I concetti fondamentali sono<br />
Il flusso logico delle istruzioni <strong>per</strong> il linguaggio;<br />
La configurazione iconica rappresentante i principali costrutti;<br />
La rappresentazione visiva, in tempo reale, del co<strong>di</strong>ce <strong>di</strong> programmazione<br />
sviluppato durante la stesura del co<strong>di</strong>ce iconico;<br />
3.2.1 Implementazione concettuale del flusso<br />
Per fornire <strong>un</strong> flusso logico all’implementazione me<strong>di</strong>ante <strong>un</strong> linguaggio <strong>di</strong><br />
programmazione visuale, si è reso necessario stu<strong>di</strong>are su come gli IDE<br />
forniscono questa caratteristica. Generalmente, durante la stesura <strong>di</strong> <strong>un</strong> co<strong>di</strong>ce,<br />
gli ambienti <strong>di</strong> <strong>sviluppo</strong> seguono le definizioni e le istruzioni dall’alto verso il<br />
basso, partendo dall’inizio delle f<strong>un</strong>zioni o procedure gi<strong>un</strong>gendo alla fine delle<br />
stesse. Seguendo questa linea <strong>di</strong> principio, si è optato <strong>per</strong> lo stesso approccio<br />
fornendo <strong>un</strong> p<strong>un</strong>to <strong>di</strong> riferimento <strong>per</strong> ogni f<strong>un</strong>zione e procedura. Il p<strong>un</strong>to <strong>di</strong><br />
riferimento consiste in <strong>un</strong>a icona Start che cost<strong>it</strong>uisce il p<strong>un</strong>to <strong>di</strong> inizio. Da<br />
questa si “agganceranno” le icone seguendo <strong>un</strong> flusso che cost<strong>it</strong>uisce il co<strong>di</strong>ce<br />
della f<strong>un</strong>zione o procedura. Le icone verranno collegate me<strong>di</strong>ante degl’archi che<br />
cost<strong>it</strong>uiscono gli oggetti <strong>di</strong> collegamento del flusso. Questo garantisce la<br />
62
continu<strong>it</strong>à tra <strong>un</strong> costrutto ed <strong>un</strong> altro. Inoltre, questo <strong>per</strong>mette la realizzazione <strong>di</strong><br />
controlli sulle variabili, costanti, f<strong>un</strong>zioni e procedure, nel seguente modo:<br />
ogni costrutto (variabile, costante, f<strong>un</strong>zione e procedura) non può avere lo<br />
stesso nome <strong>di</strong> <strong>un</strong> altro costrutto se questo è utilizzato da <strong>un</strong> altro. L’ambiente <strong>di</strong><br />
<strong>sviluppo</strong> iconico, così, risale l<strong>un</strong>go gli archi <strong>per</strong> verificare quali nomi sono stati<br />
assegnati ad altri costrutti, impedendo ed ev<strong>it</strong>ando la ridefinizione <strong>di</strong> essi.<br />
I costrutti (f<strong>un</strong>zioni, procedure, case, if e le espressioni) hanno visibil<strong>it</strong>à <strong>di</strong><br />
quali altri costrutti possono utilizzare, guidando l’utente ad utilizzare i giusti<br />
costrutti e fornendo <strong>un</strong>a programmazione robusta del co<strong>di</strong>ce senza possibil<strong>it</strong>à <strong>di</strong><br />
errore. Ogni qual volta si deve inizializzare o mo<strong>di</strong>ficare <strong>un</strong> costrutto, questo<br />
esegue <strong>un</strong> controllo preventivo su quali altri costrutti può utilizzare fornendo<br />
allo sviluppatore <strong>un</strong> aiuto nello scegliere i giusti oggetti.<br />
La visualizzazione <strong>di</strong>agrammatica del co<strong>di</strong>ce fornisce <strong>un</strong> buon metodo <strong>per</strong><br />
comprendere il comportamento delle f<strong>un</strong>zioni. Il collegamento delle icone<br />
me<strong>di</strong>ante archi migliora la visibil<strong>it</strong>à concettuale garantendo il flusso e su come<br />
questo influisce nell’algor<strong>it</strong>mo. Così, ogni oggetto assolve <strong>un</strong> determinato<br />
comp<strong>it</strong>o nell’algor<strong>it</strong>mo e fornisce <strong>un</strong>a chiara visione del tutto.<br />
Esempio <strong>di</strong> collegamento<br />
63
Fig. 3.1 Esempio <strong>di</strong> collegamento tra Start ed <strong>un</strong>a variabile<br />
Inoltre, gli archi assumeranno <strong>un</strong> colore <strong>di</strong>verso a seconda del livello <strong>di</strong><br />
annidamento al quale si riferiscono. Sono stati defin<strong>it</strong>i 10 colori <strong>per</strong> gli archi,<br />
<strong>un</strong>o <strong>per</strong> ogni livello. I colori sono<br />
Bianco<br />
Rosso<br />
Verde<br />
Blu<br />
Argento<br />
Fucsia<br />
Giallo<br />
Verde acceso<br />
Verde acqua<br />
Porpora<br />
64
3.2.2 Rappresentazione visiva dei costrutti principali<br />
Nel segu<strong>it</strong>o verranno forn<strong>it</strong>e le modal<strong>it</strong>à <strong>di</strong> visualizzazione dei costrutti. Ogni<br />
costrutto ha <strong>un</strong>a sua icona ben defin<strong>it</strong>a. Le caratteristiche che<br />
contrad<strong>di</strong>stinguono le icone sono<br />
Colore del contorno<br />
Colore del riempimento dell’icona<br />
Forma dell’icona<br />
Testo contenuto nell’icona<br />
Creazione <strong>di</strong> <strong>un</strong>a immagine custom <strong>per</strong> le f<strong>un</strong>zioni<br />
Nel segu<strong>it</strong>o, <strong>per</strong> ogni caratteristica si fornirà la rappresentazione dei costrutti.<br />
3.2.2.1 Colore del contorno<br />
Il contorno delle icone è, generalmente <strong>di</strong>verso da costrutto a costrutto. Esso è<br />
importante, <strong>per</strong> fornire <strong>un</strong> primo impatto cogn<strong>it</strong>ivo circa la rappresentazione<br />
dell’oggetto e la memorizzazione del costrutto.<br />
L’icona dello Start ha <strong>un</strong> contorno <strong>di</strong> colore rosso. Questo poiché, essendo <strong>un</strong><br />
oggetto fondamentale <strong>per</strong> il flusso, è importante che risalti tra gli altri oggetti e<br />
si <strong>di</strong>versifichi istantaneamente.<br />
65
Le variabili, e le costanti, hanno eguale contorno. Il contorno <strong>di</strong>fferisce a<br />
seconda se il tipo è numerico <strong>di</strong>screto, numerico in virgola mobile o <strong>di</strong> tipo<br />
stringa. Il numerico <strong>di</strong>screto usa <strong>un</strong> colore blu, mentre quello in virgola mobile<br />
usa <strong>un</strong> colore <strong>di</strong> tipo arancione. Infine, il tipo stringa usa <strong>un</strong> colore fucsia.<br />
Questo <strong>per</strong>mette <strong>di</strong> <strong>di</strong>stinguere imme<strong>di</strong>atamente il tipo <strong>di</strong> dato che<br />
contrad<strong>di</strong>stingue la variabile o la costante.<br />
I cicli sono contrad<strong>di</strong>stinti da <strong>un</strong> contorno verde mare. Tra essi stessi, come si<br />
vedrà in segu<strong>it</strong>o, saranno contrad<strong>di</strong>stinti dal testo contenuto nell’icona..<br />
Il costrutto delle con<strong>di</strong>zioni, l’If, usa il giallo <strong>per</strong> il suo contorno.<br />
L’icona cost<strong>it</strong>uente il blocco <strong>di</strong> co<strong>di</strong>ce ha <strong>un</strong> contorno nero.<br />
I costrutti break, continue ed ex<strong>it</strong> usano lo stesso colore <strong>per</strong> il contorno, il<br />
colore olivastro. Essi si <strong>di</strong>stingueranno, come <strong>per</strong> i cicli, dal testo contenuto<br />
nell’icona.<br />
Il case userà <strong>un</strong> colore porpora <strong>per</strong> il contorno, mentre i vari casi, che da esso<br />
ne deriveranno, useranno <strong>un</strong> colore <strong>di</strong>verso a seconda del numero <strong>di</strong> case.<br />
Il costrutto return è contrad<strong>di</strong>stinto dal colore verde.<br />
Gli oggetti begin ed end, usano <strong>un</strong> colore che cambia a seconda del livello <strong>di</strong><br />
annidamento nei quali sono inser<strong>it</strong>i, ovvero il colore sarà coincidente al colore<br />
del flusso, questo <strong>per</strong> fornire <strong>un</strong>a migliore comprensione a quale annidamento<br />
appartengono e si riferiscono.<br />
L’assegnazione usa <strong>un</strong> contorno verde, ma sarà <strong>di</strong>fferenziata dal return <strong>per</strong><br />
mezzo della sua forma.<br />
Le f<strong>un</strong>zioni o procedure, avranno eguale forma come espresso più avanti, ma<br />
il colore del contorno sarà <strong>di</strong>verso: <strong>per</strong> le f<strong>un</strong>zioni si userà <strong>un</strong> colore viola,<br />
mentre <strong>per</strong> le procedure <strong>un</strong> colore blu.<br />
66
Inoltre, l’utente ha la facoltà <strong>di</strong> scegliere il colore del contorno <strong>per</strong> le f<strong>un</strong>zioni,<br />
defin<strong>it</strong>e da lui, <strong>di</strong> cui desidera impostare <strong>un</strong>a icona <strong>per</strong>sonale.<br />
Oltre al colore del contorno, si sottolinea che al fine <strong>di</strong> identificare l’icona<br />
selezionata il suo contorno <strong>di</strong>venta maggiormente spesso, <strong>per</strong> poi tornare<br />
normale quando viene deselezionata.<br />
3.2.2.2 Colore del riempimento<br />
Generalmente il colore <strong>di</strong> riempimento delle icone sarà uguale <strong>per</strong> tutte al<br />
bianco. Vi sono dei casi particolari elencati <strong>di</strong> segu<strong>it</strong>o<br />
L’icona <strong>di</strong>venta verde tenue quando il mouse vi passa <strong>di</strong> sopra, <strong>per</strong> poi<br />
tornare normale quando questo esce dal suo riquadro;<br />
L’icona assume <strong>un</strong> colore <strong>di</strong> riempimento azzurro tenue quando questa<br />
viene selezionata. Il suo colore tornerà nuovamente bianco quando l’oggetto<br />
verrà deselezionato.<br />
L’icona assume <strong>un</strong> colore grigio quando questa non è inizializzata o non<br />
contiene alc<strong>un</strong> co<strong>di</strong>ce.<br />
3.2.2.3 Forme delle icone<br />
Ogni icona userà <strong>un</strong>a forma <strong>di</strong>fferente. I costrutti che avranno uguale forma<br />
saranno <strong>di</strong>fferenziati dai colori dei contorni e dal testo che avranno all’interno.<br />
67
Lo Start ha <strong>un</strong>a forma rettangolare all<strong>un</strong>gata in larghezza ed i suoi bor<strong>di</strong> sono<br />
smussati. Questo, visivamente, oltre al suo contorno rosso cattura<br />
imme<strong>di</strong>atamente l’attenzione fornendo <strong>un</strong> chiaro p<strong>un</strong>to <strong>di</strong> riferimento <strong>per</strong><br />
l’inizio del flusso.<br />
Le variabili e le costanti hanno anch’esse <strong>un</strong>a forma rettangolare, all<strong>un</strong>gata in<br />
larghezza. Tuttavia, a <strong>di</strong>fferenza dello Start gli angoli sono spigolosi. Questa<br />
forma coincide con la f<strong>un</strong>zione intrinseca delle variabili e le costanti.<br />
Un <strong>di</strong>scorso <strong>di</strong>verso riguarda i cicli. Essi, concettualmente, forniscono <strong>un</strong><br />
p<strong>un</strong>to <strong>di</strong> interruzione al flusso dei dati, in quanto il flusso continuerà a<br />
proseguire solo dopo che verrà ripetuto più volte il blocco <strong>di</strong> co<strong>di</strong>ce a cui essi<br />
fanno riferimento. Inoltre, proprio <strong>per</strong>ché i cicli si riferiscono a porzioni <strong>di</strong><br />
co<strong>di</strong>ce <strong>di</strong> l<strong>un</strong>ghezza variabile, da poche righe <strong>di</strong> co<strong>di</strong>ce a enormi porzioni, si è<br />
scelto <strong>di</strong> utilizzare <strong>un</strong>a forma <strong>di</strong> <strong>un</strong> quadrato smussato. Inoltre, l’icona è più<br />
grande rispetto alle altre <strong>per</strong> evidenziare che dalle sue <strong>di</strong>ramazioni vi è <strong>un</strong><br />
ulteriore co<strong>di</strong>ce, quello <strong>it</strong>erato, <strong>di</strong> l<strong>un</strong>ghezza variabile.<br />
Per rendere più vicino il linguaggio iconico del <strong>framework</strong> al linguaggio dei<br />
<strong>di</strong>agrammi a blocchi, si è deciso <strong>di</strong> utilizzare <strong>per</strong> il costrutto If <strong>un</strong>a forma<br />
romboidale, in quanto esso ha la desiderabile proprietà visiva <strong>di</strong> fornire <strong>un</strong><br />
imme<strong>di</strong>ato senso delle possibili <strong>di</strong>ramazioni del concetto <strong>di</strong> ver<strong>it</strong>à o fals<strong>it</strong>à<br />
risultante dall’espressione che verifica.<br />
L’icona del blocco <strong>di</strong> co<strong>di</strong>ce usa <strong>un</strong>a forma quadrangolare, simile a quella dei<br />
cicli. Tuttavia, a <strong>di</strong>fferenza <strong>di</strong> essi, i suoi angoli sono spigolosi. Questo fornisce<br />
<strong>un</strong> senso <strong>di</strong> incapsulamento del co<strong>di</strong>ce, che è esattamente il concetto che si vuole<br />
rendere.<br />
68
I costrutti Break, Continue ed Ex<strong>it</strong> sono rappresentati da <strong>un</strong> cerchio. Ciò che li<br />
<strong>di</strong>fferenzia è lo stile del contorno. Generalmente, il cerchio, nell’immaginario<br />
collettivo, assume <strong>un</strong> concetto <strong>di</strong> continu<strong>it</strong>à <strong>di</strong> <strong>un</strong> ciclo, esattamente il concetto<br />
che fornisce il Continue. Il Break fornisce <strong>un</strong> concetto <strong>di</strong> interruzione senza,<br />
tuttavia, uscire dalla f<strong>un</strong>zione o procedura, <strong>per</strong> questo motivo si usa <strong>un</strong> contorno<br />
tratteggiato-p<strong>un</strong>to. Infine, l’Ex<strong>it</strong>, esprimendo <strong>un</strong> significato <strong>di</strong> usc<strong>it</strong>a da <strong>un</strong>a<br />
f<strong>un</strong>zione e quin<strong>di</strong> <strong>un</strong>’interruzione <strong>di</strong> tipo forte, si è scelto <strong>di</strong> usare <strong>un</strong> contorno<br />
tratteggiato.<br />
Il costrutto Sw<strong>it</strong>ch esprime <strong>un</strong> concetto <strong>di</strong> multi-opzional<strong>it</strong>à <strong>di</strong> <strong>un</strong>’espressione,<br />
le cui alternative spostano il flusso del programma verso <strong>un</strong>a relativa porzione <strong>di</strong><br />
co<strong>di</strong>ce. Queste considerazioni hanno influenzato l’ideazione della forma<br />
dell’icona portando all’uso <strong>di</strong> <strong>un</strong> rettangolo all<strong>un</strong>gato in altezza, che assume,<br />
figurativamente ed in maniera <strong>per</strong>tinente, la rappresentazione mentale espressa<br />
dal struttura sintattica.<br />
Il Return è quasi concettualmente l’opposto dello Start, in quanto è il p<strong>un</strong>to<br />
finale <strong>di</strong> ogni f<strong>un</strong>zione. Inoltre, il Return fornisce, in usc<strong>it</strong>a della f<strong>un</strong>zione, <strong>un</strong><br />
valore. Per tali considerazioni si è deciso <strong>di</strong> assumere la stessa forma dello Start<br />
con la <strong>di</strong>fferenza nel testo e nel colore del contorno.<br />
Il Begin e l’End usano la stessa forma dello Start, ma ne cambiano il testo e il<br />
contorno.<br />
L’Assegnazione usa <strong>un</strong> triangolo equilatero, con <strong>un</strong> vertice rivolto verso<br />
destra, così da esprimere il concetto <strong>di</strong> ‘inserimento’ all’interno <strong>di</strong> <strong>un</strong>a variabile.<br />
Le f<strong>un</strong>zioni o procedure usano <strong>un</strong>a forma rettangolare, con angoli spigolosi,<br />
poco più alta delle variabili, questo associa il loro richiamo anche al significato<br />
69
<strong>di</strong> <strong>un</strong> blocco <strong>di</strong> co<strong>di</strong>ce richiesto da altre parti del programma. La <strong>di</strong>fferenza tra le<br />
f<strong>un</strong>zioni e le procedure consiste nel contorno e nel testo<br />
Le f<strong>un</strong>zioni <strong>per</strong>sonalizzate potranno assumere la forma desiderata dall’utente o<br />
la stessa forma delle f<strong>un</strong>zioni o procedure. La <strong>di</strong>mensione massima in altezza e<br />
larghezza è lim<strong>it</strong>ata a 65 x 65 pixel. Nel caso in cui l’immagine su<strong>per</strong>i tali<br />
vincoli, questa verrà ri<strong>di</strong>mensionata ai lim<strong>it</strong>i. L’immagine, inoltre, deve essere<br />
nei seguenti formati: B<strong>it</strong>map, Jpeg o Icon.<br />
3.2.2.4 Testo delle icone<br />
Il testo delle icone è rappresentativo del costrutto che in<strong>di</strong>cano. Quasi tutte le<br />
icone usano il proprio tipo <strong>di</strong> costrutto come testo, eccetto alc<strong>un</strong>i casi.<br />
Le icone delle variabili e delle costanti in<strong>di</strong>cano se il dato è <strong>un</strong>a variabile o<br />
<strong>un</strong>a costante segu<strong>it</strong>o dal nome del dato.<br />
L’Etichetta assume il valore che le si fornisce.<br />
I casi dello Sw<strong>it</strong>ch..Case usano il testo delle varie opzioni in accordo al tipo <strong>di</strong><br />
espressione usato nello Sw<strong>it</strong>ch, così da offrire <strong>un</strong> imme<strong>di</strong>ato riscontro.<br />
L’Assegnazione usa come testo soltanto il nome della variabile al quale si<br />
assegna il risultato <strong>di</strong> <strong>un</strong>’espressione, in tale maniera risalterà istantaneamente<br />
su quale variabile si eseguirà l’o<strong>per</strong>azione<br />
Le icone delle f<strong>un</strong>zioni e procedure, quelle non <strong>per</strong>sonalizzate dall’utente,<br />
useranno il loro stesso nome, così da rendere agevole l’identificazione <strong>di</strong> esse.<br />
70
3.3 Esplic<strong>it</strong>azione del co<strong>di</strong>ce sorgente me<strong>di</strong>ante l’uso delle icone<br />
Come detto, durante la stesura del co<strong>di</strong>ce iconico, l’applicativo fornisce il<br />
co<strong>di</strong>ce sorgente che si sta implementando. Questo è visionabile in tempo reale,<br />
alla destra del co<strong>di</strong>ce iconico. Per eseguire questo si inserisce <strong>un</strong> oggetto che<br />
identifica <strong>un</strong> vero e proprio Text E<strong>di</strong>tor, con l’<strong>un</strong>ica <strong>di</strong>fferenza che viene<br />
<strong>di</strong>sabil<strong>it</strong>ata la facoltà <strong>di</strong> mo<strong>di</strong>ficare il co<strong>di</strong>ce sorgente <strong>di</strong>rettamente da questo<br />
oggetto. La co<strong>di</strong>fica inser<strong>it</strong>a in questa classe sfrutta il linguaggio XHTML, in<br />
quanto appropriato <strong>per</strong> nascondere vari elementi tag non necessari a chi usa il<br />
programma ma utili all’associazione tra gli elementi iconici e il sorgente<br />
visualizzato. Questo approccio, inoltre, fa si che sia possibile esportare il co<strong>di</strong>ce<br />
in versione HTML, oltre che classico, identificando i vari costrutti e le varie<br />
keyword.<br />
Ogni oggetto iconico fornisce <strong>un</strong> particolare co<strong>di</strong>ce associato ad esso. Così, le<br />
variabili e le costanti godono <strong>di</strong> <strong>un</strong>’inizializzazione e forniscono il co<strong>di</strong>ce <strong>per</strong><br />
inizializzarle. Se, ad esempio, si inserisce <strong>un</strong>’icona <strong>di</strong> <strong>un</strong>a costante, questa crea<br />
<strong>un</strong> co<strong>di</strong>ce <strong>di</strong> tipo “const int costante = 3”. L’icona <strong>di</strong> <strong>un</strong> ciclo For fornisce <strong>un</strong><br />
co<strong>di</strong>ce simile al seguente<br />
“for(k = 1, k
3.4 Integratore iconico con <strong>un</strong> Parser XML<br />
In informatica, il parsing o analisi sintattica è il processo atto ad analizzare<br />
<strong>un</strong>o stream continuo in input (letto <strong>per</strong> esempio da <strong>un</strong> file o <strong>un</strong>a tastiera) in<br />
modo da determinare la sua struttura grammaticale grazie ad <strong>un</strong>a data<br />
grammatica formale. Un parser è <strong>un</strong> programma che esegue questo comp<strong>it</strong>o.<br />
Tipicamente, il termine <strong>it</strong>aliano viene utilizzato <strong>per</strong> riferirsi al riconoscimento <strong>di</strong><br />
<strong>un</strong>a grammatica e alla conseguente costruzione <strong>di</strong> <strong>un</strong> albero sintattico, che<br />
mostra le regole utilizzate durante il riconoscimento dall'input; l'albero sintattico<br />
viene poi vis<strong>it</strong>ato (anche più volte) durante l'esecuzione <strong>di</strong> <strong>un</strong> interprete o <strong>di</strong> <strong>un</strong><br />
compilatore.<br />
Nella maggior parte dei linguaggi, tuttavia, l'analisi sintattica o<strong>per</strong>a su <strong>un</strong>a<br />
sequenza <strong>di</strong> token in cui l'analizzatore lessicale spezzetta l'input. Pertanto, il<br />
termine parser spesso viene usato <strong>per</strong> in<strong>di</strong>care l'insieme della analisi lessicale e<br />
della analisi sintattica vera e propria.<br />
I sorgenti <strong>di</strong> <strong>un</strong> linguaggio iconico devono essere salvati e caricati come<br />
negl’altri linguaggi <strong>di</strong> programmazione. Ciò significa che si devono creare dei<br />
file <strong>per</strong> questi linguaggi. Per realizzare tali sorgenti è necessario <strong>di</strong>versificare e<br />
quin<strong>di</strong> realizzare <strong>un</strong> parser che <strong>di</strong>versifichi ogni oggetto dagl’altri, secondo le<br />
caratteristiche <strong>di</strong> questi. Si è scelto <strong>di</strong> utilizzare, quale parser, <strong>un</strong>a classe <strong>di</strong><br />
oggetti, opport<strong>un</strong>amente mo<strong>di</strong>ficata, che sfrutta la semplic<strong>it</strong>à e la potenza del<br />
linguaggio XML.<br />
Inoltre, tale approccio fornisce <strong>un</strong>a forte robustezza ai dati, ev<strong>it</strong>ando <strong>di</strong><br />
generare errori <strong>di</strong> analisi del parser<br />
72
3.5 In<strong>di</strong>cizzatore <strong>di</strong> librerie generiche<br />
Per fornire <strong>un</strong> uso anche dei linguaggi non iconici, sono state implementate<br />
delle classi e delle interfacce che incapsulano le f<strong>un</strong>zioni <strong>di</strong> <strong>un</strong>a libreria <strong>di</strong> Perl,<br />
anche detto Practical Extraction and Report Language. Sebbene, tali classi ed<br />
interfacce possano essere utili ad implementare <strong>un</strong> parser completo, è stato<br />
necessario, <strong>per</strong> l’implementazione dell’applicativo, fornire loro solo la capac<strong>it</strong>à<br />
<strong>di</strong> poter recu<strong>per</strong>are i prototipi da <strong>un</strong> testo in linguaggio C. Tali classi sono<br />
riutilizzabili anche <strong>per</strong> implementazioni future e <strong>per</strong> integrare ulteriori linguaggi.<br />
Per implementare tale in<strong>di</strong>cizzatore si sono incapsulate, all’interno <strong>di</strong> tale classi<br />
e interfacce, le regular expression.<br />
3.5.1 Regular Expression<br />
Le Regular expressions, o espressioni regolari anche dette regex sono dei<br />
linguaggi <strong>per</strong> descrivere la “forma” o la “sintassi” <strong>di</strong> <strong>un</strong>a stringa (<strong>un</strong>a stringa è<br />
<strong>un</strong> testo qual<strong>un</strong>que, <strong>di</strong> qual<strong>un</strong>que l<strong>un</strong>ghezza, <strong>un</strong>a sequenza <strong>di</strong> caratteri). Con<br />
esso si possono effettuare ricerche, e quin<strong>di</strong> sost<strong>it</strong>uzioni, molto complesse!<br />
Verificare che <strong>un</strong> testo sia conforme ad alc<strong>un</strong>e caratteristiche e segue <strong>un</strong>a certa<br />
sintassi, ad esempio verificare se <strong>un</strong> testo è <strong>un</strong> in<strong>di</strong>rizzo email o <strong>un</strong> url valido.<br />
Talvolta le regex hanno piccole <strong>di</strong>fferenze tra <strong>un</strong> programma e l’altro o tra <strong>un</strong><br />
linguaggio <strong>di</strong> programmazione ed <strong>un</strong> altro ma il loro concetto ed utilizzo resta lo<br />
stesso.<br />
73
Le espressioni regolari sono composte da costanti e o<strong>per</strong>atori che denotano<br />
insiemi <strong>di</strong> stringhe, e da o<strong>per</strong>azioni tra questi insiemi.<br />
Dato <strong>un</strong> alfabeto fin<strong>it</strong>o, sono defin<strong>it</strong>e le seguenti costanti:<br />
1. o , insieme vuoto<br />
2. , stringa vuota, ovvero la stringa <strong>di</strong> l<strong>un</strong>ghezza 0<br />
3. , carattere,<br />
e le seguenti o<strong>per</strong>azioni:<br />
1. concatenazione: RS o in<strong>di</strong>ca l'insieme<br />
2. <strong>un</strong>ione: in<strong>di</strong>ca l'<strong>un</strong>ione dei due insiemi<br />
3. stella <strong>di</strong> Kleene: in<strong>di</strong>ca l'insieme che contiene tutte le possibili<br />
<strong>it</strong>erazioni ottenibili dagli elementi <strong>di</strong> R<br />
4. intersezione: in<strong>di</strong>ca l'intersezione tra i due insiemi <strong>di</strong> stringhe<br />
5. complemento: il complementare <strong>di</strong> R in<strong>di</strong>ca l'insieme delle stringhe<br />
appartenenti a<br />
Ad esempio dati e , e<br />
Allora, possiamo <strong>di</strong>re che <strong>un</strong>'espressione regolare, defin<strong>it</strong>a a partire da <strong>un</strong><br />
alfabeto ed <strong>un</strong> insieme <strong>di</strong> simboli , è <strong>un</strong>a<br />
stringa che rende vera alc<strong>un</strong>a delle seguenti<br />
con<strong>di</strong>zioni:<br />
74
1.<br />
2.<br />
3. o o , dove S e T sono espressioni regolari<br />
sull'alfabeto<br />
Le espressioni regolari sono utilizzate principalmente da e<strong>di</strong>tor <strong>di</strong> testo <strong>per</strong> la<br />
ricerca e la sost<strong>it</strong>uzione <strong>di</strong> porzioni del testo. Grande importanza rivestono<br />
inoltre nell'informatica teorica, nella quale, ad esempio, sono utilizzate <strong>per</strong><br />
rappresentare tutti i possibili cammini su <strong>un</strong> grafo. Tuttavia, le espressioni<br />
regolari sono adatte a rappresentare <strong>un</strong> ristrettissimo insieme <strong>di</strong> linguaggi<br />
formali (se volessimo rappresentare espressioni ar<strong>it</strong>metiche o linguaggi <strong>di</strong><br />
programmazione, avremmo già bisogno <strong>di</strong> utilizzare linguaggi <strong>di</strong> tipo 2):<br />
l'utilizzo dei linguaggi regolari è com<strong>un</strong>que conveniente, in quanto la chiusura<br />
degli stessi alle o<strong>per</strong>azioni <strong>di</strong> <strong>un</strong>ione, intersezione e complementazione,<br />
<strong>per</strong>mettono la costruzione <strong>di</strong> <strong>un</strong>'algebra <strong>di</strong> Boole ed <strong>un</strong>a buona capac<strong>it</strong>à<br />
decisionale.<br />
La maggior parte dei programmi che utilizzano le RegExp usano tali regole <strong>di</strong><br />
base fornendo al contempo supporto <strong>per</strong> le nuove regole estese.<br />
In questa sintassi, la maggior parte dei caratteri sono visti come letterali, e<br />
trovano solo se stessi. Ad esempio: "a" trova "a"; "bc)" trova "bc)"; ecc. Le<br />
eccezioni a questa regola sono i metacaratteri:<br />
75
. Trova <strong>un</strong> singolo carattere se è nella modal<strong>it</strong>à linea singola,<br />
altrimenti se è in multiriga prende tutti i caratteri <strong>di</strong>versi da \n, ovvero <strong>un</strong> r<strong>it</strong>orno<br />
a capo.<br />
[ ] Trova <strong>un</strong> singolo carattere contenuto nelle parentesi.<br />
Il carattere '-' è letterale solo se è primo o ultimo carattere nelle parentesi:<br />
[abc-] o [-abc]. Per trovare <strong>un</strong> carattere '[' o ']', il modo più semplice è metterli<br />
primi all'interno delle parentesi: [][ab] trova ']', '[', 'a' o 'b'.<br />
[^ ] Trova ogni singolo carattere non incluso nelle parentesi.<br />
^ Corrisponde all'inizio della stringa o <strong>di</strong> ogni riga della stringa,<br />
quando usato in modal<strong>it</strong>à multi linea.<br />
$ Corrisponde alla fine della stringa o alla posizione imme<strong>di</strong>atamente<br />
precedente <strong>un</strong> carattere <strong>di</strong> nuova linea, o alla fine <strong>di</strong> ogni riga della stringa,<br />
quando usato in modal<strong>it</strong>à multi linea.<br />
( ) Definisce <strong>un</strong>a "sottoespressione marcata". Il risultato <strong>di</strong> ciò che è<br />
incluso nell'espressione, può essere richiamato in segu<strong>it</strong>o.<br />
\n Dove n è <strong>un</strong>a cifra da 1 a 9; trova ciò che la nesima sottoespressione<br />
ha trovato. Tale costrutto, detto backreference, estende le potenzial<strong>it</strong>à delle<br />
RegExp oltre i linguaggi regolari e non è stato adottato nella sintassi estesa delle<br />
RegExp.<br />
Sono state defin<strong>it</strong>e varie categorie <strong>di</strong> caratteri, come mostrato nella seguente<br />
tabella, che identificano <strong>un</strong> insieme generico <strong>di</strong> caratteri.<br />
76
Sintassi normale Significato<br />
[A-Z] lettere maiuscole<br />
[a-z] lettere minuscole<br />
[A-Za-z] lettera sia maiuscole che minuscole<br />
[A-Za-z0-9] numeri e lettere maiuscole e minuscole<br />
[0-9] numeri<br />
[0-9A-Fa-f] numeri in formato esadecimale<br />
[.,!?:...] segni <strong>di</strong> interp<strong>un</strong>zione<br />
[ \t] spazio o TAB<br />
Tabella 3.1 Tabella <strong>di</strong> alc<strong>un</strong>e categorie <strong>di</strong> caratteri che identificano insiemi <strong>di</strong> stringhe<br />
Inoltre, esistono i quantificatori e gli alias. Entrambi forniscono <strong>un</strong> utile<br />
supporto al riconoscimento delle stringhe.<br />
I quantificatori servono ad in<strong>di</strong>care la quant<strong>it</strong>à <strong>di</strong> volte che deve essere<br />
ripetuto <strong>un</strong> insieme <strong>di</strong> stringhe:<br />
Quantificatore Significato RegExp<br />
? zero o 1 abc?<br />
* zero o più abc*<br />
+ <strong>un</strong>o o più abc+<br />
{n} esattamente n volte abc{2}<br />
{n,m} da n a m volte abc{2,3}<br />
Tabella 3.2 Elenco dei quantificatori e loro significati<br />
77
Gli alias sono scorciatoie de<strong>di</strong>cate alle categorie <strong>di</strong> caratteri più usati,e quin<strong>di</strong><br />
li sost<strong>it</strong>uiscono:<br />
ALIAS SIGNIFICATO COORRISPONDE A<br />
\d <strong>di</strong>g<strong>it</strong> (numero) [0-9]<br />
\w word (parola) [a-zA-Z0-9_] Include il carattere <strong>un</strong>derscore<br />
\s spazio, tab o newline [ \t\r\n]<br />
\D qualsiasi non numerico ^\d<br />
\W quasiasi non alfanumerico ^\w<br />
\S quasiasi ma non lo spazio ^\s<br />
Tabella 3.3 Alias e loro corrispettivi<br />
3.6 <strong>Analisi</strong> finale<br />
Si sono analizzate le principali caratteristiche del <strong>framework</strong> e<br />
dell’applicativo, fornendone <strong>un</strong>a chiara visione degli aspetti concettuali. Si è<br />
<strong>di</strong>scusso anche delle caratteristiche <strong>di</strong> integrazione con dei parser <strong>per</strong> il<br />
salvataggio e il recu<strong>per</strong>o dei dati, nonché <strong>per</strong> il re<strong>per</strong>imento <strong>di</strong> f<strong>un</strong>zioni <strong>di</strong><br />
librerie scr<strong>it</strong>te in linguaggio C.<br />
Nel successivo cap<strong>it</strong>olo si <strong>di</strong>scuterà dell’implementazione delle icone e delle<br />
rispettive classi, nonché del Text E<strong>di</strong>tor e dell’integratore del parser XML e<br />
78
delle classi che recu<strong>per</strong>ano i prototipi delle librerie e delle procedure e f<strong>un</strong>zioni<br />
più importanti dell’applicativo.<br />
79
Cap<strong>it</strong>olo IV<br />
IMPLEMENTAZIONE DEL LINGUAGGIO<br />
ICONICO DI PROGRAMMAZIONE<br />
4.1 Sviluppo del Linguaggio<br />
Per la realizzazione del <strong>framework</strong>, è stato utilizzato, quale linguaggio <strong>di</strong><br />
programmazione, il Delphi, versione XE. Delphi è sia <strong>un</strong> linguaggio <strong>di</strong><br />
programmazione che <strong>un</strong> ambiente <strong>di</strong> <strong>sviluppo</strong>. Come linguaggio, è<br />
<strong>un</strong>’estensione del Pascal verso la programmazione orientata agli oggetti (Object<br />
Oriented Programming).<br />
Si è fatto <strong>un</strong> uso intensivo dei para<strong>di</strong>gmi <strong>di</strong> ere<strong>di</strong>tarietà e polimorfismo delle<br />
classi e degli oggetti, oltre ad alc<strong>un</strong>e tecniche avanzate <strong>di</strong> programmazione<br />
<strong>di</strong>sponibili sul sistema <strong>di</strong> <strong>sviluppo</strong>.<br />
80
4.1.1 Cenni sull’ere<strong>di</strong>tarietà e sul polimorfismo<br />
I vari linguaggi <strong>di</strong> programmazione <strong>di</strong> alto livello forniscono classi ed oggetti.<br />
Come strumenti <strong>di</strong> <strong>sviluppo</strong>. Gli oggetti, anche detti componenti o controlli,<br />
sono delle classi specializzate nella visualizzazione <strong>di</strong> varie forme, le quali<br />
forniscono all’utente <strong>un</strong>’interfaccia <strong>di</strong> com<strong>un</strong>icazione Uomo-Macchina <strong>per</strong><br />
interagire con l’applicativo. Esempi <strong>di</strong> componenti sono i bottoni, le etichette, le<br />
varie forme checkbox, ecc. Esempi <strong>di</strong> controlli sono le immagini, le progress<br />
bar, ecc.<br />
Questi sono caratterizzati da proprietà quali ere<strong>di</strong>tarietà e polimorfismo.<br />
L’ere<strong>di</strong>tarietà consiste nel creare <strong>un</strong>a classe B partendo da <strong>un</strong>’altra classe A. Se<br />
la classe A possiede <strong>un</strong> insieme <strong>di</strong> proprietà e f<strong>un</strong>zioni, la classe B ere<strong>di</strong>tà le<br />
stesse caratteristiche. Questa è <strong>un</strong>a tecnica tanto utile quanto potente, in quanto<br />
<strong>per</strong>mette <strong>un</strong>a veloce stesura del co<strong>di</strong>ce concentrandosi su alc<strong>un</strong>i aspetti chiave<br />
quali le proprietà, le f<strong>un</strong>zioni e i comportamenti che tutte le classi avranno se<br />
<strong>di</strong>ventassero figlie <strong>di</strong> <strong>un</strong>a classe rispetto ad altre.<br />
Il polimorfismo è <strong>un</strong>a conseguenza dell’aggi<strong>un</strong>zione <strong>di</strong> <strong>un</strong>a o più proprietà,<br />
f<strong>un</strong>zioni o caratteristiche ad <strong>un</strong>a classe che ne ha ere<strong>di</strong>tate altre da <strong>un</strong>a classe<br />
gen<strong>it</strong>rice. Verrà qui <strong>di</strong> segu<strong>it</strong>o si fornisce <strong>un</strong> esempio classico <strong>per</strong> spiegare<br />
l’ere<strong>di</strong>tarietà e il polimorfismo. Si può creare <strong>un</strong>a classe chiamata “Animale” ed<br />
assegnare ad essa delle proprietà quali “Zampe” e “Coda”. E’ possibile creare<br />
due altre classi “Cane” e “Gatto” che sono derivate dalla classe Animale, e<br />
d<strong>un</strong>que ere<strong>di</strong>tano le proprietà anzidette. Tuttavia, è possibile <strong>di</strong>versificare tali<br />
classi introducendo la f<strong>un</strong>zione “Sco<strong>di</strong>nzola” alla classe Cane e la f<strong>un</strong>zione<br />
81
“Miagola” alla classe Gatto. E’ indubbio che le due classi ere<strong>di</strong>tano le proprietà<br />
della classe Animale, ma creano <strong>un</strong> polimorfismo in quanto esse si <strong>di</strong>versificano<br />
dalla prima e tra <strong>di</strong> loro.<br />
4.1.2 Cenni <strong>di</strong> caratteristiche avanzate del linguaggio Delphi<br />
In Delphi è possibile implementare Eventi e caratteristiche particolari delle<br />
proprietà.<br />
Le proprietà in delphi possono essere semplici variabili o possono avere della<br />
caratteristiche più complesse. Di segu<strong>it</strong>o alc<strong>un</strong>i esempi<br />
1. Pro<strong>per</strong>ty Variabile;<br />
2. Pro<strong>per</strong>ty Variabile: string Read FVariabile;<br />
3. Pro<strong>per</strong>ty Variabile: string Wr<strong>it</strong>e FVariabile;<br />
4. Pro<strong>per</strong>ty Variabile: string Read GetVariabile;<br />
5. Pro<strong>per</strong>ty Variabile: string Wr<strong>it</strong>e SetVariabile;<br />
6. Pro<strong>per</strong>ty Variabile: string Read GetVariabile Wr<strong>it</strong>e SetVariabile;<br />
Il primo esempio, il quale non <strong>di</strong>chiara il tipo, viene utilizzato, generalmente,<br />
<strong>per</strong> mo<strong>di</strong>ficare la visibil<strong>it</strong>à <strong>di</strong> <strong>un</strong> campo ere<strong>di</strong>tato da <strong>un</strong>a classe gen<strong>it</strong>rice.<br />
Il secondo, <strong>di</strong>chiara <strong>un</strong>a variabile <strong>di</strong> tipo string che è possibile soltanto leggere<br />
e non scrivere. Questo approccio si usa tipicamente <strong>per</strong> ottenere <strong>un</strong>o stato<br />
interno <strong>di</strong> <strong>un</strong>a classe leggendo <strong>un</strong> campo incapsulato alla classe e non<br />
mo<strong>di</strong>ficabile dall’esterno <strong>di</strong> essa, ma usato solo dalla classe stessa.<br />
82
Il terzo esempio, <strong>per</strong>mette <strong>di</strong> scrivere soltanto in <strong>un</strong>a variabile interna,<br />
generalmente utilizzato in combinazione con altri esempi sopra riportati.<br />
Il quarto approccio <strong>di</strong>chiara <strong>un</strong>a Variabile <strong>di</strong> tipo stringa la quale è il risultato<br />
<strong>di</strong> <strong>un</strong>a f<strong>un</strong>zione dello stesso tipo. Viene utilizzato, generalmente, <strong>per</strong> fornire <strong>un</strong><br />
risultato in accordo ad alc<strong>un</strong>e variabili e comportamenti in cui la classe si trova e<br />
non è possibile mo<strong>di</strong>ficare il suo contenuto. Questo è <strong>un</strong> caso <strong>di</strong><br />
programmazione degli oggetti fortemente incapsulata e che implementa delle<br />
proprietà denominate “fake” o “false”, poiché si ha l’illusione <strong>di</strong> leggere<br />
<strong>di</strong>rettamente da campi interni, mentre in realtà ciò non avviene.<br />
Il quinto approccio, che è la combinazione del quarto e quinto esempio,<br />
<strong>di</strong>chiara <strong>un</strong>a variabile <strong>di</strong> tipo stringa la quale in lettura, fornisce il risultato <strong>di</strong><br />
<strong>un</strong>a f<strong>un</strong>zione ed in scr<strong>it</strong>tura memorizza <strong>di</strong>rettamente il valore in <strong>un</strong> campo<br />
incapsulato. Questo approccio è utilizzato in particolari contesti quando non si<br />
vuole <strong>per</strong>mettere allo sviluppatore <strong>di</strong> interagire <strong>di</strong>rettamente con il campo<br />
privato della classe, ma solo in accordo a ciò che le f<strong>un</strong>zioni implementano.<br />
Ovviamente, i precedenti casi possono essere combinati, come nel quinto<br />
esempio.<br />
4.1.3 Gli Eventi<br />
Gli Eventi altro non sono che proprietà particolari degli oggetti <strong>di</strong>chiarati<br />
come Tipi. Ad esempio, il tipo<br />
83
Type TNotifyEvent = procedure(Sender: TObject) of object;<br />
crea <strong>un</strong>a proprietà <strong>di</strong> tipo TNotifyEvent <strong>di</strong>chiarato come <strong>un</strong>a procedura <strong>di</strong> <strong>un</strong><br />
oggetto che ammette <strong>un</strong> parametro TObject, ovvero <strong>un</strong>a classe dal quale tutti i<br />
controlli e i componenti derivano. Gli eventi, d<strong>un</strong>que, vengono chiamati in base<br />
ad alc<strong>un</strong>e implementazioni delle classi che rispondono a particolari Messaggi<br />
inviati dai sistemi o<strong>per</strong>ativi all’applicazione o ad alc<strong>un</strong>e mo<strong>di</strong>fiche sull’istanza<br />
<strong>di</strong> <strong>un</strong>a classe. A seconda del tipo <strong>di</strong> messaggio ricevuto e se l’evento della classe<br />
istanziata p<strong>un</strong>ta ad <strong>un</strong>a procedura <strong>di</strong> tipo TNotifyEvent implementata allora la<br />
classe richiama la procedura stessa. Questo determina alc<strong>un</strong>i comportamenti che<br />
sono forn<strong>it</strong>i alla classe in fase <strong>di</strong> <strong>sviluppo</strong> e che possono essere mo<strong>di</strong>ficati in fase<br />
<strong>di</strong> esecuzione dell’applicativo.<br />
4.1.4 Sovrascr<strong>it</strong>tura delle f<strong>un</strong>zioni e procedure ere<strong>di</strong>tate<br />
Come già detto, quando <strong>un</strong>a classe deriva da <strong>un</strong>’altra classe la prima ere<strong>di</strong>ta<br />
tutte le caratteristiche, le proprietà, i meto<strong>di</strong> e i comportamenti della seconda<br />
classe. In alc<strong>un</strong>i contesti, soprattutto nei casi <strong>di</strong> polimorfismo, alc<strong>un</strong>i meto<strong>di</strong><br />
vengono sovrascr<strong>it</strong>ti con la keyword “Override”. Ciò <strong>per</strong>mette <strong>di</strong> richiamare<br />
<strong>un</strong>ivocamente la nuova procedura e la chiama. In altri contesti, la nuova<br />
procedura viene creata semplicemente <strong>per</strong> inserire alc<strong>un</strong>i comportamenti<br />
aggi<strong>un</strong>tivi, anziché mo<strong>di</strong>ficarne altri. Ad esempio, se la classe A è <strong>di</strong>chiarata nel<br />
seguente modo<br />
84
Type Classe_A = class<br />
Public<br />
End;<br />
Variabile: String;<br />
Procedure Scrivi;<br />
Procedure Paint(X,Y: Integer);<br />
la classe B la si può <strong>di</strong>chiarare nel seguente modo<br />
Type Classe_B = class(Classe_A)<br />
Public<br />
End;<br />
Procedure Paint(X,Y: Integer); override;<br />
Con questa <strong>di</strong>chiarazione <strong>di</strong> classe, facciamo sì che la classe B sovrascriva la<br />
procedura Paint(X,Y: Integer) soltanto se viene richiamata dalla classe B. E’<br />
utile notare che la Classe_B ere<strong>di</strong>ta sia Variabile che la procedura Scrivi in<br />
quanto la classe è derivata dalla Classe_A e non necess<strong>it</strong>a <strong>di</strong> <strong>di</strong>chiarare<br />
nuovamente sia la variabile che la procedura. Com<strong>un</strong>que, è possibile, tuttavia,<br />
recu<strong>per</strong>are l’intera procedura della classe ere<strong>di</strong>tata qualora si inserisca nella<br />
procedura Paint della classe B la <strong>di</strong>c<strong>it</strong>ura “Inher<strong>it</strong>ed”. Il seguente esempio è<br />
chiarificatore<br />
85
Procedure Classe_B.Paint(X,Y: Integer);<br />
begin<br />
Inher<strong>it</strong>ed Paint(X,Y);<br />
…<br />
End;<br />
così scrivendo è possibile recu<strong>per</strong>are la procedura della classe ere<strong>di</strong>tata ed è<br />
possibile estenderla inserendo ulteriore co<strong>di</strong>ce sost<strong>it</strong>uendolo ai p<strong>un</strong>tini e senza<br />
andare a mo<strong>di</strong>ficare la classe gen<strong>it</strong>rice. Come si evince, questa capac<strong>it</strong>à del<br />
linguaggio è molto utile nei casi <strong>di</strong> polimorfismo dove <strong>un</strong>a classe deriva da <strong>un</strong>a<br />
classe base sulla quale vengono implementate alc<strong>un</strong>e caratteristiche e<br />
comportamenti che devono essere com<strong>un</strong>i a tutte le classi che ne derivano.<br />
4.1.5 Visibil<strong>it</strong>à delle proprietà e meto<strong>di</strong> e semplici tecniche <strong>di</strong><br />
Hacking<br />
Nelle classi, le proprietà e i meto<strong>di</strong> hanno <strong>un</strong>a caratteristica denominata<br />
visibil<strong>it</strong>à. Questa rende visibile le proprietà e i meto<strong>di</strong> che possono essere<br />
visualizzati da altri files che compongono l’applicativo. Le visibil<strong>it</strong>à, nel<br />
linguaggio Delphi, sono quattro: Private, Protected, Public e Published.<br />
Si vuole in<strong>di</strong>care con Private quelle variabili, f<strong>un</strong>zioni e procedure che<br />
generalmente sono da ausilio alla classe in sé e che comportano<br />
86
l’implementazione interna della classe, ma non alle classe che derivano da<br />
questa.<br />
Con la keyword Protected, si intende specificare che i campi, le proprietà e i<br />
meto<strong>di</strong>, <strong>di</strong>chiarati in questo modo, possono essere visualizzabili soltanto dalla<br />
classe che le implementa e dalle classi che ne derivano, su quest’ultime attuando<br />
<strong>un</strong>a tecnica <strong>di</strong> Hacking sulla classe gen<strong>it</strong>rice.<br />
Con la <strong>di</strong>c<strong>it</strong>ura Public, si intende rendere pubbliche quei campi, meto<strong>di</strong> e<br />
proprietà ai files esterni all’implementazione della classe e tutte le altre classi<br />
che non derivano dalla classe implementante.<br />
Con la <strong>di</strong>c<strong>it</strong>ura Published, si fornisce all’ambiente <strong>di</strong> <strong>sviluppo</strong> Delphi, la<br />
capac<strong>it</strong>à <strong>di</strong> poter mo<strong>di</strong>ficare alc<strong>un</strong>e caratteristiche della classe nella fase <strong>di</strong><br />
Design Time dell’implementazione <strong>di</strong> <strong>un</strong> generico programma.<br />
Per l’applicativo della tesi, si sono utilizzate le visibil<strong>it</strong>à Private, Protected e<br />
Public.<br />
In alc<strong>un</strong>i contesti è in<strong>di</strong>spensabile usare delle tecniche particolari del<br />
linguaggio Delphi, quelle <strong>di</strong> hacking, <strong>per</strong> recu<strong>per</strong>are alc<strong>un</strong>i campi o mo<strong>di</strong>ficare<br />
alc<strong>un</strong>i meto<strong>di</strong>, durante la fase <strong>di</strong> <strong>sviluppo</strong> del programma, <strong>per</strong> rendere accessibili<br />
classi non visibili. Se, ad esempio, <strong>un</strong>a classe A <strong>di</strong>chiara <strong>un</strong>a variabile come<br />
Private come segue<br />
Type Classe_A = class<br />
Private<br />
Variabile: Integer;<br />
end;<br />
87
l’<strong>un</strong>ico modo <strong>di</strong> rendere accessibile tale variabile è quello <strong>di</strong> derivare <strong>un</strong>a<br />
classe da Classe_A e <strong>di</strong> <strong>di</strong>chiarare la Variabile in maniera Public. Il<br />
proce<strong>di</strong>mento è mostrato come segue<br />
Type Classe_B = class(Classe_A)<br />
Public<br />
Variabile: Integer;<br />
end;<br />
Per utilizzare, d<strong>un</strong>que, la Variabile è necessario eseguire <strong>un</strong> Type Casting<br />
sulla classe derivante. Quin<strong>di</strong>, avendo derivato <strong>un</strong>a Classe_C dalla Classa_A, la<br />
tecnica <strong>di</strong> hacking, <strong>per</strong> mo<strong>di</strong>ficare la Variabile, prende la seguente forma<br />
Classe_B(Classe_C).Variabile := 10;<br />
Con questa tecnica, si rende rendono visibili alc<strong>un</strong>i campi e meto<strong>di</strong> importanti<br />
<strong>per</strong> l’implementazione delle classi, eseguendo <strong>un</strong>a corretta e buona<br />
incapsulazione delle classi, senza stravolgere le classi e senza rendere insicuro il<br />
comportamento <strong>di</strong> queste.<br />
Per l’implementazione del programma si è reso necessario utilizzare tale<br />
caratteristica del linguaggio in alc<strong>un</strong>i contesti.<br />
88
4.2 Implementazione del Framework Iconico<br />
Per la rappresentazione iconica del <strong>framework</strong>, si sono creati alc<strong>un</strong>i oggetti.<br />
Questi oggetti sono classi che derivano da <strong>un</strong>’altra classe base defin<strong>it</strong>a TForme,<br />
la quale deriva da <strong>un</strong>’altra classe TGraphicControl che fornisce quelle che<br />
vengono defin<strong>it</strong>e “Regioni” dove poter <strong>di</strong>segnare le varie icone e fornisce <strong>un</strong>a<br />
serie <strong>di</strong> strumenti, <strong>per</strong> la realizzazione dei <strong>di</strong>segni, defin<strong>it</strong>i in <strong>un</strong>a sua classe,<br />
incapsulata, chiamata Canvas.<br />
Nel segu<strong>it</strong>o si fornisce la definizione ed <strong>un</strong>a descrizione delle caratteristiche<br />
rilevanti delle varie classi implementate <strong>per</strong> il <strong>framework</strong>.<br />
4.2.1 Classe TForme<br />
Di segu<strong>it</strong>o vengono forn<strong>it</strong>e la descrizione e le principali parti della classe<br />
TForme.<br />
TForme = class(TGraphicControl)<br />
private<br />
FPen: TPen;<br />
FBrush: TBrush;<br />
FEtichetta: TLabel;<br />
FShape: TForma;<br />
FCaption: String;<br />
FonUserDraw: TonUserDraw;<br />
FbyUser: boolean;<br />
FCo<strong>di</strong>ce: String;<br />
FEtichetta_Visibile: Boolean;<br />
89
FLivello_Annidamento: Integer;<br />
FColore_Bordo: TColor;<br />
FSelezionato: Boolean;<br />
procedure DrawEllipse;<br />
procedure DrawRectangle;<br />
procedure DrawRo<strong>un</strong>dRect;<br />
procedure DrawArrow;<br />
procedure SetCaption(const Value: String);<br />
procedure DrawText;<br />
procedure DoUserDraw;<br />
procedure SetLivello_Annidamento(const Value: Integer);<br />
procedure SetColore_Bordo(const Value: TColor);<br />
procedure SetSelezionato(const Value: Boolean);<br />
procedure SettaEtichetta(Value: TLabel);<br />
protected<br />
procedure Paint; override;<br />
public<br />
FEtichetta: TLabel;<br />
Connessioni: array[Low(TLati)..High(TLati)] of Tpoint;<br />
Baricentro: TPoint;<br />
Connessioni_Precedenti:array of TForme;<br />
Connessioni_Post:array of TForme;<br />
Connessioni_Trasversali_Precedenti: array of TForme;<br />
Connessioni_Trasversali_Post: array of TForme;<br />
Linkers: array of TLinker;<br />
Nome : String;<br />
Colore_Bordo_Default: TColor;<br />
constructor Create(AOwner: TComponent); override;<br />
destructor Destroy; override;<br />
procedure Calcola_Dati;<br />
pro<strong>per</strong>ty Canvas;<br />
pro<strong>per</strong>ty Colore_Bordo: TColor read FColore_Bordo wr<strong>it</strong>e SetColore_Bordo;<br />
pro<strong>per</strong>ty Selezionato: Boolean read FSelezionato wr<strong>it</strong>e SetSelezionato;<br />
pro<strong>per</strong>ty Co<strong>di</strong>ce: String read FCo<strong>di</strong>ce wr<strong>it</strong>e SetCo<strong>di</strong>ce;<br />
pro<strong>per</strong>ty Etichetta: TLabel read FEtichetta wr<strong>it</strong>e SettaEtichetta;<br />
90
pro<strong>per</strong>ty Livello_Annidamento: Integer read FLivello_Annidamento wr<strong>it</strong>e<br />
SetLivello_Annidamento;<br />
procedure In<strong>di</strong>vidua_Linker_Partenza(var Linker:TLinker; Destinazione:TForme);<br />
procedure In<strong>di</strong>vidua_Linker_Arrivo(var Linker:TLinker; Arrivo:TForme);<br />
procedure Collega_Avanti(var Destinazione: TForme);<br />
procedure Scollega_Avanti;<br />
procedure Scollega_In<strong>di</strong>etro;<br />
procedure Scollega_Trasversale;<br />
procedure Collega_Trasversale_Avanti(var Destinazione: TForme; Tipo_Collegamento:<br />
TTipi_Collegamenti);<br />
procedure Aggiorna_Co<strong>di</strong>ce;<br />
procedure Salva_Xml(var Nodo: IXMLNode);<br />
procedure Carica_Xml(var Nodo: IXMLNode);<br />
procedure Cancella_Linker(var Linker: tlinker);<br />
procedure Cancella_Linker_Avanti(var Linker: tlinker);<br />
procedure Cancella_Linker_In<strong>di</strong>entro(var Linker: tlinker);<br />
procedure Cancella_Linker_Trasversale(var Linker: tlinker);<br />
f<strong>un</strong>ction Linker_By_Nome(var Linker: TLinker; Nome: String): Boolean;<br />
pro<strong>per</strong>ty Etichetta_Visibile: Boolean read FEtichetta_Visibile wr<strong>it</strong>e SetEtichetta_Visibile;<br />
pro<strong>per</strong>ty Caption:String read FCaption wr<strong>it</strong>e SetCaption;<br />
Come si evince vi sono vari campi e meto<strong>di</strong> defin<strong>it</strong>i con visibil<strong>it</strong>à <strong>di</strong>verse. Si<br />
<strong>di</strong>scuterà, inizialmente, <strong>di</strong> ciò che viene defin<strong>it</strong>o come Private.<br />
Fpen ed FBrush sono le classi, incapsulate, specializzate nel <strong>di</strong>segnare,<br />
rispettivamente, il contorno e il riempimento dell’icona.<br />
FShape è defin<strong>it</strong>o come <strong>un</strong> tipo TForma, <strong>di</strong>chiarato come<br />
TForma = (TF_Rettangolo, TF_Quadrato, TF_Rettangolo_Arrotondato, TF_Quadrato_Arrotondato,<br />
TF_Ellisse, TF_Cerchio, F_Triangolo_Destra, TF_Triangolo_Su, TF_Triangolo_Sinistra, TF_Triangolo_Giu,<br />
TF_Rombo, TF_Ottagono,TF_Esagono);<br />
91
FCaption, <strong>di</strong> tipo stringa, è la variabile che memorizza il contenuto da dover<br />
scrivere sopra l’icona.<br />
FonUserDraw e FbyUser sono, rispettivamente, l’evento <strong>per</strong> <strong>di</strong>segnare la<br />
forma della f<strong>un</strong>zione, se l’utente desidera inserire <strong>un</strong>a immagine <strong>per</strong> definire <strong>un</strong>a<br />
propria f<strong>un</strong>zione, ed FbyUser è <strong>un</strong>a variabile booleana che in<strong>di</strong>ca se l’utente<br />
vuole che la f<strong>un</strong>zione creata abbia <strong>un</strong>a immagine <strong>per</strong>sonalizzata.<br />
FCo<strong>di</strong>ce, <strong>di</strong> tipo Stringa, è la stringa che identifica il co<strong>di</strong>ce associato<br />
all’icona. Questo viene<br />
FEtichetta_Visibile, <strong>di</strong> tipo booleano, in<strong>di</strong>ca se si vuole rendere visibile <strong>un</strong><br />
commento <strong>per</strong> l’icona.<br />
FLivello_Annidamento, <strong>di</strong> tipo intero, è <strong>un</strong> valore importante <strong>per</strong> l’interfaccia<br />
grafica. Fornisce il livello <strong>di</strong> annidamento delle varie icone.<br />
FColore_Bordo, <strong>di</strong> tipo TColor ovvero <strong>un</strong> intero, in<strong>di</strong>ca il colore del bordo<br />
dell’icona.<br />
FSelezionato, <strong>di</strong> tipo booleano, in<strong>di</strong>ca se, durante l’interazione con<br />
l’applicativo, l’utente ha selezionato o meno l’icona.<br />
Le procedure DrawEllipse, DrawRectangle, DrawRo<strong>un</strong>dRect, DrawArrow,<br />
DoUserDraw implementano la visualizzazione della grafica delle icone.<br />
La procedura DrawText implementa la visualizzazione del testo all’interno<br />
delle icone, e viene chiamata dopo le procedure che <strong>di</strong>segnano le varie forme<br />
delle icone.<br />
La procedura SetLivello_Annidamento accetta come input <strong>un</strong> valore intero e<br />
setta FLivello_Annidamento al suo valore. Contestualmente, aggiorna tutte le<br />
icone collegate ad essa. Le icone ad essa collegate sono aggiornate<br />
automaticamente.<br />
92
La procedura SetColore_Bordo richiede <strong>un</strong> valore <strong>di</strong> tipo TColor. Questa<br />
procedura, oltre a settare il corrente valore <strong>di</strong> FColore_Bordo cambia il bordo<br />
dell’icona invocando la procedura Paint, <strong>di</strong>scussa nel segu<strong>it</strong>o.<br />
La procedura SetSelezionato, che richiede <strong>un</strong> valore booleano in ingresso,<br />
setta la variabile FSelezionato al valore attuale e contestualmente cambia il<br />
bordo e il riempimento dell’icona invocando la Paint.<br />
La procedura SettaEtichetta mo<strong>di</strong>fica l’etichetta associata all’icona. Questa<br />
Etichetta, <strong>un</strong> oggetto TLabel, descrive i commenti che l’utente vuole rendere<br />
noti.<br />
L’<strong>un</strong>ica procedura Protected riguarda la procedura Paint. Questa è defin<strong>it</strong>a<br />
come override, in quanto la si vuole interamente mo<strong>di</strong>ficare rispetto alla<br />
procedura Paint del TGraphicControl. La procedura è molto importante in<br />
quanto, inizialmente, esegue alc<strong>un</strong>i calcoli <strong>per</strong> definire le <strong>di</strong>mensioni che FPen e<br />
FBrush che devono rispettare e conseguentemente anche il Canvas.<br />
Successivamente, in accordo al tipo <strong>di</strong> valore <strong>di</strong> FShape vengono invocate le<br />
procedure che <strong>di</strong>segnano la forma <strong>di</strong>chiarata in FShape. A seguire, viene<br />
invocata la procedura DrawText che scrive il testo <strong>di</strong>chiarato in FCaption.<br />
Viene, poi, chiamato il metodo Calcola_Dati, spiegato nei dettagli<br />
successivamente, che calcola alc<strong>un</strong>i valori <strong>per</strong> i collegamenti con le altre icone.<br />
Nel segu<strong>it</strong>o del paragrafo, si <strong>di</strong>scuterà delle <strong>di</strong>chiarazioni pubbliche della<br />
classe.<br />
La variabile Connessioni è <strong>un</strong> array <strong>di</strong> TPoint, il quale è <strong>un</strong> record <strong>di</strong> due<br />
variabili: X e Y <strong>di</strong> tipo intero. Connessioni serve <strong>per</strong> specificare quali saranno i<br />
p<strong>un</strong>ti nel quale gli archi del flusso del programma saranno incidenti all’icona.<br />
93
Un’altra variabile importante è Baricentro, anch’essa <strong>di</strong> tipo TPoint. Questa<br />
serve a memorizzare il baricentro dell’immagine. Questo dato sarà utilizzato<br />
dagli archi <strong>per</strong> creare visualmente e <strong>di</strong>namicamente i collegamenti, in base alle<br />
posizioni in cui si troveranno due immagini, anche quando verranno spostate<br />
dall’utente.<br />
Le variabili Connessioni_Precedenti, Connessioni_Post, ,<br />
Connessioni_Trasversali_Precedenti, Connessioni_Trasversali_Post sono degli<br />
array <strong>di</strong> tipo TForme. Gli elementi <strong>di</strong> questi array corrispondono alle altre icone<br />
con le quali sono <strong>di</strong>rettamente collegate alle istanze della classe. Gli elementi <strong>di</strong><br />
questi array sono molto importanti <strong>per</strong> la continu<strong>it</strong>à del flusso e <strong>per</strong> la<br />
generazione del co<strong>di</strong>ce sorgente attraverso il co<strong>di</strong>ce iconico.<br />
La variabile Linkers è <strong>un</strong> array <strong>di</strong> tipo TLinker. E’ <strong>un</strong>a variabile fondamentale<br />
<strong>per</strong> il concetto <strong>di</strong> flusso iconico, questa verrà introdotta nel prosieguo.<br />
Il campo Nome, <strong>di</strong> tipo string, <strong>per</strong>mette <strong>di</strong> identificare <strong>un</strong>ivocamente le icone.<br />
Viene settato alla creazione <strong>di</strong> ogni istanza della classe.<br />
La variabile Colore_Bordo_Default, <strong>di</strong> tipo TColor, fornisce <strong>un</strong> colore <strong>di</strong><br />
default nel caso si voglia cambiare e successivamente reimpostare il colore del<br />
bordo. Il valore della variabile è settato alla creazione <strong>di</strong> ogni istanza della classe<br />
derivante da TForme.<br />
La procedura Create, che ammette <strong>un</strong> input <strong>di</strong> tipo TComponent ovvero il<br />
proprietario dell’istanza della classe, è <strong>di</strong>chiarato come override e constructor.<br />
La <strong>di</strong>chiarazione constructor è <strong>un</strong>a procedura richiamabile da qual<strong>un</strong>que classe<br />
non ancora instanziata e <strong>per</strong>mette la creazione dell’istanza. Questa procedura<br />
inizializza molte variabili quali Nome, FEtichetta, FPen, FBrush FbyUser,<br />
94
FEtichetta, i Linkers, FFLivello_Annidamento, Colore_Bordo_Defaul e<br />
Colore_Bordo, oltre alle <strong>di</strong>mensioni dell’icona <strong>di</strong> default.<br />
La procedura Destroy è <strong>di</strong>chiarata come override e come destructor. Le<br />
procedure destructor sono procedure chiamate automaticamente da ogni classe,<br />
in Delphi, è consentono <strong>di</strong> eseguire alc<strong>un</strong>e o<strong>per</strong>azioni prima che l’istanza della<br />
classe venga defin<strong>it</strong>ivamente eliminata e che la memoria, occupata dalla classe,<br />
venga liberata. In questa procedura vengono soltanto invocate le procedure <strong>per</strong><br />
liberare la memoria dalle altre classi incapsulate dalla classe TForme.<br />
La procedura Calcola_Dati, come già accennato, è importante <strong>per</strong> la<br />
visualizzazione e l’automatismo grafico degli archi, chiamati Linkers. In questa<br />
procedura vengono aggiornati il Baricentro e l’array delle Connessioni, entrambi<br />
già <strong>di</strong>scussi. Vedremo successivamente che questi parametri sono fondamentali<br />
<strong>per</strong> fornire agli archi il giusto orientamento.<br />
La proprietà Canvas è l’oggetto specializzato a <strong>di</strong>segnare sulla Regione forn<strong>it</strong>a<br />
dal TGraphicControl e viene chiamato ogni qualvolta sia necessario <strong>di</strong>segnare o<br />
scrivere.<br />
La proprietà Colore_Bordo setta il bordo dell’icona richiamando<br />
implic<strong>it</strong>amente la procedura SetColore_Bordo che serve a mo<strong>di</strong>ficare<br />
FColore_Bordo.<br />
La proprietà Selezionato richiama la procedura SetSelezionato, questa setta<br />
FSelezionato a True quando l’icona è selezionata e contestualmente mo<strong>di</strong>fica lo<br />
spessore ed il colore del bordo dell’icona; oppure setta FSelezionato a False,<br />
rendendo normale lo spessore dell’icona ed anche il suo colore.<br />
La proprietà Co<strong>di</strong>ce richiama la procedura SetCo<strong>di</strong>ce che setta il valore <strong>di</strong><br />
FCo<strong>di</strong>ce a Co<strong>di</strong>ce.<br />
95
La proprietà Etichetta invoca implic<strong>it</strong>amente la procedura SettaEtichetta la<br />
quale <strong>per</strong>mette <strong>di</strong> gestire l’istanza FEtichetta dell’oggeto TLabel, incapsulato in<br />
TForme.<br />
La proprietà Livello_Annidamento invoca la procedura<br />
SetLivello_Annidamento che setta il corretto valore alla variabile<br />
FLivello_Annidamento, già <strong>di</strong>scussa, e aggiorna tutti i valori <strong>di</strong> tutte le icone<br />
che <strong>di</strong>scendono dall’istanza della classe. Questo è molto utile e potente, quanto<br />
semplice, in quanto ogni icona che avrà mo<strong>di</strong>ficato il proprio livello <strong>di</strong><br />
annidamento, mo<strong>di</strong>ficherà le icone ad essa collegate, in cascata ed in maniera<br />
automatica.<br />
La procedura In<strong>di</strong>vidua_Linker_Partenza, che ammette come dati in input <strong>un</strong><br />
Linkers <strong>di</strong> tipo TLinkers ed <strong>un</strong>a Destinazione <strong>di</strong> tipo TForme, serve <strong>per</strong><br />
rintracciare quale icona è collegata all’arco incidente a Destinazione, ovvero da<br />
quale icona parte l’arco che p<strong>un</strong>ta verso Destinazione.<br />
La procedura In<strong>di</strong>vidua_Linker_Arrivo, che ammette come dati in input <strong>un</strong><br />
Linkers <strong>di</strong> tipo TLinkers ed <strong>un</strong>a Arrivo <strong>di</strong> tipo TForme, serve <strong>per</strong> rintracciare<br />
quale icona è collegata all’arco uscente ad Arrivo, ovvero verso quale icona<br />
finisce l’arco che parte da Arrivo.<br />
La procedura Collega_Avanti, ammette come dato in input <strong>un</strong>a variabile<br />
Destinazione <strong>di</strong> tipo TForme. Tale procedura crea fisicamente il legame tra due<br />
icone ed in<strong>di</strong>vidua la <strong>di</strong>rezione del flusso. Il legame, o relazione, tra le due icone<br />
è consent<strong>it</strong>o soltanto se l’icona <strong>di</strong> destinazione non ha archi incidenti su essa e se<br />
l’icona <strong>di</strong> partenza non ha già <strong>un</strong> suo successore nel flusso. Dopo aver collegato<br />
le icone, la procedura invoca la procedura Calcola_Dati sia <strong>per</strong> l’icona <strong>di</strong><br />
partenza che <strong>per</strong> quella <strong>di</strong> destinazione al fine <strong>di</strong> aggiornare i dati, ovvero le<br />
96
coor<strong>di</strong>nate, utili all’orientamento degli archi. Alla fine, viene invocata la<br />
procedura Aggiorna_Linker dell’arco appena creato, <strong>di</strong>scussa nel prosieguo.<br />
La procedura Scollega_Avanti elimina fisicamente <strong>un</strong> collegamento tra<br />
<strong>un</strong>’icona ed <strong>un</strong>’altra, aggiornando gli archi <strong>di</strong> entrambe le icone.<br />
La procedura Scollega_In<strong>di</strong>etro richiama la procedura Scollega_Avanti se<br />
l’icona ha <strong>un</strong> predecessore nel flusso, altrimenti la procedura si ferma.<br />
La procedura Collega_Trasversale_Avanti, richiede in input <strong>un</strong>a<br />
Destionazione <strong>di</strong> tipo TForme e <strong>un</strong> Tipo_Collegamento <strong>di</strong> tipo<br />
TTipi_Collegamenti, quest’ultimo può assumere <strong>un</strong>o dei seguenti valori<br />
TTC_Avanti, TTC_Begin, TTC_Ciclo, TTC_IF_Then, TTC_IF_ELSE,<br />
TTC_Case. Ogn<strong>un</strong>o <strong>di</strong> questi valori corrisponde a casi <strong>di</strong>stinti <strong>di</strong> collegamenti<br />
nel flusso. Un collegamento trasversale avviene ogni qual volta vi è <strong>un</strong><br />
cambiamento <strong>di</strong> livello <strong>di</strong> annidamento nel flusso. Poiché <strong>un</strong>’icona può avere<br />
collegato in entrata solo <strong>un</strong> arco trasversale, eccezion fatta <strong>per</strong> le icone Etichetta,<br />
e in usc<strong>it</strong>a solo <strong>un</strong> arco trasversale, eccezion fatta <strong>per</strong> l’icona del Case. La<br />
procedura controlla se vi è possibil<strong>it</strong>à <strong>di</strong> collegare le due icone verificando se<br />
ness<strong>un</strong>a delle due icone hanno collegamenti trasversali, eccezion fatta <strong>per</strong> i due<br />
casi precedenti.<br />
Quin<strong>di</strong>, la procedura collega trasversalmente le due icone, assegnando<br />
all’icona <strong>di</strong> Destinazione il livello <strong>di</strong> annidamento dell’icona <strong>di</strong> partenza<br />
aumentato <strong>di</strong> <strong>un</strong>o. In tale modo, aggiorna in cascata tutti i livelli <strong>di</strong> annidamento<br />
delle icone successive nel flusso a Destinazione.<br />
La procedura Scollega_Trasversale, scollega l’arco trasversale tra due icone,<br />
settando a 1 il livello <strong>di</strong> annidamento della icona che precedentemente era <strong>di</strong><br />
97
Destinazione, ed aggiornando così in cascata tutte le successive icone nel suo<br />
flusso.<br />
La procedura Aggiorna_Co<strong>di</strong>ce non è implementata in questa classe in quanto<br />
sarà sovrascr<strong>it</strong>ta in tutte le altre classi che derivano da TForme. E’ stata inser<strong>it</strong>a<br />
in quanto poiché implementata dalle classi derivanti, questa richiama la<br />
procedura <strong>di</strong>chiarata ed implementata dalla classe corretta. Questo <strong>per</strong> ev<strong>it</strong>are<br />
continui Type Casting sulle varie icone.<br />
La procedura Salva_Xml, riceve in input <strong>un</strong>’interfaccia IXMLNode, la quale<br />
fornisce <strong>un</strong>’interfaccia <strong>per</strong> salvare i dati dell’icona in formato xml. La procedura<br />
crea <strong>un</strong> nodo Figura attraverso l’interfaccia ed scrive <strong>un</strong>a serie <strong>di</strong> attributi XML<br />
in maniera tale da memorizzare sia le informazioni utili al recu<strong>per</strong>o dello stato<br />
dell’icona, sia informazioni legate al flusso dei dati, ovvero gli archi incidenti ed<br />
uscenti dall’icona.<br />
La procedura Carica_Xml, ricevere anch’essa <strong>un</strong>’interfaccia IXMLNode.<br />
Questa è la procedura duale a Salva_Xml, ovvero recu<strong>per</strong>a dagli attributi XML<br />
tutti i dati necessari a ripristinare lo stato salvato dell’icona e le informazioni<br />
inerenti il flusso.<br />
La procedura Cancella_Linker, richiede in input <strong>un</strong> Linker <strong>di</strong> tipo TLinkers.<br />
Tale procedura serve <strong>per</strong> aggiornare la lista degli archi incidenti ed uscenti da<br />
<strong>un</strong>’icona. Questa procedura viene creata poiché si vuole ev<strong>it</strong>are la ridondanza <strong>di</strong><br />
co<strong>di</strong>ce in quanto è <strong>un</strong>a porzione <strong>di</strong> co<strong>di</strong>ce che<br />
viene utilizzata dalle procedure Cancella_Linker_Avanti,<br />
Cancella_Linker_In<strong>di</strong>entro e Cancella_Linker_Trasversale, le quali eliminano,<br />
rispettivamente, gli archi in avanti, in<strong>di</strong>etro e trasversalmente al flusso.<br />
98
La procedura Linker_By_Nome, riceve in input <strong>un</strong> Linker <strong>di</strong> tipo TLinker e<br />
<strong>un</strong>a variabile Nome <strong>di</strong> tipo stringa. Questa procedura rest<strong>it</strong>uisce l’arco,<br />
assegnandolo a Linker, che collega l’icona ad <strong>un</strong>’altra icona <strong>di</strong> nome Nome.<br />
La proprietà Etichetta_Visibile richiama la procedura SetEtichetta_Visibile la<br />
quale rende visibile o meno FEtichetta.<br />
Infine, la proprietà Caption invoca la procedura SetCaption che oltre a<br />
mo<strong>di</strong>ficare la variabile FCaption ri<strong>di</strong>segna l’icona inserendo come testo il valore<br />
<strong>di</strong> Caption.<br />
4.2.2 Classe TFigura_Start<br />
La classe TFigura_Start deriva dalla classe TFigure che deriva da TForme.<br />
TFigure è solo <strong>un</strong>a classe <strong>di</strong> intermezzo senza mo<strong>di</strong>fiche, usata <strong>per</strong> verifiche <strong>di</strong><br />
Type Casting dal programma. Grazie all’ere<strong>di</strong>tarietà delle classi, questa riceve in<br />
ere<strong>di</strong>tà tutte le proprietà, i campi e i meto<strong>di</strong> implementati nella classe gen<strong>it</strong>rice.<br />
La descrizione della classe assume la seguente forma<br />
TFigura_Start = class(TFigure)<br />
public<br />
constructor Create(AOwner: TComponent); override;<br />
procedure Salva_Xml(var Xml: TXMLDocument; var Nodo: IXMLNode);<br />
procedure Carica_Xml(var Nodo: IXMLNode);<br />
end;<br />
99
la procedura Create, è <strong>di</strong>chiarata come override. All’interno della procedura<br />
viene richiamata la procedura Create ere<strong>di</strong>tata, e successivamente mo<strong>di</strong>fica<br />
altezza e larghezza dell’immagine. Viene anche mo<strong>di</strong>ficata, la forma agendo<br />
sulla proprietà Shape che in automatico assicura la corretta icona.<br />
Successivamente, vengono inizializzate tutte le altre proprietà quali i colori del<br />
bordo e del riempimento e del Font utilizzato <strong>per</strong> scrivere sull’icona. Viene<br />
anche richiamata la procedura Calcola_Dati che assicura <strong>di</strong> avere i corretti p<strong>un</strong>ti<br />
<strong>di</strong> gi<strong>un</strong>zione tra gli archi e il Baricentro.<br />
La procedura procedura Salva_Xml, ammette come dati due classi <strong>di</strong><br />
interfaccia XML. La prima corrisponde al progetto e la seconda corrisponde al<br />
nodo in cui verranno scr<strong>it</strong>ti i dati <strong>per</strong> recu<strong>per</strong>are le posizioni dell’icona e l’arco<br />
uscente da essa.<br />
La procedura Carica_Xml, ammette come dato in ingresso <strong>un</strong>’interfaccia al<br />
nodo dal quale bisogna recu<strong>per</strong>are i dati e setta le variabili della classe <strong>per</strong> il<br />
riposizionamento e il possibile collegamento ad <strong>un</strong>’altra icona, <strong>per</strong> il flusso.<br />
4.2.3 Classe TFigura_Dato<br />
La classe TFigura_Dato, come le altre icone, deriva da TFigure. Essa serve a<br />
memorizzare le variabili e le costanti all’interno <strong>di</strong> <strong>un</strong>a f<strong>un</strong>zione o procedura. La<br />
descrizione della classe è la seguente<br />
TFigura_Dato = class(TFigure)<br />
public<br />
Tipo_Dato: TDato_Matrice;<br />
100
constructor Create(AOwner: TComponent); override;<br />
destructor Destroy; override;<br />
procedure Aggiorna_Co<strong>di</strong>ce;<br />
procedure Salva_Xml(var Xml: TXMLDocument; var Nodo: IXMLNode);<br />
procedure Carica_Xml(var Nodo: IXMLNode);<br />
end;<br />
La variabile Tipo_Dato è <strong>un</strong>a classe che identifica i tipi <strong>di</strong> dato e verrà<br />
spiegata successivamente.<br />
La procedura Create, anch’essa è descr<strong>it</strong>ta come override ed invoca la<br />
procedura gen<strong>it</strong>rice. Inoltre, inizializza alc<strong>un</strong>i parametri atti ad identificare<br />
cogn<strong>it</strong>ivamente il tipo <strong>di</strong> costrutto, fornendo <strong>un</strong>a chiara forma e colore in base al<br />
tipo <strong>di</strong> dato che memorizza. Esegue anche la creazione e la inizializzazione della<br />
variabile Tipo_Dato e richiama la procedura Calcola_Dati. Tale procedura, in<br />
tutte le classi derivate da TForme, deve essere necessariamente chiamata dalla<br />
sub-classe in quanto essa stessa identifica la forma e le <strong>di</strong>mensioni dell’icona e<br />
quin<strong>di</strong> deve anche assumersi il comp<strong>it</strong>o <strong>di</strong> calcolare i dati <strong>di</strong> congi<strong>un</strong>zione<br />
degl’archi e del Baricentro.<br />
La procedura Destroy, <strong>di</strong>chiarata come override, libera la memoria usata dalla<br />
classe Tipo_Dato e invoca la procedura Destroy ere<strong>di</strong>tata da TForme.<br />
La procedura Aggiorna_Co<strong>di</strong>ce non è <strong>di</strong>chiarata come override, in quanto la<br />
classe gen<strong>it</strong>rice ha <strong>un</strong>a procedura vuota, quin<strong>di</strong> non è necessario sovrascriverla.<br />
Questa procedura esegue <strong>un</strong>a serie <strong>di</strong> controlli sulla variabile Tipo_Dato e, nel<br />
caso in cui tutti i dati <strong>di</strong> quest’ultimo siano completi, viene generato il co<strong>di</strong>ce<br />
sorgente in linguaggio C in accordo ai dati inser<strong>it</strong>i in Tipo_Dato.<br />
101
La procedura Salva_Xml, ammette come dati due classi <strong>di</strong> interfaccia XML.<br />
La prima corrisponde al progetto e la seconda corrisponde al nodo in cui<br />
verranno scr<strong>it</strong>ti i dati in Tipo_Dato. Inoltre, richiama la procedura richiama<br />
Salva_Xml della classe gen<strong>it</strong>rice, che serve a memorizzare tutte le variabili utili<br />
alla rappresentazione visiva dell’icona e dei suoi archi.<br />
La procedura Carica_Xml, accetta come input l’interfaccia IXMLNode che<br />
fornisce i dati al recu<strong>per</strong>o <strong>di</strong> tutti valori <strong>di</strong> Tipo_Dato e alle posizioni dell’icona<br />
e dei suoi collegamenti, anche richiamando la procedura ere<strong>di</strong>tata.<br />
4.2.3.1 Classe TTipo_Dato<br />
Questa classe implementa la classe base <strong>per</strong> TDato_Matrice. Essa consiste <strong>di</strong><br />
tutte le informazioni utili all’identificazione del dato, variabile o costante, il tipo<br />
<strong>di</strong> variabile, il suo nome e il suo valore, nel caso <strong>di</strong> costanti o variabili<br />
inizializzate. La sua definizione assume la seguente forma<br />
TTipo_Dato = class<br />
public<br />
Nome: String;<br />
Tipo_Di_Dati: TTipi_<strong>di</strong>_Dati;<br />
Tipo_Di_Shape: TTipi_Variabile;<br />
Stringa_Tipo_Di_Dati: String;<br />
Stringa_Tipo_Di_Shape: String;<br />
Valore: String;<br />
procedure Salva_Parametro(var Xml: TXMLDocument; var Nodo: IXMLNode);<br />
procedure Carica_Parametro(var Xml: TXMLDocument; var Nodo: IXMLNode);<br />
End;<br />
102
La variabile Nome, <strong>di</strong> tipo stringa, consiste nel nome, o simbolo, che si<br />
fornisce alla variabile.<br />
La variabile Tipo_Di_Dati, <strong>di</strong> tipo TTipi_<strong>di</strong>_Dati, assume <strong>un</strong> valore <strong>di</strong> <strong>un</strong><br />
insieme enumerabile defin<strong>it</strong>o come TD_Sconosciuto, TD_Void, TD_Char,<br />
TD_int, TD_short, TD_long, TD_long_long, TD_float, TD_double,<br />
TD_F<strong>un</strong>zione, ovvero i tipi prim<strong>it</strong>ivi che si possono incontrare nel linguaggio C,<br />
aggi<strong>un</strong>to da <strong>un</strong> tipo sconosciuto e dal tipo f<strong>un</strong>zione.<br />
La variabile Tipo_Di_Shape, <strong>di</strong> tipo TTipi_Variabile, assume <strong>un</strong> valore nel<br />
seguente insieme TTS_Sconosciuto, TTS_Costante, TTS_Variabile, ovvero<br />
descrive se la il dato è <strong>un</strong>a costante o <strong>un</strong>a variabile, oppure <strong>un</strong> tipo sconosciuto.<br />
La variabile Stringa_Tipo_Di_Dati assume <strong>un</strong> valore stringa, comprensibile<br />
all’utente, che è in accordo alla variabile Tipo_Di_Dati.<br />
La variabile Stringa_Tipo_Di_Shape, <strong>di</strong> tipo stringa, assume <strong>un</strong> valore in<br />
accordo a Tipo_Di_Shape.<br />
La variabile Valore, anch’essa <strong>di</strong> tipo stringa, coincide col valore del dato<br />
<strong>di</strong>chiarato, nel caso <strong>di</strong> costante o <strong>di</strong> variabile inizializzata.<br />
La procedura Salva_Parametro riceve in input, come le altre classi, le<br />
interfacce <strong>per</strong> salvare i valori sopra <strong>di</strong>scussi. Questi verranno recu<strong>per</strong>ati con la<br />
procedura Carica_Parametro e inser<strong>it</strong>i nelle rispettive variabili.<br />
103
4.2.3.2 Classe TDato_Matrice<br />
Questa è <strong>un</strong>a classe che implementa <strong>un</strong>a serie <strong>di</strong> meto<strong>di</strong> e proprietà atte ad<br />
in<strong>di</strong>viduare le <strong>di</strong>mensioni del dato e a memorizzarle attraverso <strong>un</strong>a forte<br />
incapsulazione. Deriva dalla classe TTipo_Dato, dalla quale ne riceve tutte le<br />
variabili e le procedure. E’ descr<strong>it</strong>ta come segue<br />
TDato_Matrice = class(TTipo_Dato)<br />
private<br />
FArray_Dimensioni: array of Integer;<br />
FDimensioni: Integer;<br />
procedure SetDimensioni(const Value: Integer);<br />
f<strong>un</strong>ction GetArray_Dimensioni(Index: Integer): Integer;<br />
procedure SetArray_Dimensioni(Index: Integer; const Value: Integer);<br />
public<br />
pro<strong>per</strong>ty Array_Dimensioni[Index: Integer]: Integer read GetArray_Dimensioni wr<strong>it</strong>e<br />
SetArray_Dimensioni;<br />
pro<strong>per</strong>ty Dimensioni: Integer read FDimensioni wr<strong>it</strong>e SetDimensioni;<br />
procedure Salva_Parametro(var Xml: TXMLDocument; var Nodo: IXMLNode);<br />
procedure Salva_Parametro(var Nodo: IXMLNode);<br />
constructor Create;<br />
destructor Destroy;<br />
end;<br />
la variabile FArray_Dimensioni è <strong>un</strong> array <strong>di</strong> tipo intero. Questa definisce la<br />
grandezza <strong>di</strong> ogni <strong>di</strong>mensione del dato. Non viene <strong>di</strong>rettamente manipolata<br />
dall’utente, ma è fortemente incapsulata e i suoi dati vengono manipolati da<br />
GetArray_Dimensioni e da SetArray_Dimensioni che ricevendo in input il<br />
valore <strong>di</strong> Index, <strong>un</strong> intero, rest<strong>it</strong>uiscono o mo<strong>di</strong>ficano il valore in accordo alla<br />
104
loro implementazione. L’utente ha la sensazione <strong>di</strong> manipolarle <strong>di</strong>rettamente<br />
quando si interagisce con la variabile pubblica Array_Dimensioni, che in realtà<br />
richiama le sopra dette procedure e f<strong>un</strong>zioni.<br />
La variabile FDimensioni, <strong>di</strong> tipo intero, setta la <strong>di</strong>mensione dell’array<br />
FArray_Dimensioni attraverso la procedura SetDimensioni invocata<br />
implic<strong>it</strong>amente quando si mo<strong>di</strong>fica la variabile Dimensioni.<br />
La procedura Salva_Paramentro, come tutte le altre classi, accetta le interfacce<br />
XML <strong>per</strong> salvare sia le variabile del tipo <strong>di</strong> classe gen<strong>it</strong>rice sia le variabili<br />
proprie.<br />
La procedura Carica_Parametro, riceve in input <strong>un</strong>’interfaccia IXMLNode e la<br />
usa recu<strong>per</strong>ando i valori delle variabili memorizzate precedentemente con<br />
Salva_Parametro.<br />
La procedura Create costruttrice della classe, <strong>di</strong>versamente dai precedenti casi,<br />
non è <strong>di</strong>chiarata come override. Questo poiché dalla classe gen<strong>it</strong>rice non era<br />
necessario andare ad implementarla, d<strong>un</strong>que non è necessario e né possibile<br />
andare a sovrascriverla. Questa procedura inizializza le variabili in maniera<br />
opport<strong>un</strong>a e setta la l<strong>un</strong>ghezza <strong>di</strong> FArray_Dimensioni a zero.<br />
La procedura Destroy elimina la classe, ed è necessaria implementarla in<br />
quanto essa libera la memoria dell’array FArray_Dimensioni.<br />
105
4.2.4 Classe TFigura_Ciclo<br />
La classe TFigura_Ciclo serve a configurare la <strong>di</strong>chiarazione <strong>di</strong> <strong>un</strong> ciclo nel<br />
co<strong>di</strong>ce sorgente in C. La classe, come le altre, deriva da TFigure ed ha la<br />
seguente forma <strong>di</strong>chiarativa<br />
TFigura_Ciclo= class(TFigure)<br />
private<br />
FTipo_Ciclo: TTipi_Ciclo;<br />
procedure SetTipo_Ciclo(const Value: TTipi_Ciclo);<br />
public<br />
Con<strong>di</strong>zioni: TCon<strong>di</strong>zione;<br />
Variabile: String;<br />
Valore: String;<br />
Espressione: String;<br />
constructor Create(AOwner: TComponent); override;<br />
destructor Destroy; override;<br />
procedure Aggiorna_Co<strong>di</strong>ce;<br />
pro<strong>per</strong>ty Tipo_Ciclo: TTipi_Ciclo read FTipo_Ciclo wr<strong>it</strong>e SetTipo_Ciclo;<br />
procedure Salva_Xml(var Xml: TXMLDocument; var Nodo: IXMLNode);<br />
procedure Carica_Xml(var Nodo: IXMLNode);<br />
end;<br />
La variabile privata FTipo_Ciclo assume <strong>un</strong>o dei seguenti valori enumerabili<br />
TTC_For, TTC_While, TTC_Repeat, e serve ad in<strong>di</strong>care il tipo e la forma del<br />
ciclo nel co<strong>di</strong>ce sorgente in C, in accordo alle forme <strong>di</strong> <strong>di</strong>chiarazione in C.<br />
La procedura privata SetTipo_Ciclo, che richiede in input <strong>un</strong> valore<br />
TTipi_Ciclo, viene richiamata implic<strong>it</strong>amente quando si mo<strong>di</strong>fica la proprietà<br />
publica Tipo_Ciclo. Tale procedura, oltre a mo<strong>di</strong>ficare la variabile FTipo_Ciclo,<br />
106
mo<strong>di</strong>fica anche il colore del riempimento dell’icona in accordo al colore<br />
associato al valore <strong>di</strong> FTipo_Ciclo. Inoltre, mo<strong>di</strong>fica anche il testo all’interno<br />
dell’icona <strong>per</strong> fornire <strong>un</strong> imme<strong>di</strong>ata comprensione cogn<strong>it</strong>iva del ciclo utilizzato<br />
all’utente finale.<br />
La variabile Con<strong>di</strong>zioni è <strong>un</strong>a classe <strong>di</strong> tipo TCon<strong>di</strong>zione, tale classe verrà<br />
spiegata nel segu<strong>it</strong>o. Questa variabile memorizza tutte le con<strong>di</strong>zioni alle quali<br />
Variabile è soggetta <strong>per</strong> la continuazione del ciclo.<br />
La variabile Variabile, <strong>di</strong> tipo stringa, assume il nome della variabile assegnata<br />
come contatore da utilizzare all’interno del ciclo.<br />
La variabile Valore, <strong>di</strong> tipo stringa, è il valore iniziale che Variabile avrà<br />
assegnato all’interno del ciclo, se si utilizza come Tipo_Ciclo il valore<br />
TTC_For.<br />
La variabile Espressione, <strong>di</strong> tipo stringa, fornisce l’espressione <strong>di</strong> incremento<br />
che agisce su Variabile nel caso <strong>di</strong> <strong>un</strong> ciclo For.<br />
La procedura costruttiva Create, <strong>di</strong>chiarata come override, inizializza tutte le<br />
variabili e anche l’istanza <strong>di</strong> classe Con<strong>di</strong>zioni, oltre ad invocare la omonima<br />
procedura gen<strong>it</strong>rice.<br />
Mentre la procedura <strong>di</strong>struttiva <strong>di</strong> classe Destroy, <strong>di</strong>chiarata anch’essa come<br />
override, libera la memoria usata dall’istanza della classe Con<strong>di</strong>zioni e invoca la<br />
procedura omonima gen<strong>it</strong>rice.<br />
La procedura Aggiona_Co<strong>di</strong>ce, in base ai valori delle singole variabili, crea il<br />
co<strong>di</strong>ce del ciclo e lo struttura in maniera tale che sia in accordo con le tipologie<br />
dei costrutti del linguaggio C, in base al tipo <strong>di</strong> valore memorizzato in<br />
FTipo_Ciclo.<br />
107
Le procedure Salva_Xml e Carica_Xml, come nei precedenti casi, ricevono in<br />
input delle interfacce XML che servono, rispettivamente alle procedure, <strong>per</strong><br />
salvare tutti i dati memorizzati all’interno dell’istanza della classe e <strong>per</strong><br />
recu<strong>per</strong>are e settare i valori salvati nell’istanza della classe.<br />
4.2.4.1 Classe TCon<strong>di</strong>zione<br />
La classe TCon<strong>di</strong>zione <strong>per</strong>mette <strong>di</strong> memorizzare le varie con<strong>di</strong>zioni, o<br />
espressioni booleane, e i relativi connettori logici tra queste. Tale classe verrà<br />
utilizzata anche in altre classi derivate da TFigure. Questa classe memorizza<br />
soltanto i valori e non crea co<strong>di</strong>ce in C. La classe è defin<strong>it</strong>a nella seguente forma<br />
TCon<strong>di</strong>zione = class<br />
Public<br />
Negazioni: array of boolean;<br />
Con<strong>di</strong>zioni: array of String;<br />
O<strong>per</strong>_Logici: array of String;<br />
constructor Create;<br />
destructor Destroy;<br />
procedure Salva_Parametro(var Xml: TXMLDocument; var Nodo: IXMLNode);<br />
end;<br />
La variabile Negazioni è <strong>un</strong> array <strong>di</strong> valori booleani, i quali servono a riferire<br />
se si deve considerare la negazione delle singole con<strong>di</strong>zioni oppure il valore<br />
originario.<br />
108
La variabile Con<strong>di</strong>zioni è <strong>un</strong> array <strong>di</strong> stringhe, dove vengono memorizzate<br />
tutte le con<strong>di</strong>zioni usate.<br />
La variabile O<strong>per</strong>_Logici è anch’essa <strong>un</strong> array <strong>di</strong> stringhe dove si<br />
memorizzano tutti gli o<strong>per</strong>atori logici usati <strong>per</strong> connettere le varie con<strong>di</strong>zioni, o<br />
espressioni booleane.<br />
4.2.5 Classe TFigura_If_Then_Else<br />
La classe TFigura_If_Then_Else realizza l’omonimo costrutto. La forma<br />
<strong>di</strong>chiarativa è la seguente<br />
TFigura_If_Then_Else= class(TFigure)<br />
public<br />
Con<strong>di</strong>zioni: TCon<strong>di</strong>zione;<br />
constructor Create(AOwner: TComponent); override;<br />
destructor Destroy; override;<br />
procedure Aggiorna_Co<strong>di</strong>ce;<br />
procedure Salva_Xml(var Xml: TXMLDocument; var Nodo: IXMLNode);<br />
procedure Carica_Xml(var Nodo: IXMLNode);<br />
end;<br />
La variabile Con<strong>di</strong>zioni assume la stessa f<strong>un</strong>zione esposto nella classe<br />
TFigura_Ciclo, solo che viene usato <strong>per</strong> il costrutto If..Then..Else.<br />
La procedura costruttiva Create, <strong>di</strong>chiarata come override, inizializza l’istanza<br />
<strong>di</strong> classe Con<strong>di</strong>zioni, oltre ad invocare la omonima procedura gen<strong>it</strong>rice.<br />
109
La procedura <strong>di</strong>struttiva <strong>di</strong> classe Destroy, <strong>di</strong>chiarata anch’essa come override,<br />
libera la memoria usata dall’istanza della classe Con<strong>di</strong>zioni e invoca la<br />
procedura omonima gen<strong>it</strong>rice.<br />
La procedura Aggiona_Co<strong>di</strong>ce è molto importante in quanto costruisce il<br />
co<strong>di</strong>ce sorgente partendo dalle con<strong>di</strong>zioni forn<strong>it</strong>e.<br />
Le procedure Salva_Xml e Carica_Xml, come nei precedenti casi, ricevono in<br />
input delle interfacce XML che servono, rispettivamente alle procedure, <strong>per</strong><br />
salvare tutti i dati memorizzati all’interno dell’istanza della classe e <strong>per</strong><br />
recu<strong>per</strong>are e settare i valori salvati nell’istanza della classe.<br />
4.2.6 Classe TFigura_Blocco<br />
La classe TFigura_Blocco fornisce <strong>un</strong> semplice modo <strong>per</strong> inserire blocchi <strong>di</strong><br />
co<strong>di</strong>ce aggi<strong>un</strong>tivi. La classe deriva, come le altre classi iconiche, da TFigure ed<br />
assume la seguente forma <strong>di</strong>chiarativa<br />
TFigura_Blocco = class (TFigure)<br />
public<br />
Stringhe: array of String;<br />
Numero_Stringhe: Integer;<br />
constructor Create(AOwner: TComponent); override;<br />
destructor Destroy; override;<br />
procedure Salva_Xml(var Xml: TXMLDocument; var Nodo: IXMLNode);<br />
procedure Carica_Xml(var Nodo: IXMLNode);<br />
end;<br />
110
La variabile Stringhe, <strong>un</strong> array <strong>di</strong> tipo stringa, memorizza le stringhe inser<strong>it</strong>e<br />
dall’utente.<br />
Mentre, la variabile Numero_Stringhe, <strong>di</strong> tipo intero, corrisponde alla<br />
car<strong>di</strong>nal<strong>it</strong>à dell’array, ovvero al numero <strong>di</strong> stringhe inser<strong>it</strong>e.<br />
Il costruttore Create, come negl’altri casi, è <strong>di</strong>chiarato override, e serve <strong>per</strong><br />
inizializzare l’array Stringhe e il valore Numero_Stringhe a zero, oltre che ad<br />
inizializzare le altre variaibili ere<strong>di</strong>tate e a costruire l’immagine corretta<br />
dell’icona.<br />
Mentre il <strong>di</strong>struttore Destroy, anch’esso <strong>di</strong>chiarato override, serve <strong>per</strong> liberare<br />
la memoria dell’array Stringhe.<br />
4.2.7 Classe TFigura_Break_Continue_Ex<strong>it</strong><br />
La classe TFigura_Break_Continue_Ex<strong>it</strong>, è <strong>un</strong>a classe iconica che fornisce<br />
informazioni circa la continu<strong>it</strong>à o le interruzioni all’interno <strong>di</strong> <strong>un</strong>a f<strong>un</strong>zione.<br />
Deriva da TFigure ed ha la seguente forma <strong>di</strong>chiarativa<br />
TFigura_Break_Continue_Ex<strong>it</strong> = class (TFigure)<br />
private<br />
FTipo: TTipi_Interruzioni;<br />
procedure SetTipo(Value: TTipi_Interruzioni);<br />
public<br />
pro<strong>per</strong>ty Tipo: TTipi_Interruzioni read FTipo wr<strong>it</strong>e SetTipo;<br />
constructor Create(AOwner: TComponent); override;<br />
procedure Salva_Xml(var Xml: TXMLDocument; var Nodo: IXMLNode);<br />
procedure Carica_Xml(var Nodo: IXMLNode);<br />
111
end;<br />
la variabile FTipo, <strong>di</strong> tipo TTipi_Interruzioni, assume <strong>un</strong>o dei seguenti valori<br />
TTI_Break, TTI_Continue, TTI_Ex<strong>it</strong>, ed in<strong>di</strong>ca il tipo <strong>di</strong> co<strong>di</strong>ce che si andrà ad<br />
inserire.<br />
La procedura SetTipo mo<strong>di</strong>fica FTipo con il valore ricevuto in ingresso e<br />
contestualmente mo<strong>di</strong>fica anche l’immagine dell’icona e il suo testo, che<br />
rappresenta la scelta del tipo <strong>di</strong> informazione desiderato.<br />
Il costruttore Create, <strong>di</strong>chiarata come override, si comporta come nelle<br />
precedenti classi incontrate.<br />
Anche le procedure Salva_Xml e Carica_Xml hanno lo stesso comportamento<br />
delle altre classi incontrate.<br />
4.2.8 Classe TFigura_Sw<strong>it</strong>ch<br />
La classe TFigura_Sw<strong>it</strong>ch è <strong>un</strong>a classe che corrisponde al costrutto<br />
Sw<strong>it</strong>ch..Case. Con questa classe si offre all’utente la possibil<strong>it</strong>à <strong>di</strong> fornire più<br />
scelte, e quin<strong>di</strong> più comportamenti, ad <strong>un</strong>a porzione <strong>di</strong> <strong>un</strong> algor<strong>it</strong>mo in base al<br />
risultato <strong>di</strong> <strong>un</strong>’espressione. La definizione della classe è la seguente<br />
TFigura_Sw<strong>it</strong>ch = class(TFigure)<br />
public<br />
Espressione: String;<br />
Casi: array of String;<br />
constructor Create(AOwner: TComponent); override;<br />
112
destructor Destroy; override;<br />
end;<br />
La variabile Espressione, <strong>di</strong> tipo stringa, memorizza l’omonima l’espressione<br />
dello costrutto Sw<strong>it</strong>ch.<br />
La variabile Casi è <strong>un</strong> array <strong>di</strong> tipo stringa la quale memorizza le possibili<br />
<strong>di</strong>ramazioni dello Sw<strong>it</strong>ch. Tali <strong>di</strong>ramazioni, devono essere in accordo con i<br />
possibili risultati dell’Espressione.<br />
Il costruttore Create, <strong>di</strong>chiarato override, oltre d invocare, come nelle altre<br />
classi, l’omonima procedura ere<strong>di</strong>tata inizializza Espressione e Casi.<br />
Il <strong>di</strong>struttore Destroy, anch’esso override, libera la memoria dell’array Casi,<br />
oltre a chiamare il <strong>di</strong>struttore ere<strong>di</strong>tato.<br />
4.2.9 Classe TFigura_Assegnazione<br />
La classe TFigura_Assegnazione è <strong>un</strong>a classe che fornisce <strong>un</strong>’icona più<br />
grande rispetto alle altre. Rappresenta l’assegnazione <strong>di</strong> <strong>un</strong>a espressione ad <strong>un</strong>a<br />
variabile. La classe deriva anch’essa da TFigure, e la sua <strong>di</strong>chiarazione è la<br />
seguente<br />
TFigura_Assegnazione = class(TFigure)<br />
private<br />
FTipo_Variabile: TTipi_<strong>di</strong>_Dati;<br />
procedure SetTipo_Variabile(Value: TTipi_<strong>di</strong>_Dati);<br />
public<br />
Espressione: String;<br />
113
Variabile: String;<br />
pro<strong>per</strong>ty Tipo_Variabile: TTipi_<strong>di</strong>_Dati read FTipo_Variabile wr<strong>it</strong>e SetTipo_Variabile;<br />
procedure Aggiorna_Co<strong>di</strong>ce;<br />
constructor Create(AOwner: TComponent); override;<br />
end;<br />
La variabile FTipo_Variabile, <strong>di</strong> tipo TTipi_<strong>di</strong>_Dati, memorizza internamente<br />
il tipo <strong>di</strong> variabile alla quale si assegnerà la variabile Espressione.<br />
La procedura Set Tipo_Variabile, richiede in input <strong>un</strong> tipo in accordo a<br />
FTipo_Variabile, e lo assegna ad essa. Inoltre, mo<strong>di</strong>fica l’aspetto dell’icona, in<br />
accordo sia al nome della variabile che al tipo.<br />
La variabile Espressione, <strong>di</strong> tipo stringa, in<strong>di</strong>ca l’espressione da assegnare a<br />
Variabile.<br />
Il campo Variabile, anch’esso <strong>di</strong> tipo string, identifica il nome della variabile<br />
assegnataria.<br />
La procedura Create, come nelle altre classi, è <strong>di</strong>chiarata override, e oltre ad<br />
invocare l’omonima procedura ere<strong>di</strong>tata inizializza FTipo_Variabile ed altre<br />
variabili ere<strong>di</strong>tate <strong>per</strong> la rappresentazione iconografica.<br />
La procedura Destroy non viene implementata, in quanto non vi è alc<strong>un</strong>a<br />
variabile che, alla <strong>di</strong>struzione dell’istanza della classe, non libera la memoria<br />
usata.<br />
114
4.2.10 Classe TFigura_F<strong>un</strong>zione<br />
Anche tale classe deriva da TFigure. Questa classe rappresenta la f<strong>un</strong>zione che<br />
viene richiamata nel flusso, senza necess<strong>it</strong>à <strong>di</strong> assegnare <strong>un</strong> valore a qualche<br />
variabile. La sua <strong>di</strong>chiarazione è la seguente<br />
TFigura_F<strong>un</strong>zione = class(TFigure)<br />
public<br />
Include: String;<br />
Nome_F<strong>un</strong>zione: String;<br />
Tipo_F<strong>un</strong>zione: TTipi_<strong>di</strong>_Dati;<br />
Parametri: array of string;<br />
constructor Create(AOwner: TComponent); override;<br />
destructor Destroy; override;<br />
end;<br />
La variabile Include, <strong>di</strong> tipo stringa, identifica il file utilizzato dove risiede la<br />
f<strong>un</strong>zione cercata.<br />
La variabile Nome_F<strong>un</strong>zione, <strong>di</strong> tipo stringa, definisce il nome della f<strong>un</strong>zione<br />
desiderata.<br />
Invece, Tipo_F<strong>un</strong>zione, <strong>di</strong> tipo TTipi_<strong>di</strong>_Dati, identifica la tipologia <strong>di</strong> dato<br />
che la f<strong>un</strong>zione fornisce in output.<br />
La variabile Paramentri, <strong>un</strong> array <strong>di</strong> tipo stringa, memorizza i parametri<br />
assegnati alla procedura.<br />
La procedura Create, sovrascr<strong>it</strong>ta a quella ere<strong>di</strong>tata, che la richiama, inizializza<br />
Parametri definendo l’array con <strong>un</strong>a l<strong>un</strong>ghezza uguale a zero.<br />
115
Mentre, il <strong>di</strong>struttore Destroy, anch’esso sovrascr<strong>it</strong>to, libera la memoria <strong>di</strong><br />
Parametri;<br />
4.2.11 Classi TFigura_Label, TFigura_Goto, TFigura_Return,<br />
TFigura_Begin, TFigura_End<br />
Queste classi non implementano particolari proprietà in quanto sfruttano i<br />
campi e i meto<strong>di</strong> defin<strong>it</strong>i in TForme. L’<strong>un</strong>ica procedura che mo<strong>di</strong>ficando è il<br />
costruttore Create, <strong>di</strong>chiarato override, in quanto alla creazione <strong>di</strong> ciasc<strong>un</strong>a<br />
istanza, mo<strong>di</strong>ficano opport<strong>un</strong>amente la loro forma e i loro colori, <strong>per</strong> rendere<br />
cogn<strong>it</strong>ivamente rappresentativo il significato delle loro icone.<br />
4.3 Implementazione del flusso grafico: classe TLinker<br />
Il flusso può essere <strong>di</strong>stinto in flusso grafico e flusso logico. Il flusso logico è<br />
implementato tram<strong>it</strong>e gli array delle Connessioni implementate nella classe<br />
TForme. Mentre, il flusso grafico è cost<strong>it</strong>u<strong>it</strong>o dagli archi, entranti o uscenti, dalle<br />
icone. La classe che implementa tali grafici è chiamata TLinker. La classe<br />
assume la seguente forma<br />
TLinker = class<br />
private<br />
FOggetto_Partenza: TForme;<br />
116
FOggetto_Arrivo: TForme;<br />
Linee: array[0..2] of TForme;<br />
procedure SetOggetto_Partenza(const Value: TForme);<br />
procedure SetOggetto_Arrivo(const Value: TForme);<br />
procedure Disegna_Linker;<br />
public<br />
Lato_Partenza, Lato_Arrivo: TLati;<br />
Freccia_Partenza: TForme;<br />
Freccia_Arrivo: TForme;<br />
pro<strong>per</strong>ty Oggetto_Partenza: TForme read FOggetto_Partenza wr<strong>it</strong>e SetOggetto_Partenza;<br />
pro<strong>per</strong>ty Oggetto_Arrivo: TForme read FOggetto_Arrivo wr<strong>it</strong>e SetOggetto_Arrivo;<br />
constructor Create(Owner: Twincontrol);<br />
procedure Cancella;<br />
destructor Destroy;<br />
procedure Aggiorna_Linker;<br />
procedure Evidenzia_Linker;<br />
procedure Hide;<br />
procedure Show;<br />
end;<br />
Le variabili FOggetto_Partenza e FOggetto_Arrivo, <strong>di</strong> tipo TForme,<br />
cost<strong>it</strong>uiscono le icone, rispettivamente, <strong>di</strong> partenza e <strong>di</strong> arrivo dell’arco ed,<br />
attraverso esse, definiscono i p<strong>un</strong>ti dove l’arco verrà <strong>di</strong>segnato.<br />
La variabile Linee è <strong>un</strong> array <strong>di</strong> tipo TForme che cost<strong>it</strong>uisce le linee dell’arco.<br />
Le procedure SetOggetto_Partenza e SetOggetto_Arrivo ricevono in input i<br />
valori assegnati alle proprietà Oggetto_Partenza ed Oggetto_Arrivo.<br />
Le variabili Freccia_Partenza e Freccia_Arrivo, entrambi <strong>di</strong> tipo TForme<br />
definiscono le icone dell’arco rappresentate, rispettivamente, da <strong>un</strong> cerchio<br />
pieno dal quale parte l’arco e da <strong>un</strong>a freccia verso il quale finisce l’arco.<br />
117
Il costruttore Create, non <strong>di</strong>chiarato override in quanto la classe non deriva da<br />
alc<strong>un</strong>’altra classe, inizializza tutte le classi incapsulate in TLinker.<br />
La procedura Cancella richiama il <strong>di</strong>struttore Destroy, <strong>per</strong> eliminare l’arco.<br />
La procedura Destroy libera la memoria <strong>di</strong> tutte le classi incapsulate in<br />
Tlinker.<br />
La procedura Aggiorna_Linker è richiamata ogni qualvolta le icone dei<br />
costrutti vengono spostate e quando cambiano il loro livello <strong>di</strong> annidamento nel<br />
flusso. Questa procedura richiama Disegna_Linker e Evidenzia_Linker;<br />
La procedura Disegna_Linker è specializzata nel <strong>di</strong>segnare l’arco. Verifica il<br />
livello <strong>di</strong> annidamento dell’icona <strong>di</strong> arrivo e definisce il colore dell’arco in base<br />
a questo dato. Inoltre, a seconda delle posizioni del Baricentro delle Icone,<br />
definisce i p<strong>un</strong>ti <strong>di</strong> partenza e <strong>di</strong> arrivo dell’arco verificando quali siano i<br />
<strong>per</strong>corsi e la forma che l’arco deve assumere <strong>per</strong> rendere il concetto <strong>di</strong> flusso<br />
grafico, verificando quale siano i corretti valori delle variabili Lato_Partenza e<br />
Lato_Arrivo, che possono assumere i valori TL_Su, TL_Destra, TL_Giu,<br />
TL_Sinistra. Verificato questi, assegna agli oggetti <strong>di</strong> Linee le corrette<br />
coor<strong>di</strong>nate e <strong>di</strong>mensioni, e immagini, rappresentando così l’arco.<br />
La procedura Evidenzia_Linker fa sì che gli oggetti grafici dell’arco vengano<br />
portati sopra tutte gli altri oggetti dello spazio <strong>di</strong> programmazione iconica, <strong>per</strong><br />
evidenziare l’arco. Questo accade ogni volta che <strong>un</strong>’icona viene selezionata <strong>per</strong><br />
rendere imme<strong>di</strong>atamente <strong>di</strong>sponibile la continu<strong>it</strong>à del flusso da quell’icona.<br />
Le procedure Hide e Show, rispettivamente, nascondono e rendono visibile<br />
l’arco, <strong>it</strong>erando su tutti gli oggetti dell’istanza della classe.<br />
118
4.4 Integrazione del parser XML<br />
Per salvare <strong>un</strong> progetto, i suoi files e le relative f<strong>un</strong>zioni, sono state<br />
implementate tre classi derivate dalla classe TXMLDocument: TXML_Progetto,<br />
TXML_File, TXML_F<strong>un</strong>zione.<br />
4.4.1 Classe TXML_Progetto<br />
La classe TXML_Progetto serve a salvare e recu<strong>per</strong>are i dati contenenti che<br />
compongono il progetto. E’ <strong>di</strong>chiarata come segue<br />
TXML_Progetto= class(TXMLDocument)<br />
private<br />
FFiles: array of String;<br />
public<br />
Nome: String;<br />
Percorso: String;<br />
constructor Create(AOwner: TComponent); overload; override;<br />
constructor Create(const AFileName: DOMString); reintroduce; overload;<br />
destructor Destroy; override;<br />
f<strong>un</strong>ction Inserisci_File(File_: TXML_File): Boolean;<br />
f<strong>un</strong>ction Elimina_File(Nome_File: String): Boolean;<br />
f<strong>un</strong>ction Salva_Progetto(Figura: TForme): Boolean;<br />
f<strong>un</strong>ction Carica_Progetto(Co<strong>di</strong>ce: String): Boolean;<br />
end;<br />
119
L’array FFiles, <strong>di</strong> tipo string, memorizza tutti i files che compongono il<br />
progetto.<br />
Le variabili Nome e Percorso memorizzano rispettivamente il nome e il<br />
<strong>per</strong>corso della configurazione del progetto.<br />
I due costruttori Create, <strong>di</strong>chiarati override, ma anche overload ed reintroduce<br />
inizializzano l’array Files ed invocano i costruttori della classe gen<strong>it</strong>rice. La<br />
classe può essere create richiamando <strong>un</strong>o dei due costruttori, a seconda se si<br />
vuole fornire in input <strong>un</strong> oggetto TComponent o <strong>un</strong> tipo DOMString ovvero <strong>un</strong>a<br />
stringa. Il primo Create sovrascrive la procedura ere<strong>di</strong>tata e, attraverso la<br />
keyword overload, la marca come <strong>un</strong>ica procedura che può essere invocata nel<br />
caso in cui viene forn<strong>it</strong>o in input <strong>un</strong> TComponent. Il secondo costruttore,<br />
attraverso la keyword reintroduce, <strong>di</strong>chiara implementabile la procedura in<br />
quanto nella classe gen<strong>it</strong>rice il prototipo del costruttore è <strong>di</strong>chiarato come<br />
virtual, ovvero <strong>un</strong>a procedura implementabile soltanto dalle classi derivate, e,<br />
attraverso la parola chiave overload, rende la procedura invocabile quando viene<br />
forn<strong>it</strong>o a Create <strong>un</strong> dato <strong>di</strong> tipo Domstring, ovvero <strong>un</strong>a stringa.<br />
Il <strong>di</strong>struttore Destroy libera la memoria utilizzata dall’array Files, ed invoca il<br />
<strong>di</strong>struttore ere<strong>di</strong>tato.<br />
La f<strong>un</strong>zione Inserisci_File riceve in input <strong>un</strong> dato TXML_File e memorizza<br />
tutti i suoi dati in formato XML e rest<strong>it</strong>uisce True se la memorizzazione avviene<br />
con successo, o False altrimenti.<br />
La f<strong>un</strong>zione Elimina_File riceve in input il nome, <strong>di</strong> tipo stringa, interno <strong>di</strong> <strong>un</strong><br />
oggetto TForme <strong>per</strong> eliminarlo da FForme e rest<strong>it</strong>uisce True se la cancellazione<br />
avviene con successo, o False altrimenti.<br />
120
La f<strong>un</strong>zione Salva_Progetto rest<strong>it</strong>uisce <strong>un</strong> valore booleano in accordo al<br />
successo del salvataggio. La procedura salva i parametri necessari <strong>per</strong> il suo<br />
successivo recu<strong>per</strong>o.<br />
La f<strong>un</strong>zione Carica_Progetto accetta in input <strong>un</strong>a stringa dalla quale è<br />
possibile riprodurre l’intero progetto e rest<strong>it</strong>uisce il valore True se il progetto è<br />
stato caricato correttamente, o False altrimenti.<br />
4.4.2 Classe TXML_File<br />
La classe TXML_File serve a salvare e recu<strong>per</strong>are i dati (f<strong>un</strong>zioni, variabili,<br />
costanti, strutture e file include) contenenti che compongono il progetto.<br />
La classe è <strong>di</strong>chiarata come segue<br />
TXML_File= class(TXMLDocument)<br />
private<br />
FF<strong>un</strong>zioni: array of String;<br />
public<br />
Nome: String;<br />
Percorso: String;<br />
Include: array of String;<br />
Variabili: array of TDato_Matrice;<br />
Costanti: array of TDato_Matrice;<br />
Strutture: array of TStrutture;<br />
constructor Create(AOwner: TComponent); overload; override;<br />
constructor Create(const AFileName: DOMString); reintroduce; overload;<br />
destructor Destroy; override;<br />
f<strong>un</strong>ction Inserisci_F<strong>un</strong>zione(F<strong>un</strong>zione: TXML_F<strong>un</strong>zione): Boolean;<br />
f<strong>un</strong>ction Elimina_F<strong>un</strong>zione(F<strong>un</strong>zione: String): Boolean;<br />
121
f<strong>un</strong>ction Salva_File: Boolean;<br />
f<strong>un</strong>ction Carica_File(Co<strong>di</strong>ce: String): Boolean;<br />
end;<br />
L’array FF<strong>un</strong>zioni, <strong>di</strong> tipo string, serve a memorizzare in ogni stringa le<br />
f<strong>un</strong>zioni.<br />
Le variabili Nome e Percorso, <strong>di</strong> tipo string, memorizzano il nome e il<br />
<strong>per</strong>corso del file.<br />
La variabile Include è <strong>un</strong> array <strong>di</strong> tipo stringa. Questa serve a memorizzare<br />
quali sono le librerie <strong>di</strong> file dai quali il file, che si sta implementando, <strong>di</strong>pende.<br />
Le variavili Costanti e Variabili, due array <strong>di</strong> tipo TDato_Matrice, servono <strong>per</strong><br />
memorizzare le variabili e le costanti globali.<br />
L’array Strutture, <strong>di</strong> tipo TStrutture, serve a memorizzare le strutture<br />
implementate nel file. Il tipo TStrutture è <strong>un</strong> array <strong>di</strong> TDato_Matrice.<br />
I costruttori e il <strong>di</strong>struttore <strong>di</strong> classe f<strong>un</strong>ziona in maniera analoga a<br />
TXML_Progetto, ma, in questo caso, vengono inizializzate e <strong>di</strong>strutte le<br />
variabili proprie della classe.<br />
La f<strong>un</strong>zione Inserisci_F<strong>un</strong>zione riceve in input <strong>un</strong> dato TXML_F<strong>un</strong>zione, il<br />
quale viene memorizzato nella variabile FF<strong>un</strong>zioni, e rest<strong>it</strong>uisce <strong>un</strong> valore True<br />
se la memorizzazione avviene con successo, o False altrimenti.<br />
La f<strong>un</strong>zione Elimina_F<strong>un</strong>zione riceve in input <strong>un</strong>a stringa che identifica il<br />
nome della f<strong>un</strong>zione da eliminare e rest<strong>it</strong>uisce <strong>un</strong> valore True se la<br />
memorizzazione avviene con successo, o False altrimenti.<br />
La f<strong>un</strong>zione Salva_File rest<strong>it</strong>uisce <strong>un</strong> valore booleano: True se il file viene<br />
salvato o False altrimenti.<br />
122
La f<strong>un</strong>zione Carica_File, la quale riceve in input <strong>un</strong>a stringa, rest<strong>it</strong>uisce <strong>un</strong><br />
valore booleano in accordo all’es<strong>it</strong>o del recu<strong>per</strong>o dei dati memorizzati nella<br />
stringa Co<strong>di</strong>ce.<br />
4.4.3 Classe TXML_F<strong>un</strong>zione<br />
La classe TXML_F<strong>un</strong>zione rappresenta la f<strong>un</strong>zione implementata e la sua<br />
<strong>di</strong>chiarazione è come segue<br />
TXML_F<strong>un</strong>zione = class(TXMLDocument)<br />
private<br />
FForme: array of String;<br />
public<br />
constructor Create(AOwner: TComponent); overload; override;<br />
constructor Create(const AFileName: DOMString); reintroduce; overload;<br />
destructor Destroy; override;<br />
f<strong>un</strong>ction Inserisci_Forma(Forma: TForme): Boolean;<br />
f<strong>un</strong>ction Elimina_Forma(Forma: String): Boolean;<br />
f<strong>un</strong>ction Salva_F<strong>un</strong>zione: Boolean;<br />
f<strong>un</strong>ction Carica_F<strong>un</strong>zione(Co<strong>di</strong>ce: String): Boolean;<br />
end;<br />
L’array FForme <strong>di</strong> tipo string memorizza tutti i dati delle forme inser<strong>it</strong>e.<br />
I costruttori Create e il <strong>di</strong>struttore <strong>di</strong> classe Destroy f<strong>un</strong>ziona similarmente alla<br />
precedente classe, ma inizializza soltanto la variabile FForme.<br />
123
La f<strong>un</strong>zione Inserisci_Forma riceve in input <strong>un</strong> dato TForme e memorizza tutti<br />
i suoi dati in formato XML all’interno <strong>di</strong> FForme e rest<strong>it</strong>uisce True se la<br />
memorizzazione avviene con successo, o False altrimenti.<br />
La f<strong>un</strong>zione Elimina_Forma riceve in input il nome, <strong>di</strong> tipo stringa, interno <strong>di</strong><br />
<strong>un</strong> oggetto TForme <strong>per</strong> eliminarlo da FForme e rest<strong>it</strong>uisce True se la<br />
cancellazione avviene con successo, o False altrimenti.<br />
La f<strong>un</strong>zione Salva_F<strong>un</strong>zione rest<strong>it</strong>uisce <strong>un</strong> valore booleano: True se la<br />
f<strong>un</strong>zione viene salvata o False altrimenti.<br />
La f<strong>un</strong>zione Carica_F<strong>un</strong>zione, la quale riceve in input <strong>un</strong>a stringa, rest<strong>it</strong>uisce<br />
<strong>un</strong> valore booleano in accordo all’es<strong>it</strong>o del recu<strong>per</strong>o dei dati memorizzati nella<br />
stringa Co<strong>di</strong>ce.<br />
4.5 Implementazione sintetica dell’in<strong>di</strong>cizzatore <strong>di</strong> librerie<br />
L’in<strong>di</strong>cizzatore <strong>di</strong> librerie è <strong>un</strong> insieme <strong>di</strong> classi atte ad eseguire <strong>un</strong>a serie <strong>di</strong><br />
corrispondenze <strong>di</strong> testo tram<strong>it</strong>e le f<strong>un</strong>zioni <strong>di</strong> RegEx esternalizzate da <strong>un</strong>a<br />
libreria <strong>di</strong> Perl. Le classi, utilizzate dall’applicazione, sono: TC_Metodo,<br />
TC_Sorgente. Ogn<strong>un</strong>a <strong>di</strong> queste utilizza l’interfaccia IRegEx la quale incapsula<br />
le f<strong>un</strong>zioni, tra le tante, della libreria <strong>di</strong> corrispondenza: IsMatch, Match,<br />
Matches, Spl<strong>it</strong>, Pattern.<br />
Per definire la regulare expression, re<strong>per</strong>ire i prototipi e parametri accettati<br />
dalle f<strong>un</strong>zioni, sono state inizializzate alc<strong>un</strong>e stringhe:<br />
124
Tipi = '(void|signed char|char|signed short|short|signed int|int|signed long|long|long<br />
long|float|double)';<br />
VarNomeStr = '(\w+?)(((\s*)(\=(\s*)(.*))|));';<br />
Usando queste stringhe si sono inizializzate le interface IRegEx nella seguente<br />
maniera<br />
MetodoRegEx := RegexCreate(Tipi + '([\w\s]*)'+'(\s+?)(\&|)(\w*)(\s*?)\((.*)\)',<br />
[rcoSingleLine, rcoUngreedy]);<br />
VarRegEx := RegexCreate(‘var(\s+?)' + Tipi + '(\s+?)' + '(\**)'+ VarNomeStr ,<br />
[rcoSingleLine, rcoUngreedy]);<br />
Alla fine dell’analisi delle RegEx, tutti I dati vengono memorizzati in<br />
TC_Metodo, TC_Sorgente.<br />
4.5.1 Classe TC_Sorgente<br />
TC_Sorgente deriva da <strong>un</strong>’altra classe TC_Classe la quale definisce alc<strong>un</strong>i<br />
meto<strong>di</strong> interni ed è <strong>un</strong>a classe base, <strong>per</strong> TC_Sorgente, che contiene <strong>un</strong>a variabile<br />
FMeto<strong>di</strong> <strong>di</strong> tipo TObjectList, ovvero <strong>un</strong>a lista <strong>di</strong> oggetti. Per l’uso<br />
nell’applicativo, TC_Sorgente ha la seguente <strong>di</strong>chiarazione<br />
TC_Source = class(TC_Classe)<br />
protected<br />
f<strong>un</strong>ction Pren<strong>di</strong>_Meto<strong>di</strong>(Index: Integer): TC_Metodo; override;<br />
125
public<br />
pro<strong>per</strong>ty Meto<strong>di</strong>[Index: Integer]: TC_Metodo read Pren<strong>di</strong>_Meto<strong>di</strong>;<br />
constructor Create(const Testo_Sorgente: string); overload;<br />
destructor Destroy; override;<br />
end;<br />
la f<strong>un</strong>zione Pren<strong>di</strong>_Meto<strong>di</strong>, <strong>di</strong>chiarata override e con visibil<strong>it</strong>à protetta,<br />
sovrascrive la f<strong>un</strong>zione della classe base e fornisce il Metodo in<strong>di</strong>cato da Index<br />
quando si prova ad accedere alla proprietà Meto<strong>di</strong>.<br />
Il costruttore Create, <strong>di</strong>chiarata overload, riceve in input <strong>un</strong>a costante <strong>di</strong> tipo<br />
stringa e analizza il testo alla ricerca <strong>di</strong> prototipi. Questi, quando riscontrati,<br />
verrano inser<strong>it</strong>i in FMeto<strong>di</strong>.<br />
Il <strong>di</strong>struttore Destroy, <strong>di</strong>chiarato override, libera la memoria dalle variabili<br />
interne.<br />
4.5.2 Classe TC_Meto<strong>di</strong><br />
La classe TC_Meto<strong>di</strong> è <strong>un</strong>a classe che collezione i prototipi e la sua forma<br />
<strong>di</strong>chiarativa è la seguente<br />
TC_Method = class(TC_Ent<strong>it</strong>y)<br />
protected<br />
FMetodo_Nome: string;<br />
FMetodo_Prototipo: string;<br />
FMetodo_Corpo: string;<br />
FBracket_Inizio: Integer;<br />
FBracket_Fine : Integer;<br />
FParametri: array of TDato_Matrice<br />
126
FTipo: string;<br />
f<strong>un</strong>ction Pren<strong>di</strong>_Numero_Parametri: Integer;<br />
f<strong>un</strong>ction Pren<strong>di</strong>_Parametri(Index: Integer): TDato_Matrice;<br />
public<br />
pro<strong>per</strong>ty Nome: string read FMetodo_Nome;<br />
pro<strong>per</strong>ty Prototipo: string read FMetodo_Prototipo;<br />
pro<strong>per</strong>ty Corpo: string read FMetodo_Corpo;<br />
pro<strong>per</strong>ty Bracket_Inizio: Integer read FBracket_Inizio;<br />
pro<strong>per</strong>ty Bracket_Fine: Integer read FBracket_Fine<br />
pro<strong>per</strong>ty Numero_Parametri: Integer read Pren<strong>di</strong>_Numero_Parametri;<br />
pro<strong>per</strong>ty Parametri[Index: Integer]: TDato_Matrice read Pren<strong>di</strong>_Parametri;<br />
pro<strong>per</strong>ty Tipo: string read FTipo;<br />
constructor Create(Parent: TC_Classe;<br />
const Occorrenza: string; TextPos: Integer); overload; override;<br />
destructor Destroy; override;<br />
end;<br />
Le variabili FMetodo_Nome, FMetodo_Prototipo e FMetodo_Corpo e i loro<br />
omonimi con visibl<strong>it</strong>à pubblica, <strong>di</strong> tipo stringa, sono rispettivamente il nome, il<br />
prototipo e il corpo del prototipo trovato nella libreria analizzata.<br />
Le variabili FBracket_Inizio, e FBracket_Fine e i loro omonimi con visibil<strong>it</strong>à<br />
pubblica, <strong>di</strong> tipo intero, corrispondono ai p<strong>un</strong>ti, rispettivamente, dove comincia e<br />
finisce il corpo della f<strong>un</strong>zione.<br />
La variabile FTipo memorizza il tipo <strong>di</strong> dato in formato stringa e viene letto il<br />
suo valore me<strong>di</strong>ante la proprietà Tipo;<br />
La f<strong>un</strong>zione Pren<strong>di</strong>_Numero_Parametri, <strong>di</strong> tipo intero e con visibil<strong>it</strong>à protetta<br />
poiché incapsulata, fornisce il quant<strong>it</strong>ativo dei parametri richiesti dalla f<strong>un</strong>zione<br />
e viene invocato implic<strong>it</strong>amente quando viene usato la proprietà<br />
Numero_Parametri.<br />
127
La f<strong>un</strong>zione Pren<strong>di</strong>_Parametri, la quale accetta <strong>un</strong> valore <strong>di</strong> tipo intero ed ha<br />
<strong>un</strong>a visibil<strong>it</strong>à protetta, rest<strong>it</strong>uisce <strong>un</strong> dato <strong>di</strong> tipo TDato_Matrice. Questa<br />
f<strong>un</strong>zione fornisce il parametro memorizzato in FParametri e viene invocata<br />
implic<strong>it</strong>amente quando si usa la proprietà Parametri.<br />
Il costruttore Create, <strong>di</strong>chiarato override ed overload, riceve in input il<br />
proprietario della classe, <strong>di</strong> tipo TC_Classe, l’Occorrenza <strong>di</strong> tutto il prototipo<br />
rintracciato, <strong>di</strong> tipo stringa, e la posizione iniziale del testo in formato numerico<br />
intero.<br />
Il <strong>di</strong>struttore <strong>di</strong> classe Destroy libera la memoria <strong>di</strong> tutte le variabili usate dalla<br />
classe.<br />
4.6 Implementazione del Text E<strong>di</strong>tor<br />
Per l’implmentazione del componente Text E<strong>di</strong>tor, che serve a visualizzare il<br />
co<strong>di</strong>ce in formato html, si è derivata <strong>un</strong>a classe da TWebBrowser versione 6 e si<br />
sono incapsulate <strong>di</strong>verse variabili, proprietà ed eventi, ed <strong>un</strong>a serie <strong>di</strong> f<strong>un</strong>zioni e<br />
procedure secondo le specifiche delle librerie MSHTML della Microsoft.<br />
Si fornisce <strong>un</strong>a breve descrizione della classe, mostrando alc<strong>un</strong>e delle<br />
variabili, proprietà e f<strong>un</strong>zioni aggi<strong>un</strong>te<br />
TMioWebBrowser = class(TWebBrowser)<br />
private<br />
FRead_Only: Boolean;<br />
f<strong>un</strong>ction GetDocument1: IHTMLDocument;<br />
f<strong>un</strong>ction GetDocument2: IHTMLDocument2;<br />
128
f<strong>un</strong>ction GetDocument3: IHTMLDocument3;<br />
f<strong>un</strong>ction GetDocument4: IHTMLDocument4;<br />
f<strong>un</strong>ction GetDocument5: IHTMLDocument5;<br />
f<strong>un</strong>ction GetWindow2: IHTMLWindow2;<br />
f<strong>un</strong>ction GetWindow3: IHTMLWindow3;<br />
f<strong>un</strong>ction GetWindow4: IHTMLWindow4;<br />
f<strong>un</strong>ction GetElementById1(Id: String): IHTMLElement;<br />
f<strong>un</strong>ction GetElementById2(Id: String): IHTMLElement2;<br />
f<strong>un</strong>ction GetElementById3(Id: String): IHTMLElement3;<br />
f<strong>un</strong>ction GetElementById4(Id: String): IHTMLElement4;<br />
f<strong>un</strong>ction GetElementByName1(Id: String): IHTMLElement;<br />
f<strong>un</strong>ction GetElementByName2(Id: String): IHTMLElement2;<br />
f<strong>un</strong>ction GetElementByName3(Id: String): IHTMLElement3;<br />
f<strong>un</strong>ction GetElementByName4(Id: String): IHTMLElement4;<br />
f<strong>un</strong>ction GetElementByTagName1(Id: String): IHTMLElement;<br />
f<strong>un</strong>ction GetElementByTagName2(Id: String): IHTMLElement2;<br />
f<strong>un</strong>ction GetElementByTagName3(Id: String): IHTMLElement3;<br />
f<strong>un</strong>ction GetElementByTagName4(Id: String): IHTMLElement4;<br />
f<strong>un</strong>ction GetAttribute(IdElement, AttributeName: String): String;<br />
f<strong>un</strong>ction SetAttribute(IdElement, AttributeName, Value: String): Boolean;<br />
f<strong>un</strong>ction RemoveAttribute(IdElement, AttributeName: String): Boolean;<br />
pro<strong>per</strong>ty Document1: IHTMLDocument read GetDocument1;<br />
pro<strong>per</strong>ty Document2: IHTMLDocument2 read GetDocument2;<br />
pro<strong>per</strong>ty Document3: IHTMLDocument3 read GetDocument3;<br />
pro<strong>per</strong>ty Document4: IHTMLDocument4 read GetDocument4;<br />
pro<strong>per</strong>ty Document5: IHTMLDocument5 read GetDocument5;<br />
pro<strong>per</strong>ty Windows2: IHTMLWindow2 read GetWindow2;<br />
pro<strong>per</strong>ty Windows3: IHTMLWindow3 read GetWindow3;<br />
pro<strong>per</strong>ty Windows4: IHTMLWindow4 read GetWindow4;<br />
procedure AboutBlank;<br />
procedure Pulisci;<br />
procedure InserisciHtml(Testo: String);<br />
f<strong>un</strong>ction GetSelection: IHTMLSelectionObject;<br />
published<br />
pro<strong>per</strong>ty DesignMode: Boolean read FDesignMode wr<strong>it</strong>e SetDesignmode default False;<br />
129
pro<strong>per</strong>ty Read_Only: Boolean read FRead_Only wr<strong>it</strong>e SetRead_Only default False;<br />
pro<strong>per</strong>ty OnDocumentDocumentClick : TEventi1 read FOnDocumentDocumentClick wr<strong>it</strong>e<br />
SetOnDocumentDocumentClick ;<br />
pro<strong>per</strong>ty OnDocumentDoubleClick : TEventi1 read FOnDocumentDoubleClick wr<strong>it</strong>e<br />
SetOnDocumentDoubleClick ;<br />
end;<br />
La variabile FRead_Only, <strong>di</strong> tipo booleano, rende capace il component <strong>di</strong><br />
accettare o meno l’input dalla tastiera e viene mo<strong>di</strong>ficato quando si cambiare il<br />
valore <strong>di</strong> Read_Only, il quale invoca la procedura SetRead_Only che mo<strong>di</strong>fica il<br />
comportamento del componente oltre a cambiare il valore <strong>di</strong> FRead_Only.<br />
Le f<strong>un</strong>zioni GetDocumentX e GetWindowX, dove X è <strong>un</strong> numero da 1 a 5 <strong>per</strong><br />
GetDocument e da 2 a 4 <strong>per</strong> GetWindow, rest<strong>it</strong>uiscono delle interfacce che<br />
forniscono <strong>di</strong>verse f<strong>un</strong>zional<strong>it</strong>à, in accordo alla Microsoft, <strong>per</strong> poter agire sul<br />
componente e vengono invocate quando si cerca <strong>di</strong> ottenere <strong>un</strong> valore dalle<br />
proprietà DocumentX e WindowsX.<br />
Le f<strong>un</strong>zioni GetElementByIdX, GetElementByNameX e<br />
GetElementByTagNameX, dove X è <strong>un</strong> numero, richiedono in input <strong>un</strong>a stringa<br />
e forniscono <strong>un</strong>a interfaccia <strong>di</strong> tipo IHTMLElement, IHTMLElement2,<br />
IHTMLElement3 o IHTMLElement4. Queste servono <strong>per</strong> cercare degli elementi<br />
all’interno del co<strong>di</strong>ce HTML attraverso o l’Id, o il Nome o il loto TagName.<br />
La f<strong>un</strong>zione GetAttribute accetta in input due stringhe che identificano<br />
l’elemento e l’attributo <strong>di</strong> <strong>un</strong>a interfaccia IHTMLElementX e rest<strong>it</strong>uisce il<br />
valore dell’attributo.<br />
130
La f<strong>un</strong>zione SetAttribute, oltre ad accettare gli stessi valori <strong>di</strong> GetAttribute,<br />
accetta anche <strong>un</strong> input <strong>di</strong> tipo stringa, Value, il quale serve a settare il valore<br />
desiderato.<br />
La f<strong>un</strong>zione RemoveAttribute, riceve due stringhe le quali servono a<br />
identificare l’attributo da cancellare <strong>di</strong> <strong>un</strong> elemento html.<br />
La procedura AboutBlank <strong>per</strong>mette <strong>di</strong> inizializzare il componente <strong>per</strong><br />
<strong>per</strong>mettere <strong>di</strong> poter interagire con esso.<br />
La procedura Pulisci <strong>per</strong>mette <strong>di</strong> cancellare il contenuto html del componente<br />
e ,quin<strong>di</strong>, anche <strong>di</strong> ciò che visualizza.<br />
La procedura InserisciHtml riceve in input <strong>un</strong>a stringa e la inserisce nel corpo<br />
html.<br />
La f<strong>un</strong>zione GetSelection rest<strong>it</strong>uisce <strong>un</strong>’interfaccia che fornisce <strong>un</strong> elemento<br />
della selezione che si è resa nel componente..<br />
Le proprietà OnDocumentDocumentClick e OnDocumentDoubleClick<br />
servono <strong>per</strong> implementare gli eventi che rispondono all’interazione con l’utente.<br />
4.7 Implementazione delle caratteristiche del <strong>framework</strong><br />
Per far si che il <strong>framework</strong> svolga le caratteristiche <strong>di</strong>scusse, si sono<br />
implementate <strong>un</strong>a serie <strong>di</strong> f<strong>un</strong>zioni e procedure.<br />
L’applicativo, in fase <strong>di</strong> avvio, costruisce <strong>di</strong>namicamente i bottoni che servono<br />
<strong>per</strong> la creazione degli oggeti. Questi bottoni, cliccati due volte o trascinati<br />
nell’area <strong>di</strong> lavoro, creano le icone associate. Durante la creazione delle icone<br />
me<strong>di</strong>ante le f<strong>un</strong>zioni Crea_XXX, dove XXX è il costrutto desiderato, vengono<br />
131
assegnate alle proprietà delle icone <strong>un</strong>a serie <strong>di</strong> procedure che ne determinano il<br />
controllo. Ad esempio, quando si seleziona clicca <strong>un</strong>’icona, questa richiama gli<br />
eventi ControlClick, ControlMouseDown, ControlMouseUp e ControlMouseUp<br />
che determinano alc<strong>un</strong>i comportamenti e qualora si dovesse eseguire <strong>un</strong> doppio<br />
click sull’icona, verrà a<strong>per</strong>ta <strong>un</strong>a finestra, associata al tipo <strong>di</strong> icona, la quale<br />
<strong>per</strong>mette <strong>di</strong> interagire con essa e <strong>di</strong> assegnare il corretto co<strong>di</strong>ce del linguaggio C.<br />
Infatti, nella procedura <strong>di</strong> creazione delle icone, ad ogn<strong>un</strong>a <strong>di</strong> esse viene<br />
assegnato <strong>un</strong>a procedura DoubleClick_XXX, dove XXX è il costrutto associato.<br />
Inoltre, in fase <strong>di</strong> creazione viene anche associato all’icona <strong>un</strong> oggetto TPopUp,<br />
ovvero <strong>un</strong> menù a ten<strong>di</strong>na che si apre quando l’utente clicca l’icona col tasto<br />
destro del mouse. Questo menù, simile in tutte le icone, eccezion fatta <strong>per</strong><br />
alc<strong>un</strong>e, fornisce <strong>un</strong>a serie <strong>di</strong> possibil<strong>it</strong>à all’utente <strong>per</strong> interagire con le icone, ad<br />
esempio può collegare nel flusso le icone o eliminarle.<br />
Completano il quadro le classiche f<strong>un</strong>zioni <strong>di</strong> salvataggio del progetto e del<br />
file, nonché delle inizializzazioni <strong>di</strong> questi, oltre che la configurazione del<br />
progetto e dell’IDE e le f<strong>un</strong>zioni <strong>di</strong> compilazione e <strong>di</strong> avvio del programma<br />
sviluppato.<br />
132
Fig. 4.1 Esempio <strong>di</strong> <strong>un</strong> algor<strong>it</strong>mo creato con il <strong>framework</strong> con <strong>un</strong>a icona selezionata<br />
133
Conclusioni<br />
Nel corso della tesi si è voluto procedere all’analisi delle <strong>di</strong>fficoltà e delle<br />
caratteristiche che i linguaggi iconici possiedono partendo dallo stato dell’arte<br />
nel campo <strong>di</strong> tali linguaggi. Si è, d<strong>un</strong>que, costru<strong>it</strong>o <strong>un</strong> <strong>framework</strong> iconico che<br />
fornisca <strong>un</strong>a chiara e semplice rappresentazione del linguaggio, utile<br />
all’implementazione <strong>di</strong> algor<strong>it</strong>mi e software che, me<strong>di</strong>ante il proprio uso,<br />
costruisca <strong>un</strong> buon co<strong>di</strong>ce sorgente in linguaggio C. Inoltre, il <strong>framework</strong> si<br />
presta a essere utilizzato sia da principianti, che si accostano alla<br />
programmazione, sia da professionisti, in quanto, attraverso il linguaggio<br />
iconico, si evidenziano le logiche degli algor<strong>it</strong>mi che si sviluppano e i loro<br />
comportamenti. Infine, poiché il linguaggio iconico sfrutta <strong>un</strong>a modellazione<br />
tipica dei Diagrammi a blocchi, il <strong>framework</strong> si rivela utilizzabile anche in<br />
amb<strong>it</strong>o aziendale.<br />
Un ulteriore <strong>sviluppo</strong> è l’ampliamento del <strong>framework</strong> iconico affinché possa<br />
produrre il co<strong>di</strong>ce sorgente <strong>di</strong> altri linguaggi <strong>di</strong> programmazione quali: Pascal e<br />
Delphi, C++, Php, Java, JavaScript, Ruby, etc.<br />
134
Bibliografia<br />
Abelson H., Sussman G. J., Sussman J., Structure and Interpretation of<br />
Computer Programs. 2nd ed., MIT Press, Cambridge, 1996.<br />
Ae T., Yamash<strong>it</strong>a M., C<strong>un</strong>ha W. C., Matsumoto H., Visual user-interface<br />
of a programming system: MOPS-2, in Procee<strong>di</strong>ngs of IEEE Workshop<br />
on Visual Languages, Dallas, TX. IEEE CS Press, Silver Spring, 1986,<br />
pp. 44-53.<br />
Andries M., Engels G., Rekers J., Using graph grammars to represent<br />
visual programs, 1997.<br />
Antonietti A., Why does mental visualization facil<strong>it</strong>ate problem solving?,<br />
in R. H. Logie, M. Denis, Mental Images in Human Cogn<strong>it</strong>ion, Elsevier<br />
Science Publishers B. V., Amsterdam, 1991, pp. 211-227.<br />
Arnheim, R., Visual Thinking, Univers<strong>it</strong>y of California Press, Berkeley,<br />
1969.<br />
Aufaure-Portier M. A., A high level interface language of GIS, in Journal<br />
of Visual Languages and Computing, 1995, pp. 167-182.<br />
135
Badre A., Allen, J.. Graphic language representation and programming<br />
behavior, in S .Salvendy, M. J. Sm<strong>it</strong>h, Designing and Using Human-<br />
Computer Interfaces and Knowledge Based Systems, Elsevier Science<br />
Publishers, Amsterdam, 1989, pp. 59- 65.<br />
Bardohl R., Schultzke T., Taentzer G, Visual Language Parsing in<br />
GenGEd, in Procee<strong>di</strong>ngs of 2nd International Workshop on Graph<br />
Transformation and Visual Modeling Techniques GT-VMT ‘01, Creta,<br />
2001.<br />
Barwise J., Etchemendy J., Hy<strong>per</strong>proof, Cambridge Univers<strong>it</strong>y Press,<br />
Cambridge, 1994<br />
Barwise, J., Etchemendy J., Heterogeneous logic. In Diagrammatic<br />
Reasoning: Cogn<strong>it</strong>ive and Computational Perspectives. J. Glasgow, N. H.<br />
Narayanan, B. Chandrasekaran, (Eds.), AAAI Press, Menlo Park, CA and<br />
MIT Press, Cambridge, 1995, pp. 211-234.<br />
Beguelin A., Nutt G., Visual parallel programming and determinacy: a<br />
language specification, an analysis technique, and a programming tool,<br />
Journal of Parallel and Distributed Computing, 1994, pp. 235-250.<br />
136
Bertin, J., Semiology of Graphics. Traduzione inglese <strong>di</strong> W. J. Berg,<br />
Univers<strong>it</strong>à <strong>di</strong> Wisconsin Press, Ma<strong>di</strong>son, WI, 1983.<br />
Blackwell A. F., Metacogn<strong>it</strong>ive theories of visual programming: What do<br />
we think we are doing?, Proc. IEEE Symposium on Visual Languages,<br />
IEEE Computer Society Press, 1996, pp. 240-246.<br />
Bottoni P., Costabile M. F., Levial<strong>di</strong> S., Mussio P., Formalizing visual<br />
languages, Proc. IEEE Symposium on Visual Languages, IEEE Computer<br />
Society Press, 1995, pp. 45-52.<br />
Bottoni P., Costabile M. F., Levial<strong>di</strong> S., Mussio P., Specification of visual<br />
languages as means for interaction, Springer-Verlag New York, Inc. New<br />
York, New York, 1998.<br />
Bottoni P., Costabile M. F., Mussio P.,Specification and <strong>di</strong>alogue control<br />
of visual interaction through visual rewr<strong>it</strong>ing systems, ACM TOPLAS,<br />
1999, pp. 1077-1136.<br />
Brooks F. P.,No silver bullet: Essence and accidents of software<br />
engineering, IEEE Computer, 1987, pp. 10-19.<br />
Brown M. H., Sedgewick R., Techniques for algor<strong>it</strong>hm animation. IEEE<br />
Software, 1985, pp. 28-38.<br />
137
Byrne M. D., Catrambone R., Stasko J. T., Do algor<strong>it</strong>hm animations aid<br />
learning?, Tech. Rep. GIT-GVU-96-18, GVU Center, Georgia Inst<strong>it</strong>ute of<br />
Technology, Atlanta, 1996.<br />
CACM, Special section on educational technology, Com<strong>un</strong>icazioni<br />
dell’ACM, 1996.<br />
Chang S. K., Costagliola G., Pacini G., Tortora G., Tucci M., Yu B., Yu J.<br />
S., A visual language system for user interfaces, IEEE Software, Vol. 12 ,<br />
1995, pp. 33-44.<br />
Chang S. K., Exten<strong>di</strong>ng visual languages of multime<strong>di</strong>a, IEEE<br />
Multime<strong>di</strong>a, 1996, pp. 18-26.<br />
Chang S. K., Polese G., Orefice S., Tucci M., A methodology and<br />
interactive environment for iconic language design, in International<br />
Journal of Human Computer Stu<strong>di</strong>es, 1994, pp. 683-716.<br />
Chang S. K., Polese G., Thomas R., Das S., A visual language for<br />
authorization modeling, in Procee<strong>di</strong>ngs of 13esimo IEEE Symposium of<br />
Visual Languages, Capri, 1997pp. 110-118.<br />
Chang S. K., Tauber M. J., Yu B., Yu J. S., A visual language compiler, in<br />
IEEE Transactions on Software Engineering, 1989, pp. 506-525.<br />
138
Chang S. K., Visual languages: A tutorial and survey, IEEE Software,<br />
1987, pp. 29-39.<br />
Costagliola G., Delucia A., Orefice S., Polese G., A Classification<br />
Framework to Support the Design of Visual Languages, Journal of Visual<br />
Languages and Computing 2002, pp. 573-600.<br />
Costagliola G., Tortora G., Orefice S., De Lucia A., A parsing<br />
methodology for the implementation of visual systems, IEEE Transactions<br />
on Software Engineering, Vol. 23, 1997, pp. 777-799.<br />
Costagliola G., Tortora G., Orefice S., De Lucia A., Automatic generation<br />
of visual programming environments, IEEE Computer Vol. 28, 1995, pp.<br />
56-66.<br />
Crimi C., Guercio A., Pacini G., Tortora G., Tucci M., Automating visual<br />
language generation, IEEE Transactions on Software Engineering Vol.<br />
161, 1990, pp. 1122-1135.<br />
C<strong>un</strong>niff N., Taylor R. P., Black J. B., Does programming language affect<br />
the type of conceptual bugs in begineers’ programs? A comparison of<br />
APL and Pascal, in Procee<strong>di</strong>ngs of SIGCHI ’86, Human Factors in<br />
Computing Systems, Boston, 1986, pp. 175-182.<br />
139
Davis M.,Me<strong>di</strong>a stream: an iconic visual language for video annotation,<br />
in Procee<strong>di</strong>ngs of IEEE Symposium of Visual Languages. IEEE CS<br />
Press, Silver Spring, 1993, pp. 196-201.<br />
Dinesh T. B., Üsküdarli S., Specifying input and output of visual<br />
languages, Dipartimento <strong>di</strong> Software Technology, Amsterdam, 1997.<br />
Diskin Z., Da<strong>di</strong>sh B., Piessens F., Johnson M.,Universal arrow<br />
fo<strong>un</strong>dations for visual modeling, in Theory and Application of Diagrams<br />
in M. Anderson, P. Cheng, V. Haarslev. Springer, Berlino, 2000, pp. 345-<br />
360.<br />
Douglas S., H<strong>un</strong>dhausen C., McKeown D., Toward empirically-based<br />
software visualization languages, Proc. IEEE Symposium on Visual<br />
Languages, IEEE Computer Society Press, 1995, pp. 342-349.<br />
Douglass B.P., Real Time Uml, Ad<strong>di</strong>son Wesley, 2004.<br />
Ebert J., Winter A., Dahm P., Franzke A., Süttenbach R., Graph based<br />
modeling and implementation w<strong>it</strong>h EER/GRAK, in: Procee<strong>di</strong>ngs of<br />
ER’96,B.Thalheim, Springer, Berlino, 1996, pp. 163-178.<br />
Engelhardt Y., Bruin J., Janssen T., Scha, R., The visual grammar of<br />
information graphics, in N. H. Narayanan, J. Damski, Proc. AID’96<br />
140
Workshop on Visual Representation, Reasoning and Interaction in<br />
Design, Key Center for Design Computing, Univers<strong>it</strong>à <strong>di</strong> Sydney, 1996<br />
Erwig M., Meyer B., Heterogeneous visual languages: Integrating visual<br />
and textual programming, Proc. IEEE Symposium on Visual Languages,<br />
IEEE Computer Society Press, 1995, pp. 318-325.<br />
Feder J., Plex languages, Information Science, Elsevier Science Inc. New<br />
York, 1971, pp. 225-241.<br />
Ferguson R. I., H<strong>un</strong>ter A., Hardy C., MetaBuilder: the <strong>di</strong>agrammer’s<br />
<strong>di</strong>agrammer, in Theory and Application of Diagrams, M. Anderson, P.<br />
Cheng,V. Haarslev, Springer, Berlino, 2000, pp. 407-421.<br />
Fowler M., Uml Distilled, Ad<strong>di</strong>son Wesley, 2003.<br />
Frank M. R., Foley J. D., A pure reasoning engine for programming by<br />
example, Tech. Rep. GIT-GVU-94-11, GVU Center, Georgia Inst<strong>it</strong>ute of<br />
Technology, Atlanta, 1994.<br />
Freeman E., Gelernter D., Jagannathan S., In search of a simple visual<br />
vocabulary, Proc. IEEE Symposium on Visual Languages, IEEE<br />
Computer Society Press, 1995, pp. 302-309.<br />
141
Fuk<strong>un</strong>aga S., Kimura T. D., Pree W., Object-oriented development of a<br />
data flow visual language systems, in Procee<strong>di</strong>ngs of IEEE Symposium of<br />
Visual Languages. IEEE CS Press, Silver Spring,, 1993, pp. 134-141.<br />
Furnas G., New graphical reasoning models for <strong>un</strong>derstan<strong>di</strong>ng graphical<br />
interfaces, Proc.Human Factors in Computing Systems Conference<br />
(CHI’91), ACM Press, 1991, pp. 71-78.<br />
Furnas G., Reasoning w<strong>it</strong>h <strong>di</strong>agrams only, Proc. AAAI Spring<br />
Symposium on Reasoning w<strong>it</strong>h Diagrammatic Representations, AAAI<br />
Technical Report SS-92-02, AAAI Press, Menlo Park, 1992, pp. 118-123.<br />
Gero J. S., Yan M., Shape emergence by symbolic reasoning,<br />
Environment and Planning B: Planning and Design, 1994, pp. 191-218.<br />
Ghezzi C., Pezzeè M., Cabernet: an environment for the specification and<br />
verification of real-time systems, in DECUS Europe Symposium, Cannes,<br />
1992.<br />
Ghezzi G., Mandrioli D., Morasca S., Pezzeè M., A <strong>un</strong>ified high-level<br />
Petri net formalism for time-cr<strong>it</strong>ical systems, IEEE Transactions on<br />
Software Engineering, Vol. 17, 1991.<br />
142
Glasgow J., Narayanan N. H., Chandrasekaran B., Diagrammatic<br />
Reasoning: Cogn<strong>it</strong>ive and Computational Perspectives. AAAI Press,<br />
Menlo Park, CA and MIT Press, Cambridge, 1995.<br />
Glinert E. P., Nontextual programming environments, in S. K. Chang,<br />
Principles of Visual Programming Systems, Prentice-Hall, 1990, pp. 144-<br />
230.<br />
Glinert E. P., Tanimoto L., Pict: an interactive graphical programming<br />
environment, IEEE Computer, Vol. 17, 1984, pp. 7-25.<br />
Glinert E., Towards second generation interactive graphical<br />
programming environments, in Procee<strong>di</strong>ngs of IEEE Workshop on Visual<br />
Language, IEEE CS Press, Silver Spring, 1986, pp. 61-70.<br />
Goel V., Sketches of Thought, MIT Press, Cambridge, 1995.<br />
Goldman N., Balzer R., The ISI visual design e<strong>di</strong>tor generator, In<br />
Procee<strong>di</strong>ngs of IEEE Symposium on Visual Languages, Tokyo, 1999, pp.<br />
20-27.<br />
Golin E. J., Magliery T., A compiler generator for visual languages, in<br />
Procee<strong>di</strong>ngs of IEEE Workshop on Visual Languages, Bergen, 1993, pp.<br />
314-321.<br />
143
Gombrich E. H., Art and Illusion: A Study in the Psychology of Pictorial<br />
Representations. Phaidon, Londra, 1968.<br />
Gooday J. M., Cohn A. G., Visual language syntax and semantics: A<br />
spatial logic approach, Divisione <strong>di</strong> Articifial Intelligence, Univers<strong>it</strong>y of<br />
Leeds, Leeds, 1997.<br />
Goodman N., Languages of Art: An Approach to a Theory of Symbols,<br />
Hackett Publishing Company, In<strong>di</strong>anapolis, 1976.<br />
Graf M., A visual environment for the design of <strong>di</strong>stributed systems, in<br />
Procee<strong>di</strong>ngs of IEEE Workshop on Visual Languages, Linkoping,<br />
Sweden. IEEE CS Press, Silver Spring, 1987, pp. 330-344.<br />
Green T. R. G., Cogn<strong>it</strong>ive <strong>di</strong>mensions of notations, in A. Sutcliffe e L.<br />
Macaulay,People and Computers V., Cambridge, Cambridge Univers<strong>it</strong>y<br />
Press, 1989, pp 443-460. Green T. R. G., Petre M., When visual programs<br />
are harder to read than textual programs, in G. C. van der Veer, M. J.<br />
Tauber, S. Bagnarola, M. Antavol<strong>it</strong>s, Human-Computer Interaction:<br />
Tasks and Organization, Proc. 6th European Conference on Cogn<strong>it</strong>ive<br />
Ergonomics, 1992, pp.167-180.<br />
144
Green T. R. G., Petre M., Bellamy R. K. E., Comprehensibil<strong>it</strong>y of visual<br />
and textual programs: A test of su<strong>per</strong>lativism against the match-mismatch<br />
conjecture, in J. Koenemann- Belliveau, T. G. Moher, S. P. Robertson,<br />
Proc. Fourth Workshop on Empirical Stu<strong>di</strong>es of Programmers, Ablex<br />
Publishers, 1992.<br />
Green, T. R. G., Petre M., Usabil<strong>it</strong>y analysis of visual programming<br />
environments: A cogn<strong>it</strong>ive <strong>di</strong>mensions <strong>framework</strong>. Journal of Visual<br />
Languages and Computing. 1996, pp. 131-174.<br />
Gross M., The fat pencil, the cocktail napkin, and the slide library, in A.<br />
Harfmann, M. Fraser, Proc. ACADIA 94, Association for Computer<br />
Aided Design in Arch<strong>it</strong>ecture, 1994, pp.103-113.<br />
Gurr C. A., On the isomorphism (or otherwise) of representations, 1997.<br />
Haarslev V., A fully formalized theory for describing visual notations,<br />
International Workshop on the Theory of Visual Languages, Gubbio,<br />
1996.<br />
Hammer E., Logic and visual information. In Stu<strong>di</strong>es in Logic, Language,<br />
Computation, CSLI Press, Stanford Univers<strong>it</strong>y, California, 1995.<br />
145
Harel D., On visual formalisms. Comm<strong>un</strong>ications of the ACM, 1988, pp.<br />
514-530.<br />
Harel D., Statecharts: a visual formalism for complex system, Science of<br />
Computer Programming, Elseiver Science Publishers B.V. 1987, 231-274.<br />
Hegarty M., Just M. A., Constructing mental models of machines from<br />
text and <strong>di</strong>agrams, Journal of Memory and Language, 1993, pp. 717-742.<br />
Hegarty M., Mental animation: Inferring motion from static <strong>di</strong>splays of<br />
mechanical systems, Journal of Ex<strong>per</strong>imental Psychology: Learning,<br />
Memory, Cogn<strong>it</strong>ion, 1992, pp. 1084-1102.<br />
Hirakawa M., Tanaka M., Hichikawa T., An iconic programming<br />
system,HI-VISUAL, in IEEE Transactions on Software Engineering, 1990,<br />
pp. 178-184.<br />
Hix, D., Hartson H. R., Developing User Interfaces: Ensuring Usabil<strong>it</strong>y<br />
Through Product & Process, John Wiley & Sons, Inc., New York, 1993.<br />
Hübscher R., Composing complex behavior from simple visual<br />
descriptions, Proc. IEEE Symposium on Visual Languages, IEEE<br />
Computer Society Press, 1996, pp. 88-94.<br />
146
Hübscher R., Rewr<strong>it</strong>ing interaction, Proc. Human Factors in Computing<br />
Systems Conference (CHI’95), ACM Press, 1995.<br />
Huttenlocher J., Constructing spatial images: A strategy in reasoning,<br />
Psychological Review, 1968, pp. 550-560.<br />
Jacob R. J. K., A state trans<strong>it</strong>ion <strong>di</strong>agram language for visual<br />
programming, IEEE Computer, Vol. 18, 1985, pp. 51-59.<br />
Johnson S. C., YACC: Yet another compiler compiler, Tech. Report 32,<br />
AT&T Bell Laboratories, Murray Hills, 1975.<br />
Joseph S. H., Pridmore T. P., Knowledge-<strong>di</strong>rected interpretation of<br />
mechanical engineering drawings, IEEE Trans. on Pattern Analysis and<br />
Machine Intelligence, 1992, pp. 928-940.<br />
Kahn K. M., Saraswat V. A., Complete visualizations of concurrent<br />
programs and their executions, Proc. IEEE Symposium on Visual<br />
Languages, IEEE Computer Society Press, 1990, pp. 7-14.<br />
Karsai G., A configurable visual programming environment: a tool for<br />
domain specific programming, IEEE Computer, Vol 28, 1995, pp. 36-44.<br />
147
Kimura T. D., Apte A., Sengupta S., Chan J. W., Form/formula: a visual<br />
programming para<strong>di</strong>gm for user-definable user interfaces, IEEE<br />
Computer, Vol. 28, 1995, pp. 27-35.<br />
Kimura T. D., Hy<strong>per</strong>Flow: a visual programming language for pen<br />
computers, in Procee<strong>di</strong>ngs of IEEE Workshop on Visual Languages,<br />
Seattle,Washington. IEEE CS Press, Silver Spring, 1992, pp. 125-132.<br />
Kimura T. D., J Choi.W., Mack J. M., A visual language of keyboard-less<br />
programming, in Technical report WUCS-86-6, Department of Computer<br />
Science, Washington Univers<strong>it</strong>y, St. Louis, 1986.<br />
Koe<strong>di</strong>nger K. R.,. Emergent pro<strong>per</strong>ties and structural constraints:<br />
Advantages of <strong>di</strong>agrammatic representations for reasoning and learning,<br />
Proc. AAAI Spring Symposium on Reasoning w<strong>it</strong>h Diagrammatic<br />
Representations, AAAI Technical Report SS-92-02, AAAI Press, Menlo<br />
Park, 1992, pp. 154-169.<br />
Larkin J. H., Simon H. A., Why a <strong>di</strong>agram is (sometimes) worth ten<br />
thousand words, Cogn<strong>it</strong>ive Science, Carnegie-Mellon Univers<strong>it</strong>y, 1987,<br />
pp. 65-99.<br />
148
Larkin J., Display based problem solving, in D. Klahr, K. Kotovsky,<br />
Complex Information Processing, Lawrence Erlbaum Publishers,<br />
Hillsdale, New York, 1989.<br />
Larman C., Applying UML and Patterns, Prentice Hall, 2005.<br />
Lohse G. I., Biolsi K., Walker N., Rueler H. H., A classification of visual<br />
representations. Com<strong>un</strong>icazioni dell’ACM, 1994, pp. 36-49.<br />
Lowe R. K., Constructing a mental representation from an abstract<br />
technical <strong>di</strong>agram, Learning and Instruction, Curtin Univers<strong>it</strong>y, Perth,<br />
1993, pp. 157-179.<br />
Lowe R. K., Selectiv<strong>it</strong>y in <strong>di</strong>agrams: Rea<strong>di</strong>ng beyond the lines, in<br />
Educational Psychology: An International Journal of Ex<strong>per</strong>imental<br />
Educational Psychology, 1994, pp. 467-491.<br />
Ludolph F., Chow Y.Y., Ingalls D., Wallace S., Doyle J., The fabrik<br />
programming environment , in Procee<strong>di</strong>ngs of IEEE Workshop on Visual<br />
Language, P<strong>it</strong>tsburgh, PA. IEEE CS Press, Silver Spring, 1988, pp. 222-<br />
230.<br />
149
Mahling D. E., Fisher D. L., The cogn<strong>it</strong>ive engineering of visual<br />
languages, Proc. IEEE Symposium on Visual Languages, IEEE Computer<br />
Society Press, 1990, pp. 22-28.<br />
Maimone M.W., Tygar J. D., Wing J. M., Micro Semantics fors ecur<strong>it</strong>y, in<br />
Procee<strong>di</strong>ngs of IEEE Workshop on Visual Languages, P<strong>it</strong>tsburgh, PA.<br />
IEEE CS Press, Silver Spring, 1988, pp. 45-51.<br />
Marriott K., Meyer B., The CCMG visual language hierarchy, in Visual<br />
Language Theory, K.Marriot, B. Meyer, Springer, 1998.<br />
Marriott K., Meyer B., Towards a hierarchy of visual languages,<br />
Dipartimento <strong>di</strong> Computer Science, Monash Univers<strong>it</strong>y, Clayton, 1997.<br />
Marriott K., Meyer B., W<strong>it</strong>tenburg K., A survey of visual language<br />
specification and recogn<strong>it</strong>ion, Springer-Verlag New York, Inc. New<br />
York, New York, 1998, pp. 5-85.<br />
Marriott K., Meyer B., W<strong>it</strong>tenburg K., A survey of visual language<br />
specification and recogn<strong>it</strong>ion, in Visual Language Theory, K.Marriot, B.<br />
Meyer, Springer, 1998.<br />
Martin R., Uml for Java Programmers, Prentice Hall, 2003.<br />
McCorduck P., Aaron's Code, Freeman, San Francisco, 1991.<br />
150
Menzies T., Frameworks for Assessing Visual Languages. Technical<br />
Report TR95-35, Department of Software Development, Monash<br />
Univers<strong>it</strong>y, 1995.<br />
Meyer B., Pictures depicting pictures: On the specification of visual<br />
languages by visual grammars Technical Report No. 139, Informatik<br />
Berichte, FernUnivers<strong>it</strong>at, Hagen, 1993 , (In <strong>un</strong>a versione più corta appare<br />
in Proc. 1992 IEEE Symposium on Visual Languages, IEEE Computer<br />
Society Press, pp. 41-47.<br />
Minas M., Concepts and realization of a <strong>di</strong>agram e<strong>di</strong>tor generator based<br />
on hy<strong>per</strong>graph transformation. Science of Computer Programming, to<br />
appear, Elsevier North-Holland, Amsterdam, 2002.<br />
Moriconi M., Hare D. F., Visualizing program design through PegaSys,<br />
IEEE Computer, Vol. 18, 1985, pp. 72-85.<br />
Musen M. A., Fagen L. M., Shortliffe E. H., Graphical specification of<br />
procedural knowledge for an ex<strong>per</strong>t system, in Procee<strong>di</strong>ngs of IEEE<br />
Workshop on Visual Languages, Dallas, 1986, pp. 167-178.<br />
151
Myers B., Visual programming, programming by example and program<br />
visualization: A taxonomy. Proc. Human Factors in Computing Systems<br />
Conference (CHI’86), ACM Press, 1986, pp. 59-66.<br />
Najork M., Golin E. J., Enhancing show-and-tell w<strong>it</strong>h a polymorphic type<br />
system and higher order f<strong>un</strong>ctions, in Procee<strong>di</strong>ngs of IEEE Workshop on<br />
Visual Languages, Skokie, 1990.<br />
Narayanan H. N., Hübscher R., Visual language theory: towards a<br />
Human-Computer interaction <strong>per</strong>spective, Technical Report CSE97-05,<br />
1997.<br />
Narayanan N. H., Hegarty M., On designing comprehensible interactive<br />
hy<strong>per</strong>me<strong>di</strong>a manuals. International Journal of Human-Computer Stu<strong>di</strong>es,<br />
Associate E<strong>di</strong>tor, 1998, pp. 267-301.<br />
Narayanan N. H., Proc. AAAI Spring Symposium on Reasoning w<strong>it</strong>h<br />
Diagrammatic Representations. AAAI Technical Report SS-92-02, AAAI<br />
Press, Menlo Park, 1992.<br />
Narayanan N. H., Suwa M., Motoda H., A study of <strong>di</strong>agrammatic<br />
reasoning from verbal and gestural protocols, Proc. 16th Annual<br />
152
Conference of the Cogn<strong>it</strong>ive Science Society, Lawrence Erlbaum<br />
Associates, 1994, pp. 652-657.<br />
Narayanan N. H., Suwa M., Motoda H., How things appear to work:<br />
Pre<strong>di</strong>cting behaviors from device <strong>di</strong>agrams.,Proc. 12th National<br />
Conference on Artificial Intelligence, AAAI Press, 1994, pp. 1161-1167.<br />
Narayanan N. H., Suwa M., Motoda, H., Diagram-based problem solving:<br />
The case of an impossible problem, Proc. 17th Annual Conference of the<br />
Cogn<strong>it</strong>ive Science Society, Lawrence Erlbaum Associates, 1995, pp. 206-<br />
211.<br />
Narayanan N. H., Suwa, M., Motoda, H., Behavior hypothesis from<br />
schematic <strong>di</strong>agrams, in Diagrammatic Reasoning: Cogn<strong>it</strong>ive and<br />
Computational Perspectives, J. Glasgow, N. H. Narayanan, B.<br />
Chandrasekaran, (Eds.) AAAI Press and MIT Press, 1995, pp. 501 -534.<br />
Nassi I., Shneiderman B., Flowchart techniques for structured<br />
programming, in ACM SIGPLAN Notice, 1973, pp. 12-26.<br />
Newell A., Simon H. A., Human Problem Solving, Prentice-Hall,<br />
Englewood Cliffs, 1972.<br />
153
Newman W. M., Lamming M. G., Interactive System Design. Ad<strong>di</strong>son-<br />
Wesley, Wokingham, 1995.<br />
Nickerson J. V., Visual programming: Lim<strong>it</strong>s of graphic representation,<br />
Proc. IEEE Symposium on Visual Languages, IEEE Computer Society<br />
Press, 1994, pp. 178-179.<br />
Norman D. A., Cogn<strong>it</strong>ive engineering, in D. A. Norman, S. W. Dra<strong>per</strong>,<br />
User Centered System Design, Lawrence Erlbaum Associates, Hillsdale,<br />
1986, pp. 31-65.<br />
Norman D. A., The Psychology of Everyday Things, Basic Books, New<br />
York, 1988.<br />
Novak G. S., Bulko W. C., Diagrams and text as computer input, Journal<br />
of Visual Languages and Computing, 1993, pp. 161-175.<br />
Petre M., Blackwell A. F., Green T. R. G., Cogn<strong>it</strong>ive questions in software<br />
visualization, in J. Stasko, J. Domingue, B. Price, M. Brown, Software<br />
Visualization: Programming as a Multi-Me<strong>di</strong>a Ex<strong>per</strong>ience, MIT Press.<br />
Petre M., Why looking isn't always seeing: Readership skills and<br />
graphical programming. Comm<strong>un</strong>ications of the ACM, 1995, pp. 33-44.<br />
154
Pietrzykowsky T., Matwin S., Muldner T., The programming language<br />
PROGRAPH: yet another application of graphics, in Procee<strong>di</strong>ngs of<br />
Graphics Interface ‘83, Edomonton, 1983, pp. 143-145.<br />
Price B. A., Baecker R. M., Small I. S., A principled taxonomy of software<br />
visualization. Journal of Visual Languages and Computing, 1993, pp.<br />
211-266.<br />
Puigsegur J., Agusti J., Robertson, D., A visual programming language,<br />
Proc. IEEE Symposium on Visual Languages, IEEE Computer Society<br />
Press, 1996, pp. 214-215.<br />
Raymond D. R., Characterizing visual languages, Proc. IEEE Symposium<br />
on Visual Languages, IEEE Computer Society Press, 1991, pp. 176-182.<br />
Repenning A., Ben<strong>di</strong>ng the rules: Steps toward semantically enriched<br />
graphical rewr<strong>it</strong>e rules, Proc. IEEE Symposium on Visual Languages,<br />
IEEE Computer Society Press, 1995, pp. 226- 233.<br />
Repenning A., Sumner T., Agentsheets: A me<strong>di</strong>um for creating domain-<br />
oriented visual languages, IEEE Computer, 1995, pp. 17-25.<br />
Resnick M., Beyond the centralized mindset, Journal of the Learning<br />
Sciences, 1996, pp. 1-22.<br />
155
Robertson G. G., Card S. K., Mackinlay J. D., Information visualization<br />
using 3D interactive animation, Comm<strong>un</strong>ications of the ACM, 1993, pp.<br />
57-71.<br />
Rohr G., Using visual concepts, in Visual Languages , S. K. Chang, T.<br />
Ichikawa, P. Ligomenides, Plenum, NewYork., 1986.<br />
Ross D.T., Schoman K. E. Jr, Structured analysis for requirement<br />
defin<strong>it</strong>ion, IEEE Transactions on Software Engineering, 1977, pp. 6-15.<br />
Rumbaugh J., Jacobson I., Booch G., The Unified Modeling Language<br />
Reference Manual, Ad<strong>di</strong>son-Wesley Object Technology Series, Ad<strong>di</strong>son-<br />
Wesley, 1998.<br />
Rumbaugh J., Jacobson I., Booch G., The Unified Modelling Language<br />
Reference manual, Ad<strong>di</strong>son Wesley, 2005.<br />
Saint-Martin F., Semiotics of Visual Language. In<strong>di</strong>ana Univers<strong>it</strong>y Press,<br />
Bloomington, 1990.<br />
Schwartz D. L., Black J. B., Analog imagery in mental model reasoning:<br />
Depictive models, Cogn<strong>it</strong>ive Psychology, 1996, pp. 154-219.<br />
Selker T., Koved L., Elements of visual language, Proc. IEEE Symposium<br />
on Visual Languages, IEEE Computer Society Press, 1988, pp. 38-44.<br />
156
Shepard R. N., Coo<strong>per</strong> L. A., Mental Images and Their Transformations,<br />
MIT Press, Cambridge, 1986.<br />
Shin S.J., The Logical Status of Diagrams. Cambridge Univers<strong>it</strong>y Press,<br />
Cambridge, 1994.<br />
Shu N. C., Visual programming languages: A <strong>per</strong>spective and a<br />
<strong>di</strong>mensional analysis, in S. K. Chang, T. Ichikawa, P. A. Ligomenides,<br />
Visual Languages, Plenum Publishing Corporation, New York, 1986, pp.<br />
11-34.<br />
Sinha A., Vessey I., Cogn<strong>it</strong>ive f<strong>it</strong> in recursion and <strong>it</strong>eration: An empirical<br />
study, IEEE Trans. on Software Engineering, 1992, pp. 386-379.<br />
Sm<strong>it</strong>h D. C., Cypher A., Spohrer J., Kidsim: Programming agents w<strong>it</strong>hout<br />
a programming language, Comm<strong>un</strong>ications of the ACM, 1994, pp. 54-68.<br />
Sm<strong>it</strong>h D. N., Visual programming in the interface construction, in<br />
Procee<strong>di</strong>ngs of IEEE Workshop on Visual Languages, P<strong>it</strong>tsburgh, PA.<br />
IEEE CS Press, Silver Spring, 1988, pp.109-120.<br />
Sm<strong>it</strong>h R. B., The alternate real<strong>it</strong>y k<strong>it</strong>: An animated environment for<br />
creating interactive simulations, Proc. IEEE Symposium on Visual<br />
Languages, IEEE Computer Society Press, 1986, pp. 99-106.<br />
157
Steinman S., Carver K.,. Visual programming w<strong>it</strong>h Prograph CPX,<br />
Manning Publications/Prentice Hall, Englewood Cliffs, 1995.<br />
Stenning K., Cox R., Oberlander J., Contrasting the cogn<strong>it</strong>ive effects of<br />
graphical and sentential logic teaching: Reasoning, representation and<br />
in<strong>di</strong>vidual <strong>di</strong>fferences, Language and Cogn<strong>it</strong>ive Processes, 1995, pp. 333-<br />
354.<br />
Stenning K., Oberlander J., A cogn<strong>it</strong>ive theory of graphical and linguistic<br />
reasoning: Logic and implementation, Cogn<strong>it</strong>ive Science, 1995, pp. 97-<br />
140.<br />
Tessler S., Iwasaki Y., Law K., Qual<strong>it</strong>ative structural analysis using<br />
<strong>di</strong>agrammatic reasoning, in Diagrammatic Reasoning: Cogn<strong>it</strong>ive and<br />
Computational Perspectives, J . Glasgow, N. H. Narayanan, B.<br />
Chandrasekaran, (Eds.), AAAI Press and MIT Press, 1995, pp. 711-730.<br />
Tufte E. R., The Visual Display of Quant<strong>it</strong>ative Information, Graphics<br />
Press, Cheshire, 1983.<br />
Tufte E. R., Visual Explanations, Graphics Press, Cheshire, 1997.<br />
Tufte E. R., Envisioning Information, Graphics Press, Cheshire, 1990.<br />
158
Tversky B., Cogn<strong>it</strong>ive origins of graphic productions, in F. T. Marchese,<br />
Understan<strong>di</strong>ng Images: Fin<strong>di</strong>ng Meaning in Dig<strong>it</strong>al Imagery, Springer-<br />
Verlag, New York, 1995, pp. 29-53.<br />
Wang D., Lee J. R., Zeevat H., Reasoning w<strong>it</strong>h <strong>di</strong>agrammatic<br />
representations, in Diagrammatic Reasoning: Cogn<strong>it</strong>ive and<br />
Computational Perspectives, J. Glasgow, N. H. Narayanan, B.<br />
Chandrasekaran, (Eds.), AAAI Press and MIT Press, 1995, pp. 339-396.<br />
Wang D., Zeevat H., A syntax <strong>di</strong>rected approach to picture semantics,<br />
CWI, Amsterdam, 1997.<br />
Wellner P. D., StateMaster: a UIMS based on statecharts for prototyping<br />
and target implementation, in Procee<strong>di</strong>ngs of SIGCHI ’89, Human<br />
Factors in Computing Systems, Austin, 1989, pp. 177-182.<br />
W<strong>it</strong>tenburg K., We<strong>it</strong>zman, L., Relational grammars: Theory and practice<br />
in a visual language interface for process modeling, 1997.<br />
Zhang D., Zhang K., VisPro: a visual language generation toolset, in<br />
Procee<strong>di</strong>ngs of IEEE Symposium on Visual Languages, Halifax, 1999,<br />
pp. 195-202.<br />
159