6
Le metriche devono avere le seguenti caratteristiche:
• rappresentare lo stato dell arte nel settore
• essere connettibili alle caratteristiche e sottocaratteristiche per
la cui valutazione vengono utilizzate
• essere il piø possibile facilmente comprensibili
• essere applicabili nel modo il piø possibile oggettivo
Nel quarto si applicher questa metodologia a progetti reali di
RAD Soluzioni Software con l ausilio di uno strumento
automatico sviluppato nell ambito della tesi.
Il prodotto dovr calcolare varie misure della qualit del
software (secondo le metriche esistenti e quella proposta in
questa tesi) e quindi indicare quali sono i punti del programma
che, in base alle assunzioni fatte nel modello, possono creare i
maggiori problemi di leggibilit , manutenibilit o affidabilit .
Nel quinto si porteranno le conclusioni.
7
Capitolo 1
LINGUAGGI E AMBIENTI DI SVILUPPO VISUALI
8
Il campo della programmazione visuale ha mosso i primi passi
negli anni 70 e da allora sono stati realizzati molti differenti
sistemi per creare e gestire programmi. Lo scopo di questo
capitolo Ł identificare ed esaminare i piø importanti ed
interessanti per i nostri scopi.
La programmazione visuale utilizza espressioni visuali come
diagrammi, disegni a mano libera, icone o perfino manipolazioni
grafiche: genericamente la si pu definire come l uso di
diagrammi nel processo di programmazione
Quando la sintassi di un linguaggio di programmazione include
queste espressioni esso Ł chiamato linguaggio di
programmazione visuale (VPL). Un ambiente di
programmazione visuale (VPE) invece, fornisce funzionalit di
programmazione visuali con linguaggi visuali o testuali.
Fig. 1.1 Windows95: una dei sistemi operativi grafici piø
diffusi
9
1.1 LO SVILUPPO DELLA PROGRAMMAZIONE
VISUALE
I primi approcci alla programmazione visuale cominciarono con
due tipi di VPL:
approcci visuali a linguaggi di programmazione visuale (come
flowchart eseguibili) e approcci visuali derivanti dalla tradizione
(come la programmazione per dimostrazione dell azione
desiderata sullo schermo).
Entrambi i tipi di sistemi sembrarono interessanti ed intuitivi
quando utilizzati per dimostrazioni ma incontrarono presto
grosse difficolt con programmi estesi di dimensione reale.
Questi problemi presto portarono al disinteresse verso la
programmazione visuale e molti pensarono che si trattasse solo
di un esercizio accademico inadatto al lavoro reale.
Per superare questo, i ricercatori cominciarono a sviluppare
strade che portavano a utilizzare la programmazione visuale per
parti limitate di sviluppi software, incrementando cos il numero
dei progetti che potevano supportare.
Con questo approccio, le tecniche visuali sono state incorporate
nei VPE che supportano linguaggi testuali e sono usati per:
• Programmazione della GUI
• Disegno grafico delle relazioni e delle strutture dati
• Combinazione visuale di unit di programmi testuali per
generare nuovi programmi
VPE commerciali di successo come Microsoft Visual Basic (per
il Basic) e VisualWorks di PercPlace System (per Smalltalk),
seguirono presto; ne parleremo nei dettagli in seguito.
Altri ricercatori presero una strada diversa, lavorando per
incrementare il tipo dei progetti adatti alla programmazione
visuale con un approccio di dominio specifico.
10
Gli sviluppatori di VPL e VPE per domini specifici
cominciarono ad utilizzare espressioni visuali e terminologie che
riflettevano i bisogni , diagrammi di soluzione dei problemi e
vocabolari specifici del dato dominio.
Questo approccio presto produsse numerosi successi nel campo
della ricerca e sul mercato. VPL e VPE commerciali sono ora
disponibili in molti domini come laboratori di acquisizione dati,
visualizzazione scientifica e telefonia e posta vocale.
La sfida originale (come concepire VPL con abbastanza potenza
e generalit per indirizzare una molteplicit di problemi di
programmazione sempre in espansione) Ł ancora un area di
ricerca. Un obiettivo Ł continuare a incrementare la tecnologia
relativa alla programmazione visuale. Un altro obiettivo Ł
raggiungere, attraverso l approccio visuale, lo stesso guadagno
per VPL general purpose che Ł gi stato raggiunto con VPL con
dominio specifico.
Sebbene questo lavoro sia ancora in fase di ricerca, VPL di
successo commerciale come Prograph di International Prograph
stanno gi emergendo.
Al momento attuale ci troviamo in una situazione in cui si
cominciano a cogliere i primi benefici: sin dall introduzione
della tecnologia object-oriented, uno dei principali benefici era
l impostazione del ciclo di produzione del software similmente a
quello dell hardware.
Il programma viene realizzato assemblando componenti gi
sviluppate, e verosimilmente gi testate, scegliendole in un
mercato che offre innumerevoli soluzioni che di fatto stanno
convergendo a degli standard.
Sicuramente un intervento dell ANSI o dell ISO risolverebbe
molti problemi di compatibilit di questi oggetti tra i vari
ambienti di programmazione che specialmente nel caso di VPL
sono costruiti con filosofie proprie con una drastica riduzione
degli oggetti standard.
La programmazione classica quindi, tende ad essere confinata
alla realizzazione di questi oggetti per il mercato, le cosiddette
11
componenti o parti, e si ha un nuovo modo di programmare detto
appunto per parti o per componenti.
Una forte spinta a questo settore Ł data dall evoluzione
dell hardware che riesce sempre piø a far fronte (se non a
guidare) le naturali esigenze di questi strumenti in termini di
potenza di calcolo.
Il futuro con le possibilit date dalle realt virtuale porter
probabilmente a varcare nuove frontiere per la programmazione
visuale come ad esempio la tridimensionalit .
Fig.1.2 Visual Basic: VPE di Microsoft.
12
1.2 VISUAL WORKS SMALLTALK E MICROSOFT
VISUAL BASIC
Parliamo ora dei due VPE commerciali che piø di altri hanno
avuto successo.
Smalltalk fu inventato presso il laboratorio Palo Alto Research
Center della Xerox piø di venti anni fa. Nella scala temporale
dell informatica Ł un linguaggio vecchio: piø vecchio del C,
molto piø vecchio del C++ ed all incirca della stesa et del
Pascal. Nei suoi primi 15 anni di vita ha lavorato nell ombra:
pochi lo conoscevano, pochissimi lo usavano, eppure era gi il
linguaggio che piø di ogni altro stava influenzando il modo di
interagire con i calcolatori.
Tra i concetti e le idee introdotti da Smalltalk c Ł l interazione
con l utente basata su finestre, cursore e menø pop-up :
Smalltalk Ł anche il progenitore di Windows. Infatti agli inizi
degli anni 80 alcuni programmatori del progetto Smalltalk
lasciarono il PARC e passarono alla Apple ove svilupparono in
Smalltalk il sistema operativo Lisa; dal Lisa deriv il Macintosh,
e dal Macintosh deriv Windows. Ci spiega anche parzialmente
perchØ la Apple ha perso la causa contro la Microsoft per i diritti
sugli ambienti a finestre. Caso mai, la causa avrebbe dovuto
farla ad entrambi la Xerox.
Anche la programmazione ad oggetti e quasi tutti gli attuali
linguaggi Object Oriented derivano da Smalltalk, cos come idee
oggi accettate da tutti come la netta separazione nelle
applicazioni tra parte che elabora i dati e parte che li presenta
all utente.
Nonostante questi successi, Ł solo da poco tempo che Smalltalk
sta conoscendo una reale diffusione di massa, specialmente negli
USA. Si calcola che il mercato sia attualmente circa un quarto di
quello del C++, ed aumenti piø velocemente.
Il progetto Smalltalk nasce, come gi detto, presso il PARC della
Xerox nel 1972, epoca dei calcolatori batch programmati a
schede, di Cobol, Algol e Fortran. L animatore del progetto Ł
Alan Kay, con la sua visione del Dynabook , un computer
grande come un libro, portatile, collegato via radio con altri
13
computer via ARPAnet (oggi Internet), e con cui interagire
tramite una penna. Kay era alla ricerca di un linguaggio potente
ma cos semplice da poter essere usato anche dai bambini. In
questo contesto, ed anche nell ambito di ricerche sui personal
computer (che diverranno le workstation) e su nuovi approcci di
interazione uomo-macchina che porteranno a definire quelle che
diverranno le moderne GUI, il linguaggio si sviluppa in versioni
successive.
Fondamentale Ł anche l influenza del Simula, il primo
linguaggio ad oggetti, ben noto a Kay ed agli altri membri del
gruppo. Il progetto Ł aperto, e a esso partecipano molte altre
societ ed organizzazioni, tra cui la Digital, l Apple, l Universit
di Berkeley, la Tektronic. Nel frattempo, Alan Kay lascia il
progetto perchØ Smalltalk Ł diventato secondo lui troppo
complicato e non risponde piø alle sue aspettative.
Sino ai primi anni 80, tuttavia, era stato un progetto di ricerca
noto solo agli addetti ai lavori, ed utilizzabile realmente solo dai
partecipanti. Nel 1983 esce una serie di libri fondamentali ad
opera di Adele Goldberg, David Robson e altri, che illustrano il
linguaggio e i fondamenti della programmazione ad oggetti.
In quegli stessi anni, la Xerox e la Tektronix commercializzano
le prime workstation con il linguaggio e l ambiente. Si tratta
per di macchine molto costose e poco standard, la cui
diffusione resta molto limitata.
Il 1986 Ł un altro anno fondamentale: viene commercializzata
dalla Xerox (poi Parc Place) una versione di smalltalk per
computer Sun, ed appare sul mercato Smalltalk/V (Virtuale).
VisualWorks (VW) Ł lo Smalltalk direttamente derivato da
quello originale Xerox, ed uno dei prodotti piø professionali e
diffusi. Le sue principali caratteristiche sono la completa
interoperabilit del codice tra le varie piattaforme supportate e la
grande ricchezza di oggetti predefiniti forniti col sistema (quasi
2000 classi), che comprendono un generatore visuale di GUI. I
suoi lati negativi sono il costo e la difficolt di apprendimento,
che ne fanno un punto di arrivo e non di partenza.
14
Fig. 1.3 L ambiente di sviluppo di VW Smalltalk
L arrivo di Java ha impresso uno stimolo alle societ che
producono smalltalk, portando ad una riduzione dei prezzi e a
una loro riorganizzazione. Si tenga presente infatti che Java
assomiglia molto di piø a Smalltalk che al C++.
Quando si pensa ad un linguaggio di programmazione visuale,
l associazione immediata Ł con Visual Basic, un prodotto di
Microsoft. Per la definizione che abbiamo dato Visual Basic non
Ł un linguaggio puramente visuale. E piuttosto un VPE: invece
di essere basato su rappresentazioni diagrammatiche, il suo
linguaggio Ł un avanzata versione testuale del linguaggio Basic.
Abbinata al suo linguaggio testuale si ha un interfaccia utente
grafica ben ideata, che permette al programmatore di costruire
finestre e tutti i corrispondenti componenti come pulsanti, barre
15
di scorrimento e menø selezionando icone e trascinandole in una
rappresentazione grafica della finestra.
Il programmatore scrive i frammenti di codice sorgente che sono
essenzialmente gestori di eventi per i possibili eventi generati
dall uso di mouse e di tastiera. Si parla in questo caso di
programmazione event-driven: in pratica il verificarsi di un
evento Ł rilevato dal kernel di Visual Basic che provvede ad
appenderlo alla coda degli eventi dell applicazione che Ł gestita
dal sistema operativo.
Questo codice Ł collegato alla rappresentazione grafica della
finestra, cos che invece di scorrere lunghi file di codice
sorgente, un programmatore pu accedere alla parte di codice in
questione cliccando con il mouse su una locazione fisica. In altre
parole, l interfaccia dell ambiente fornisce, prima di tutto, un
modo per costruire la struttura dell interfaccia utente
manipolando oggetti grafici, e in secondo luogo un modo di
accesso alla parte di codice sorgente testuale che deve essere
scritto. Parte del successo di Visual Basic Ł la ricca gamma di
componenti o parti gi scritte da svariate societ produttrici di
software. Come vedremo piø avanti parlando di metriche la
natura ibrida di Visual Basic Ł un ottima caratteristica che
permette alla rappresentazione grafica di essere usata in modo
produttivo.
VisualWorks e Visual Basic sono due dei molti ambienti di
programmazione piø diffusi con interfaccia grafica orientata
verso i programmatori. Microsoft ha creato Visual C++,
un interfaccia utente grafica con un compilatore C++. Borland e
PowerSoft hanno realizzato prodotti che usano convenzioni
visuali simili a VB quali Delphi e Power Builder. Societ di
Computer-Aided Software Engeneering (CASE) come Cadre e
IDE hanno realizzato strumenti visuali per molti anni, ed ora
prendono vantaggio dal corrente interesse per la notazione
object-oriented ampliata delle caratteristiche dei loro prodotti.
Java si sta diffondendo come il linguaggio per eccellenza nella
programmazione di Internet. La famiglia di strumenti Visualage
di Ibm Ł leader in questo campo.
16
E proprio Visual Basic l empio piø significativo di quanto
questo nuovo approccio alla programmazione possa essere stato
e sar innovativo nel campo dello sviluppo del software.
Per capire meglio il processo di sviluppo, Ł utile capire alcuni
concetti chiave con cui Visual Basic Ł stato costruito. Dal
momento che Visual Basic Ł un ambiente di sviluppo progettato
per Windows Ł importante capire come questo lavora.
Ci sono tre concetti chiave nel funzionamento di Windows: le
finestre, gli eventi ed i messaggi.
Vediamo ora nel dettaglio le caratteristiche di Visual Basic.
Fig. 1.4 Delphi di Borland: uno dei VPE piø apprezzati
17
1.2.1 COME LAVORA WINDOWS: FINESTRE, EVENTI,
MESSAGGI
Pensiamo ad una finestra semplicemente come a una regione
rettangolare con i suoi confini. Esistono ovviamente diversi tipi
di finestre: quelle di Explorer per visualizzare pagine Web,
finestre di word processor per visualizzare documenti, finestre di
dialogo sia di programmi che di sistema e altre ancora.
Questi sono gli esempi piø tipici di finestre, ma ci sono altri tipi
di finestre: i pulsanti, le icone, le caselle di testo, i pulsanti di
opzioni e le barre dei menø sono tutte finestre.
Il sistema operativo Windows gestisce tutte queste finestre
assegnando ad ognuna un numero identificativo univoco (handle
o hWnd). Il sistema monitorizza continuamente ognuna di
queste finestre per rilevare le attivit o gli eventi. Gli eventi
possono occorrere per un azione dell utente come un clic del
mouse o la pressione di un tasto, per un controllo programmato
o anche per un azione su di un altra finestra.
Ogni evento quando avviene, genera un messaggio che viene
inviato al sistema operativo. Il sistema processa il messaggio e
lo invia alle altre finestre in modo broadcast. Ogni finestra pu
intraprendere l azione basata sulle proprie istruzioni per
rispondere al particolare messaggio (per esempio, ridisegnarsi
quando Ł scoperta da un altra finestra).
Come si pu immaginare, gestire ogni possibile combinazione di
finestre, eventi e messaggi pu essere alquanto complicato.
Fortunatamente, Visual Basic isola il programmatore dai
messaggi a piø basso livello e molti dei messaggi sono gestiti
automaticamente dal linguaggio; altri sono gestibili invece come
procedure evento. Questo permette di creare velocemente
applicazioni senza per avere un controllo completo
dell ambiente a meno di utilizzare funzioni di piø basso livello
dette API.
18
1.2.2 IL MODELLO EVENT-DRIVEN
Nelle applicazioni tradizionali, che definiremo d ora innanzi
testuali o procedurali, Ł l applicazione stessa che controlla quale
porzione di codice eseguire ed in quale sequenza. L esecuzione
inizia con la prima linea di codice e segue un percorso
predefinito nell applicazione, chiamando se necessario delle
procedure.
In un applicazione Event-driven, il codice non segue un
percorso predeterminato ma esegue sezioni differenti di codice
in risposta agli eventi. Gli eventi possono essere generati dalle
azioni dell utente, dai messaggi del sistema o di altre
applicazioni, o dall applicazione stessa. La sequenza di questi
eventi determina la sequenza con cui il codice verr eseguito, e
quindi il percorso nel codice dell applicazione differir ad ogni
esecuzione del programma.
Dal momento che non si pu predire la sequenza di eventi, il
codice deve avere alcuni assunti sullo stato dell ambiente al
momento dell esecuzione. Quando viene fatto un assunto (per
esempio, che un campo di input deve contenere un valore prima
di lanciare una procedure che lo processa), bisogna strutturare
l applicazione in modo che l assunto sia sempre valido (per
esempio, disabilitando il pulsante che lancia la procedura fino a
che il campo non contiene un valore).
Il codice pu anche generare eventi durante l esecuzione. Per
esempio, la modifica da programma del contenuto di una casella
di testo genera un evento. Questo fa eseguire il codice associato
all evento relativo. Se si Ł pensato a questo codice solo per la
modifica da parte dell utente del contenuto della casella di testo
si possono avere risultati inaspettati. E proprio per questo che Ł
fondamentale comprendere fino in fondo il modello Event-
Driven per scrivere applicazioni con questo tipo di linguaggi.
19
1.2.3 SVILUPPO INTERATTIVO
Il tradizionale processo di sviluppo del software pu essere
diviso in tre fasi distinte: scrittura, compilazione e test del
codice.
Diversamente dai linguaggi tradizionali, Visual Basic usa un
approccio interattivo allo sviluppo senza una distinzione tra le
tre fasi.
Con molti linguaggi, se viene commesso un errore quando si
scrive il codice, l errore Ł catturato dal compilatore quando si
compila l applicazione. Bisogna trovare e correggere l errore e
ricominciare il ciclo di compilazione, ripetendo il processo per
ogni errore trovato.
Con Visual Basic l errore pu essere corretto al momento della
digitazione del codice grazie ad un controllo della sintassi
immediato, oppure durante l esecuzione del codice, senza
terminare e riavviare il programma in un formato semi-
compilato che permette un alto fattore d incremento della
produttivit dello sviluppo.