Sviluppo dei Data Mart “Costo Attività” e “Risorse Strumentali” nell’ambito del sistema CIPEL

 9 
SCOPO 
Questo progetto è frutto di un periodo di stage aziendale, svolto 
presso la Svimservice di Bari, ed ha l’obiettivo di fornire uno strumento 
per risolvere il “Controllo di Gestione” degli enti pubblici locali, 
facilitando il compito del Knowledge Worker (lavoratore della 
conoscenza), ossia del personale addetto alla valutazione dei risultati 
aziendali. 
Il sistema dovrà, tramite la generazione di report mirati, 
provvedere alla produzione di indicatori utili alla valutazione dei “Costi 
Attività” e delle “Risorse Strumentali”. 
Per ottenere il risultato desiderato, occorrerà in primis 
progettare un database relazionale in grado di contenere i dati relativi 
all’ente; poi si potrà procedere alla progettazione di un Data 
Warehouse (magazzino di dati) per importare i dati da fonti di dati 
differenti e riorganizzarli tramite opportune trasformazioni. 
L’output di questa fase sarà rappresentato da dei Data Mart, su 
cui si potranno effettuare le analisi tramite gli strumenti di Business 
Intelligence. Si utilizzano questi strumenti perchè grazie alla loro 
facilità d’uso permettono la produzione di indicatori (e quindi 
“informazioni”) anche ad un target che non ha elevate competenze 
informatiche e di basi di dati; grazie alla Business Intelligence si 
riducono i tempi di produzione delle query e si individuano più 
facilmente i soli risultati utili. 
 10 
Capitolo 1       
ELABORAZIONE DISTRIBUITA A 
COMPONENTI 
Gli anni ’90 hanno portato un clima generale di crisi nelle 
aziende del terziario avanzato: i sistemi software diventavano sempre 
più complessi da sviluppare e richiedevano tempi lunghissimi di 
rilascio; solo il 5% dello sviluppo software portava sistemi funzionanti, 
per lo più i progetti venivano abbandonati dopo la consegna (tarda o 
incompleta), a volte il software prodotto era già obsoleto al momento 
del rilascio o non veniva mai terminato. Si venivano quindi a definire i 
limiti fisici della programmazione procedurale.  
Il mondo del software richiedeva una nuova metodologia di 
sviluppo, una metodologia flessibile ai cambiamenti imposti dal 
mercato, che potesse risolvere i problemi economici e temporali del 
vecchio modello di sviluppo.  
La maggior parte dei costi e degli sforzi di sviluppo derivano 
dalla continua riscoperta e reinvenzione di concetti e componenti 
basilari, già sviluppati in precedenza. La comunità software da tempo 
ha bisogno di tecnologie che permettono il riutilizzo di una parte o di 
intere applicazioni precedentemente realizzate; alcune di queste 
tecniche sono state sviluppate e sono già largamente utilizzate dagli 
sviluppatori. 
CAPITOLO 1            ELABORAZIONE DISTRIBUITA A COMPONENTI 
11 
La visione originale di riutilizzo nella comunità software era 
basata sui componenti. All’inizio la comunità object oriented si 
concentrò nel riutilizzo del codice, adottando la terminologia di 
Software ICs descritta da Brad Cox. I componenti software riusabili, 
venivano chiamati Software ICs (Integrated Circuits) per fare un 
parallelismo con l’hardware engineering. In questo campo 
dell’ingegneria, le schede sono costruite utilizzando chip di silicio, i 
quali sono già stati sviluppati in precedenza. Un Software ICs 
implementa una classe di oggetti; come un circuito integrato per una 
scheda elettronica, è un componente indipendente dal contesto specifico 
in cui è inserito, ed altamente riutilizzabile nei progetti futuri. 
La tecnologia di riuso ideale fornisce componenti che possono 
essere facilmente connessi per creare un nuovo sistema. Gli 
sviluppatori software non devono conoscere l’implementazione interna 
dei componenti, e la loro specifica è semplice da comprendere. Il nuovo 
sistema ottenuto in questo modo sarà facile da manutenere ed 
affidabile. 
CAPITOLO 1            ELABORAZIONE DISTRIBUITA A COMPONENTI 
12 
1.1   Programmazione orientata agli 
oggetti 
L'approccio di design che sta alla base delle architetture a 
componenti odierne è object oriented. Un'applicazione ad oggetti è 
costituita da un insieme di moduli software logicamente indipendenti, 
le classi, che incapsulano dati ed operazioni sui dati (risolvendo la 
distinzione tradizionale tra dati e funzioni), e che interagiscono tra loro 
tramite scambi di messaggi.  
Rispetto ai moduli software tradizionali, le classi presentano 
alcuni vantaggi decisivi, sotto il profilo tecnico-organizzativo: 
1. Elevata coesione
1
 interna, coupling
2
 limitato verso 
l'esterno: ogni classe è un componente estremamente 
coeso, che gestisce un insieme di dati omogenei e le 
operazioni che accedono a tali dati , e se necessario li 
modificano. Vantaggi: 
a. Manutenibilità: le modifiche sui dati sono 
normalmente limitate all'ambito omogeneo della 
classe che li definisce, poiché i dati sono accessibili 
solo dalle operazioni interne alle classi  
                                            
1
 Coesione= grado di omogeneità e uniformità di oggetti e funzioni all’interno 
di un modulo. Per ottenere un elevato grado di coesione è necessario includere in una 
classe tutte e solo le funzioni che realmente riguardano la classe. 
2
 Coupling= accoppiamento, grado di interrelazione fra elementi di moduli 
diversi 
CAPITOLO 1            ELABORAZIONE DISTRIBUITA A COMPONENTI 
13 
b. Ricusabilità: la classe fornisce tutte le operazioni 
significative per l'oggetto business, utilizzabili in 
contesti eterogenei  
c. Distribuibilità: la classe è un elemento ideale per la 
distribuibilità, grazie alla sua coesione ed al 
sufficiente disaccoppiamento rispetto ad altre 
classi; nei casi in cui sia opportuno un livello di 
accorpamento maggiore, più classi accoppiate tra 
loro possono essere ricomprese in un unico 
componente distribuibile.  
2. Separazione rigorosa di interfaccia ed 
implementazione: le richieste (messaggi) indirizzabili ad 
una classe sono definite esplicitamente (nome messaggio, 
parametri di input e di output): l'interfaccia della classe è 
costituita, precisamente, dall'insieme dei messaggi che un 
qualsiasi chiamante (client) può indirizzarle. 
L'implementazione della classe è invece inaccessibile ai 
client. Vantaggi:  
a. Manutenibilità: ogni variazione 
all'implementazione di una classe non ha impatto 
sui client, se non si verificano variazioni a livello 
dell'interfaccia; è possibile sostituire 
completamente l'implementazione mantenendo la 
medesima interfaccia, senza impatti sui client.  
b. Distribuibilità: le comunicazioni tra le classi 
avvengono esclusivamente tramite messaggi, 
indirizzabili sia in locale che in remoto.  
3. Polimorfismo: classi diverse possono rispondere al 
medesimo messaggio, ciascuna in modo appropriato. Il 
CAPITOLO 1            ELABORAZIONE DISTRIBUITA A COMPONENTI 
14 
client non ha necessità di conoscere la classe precisa a cui 
appartiene l'oggetto su cui sta lavorando, ma può inviare 
un messaggio generico la cui risposta dipenderà dalla 
classe a cui l'oggetto appartiene. Vantaggi:  
a. riduzione della complessità: la logica del client 
risulta semplificata, in quanto viene eliminata gran 
parte della logica condizionale legata al 
trattamento di oggetti di tipologia diversa  
b. manutenibilità: le modifiche ai comportamenti 
specifici, i quali implementano nelle diverse classi il 
modo specifico di rispondere ad un messaggio 
generico, sono localizzate nell'ambito delle singole 
classi, e non devono essere conosciute dai client.  
4. Ereditarietà: è possibile specializzare una classe 
esistente, ereditandone attributi e comportamenti nella 
nuova classe, ed aggiungendo solo attributi ed operazioni 
specifici per la nuova tipologia da gestire. Vantaggi:  
a. Ricusabilità: l'ereditarietà consente di distinguere 
in modo rigoroso gli aspetti comuni a più tipologie 
di oggetti da quelli specifici ad una tipologia 
particolare, riducendo il carico di programmazione e 
al tempo stesso garantendo una migliore 
organizzazione del codice  
b. Manutenibilità: le modifiche ad attributi ed 
operazioni comuni a più sottoclassi vengono 
localizzati al livello della sola superclasse, con una 
riduzione del carico di manutenzione.  
CAPITOLO 1            ELABORAZIONE DISTRIBUITA A COMPONENTI 
15 
Queste caratteristiche dell'approccio object oriented, innovative 
sul piano tecnico, hanno favorito la progressiva diffusione dei linguaggi 
OO in tutti i domini applicativi e nelle realtà che richiedono volumi di 
dati e processi elevati.  
 
 
Figura 1-1: Esempio di classe rappresentata nella metodologia UML 
1.2   Componenti 
Brown and Wallnau (1998) descrivono un componente come una 
parte di sistema non semplice, quasi indipendente, e sostituibile, che 
implementa una funzionalità precisa nel contesto di un’architettura 
ben definita. 
Una componete è un oggetto flessibile che può essere facilmente 
integrato in altri progetti, quindi riutilizzato. Affinché si possa parlare 
di componente software, l’unità di composizione
3
 deve possedere le 
seguenti caratteristiche: 
1. Formato binario: la componente è un oggetto compilato 
(ad esempio in java un file .class) 
                                            
3
 Unità di composizione = è una parte di un sistema. Ad esempio una classe 
CAPITOLO 1            ELABORAZIONE DISTRIBUITA A COMPONENTI 
16 
2. Implementi una o più interfacce: le interfacce della 
componente sono le funzionalità messe a disposizione 
dalla stessa, posso essere viste come dei suoi punti di 
accesso. Affinché una componente sia riusabile deve avere 
una interfaccia ben definita. 
3. Abbia un comportamento personalizzabile: Le componenti 
riusabili devono avere meccanismi attraverso cui poter 
modificare il loro comportamento, il tutto senza accedere 
al codice sorgente. 
 
Una componente può essere sviluppata all’interno dell’ 
organizzazione (sviluppate “in house”) o acquistata da terzi sul mercato 
(COTS 
4
). 
 
Un COTS di qualità, oltre alle proprietà precedentemente 
descritte, deve possedere altre caratteristiche, affinché sia una 
componente flessibile e riusabile in vari sistemi : 
 ξ  information hiding: è necessario conoscere solo 
l’interfaccia e le funzionalità per rendere indipendente il 
suo utilizzo dalla sua implementazione; 
 ξ  indipendenza dell’utilizzo: l’uso non deve dipendere dagli 
strumenti e dalla conoscenza di chi lo fornisce; 
 ξ  conformità ad un component model: i component model 
definiscono le regole per la composizione e l’interazione di 
componenti (Heinman and Councill, 2001). La conformità 
                                            
4
 COTS= Commercial Off The Self.  
CAPITOLO 1            ELABORAZIONE DISTRIBUITA A COMPONENTI 
17 
ad un component model trasforma lo sviluppo del software 
in un’implementazione che rispetta un’architettura; 
 ξ  rispetto dei contratti : 
o sintattici, come la definizione delle interfacce e dei 
parametri di input e output;  
o semantici, ad esempio il rispetto di pre e post-
condizioni definite in fase di design 
 
I sistemi basati su COTS (Component Based Software, COTS 
based Software) includono componenti sviluppate ad hoc  che si 
affiancano a componenti commerciali. 
 
Figura 1-2: Un software formato da diverse componenti indipendenti 
 
Si renderà pertanto necessario un lavoro di integrazione per fare 
in modo che i prodotti COTS lavorino all’interno del sistema e si 
integrino con i prodotti sviluppati in house. 
CAPITOLO 1            ELABORAZIONE DISTRIBUITA A COMPONENTI 
18 
1.3   Component-based development 
Il processo con cui le aziende e le organizzazioni sviluppano 
software basato sulle componenti viene definito CBD ( Component-
based Development) 
 
Figura 1-3: CBD (Component-Based Development ) 
 
Come si evince dalla figura, durante le fasi di analisi e design, si 
cerca di capire se i componenti necessari sono già presenti fra le 
preesistenze dei soggetti attuatori o sul mercato, oppure se è richiesta 
una nuova implementazione.  
CAPITOLO 1            ELABORAZIONE DISTRIBUITA A COMPONENTI 
19 
Nel primo caso dovrà essere resa disponibile una lista di 
componenti utilizzabili e si dovrà valutare se questi rispecchiano 
pienamente le specifiche iniziali o se devono essere modificati. È anche 
possibile, in virtù del fatto che spesso i componenti disponibili non 
rispecchiano le specifiche previste, rivedere l’architettura del sistema 
in modo da valutare la possibilità di applicare modifiche alla stessa.  
Nel caso in cui la componente non è di proprietà 
dell’organizzazione si procederà a ricercarle nel mercato, le componenti 
individuate verranno valutate e se qualificate si potrà iniziare la fase 
di integrazione delle stesse. 
 
L’integrazione per componenti è la pratica che consente di 
combinare le singole componenti software sviluppate in-house e/o 
COTS allo scopo di realizzare un sistema integrato, dotato di tutte le 
funzionalità fornite indipendentemente dalle singole componenti che lo 
costituiscono. 
1.4   Applicazione Distribuita 
Costruire un’applicazione distribuita, sulla base di un’altra già 
esistente, è più facile se questa ultima è sviluppata a componenti. E’ 
così possibile sostituire un componente con un altro in grado di 
comunicare con uno in remoto.  
Per l’applicazione sulla macchina locale non interessa che gli 
effettivi componenti siano in postazione remota, ed allo stesso modo ai 
componenti remoti non interessa essere tali.  
In pratica, grazie all’apposito componente per il colloquio remoto, 
l’applicazione può totalmente ignorare dove siano effettivamente 
situati gli altri componenti. 
CAPITOLO 1            ELABORAZIONE DISTRIBUITA A COMPONENTI 
20 
 
Figura 1-4: Applicazione distribuita che utiizza componenti presenti 
su macchine remote