Un sistema distribuito per le metriche del software basato su java e Network Computer

Introduzione 
2 
Modeling Language) ed i paradigmi programmativi quali MVC (Model - 
View - Control) forniscono il necessario supporto teorico ad una corretta 
formalizzazione. 
Nonostante quanto appena affermato, nella pratica molte delle numerose 
esperienze di riutilizzo del software a livello industriale intraprese negli 
ultimi anni si sono rivelate fallimentari dal punto di vista pratico, che in 
ambito industriale si traduce in termini di scarso ritorno economico. Le 
cause del fallimento di queste iniziative sono da ricercarsi principalmente in 
due fattori: la mancanza di un’adeguata cultura nell'ambito della ingegneria 
del software, e la mancanza di strumenti specifici a supporto delle attività di 
riutilizzo. 
La presente Tesi di Laurea, nata dalla collaborazione della Università di 
Pavia con l’IBM Italia S.p.A. (sede di Vimercate - MI), ha lo scopo di 
fornire una soluzione ad uno degli aspetti legati alla carenza di strumenti a 
supporto del riutilizzo del software. 
Il sistema da sviluppare deve fornire un’applicazione funzionante in 
ambiente distribuito e multi piattaforma, che realizzi un supporto grafico per 
la visualizzazione delle metriche di prodotto. 
La possibilità di accedere in modo semplice e standardizzato ad 
informazioni quantitative su un componente software potenzialmente 
riutilizzabile, garantisce un livello di confidenza superiore. E’ così dato un 
valido supporto decisionale qualora siano disponibili più componenti con 
caratteristiche analoghe. 
L'applicazione, denominata "FCM Viewer", complementa il lavoro svolto 
nell'ambito del programma ESSI (European System and Software Initiative) 
dal progetto SURF (Software re - Use: a process improvement experiment at 
an IBM Italia Facility). 
Introduzione 
3 
La base teorica della applicazione, frutto di un precedente progetto 
finanziato dalla Comunità Europea (REBOOT), si appoggia al modello FCM 
(Fattori- Criteri- Metriche). Questo modello utilizza una gerarchia ad albero 
per descrivere i principali attributi di un prodotto software.  
L’applicazione dovrà consentire la personalizzazione dell’albero delle 
metriche, sia nel numero di livelli sia nel numero e tipo di misurazioni 
effettuate. 
L’implementazione dovrà essere eseguita secondo una metodologia, basata 
su criteri di "progetto per il riutilizzo" definita dallo stesso progetto Surf. 
Tale metodologia di progetto del software, una volta approvata ed 
opportunamente adeguata sarà adottata come protocollo ISO. 
L’architettura software sarà sviluppata secondo il paradigma MVC e 
documentata con UML. 
Il sistema di visualizzazione deve essere implementato seguendo lo standard 
Java Bean, in modo da essere immediatamente riutilizzabile all'interno di un 
ambiente di sviluppo grafico. 
L’applicazione sviluppata dovrà funzionare anche su Network Computer 
(NC) perché queste macchine, pensate per diminuire i costi, permettono di 
sfruttare al meglio l’hardware a disposizione, aumentando la sicurezza dei 
dati. 
Questi particolari prodotti hardware offrono diverse risorse ma sono stati 
ideati come client leggeri. 
Il sistema deve basarsi sul funzionamento di un Internet Server e di un 
numero qualsiasi di client che si collegano tramite browser utilizzando come 
supporto TCP/IP (Transmission Control Protocol/Internet Protocol) e 
protocollo http (Hyper Text Transfer Protocol). 
Il lavoro di tesi si è evoluto in fasi successive, i capitoli costituenti 
l’elaborato rappresentano tali fasi. 
Introduzione 
4 
In particolare il primo capitolo tratta il linguaggio UML impiegato per la 
documentazione del software. 
Questo nuovo linguaggio standard è presentato in diversi documenti, spesso 
molto complessi. Qui ne è data una spiegazione generale fissando 
l’attenzione sui grafici del linguaggio, essi sono la documentazione 
principale, necessaria all’individuazione dei componenti da progettare 
durante le fasi di implementazione del sistema. 
Il secondo capitolo tratta della metodologia che si è progettata, raffinata ed 
utilizzata per la realizzazione del sistema di visualizzazione. Essa individua 
i documenti in notazione UML da redigere, la sequenza logica di passi da 
seguire e consiglia gli strumenti da utilizzare in ogni fase. 
Il successivo capitolo tratta del Network Computer, un prodotto hardware di 
recente introduzione, al quale molte industrie stanno dedicando vaste 
risorse. In questo capitolo si spiegano l’importanza del server, della rete e le 
caratteristiche dei client che utilizzeranno lo strumento di visualizzazione. 
Il quarto capitolo vuole dare una panoramica delle caratteristiche principali 
del linguaggio Java. 
In esso sono state riportate oltre alle particolarità del linguaggio, quelle 
utilizzate nella realizzazione e le scelte effettuate per la stesura 
dell’applicazione. Al termine del capitolo è data una breve indicazione degli 
strumenti utilizzati e delle loro caratteristiche principali. 
Il quinto é il capitolo in cui è spiegata la teoria della “misurazione” del 
software. Oltre a spiegare le difficoltà di interpretazione delle misure 
ottenute, si conclude con le motivazioni delle scelte effettuate e le soluzioni 
adottate. 
L’ultimo capitolo è l’insieme di tutte le fasi, individuate nella metodologia 
spiegata nel capitolo due, e qui applicate per lo sviluppo della tesi. In questo 
Introduzione 
5 
capitolo è riportata parte della documentazione prodotta per la realizzazione 
del sistema. 
E’ aggiunta anche parte della documentazione prodotta da Rational Rose che 
secondo la metodologia è parte integrante del progetto software realizzato. 
L’elaborato comprende un’appendice, glossario delle sigle utilizzate 
comunemente in ambito informatico o semplicemente delle abbreviazioni 
impiegate nella tesi. 
E’ quindi inserita una bibliografia, elenco dei libri consultati per 
l’approfondimento delle tecnologie adottate oltre ai principali libri specifici 
per le varie tematiche. Spesso tali libri sono sottoforma di pubblicazioni 
html e per questi sarà riportato il link Internet. 
Quindi è riportata l’appendice in cui è inserito l’indice di tutti i metodi, le 
classi, e gli attributi implementati per tutte le classi dell’applicazione. 
Tale risultato si è ottenuto grazie all’uso del tool Javadoc nella versione 1.2. 
L’ultima appendice riporta le tabelle in cui sono spiegate le caratteristiche 
delle metriche utilizzate e i filtri associati ad ognuna di esse. 
Capitolo 1:     Il Linguaggio di Modellazione Unificato 
6 
 
 
1.1 Introduzione 
Questo capitolo intende dare una spiegazione di cosa tratta il linguaggio di 
modellazione unificato o l’Unified Modeling Language (UML). Questa sigla 
ultimamente in ambito specialistico è divenuta molto comune e per questo 
motivo sono stati pubblicati vari libri su questo argomento. Si rimanda a 
questi libri (alcuni dei quali riportati in bibliografia) per un 
approfondimento sull’argomento. Qui intendo dare una traccia di cosa è 
l’UML e come è stato utilizzato per la realizzazione del progetto. 
Una citazione riportata praticamente in tutti i documenti che trattano questo 
argomento è: "UML è un linguaggio per specificare, visualizzare e realizzare 
i prodotti di sistemi software e per il business modeling. L’UML rappresenta 
una collezione delle migliori pratiche ingegneristiche, che si sono 
dimostrate utili nella progettazione di sistemi complessi e di grandi 
dimensioni." 
L’Object Management Group (OMG), un consorzio internazionale di 
standardizzazione, alla fine del 1996 chiese la pubblicazione di una 
notazione standard che permettesse la documentazione dei sistemi ad oggetti 
e che agevolasse l’interscambio di dati tra strumenti o team di sviluppo 
Capitolo 1:     Il Linguaggio di Modellazione Unificato 
7 
eterogenei. A questa richiesta aderirono diverse industrie e il prodotto che 
ne scaturì alla fine di accordi e trattative fu proprio UML. 
Questo standard è nato per essere indipendente dai linguaggi di 
programmazione ed addirittura dalla programmazione stessa poiché può 
essere utilizzato in tutti i contesti, infatti, la documentazione del linguaggio 
stesso è redatta proprio in UML per dimostrare che è adatta a tutto ma 
soprattutto che è autoesplicativa. 
Questo linguaggio è stato costruito per adattarsi alla produzione iterativa di 
software. Come ben noto tutti i progettisti prevedono più release di un 
prodotto, anche se spesso la linea decisionale ed i clienti non condividono 
questo metodo. 
Solo seguendo questa tecnica è possibile avere prodotti testabili nel minor 
tempo possibile anche se non contenenti tutte le funzionalità richieste. 
Il fatto di non stimare in maniera preventiva tali tempi può portare o a 
ritardi nel rilascio dei prodotti o alla distribuzione di software 
malfunzionante. 
1.2 Storia di UML 
Il processo di standardizzazione ed unificazione che ha portato ad UML ha 
avuto origine nei primi anni ‘90 quando Booch iniziò la pubblicazione dei 
suoi metodi con il marchio Rational. 
Nel 1994 con l'ingresso di Jim Rumbaugh nella società Rational è proseguito 
lo sviluppo di metodi atti alla documentazione del software. La svolta 
decisiva è avvenuta con l'arrivo nella stessa società, ad ottobre del 1995, di 
Ivar Jacobson la cui ditta Objectory fu acquistata dalla Rational. Il grafico 
successivo è tratto dal sito Web di Rational e rappresenta la cronologia per 
lo sviluppo del linguaggio. 
Capitolo 1:     Il Linguaggio di Modellazione Unificato 
8 
Booch ´91
Booch ´93
Unified Method 0.8
UML 1.0
OMT - 2
OMT - 1 OOSE
UM L 0.9 &  0.91
OOPSLA ´95
June ´96 & Oct ´96
Submission of UML 1.0 to OMG
for adoption, Jan ´97
Other methods
public
feedback
Publication of 
UM L 1.0, Jan ´97
UML Partners’
Expertise
Industrialization
Standardization
Unification
Fragmentation
 
Figura 1. Cronologia di UML  
La cronologia di UML in dettaglio è: 
• Ottobre 1995: è introdotto Unified Method versione 0.8 (Booch e 
Rumbaugh) come unificazione dei loro due metodi. (nello stesso periodo è 
acquistata Objectory). 
• Giugno 1996: nasce UML versione 0.9 sviluppata da Booch, Rumbaugh e 
Jacobson. UML non è più una metodologia ma diventa un linguaggio. 
• Ottobre 1996: esce la versione UML 0.91 revisione della precedente 
sempre frutto dei tre “amigos” Booch, Rumbaugh e Jacobson.  
• Novembre 1996: l’OMG chiede di “costruire una notazione standard che 
permetta la documentazione dei sistemi ad oggetti e che agevoli 
l’interscambio di dati tra strumenti o team di sviluppo eterogenei”. 
Capitolo 1:     Il Linguaggio di Modellazione Unificato 
9 
• 16 gennaio 1997: è depositata all’OMG la versione UML 1.0 di Booch, 
Rumbaugh, Jacobson e le prime aziende produttrici di software al mondo, 
tra cui Microsoft, Oracle, Hewlett Packard, Digital e Texas Instruments. 
• Gennaio 1997: all'OMG arrivano anche altre proposte; OCL di IBM e una 
di Platinum. 
• Settembre 1997: dopo aver raggiunto accordi con Platinum, IBM e le altre 
case, la versione 1.1 dello Unified Modeling Language è sottoposta 
all'approvazione di OMG la proposta appartiene a Rational Software, 
Microsoft, Hewlett Packard, Oracle, Sterling Software, MCI Systemhouse, 
Unisys, ICON Computing, IntelliCorp, i-Logix, IBM, ObjecTime, 
Platinum Technology, Ptech, Taskon, Reich Technologies, Softeam, ed 
altri.  
• 16 novembre 1997: UML 1.1 diventa ufficialmente uno standard OMG 
(con il nome ufficiale di "UML OMG 1.0") 
1.3 Il Linguaggio 
L’UML è un linguaggio visuale di modellazione che permette ai progettisti 
di definire gli artefatti della programmazione necessari a rappresentare il 
sistema da gestire. E’ data la possibilità di utilizzare uno strumento di 
documentazione, svincolato da rigide sequenze, dalle caratteristiche 
tecnologiche e dei requisiti utente che consente di descrivere il progetto fino 
all’allocazione dei componenti software su diversi processori in 
un’architettura distribuita. Il linguaggio consente di rappresentare uno 
stesso sistema a diversi livelli di astrazione, corrispondenti ai diversi 
professionisti ed ai diversi interlocutori: committenti, utenti, addetti 
all’utilizzo od allo sviluppo, che comunicano per giungere alla definizione 
dei requisiti che il software dovrà contenere. Il linguaggio si propone di 
seguire tutte le diverse fasi di un progetto. 
Capitolo 1:     Il Linguaggio di Modellazione Unificato 
10 
Gli autori ed i proponenti di UML hanno evitato di associare al linguaggio la 
proposta di un processo che suggerisse una sequenza di passi da compiere 
per lo sviluppo dei sistemi. Questa caratteristica è stata introdotta già dalla 
versione 0.9 per vincolarne il meno possibile l’accettazione e l’uso da parte 
dei vari settori del mondo informatico e per rendere il più globale possibile 
l’uso di tale linguaggio. Ma UML non è riducibile a una semplice notazione 
grafica, infatti, il metamodello su cui gli autori hanno trovato un accordo è 
estremamente ricco e complesso sotto il profilo semantico. Le caratteristiche 
dei vari elementi del modello e le associazioni possibili tra loro sono 
definite in modo particolareggiato, anche grazie a una serie di vincoli 
espressi mediante un linguaggio formale, Object Constraint Language 
(OCL), che consentono di verificare se un enunciato definito in UML è ben 
formato.  
IBM, che ha sviluppato OCL, dispone di un parser che verifica la correttezza 
della semantica utilizzata. Il “compilatore” indica quindi se le notazioni 
introdotte per descrivere il sistema sono definite correttamente ed inoltre 
dimostra che il linguaggio è estremamente ricco. Questo non deve 
scoraggiarne l’uso, ma al contrario facilitarlo perché UML è stato pensato 
con un “core” non molto complesso che deve essere appreso e da estensioni 
che permettono di adattare le notazione a tutti i dettagli desiderati ma la cui 
conoscenza non è fondamentale per la comprensione dei modelli costruiti. 
Per visualizzare e diagrammare correttamente i sistemi software sono 
necessari tre elementi: un processo, una notazione ed un tool di 
modellizzazione e queste sono proprio le tre caratteristiche principali di 
UML. 
Esso permette la scomposizione di grandi programmi in sottoprogrammi che 
possono essere sviluppati indipendentemente, e soprattutto di redigere una 
documentazione chiara e comprensibile. In questo modo è agevolato il 
Capitolo 1:     Il Linguaggio di Modellazione Unificato 
11 
lavoro dei team ma soprattutto è incrementata la possibilità di riutilizzare 
quanto sviluppato. 
L’UML si basa su diversi linguaggi preesistenti e li estende ed unifica: uno 
di questi è Object Oriented Software Engineering (OOSE) sviluppato da Ivar 
Jacobson che ha un approccio orientato agli USE CASE e da un eccellente 
supporto all’analisi delle richieste del cliente (Requirements), si adatta 
all’ingegneria d’impresa. Questo metodo conteneva la parte di metodologia 
di Objectory un altro metodo sviluppato sempre da Jacobson. Un altro 
linguaggio incluso è Object Modeling Technique 2 (OMT-2) sviluppato da 
Jim Rumbaught particolarmente adatto all’analisi di sistemi informativi per 
la gestione di grandi quantità di dati. Nell’UML è compreso inoltre 
Booch’93 sviluppato da Grady Booch particolarmente adatto alla fase di 
Design e costruzione del progetto per applicazioni che richiedono 
particolare sforzo ingegneristico. Oltre alle idee dei suoi tre principali 
autori, accoglie quelle di numerosi altri metodologi: David Harel per i 
diagrammi di stato, Bertrand Meyer per le precondizioni e postcondizioni 
per l’ammissibilità di avvio degli eventi. 
Sally Shlaer & Stephen Mellor hanno sviluppato i grafici per esprimere il 
Ciclo di Vita degli Oggetti e Rebecca Wirfs-Brock è intervenuta nello studio 
delle responsabilità e collaborazioni delle classi. 
Per concludere attorno a questo linguaggio si sono sviluppati molti tool 
grafici, anche complessi, che permettono di gestire tutti i diagrammi e di 
redigere anche della documentazione testuale da allegare ai prodotti 
sviluppati. 
In questo campo è da ricordare Rational Rose prodotto dalla ditta dei tre 
‘guru’ del linguaggio che, seppure con le sue pecche, la considerevole 
complessità ed il costo molto elevato, è un prodotto adatto a dimostrare che 
Capitolo 1:     Il Linguaggio di Modellazione Unificato 
12 
è possibile utilizzare UML per facilitare la progettazione e soluzione di 
molti problemi. 
Questo tool è quello utilizzato per la stesura dei diagrammi del progetto, nel 
capitolo sei vengono riportarti i principali diagrammi costruiti durante tale 
fase. 
1.4 Perché non metodo? 
A questo punto è giunto il momento di chiedersi come mai UML, che era 
nato col nome “Unified Method”, è passato da "metodo" a "linguaggio" con 
l’obiettivo di divenire "universale". Una spiegazione citata dai suoi autori 
più volte è: "Un solo processo universale buono per tutti gli stili di sviluppo 
non sembra possibile e tanto meno desiderabile. Ciò che va bene per un 
progetto è probabilmente sbagliato od inutilizzabile per un altro. Tuttavia 
UML può essere usato per esprimere gli artefatti di tutti i processi, in 
particolare i modelli prodotti". 
Ma ciò non significa che UML trascuri i processi. In realtà quello che i suoi 
autori hanno sviluppato è un processo basato sui Casi d'Uso, incentrato 
sull'architettura, iterativo e incrementale. 
"L'esperienza insegna che i dettagli di questo processo di tipo generale 
vanno adattati alle peculiarità della cultura dello sviluppo applicativo in 
ciascuna organizzazione". 
Siccome non si collega ad una metodologia predefinita, UML può essere 
definito universale: "Universale nel senso che può esprimere contenuti di 
natura differenti e si presta a scopi anche assai diversi, esattamente come un 
linguaggio di programmazione, non naturale, può essere usato in modi molto 
diversi". 
Ci vorrà ancora del tempo per sapere se questo linguaggio sarà adottato 
massicciamente. In molte aziende, e chiunque ha esperienza di un progetto 
Capitolo 1:     Il Linguaggio di Modellazione Unificato 
13 
lo può affermare, la produzione di software è basata su una definizione delle 
specifiche di analisi in formato testuale, e sulla loro immediata 
implementazione in righe di codice. Spesso le specifiche sono in formato 
vocale e le modifiche che avvengono dal primo accordo alla soluzione sono 
molteplici. In alcune aziende, i flow chart costituiscono la documentazione 
di corredo al software. In altre, l'avvento e l'utilizzo di linguaggi visuali e di 
tool IDE (Integrated Development Environment), oltre alla necessità di 
limitare la massimo ulteriori spese ha spinto l’attività di documentazione a 
divenire un'operazione trascurabile.  
Per tutte le aziende in cui esiste la certezza che lo sviluppo e la 
manutenzione del software sono attività complesse, come per tutti gli altri 
settori ingegneristici, la definizione e l’utilizzo di modelli formali per le 
specifiche di analisi e progetto è un requisito essenziale alla produzione di 
tutti i componenti. 
Non bisogna dimenticare che diversi studi hanno appurato che in un’azienda 
l’acquisto di un nuovo programma software corrisponde solo ad un terzo 
della spesa complessiva che l’azienda stessa dovrà sostenere per la 
successiva manutenzione ed i futuri aggiornamenti. 
Le società più importanti, che documentano i prodotti utilizzando le tecniche 
affinate con la progettazione tradizionale, sono alla ricerca di tecniche di 
sviluppo orientate agli oggetti. La confusione riguardante la scelta di 
metodologie e documentazione da redigere è notevolmente aumentata in 
questo decennio poiché sono nate più di cinquanta metodologie il cui 
obiettivo era quello di documentare i prodotti software ma che hanno fallito 
o perché troppo complesse o perché non adatte a seguire tutte le fasi della 
progettazione. 
Oggi le tecnologie cambiano sempre più spesso, a un ritmo sempre 
maggiore. Dagli ambienti centralizzati si è passati alle architetture 
Capitolo 1:     Il Linguaggio di Modellazione Unificato 
14 
distribuite ed ora sembra si stia ritornando a quelle centralizzate (Network 
Computer). La tecnologia non è più omogenea e soprattutto è molto meno 
stabile che in passato, quando la scelta di un sistema operativo, di un 
linguaggio, di un data base determinavano per anni le caratteristiche 
dell’ambiente di sviluppo in un azienda. Normalmente ora diversi linguaggi 
e soprattutto numerosi data base coesistano in un unico ambiente operativo e 
colloquiano tra loro. In questi ambienti, la standardizzazione portata 
dall'UML, supportata dagli strumenti di sviluppo, costituirà senza dubbio un 
elemento fondamentale per l'unificazione delle tecniche di progetto. 
1.5 I diagrammi di UML 
L’UML non è formato solo da diagrammi ma essi ne sono la parte più 
importante. Ne esistono diversi tipi, pensati per facilitare la comprensione 
dei comportamenti degli elementi appartenenti al sistema da descrivere. I 
diagrammi sono stati utilizzati perché la programmazione software, ed in 
particolare quella ad oggetti, richiede una documentazione particolare per 
rendere facilmente comprensibili a coloro che dovranno effettuare la 
manutenzione del software, dove effettuare le modifiche o meglio come 
utilizzare i componenti già sviluppati. Questi documenti previsti da UML 
assistono tutte le fasi di sviluppo e possono essere separate in un due 
insiemi. 
Il primo insieme può essere definito come “descrittivo”, in cui cioè si cerca 
di comprendere a fondo il problema da risolvere senza pensare a come si 
risolverà. 
Infatti le soluzioni che si adottano devono essere indipendenti dal 
linguaggio e dalle caratteristiche specifiche del sistema da sviluppare, si 
deve cioè cercare di ottenere dei componenti che abbiano la possibilità di 
essere utilizzati in ambienti diversi e su problemi differenti dallo specifico 
Capitolo 1:     Il Linguaggio di Modellazione Unificato 
15 
sotto osservazione. Questi obiettivi permetteranno di realizzare soluzioni più 
semplici e probabilmente riutilizzabili. 
Naturalmente la fase di sviluppo dovrebbe iniziare dalla verifica 
dell’esistenza di problemi simili già risolti o parzialmente risolti. 
Il secondo insieme di grafici lo chiameremo “implementativo” poiché questi 
diagrammi sono rivolti alla fase di realizzazione effettiva del progetto. 
Questi ultimi infatti servono a descrivere come sarà fisicamente distribuita 
l’elaborazione e permette anche la rappresentazione di componenti 
hardware. Solo in questa fase è necessario pensare alla soluzione definitiva 
con la relativa allocazione dei componenti che si sono progettati, al tipo di 
linguaggio stesso in cui sviluppare il progetto se non erano state fatte 
richieste particolari dall’utente. 
1.6 Insieme Descrittivo 
1.6.1. Diagramma dei casi d’uso 
Come probabilmente riscontrato da tutti i programmatori uno dei passi più 
complicati nella progettazione è capire a fondo tutte le esigenze del cliente 
per poterle soddisfare. 
A questo punto sorge una domanda: “Ma a cosa serve imparare ed utilizzare 
una notazione grafica magari anche piacevole che costa però molto, visto 
che al cliente interessa solo l’output del sistema sviluppato?” 
La risposta è molto semplice, la notazione è stata introdotta per ovviare alla 
difficoltà di comunicazione tra committente e progettista e tra tutti i 
collaboratori allo sviluppo di un sistema. Infatti spesso essi sembrano 
parlare lingue differenti, e quasi sempre i risultati ottenuti nelle prime 
versioni dei prodotti software sono completamente differenti da quelli attesi 
dal cliente.