Untitled - AIRT Lab

Ai miei genitori Filomena e Mario
e mia sorella Stefania
Indice
Indice
ii
Elenco delle figure
iv
Introduzione
vii
1 Lo stato dell’arte
1
1.1
Il software gestionale . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2
Sistemi ERP: Enterprise Resource Planning . . . . . . . . . . . . . .
3
1.2.1
Moduli core intersettoriali . . . . . . . . . . . . . . . . . . .
4
1.2.2
Moduli core settoriali . . . . . . . . . . . . . . . . . . . . . .
5
1.2.3
Extended ERP . . . . . . . . . . . . . . . . . . . . . . . . . .
6
1.2.4
Diffusione . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
1.2.5
Il paradigma ERP . . . . . . . . . . . . . . . . . . . . . . . .
8
2 Computi metrici
15
2.1
Il computo metrico . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.2
Il computo metrico estimativo . . . . . . . . . . . . . . . . . . . . .
18
3 Caso di studio
25
3.1
Raccolta dei requisiti . . . . . . . . . . . . . . . . . . . . . . . . . .
26
3.2
Analisi dei requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
3.3
Progettazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
ii
INDICE
iii
4 L’ambiente di sviluppo
43
4.1
Il sistema operativo . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
4.2
MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
4.3
MySQL Workbench . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
4.4
Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
4.5
Eclipse e Netbeans . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
5 Conclusioni e sviluppi futuri
55
Bibliografia
59
Elenco delle figure
1.1
Schema a “T” di un sistema ERP . . . . . . . . . . . . . . . . . . . . . .
4
1.2
Architettura ERP dei dati . . . . . . . . . . . . . . . . . . . . . . . . . .
9
1.3
Architettura ad isole di sistemi legacy . . . . . . . . . . . . . . . . . . .
10
2.1
Schema esemplif. di impianto per il calcolo del P.U. delle voci di C.M. . .
19
2.2
Schema concettuale di approccio al C.M.E. . . . . . . . . . . . . . . . .
20
2.3
Esempio di computo metrico, parte 1 . . . . . . . . . . . . . . . . . . . .
21
2.4
Esempio di computo metrico, parte 2 . . . . . . . . . . . . . . . . . . . .
22
2.5
Esempio di computo metrico, parte 3 . . . . . . . . . . . . . . . . . . . .
23
3.1
Steps del progetto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
3.2
Raccolta dei requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
3.3
Modello concettuale del progetto . . . . . . . . . . . . . . . . . . . . . .
27
3.4
Passaggio dei dati tra tabelle del db 1 . . . . . . . . . . . . . . . . . . . .
28
3.5
Passaggio dei dati tra tabelle del db 2 . . . . . . . . . . . . . . . . . . . .
28
3.6
Suddivisione del progetto in un sotto-problema . . . . . . . . . . . . . .
29
3.7
Componenti del Listino Vendite . . . . . . . . . . . . . . . . . . . . . .
30
3.8
Componenti del Listino Acquisti . . . . . . . . . . . . . . . . . . . . . .
30
3.9
Componenti della Home . . . . . . . . . . . . . . . . . . . . . . . . . .
31
3.10 Schema E/R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
3.11 Screenshot della finestra Home . . . . . . . . . . . . . . . . . . . . . . .
32
3.12 Screenshot della finestra Listino Vendite . . . . . . . . . . . . . . . . . .
33
iv
Elenco delle figure
v
3.13 Screenshot della finestra Listino Acquisti . . . . . . . . . . . . . . . . . .
34
3.14 Risultato della stampa di un computo metrico, parte 1 . . . . . . . . . . .
35
3.15 Risultato della stampa di un computo metrico, parte 2 . . . . . . . . . . .
36
3.16 Risultato della stampa di un computo metrico, parte 3 . . . . . . . . . . .
37
3.17 Risultato della stampa di un computo metrico, parte 4 . . . . . . . . . . .
38
3.18 Risultato della stampa di un computo metrico, parte 5 . . . . . . . . . . .
39
3.19 Risultato della stampa di un computo metrico, parte 6 . . . . . . . . . . .
40
3.20 Risultato della stampa di un computo metrico, parte 7 . . . . . . . . . . .
41
4.1
Interfaccia visuale di MySQL Workbench . . . . . . . . . . . . . . . . .
47
4.2
Il Forward Engineering di MySQL Workbench . . . . . . . . . . . . . .
48
4.3
Il Reverse Engineering di MySQL Workbench . . . . . . . . . . . . . . .
49
4.4
La funzione di sincronizzazione di MySQL Workbench . . . . . . . . . .
50
4.5
Il linguaggio Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
4.6
IDE di sviluppo Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
4.7
IDE di sviluppo Netbeans . . . . . . . . . . . . . . . . . . . . . . . . . .
53
Introduzione
Da alcuni decenni le tecnologie dell’informazione (IT) sono oggetto di crescente
interesse, soprattutto da parte dalle grandi aziende alla ricerca di strategie concorrenziali per emergere in un mercato sempre più agguerrito. Storicamente, i primi vantaggi
derivanti dall’introduzione di tali tecnologie si realizzarono in termini di aumento di
produttività. Col passare del tempo, ci si rese conto che esse potevano garantire vantaggi strategici non solo relativamente alle funzioni produttive, ma anche in termini di
competitività sul mercato: disponibilità di informazioni in tempi brevi, maggiore flessibilità decisionale (possibilità di valutare un numero maggiore di alternative), migliore
utilizzo e controllo delle risorse. (5)
Con l’evoluzione delle tecnologie di informatizzazione, accade sempre più spesso,
di trattare con la veste informatica anche gli aspetti più soft della gestione, in tali circostanze, il sistema informativo gestionale rappresenta sempre più l’immagine riflessa
“in formato digitale” dell’azienda, al punto che dove le immagini non si sovrappongono perfettamente, non è detto che a dover mutare sia il sistema informativo gestionale,
verificandosi sempre più frequentemente casi in cui accade il viceversa. (6)
In conseguenza del decreto “Codice degli appalti” in vigore dal 1 Luglio 2006, è
riservato un posto di rilievo all’appalto integrato: con tale procedura di gara si consente all’impresa che dovrà costruire, di controllare anche la progettazione esecutiva. È
previsto pertanto un aumento di questa forma di appalti e delle connesse attività computistiche, di valutazione e contabili, sia a carico dell’impresa in gara, sia durante il
successivo controllo del processo costruttivo da parte della medesima impresa e del
vii
INTRODUZIONE
viii
committente, in contraddittorio. (4)
Gli argomenti trattati, in questa relazione, dunque sono quelli relativi all’attività
di misurazione e quantificazione dei lavori, in particolare la gestione della contabilità
lavori su base informatica, a seguito del lavoro di tirocinio, avente come obiettivo la
progettazione e lo sviluppo di un software gestionale che semplifichi le operazioni di
calcolo dei computi metrici, svolto per la Monte Impianti, un’azienda, attiva ormai da
4 anni, operante nel territorio Modenese, in ambito edilizio, in particolare nel settore
idro-termo-idraulico.
Capitolo 1
Lo stato dell’arte
1.1
Il software gestionale
Il software gestionale rappresenta l’insieme dei software che automatizzano i processi di gestione all’interno delle aziende. Come per tutti i prodotti software ha avuto
una rapida evoluzione dopo i primi anni settanta legata soprattutto alla progressiva diminuzione del costo degli elaboratori e alla diffusione della professione di sviluppatori
software. Anche la nascita di ambienti di sviluppo come il COBOL ha accelerato il
processo di diffusione portando il computer e software dedicati alla gestione aziendale
sempre più vicino a tutti i lavoratori. Intorno agli anni novanta si è assistito ad un
cambiamento, il passaggio dai software di gestione con interfaccia a caratteri a quelli
di nuova generazione ad interfaccia grafica, inoltre le stampe sono passate dalle tipiche
a caratteri e quelle grafiche su laser. (1)
Per capire meglio cos’è un software gestionale si prenderanno in considerazione
diverse prospettive.
È possibile descrivere un gestionale in base alle dimensioni:
• piccole dimensioni se si occupa soltanto di differenziati processi gestionali
• medie dimensioni se si occupa di diversi processi gestionali tra loro connessi
1
CAPITOLO 1. LO STATO DELL’ARTE
2
• grandi dimensioni se si occupa di tutti o una buona parte dei processi aziendali.
È possibile descriverlo in base alle funzionalità:
• gestione magazzino
• gestione contabilità
• gestione anagrafiche
• gestione ciclo attivo
• gestione ciclo passivo
• gestione finanziaria, . . .
È possibile descriverlo in base ai livelli di supporto:
• supporto operativo: software dedicato al supporto di tutti i processi operativi, al
miglioramento degli scambi d’informazione in senso orizzontale (supporto agli
scambi d’informazione tra i vari reparti del livello più basso della scala gerarchica). Ne sono un esempio tutti i software che vengono utilizzati direttamente
dagli addetti del processo di produzione: acquisizione materie prime, software
per l’avvio della macchina di produzione, gestione dei work in progess, . . .
• supporto direzionale: software dedicato al supporto di tutti i processi direzionali
aziendali. Ottimizzazione degli scambi d’informazione dal livello più basso al
livello più alto della scala gerarchica (informazione per il controllo dei processi
operativi). Ottimizzazione degli scambi d’informazione dal livello più alto al
livello più basso (informazione di direzione dei processi operativi). Un esempio
sono i software che vengono utilizzati dai responsabili di un determinato processo per il controllo del numero di prodotti venduti o, più in generale, per la
misurazione delle performance di processo.
CAPITOLO 1. LO STATO DELL’ARTE
3
• supporto strategico (miglioramento obiettivi strategici): supporto alle decisioni
strategiche del management aziendale attraverso un miglioramento dell’efficacia
organizzativa. Esistono software in grado di effettuare simulazioni sul comportamento di un determinato processo sulla base dei dati storici dell’azienda. La
previsione futura circa l’andamento di un processo è un ottimo supporto alle
decisioni strategiche.
È da notare, comunque, che un software gestionale possiede delle complicazioni che
vanno ben al di là delle competenze informatiche. Un software gestionale è un sistema molto complesso che raggruppa diverse tecnologie informatiche e che deve
assolutamente trovare sinergie con la situazione aziendale in cui viene adoperato.
Se ciò non avviene il risultato potrebbe essere un fallimento dal punto di vista gestionale del progetto informatico: potrebbero peggiorare gli scambi d’informazione tra
i vari reparti, si potrebbero creare malcontenti tra gli utilizzatori, se non viene correttamente adoperato si rischia di non avere dati corretti per fare valutazioni adeguate di
controllo sui processi. In poche parole si potrebbero spendere costi e tempi eccessivi
non anticipatamente preventivati. (2)
1.2
Sistemi ERP: Enterprise Resource Planning
L’acronimo ERP (Enterprise Resource Planning) è stato coniato agli inizi degli anni Novanta dal Gartner Group per indicare una suite di moduli applicativi integrati che
supportano l’intera gamma dei processi di un’impresa. Oggi, una suite completa comprende decine di moduli applicativi, che possono essere schematicamente classificati
nei tre gruppi di moduli core settoriali, moduli core intersettoriali e moduli extended.
Uno schema generale della suite ERP è in Figura1.1, dove la suite ERP è rappresentata da uno schema a T. I moduli settoriali sono la gamba della T, in quanto
rappresentano la verticalizzazione delle applicazioni in ogni singolo settore industriale. La barra è formata dai moduli intersettoriali, in quanto orizzontali rispetto ai settori
CAPITOLO 1. LO STATO DELL’ARTE
4
industriali, e dai moduli extended, che integrano l’azione degli ERP verso i mondi dei
clienti e dei fornitori. La Figura1.1 riporta anche un sommario elenco dei titoli dei
principali moduli, che sono illustrati qui di seguito.
Figura 1.1: Schema a “T” di un sistema ERP
1.2.1
Moduli core intersettoriali
I moduli core intersettoriali sono sostanzialmente invarianti rispetto ai singoli settori industriali; in generale, informatizzano le attività aziendali di supporto.
I moduli istituzionali, così detti in quanto riflettono la regolamentazione pubblica, servono le attività amministrative, come la contabilità civilistica, la contabilità gestionale e la finanza aziendale, e la gestione delle risorse umane, che include sia le
procedure contabili delle paghe sia i processi di gestione e sviluppo del personale.
I sistemi direzionali comprendono una serie di moduli che servono i processi, appunto, di conduzione manageriale dell’impresa, come la pianificazione strategica, la
CAPITOLO 1. LO STATO DELL’ARTE
5
programmazione ed il controllo del budget, l’analisi dei costi e, più in generale, il reporting aziendale. Sono intersettoriali, in quanto trasversali ai settori industriali, anche
i moduli applicativi che pianificano e controllano le attività dei progetti ed elaborano
la contabilità degli investimenti.
Fra i moduli intersettoriali includiamo anche il portale aziendale. Apparso alla fine
degli anni Novanta, offre un accesso via Web alle informazioni aziendali. L’alta uniformità dei moduli intersettoriali ha favorito l’industrializzazione dell’offerta ERP in
termini di qualità/costo; per contro, il cuore del sistema informativo aziendale, quindi
il mercato maggiore, è dato dai moduli settoriali.
1.2.2
Moduli core settoriali
Le suite settoriali comprendono normalmente i moduli che supportano le attività
primarie dell’azienda, tipiche del settore; sono molto diversificate, poiché riflettono le
peculiarità d’ogni settore. Nella Figura1.1 è esemplificata, in sintesi estrema, la suite
del settore automobilistico. Essa comprende una serie di moduli, che servono i processi
d’approvvigionamento, produzione e vendita ai livelli di pianificazione, gestione degli
ordini, attività fisiche. La suite del settore automotoristico è diversa da quella del
settore elettrico, che invece comprenderà moduli per la programmazione e controllo
dei lavori (allacciamenti, nuovi impianti, dismissioni, ecc. . . ) e per la bollettazione.
Le suite settoriali sono numerose (per esempio il vendor SAP ne elenca una ventina)
ed è conseguentemente elevato il costo sostenuto dai vendor per concepirle, realizzarle
e mantenerle nel tempo. Non sorprendentemente, l’effettiva completezza delle suite
settoriali è piuttosto variabile. In generale, è massima nel settorea auto-motoristico,
terra d’origine degli ERP, mentre è più limitata in altri settori, come banche o pubblica
amministrazione, dove le suite includono ancora un limitato numero di moduli.
CAPITOLO 1. LO STATO DELL’ARTE
1.2.3
6
Extended ERP
L’extended ERP è formato da una serie di moduli che gestiscono le transazioni interaziendali e, più in generale, l’interazione fra più aziende o fra una singola azienda
e clienti o fornitori. In generale, queste suite supportano il ciclo vitale del prodotto
(PLM, Product Lifecycle Management), la catena d’approvvigionamento (nota come
SCM, Supply Chain Management), le interazioni con il cliente (CRM, Customer Relationship Management), l’E-Procurement e forniscono infrastrutture informatiche ai
cosiddetti Market Place. Queste suite sono apparse sul mercato a partire dal 1995 come
applicazioni indipendenti e separate dagli ERP core; con gli anni 2000, sono state integrate. Il valore distintivo dello schema ERP extended è l’integrazione fra transazioni
interaziendali e transazioni interne. Per esempio, le suite ERP core sono integrate con
i moduli CRM, che gestiscono i canali di contatto con il cliente (call-center, internet,
agenti, negozi). L’integrazione fra CRM ed ERP core assicura l’effettiva esecuzione
delle richieste del cliente (p.e. l’ordine di un’automobile, raccolto dai sistemi CRM,
è programmato e controllato dai sistemi ERP core che gestiscono la produzione e la
distribuzione). In altri termini, i sistemi CRM e, in generale, i sistemi d’interazione
formano il frontend della azienda verso clienti e fornitori, mentre i sistemi ERP core
formano il backend.
1.2.4
Diffusione
Con l’estensione dello schema ERP, le aziende quindi hanno a disposizione una
gamma molto ampia d’applicazioni informatiche; infatti:
• le suite core informatizzano le attività aziendali interne di livello operativo e
direzionale;
• le suite extended informatizzano le transazioni interaziendali verso fornitori e
clienti.
CAPITOLO 1. LO STATO DELL’ARTE
7
Non sorprendentemente, gli ERP sono divenuti uno dei massimi mercati d’applicazioni software. Alla fine degli anni Novanta, nel mondo si spendevano annualmente oltre
23 miliardi di dollari e i sistemi ERP erano installati in oltre 30.000 imprese. Oltre il
50% delle aziende europee ha uno o più moduli ERP e oltre il 35% li usa in tre o più
aree funzionali. Il numero totale di vendor sul mercato può essere stimato prossimo al
centinaio. Tuttavia, solo alcuni, fra cui SAP, Oracle, Peoplesoft e JDEdwards, sono in
grado di offrire l’intera gamma ERP. Il loro scarso numero riflette gli enormi investimenti necessari allo sviluppo ed al mantenimento di una gamma completa di moduli,
intersettoriali e settoriali (Tabella1.1).
Vendor
Vendite
Quota mercato
SAP
5.839
30%
Oracle
2.870
15%
Peoplesoft
1.736
9%
J.D.Edwards
980
5%
Altri
7.127
41%
Tabella 1.1: Vendite 2000 dei maggiori vendor ERP (da AMR 2001)
Terza azienda software del mondo, SAP è nata intorno all’idea ERP e ha una quota
stimata intorno ad un terzo del mercato. Il primo prodotto SAP, R/1, è stato un software
batch per mainframe, sostituito nel 1981 da R/2 on-line e, nel 1992, da R/3 on-line e
su architettura client-server, che negli anni 2000 è stata integrata da architetture webenabled. A fine 2001, SAP, leader di mercato, dichiarava 12 milioni di utenti, 44.500
installazioni, 1.000 aziende in partnership di vario tipo, 21 suite settoriali.
Oracle lancia la sua suite ERP negli anni Novanta, iniziando anch’essa dal core
ERP poi integrato a portali e CRM, sfruttando ampiamente le proprie tecnologie di basi
dati e Internet. Punto di partenza di Peoplesoft sono i sistemi di gestione delle risorse
CAPITOLO 1. LO STATO DELL’ARTE
8
umane, cui si aggiunge, dalla metà degli anni Novanta, la filiera standard ERP e CRM.
JD Edwards, fondata nel 1977, si rivolge più specificatamente alla media impresa con
un’offerta piuttosto ampia (6.000 clienti, di cui 300 in Italia).
Ai vendor multinazionali a gamma completa, si affiancano qualche decina di vendor multinazionali focalizzati su gruppi di moduli o su estensioni dello ERP core. Per
esempio, Siebel, leader nel CRM, ha sviluppato un’offerta completa di CRM, che è a
sua volta verticalizzata in soluzioni settoriali ed integrata con suite ERP. A sua volta,
SAS, azienda leader di software statistici, offre una suite di CRM analitico, che elabora analisi sul comportamento del cliente o supporta la pianificazione delle campagne
di promozione. I grandi vendor multinazionali dominano nella grande impresa. Nelle
piccole e medie imprese, invece, i primi 5 vendor hanno solo una quota minoritaria del
mercato.
1.2.5
Il paradigma ERP
La suite ERP rispecchia una precisa concezione del sistema informativo aziendale,
con caratteristiche distintive:
• unicità dell’informazione;
• estensione e modularità funzionale;
• prescrittività.
Queste caratteristiche formano un paradigma funzionale, che indichiamo come paradigma ERP.
Unicità dell’informazione
Gli ERP sono caratterizzati da una base dati unica. Unica fisicamente od unificata
attraverso un comune repository dei dati e servizi di replica automatica, memorizza i
dati condivisi intorno alla quale ruotano i moduli. La base dati unica è una conquista
sostanziale degli ERP che ha molti ed importanti vantaggi (Figura1.2).
CAPITOLO 1. LO STATO DELL’ARTE
9
Figura 1.2: Architettura ERP dei dati
In primo luogo, l’aggiornamento unificato delle basi dati abilita la sincronizzazione di processi gestionali interdipendenti: p.e. l’arrivo di un materiale al magazzino
aggiorna la situazione delle scorte, degli ordini ai fornitori e della contabilità dei fornitori, dando ai corrispondenti processi un’informazione unica e sincronizzata. Ciò non
è possibile nelle tradizionali architetture ad isole, dove le basi dati sono separate e i
dati comuni sono sincronizzati attraverso periodici processi di allineamento. Nell’architettura ad isole, le informazioni sullo stesso oggetto (cliente, fornitore o materiale)
sono temporalmente sfasate e ridondanti: il mancato pagamento di un cliente può non
essere notificato in tempo alla gestione degli ordini, così che la situazione del cliente
alla gestione degli ordini contrasta con quella della contabilità clienti (Figura1.3).
CAPITOLO 1. LO STATO DELL’ARTE
10
Figura 1.3: Architettura ad isole di sistemi legacy
In secondo luogo, l’architettura ERP certifica l’informazione e ne garantisce la
tracciabilità: ogni evento di un processo per esempio la gestione di un magazzino, è testimoniato da un documento, per esempio una bolla di prelievo, che è specificatamente
registrato nella base dati; ogni evento gestionale si riflette in una variazione di stato
della base dati e la variazione é certificata da un documento.
Infine, l’unicità della base dati a livello operativo favorisce, in modo del tutto naturale, l’unicità dei dati per la direzione aziendale. L’unicità è ottenuta attraverso l’integrazione verticale dell’informazione operativa e dell’informazione manageriale. L’integrazione verticale si basa su un Data Warehouse, che memorizza i dati, aggregati e
trasformati, estratti dalla base dati operativa (e da altre fonti). I dati sono elaborati da
una suite di applicazioni, dette SEM (Strategic Enterprise Management) od EPM (Enterprise Performance Management), che assistono il management nella formulazione
CAPITOLO 1. LO STATO DELL’ARTE
11
della strategia, nel budgeting, nell’analisi dei risultati.
L’integrazione rende disponibili informazioni sintetiche univoche (in quanto basate su dati operativi univoci ed unici), con un vantaggio rilevante per il management.
Come molti studi hanno notato, la qualità dei dati è fra i vantaggi più apprezzati delle
soluzioni ERP.
Estensione e modularità
Grazie all’estensione molto ampia, la suite ERP si propone come soluzione di riferimento per il sistema informativo aziendale, nelle sue componenti intra-aziendale,
operativa direzionale, ed inter-aziendale.
Tuttavia, l’estensione funzionale sarebbe vana se la suite non fosse composta da
moduli autosufficienti. Grazie alla modularità, l’azienda può scegliere una strategia di
implementazione coerente con la situazione dei sistemi e con il grado di rischio che è
in grado di sostenere.
Una diffusa strategia semplice ed a basso rischio è l’implementazione parziale: l’azienda, cioè, sceglie di realizzare un piccolo numero di moduli, che vanno a sostituire
preesistenti sistemi legacy.
La strategia, più ambiziosa, di implementare un elevato numero di moduli può
essere attuata in due varianti, one stop shopping e best of the breed. Nel primo caso,
privilegiando linearità e semplicità, l’azienda usa i moduli di un solo vendor, mentre,
nel secondo, mette insieme moduli di più vendor, alla ricerca della soluzione ottimale
per ogni processo aziendale, p.e. scegliendo il vendor A per la gestione del personale
ed il vendor B per la gestione amministrativa.
Osserviamo che, data la modularità e l’ampia estensione funzionale degli ERP, la
progettazione diventa simile ad una specie di LEGO, in cui è critico l’incastro fra i
diversi moduli ERP, magari di più fornitori, e fra i moduli ERP e gli eventuali moduli
legacy. Infatti, vanno garantite l’unicità e la sincronizzazione delle informazioni, attraverso interfacce standard, API (Application Programming Interface) e software di
CAPITOLO 1. LO STATO DELL’ARTE
12
workflow o d’integrazione.
Prescrittività
I moduli ERP incorporano, in misura significativa, una logica di processo gestionale. Per esempio, la transazione di ricevimento dei materiali a magazzino presuppone
un ordine al fornitore: un materiale non entra in azienda se non è stato ordinato e non
può essere ordinato se non è stato richiesto da un ente aziendale autorizzato. Il software quindi norma il comportamento dell’utente aziendale, ribaltando la tradizionale
concezione secondo cui è il software che si deve adattare all’utente.
La prescrittività ha importanti implicazioni. In primo luogo, semplifica l’analisi
dei requisiti. L’analista, infatti, non deve specificare tutto il processo gestionale e tutto
il sistema, ma si concentra sulle differenze rispetto al modello standard: definisce il
processo ottimale, lo incrocia con le funzioni del sistema e sceglie le funzionalità del
sistema. La progettazione funzionale diventa quindi una sorta di attività “taglia ed
incolla” su di un menu di opzioni predefinite.
In secondo luogo, la prescrittività favorisce la standardizzazione dei processi ed
uniforma i comportamenti, un vantaggio rilevante per le aziende distribuite territorialmente e le multinazionali.
Infine, la prescrittività può favorire una razionalizzazione dei processi, facendo
coincidere il progetto informatico ERP con un progetto di razionalizzazione organizzativa, meglio noto sotto la sigla BPR (Business Process Reengineering).
Tuttavia, la prescrittività comporta anche una certa rigidità, che può rendere gli
ERP incompatibili con le specificità dell’utente. Infatti, se la razionalizzazione organizzativa richiesta è vasta e profonda, il progetto implica un costoso e rischioso intervento sul tessuto organizzativo dell’impresa. L’intervento può risultare infattibile per i
tempi, troppo stretti, per i contenuti dei processi, incompatibili con il sistema dei valori
esistente nell’azienda, per il rischio della trasformazione, troppo ampia, o, infine, per
la mancanza di un gruppo di lavoro di quantità e qualità adeguata o, equivalentemente,
CAPITOLO 1. LO STATO DELL’ARTE
13
per limiti di budget. L’alternativa ad adattare l’azienda al sistema è quella, piuttosto
costosa e di un certo rischio tecnico, di adattare il sistema all’azienda, riscrivendo e/o
modificando i moduli software.
In conclusione, il fenomeno ERP rispecchia la progressiva uniformazione del sistema informativo aziendale ed interaziendale in un paradigma completo ed integrato che
ha trasformato, in varia misura, le aziende che lo hanno adottato. La prima sostanziale
trasformazione è in realtà la trasformazione del sistema informativo aziendale, che da
collezione di applicazioni diverse ed indipendenti diviene un’ordinata catena di montaggio e distribuzione dell’informazione. La trasformazione del sistema informativo
può favorire la trasformazione dei processi a livello operativo, direzionale, interaziendale. La trasformazione direzionale é un’area di potenziale alto successo, che integra
bene modelli manageriali maturi con una tecnologia adeguata. La trasformazione interaziendale è ancora agli inizi. Il contributo degli ERP all’innovazione del modello di
business appare limitato e incidentale. Le trasformazioni qui discusse sono potenziali.
La trasformazione effettiva è funzione dell’effettiva capacità dell’azienda di sfruttare
le potenzialità ERP attraverso un’opportuna trasformazione del tessuto organizzativo
ed un approccio cauto e ben bilanciato al progetto ERP. Per misurare i benefici, potenziali ed effettivi degli ERP, è conveniente considerare il valore totale della trasformazione, concepito come la somma algebrica dei vari guadagni d’efficienza operativa e
d’efficacia indotti dai progetti ERP.
Capitolo 2
Computi metrici
In questo capitolo si parlerà dei computi metrici evidenziandone il pregnante significato nel contesto del processo di produzione edilizia, sottolineandone l’importanza ai
fini della gestione del contratto d’appalto, sia per il committente che per l’appaltatore,
e la necessità che il prezzo dell’appalto ottenuto dalla stima medesima non abbia a
variare durante l’esecuzione fisica del lavoro. (8)
2.1
Il computo metrico
Il computo metrico (C.M.) è un documento prettamente tecnico, che viene elaborato, per necessità gestionali, sia dal committente (cliente) che dall’appaltatore principale (main contractor).
Il committente ha come obiettivo prioritario, quello di definire se la sua iniziativa economica, sia essa pubblica o privata, rientri nei parametri prefissati di costo.
L’impresa esecutrice delle opere, deve necessariamente elaborare il C.M. per poter
partecipare ad una gara con forma di compenso a corpo. L’elaborato, infatti, serve a
determinare l’importo di offerta, o il ribasso d’asta se si tratta di una gara per lavori
pubblici di cui viene a costituire il preventivo.
Il preventivo di gara poi (se verranno acquisiti i lavori) dovrà essere revisionato
15
CAPITOLO 2. COMPUTI METRICI
16
prima dell’inizio dei medesimi per definire nel minimo dettaglio tutte le opere da realizzare, al fine di verificare se quanto è stato valutato in fase di gara - e successivamente
definito contrattualmente con il committente - rientra nel budget di commessa, trasformandosi così nel preventivo operativo. Quest’ultimo, da questo momento, diventa
il perno su cui ruota tutto il project management, cioè l’intera gestione del processo
costruttivo. La rilevanza, già in questa fase operativa-gestionale, di differenze nelle
valutazioni tecniche ed economiche (es. quantità in meno e maggiori oneri rispetto al
budget contrattuale) mette necessariamente in moto il regime delle riserve.
Si può dunque definire il computo metrico come la quantificazione analitica e
sistemica di tutte le attività di lavoro necessarie per realizzare una data opera nella sua
completezza: ad esempio, nel settore civile-abitativo, dallo scavo di sbancamento alla
posa in opera delle porte e delle altre finiture.
L’elaborazione del C.M. richiede una consumata esperienza in lavori del tipo di
quell’oggetto in valutazione, perché il tecnico incaricato deve avere la capacità di individuare esattamente l’opera compiuta tramite la propria immaginazione e fantasia.
Tale elaborazione, inoltre per raggiungere il grado di valutazione più vicino possibile
alla realtà, deve essere necessariamente supportata da disegni e specifiche tecniche di
tipo costruttivo.
Con l’attuale sviluppo del controllo costi e della programmazione il computo metrico è diventato un documento di primaria importanza, poiché i suoi dati vengono
utilizzati per la gestione a vita intera dell’appalto.
Un C.M. si può definire realmente operativo, secondo le attuali metodologie gestionali, solo se da esso è possibile estrapolare:
• il monte ore della manodopera, ossia le “ore dirette” (per la programmazione)
• la quantificazione e valutazione dei materiali (per acquisti e gestione materiali)
• la produzione (resa) per ogni categoria di lavoro (in funzione della squadra tipo
e dei mezzi che si suppone saranno utilizzati per realizzare le opere).
CAPITOLO 2. COMPUTI METRICI
17
A tal fine è necessario:
• calcolare le quantità di ogni singola attività di lavoro, scrupolosamente e secondo
precise norme di misurazione. Nel definire tali norme è opportuno tener conto
anche delle specifiche consuetudini della località in cui si lavora, per rendere più
comprensibile il linguaggio ed efficace la comunicazione tra chi opera in cantiere (possibilmente usare anche la terminologia locale sull’uso di un particolare
attrezzo o tipo di lavoro da eseguire).
• esporre una descrizione dettagliata delle modalità di esecuzione delle opere, dei
tipi di materiali da impiegare e di tutti gli oneri necessari per consegnare il lavoro
finito e funzionale in ogni sua parte.
Il C.M. ha una duplice divisione logico-strutturale: la prima afferisce al tipo di
opera da realizzare (opere edilizie, stradali, marittime, ecc.); la seconda alla divisione
fisica e/o sistema secondo la quale si vuole impostare il computo metrico (es. fabbricato A e B per un complesso residenziale; edificio turbina e caldaia per un impianto di
produzione energia, ecc. . . ).
Quindi si può affermare che per elaborare compiutamente un computo metrico è necessario conoscere:
• le discipline tecnologiche cui appartiene l’opera da realizzare (in generale più di
una)
• la forma di compenso
• le categorie e sotto-categorie di lavoro
• le norme di misurazione
• gli oneri che si intendono inserire in ogni voce di applicazione
• la divisione fisica dell’opera da computare
• la divisione sistemica della stessa.
CAPITOLO 2. COMPUTI METRICI
2.2
18
Il computo metrico estimativo
Il computo metrico estimativo (C.M.E.) si può definire come la valutazione economica di tutte le quantità ricavate mediante l’elaborazione del computo metrico; esso
perciò prende anche il nome di “stima dei lavori”, “perizia di stima”, o semplicemente
“preventivo”.
La stima è ottenuta applicando alle singole quantità i prezzi unitari ottenuti da apposite analisi dei prezzi, da elenchi prezzi forniti dal committente o emessi dalle camere
di commercio, da consorzi di ditte specializzate o da enti concessionari istituzionali.
L’analisi dei prezzi, qualora venga effettuata, ha lo scopo di determinare il prezzo di
applicazione per ogni singola attività di lavoro (voce d’opera), prendendo in esame
tutti i fattori della produzione, cioè i materiali, la manodopera, i mezzi meccanici, i
noleggi, ed infine gli opportuni ricarichi, come: le spese di cantiere, le spese generali
e l’utile dell’impresa che concorrono alla formazione del prezzo medesimo.
CAPITOLO 2. COMPUTI METRICI
19
Figura 2.1: Schizzo esemplificativo di un impianto per il calcolo del prezzo unitario
delle voci di C.M.
CAPITOLO 2. COMPUTI METRICI
Figura 2.2: Schema concettuale di approccio al C.M.E.
20
CAPITOLO 2. COMPUTI METRICI
21
computo metrico componenti
codice
Descrizione
U.M. Quantità
Prezzo
Importo
RETE IMPIANTO IDRICO
(le quantità sono da verificare con gli elaborati grafici di
progetto)
Impianti di adduzione idrica, diametri come da elaborati grafici,
realizzati con seguenti caratteristiche:
- Tubo multistrato composto da tubo interno in polietilene
reticolato, strato legante, strato intermedio in alluminio saldato di
testa longitudinalmente, strato legante e strato esterno in
polietilene ad alta densità
- Conduttività termica 0,43 W/mK
- Coefficiente di dilatazione termica 0,026 mm/mK
- Temperatura di esercizio 0 - 70 °C
- Temperatura di punta di breve durata ( secondo DIN 1988 ) 95
°C
- Pressione d’ esercizio 10 bar
- Raccorderia in ottone stampato e in materia sintetica, con ORing in EPDM e rondella in PE-LD anti elettrocorrosione
Lavorazione da effettuare pressando direttamente il tubo sul
raccordo con le apposite attrezzature omologate dal produttore
del sistema.
Le istruzioni del fabbricante riguardo il montaggio e la posa in
opera, dovranno essere scrupolosamente osservate.
in opera
c.po
1,0
€ 2.000,00
€ 2.000,00
Complesso di scarico per ogni apparecchio, con tubazione di
scarico al piano, in polietilene con giunzioni ad innesto.
Compresi pezzi speciali ed ancoraggi. (costo compreso nella
voce 1)
in opera
Colonne di scarico a cura impresa edile.
APPARECCHI SANITARI
BAGNI
1
Figura 2.3: Esempio di computo metrico, parte 1.
CAPITOLO 2. COMPUTI METRICI
22
computo metrico componenti
codice
Descrizione
VOCE 1
Blocco bagno comprensivo di:
Collettore di distribuzione idrosanitaria preassemblato in cassetta.
Lavabo in vetrochina sospeso, colore bianco. Completo di piletta
di scarico con guarnizioni e comando a saltarello, raccordo di
scarico e sifone.
Vaso sospeso in vetrochina, colore bianco, con scarico a
pavimento. Sedile di tipo pesante. Completo di cassetta di
risciacquo ad incasso e accessori di collegamento. Comando a
pulsante su placca esterna a parete.
Bidet in vetrochina sospeso, colore bianco. Completo di piletta di
scarico con guarnizioni e comando a saltarello, raccordo di
scarico e sifone.
Piatto doccia in gres porcellanato,colore bianco. Dimensione
80x80 cm.
Completo di gruppo miscelatore monocomando da incasso,
doccia con soffione, piletta di scarico con griglietta, sifone a
scatola con tappo e coperchio cromato.
U.M. Quantità
Prezzo
Importo
Marca: IDEAL STANDARD o similare
Modello:
n
5,0
€ 2.000,00
€ 10.000,00
n
1,0
€ 624,00
€ 624,00
n
1,0
€ 515,00
€ 515,00
n
1,0
€ 193,00
€ 193,00
n
1,0
€ 33,00
€ 33,00
n
1,0
€ 241,00
€ 241,00
n
1,0
€ 62,50
€ 62,50
Lavabo reclinabile c/mov meccanico completo di pikletta,
miscelatore, portasapone.
Marca: BOCCHI o similare
Modello: NS98221
NABI2 -Vaso-bidet c/cass. Esterna ceramica per disabili
Marca: BOCCHI o similare
Modello: NS96101
Miscelatore termostatico
Marca: BOCCHI o similare
Modello: NMB016
Doccetta
Marca: BOCCHI o similare
Modello: NV00621
Maniglione reclinabile.
Marca: BOCCHI o similare
Modello: MALUX900M
Maniglione
Marca: BOCCHI o similare
Modello: MALUX415
2
Figura 2.4: Esempio di computo metrico, parte 2.
CAPITOLO 2. COMPUTI METRICI
23
computo metrico componenti
codice
Descrizione
U.M. Quantità
Prezzo
Importo
Scaldasalviette elettrico riempito con liquido ad alta conducibilità,
fornito con resistenza elettrica da 300 W
Marca: ZEHENDER o similare
Modello:
n
3,0
€ 200,00
€ 600,00
c.po
1,0
€ 300,00
€ 300,00
Blocco cucina comprensivo di attacco acqua calda/fredda da
collettore premontato per lavello zona preparazione e lavello zona
lavaggio, completo di tubazioni di scarico (restano esclusi sanitari
e rubinetterie a carico dell'arredamento cucina).
INSTALLAZIONE
Raccorderia, pezzi speciali, attrezzature, materiali di consumo e
quant'altro necessario al completamento dell'impianto.
a corpo
Prove di tenuta e circolazione
a corpo
PREZZO COMPLESSIVO DELLA FORNITURA
(Trasporto e manodopera inclusi)
€ 14.568,50
3
Figura 2.5: Esempio di computo metrico, parte 3.
Capitolo 3
Caso di studio
La “Monte impianti”, essendo un’azienda del settore idro-termo-idraulico, operante quindi in ambito edilizio, sia per la cooperazione con altre aziende, dello stesso
ambito, che per la partecipazione a gare di appalto, occorre che presenti un computo
metrico.
Partendo da un modello di foglio elettronico, l’azienda ha richiesto la progettazione e conseguente sviluppo di un applicativo, in grado di semplificare il processo di
compilazione/redazione dei computi metrici.
Figura 3.1: Steps tipici dell’attività di ingegneria del software.
25
CAPITOLO 3. CASO DI STUDIO
3.1
26
Raccolta dei requisiti
Dalla raccolta dei requisiti, è emersa la necessità di avere (Figura3.2):
• una finestra “Listino acquisti” dalla quale sia possibile accedere ai prodotti del
proprio fornitore.
• un database che contenga i prodotti del fornitore
• una finestra “Listino vendite” da cui sia possibile creare una singola voce, relativa al tipo di categoria di impianto (composta di più voci del listino acquisti), che
andrà aggiunta al computo oppure salvata come modello, per essere facilmente
riutilizzata
• un database che contenga le voci del listino vendite
• un pannello che permetta di, differenziare e, selezionare le varie categorie di
impianti (solare, condizionamento, . . . )
• una finestra principale “Home” , che riepiloghi il totale dei singoli impianti e il
totale complessivo del computo, dato dalla somma dei vari impianti.
Figura 3.2: Raccolta dei requisiti
CAPITOLO 3. CASO DI STUDIO
3.2
27
Analisi dei requisiti
Tramite l’analisi dei requisiti, si è cercato di schematizzare i vari punti della futura applicazione, in modo da avere un modello da cui partire per l’implementazione
(Figura 3.3).
Figura 3.3: Modello concettuale del progetto
CAPITOLO 3. CASO DI STUDIO
28
Si è partiti dal fatto che, una voce
di computo, quindi del listino vendite, è
composta di più voci del listino acquisti
(i materiali). L’idea, perciò è stata quella di copiare, i record di interesse, dalla
tabella acquisti ad una tabella di supporto, quella dei materiali ed associarli alla tabella vendite con una foreign key1
Figura 3.4:
(Figura 3.4).
Ogni progetto può avere più voci di
computo (preventivi) di categorie di impianti diversi. Analogamente, come fatto
in precedenza, l’idea è quella di copiare
i record dalla tabella vendite a quella dei
preventivi, e associare quest’ultima alla
tabella progetti, con un chiave esterna
(FK) (Figura 3.5).
Figura 3.5:
1
oppure FK, denota una chiave esterna nel contesto dei database relazionali, è un vincolo di referenza tra due tabelle. La chiave esterna identifica una colonna o un insieme di colonne di una tabella
(referenziante) che referenzia una colonna o un insieme di colonne di un’altra tabella (referenziata). (1)
CAPITOLO 3. CASO DI STUDIO
29
Il passo successivo è stato quello di
analizzare gli elementi, che al termine
andranno implementati nell’interfaccia grafica.
Data la natura del progetto, è stato
necessario scomporlo in un sotto-problema
più facilmente affrontabile (si veda Figura 3.6).
Si è presa dunque in esame la voce di
computo, che è risultata essere la parte
più complessa dell’intera attività progettuale.
Figura 3.6:
Nel dettaglio, la finestra Listino vendite, avrà (Figura3.7):
• una parte dedicata alle operazioni di calcolo
• una parte dedicata per listare i materiali, che faranno parte della descrizione della
voce di computo.
La finestra Listino acquisti avrà la possibilità di (Figura3.8):
• visualizzare i materiali, prelevati dal db
• filtrare i risultati, con un apposito campo “cerca”
• trasferire nel listino vendite il record selezionato.
La finestra Home, infine, sarà composta da (Figura3.9):
CAPITOLO 3. CASO DI STUDIO
• una parte che mostra le categorie di impianti
• una parte che mostra le voci di computo relative all’impianto selezionato
• una parte di ricapitolazione.
Figura 3.7: Componenti del Listino Vendite
Figura 3.8: Componenti del Listino Acquisti
30
CAPITOLO 3. CASO DI STUDIO
31
Figura 3.9: Componenti della Home
3.3
Progettazione
La (Figura3.3) mostra lo schema E/R
della base di dati derivante dalla sua progettazione con “MySQL Workbench”2 .
La tabella acquisti contiene voci di materiali dei fornitori, importati da diversi
listini (camera di commercio di Modena,
. . . ) e che fornisce dati alla finestra Listino Acquisti. La tabella vendite insieme
a quella materiali supportano la finestra
Listino Vendite, per la memorizzazione
di singole voci di computo. Le tabelle
progetti e preventivi supportano la fine-
Figura 3.10:
stra Home per gestire i vari progetti di computo.
La finestra Home (Figura3.11) è il punto di partenza dell’intera applicazione, essa
è costituita di:
• una parte di riepilogo dove è possibile tenere sempre a vista i “totali” delle varie
categorie e dell’intero cantiere
2
È uno strumento grafico open source della Oracle per architetti, sviluppatori e DBA. Viene trattato
nel ??
CAPITOLO 3. CASO DI STUDIO
32
• una parte relativa alla categoria di impianto. Facendo click con il tasto destro
del mouse, all’interno del “Pannello impianti”, si crea una nuova istanza della finestra “Listino Vendite” da cui è possibile costruire la voce di computo
desiderata.
Figura 3.11: Screenshot della finestra Home
La finestra Listino Vendite (Figura3.12) è il cuore del programma. Come visto in
precedenza, nell’analisi dei requisiti, essa è formata da:
• una parte dedicata alle operazioni di calcolo
• una parte dedicata alla descrizione della voce di computo, composta da voci del
listino acquisti
• una parte di ricapitolazione.
Premendo il tasto destro, su una cella vuota del “Pannello materiali”, si crea una nuova
istanza della finestra Listino Acquisti, a cui viene passata come argomento il codice
CAPITOLO 3. CASO DI STUDIO
33
articolo della voce di preventivo. I valori della riga selezionata nel Listino Acquisti
vengono inseriti in un array reso disponibile con il metodo getSelectedMateriale() della
classe Materiali; inoltre viene scritto il record nella tabella materiali con la FK codart.
Con il metodo setValueAt() si scrive il contenuto dell’array nelle celle del Pannello
Materiali.
Figura 3.12: Screenshot della finestra Listino Vendite
La Figura3.13 mostra la finestra Listino Acquisti. I dati acquisiti dal database
vengono renderizzati tramite una jTable3 in cui è possibile filtrarli attraverso il campo
“Cerca”. Il testo ottenuto viene inserito in una query che viene passata al db, per
recuperare i dati di interesse.
Infine in Figura3.14 è riportato un esempio di stampa derivante dall’uso dell’applicazione. I prezzi sono stati volutamente omessi per questioni di privacy.
3
Componente grafico Swing di Java.
CAPITOLO 3. CASO DI STUDIO
Figura 3.13: Screenshot della finestra Listino Acquisti
34
CAPITOLO 3. CASO DI STUDIO
&" "* +
, # -
(,(,
35
,, .
+* /
!" # $! "
!
##.1&
+"
%& %& '
+ 0
( )
""""""""""""
'2 #%
'
Figura 3.14: Risultato della stampa di un computo metrico, parte 1
CAPITOLO 3. CASO DI STUDIO
36
+
2
.
2.3 1 )
# $ %$ & ' (
'&$
!
) *&$ (
) +% ,
*&
'$ %, &
).% )
- * $)
).43 :; ) *'$&(
/
.
+ $
%$
& '
5
5
5
5
5
)
1
$
1
)
'&$
! "
% ) *'$&(
# $ %$ & ' (
$*
& &
* % ) *'$&(
# $ %$ & ' (
'&$
) % %$
& & - &
*& $ &)&(( $ '&$ !
?
!
$!
+ ) *'$&( /
5 $ )) $ &$
5 * &$
# $
!
' , $& &
) (%*
($
!
4% & 1
& & '. 6
%1
%1
( $ 2%,
&
) '&$)9
">
!
- (
!
"
"
%1
(
"8
$&
" (
"+
!
$*
"
%1
&$&
%$ & ' (
'&$
"
"
@ "$ + ((&*2
1&$ )
2 ) - ) *'$&(
$ * +" + !!
2 &$ & & &*&
! )"+ @"
&,,
/
5 : & &*&
)
&
5 6 '' $
+ $
) &)9
5 1 1
&$* ( ,, 2 & 3 4
5 & & $& 3 4
5 ) ''
*& ( &
5 $ (& & ) '$ + $ '&$ %2
# $
50&
%1
'&$
) % %$
- '&$ ) & *&
/
( $ &$& &
) (%*
$& '&$
.%&
(
* & &
&1 9
.1= 3
" ) *'
/
& $& 484
1 & ) 2 ))9&
&
%, & '&$ 1 1
& (+
1
& (+
* %
((&
) & *&
' ( ) )
5 $ )) $ &$
' , $& &
5 % $ ,
& * &$ &
& '&
"+$ " ! + 7 "
( *&
- '&$ $ ()
" 8 $ * &
3 %2 .3&.1% * $)
# $ %$ & ' (
& &$* ( + -
'2
40 0
< 0 &1 )% , & +%* & (' $ , & $ ) *2%$& & %2
(&' $ 34
5 $ )) $
( $ &$&
67 '&$ ) & $& ) $)%
$ ()
*&
5 1 1
(+&$ '&$ &$)& $& ) $)%
).%
$&((
5 +&$$ $ *& '&$ ) & *&
& ) $)%
).% )
5 1 1
(+&$
67 '&$ &$)& $& ) $)%
(
5 % $ ,
& * &$
) (%*
. (
''1
13
%.
%$ & ' (
'&$
"
"
@ "$ + ((&*2
1&$ )
2 ) - ) *'$&(
5 4 & &*&
)
&
5 6 '' $
+ $
) &)9
5 1 1
&$* ( ,, 2 & 3 4
5 & & $& 3 4
5 ) ''
*& ( &
5 $ (& & ) '$ + $ '&$ %2
%1
$ * +" + !!
2 &$ & & &*&
! )"+ @"
&,,
/
%1
Figura 3.15: Risultato della stampa di un computo metrico, parte 2
CAPITOLO 3. CASO DI STUDIO
# $
!
%$ & ' (
'&$
"
"
@ "$ + ((&*2
1&$ )
2 ) - ) *'$&(
$ * +" + !!
2 &$ & & &*&
37
! )"+ @"
&,,
/
5 6 & &*&
)
&
5 6 '' $
+ $
) &)9
5 1 1
&$* ( ,, 2 & 3 4
5 & & $& 3 4
5 ) ''
*& ( &
5 $ (& & ) '$ + $ '&$ %2
# $
!
%$ & ' (
'&$
"
"
@ "$ + ((&*2
1&$ )
2 ) - ) *'$&(
%1
$ * +" + !!
2 &$ & & &*&
! )"+ @"
&,, (
/
5 : & &*&
)
&
5 6 '' $
+ $
) &)9
5 1 1
&$* ( ,, 2 & 3 4
5 & & $& 3 4
5 ) ''
*& ( &
5 $ (& & ) '$ + $ '&$ %2
# $
!
(
%$ & ' (
'&$
"
"
@ "$ + ((&*2
1&$ )
2 ) - ) *'$&(
"
"
%$ & ' (
& 8
'&$
&,,
"
(
%$ & ' (
& 8
'&$
&,,
+ !!
! )"+ @"
2 ) - ) *'$&(
/
%1
"
1&$ )
+ !!
! )"+ @"
2 ) - ) *'$&(
/
5 1 1
&$* ( ,, 2 & 3 4
5 & & $& 3 4
5 ) ''
*& ( &
5 $ (& & ) '$ + $ '&$ %2
# $
%$ & ' (
, &
.%
&*'&$ %$ & (
23&1
# + ? "
$
'&$
"+!D $" * & .?
8
#'&1
# + ? " $
"+!D $" * &
# + ?
' + (+
%&4
%1
"
1&$ )
"
&13&
A 3
! )"+ @"
&,, (
5 1 1
&$* ( ,, 2 & 3 4
5 & & $& 3 4
5 ) ''
*& ( &
5 $ (& & ) '$ + $ '&$ %2
# $
&1 1
$ * +" + !!
2 &$ & & &*&
/
5 ; & &*&
6)
&
5 6 '' $
+ $
) &)9
5 1 1
&$* ( ,, 2 & 3 4
5 & & $& 3 4
5 ) ''
*& ( &
5 $ (& & ) '$ + $ '&$ %2
# $
&1 1
%1
5
5
5
5
<
<
<
%2
"
&
%1
'&$
&.3& % &.1
* $) 1
'&$ $&
&$*
'&$
5? +
$
)
$
*
,
3& &
& &
"
?
* $*
%1
BC * $)
+? " BC * $)
? "+ "
0
'&$
7E $$ '&$ + $
$& ) *'$&(
/
&
(
'&$
?7
+ .>
)
$ %2
%1
$&
1 1
$ &
3=
1 1 &
&$)& , & ).% 3=
$%2 & '&$ '$& &1 ) *'
).%
, & ) (( & &( &$
' .% 9&$*
# $ %$ & ' (
+%* $ &( ( & &
%1
%1
&
)
%1
Figura 3.16: Risultato della stampa di un computo metrico, parte 3
CAPITOLO 3. CASO DI STUDIO
1"
)
GG G +" & *
- ) *'$&(
/
'&$
>
38
) *2%$& &
"$
&
1
%1
5 < $
5 < $ ( &
'$ &, & &( &$
&$
( ) &2
1" GG G +" & *
) *'$&(
/
' ( ) 2
)
'&$
>
"+
)
G +" "
! " !?! + F
1
%1
5 <
5 <
$
$
'$ &,
'$ &,
# $ %$ & ' (
+%* $ &( ( & &
%&4
& &( &$
& &$
'&$
?7
' ( ) 2
' ( ) 2
)
+ .>
)
)
$ %2
&
)
%1
34 & & '.
+
2
.
2.3 1 )
# $ %$ & ' (
'&$
*'
! + G + "+
) & 2 & % % ?* )
%2
%2 )
%.
%
40 0
?7 G + '&$ > (
, &
%
) ( %
?+ ?+ H + " +
& ( &' (
2 ) &
50&
4% & 1
2
1
.
.
2.3 1 )
1
.
?G +" " = 3
%.
40 0
#
? " $
'&$
) % %$
" +? "
!
"
! ? ('&(( $& **- &
*& $ &)&(( $ '&$ + $* , & & &
$&
( *&
>
$&((
&
$& & & >
- +
>
)) *&
& & % & ,& *&( )9& @ )
&+ $ &
)%) A) *'$&(
/
5 %2
5 %2
5 )) $
*&
*& $
6 **
*& $ 4
**
&$
& & $ *& )
1&
$ + $, - * &$
) (%*
#
? " $
'&$
) % %$
! ?
('&(( $& -: **- &
*& $
& & $&
( *&
* (%$ $& +
- ) *'$&(
/
& % -
50&
4% & 1
& & '. 6
%1
$&
%1
& % -
' '
? " $
'&$
?7 +"
* *
8
8 " - '&$ &$ , & ( *&
) *'$&( $ )) $ & * &$
*
' '
#
? " $
"
!! !
) *'$&( $ )) $
#
?7 +"
&$)& $&
*
F
.& %
" +? "
!
"
&)&(( $ '&$
+ $* , &
>
$&(( & $& & & >
5 %2
*& $ 4
**
5 )) $ &$
& & $ *& )
1&
*& $ + $, - * &$
) (%*
'&$
- '&$
& * &$
(
& & '. 6
%1
34 & & '.
+
F
.%&
"
(
$&
"
+% )9
! + $!
( *&
)%)
! +
-
%1
+! $$
& >
-
%1
34 & & '.
F
6
Figura 3.17: Risultato della stampa di un computo metrico, parte 4
CAPITOLO 3. CASO DI STUDIO
+
2
.
2.3 1 )
39
21
%.
# =% %&.
40 0
50&
4% & 1
& & '. 6
# $ %$ & ' (
'&$
?7 G +
$
" +
1
54 &I.1 @ ( * $&A- )
%
(
&- '&$ + $* , &
& & $&
$ )9& ).% )
& +$&
J + " + " $" G 8 "+ !
& ) *' & & /
54
5 < '%
> )) ).%
5 < '%
> )) ).%
5 < '%
> )) ).%
))
5 < '%
> )) ).%
5 < '%
> )) ).%
5 < $%2 &
$$&(
5 $ )) $ &$ - &$*
+ &
)
)
)
& +$&
& +$&
& +$&
B 1 2
B 2 &
B'
+$&
+$&
) ((
& * &$
%1
B C)
B 1 $ )&
) (%*
# $ %$ & ' (
'&$
?7 G +
$
" +
1
54 &I.1 @ ( * $&A- )
%
(
&- '&$ + $* , &
& & $&
$ )9& ).% )
& +$&
J + " + " $" G 8 "+ !
& ) *' & & /
54
5 < '%
> )) ).%
5 < '%
> )) ).%
5 < '%
> )) ).%
2
5 < '%
> )) ).%
5 < $%2 &
$$&(
5 $ )) $ &$ - &$*
+ &
# $ %$ & ' (
'&$
+ $* , & & & $&
$ +
+
2$
3
3
1
1
)
)
)
& +$&
& +$&
& +$&
+$&
) ((
& * &$
# $ %$ & ' (
'&$
+ $* , & & & $&
$ +
+
2$
'&$
"!!@
%1
&(
&
(
$&- &
&(
&
(
'&$
"!!@
)
$$&(
)
$$&(
$& +
& 2
+
& 2
).% )
& +$&
+ &
& * &$
%1
) ((&
&
)
) ((&
# $ %$ & ' (
'&$
?7 G +
$
" +
1
54 &I.1 @ ( * $&A- )
%
(
&- '&$ *
G +"
" " "
!@" !K? !
" * "
J+" +
"
! "
(
!?! + & ) *' & & /
5 < '%
> ))
5 $ )) $ &$ - &$*
%1
$&- &
# $ %$ & ' (
'&$
?7 G +
$
" +
1
54 &I.1 @ ( * $&A- )
%
(
&- '&$ *
G +"
" " "
!@" !K? !
"* "
$ 7?G +" 8"+" "
> &$
& > '' $ *&
& ) *' & & /
5 %2 +$&
E : ' $ $&
( $ 2%, & $%2 &
5 %2 )
E : ' $ $&
( $ 2%, & $%2 &
54
) (%*
?7 G +
) $& $
$! !
$ ,,
8+
() $ ) D ! - ) ( %
/
5 < '%
() $ ) 1 2
5 < '%
() $ ) 2 &
5 < '%
() $ ) 1 ()
2
5 )%$1&- 2$ 9& & $ )) $ ('&)
* &$
) (%*
54
B C)
?7 G +
) $& $
$! !
$ ,,
8+
() $ ) D ! - ) ( %
/
5 < '%
() $ ) 1 2
5 < '%
() $ ) 2 &
5 < '%
() $ ) '
))
5 < '%
() $ ) 1 $ )&
5 )%$1&- 2$ 9& & $ )) $ ('&)
* &$
) (%*
%1
B 1 2
B2 &
B 1 ()
%1
B 1&
) (%*
:
Figura 3.18: Risultato della stampa di un computo metrico, parte 5
CAPITOLO 3. CASO DI STUDIO
3
1 (
# $ %$ & ' (
'&$
?7 G + + 0 0.0
+ $* , & & & $&
$! ! $ ,,
)
*
& () $ ) - ) ( %
/
5 < '%
() $ ) 1&
5 )%$1&- 2$ 9& & $ )) $ ('&)
* &$
) (%*
# $ %$ & ' (
1 $& %( )9 - &
'&$
'
&(
7 "
+ *
!
&
# $ %$ & ' (
$" " A
2?
"+ ) *' &
))
'&$
$
1 $& %( )9
%
/
) $& $
'&$
" !?! + +
%1
(
$&- &
GG = + $" " A
"+ ) *' &
%
5 * ()& $& * ) *
* $) #$
) () $ ) ( &$&
5(+ &
& )$ *
7 7 ) $ (&
51
+ ((
' 1 *&
))
40
* &
) '$ + $
L +8 "$"
2 ) - &
/
(&$ &
%1
*%$
!
' )
GG = +
$! !
%1
5 ) ((&
() $ )
''
)&$ * )
5 2 &$
$ &*' *&
% * )
5 (& &
2 )
' '&( &
51
+ ((
' 1 *&
# $
A
/
))
%$ & ' (
'&$
1 $& %( )9 - &
!
!
5 * ()& $& * ) *
* $) #$
(&$ & ) () $ ) ( &$&
5(+ &
& )$ *
7 7 ) $ (&
*%$
5)
( (&
' 1 *&
51
+ ((
' $& &
* &
# $ %$ & ' (
7 +!
! 0
7
'
+ *
'&$
$!
9 ( ) *' &
/
5 * ()& $& * ) *
(&$ &
) ((
5 ( ++ & + (( ( ()&
5' &
() $ ) ( +
))
! 0
9
7 8+
%1
+ !!
$
* &
!!
-
* $) #$
$" "
%
) '$ + $
)) ( 5 * ()& $& * ) *
* $) #$
(&$ &
&( &$
5 ( ++ & )
%2 + &(( 2 &
: )*
5' &
() $ ) ( &$&
# $ %$ & ' (
'&$
1"+
+ $& ) F 2 )
GG = +
" " ) *' &
!
GG = +
) *' &
/
%1
$" "
* &
%1
34 & & '.
.1& #
2
.1&
.
2.3 1 )
1"
G +" & ) (&
) ** & & &
))
&$& !" * ! G +" ! +*
%.
)
40 0
$
%++ )
'$&' (
H & >&(&)%, & 1 $
F
%
50&
4% & 1
& & '. 6
%1
34 & & '.
F
;
Figura 3.19: Risultato della stampa di un computo metrico, parte 6
CAPITOLO 3. CASO DI STUDIO
! *'$&( *
'&$
'&$ ('&) ,,
+ $* , & & & '&$& ( '$ &()$ &
%&
2 13
%%. #4
(
1
$
,
&
% - '&$ >&(&)%, & $&
* ,, - )
&$& & $
$
> $ & & & (% & & '&$& $ (' $
& & $ * & ,&
1 $ % *
.%&
%& %& 3
%. = 3
.& %
F
# =% %&.
F
I
F
1
.
%2 )
1
,
F
%
.%&
F
%&
.1& #
F
)
% 2
%# 1
& J
F
& & '.
.3 '43
F
" ""
* &$
F
224)
21
%
F
1.
%&
%&
'2
) *
% 9
41
" K? + J
+ + "$ "$$
F
%
"+ " !
=
8 "+ $
< !! +
"
O +G
! + $$"8+ ! !
< O "
+"+G
! +$"8+ "8
+
<( O "
+"+G
! +$"8+ "
"
< * +"
F
"
!
?
" $ +
"
$
"
" "$ + " "
? ! + $$"8+
*
* "
" J
"+? !
? 0
.%&
++ "$"8? ! + $"8?"+ " "8
H
" $
"0
8 "GG !
?
0
" "*+ ? " !
F"
F$ +
F* ? "" !F!
" J
+ " " ! + "$"+G " !
"+ "F K?"$
! !
" $
"F
$$
?+ $"
+
'"
"$
"!!
$
"8+
" 7 GG G +"
$!
M NNNNNNNNNNNNNNNNNN
!
"+ "
NNNNNNNNNNNNNNN
'J"$"!?
+"
"
+
Figura 3.20: Risultato della stampa di un computo metrico, parte 7
)) $$&
Capitolo 4
L’ambiente di sviluppo
Una volta terminata la fase di progettazione ha avuto inizio quella relativa all’implementazione. In questo capitolo verranno trattate le varie tecnologie scelte e i relativi
strumenti software utilizzati per la stesura del codice sorgente, durante il periodo di
tirocinio, dell’applicazione gestionale.
4.1
Il sistema operativo
Una delle numerose attività svolte è
stata quella di scegliere una distribuzione Linux, da installare e customizzare ad
hoc su di una macchina, dove avrebbe girato il programma gestionale. Tale scelta
è ricaduta sulla distro1 Ubuntu Linux.
Ubuntu è un sistema operativo GNU
Linux nato nel 2004, basato su Debian2 ,
che si focalizza sull’utente e sulla facilità d’uso. Ubuntu è orientato all’utilizzo de1
2
Abbreviazione di “distribuzione”.
È un’altra distribuzione GNU/Linux.
43
CAPITOLO 4. L’AMBIENTE DI SVILUPPO
44
sktop, pone una grande attenzione al supporto hardware, e non necessita di costi di
licenza. (1)
4.2
MySQL
Un database3 è una collezione di dati
gestita da un DBMS. DBMS è l’acronimo di Data Base Management System4 ,
ovvero un sistema software in grado di
gestire collezioni di dati che siano grandi, condivise e persistenti assicurando la
loro affidabilità, coerenza e privatezza. Nell’uso comune con il termine Database, si
è soliti indicare una pluralità di concetti, ad esempio si indica indifferentemente: un
elenco organizzato di dati su un foglio di calcolo, un software applicativo che contiene
i dati operativi per la gestione di un Azienda o un DBMS come Oracle o DB2.
MySQL un RDBMS (Relational Data Base Management System) ovvero un Sistema per la Gestione di Basi Dati Relazionali. Tale tipologia di DBMS si basa sul
modello relazionale che pone le sue basi su due concetti fondamentali: Relazione e
Tabella. Tale modello domina la scena da molti anni, esistono però altre tipologie di
dbms poco utilizzate ad esempio: a oggetti (OODBMS), gerarchici (alberi) e reticolari
(grafi).
David Axmark e Micheal “Monty” Widenius, iniziarono a scrivere il codice di
MySQL quando erano adolescenti con lo scopo di fare soldi ma non avevano idea di
ciò che avrebbero creato. Nel 1995 MySQL divenne Open Source e nel 1996 venne
distribuito per la prima volta riscuotendo un forte interesse.
Nel giro di pochi mesi centinaia di persone si iscrissero alla mailing list e migliaia
furono i download. Fu un ottimo inizio per due giovani e ambiziosi sviluppatori ma
ciò non significava ottenere risultati di grande successo.
3
4
in italiano Base di dati.
in italiano Sistema di gestione di basi di dati.
CAPITOLO 4. L’AMBIENTE DI SVILUPPO
45
La realtà di oggi è che circa il 66% delle aziende del mondo utilizzano o intendono
utilizzare MySQL nelle loro applicazioni e alcuni dei siti più popolari sul web, tra cui
Google, Wikipedia, Facebook, Yahoo, eBay etc. . .
Una delle motivazioni più forti alla base del successo di MySQL coincide con
una delle sue caratteristiche principali, lo stesso Axmark svelò in una sessione “Tech
Days di Sun Microsystems” nel febbraio del 2008 che già nel 1996 si era cercato di
fare un pacchetto che consentisse compilazione e installazione in 15 minuti, l’idea di
base doveva essere quella che chi voleva provare MySQL doveva poterlo fare in pochi
minuti, e si sarebbe affezionato a MySQL per 10 anni.
Un altro punto di forza di MySQL, rivelato al medesimo evento da Axmark, fu la
scelta vincente dell’ottimizzare MySQL per il web. Tale scelta ha portato MySQL a
dominare il mercato dei database per il web grazie al fatto che il tempo di connessione
è più basso rispetto agli altri database tradizionali, infatti un applicazione web necessita di connettersi ad un database molto più spesso di un applicazione tradizionale.
A seguire vengono solamente elencate alcune delle caratteristiche fondamentali di
MySQL:
• un RDBMS basato su architettura Client/Server
• supporto di: SubSELECT, Viste, Stored Procedure, Trigger, Eventi, UDF, Unicode, Replicazione, Ricerche full-text, Transazioni, Clustering, Funzioni
• architettura a plugin, che permette di implementare una nuova libreria per lo
storage dei dati, un nuovo parser Fulltext o funzionalità aggiuntive
• è indipendente dalla piattaforma e supporta un gran numero di sistemi e architetture hardware
• supporta API per moltissimi linguaggi di programmazione. Per citarne i più usati
C/C++, Java, Perl, PHP, Pythom, Ruby, Tcl; inoltre supporta lo standard ODBC.
CAPITOLO 4. L’AMBIENTE DI SVILUPPO
46
La grande Community degli utenti costituisce realmente l’arma in più di MySQL,
sulla stregua del sistema operativo Linux, i creatori di MySQL sono riusciti a costruire
una folta comunità iternazione che contribuisce a favorire la diffusione di MySQL, a
scoprire, risolvere e a migliorarlo.
MySQL AB è il nome dell’azienda fondata da David Axmark e Monty Widenius che deteneva lo sviluppo di MySQL fino a Gennaio 2008 quando con una maxi acquisizione da un miliardo di dollari Sun Microsystem ne acquisisce la proprietà (http://www.mysql.com/news-and-events/sun-to-acquire-mysql.html). Nell’Aprile
del 2009 Oracle con un acquisizione di quasi 8 miliardi di dollari acquisisce SUN
Microsystem, e di conseguenza MySQL.
Oggi MySQL è il database open source più famoso del mondo, con oltre 11 milioni
di installazioni attive (dato 2007) e sessantamila download giornalieri. Molte delle
organizzazioni mondiali più grandi e in rapida crescita hanno scelto MySQL per ridurre
i tempi e i costi della realizzazione di siti web, sistemi business-critical e software
pacchettizzato. (3)
4.3
MySQL Workbench
MySQL Workbench è uno strumento di progettazione
e modellazione di database visuale, fornito da Sun. Grazie a questo tool, gli sviluppatori e i DBA possono creare
nuovi modelli di dati fisici per i database MySQL e modificare quelli esistenti, utilizzando le funzionalità di Reverse/Forward Engineering e di gestione delle modifiche.
MySQL Workbench è stato progettato per aumentare la
produttività dell’utente e riuscire a concettualizzare, co-
municare, generare e gestire i metadati principali dell’azienda, nonché i database ad
CAPITOLO 4. L’AMBIENTE DI SVILUPPO
47
Figura 4.1: Interfaccia visuale di MySQL Workbench
elevate prestazioni e i datawarehouse.
L’applicazione aiuta gli sviluppatori e i DBA a creare visivamente i progetti di database fisici che si trasformeranno poi in database MySQL (Figura4.1). I modelli sono
di gran lunga il mezzo migliore e più efficiente per comprendere e creare un database valido e ben funzionante. MySQL Workbench consente agli utenti di accelerare il
lavoro utilizzando una serie di funzioni e utility, permette infatti di creare uno o più
modelli nell’interfaccia e fornisce varie viste degli oggetti in corso di progettazione
(relazioni tra tabelle (chiavi esterne), viste, trigger, stored procedure, funzioni, autorizzazioni per gli oggetti).
La funzionalità Forward Engineering di un progetto di database fisico è tra le
più utilizzate negli strumenti di modellazione (Figura4.3). Lo strumento può generare
CAPITOLO 4. L’AMBIENTE DI SVILUPPO
48
il codice SQL necessario per creare un database fisico su un server target. MySQL
Workbench offre questo tipo di utilità, che consente di tradurre un modello di dati visuale rapidamente e semplicemente in un database fisico su un server MySQL target,
con il vantaggio che il codice SQL funziona correttamente fin da subito, senza dover
più ricorrere al tradizionale processo laborioso che prevede la trascrizione manuale del
complesso codice SQL.
MySQL Workbench offre anche un’utility di Reverse Engineering (Figura4.3) che crea un
collegamento con qualsiasi server MySQL esistente, generando un nuovo modello di dati dell’intero sistema MySQL sorgente (o di parte di esso). Una volta
all’interno dello strumento, tutti
gli oggetti e le relative relazioni
Figura 4.2: Il Forward Engineering
possono essere visualizzati, aggiunti e modificati con semplicità.
L’utility Synchronization (Figura4.4) mette a confronto un modello di dati e il server MySQL di destinazione, quindi lancia una sincronizzazione tra i due. Utilizzando
MySQL Workbench, un DBA o uno sviluppatore prima si collega a un server MySQL,
poi lo strumento confronta tutti gli aspetti del modello attualmente utilizzato con il
database fisico MySQL. L’utility Synchronization offre una visualizzazione grafica di
tutte le differenze rilevate e lascia allo sviluppatore o al DBA la decisione su come procedere. È possibile scegliere fra tre opzioni per ciascuna delle differenze individuate
tra un modello e un database fisico:
• ignorare le differenze
CAPITOLO 4. L’AMBIENTE DI SVILUPPO
49
Figura 4.3: Il Reverse Engineering
• sincronizzare il modello con il server del database fisico
• sincronizzare il server del database fisico con il modello
consente perciò all’utente di procedere su base generale o su singolo oggetto, lasciando
al DBA libera scelta. Dopo aver completato la sincronizzazione, il DBA può salvare il
modello di MySQL Workbench e conservare le versioni del modello e del database in
quel determinato momento.(7)
CAPITOLO 4. L’AMBIENTE DI SVILUPPO
50
Figura 4.4: La funzione di sincronizzazione di MySQL Workbench
4.4
Java
Per quanto concerne il linguaggio di programmazione è stato scelto Java. Esso appunto è un linguaggio di
programmazione orientato agli oggetti, creato da James
Gosling e altri ingegneri di Sun Microsystems a partire da
ricerche effettuate alla Stanford University agli inizi degli
anni Novanta. Nel 1992 nasce il linguaggio Oak (in italiano quercia), prodotto da Sun Microsystems e realizzato
da un gruppo di esperti sviluppatori capitanati da James
Gosling. Tale nome fu successivamente cambiato in Java a causa di un problema di
copyright (il linguaggio di programmazione Oak esisteva già). La sintassi di base del
CAPITOLO 4. L’AMBIENTE DI SVILUPPO
51
linguaggio (strutture di controllo, operatori e così via) è stata mantenuta pressoché
identica a quella del C++; tuttavia, non sono state introdotte caratteristiche ritenute fonti di una complessità non necessaria a livello di linguaggio e che favoriscono
l’introduzione di determinati bug durante la programmazione, come l’aritmetica dei
puntatori, l’ereditarietà multipla delle classi, e l’istruzione goto. Per le caratteristiche
object-oriented del linguaggio ci si è ispirati al C++ e soprattutto all’Objective C. (1)
Figura 4.5: Il linguaggio Java
I motivi dunque che hanno portato a scegliere questo linguaggio di programmazione per l’implementazione dell’applicazione gestionale, sono stati dettati dal fatto che
il Java soddisfa le seguenti caratteristiche:
• è semplice con alte prestazioni
• è sicuro e portabile
• è orientato agli oggetti
• è robusto e dinamico
• supporta il multithread
• è indipendente dall’architettura.
CAPITOLO 4. L’AMBIENTE DI SVILUPPO
4.5
52
Eclipse e Netbeans
Eclipse è un ambiente di sviluppo integrato multi-linguaggio e multi-piattaforma.
Ideato da un consorzio di grandi società quali Ericsson, HP, IBM, Intel, MontaVista
Software, QNX, SAP e Serena Software, chiamato Eclipse Foundation, viene sviluppato da una comunità strutturata sullo stile dell’open source. (1)
Eclipse è stato utilizzato per la scrittura del codice di tutte quelle classi che lavorano
a livello background (Figura4.6).
Figura 4.6: IDE di sviluppo Eclipse
NetBeans è un ambiente di sviluppo multi-linguaggio scritto interamente in Java
nato nel giugno 2000, scelto dalla Oracle Corporation come IDE ufficiale. (1)
Questo IDE è stato utilizzato per la creazione della GUI5 (Graphical User Interface)
e di tutte quelle classi che si interfacciano con l’utente (Figura4.7). Prima di poter effettuare la connessione con il database da parte di Netbeans, è stato necessario inserire il
5
Elementi grafici che compongono le finestre.
CAPITOLO 4. L’AMBIENTE DI SVILUPPO
53
driver jdbc mysql-connector-java-*-bin.jar6 all’interno del “path” dell’applicazione.
Figura 4.7: IDE di sviluppo Netbeans
6
L’asterisco
indica
la
versione
del
driver,
http://www.mysql.it/downloads/connector, previa registrazione.
scaricabile
dall’indirizzo
Capitolo 5
Conclusioni e sviluppi futuri
Il lavoro di stage unito a quello di tesi, mi ha permesso di conoscere tutti quegli aspetti, legati al mondo aziendale, relazionati all’attività di progettazione, marcando quelle capacità di problem solving, di cui un ingegnere non può fare a meno per
svolgere al meglio la propria professione.
L’applicazione realizzata, in definitiva, rispecchia le specifiche richieste, soprattutto per l’organizzazione dei contenuti e la procedura delle operazioni di compilazione
delle singole “voci di computo”, della finestra listino vendite, che hanno notevolmente
semplificato l’elaborazione del documento, apportando un sostanziale miglioramento
in termini di tempo.
Il software può comunque essere migliorato aggiungendone funzionalità. Una futura implementazione potrebbe essere un gestore di layout per la stampa, che personalizzi il documento prodotto a seconda se l’appalto di gara, a cui l’azienda partecipa, sia
pubblico o privato.
55
Ringraziamenti
Si ringrazia il prof. Dragoni per la sua disponibilità e per avermi dato l’opportunità
di svolgere un tirocinio esterno.
Un grazie all’azienda Monte impianti, che mi ha incentivato e sostenuto nei tre
mesi di tirocinio, senza di essa non avrei potuto scrivere questa tesi.
Un grazie agli amici della vita d’infanzia, nonché di quella Sannicandrese, in particolare, Enrico, Jacopo, Silvio, Michele ù general, Dino, con cui ho condiviso, fantastiche partite di Poker durante le feste Natalizie e, anche se per pochi giorni, Estati
indimenticabili, all’insegna delle partite a beach volley e della spensieratezza.
A Marco amico fedele, come dimenticare le battute di pesca che ci hanno costretto
a settare la sveglia alle 4.00 del mattino, per arrivare al mare con lo scooter con indosso
pigiama, pantaloni, maglione e giubbotto, per difenderci dal pungente freddo invernale.
Ai miei fantastici genitori che, con tantissimi sacrifici, anche nei periodi più brutti,
hanno “sponsorizzato” il mio non breve periodo di studi, non facendomi mancare mai
niente, ma soprattutto hanno saputo credere in me. GRAZIE.
57
Bibliografia
[1] Enciclopedia libera online, http://www.wikipedia.it.
[2] Informatica gestionale, http://www.informaticagestionale.it.
[3] Mysql italia, http://www.mysqlitalia.it.
[4] M. Agliata. La direzione dei lavori. Ambiente territorio edilizia urbanistica.
Maggioli Editore, 2009.
[5] G. Bracchi e G. Motta. Sistemi informativi e imprese. Collana di Informatica.
Franco Angeli, 1992.
[6] Q.D. Inghirami.
I sistemi informativi gestionali.
Economia - Monografie.
FrancoAngeli, 2005.
[7] Oracle. White paper: Data Modeling using MySQL Workbench 5.2, 2011.
[8] P.D. Patrone e V. Piras.
Contract e project management. Strumenti di
programmazione e controlli di commessa edilizia. Alinea, 2007.
59