Progetto e realizzazione di un software in ambiente Web per l’integrazione di applicazioni basato...

UNIVERSITA’ DEGLI STUDI DI TRIESTE

FACOLTA’ DI INGEGNERIA

Corso di Laurea Specialistica in Ingegneria Informatica

Tesi di Laurea

Progetto e realizzazione di un software in ambiente Web

per l’integrazione di applicazioni basato su WCF

Laureando Relatore

Ledion Spaho Chiar.mo Prof. Maurizio Fermeglia

Anno Accademico 2009-2010

Si può discutere per cercare di capire se l'informatica sia più arte o scienza, ma è innegabile che nell'informatica il concetto di bellezza esiste a tutti i livelli: dagli algoritmi e strutture dati al codice sorgente, alle interfacce grafiche, ai singoli software stessi quando hanno quell'equilibrio tra funzionalità e intuitività.

Salvatore ‘antirez’ Sanfilippo

3

Indice

Indice delle figure .................................................................................................................................. 4

Introduzione ............................................................................................................................................ 5

Capitolo 1 - Architetture d’Integrazione ................................................................................................. 7

1.1 Introduzione .................................................................................................................................. 7

1.2 Strategie d’integrazione ................................................................................................................ 9

1.3 SOA e l’integrazione .................................................................................................................... 14

1.4 Conclusioni .................................................................................................................................. 15

Capitolo 2 – Analisi di requisiti .............................................................................................................. 17

2.1 I requisiti ..................................................................................................................................... 17

2.2 I casi d’uso ................................................................................................................................... 18

Capitolo 3 - Progettazione .................................................................................................................... 21

3.1 Database: integrazione e modifiche ........................................................................................... 21

3.2 L’applicazione .............................................................................................................................. 25

3.3 Presentazione.............................................................................................................................. 32

3.4 Scelte progettuali ........................................................................................................................ 33

Capitolo 4 – Realizzazione ..................................................................................................................... 37

4.1 Rich Internet Applications, un primo tentativo .......................................................................... 37

4.2 Persistenza di dati ....................................................................................................................... 40

4.3 Logica funzionale......................................................................................................................... 43

4.4 Interfaccia Utente (UI) ................................................................................................................ 49

Conclusioni ............................................................................................................................................ 68

Appendice 1 - Come aggiungere un’altra funzionalità ......................................................................... 70

Ringraziamenti ...................................................................................................................................... 75

Bibliografia ............................................................................................................................................ 76

Indice delle figure

Figura 1: PI, EAI e EII ------------------------------------------------------------------------------------------------------- 10

Figura 2: Portal Integration ---------------------------------------------------------------------------------------------- 10

Figura 3: Enterprise Application Integration, P2P e Middleware-based -------------------------------------- 12

Figura 4: Enterprise Information Integration ------------------------------------------------------------------------ 13

Figura 5: Figura 5: PI, EAI, EII e SOI ------------------------------------------------------------------------------------- 15

Figura 6: I casi d'uso del sistema ---------------------------------------------------------------------------------------- 20

Figura 7: Le tabelle in comune dalla fusione dei database ------------------------------------------------------- 21

Figura 8: Lo schema fisico finale del database ---------------------------------------------------------------------- 22

Figura 9: L’architettura tipica di un’ applicazione Web ----------------------------------------------------------- 25

Figura 10: La soluzione tecnica del sistema -------------------------------------------------------------------------- 30

Figura 11: Un’applicazione Web non distribuita -------------------------------------------------------------------- 31

Figura 12: Un’applicazione Web distribuita -------------------------------------------------------------------------- 31

Figura 13: RIA secondo Macromedia ---------------------------------------------------------------------------------- 38

Figura 14: La versione RIA del progetto ------------------------------------------------------------------------------- 39

Figura 15: Domain Services, un pattern scalabile ------------------------------------------------------------------ 46

Figura 16: La sequenza degli eventi durante l'autenticazione con Form ------------------------------------- 48

Figura 17: Lo schema a blocchi dell'operazione di un nuovo ordine------------------------------------------- 49

Figura 18: La struttura di un'applicazione AJAX-enabled --------------------------------------------------------- 58

Figura 19: Home Page ----------------------------------------------------------------------------------------------------- 59

Figura 20: Elenco delle sostanze chimiche con le relative frasi di R/S ----------------------------------------- 60

Figura 21: Un esempio di una pagina con i dettagli concernenti una particolare frase di rischio ------ 60

Figura 22: La pagina del prelievo di un reagente ------------------------------------------------------------------- 61

Figura 23: La pagina della restituzione di un reagente ------------------------------------------------------------ 62

Figura 24: Nuovo ordine, primo passo -------------------------------------------------------------------------------- 63

Figura 25: Nuovo ordine, secondo passo ----------------------------------------------------------------------------- 63

Figura 26: Nuovo ordine, terzo passo --------------------------------------------------------------------------------- 64

Figura 27: Nuovo ordine, quarto passo ------------------------------------------------------------------------------- 65

Figura 28: Nuovo ordine, quinto e l'ultimo passo ------------------------------------------------------------------ 65

Figura 29: Archivio degli ordini ------------------------------------------------------------------------------------------ 66

Figura 30: Lo spazio dedicato all'amministratore del sistema. -------------------------------------------------- 67

5

Introduzione

a storia dell'informatica insegna che lo sviluppo dei sistemi informativi non

avviene in maniera continua ed organica: molto più spesso l'avvento di nuove

tecnologie e le necessità legate al business producono ciclicamente l'esigenza

di creare nuovo software. Ogni volta che questo accade ci si trova di fronte al problema di

evolvere il sistema evitando però di perdere gli investimenti che sono già stati effettuati (le

applicazioni già presenti). Nell'evoluzione dei sistemi, nasce quindi in maniera naturale la

necessità di effettuare attività di "integrazione".

“Integrare applicazioni software in ambito enterprise” è un'attività all'ordine del

giorno, che presenta in certi casi sfide di notevole complessità. Lo scopo principale di queste

attività è ottenere uno scambio di informazioni tra sistemi informativi eterogenei ed

autonomi, con l'obiettivo di sviluppare le attività aziendali e mantenere certe risorse e

applicazioni già presenti in azienda.

Il motivo della presente tesi sta proprio nell’integrazione di software e componenti

già in uso sviluppati ad - hoc che soddisfano in questo momento la maggior parte delle

necessità e le esigenze del dipartimento universitario DICAMP. Con il passare del tempo la

situazione esistente risultava non solo ingestibile in termini di manutenzione e inefficiente

perché ogni programma dispone il suo database, quindi una ridondanza elevata, ma anche

poco user-friendly giacché l’interfaccia utente e la logica di funzionamento di ogni

applicazione è diversa dalle altre.

Quindi è ritenuto opportuno la necessità di unificare il lavoro svolto dagli altri

studenti, sia la parte che riguarda i dati che quella della logica applicativa e l’interfaccia

utente. L’obiettivo di questa seconda fase è quello di “tradurre” tali applicativi in .NET

ovvero rendergli, se vogliamo, più ‘standard’ e facilmente modificabili, migliorabili e

scalabili, nonché permettere all’applicativo finale di comunicare più facilmente con gli altri

software presenti e futuri. Così facendo si arriva in una soluzione robusta: un progetto di

unificazione. Tale soluzione deve :

ricoprire gli obiettivi del dipartimento

avere un unica fonte di dati

avere un’unica interfaccia utente (rendendo user-friendly)

essere distribuita in maniera tale di agevolare il collaudo e la manutenzione

essere facilmente estendibile

Il risultato finale del lavoro sarà un sistema informativo basato su web che integra tutti i processi di business rilevanti (quale gestione degli ordini, del magazzino, ecc) e le altre necessità informatiche del dipartimento.

L

E’ stato scelto di sviluppare l’applicativo usando il framework .NET per il semplice motivo che il server web del dipartimento (IIS) non è in grado di eseguire elaborazioni server-side oltre a quelle fornite dalla casa produttrice. Viene precisato inoltre che tutti i moduli software descritti in questo documento sono stati sviluppati dall'autore, ad eccezione del modulo che compie un nuovo ordine, il quale è stato reingegnerizzato parzialmente e riutilizzato.

La tesi contiene i seguenti capitoli:

Capitolo 1 – “Architetture d’Integrazione”, si presenterà una classificazione delle

strategie architetturali che è possibile utilizzare per l'integrazione. Infine vengono

presentati i concetti delle architetture service-oriented (SOA), un paradigma

architetturale più indicato per lo sviluppo di sistemi informativi complessi adattabili a

tutte le problematiche d’integrazione (sia interna che esterna).

Capitolo 2 – “Analisi di requisiti”, lo scopo generale di questo analisi è stabilire ‘che

cosa’ il sistema in questione deve fare fornendo le linee guida sulle funzionalità e le

operazioni che il sistema finale dovrà essere in grado di svolgere.

Capitolo 3 – “Progettazione”, in questa successiva fase vengono riportate le decisioni

sul ‘come’ tali requisiti saranno soddisfatti, entrando nel merito della struttura che

dovrà essere data al sistema software. Infine è stata affrontata la descrizione delle

scelte progettuali, in particolar modo mettendo in risalto le tecnologie software

scelte per l’implementazione del sistema.

Capitolo 4 – “Realizzazione”, corrisponde alla traduzione in uno o più linguaggi di

programmazione delle decisioni prese in sede di progettazione per essere

implementate concretamente attraverso la creazione dei moduli funzionali e la loro

progressiva integrazione. Essendo un’applicazione 3-tier, si è concentrato

principalmente sulla persistenza dei dati (Data Tier), sulla logica funzionale

(Business/Logic Tier) e sull’interfaccia utente (Presentation Tier).

Conclusioni, in questa parte si farà un riassunto per capire se gli obiettivi prefissati

sono stati raggiunti e i requisiti che erano stati individuati sono stati soddisfatti.

Inoltre si elencheranno eventuali sviluppi futuri per migliorare le prestazioni e altri

ambiti desiderati.

Appendice 1 – Come aggiungere un’altra funzionalità, consiste in un mini-manuale

coi passi da seguire nel caso che si vuole estendere il sistema sviluppando un’altro

modulo che svolge una certa funzionalità desiderata.

7

Capitolo 1 - Architetture d’Integrazione

’azienda dispone di tante applicazioni più o meno obsolete, è ora di

rimodernare, recuperando e riutilizzando ciò che non è conveniente riscrivere

e riscrivendo ciò che va ormai dismesso. Perché dismettere qualcosa che

funziona anche se obsoleto? Forse perché occorre la possibilità di estendere e migliorare il

preesistente, forse perché è necessario offrire i propri servizi sul Web, forse perché

l'integrazione di oggi getta le basi per affrontare le sfide di domani.

Stiamo parlando dell’ Enterprise Integration. Giga Group, in un report di qualche

tempo fa, la definiva "…..la sfida di reperire strumenti e tecnologie tali da offrire la più

semplice transizione possibile verso il web nel breve termine, e al tempo stesso un cammino

di migrazione verso architetture a componenti nel lungo termine". Si tratta in effetti di fare i

conti con un assetto IT in molti casi un tantino superato ma pienamente funzionante in

esercizio, con l'esigenza di affacciarsi sul web per conoscere e farsi conoscere, magari per

offrire anche i propri servizi applicativi, cercando di essere competitivi, di non dilapidare il

proprio budget, di "arrivare" presto sul mercato, di offrire valore aggiunto, di porre le basi

per una ristrutturazione che funzioni oggi ma che resti valida anche per il domani.

Questo è proprio l'argomento del presente capitolo, in cui si cercherà di fare il punto

su queste problematiche, di porsi delle domande e di cercare una chiave di lettura e di

analisi per possibili risposte.

1.1 Introduzione

L'integrazione è un problema assai complesso. Coinvolge aspetti economici,

tecnologici, culturali ed organizzativi. L'aspetto economico è evidenziato dal fatto che

un'organizzazione ha la necessità di evolversi e, allo stesso tempo, conservare i propri asseti

aziendali. Un'organizzazione matura con un sistema informativo complesso sa che il

cambiamento è inevitabile. E’ quindi il suo compito gestirlo in modo da minimizzare

l'impatto economico. L'ambito del Business è in continuo e rapido cambiamento; la

competizione è sempre più accesa. Le regole e gli standard impongono alle aziende una

sempre maggiore reattività.

Oltre queste sollecitazioni "esterne", ci sono quelle interne, che possono essere di

varia natura. Lo stimolo può venire dalla necessità del raggiungimento di obiettivi legati ai

processi aziendali, come ad esempio la “velocizzazione” della produzione o della consegna, il

miglioramento della qualità riducendo gli errori o i colli di bottiglia, l'aumento della

flessibilità dei processi aziendali, la possibilità di implementare nuove soluzioni di business

L

in modo più veloce ed economico per consentire una sempre più facile modifica dei processi

aziendali.

Infine può essere l'area IT che si trova a dovere affrontare questi problemi: può

nascere la necessità di integrare applicazioni esistenti ed infrastrutture IT corporate (a

seguito ad esempio di fusioni, acquisizioni, out-sourcing, ...) preservando ed ottimizzando

sempre più gli investimenti; in questi interventi si affrontano molte questioni complesse.

Alcuni esempi sono: eliminare la ridondanza di funzioni e/o dati, ridurre la complessità dei

sistemi, riutilizzare le applicazioni esistenti, mantenere il controllo di efficienza e il governo

della struttura integrata per le attuali e future applicazioni aziendali e adottare un approccio

il più possibile modulare per ridurre anche i rischi d’installazione e aggiornamento di nuove

applicazioni.

Si hanno quindi obiettivi, visioni e interessi diversi che si devono riconciliare e che

nascono dal fatto che le aziende necessitano di un continuo adattamento per sopravvivere e

rimanere profittevoli: l'obiettivo è di rispondere sempre più velocemente alle mutevoli

sollecitazioni esterne ed interne.

Le domande comuni che un'organizzazione con obiettivi di questo tipo si pone sono:

Come evolvo il mio sistema informativo in modo da avere un costo il più basso

possibile?

Come devo progettare e sviluppare un sistema oggi in modo che il costo

dell'integrazione sia basso domani?

Come posso raggiungere gli obiettivi di business prefissati nel modo più “economico”

e più flessibile possibile?

Esiste anche un ulteriore raffinamento del problema: con lo sviluppo della rete è

diventato concreto il problema dell'integrazione a livello business, cioè la creazione di

processi B2B1 ottenuti componendo funzionalità che sono esposte da organizzazioni

differenti. Possiamo quindi parlare di integrazione “interna” (normalmente legata ad una

estensione dei sistemi con nuove o vecchie tecnologie) e integrazione “esterna”. Per

rispondere correttamente a queste domande occorre affrontare innanzitutto il problema dal

punto di vista architetturale piuttosto che tecnologico.

1 B2B o Business-to-Business indica le relazioni che un'impresa detiene con i propri fornitori per attività di

approvvigionamento, di pianificazione e monitoraggio della produzione, o di sussidio nelle attività di sviluppo del prodotto, oppure le relazioni che l'impresa detiene con clienti professionali, cioè altre imprese, collocate in punti diversi della filiera produttiva.

9

1.2 Strategie d’integrazione

Si potrebbe classificare le strategie d’integrazione sulla base del livello architetturale

su cui agiscono. Si suppone di avere un sistema informativo a strati che sia suddivisibile in:

Data layer

Business Layer

Presentation Layer

Le strategie d’integrazione che saranno considerate sono classificabili , in prima istanza,

con il layer su cui vanno ad agire. Si può quindi pensare di integrare a livello di

presentazione, a livello di logica applicativa oppure a livello di dati. La scelta del livello su cui

si effettua integrazione è dettata da molti fattori.

La prima classificazione sulle strategie di integrazione è:

1. Portal Integration (PI)

2. Enterprise Information Integration (EII)

3. Enterprise Application Integration (EAI)

Questi tre possibili approcci architetturali sono volti ad aggiungere alle tradizionali

applicazioni "verticali", caratterizzate da scarsa integrazione reciproca e dalla presenza di

information silos2 isolati, una dimensione di integrazione orizzontale che è in grado di

portare ad ulteriori vantaggi di business mediante una maggiore efficienza generale dei

processi aziendali ed inter-aziendali. In seguito saranno spiegate brevemente queste

strategie evidenziando per ognuno i pregi e i difetti.

2 I silos di informazioni sono la metafora per rappresentare il modo con il quale vengono raccolte e accumulate

le informazioni contenute in specifiche basi di dati tra loro incompatibili. Costituiscono una delle principali limitazioni alla possibilità di accedere in maniera trasversale alle informazioni di singoli oggetti o soggetti archiviate sotto profili differenti in silos differenti. (fonte: www.ilsole24ore.com)

Figura 1: PI, EAI e EII

1.2.1 Portal Integration

La Portal Integration avviene a livello d’interfaccia utente. Questo tipo di strategia è

molto comune dato che è semplice da implementare, non è invasivo nei confronti delle

applicazioni integrate e permette di effettuare in maniera semplice e rapida l'aggregazione

di sistemi molto eterogenei tra loro.

Quello che viene realizzato è un “accorpamento” di diverse applicazioni su

un'interfaccia comune. Un componente aggrega le diverse applicazioni che sono

responsabili di esporre la propria interfaccia in un modo che sia componibile dal portale. Il

portale mostra quindi un'interfaccia composta da tutte le applicazioni che integra.

Al contrario dell’integrazione a

livello di business logic (che aggrega

elaborazione di sistemi diversi), nel caso di

integrazione a livello di portale le

informazioni provenienti da sorgenti

multiple e differenti vengono visualizzate

in una singola finestra. Questo avviene

normalmente dividendo lo schermo in

diverse zone ognuna delle quali comunica

con un differente sistema.

Figura 2: Portal Integration

11

I processi di business sono di fatto eseguiti dagli utenti del portale, che effettuano le

interazioni sulla base dei dati esposti. Il portale diventa di fatto il punto centrale di accesso

per insieme eterogeneo di applicazioni. Nel caso di applicazioni web (che è il più frequente)

questo si realizza tecnologicamente ad esempio tramite normali tecniche HTML (frame,

collegamento ipertestuale, tab view o window open), oppure utilizzando componenti più

raffinati (giusto per fornire qualche esempio: WebParts nell’ambito .NET, largamente usato

dal Sharepoint; oppure Portlet in quello J2EE).

In conclusione questo tipo d’integrazione è interessante nel momento in cui si

richieda una soluzione veloce e non invasiva (e, di conseguenza, poco costosa). In alcune

situazioni questo è sufficiente e può essere una strategia vincente. In altri casi è necessario

effettuare azioni più complesse, agendo sulla business logic o sull'accesso ai dati.

1.2.2 Enterprise Application Integration

In questo caso ci si focalizza sull'integrazione della logica applicativa. Lo scopo è la

condivisione della logica di business tra applicazioni diverse o la composizione di moduli di

logica già sviluppati in processi nuovi. Al contrario della PI, dove sia i dati che la logica

possono vivere indipendentemente, in questo caso parte della logica di business è

necessariamente condivisa.

Si può classificare l'integrazione EAI secondo due possibili approcci:

1. Verticale (P2P – Point-to-Point)

2. Centralizzata (Middleware-based)

In un'integrazione Punto-Punto (Spaghetti3 Integration) si costruiscono le singole

connessioni tra le Applicazioni gestendo singolarmente i problemi di comunicazione e di

mappatura dei dati. Il vantaggio principale dell’approccio P2P è che in questo modo si crea

una connessione “stretta” e sincrona tra le due applicazioni, con la possibilità di integrare

all'interno del codice (in modo mirato) non solo le necessarie conversioni dei dati, ma anche

le regole di business.

Lo svantaggio principale è che tale codice può essere complesso da sviluppare e va

generato per ogni coppia di applicazioni. All’aumentare delle applicazioni da integrare

crescono anche le connessioni da implementare e l’accoppiamento tra di esse con evidenti

impatti sui costi di manutenzione.

3 ‘Spaghetti’ è un termine dispregiativo per quei programmi per computer che abbiano una struttura di

controllo del flusso complessa e/o incomprensibile con construtti di ramificazione non strutturati. Il suo nome deriva dal fatto che i diagrammi di flusso di questi tipi di codice tendono a assomigliare a dei piatti di spaghetti, ovvero a una catasta di fili intrecciati e annodati. In generale Spaghetti = casino

L'integrazione di N applicazioni con altre M con un approccio P2P implica la creazione di

N X M connessioni separate. A tendere, un'architettura di questo tipo, degenera in un

groviglio esponenziale di collegamenti e comporta complessità e costi di manutenzione ed

evoluzione crescenti (spaghetti integration).

Figura 3: Enterprise Application Integration, P2P e Middleware-based

Sarebbe difficile che le soluzioni P2P realizzate saranno in qualche misura riusabili o

adattabili. Con la crescita delle applicazioni aziendali e la necessità di connettere molteplici

applicazioni nello sviluppo di applicazioni Web, nel campo degli strumenti per l'integrazione

era necessario un salto in termini di funzionalità e velocità: è per questo che, rispetto ad

approcci "tattici" ad - hoc per le specifiche necessità punto-punto, sono nate le piattaforme

EAI (Enterprise Application Integration) contraddistinte dalla presenza di un Middleware4

d'integrazione che consenta un'integrazione centralizzata, disciplinata e maggiormente

standardizzata.

Per evitare i problemi sopra descritti, è opportuno definire ed integrare

nell’architettura un opportuno strato di Application Integration che permetta di isolare le

applicazioni centralizzando la gestione delle interconnessioni. L’adozione di tecnologie più

sofisticate quali sistemi di Messaging, Gateway e Middleware di comunicazione consentono

di semplificare le problematiche di comunicazione e supportano meccanismi sincroni e real-

time. Tale approccio può essere a sua volta “diretto” o “indiretto”.

L’approccio più diretto prevede di utilizzare una semplice tecnologia di connessione

e comunicazione, demandando allo strato applicativo (possibilmente ingegnerizzato), le

ulteriori problematiche d’integrazione (mapping, routing, transformation, …). L’approccio

“meno diretto”, Middleware-based, prevede l’introduzione di uno strato di Middleware più

o meno evoluto. Tale strato, agendo da intermediario, centralizza sia le problematiche

puntuali di comunicazione che quelle più ampie d’integrazione.

4 Il termine Middleware genera spesso confusione. Letteralmente è lo strato software "posto nel mezzo"; si

intende un insieme di programmi informatici che fungono da intermediari tra diverse applicazioni e componenti software. Sono spesso utilizzati come supporto per sistemi distribuiti complessi. Comunemente i Middleware sono suddivisi in tre macro-aree: Basic Middleware, Platform Middleware e Integration Middleware.

13

1.2.3 Enterprise Information Integration

Relativamente nuovo, almeno rispetto ai due precedenti, quest’approccio è

incentrato sull'integrazione a livello dati. Si basa sul concetto che in alcune organizzazioni il

problema non è legato tanto alla condivisione della logica quanto ad avere una modalità di

accesso ai dati centralizzata, omogenea e condivisa. In questo caso si ritiene che

l'integrazione a livello di logica applicativa non sia necessaria: l'obiettivo è avere applicazioni

che agiscono sugli stessi dati, che devono essere quindi accessibili in maniera omogenea.

Questo si realizza mediante

l'uso di una serie di tecnologie tra le

quali la più peculiare è quella della

database federation, che

implementa un concetto di

"database virtuale".

Figura 4: Enterprise Information Integration

L'EII ha l'obiettivo di raggiungere un’integrazione a livello dati che complementi gli

altri approcci al problema generale dell'integrazione, e sia in grado di assicurare:

una vista completa, tempestiva ed univoca (!) su entità ed eventi critici a livello

aziendale

connettività, accessibilità e utilizzabilità dei dati a prescindere da specifiche

piattaforme, database, formati (inclusi i dati non strutturati)

consistenza a livello enterprise dei dati che sono a fondamento di applicazioni

diverse tra loro correlate (ad esempio a fronte di replicazione).

L'EII si rende concreto nella realizzazione di uno strato di Middleware che da un lato

sia accessibile a ogni tipo d’applicazione e strumento mediante interfacce standard, e

dall'altro sia in grado di accedere e agire su ogni tipo di dato e informazione, qualunque sia

la natura, la forma (strutturata, semi-strutturata, non strutturata), la locazione fisica,

fornendo sui dati stessi una serie di servizi che, superando il tradizionale acceso "a silos

applicativi", ne consentono un utilizzo ottimale da parte di ogni utente e ogni processo

aziendale.

1.3 SOA e l’integrazione

Dall'esperienza degli architetti sulle problematiche di sviluppo e integrazione è nata

la definizione di una serie di best-practices che globalmente sono indicate con il termine

Service-Oriented Architecture (SOA).

SOA5 è un nuovo paradigma architetturale basato sui concetti di servizio e di

processo. Un servizio è una funzionalità (con un preciso significato di business) che deve

essere disegnato seguendo una serie di dettami architetturali. La caratteristica

fondamentale di quest’approccio è un forte pragmatismo, orientato soprattutto alla

produzione di sistemi informativi complessi che siano nel frattempo facilmente mantenibili,

estendibili e integrabili.

In generale SOA, come paradigma architetturale, proponendosi come obiettivo

esplicito il disegno per l'integrazione, può essere pensato come ortogonale rispetto alle

specifiche istanze di strategie architetturali considerate. Questo significa che, sia che si

considerino sistemi in cui viene effettuata integrazione a livello di portale, di logica di

business o di dati, è possibile (ma sopratutto consigliato) adottare un’architettura a servizi.

Ad esempio, nel caso di PI possiamo comporre "viste" di servizi; nel caso di EAI, i servizi sono

composti o orchestrati in altri servizi e infine in caso di EII, i servizi possono esporre logiche

di accesso ai dati che mascherano la vera complessità dei sistemi sottostanti.

Il presupposto che guida SOA è la considerazione che conviene sviluppare sistemi già

pensando all'integrazione (il cambiamento è inevitabile!) piuttosto che adattarli volta per

volta.

Molti dei principi di SOA si sposano alla perfezione con le problematiche

d’integrazione. In effetti, questi dettami discendono direttamente dalla consapevolezza che,

se il sistema che si sviluppa ha successo, in futuro occorrerà integrarlo. Oppure dal fatto che

si ritiene necessario conservare gli asseti dell'organizzazione, in questo caso facendo

esplicitamente integrazione.

L'applicazione dei principi di SOA alle problematiche d’integrazione viene indicato

con il termine Service Oriented Integration (SOI), che prevede lo sviluppo di Integration

Services. Un Integration Service ha lo scopo di fornire un’interfaccia a servizi di applicazioni

esistenti portando a fattore comune funzionalità o dati trasversali alle applicazioni.

5 Anche se esistono molteplici definizioni di SOA, solo il gruppo OASIS (Organizzazione per lo sviluppo di

standard sull'informazione strutturata) ha prodotto una definizione formale applicabile profondamente sia alla tecnologia che ai domini aziendali: “Un paradigma per l'organizzazione e l'utilizzazione delle risorse distribuite che possono essere sotto il controllo di domini di proprietà differenti. Fornisce un mezzo uniforme per offrire, scoprire, interagire ed usare le capacità di produrre gli effetti voluti consistentemente con presupposti e aspettative misurabili.”

15

Per quanto riguarda EAI e SOA, si

può dire che nell'evoluzione generale dei

sistemi IT verso la Service Oriented

Architecture le funzionalità da integrare

devono essere esposte tramite una logica

a servizi. Tali servizi, detti Functional

Integration Service, possono permettere

l'accesso e l'utilizzo di funzionalità di

business da parte di qualunque altro

servizio, applicazione o utente finale.

Per quanto riguarda invece EII e

SOA, trova posto anche l'emergere dell'EII

nel ruolo chiave di fornitore di Data

Integration Service (o Information Service)

a livello enterprise; in questo caso questi

servizi sono resi disponibili alle altre

applicazioni mediante l'elemento portante

della SOA stessa costituito dall'Enterprise

Service Bus.

Figura 5: Figura 5: PI, EAI, EII e SOI

1.4 Conclusioni

In questo capitolo sono state introdotte le principali strategie architetturali adottate

sino a oggi nell’ambito IT per l'integrazione nei sistemi informativi complessi: Portal

Integration (PI), Enterprise Application Integration (EAI) ed Enterprise Information

Integration (EII). Queste strategie differiscono tra loro in base al layer architetturale su cui si

effettua integrazione. La PI effettua un accorpamento di diverse applicazioni in un'unica

interfaccia utente, l'EAI prevede l’integrazione a livello di business-logic mentre l'EII propone

un approccio orientato ai dati.

E' importante notare che i tre approcci brevemente descritti in precedenza non sono

in assoluta alternativa ma piuttosto complementari: l'EII può ad esempio essere

vantaggiosamente posta al servizio di soluzioni di portale e di workflow fornendo ad esse un

accesso unificato a diverse sorgenti dati, con una tangibile semplificazione nella costruzione

delle soluzioni stesse. L'Enterprise Application Integration si focalizza sull'integrazione della

logica applicativa. Lo scopo è la condivisione della logica di business tra applicazioni diverse

o la composizione di "pezzi" di logica già sviluppati in processi nuovi. Al contrario della PI,

dove l'integrazione è a livello di portale e dove sia i dati che la logica possono vivere

indipendentemente, in questo caso parte della logica di business è necessariamente

condivisa.

Si è inoltre presentato SOA / SOI come la soluzione architetturale più adattabile al

cambiamento, introducendo concetti che si dimostrano essere ortogonali e trasversali alle

strategie d’integrazione presentate. In conclusione, abbiamo osservato che SOA è

compatibile con tutte le strategie architetturali considerate (PI, EAI, EII): questo ne

conferma ulteriormente la validità nello sviluppo di applicazioni complesse orientate

all'integrazione.

17

Capitolo 2 – Analisi di requisiti

i espone in questo capitolo la fase iniziale del ciclo di vita del software, ossia

l’analisi. Questo momento, contrariamente a quanto si potrebbe pensare,

risulta essere il più importante dell’intera fase di produzione dell’applicativo. Si

è erroneamente portati a credere infatti, che sia la fase di codifica il punto critico, ma basti

pensare che un errore di valutazione al momento dell’analisi si ripercuoterà su tutte le fasi

successive (benché queste siano svolte correttamente), quindi sull’intero progetto. È quindi

l’errore in fase di definizione dei requisiti il più grave che si possa commettere, in quanto

esso potrà essere rilevato solo al momento del collaudo dell’applicativo con immaginabili

conseguenze negative, soprattutto in progetti di grandi dimensioni. Ecco perché nei casi di

produzioni importanti si è soliti utilizzare modelli di sviluppo misti, magari con l’aggiunta del

ciclo di ‘prototipizzazione’, al fine di evitare in modo assoluto grossolani errori in questo

primo avanzamento della produzione. Nel nostro caso, vista la limitatezza del lavoro, si è

ritenuto sufficiente adottare un modello di sviluppo standard a cascata.

Va detto che non è stato necessario eseguire tutte le fasi del modello da zero.

Essendo questo un lavoro d’integrazione che si fonda su una progettazione già collaudata,

alcune fasi, come la raccolta dei requisiti mediante intervista e la realizzazione della base di

dati non sono state affrontate e si è utilizzato la documentazione disponibile e analizzando il

materiale già presente, raccolto in precedenza, per finire con la stesura del documento dei

requisiti.

2.1 I requisiti

I requisiti forniscono le linee guida sulle funzionalità e le operazioni che il sistema

finale dovrà essere in grado di svolgere. Si ottengono in vari modi, come interviste dirette

agli utenti e committenti, oppure utilizzando materiali quali documentazioni raccolte in

momenti precedenti. Nel nostro caso si seguirà la seconda modalità.

In modo grossolano, le applicazioni da unificare6 sono 3, ed eventualmente ne saranno

aggiunte altre quando sarà necessario :

6 Per ulteriori dettagli degli applicativi esistenti si consiglia di consultare le tesi dei miei colleghi :

Samo Ziberna, Progetto e sviluppo di un’applicazione per la gestione di un reagentario

Daniele De Gan, Sviluppo di un’applicativo in .NET per la gestione degli ordini ai fornitori di un dipartimento universitario.

S

I. Frasi di rischio e di sicurezza:

Le frasi di rischio e sicurezza sono delle frasi standard, contraddistinte da un codice e

una frase in linguaggio naturale, che descrivono rispettivamente i rischi per la salute

umana, animale o ambientale che una sostanza chimica può provocare e i consigli di

prudenza nel manipolare tale sostanza chimica. Le frasi sono codificate dalla direttiva

europea 88/379/CEE (e successive modifiche) e attualmente vige l'obbligo di

specificarle sulle etichette delle sostanze chimiche..

II. Reagentario:

Il reagentario è il magazzino delle sostanze chimiche del dipartimento di ingegneria

chimica dell'università degli Studi di Trieste. Le sostanza chimiche in possesso del

dipartimento vengono conservate principalmente in una stanza centrale chiamata

“magazzino reagentario”. Alcune sostanze che necessitano di particolari condizioni di

stoccaggio, ad esempio temperatura costante, vengono stoccate in più frigoriferi

localizzati all'interno dei laboratori.

III. Gestione Ordini:

Gestire la memorizzazione degli ordini ai fornitori e permette agli utenti di

compilare, in modo più semplice e rapido, il documento necessario alla richiesta delle

merci o dei servizi. Il documento da elaborare consisterà in un riepilogo dei dati

dell’ordine, in particolar modo l’intestazione del fornitore, l’elenco dei prodotti da

ordinare e altri dati come ad esempio le date di ordine e offerta ecc.

Il dipartimento è già in possesso di tutto il hardware necessario per soddisfare gli

obbiettivi preposti, mentre le applicazioni, seppure coprendo le funzionalità richieste, non

soddisfano gli obbiettivi di semplicità d'utilizzo espressi dagli utenti.

Si rende così necessaria la progettazione e lo sviluppo di una nuova applicazione, la

quale dovrà raggruppare le funzionalità già esistenti in un unica interfaccia utente, avendo

come obiettivo primario la semplicità d'utilizzo ed estendibilità.

2.2 I casi d’uso

In seguito saranno elencati i casi d’uso principali.

Consultazione frasi Rischio/Sicurezza:

Questa parte del sistema sostituirà il catalogo cartaceo delle frasi di rischio e

sicurezza, il quale deve, per obbligo di legge, essere accessibile a chiunque all'interno

dei laboratori.

Il sistema deve quindi garantire l'accesso a queste informazioni a chiunque e nel

modo più intuitivo e semplice possibile. L'utilizzatore del sistema, infatti, deve poter

trovare le frasi di rischio e sicurezza della sostanza chimica desiderata nel minor

19

tempo possibile, poiché si potrebbe trovare in una situazione di pericolosità, nella

quale queste informazioni possono scongiurare un ulteriore danno.

Inoltre in questa sezione deve essere previsto un meccanismo di scelta della lingua

(italiano o inglese) sia per le frasi di rischio e sicurezza sia per la parte di interfaccia.

Prestito e Restituzione:

Questa parte del sistema deve essere accessibile solamente agli operatori di

laboratorio autorizzati. Ogni operatore può effettuare un prestito/prelievo di una o

più sostanze chimiche, dette reagenti, scegliendo, in base alla sostanza chimica, il

contenitore specifico e inserendo la quantità prelevata e il luogo nel quale il

contenitore verrà riposto. Il sistema deve inoltre tenere traccia dell'utente che ha

effettuato l'operazione e la data nella quale l'operazione è stata svolta.

Gestione Ordini

Questa parte del sistema deve essere accessibile solamente ai dipendenti del

dipartimento autorizzati ad effettuare degli ordini. Lo scopo principale di questo

modulo è l’inserimento degli ordini di un dipartimento universitario, al fine di

produrre un documento d’ordine da poter inviare alla ditta fornitrice della merce o

dei servizi. Oltre a compiere un ordine, l’operatore autorizzato può vedere anche

l’archivio completo degli ordini passati.

I casi d’uso successivi vengono svolti solo dall’/dagli amministratore/i del sistema.

Gestione Frasi Rischio/Sicurezza:

La parte di Gestione Frasi R/S deve essere raggiungibile solamente da un tipo

di utente specifico, ovvero dall'amministratore. L'amministratore deve poter inserire

le frasi di rischio/sicurezza, aggiornarle e eventualmente eliminarle.

Gestione Reagente:

L'amministratore deve poter inserire un nuovo contenitore di reagente,

specificando di quale sostanza chimica si tratta, la capacità del contenitore, la data

d'acquisto, l'eventuale data di scadenza, il fornitore che l'ha fornita, il luogo in cui è o

sarà riposta e l'operatore di laboratorio che l'ha richiesta.

In questa sezione l'amministratore deve poter modificare i dati del reagente ed

eventualmente eliminare il contenitore, il ché comporta l'inserimento in automatico

della data di eliminazione e il cambio di stato in “Eliminato”.

Inoltre deve poter visualizzare l'elenco dei reagenti, filtrati in base alla sostanza

chimica.

Gestione Sostanza Chimica:

In questa parte l'amministratore deve poter inserire una nuova sostanza

chimica, il ché comporta l'inserimento di un nome, del numero CAS, della sua

formula chimica, della massa molecolare, della classe di appartenenza. Deve poter

inserire eventuali sinonimi dei nomi, le frasi di rischio e sicurezza associate alla

sostanza chimica in questione. Inoltre non deve mancare la possibilità di modificare i

dati inseriti ed eventualmente eliminarli.

Gestione Utenti/Fornitori:

Questa sezione permetterà ad effettuare le operazioni di inserimento,

modifica o cancellazione dalla base di dati del sistema le persone che possono

interagire con il sistema stesso. In particolare, anche se il sistema dispone una fase di

registrazione per gli utenti, è necessario che l’amministratore del sistema li

attribuisce i ruoli specificati.

Gestione scarti:

Un’ operazione poco usata fin ora, che però risulta necessaria. Essa elenca gli

scarti smaltiti e quelli da smaltire.

Figura 6: I casi d'uso del sistema

21

Capitolo 3 - Progettazione

n questa successiva fase vengono riportate le decisioni sul ‘come’ tali requisiti

analizzati nel capitolo precedente saranno soddisfatti, entrando nel merito della

struttura che dovrà essere data al sistema software che deve essere realizzato. In

particolare vengono trattate l’integrazione e le modifiche sulla base di dati, viene illustrato

l’architettura del sistema (evidenziando alcuni considerazioni nell'utilizzo dei livelli e

fornendo linee guida per le prestazioni, la sicurezza e la distribuzione) ed il livello di

presentazione. Infine è stata affrontata la descrizione delle scelte progettuali, in particolar

modo mettendo in risalto le tecnologie software scelte per l’implementazione del sistema.

3.1 Database: integrazione e modifiche

Come già anticipato, si è partiti nella realizzazione dell’applicativo da database

preesistenti. Essendo le applicazioni sviluppate distintamente, ognuna ha il proprio DB.

Il database Reagentario è stato realizzato per la gestione dei reagenti (sostanze

chimiche) presenti all'interno del dipartimento; l'obbiettivo primario era la

tracciabilità dei prelievi/prestiti dei reagenti. Inoltre vengono salvati i dati riguardanti

le frasi di rischio e sicurezza che sono associate alle sostanze chimiche.

Il database GestioneOrdini permette di memorizzazione degli ordini effettuati ai

fornitori.

In questo sottocapitolo seguirà una breve descrizione della struttura del database finale

e in particolar modo si evidenzieranno le modifiche apportate alle tabelle dello stesso, per

poter implementare alcune funzionalità utili.

Confrontando i due diagrammi E-R esistenti si identificavano come possibili punti

d'incontro dei due database le entità Utente e Fornitore. Dalla fusione dei due database

(Reagentario e GESTIONEORDINI) sono cambiati i campi di queste due tabelle :

Figura 7: Le tabelle in comune dalla fusione dei database

I

Lo schema del database finale è basato sugli schemi dei database esistenti.

Figura 8: Lo schema fisico finale del database

I cambiamenti strutturali apportati sono:

È stata cancellata la tabella tblAbilitazione, perché limita i ruoli di un utente (utente

- ruolo 1:1); invece sono state create le tabelle tblUtenteRuolo e tblRuolo così

facendo si avrà: (utente - ruolo 1:N)

È stata cancellata la tabella tblStatoUtente perché non serve con il nuovo sistema di

autenticazione/autorizzazione. Nel caso che vogliamo attivare un utente registrato,

basta associarlo i ruoli appropriati, nel caso contrario (sospensione) basta toglierlo

tutti i ruoli

la tabella tblLaboratorio è stata sostituita dalla tblLocazioneUtente con i rispettivi

campi: IDLocazioneUtente, NomeLocazione e NomeStanza

visReagentiInUso

SELECT dbo.tblReagenteDF.IDreagente, dbo.tblSostanzaChimica.NomeSostanza, dbo.tblReagenteDV.QuantitàResidua, dbo.tblReagenteDF.Capacità, dbo.tblUnitàDiMisura.Misura, dbo.tblLocazione.NomeLocazione, dbo.tblReagenteDF.DataAcquisto, dbo.tblReagenteDF.DataScadenza, dbo.tblUtente.CognomeUtente, dbo.tblUnitàDiMisura.IDMisura, dbo.tblSostanzaChimica.IDSostanzaChimica, dbo.tblStato.Stato,

23

dbo.tblLocazione.IDLocazione FROM dbo.tblLocazione INNER JOIN dbo.tblReagenteDV ON dbo.tblLocazione.IDLocazione = dbo.tblReagenteDV.IDLocazione INNER JOIN dbo.tblStato ON dbo.tblReagenteDV.IDStato = dbo.tblStato.IDStato RIGHT OUTER JOIN dbo.tblReagenteDF INNER JOIN dbo.tblSostanzaChimica ON dbo.tblReagenteDF.IDSostanzaChimica = dbo.tblSostanzaChimica.IDSostanzaChimica INNER JOIN dbo.tblUnitàDiMisura ON dbo.tblReagenteDF.IDMisura = dbo.tblUnitàDiMisura.IDMisura INNER JOIN dbo.tblUtente ON dbo.tblReagenteDF.Username = dbo.tblUtente.Username ON dbo.tblReagenteDV.IDReagente = dbo.tblReagenteDF.IDreagente WHERE (dbo.tblStato.Stato = 'Attivo') AND (dbo.tblReagenteDV.QuantitàResidua > 0) OR (dbo.tblStato.Stato = N'In Prestito') AND (dbo.tblReagenteDV.QuantitàResidua > 0)

visReagenteInPrestito

SELECT dbo.tblPrelievo.IDPrelievo, dbo.tblPrelievo.DataPrelievo, dbo.tblSostanzaChimica.NomeSostanza, dbo.tblPrelievo.Username, dbo.tblPrelievo.QuantitàPrelevata, dbo.tblUnitàDiMisura.Misura FROM dbo.tblPrelievo INNER JOIN dbo.tblReagenteDV ON dbo.tblPrelievo.IDReagente = dbo.tblReagenteDV.IDReagente INNER JOIN dbo.tblReagenteDF ON dbo.tblReagenteDV.IDReagente = dbo.tblReagenteDF.IDreagente INNER JOIN dbo.tblSostanzaChimica ON dbo.tblReagenteDF.IDSostanzaChimica = dbo.tblSostanzaChimica.IDSostanzaChimica INNER JOIN dbo.tblUnitàDiMisura ON dbo.tblReagenteDF.IDMisura = dbo.tblUnitàDiMisura.IDMisura WHERE (dbo.tblPrelievo.DataRestituzione IS NULL)

Come esempio sono riportate le seguenti Stored Procedures che verranno maggiormente

utilizzate:

spPrestito : Procedura da chiamare per effettuare un prestito di un reagente.

La procedura inserisce una nuova riga nella tabella Prelievo, utilizzando i dati forniti

come parametri (IDReagente, Quantità, Username, IDLocazione), mentre per la data del

prelievo viene usata la data corrente fornita dal DBMS. Viene inoltre aggiornato lo stato del

reagente, passando a 'In prestito' e la quantità residua viene diminuita della quantità

specificata.

PROCEDURE [dbo].[spPrestito] @IDReagente as int,@Quantita as float,

@Username as nvarchar(16), @IDLocazione as int

AS

BEGIN

SET NOCOUNT ON;

BEGIN TRANSACTION

INSERT INTO visPrelievo

(IDReagente,DataPrelievo,QuantitàPrelevata,Username) values

(@IDReagente,getDate(),@Quantita,@Username)

IF @@ERROR <> 0

BEGIN

ROLLBACK TRANSACTION

return 10

END

UPDATE visReagenteDV SET QuantitàResidua = QuantitàResidua-

@Quantita, IDStato = (SELECT IDStato FROM visStato WHERE Stato = 'In

prestito'), IDLocazione = @IDLocazione WHERE IDReagente = @IDReagente;

IF @@ERROR <> 0

BEGIN


return 10

END

COMMIT TRANSACTION

END

spRestituzione : Procedura da chiamare per restituire un reagente.

La procedura aggiorna la riga della tabella Prelievo, inserendo la data corrente

fornita dal DBMS come data di restituzione. Inoltre aggiorna la tabella del reagente,

cambiandone lo stato in 'Attivo' e aggiornandone la locazione.

PROCEDURE [dbo].[spRestituzione] @IDPrelievo as int, @IDLocazione as int

AS

BEGIN

SET NOCOUNT ON;

BEGIN TRANSACTION

UPDATE visPrelievo SET DataRestituzione = getDate() WHERE

IDPrelievo = @IDPrelievo

IF @@ERROR <> 0

BEGIN


return 10

END

UPDATE visReagenteDV SET IDStato = (SELECT IDStato FROM

visStato WHERE Stato = 'Attivo'), IDLocazione = @IDLocazione WHERE

IDReagente = (SELECT IDReagente FROM visPrelievo WHERE IDPrelievo =

@IDPrelievo);

IF @@ERROR <> 0

BEGIN


return 10

END

COMMIT TRANSACTION

END

25

3.2 L’applicazione

Essendo partiti da applicazioni desktop-based, è di buona norma spiegare le scelte progettuali della migrazione verso la piattaforma web 3(N)-tier. Analizzando i problemi comuni, si potrebbero evitare gli errori fatti frequentemente.

Il nucleo di un'applicazione Web è la sua logica sul lato server. Il livello di applicazione Web stesso può essere composto di molti strati distinti. L'esempio tipico è un’ architettura a tre strati composta di presentazione, business, e lo strato dei dati. Nei giorni d’oggi è aumentata anche l’importanza assai notevole dei servizi che può essere considerato come un ulteriore strato. La figura accanto illustra un comune architettura di un’applicazione Web con componenti comuni raggruppati in diverse aree di coinvolgimento.

Figura 9: L’architettura tipica di un’ applicazione Web

3.2.1 Considerazioni sulla progettazione

Durante la progettazione di un'applicazione Web, gli obiettivi di un architetto del software sono di ridurre al minimo le complessità di separazione tra le funzioni in diverse aree di interesse, mentre si progetta un applicazione sicuro e di alta prestazione.

In questa fase valgono i seguenti orientamenti:

• Partizionare l'applicazione logicamente.

Usare stratificazione per partizionare l'applicazione logicamente in livelli di presentazione, business, e accesso ai dati. Ciò consente di creare codice mantenibile e consente di monitorare, testare e ottimizzare le prestazioni di ogni strato separatamente. Un chiaro separazione logica offre anche una maggiore scelta per la scalabilità dell'applicazione.

• Utilizzare astrazione per implementare disaccoppiamento fra gli strati.

Questo può essere realizzato mediante la definizione dei componenti dell'interfaccia, come ad esempio una facciata con note ingressi e uscite che traduce le richieste in un formato comprensibile per i componenti all'interno del livello. In aggiunta, è anche possibile utilizzare i tipi di interfaccia o le classi di base astratta per definire una astrazione condivisa che devono essere attuate dai componenti di interfaccia.

• Capire come i componenti comunicano tra loro.

Ciò richiede una comprensione degli scenari di distribuzione che l'applicazione deve supportare. È necessario determinare se la comunicazione va oltre i confini fisici o limiti di processi che devono essere supportati, o se tutti i componenti si svolgeranno all'interno dello stesso processo.

• Ridurre il round trip.

Durante la progettazione di un'applicazione Web, è possibile utilizzare tecniche come memorizzazione nella cache e il buffer di uscita per ridurre i viaggi 'andata e ritorno' tra il browser e il server web.

• Considerare l'uso e la strumentazione di registrazione.

E’ buona prassi di tenere traccia di log di attività in tutti i strati e livelli dell‘ applicazione. Questi log possono essere utilizzati per rilevare le attività sospette, che forniscono spesso le prime indicazioni di un attacco al sistema.

• Evitare il blocco durante i compiti funzionali di lunga durata.

Se si dispongono blocchi di operazioni di lunga durata, si considera l'utilizzo di un approccio asincrono per consentire al server Web di elaborare altre richieste in arrivo.

• Considerare l'autenticazione degli utenti attraverso i confini di fiducia.

Si consiglia di progettare l’applicazione per autenticare gli utenti ogni volta che attraversa una frontiera di fiducia, per esempio, quando l'accesso a uno strato a distanza di business dal livello di presentazione.

• Non far passare i dati sensibili in chiaro attraverso la rete.

Quando è necessario passare dati sensibili come password o cookie di autenticazione attraverso la rete, si prende in considerazione la cifratura, firmare i dati o utilizzando SSL.

• Modellare per eseguire l'applicazione Web utilizzando un account con privilegi minimi.

Se un pirata informatico riesce assumere il controllo di un processo, l'identità del processo avrebbe dovuto limitare l'accesso al file del sistema e altre risorse di sistema, al fine di limitare i possibili danni.

27

3.2. 2 Il panorama di un’applicazione web

Ci sono diversi problemi comuni che sono necessari considerare come sviluppare il disegno. Questi problemi possono essere suddivisi in aree specifiche del progetto. La seguente lista elenca i comuni temi per ciascuna categoria in cui gli errori fatti sono più frequenti:

Autenticazione:

Progettazione di una strategia di autenticazione efficace è importante per la sicurezza e l'affidabilità dell'applicazione. Un’ autenticazione improprio o debole può lasciare l'applicazione vulnerabile agli attacchi di spoofing o di vocabolario, dirottamento di sessione, e altri tipi di attacco.

Autorizzazione:

L'autorizzazione stabilisce i compiti che un’identità autenticata può eseguire e identifica le risorse a cui può accedere. Progettazione di una strategia efficace di autorizzazione è importante per la sicurezza e l'affidabilità dell'applicazione. Un’autorizzazione impropria o debole porta a divulgazione di informazioni, l'alterazione dei dati, e l'elevazione di privilegi. La difesa in profondità è la chiave principiale di sicurezza da applicare alla strategia di autorizzazione.

Caching:

La memorizzazione nella cache migliora le prestazioni e i tempi di risposta dell'applicazione. Tuttavia, le scelte non corrette di caching e design caching poveri possono degradare le prestazioni e la reattività. Si dovrebbe utilizzare la cache di riferimento per ottimizzare le ricerche dei dati, evitare viaggi di andata e ritorno di rete, ed evitare trasformazione inutili e duplicati. Per implementare la memorizzazione nella cache, è necessario decidere quando si devono caricare i dati nella cache. Si deve caricare la cache in modo asincrono o utilizzando un processo batch per evitare eventuali ritardi.

Gestione delle eccezioni:

La progettazione di una strategia efficace di gestione delle eccezioni è importante per la sicurezza e l'affidabilità dell'applicazione. La corretta gestione delle eccezioni nelle pagine Web impedisce dettagli sensibili di eccezione di essere rivelato per l'utente, migliora la robustezza di applicazione, e aiuta ad evitare di lasciare l'applicazione in uno stato incoerente, in caso di un errore.

Navigazione:

Progettare la strategia di navigazione in modo che la separa dalla logica di elaborazione. Esso dovrebbe consentire agli utenti di navigare facilmente attraverso le schermate o le pagine. La progettazione di una navigazione coerente nell'applicazione aiuterà a ridurre al minimo la confusione degli utenti così come la riduzione dell’apparente complessità della domanda.

Layout di pagina (User Interface):

Si deve progettare l’applicazione in modo che il layout della pagina può essere separata dai componenti specifici dell’interfaccia utente e dall'elaborazione del tale. Quando si sceglie una strategia di layout, bisogna valutare un approccio che non richiede la codifica o l'utilizzo di strumenti orientati allo sviluppo.

Renderizzazione delle pagine:

Quando si progetta il rendering della pagina, è necessario assicurarsi che si esegue il rendering delle pagine in modo efficiente e massimizzare l'usabilità dell'interfaccia. Da considerare l'uso di AJAX per un'esperienza utente migliorata e una migliore reattività.

Oggetti di presentazione:

Gli oggetti di presentazione memorizzano i dati che verranno utilizzati per gestire lo strato della presentazione. Questi oggetti non sono sempre necessari. Sono da considerare solo se gli insiemi di dati che devono essere conservati sono sufficientemente di grandi dimensioni, complessi o la loro esistenza sta separatamente da controlli di interfaccia utente.

L'elaborazione della richiesta:

Quando si progetta una strategia di elaborazione richiesta, si dovrebbe garantire la distinzione delle preoccupazioni da parte della logica di elaborazione della richiesta separatamente dall’interfaccia utente.

Gestione della sessione:

Durante la progettazione di un'applicazione Web, un’efficiente e sicura strategia di gestione della sessione è importante per le prestazioni e l'affidabilità. È necessario considerare fattori come la gestione della sessione come quello di immagazzinare, dove metterlo, e per quanto tempo le informazioni saranno mantenute.

Convalida:

29

Progettare una soluzione effettiva di convalida è importante per la sicurezza e l'affidabilità dell’applicazione. Un autorizzazione improprio o debole può lasciare l'applicazione vulnerabile agli attacchi di ingresso.

Test e considerazioni sulla testabilità: Testabilità è una misura di quanto un sistema o dei componenti consentono di creare

criteri di prova ed eseguire test per determinare se i criteri sono rispettati. Si dovrebbe

prendere in considerazione la testabilità prima che si inizia a progettare l'architettura

perché rende più facile diagnosticare prima i problemi e ridurre costi di manutenzione. Per

migliorare la testabilità dell’applicazione, è possibile utilizzare la registrazione degli eventi,

fornire risorse di monitoraggio, e implementare le interfacce di test.

Considerazioni sulle prestazioni:

È necessario identificare gli obiettivi di prestazioni, già in fase di progettazione di

un'applicazione Web raccogliendo i requisiti non funzionali. Il tempo di risposta, throughput,

CPU, memoria e Input / Output su disco sono alcuni dei fattori chiave necessari a

considerare durante la progettazione dell'applicazione.

Considerazioni sulla sicurezza:

La sicurezza è un fattore importante per proteggere l'integrità e riservatezza dei dati

e le risorse dell’applicazione web. Si consiglia di progettare una strategia di sicurezza per

l'applicazione Web che utilizza le soluzioni di sicurezza testate e provate e implementare

l'autenticazione, autorizzazione e convalida dei dati per proteggere l'applicazione da una

serie di minacce.

3.2.3 Stratificazione

L'utilizzo dei layer in un disegno permette di separare le funzionalità in diverse aree di

preoccupazione. In altre parole, i livelli rappresentano il gruppo logico dei componenti

all'interno del disegno. Si dovrebbe anche definire le linee guida per la comunicazione tra i

livelli. Ad esempio, il livello A può accedere il livello B, ma il livello B non può accedere al

livello A. I livelli dovrebbero rappresentare un raggruppamento logico di componenti. Ad

esempio, utilizzare livelli separati per 1) l'interfaccia utente, 2) logica di business, 3)i

componenti di accesso ai dati e 4) il livello di servizi (facoltativo).

Lo strato di presentazione:

Il livello di presentazione dell'applicazione Web serve a visualizzare l'interfaccia utente e facilita l’interazione con l'utente. Il design dovrebbe concentrarsi sulla separazione degli interessi, dove la logica dell'interazione con l'utente è disaccoppiato dai componenti dell'interfaccia.

Lo strato di Business:

Durante la progettazione di livello aziendale per l'applicazione Web, considerare come implementare la logica di business e flusso di lavoro(workflow) in esecuzione a lunga durata. Disegnare le entità commerciali che rappresentano i veri dati nel mondo reale, e utilizzare questi per passare dati tra i componenti.

Lo strato di dati:

Progettare un livello di dati per l'applicazione Web di astrarre la logica necessaria per accedere al database. Utilizzando un livello separato dati rende l'applicazione più semplice da configurare e mantenere. Lo strato di dati può anche avere bisogno di accedere ai servizi esterni che utilizzano agenti di servizio.

Lo strato dei servizi:

Si consideri la progettazione di un livello di servizio separato se si preveda di distribuire il livello di business su uno strato a distanza, o se si prevede di esporre la logica di business utilizzando un servizio web.

Figura 10: La soluzione tecnica del sistema

3.2.4 Considerazioni sulla distribuzione

Durante la distribuzione di un'applicazione Web, si dovrebbe prendere in

considerazione come la posizione di ogni strato e componente influenzerà le prestazioni, la

scalabilità e la sicurezza dell'applicazione. Utilizzare un approccio distribuito o non

distribuito, a seconda delle esigenze aziendali e dei vincoli infrastrutturali.

31

Applicazioni non distribuite:

In uno scenario non distribuito,

tutti gli strati logicamente separati

dell’applicazione Web si trovano

fisicamente nello stesso server Web, ad

eccezione del DB. È necessario

considerare come l'applicazione di gestire

più utenti contemporaneamente, e per

come garantire la strati che risiedono sullo

stesso server. La Figura 11 mostra questo

scenario.

Figura 11: Un’applicazione Web non distribuita

Applicazioni distribuite:

Nello scenario distribuito, i livelli di presentazione e di business dell'applicazione Web

risiedono su distinti livelli fisici, e comunicano a distanza. In genere si localizzano il livello di

logica di business e livelli di accesso ai dati sullo stesso server. La Figura 12Error! Reference

source not found. mostra questo scenario.

Figura 12: Un’applicazione Web distribuita

Considerazioni sulla tecnologia:

Sulla piattaforma Microsoft, da un punto di vista ASP.NET, è possibile combinare il

modello ASP.NET Web Forms con una serie di altre tecnologie, tra cui ASP.NET AJAX,

ASP.NET MVC, Silverlight e ASP.NET Dynamic Data.

Considerate le seguenti linee guida:

Se si desidera creare applicazioni a cui si accede tramite un browser Web o user

agent specializzato, considerare l'utilizzo di ASP.NET.

Se si vuole costruire applicazioni che offrono una maggiore interattività e

l'elaborazione in background, con un minor numero di refresh della pagina, è

consigliabile utilizzare ASP.NET AJAX (aka ATLAS).

Se si vuole costruire applicazioni che includono contenuti multimediali e interattività,

considerare l'utilizzo di ASP.NET con controlli di Silverlight.

Se si utilizza ASP.NET, considerare l'utilizzo di pagine master per attuare una

coerente interfaccia utente in tutte le pagine.

Se si sta creando un'applicazione Web basata sui dati con pagine basate sul modello

di dati del database sottostante, è consigliabile utilizzare ASP.NET Dynamic Data.

3.2.5 User Experience (UX)

L’ultimo argomento, ma non meno importante degli altri citati in precedenza è

l’esperienza dell’utente finale. L’User eXperience è una disciplina decisamente importante

quando si sviluppa un sito web, permette infatti di capire i problemi degli utenti, i bisogni

delle aziende, i requisiti che quel dato sito dovrà avere.

Con il termine di user experience (in italiano esperienza utente), s’intende

l’esperienza vissuta dall’utente nel momento in cui interagisce con una interfaccia web o

con altre tecnologie digitali. Nel caso dell’interfaccia di un sito web, per misurare la qualità

dell’esperienza che l’utente ha nell’interagire con essa, spesso e volentieri si ricorre allo

strumento dei test su persone non coinvolte nel progetto.

In base ai comportamenti e alle scelte intraprese dai tester nell’utilizzare una determinata

interfaccia grafica, si possono trarre le opportune considerazioni in merito all’usabilità del

progetto stesso. In sostanza, permette di creare un sito (o, in generale, un’applicazione) più

usabile.

Progettare per una user experience efficace può essere fondamentale per il successo

dell’applicazione. Se la navigazione è difficile, se gli utenti vengono indirizzati alle pagine

inaspettato, l'esperienza utente può essere negativo.

3.3 Presentazione

Pur avendo a disposizione il codice sorgente delle applicazioni attualmente a

disposizione del dipartimento, le loro interfacce utente sono completamente differenti,

quindi si rende così necessario lo sviluppo ex novo dell'interfaccia utente e della logica

sottostante. Questa scelta è stata giustificata anche perché è stato deciso di migrare dalla

piattaforma desktop-based a quella Web.

L'interfaccia utente è stata progettata con l'intento di renderla il più semplice

possibile. Si è quindi deciso di creare una struttura paginata; ogni pagina implementa un

caso d'uso tra quelli principali. Si è cercato inoltre di rendere le pagine più simili possibili,

semplificando così l'apprendimento dell'interfaccia all'utente finale.

33

Inoltre, per non far sentire l’utente finale in difficoltà (come il pesce fuor d’acqua) di

trovare qualcosa o andare nell’area specifica d’interesse, è stato ideato un menù

‘intelligente’ alla sinistra del sito nel quale compaiono i collegamenti di navigazione solo

sulle pagine consentite per quello specifico ruolo in cui l’utente appartiene. Questi

collegamenti sono raggruppati per la similitudine dell’operazione che offrono. Ogni raccolta

contiene una pagina di default in cui vengono elencati i collegamenti insieme con una breve

descrizione per ognuna. In più, c’è anche una menù di navigazione a barra, la quale mostra

sempre il collegamento con la pagina principale e il punto della posizione attuale della

navigazione nella gerarchia delle pagine.

3.4 Scelte progettuali

Affrontiamo qui la descrizione delle scelte progettuali, in particolar modo mettendo

in risalto le tecnologie software scelte per l’implementazione del nostro sistema. Si fornisce

una panoramica del progetto .NET di Microsoft e del linguaggio C# scelto come linguaggio di

sviluppo. Si passerà poi a trattare il middleware della logica di business, per finire a

descrivere le modalità di accesso ai dati dell’applicativo, descrivendo come sia possibile

associare svariati controlli alle tabelle del nostro Data Base.

3.4.1 ASP.NET

ASP.NET è un insieme di tecnologie di sviluppo di software per il web,

commercializzate dalla Microsoft. Utilizzando queste tecnologie gli sviluppatori possono

realizzare applicazioni Web e servizi Web (Web Services).

Sebbene il nome ASP.NET derivi da ASP (Active Server Pages, la vecchia tecnologia

per lo sviluppo web di Microsoft), esistono sostanziali differenze fra le due. Infatti ASP.NET

si basa, come tutte le applicazioni della famiglia Microsoft .NET, sul CLR (Common Language

Runtime).

Gli sviluppatori possono scrivere codice utilizzando uno qualsiasi dei linguaggi di alto

livello supportati dal Framework .NET (libreria di classi) .NET come, ad esempio, Visual Basic

.Net (proprietario Microsoft), C# (linguaggio soggetto a una specifica di standardizzazione),

J# (J sharp, derivato da Java), ma anche, molti altri linguaggi open source (e non), come Perl

e Python, questo è possibile poiché il CLR è stato standardizzato presso ECMA. Le

applicazioni ASP.NET sono significativamente più veloci e performanti rispetto a quelle

realizzate utilizzando altre tecnologie di scripting, in quanto l'intero codice del sito web è

pre-compilato in pochi file dll (spesso in un unico file) gestiti da un server Web.

http://it.wikipedia.org/w/index.php?title=Tecnologia_di_programmazione&action=edit&redlink=1

http://it.wikipedia.org/wiki/Software

http://it.wikipedia.org/wiki/Web

http://it.wikipedia.org/wiki/Microsoft

http://it.wikipedia.org/wiki/Applicazione_Web

http://it.wikipedia.org/wiki/Web_Service

ASP.NET si propone di semplificare la migrazione degli sviluppatori dalle applicazioni

Windows alle applicazioni web mettendoli in grado di generare pagine composte da tanti

controlli widget, del tutto simili a quelli usati dall'interfaccia utente di Windows.

Un controllo web, come ad esempio un pulsante o un etichetta (label), funzionano in

modo molto simile a quello delle loro controparti Windows: il codice ad essi associato può

assegnare loro determinate proprietà ed eseguire azioni in risposta ad eventi ad essi

associati (ad esempio alla pressione di un pulsante). La differenza sta nel fatto che, mentre i

controlli Windows disegnano sé stessi sullo schermo, i controlli web producono blocchi di

codice HTML che si vanno ad inserire automaticamente nella pagina che deve essere inviata

al browser dell'utente finale.

La vasta disponibilità di controlli, classi e strumenti di sviluppo consente di ridurre

sensibilmente i tempi di sviluppo dei moduli software, e mette lo sviluppatore in condizione

di riutilizzare facilmente uno stesso codice in applicazioni differenti. ASP.NET ha inoltre

semplificato significativamente le funzionalità di accesso ai dati rispetto ad ASP. Ad

esempio, è molto più semplice ed immediato generare una pagina contenente una lista di

dati prelevati da un database.

3.4.2 C#

Sebbene la piattaforma .NET non obblighi nessun programmatore nel scegliere un

qualsiasi dei linguaggi di alto livello supportati dal Framework, è stato opportuno trarne i

benefici offerti dal C#, abbastanza consolidato anche se nato nell’ultimo decennio.

C# (C Sharp) è un linguaggio di programmazione ad alto livello, orientato agli oggetti,

sviluppato dalla stessa Microsoft all'interno dell'iniziativa .NET, e in seguito approvato come

standard ECMA. La sintassi del C# prende spunto da quella della Delphi (hanno il medesimo

autore, Anders Hejlsberg), del C++, da quella di Java e da Visual Basic per gli strumenti di

programmazione visuale e per la sua semplicità (meno simbolismo rispetto a C++, meno

elementi decorativi rispetto a Java).

C# è, in un certo senso, il linguaggio che meglio degli altri descrive le linee guida sulle

quali ogni programma .NET viene eseguito; questo linguaggio, infatti, è stato creato da

Microsoft specificatamente per la programmazione nel Framework .NET. I suoi tipi di dati

"primitivi" hanno una corrispondenza univoca con i tipi .NET e molte delle sue astrazioni,

come classi, interfacce, delegati ed eccezioni, sono particolarmente adatte a gestire il .NET

Framework.

3.4.3 Windows Communication Foundation

35

WCF è un "sottosistema applicativo" proprietario della Microsoft, che offre la

struttura API per la creazione di applicazioni distribuite in ambienti Windows. Se da un lato

ogni protocollo di rete (ad esempio HTTP, FTP, SMTP, ecc.) ha un suo modello di

programmazione, e necessita quindi di una conoscenza specifica da parte degli sviluppatori

per poter essere utilizzata, WCF è stato realizzato con l'intento di ricondurre ad un unico

modello diverse tecnologie, rendendo più semplice ed uniforme la programmazione in

ambiente Windows.

In particolare, WCF RIA Services 7fornisce il controllo DomainDataSource per

semplificare l'interazione tra l’interfaccia utente e dati da un contesto di dominio. Con il

DomainDataSource è possibile recuperare, adattare e modificare dati usando solo la sintassi

dichiarativa. Con quest’oggetto si può fare il carico, il filtraggio, il raggruppamento e

l’ordinamento di raccolte di dati in modo più facile e trasparente. Si specifica il contesto di

dominio da utilizzare con la DomainDataSource, e quindi chiamare le operazioni che sono

disponibili attraverso tale contesto di dominio.

3.4.4 Dynamic Data (DD)

ASP.NET Dynamic Data è un framework di ponteggi ispirato da Ruby on Rails, fornito

come estensione ad ASP.NET, che consente di generare un sito web completo partendo da

un modello dei dati. Espone le tabelle di un database codificandole nell’URI dei Web Service

ASP.NET, e i dati nella tabella vengono automaticamente presentati in HTML. Il processo di

rendering può essere controllato utilizzando la progettazione di modelli personalizzati.

Internamente, si scopre lo schema di database utilizzando i metadati del DB.

Un altro aspetto importante riguarda il motore di routing su cui si basano, che

consente di non legare l’url che chiamiamo nel browser per richiedere una specifica pagina

la dove risieda, oppure come questa si chiami. Inoltre è possibile modificare il

comportamento del motore di routing tramite delle regole, in un unico punto, senza dover

modificare nulla nelle singole pagine e come queste si richiamino tra di loro.

In conclusione, i DD vanno ad arricchire le funzionalità delle WebForms, offrendo un

framework per realizzare applicazioni web orientate ai dati. I DD offrono comunque un

meccanismo che permette molte forme di personalizzazione, permettono di usare dei

template particolari per fare il rendering di campi specifici di una tabella usando ad esempio

i controlli dell’AJAX Control Toolkit o di terze parti ad esempio per selezionare un

calendario, oppure uno slider per decidere una quantità numerica. Le pagine degli ASP.NET

Dynamic Data sono già pensate per sfruttare i controlli ASP.NET AJAX. Altri attributi

consentono di impostare delle regole di validazione sul modello dei dati, ad esempio si può

7 WCF RIA Services fornisce un framework end-to-end per semplificare la creazione di applicazioni tradizionali

n-tier data-driven con Microsoft Silverlight, ASP.NET e WCF.

impostare tali regole direttamente sulle proprietà delle classi generate dal modello dei dati,

creando delle classi parziali. Questo meccanismo consente di accentrare le regole di

validazione, che poi “fluiscono” nell’UI e valgono in qualsiasi pagina web si faccia

riferimento a quella specifica classe.

3.4.5 Entity Framework

Entity Framework è il nuovo O/RM8 realizzato da Microsoft basato interamente sul

.NET Framework. EF fa l’astrazione dello schema relazionale (logico) dei dati che vengono

memorizzati in un database e presenta il suo schema concettuale per l'applicazione.

Quest’astrazione elimina la mancata corrispondenza relazionale a oggetti che generalmente

è comune nei classici programmi orientati ai database.

Per esempio, in un sistema convenzionale di database-oriented, le voci su un cliente

e le loro informazioni possono essere memorizzate in una tabella Clienti, i loro ordini in una

tabella Ordini e le loro informazioni di contatto in un altro ancora tabella Contatti.

L'applicazione che si occupa di questo database deve "sapere" quali informazioni sono in

quale tabella, che, cioè, lo schema relazionale dei dati è ‘hardcoded’ nell'applicazione.

Un’altra arma potente dell’EF è il supporto del LINQ come linguaggio di selezione e

manipolazione dati. In genere, le query sui dati vengono espresse come stringhe semplici

senza il controllo dei tipi in fase di compilazione o il supporto IntelliSense. È inoltre

necessario imparare un linguaggio di query diverso per ogni tipo di origine dati: database

SQL, documenti XML, svariati servizi Web e così via. LINQ2Entity (e LINQ in generale) rende

una query un costrutto di linguaggio di prima categoria in C#.

Lo svantaggio di quest’approccio è che se questo schema viene cambiato

l'applicazione non è al riparo dal cambiamento. Inoltre, l'applicazione deve eseguire uno join

SQL per attraversare le relazioni degli elementi di dati al fine di trovare i dati correlati.

Questo modello di relazioni tra gli elementi trasversali è molto diverso dal modello

utilizzato nei linguaggi di programmazione object-oriented, dove sono esposte le relazioni

delle caratteristiche di un oggetto come proprietà dell'oggetto e l'accesso alla proprietà

attraversa il rapporto. EF consente di scrivere i programmi con le classi che vengono

generate da questo livello concettuale. Il framework gestisce quindi tutta la traduzione

richiesta, come si estraggono i dati dal database e inviare di nuovo dentro di esso.

8 L' Object-Relational Mapping è una tecnica di programmazione che favorisce l'integrazione di sistemi SW

aderenti al paradigma della programmazione orientata agli oggetti con sistemi RDBMS. Vedi 4.2.2 ORM

37

Capitolo 4 – Realizzazione

a fase di realizzazione (o meglio conosciuta come la codifica) è la fase in cui le

idee sviluppate nella progettazione vengono implementate concretamente

attraverso la creazione dei moduli funzionali e la loro progressiva integrazione.

In questo capitolo sarà descritto il tentativo verso l’approccio RIA e argomentato perché non

era adatto per il sistema. In seguito saranno elencate le principali funzionalità

dell’applicativo.

4.1 Rich Internet Applications, un primo tentativo

Si tratta di una versione di prova che poi è stata abbandonata, rimpiazzata

totalmente dall’AJAX. RIA, essendo un modello nuovo nella classe di sviluppo di applicazioni

web, presenta ancora delle problematiche che riguardano principalmente la sicurezza,

l’usabilità, l’ottimizzazione e la navigazione. In seguito verrà fatto un’analisi superficiale di

questo modello evidenziando i suoi punti di forza e debolezza.

Tramite il modello RIA è possibile realizzare applicazioni web il cui comportamento è

molto simile a quello di un’applicazione stand-alone desktop. Ma, il proliferare di

applicazioni di questo genere introduce una serie di aspetti legati a problematiche

tecnologiche, architetturali e anche mentali.

Dal giorno della sua prima definizione9, il termine di Rich Internet Application è

divenuto uno dei più usati e abusati sul web; da allora nuove tecnologie e nuovi modelli di

programmazione si sono avvicendati sullo scenario con l’obiettivo, fra le altre cose, di

aumentare la potenza e l’interattività delle GUI delle applicazioni al fine di far sì che la

cosiddetta user experience fosse paragonabile a quella di una comune applicazione desktop.

Probabilmente l’invenzione di Ajax (meglio chiamarla "la scoperta") ha rappresentato

l’impulso principale per la diffusione di sempre nuove e migliori tecnologie dall’interfaccia

ricca.

Un’applicazione RIA è spesso più “bella da vedere”, più ricca, più intuitiva da usare,

in breve è un’applicazione migliore. Le RIA si caratterizzano per la dimensione interattiva, la

multimedialità e per la velocità d'esecuzione. Infatti, la parte dell'applicazione che elabora i

dati è trasferita a livello client e fornisce una pronta risposta all'interfaccia utente, mentre la

gran parte dei dati e dell'applicazione rimane sul server remoto, con notevole

9 “Le Rich Internet Application (RIA) sono applicazioni web che possiedono le caratteristiche e

le funzionalità delle applicazioni desktop, senza però necessitare dell'installazione sul disco fisso.” – Macromedia, 2002

L

alleggerimento per il computer utente. Le RIA si fondano perciò su un'architettura di tipo

distribuito.

Il set di funzionalità e delle caratteristiche che un’applicazione Rich dovrebbe avere:

applicazione client side

browser embedded

modello a eventi sulla GUI

asincronia delle invocazioni server-side

rich user interface

Figura 13: RIA secondo Macromedia

È bene ricordare che il modello RIA si differenzia molto da quello a pagine e che

alcuni aspetti dello sviluppo di applicazioni per il web rappresentano ancora delle importanti

limitazioni:

Single Page Interface Page Flow

Viene eseguita all’interno del browser e interagisce in modo dinamico con il sistema tramite la proposizione di una GUI ricca di componenti e comportamenti (State Oriented)

Una serie di pagine HTML, ogni pagina rappresenta una vista parziale del sistema nel suo complesso e la visione completa si ha solo grazie alla navigazione ipertestuale pagina dopo pagina. (Page Oriented)

Stateful Stateless

L’applicazione vive nella pagina e con la pagina: non è legata alla cronologia del browser.

Ogni pagina ha il suo ciclo di vita

Ricchezza della GUI e la capacità di interagire con l’utente senza la necessità di ricaricare la pagina per ogni click o azione dell'utente

Il problema dell’User eXperience viene risolto parzialmente con la scoperta dell’AJAX.

Installazione di software aggiuntivo o plug-in oltre al browser

All’utente basta il browser, ed eventualmente script-enabled per AJAX.

Una parte della logica viene spedita al client -> più veloce.

Tutta la logica risiede nel server

Difficile / impossibile permettere il segnalibro di un determinato stato dell’applicazione.

Non ci sono problemi

una rich application difficilmente può essere scandagliata da un crawler di un motore di ricerca.

Non ci sono problemi

Eseguire un’app. remotamente fa nascere I problemi di sicurezza ci sono, ma di un

39

una serie di problematiche tipiche di attacchi "Man in the middle" o "JS-Injection”.

grado meno elevato paragonato con SPI.

OOP vero e proprio Fastidio dallo scripting e tag o custom tag in parte proprietari

UI Definition ancora giovane Templating e UI Definition rapido

La gestione delle singole risorse è meno semplice.

La gestione e il controllo delle singole componenti (pagine o business objects per le applicazioni tradizionali, così come pannelli, window dialog per le RIA) risulta più dettagliatamente definibile.

Figura 14: La versione RIA del progetto

In conclusione si può dire che le applicazioni RIA sono migliori per quanto concerne

la modalità di utilizzo da parte dell’utente e per alcuni aspetti implementativi. L’utilizzo di

queste applicazioni porta con sé alcune problematiche spesso derivanti dal fatto che per

anni siamo stati abituati a ragionare con applicazioni a pagine, che funzionano come

macchine a stati per le quali sono state inventate trucchi e barbatrucchi per risolvere i

problemi di questo modello. Tali soluzioni non funzionano con il modello RIA:

probabilmente è il modello stesso che se affrontato con una mentalità a pagine si troverà in

difficoltà. Non è illogico pensare che, cambiando approccio (da page oriented a state

oriented), spariranno molti dei problemi per i quali le soluzioni derivanti dal modello web

non funzionano con l’approccio rich.

Alcune problematiche restano, in effetti, poco gestibili nel modello rich per cui c’è da

attendersi che presto verranno rese disponibili soluzioni ufficiali e integrate.

4.2 Persistenza di dati

Introduzione

Rimane in sospeso un problema molto sentito, ovvero come memorizzare gli oggetti

su disco e come recuperarli. Questo problema, che viene in genere detto di "persistenza dei

dati", è di soluzione tutt'altro che immediata, e può essere affrontato a due differenti livelli:

1. Utilizzando un database orientato agli oggetti. In questo caso, la persistenza degli

oggetti è garantita dal database stesso. I database object oriented sono relativamente

nuovi, e non vi sono molti prodotti commerciali disponibili. In ogni caso, esistono sia

prodotti stand-alone (equiparabili a un tradizionale package con funzionalità di

database) sia librerie che possono essere utilizzate con linguaggi tradizionali.

2. Implementando una soluzione all'interno di un normale linguaggio object oriented.

Quindi dovremo in genere definire manualmente, per ogni classe, alcuni metodi che si

occuperanno della gestione specifica dei nostri dati.

Uno dei metodi per rappresentare gli oggetti è quello di far riferimento al modello

relazionale; in questo caso, è molto vantaggioso sfruttare una delle tante librerie esistenti

per la gestione relazionale dei dati. Di norma, ciò richiederà comunque la creazione di

alcune classi "adattatore" che isolino la visione relazionale (verso il database) e quella

orientata agli oggetti (verso i clienti della classe). Può comunque essere una scelta

vantaggiosa in numerosi casi, ad esempio quando esistano esigenze di condivisione con una

base dati esistente (come nel caso trattato in questo elaborato) o d’interoperabilità con altri

prodotti basati sul modello relazionale.

4.2.1 Data first vs. Model first

Alcune persone trovano l'atto di categorizzazione e di astrazione naturale e

gratificante, altri trovano frustrante e inutile. Il problema con le tecnologie dell'informazione

è che i programmatori di computer sono suscettibili di rientrare nella prima categoria e gli

utilizzatori di tali programmi sono suscettibili di cadere in un secondo.

Ad esempio, il file system. I file e le cartelle sono concetti che sono stati inventati da

persone che hanno gestito le tonnellate d’informazioni su carta e, per questo, gli piaceva la

categorizzazione e l’astrazione ... agli utenti normali non lo fanno! Guardate la vettura,

41

scrivania, sala, ripostiglio ... sono tutte perfettamente ordinate e strutturate, etichettati e

ben categorizzate? Se è più facile / più veloce per trovare qualcosa in otto miliardi di pagine

del web che nella tua raccolta di 100 mila file (inclusi documenti, mail, immagini, ecc.), c'è

qualche problema.

Un altro esempio è il paragone tra i fogli di calcolo contro basi di dati. Entrambi sono

basati su tabelle, righe essendo gli elementi, le colonne sono i loro attributi. Entrambe

permettono le relazioni. Fogli di calcolo (non basi di dati!) sono stati i motivi per cui la gente

ha speso $ 10K su un personal computer nei primi anni 80.

E se vogliamo ancora un altro esempio: i blog vs CMS. E gli esempi non finiscono se

vogliamo continuare. Tutti questi esempi sono elencati solo per illustrare che la strategia

“Data First” ha un'efficienza e usabilità superiore (a parità di tutte le altre) che la strategia

“Model First”.

Le ragioni non sono così evidenti:

I. Data First è come imparare le lingue e di come si evolvono. Costruiamo regole,

modelli, astrazioni e categorie nella nostra mente dopo aver raccolto informazioni,

non prima. Per questo motivo è più facile imparare un linguaggio di programmazione

da esempi che dalla sua teoria, o una lingua naturale da solo di essere esposti a esso,

invece di conoscere tutte le regole ed eccezioni.

II. Data First è più reversibile in modo incrementale, la complessità del sistema è

aggiunta in modo più graduale, ed è più facilmente tornare indietro.

III. A quanto detto sopra, il ritorno del capitale investito (ROI) del Data First è più

immediatamente percepibile.

Quindi, nella situazione che il modello dei dati cambia poco o niente nell’arco del tempo

sarebbe più opportuno scegliere questa strategia.

4.2.2 ORM

Il passo successivo è sfruttarsi il vantaggio di un framework Object-Relational

Mapping, ovvero una libreria in grado di mappare oggetti su Database Relazionali e

viceversa (ORM è una tecnica di programmazione10 che favorisce l'integrazione di sistemi

software aderenti al paradigma della programmazione orientata agli oggetti con sistemi

RDBMS). L'uso di un ORM favorisce il raggiungimento di più alti standard qualitativi

software, migliorando in particolare le caratteristiche di correttezza, manutenibilità,

evolvibilità e portabilità. Un prodotto ORM fornisce, mediante un'interfaccia orientata agli

10

In pratica un ORM implementa il pattern Data Mapper ed è in grado di gestire la persistenza di oggetti, termine che indica genericamente l'operazione di salvataggio dello stato dell'oggetto su un supporto stabile. (Martin Fowler - Patterns of Enterprise Application Architecture)

oggetti, tutti i servizi inerenti alla persistenza dei dati, astraendo nello stesso tempo le

caratteristiche implementative dello specifico RDBMS utilizzato.

I principali vantaggi nell'uso di un tale sistema sono i seguenti.

Il superamento (più o meno completo) dell'incompatibilità di fondo tra il progetto

orientato agli oggetti ed il modello relazionale sul quale è basata la maggior parte

degli attuali RDBMS utilizzati; con una metafora legata al mondo dell'elettrotecnica,

si parla in questo caso di disadattamento dell'impedenza tra paradigma relazionale e

ad - oggetti (object/relational impedance mismatch).

Un'elevata portabilità rispetto alla tecnologia DBMS utilizzata: cambiando DBMS non

devono essere riscritte le routine che implementano lo strato di persistenza;

generalmente basta cambiare poche righe nella configurazione del prodotto per

l'ORM utilizzato.

Rilevante riduzione della quantità di codice da redigere; l'ORM maschera dietro

semplici comandi le complesse attività di creazione, prelievo, aggiornamento ed

eliminazione dei dati (dette CRUD - Create, Read, Update, Delete). Tali attività

occupano di solito una buona percentuale del tempo di stesura, testing e

manutenzione complessiva. Inoltre, sono per loro natura molto ripetitive e, dunque,

favoriscono la possibilità che vengano commessi errori durante la stesura del codice

che le implementa.

Suggerisce la realizzazione dell'architettura di un sistema software mediante

approccio stratificato, tendendo pertanto a isolare in un solo livello la logica di

persistenza dei dati, a vantaggio della modularità complessiva del sistema.

Si è scelto il prodotto della casa Microsoft, l’Entity Framework11, il quale usa LINQ

come linguaggio di query (una descrizione più ampia è stata data nella sezione 3.4.5). Il

framework offre nativamente funzionalità che altrimenti andrebbero realizzate

manualmente dal programmatore. Per citarne alcune:

Caricamento automatico del grafo degli oggetti secondo i legami d'associazione

definiti a livello di linguaggio. Il caricamento di un'ipotetica istanza della classe

Utente, potrebbe automaticamente produrre il caricamento dei dati collegati sui

Reagenti in prestito. Tale caricamento, in più, può avvenire solo se il dato è

effettivamente richiesto dal programma, ed è altrimenti evitato (tecnica nota con il

nome di lazy-initialization).

11

Da non scartare anche NHibernate; un’alternativa valida del EF e abbastanza completa, ma supportata pochissimo dal IDE VisualStudio

43

Gestione della concorrenza nell'accesso ai dati durante conversazioni. Conflitti

durante la modifica di un dato da parte di più utenti in contemporanea, possono

essere automaticamente rilevati dal sistema ORM.

Meccanismi di caching dei dati. Per esempio, se accade che uno stesso dato sia

prelevato più volte dal RDBMS, il sistema ORM può fornire automaticamente un

supporto al caching che migliori le prestazioni dell'applicazione e riduca il carico sul

sistema DBMS.

Gestione di una conversazione mediante uso del design pattern Unit of Work, che

ritarda tutte le azioni di aggiornamento dei dati al momento della chiusura della

conversazione; in questo modo le richieste inviate al RDBMS sono quelle

strettamente indispensabili (per es. viene eseguita solo l'ultima di una serie di

aggiornamenti su uno stesso dato, oppure non viene eseguita affatto una serie di

aggiornamenti su di un dato che in seguito viene eliminato); inoltre il colloquio con il

DBMS avviene mediante composizione di query multiple in un unico statement,

limitando così al minimo il numero di round-trip-time richiesti e, conseguentemente,

i tempi di risposta dell'applicazione.

La mappatura 1-1 tra le tabelle, viste e stored procedure con le classi di tipo business

objects. Tale operazione permette al programmatore di eseguire tutte le operazioni

su oggetti senza aver la minima idea dello schema del database, né del linguaggio

d’interrogazione SQL. Quest’approccio separa due profili nettamente distinti.

Conclusioni

Ancora una volta, il passaggio al paradigma object oriented non significa il rifiuto dei

concetti già consolidati in altri settori dell'informatica: in particolare, il trattamento dei dati

e delle relazioni ha molto in comune, ma anche grandi punti di distacco, con il modello

relazionale. Non è raro che esperti di diverso calibro affermino che il paradigma object

oriented rappresenta una totale rottura con il passato, e che conoscenze precedenti

possono essere controproducenti nella transizione ai nuovi schemi di pensiero: mentre ciò

può essere vero per alcune tecniche di programmazione a basso livello, spesso le

conoscenze acquisite in campi più astratti, non solo non sono d’impaccio, ma costituiscono

anche un utile strumento per la comprensione e la progettazione dei sistemi.

4.3 Logica funzionale

Con il termine Business Logic ci si riferisce a tutta quella logica applicativa che rende

operativa un'applicazione. E’ un termine non-tecnico generalmente usato per descrivere le

funzionalità degli algoritmi che gestiscono lo scambio d’informazioni tra un database e

un’interfaccia utente. Il business logic racchiude in sé regole cosiddette di "business",

piuttosto che regole ed elementi legati alla visualizzazione delle informazioni (interfaccia

grafica) o alla memorizzazione dei dati (es. database, repository, cloud storage, ecc.).

È un termine largamente utilizzato nella progettazione del software per individuare

un componente software, un layer (o tier, cioè livello) di un’architettura software, ecc. Il

business logic è spesso associato ad architetture software di tipo a tre strati.

4.3.1 Ambito di applicazione della logica di business

Logica di business:

modella la vita reale di Business Objects (come i conti, prestito, itinerari e scorte.)

prescrive come gli oggetti di business interagiscono tra loro.

applica i percorsi e le modalità con cui gli oggetti di business sono accessibili e

aggiornati.

La logica di business è costituita da:

regole di business che esprimono la politica commerciale (come i canali, l'ubicazione,

la logistica, i prezzi e prodotti);

flussi di lavoro che sono i compiti ordinati di passare documenti o dati da un

partecipante (una persona o di un sistema software) a un altro.

4.3.2 Posizione della logica di funzionale (Business Logic)

Nelle applicazioni a livello singolo, la logica di business, la logica di presentazione e il

CRUD sono spesso utilizzati, con ognuna di avere la massima conoscenza, o di essere

fortemente accoppiato agli altri. Questo viene visto come problematico, poiché le modifiche

a un risultato richiedono nuove prove alla convalida di tutto il sistema per un singolo

cambiamento. L'intreccio limita anche la misura in cui il CRUD e la logica di business

possono essere riutilizzati.

In un’architettura multistrato (a fronte di architettura multilivello) la logica di

business è un modulo separato. Nell'architettura comune 3-tier, la logica di business, in

teoria, occupa lo strato del livello intermedio, il livello dei servizi di business o di lavoro. In

pratica, la logica aziendale è spesso intrecciata negli altri due livelli (il livello di servizi per gli

utenti e il livello di servizi di database), come da logica di business di codifica in stored

procedure e nelle decisioni sulla convalida d’input e la formattazione del display. Tuttavia

non c'è una regola ben definita.

45

Nel sistema costruito la logica è sparsa sia sulle stored procedure sia sullo strato

della logica. Infatti, per le regole assai complicate è di buone prassi di incapsularle sulle SP,

mentre per le altre operazioni quotidiane (specialmente nell’uso del pattern Master-Detail)

si può permettere piazzarle sullo strato della logica. Questo strato fa uso dei Domain

Services. Per illustrarlo, diamo un semplice esempio:

//----------------Prestito & Restituzione------------------------------

public int ExecPrestito(int IDReagente, double quantita, string username, int locazione) { return this.ObjectContext.spPrestito(IDReagente, quantita, username, locazione); } public int ExecRestituzione(int IDPrelievo, int IDLocazione) { return this.ObjectContext.spRestituzione(IDPrelievo, IDLocazione); }

Sono due funzioni implementate per il reso/prelievo di reagenti. Risiedono dentro la classe class ResoPrelievoDomainService : LinqToEntitiesDomainService<DB_DipartimentoEntities>

Prendono i parametri d’input e li restituiscono alle stored procedure corrispondenti, le quali

vengono chiamate dall’Entity Framework. Come si vede, con poche righe si gestisce la

persistenza senza preoccuparsene dell’apertura/chiusura della connessione DB oppure di

costruire comandi SQL. Infatti, l’ORM fa l’astrazione del database e restituisce al

programmatore il relativo modello a oggetti.

In seguito sarà approfondito in dettaglio il pattern della logica applicativa.

4.3.3 Il pattern DomainService

I servizi di dominio sono i servizi WCF che incapsulano la logica di business di

un'applicazione. Un servizio di dominio espone una serie di operazioni correlate, sotto

forma di un livello di servizio. Quando si definisce un servizio di dominio, si specificano le

operazioni dati che sono consentiti attraverso il servizio di dominio.

Microsoft. NET RIA Services semplifica il tradizionale modello di applicazione n-tier,

riunendo le piattaforme ASP.NET e Silverlight. RIA Services fornisce uno schema per scrivere

la logica di un’applicazione che si esegue sul middle tier e controlla l'accesso ai dati per le

query, modifiche e operazioni su misura. Fornisce anche supporto end-to-end per le attività

comuni come la validazione dei dati, l'autenticazione e ruoli grazie all'integrazione con

componenti sul client Silverlight e ASP.NET sullo strato intermedio (della logica).

Quando si progetta un servizio di dominio, si dovrebbe pensare come un insieme di

attività correlate che si prevede agli utenti di eseguire nell'applicazione. Tipicamente, le

attività interessate riguardano un piccolo gruppo di soggetti strettamente connessi. Per

esempio, in una domanda di registrazione degli ordini, si potrebbe esporre gli enti per i noti

ordini, voci e dettagli. Si potrebbe piazzare le entità per i conti e i pagamenti in un servizio di

dominio separato.

Un pattern scalabile12

Ci sono troppe cose che sono non-naturale. La norma, a partire dalla forzata n-tier

(molti sviluppatori sono abituati per scrivere applicazioni 2-tier), asincrona (quando Sync è la

norma), si occupano di latenza (così facendo in modo non corretto ha le potenzialità per

rompere l'esperienza dell'utente finale), cercando di capire come essere meno loquace, si

occupano di convalida, i conflitti, scenari disconnessi o connessi occasionalmente, di

eseguire l'autenticazione dell'utente e lo stato di condivisione tra client e server. L'elenco

potrebbe continuare all'infinito...

Il modello DomainService per scrivere la logica dell'applicazione stessa non è limitato al solo RIA scritte in Silverlight di connessione ad alcuni database relazionali nel retroscena. Questa è una sola fetta di una storia più grande (vedi Figura 1Figura 15).

Figura 15: Domain Services, un pattern scalabile

Il modello DomainService può funzionare contro una vasta varietà di fonti di dati.

Dall'altro lato, abbiamo Silverlight e WPF che rappresenta una parte della storia .NET TO

.NET. Tuttavia, l'infrastruttura in cima di DomainService parla in modo aperto / standard /

RESTful. Come tali script / client AJAX che utilizzano qualsiasi framework Ajax possono

12

Nikhil Kothari - .NET RIA Services: From Vision to Architecture

47

funzionare (interagire) con il livello intermedio. Le applicazioni server-side di rendering

basato su Web Form o usando MVC possono fare uso della logica dell'applicazione stessa. E,

infine, per i clienti non UI, come altre applicazioni, si può costruire un livello di servizi per

proiettare i dati e le operazioni tramite un’interfaccia SOAP o REST.

Riepilogo

Come già visto sopra, si abbia una tecnologia molto adattabile costruita su blocchi di costruzione che possono essere sostituiti. Si tratta di un pattern scalabile che va al di là delle semplici operazioni CRUD. Alcune caratteristiche sono:

CRUD

Sicurezza (Require Authentication / Authorization / SSLEncryption)

Incapsulamento del Business Logic

Paginazione / Raggruppamento / Filtro sui dati

Validazione dei dati d’input

UnitTest Code

Queries Parallelizabili

4.3.4 Autenticazione/Autorizzazione

In ASP.NET si può utilizzare uno dei seguenti provider di autenticazione: Windows,

Passport e Forms. E’ stata scelta quest’ultima, ma si potrebbe cambiare facilmente

modificando semplicemente il file di configurazione del sito “web.config”.

L’autenticazione basata su Form (chiamata anche autenticazione basata su cookie)

sfrutta un sistema che reindirizza le richieste non autenticate a un form HTML

(personalizzabile) usando il reindirizzamento http client. L'utente che viene indirizzato su

questo form fornisce le credenziali per l'accesso (username e password) e invia il form. Se

l'applicazione autentica la richiesta, viene creato un cookie criptato che contiene le

credenziali dell'utente e informazioni aggiuntive (per esempio i ruoli in questo caso), o una

chiave (ticket) per riacquisire le credenziali. Il browser rinvia questo cookie a ogni richiesta e

l'utente può accedere alle applicazioni, poiché le richieste conservano questo cookie.

In seguito verrà spiegato brevemente il flusso delle richieste – risposte che

avvengono durante l’autenticazione basata su Form.

Figura 16: La sequenza degli eventi durante l'autenticazione con Form

1. L'utente richiede il file Default.aspx

dalla directory virtuale

dell'applicazione. IIS consente la

richiesta giacché l'accesso anonimo è

attivato nella metabase di IIS. ASP.NET

conferma che l'elemento di

autorizzazione comprende un tag

<negare agli utenti = "?" / >.

2. Il server cerca un cookie di autenticazione. Se non riesce a trovare il cookie di autenticazione, l'utente viene reindirizzato alla pagina di accesso configurato (Login.aspx), come specificato dal loginUrl dell'elemento form. L'utente invia le credenziali attraverso questo form. Informazioni sulla pagina di origine viene inserito nella stringa di query utilizzando RETURNURL come chiave. La risposta del server HTTP è la seguente: 302 Found Location: http://localhost/FormsAuthTest/login.aspx?RETURNURL=%2fFormAuthTest%2fDefault.aspx

3. Il browser richiede la pagina Login.aspx e comprende il RETURNURL parametro nella stringa di query.

4. Il server restituisce la pagina di accesso e il 200 OK codice di stato HTTP.

5. L'utente inserisce le credenziali nella pagina di accesso e posti nella pagina, compreso il RETURNURL parametro dalla stringa di query, di nuovo al server.

6. Il server convalida le credenziali dell’utente rispetto a un archivio, come ad esempio un database SQL Server o di un utente Active Directory. Il codice nella pagina di accesso crea un cookie che contiene un ticket di autenticazione form che si trova per la sessione.

7. Per l'utente autenticato, il server reindirizza il browser all'URL originale che è stato specificato nella stringa di query dal RETURNURL parametro. La risposta del server HTTP è la seguente: 302 Found Location: http://localhost/TestSample/default.aspx

8. Dopo il reindirizzamento, il browser richiede la pagina Default.aspx di nuovo. Questa richiesta comprende il cookie di autenticazione.

9. La classe FormsAuthenticationModule rileva il cookie di autenticazione moduli e autentica l'utente. Dopo l'autenticazione con successo, la classe FormsAuthenticationModule popola la proprietà dell'utente corrente, che è esposta dall'oggetto HttpContext, con informazioni circa l'utente autenticato.

10. Poiché il server ha verificato il cookie di autenticazione, si concede l'accesso e restituisce la pagina Default.aspx.

49

Nel punto 6 il server può inserire nel cookie (che per altro è crittato) anche i ruoli

associati all’utente. Cosi facendo, oltre a proteggere le pagine dagli utenti anonimi, si limita

la vista delle pagine dedicate ai particolari gruppi o utenti. Per maggiori dettagli

sull’implementazione si consiglia di leggere13 la guida di Microsoft.

4.3.5 Flusso Nuovo Ordine

Le operazioni via codice di un nuovo ordine implementate, seguono la successione e

la logica descritti nel seguente schema a blocchi:

Figura 17: Lo schema a blocchi dell'operazione di un nuovo ordine

4.4 Interfaccia Utente (UI)

L’interfaccia Utente, ovvero i meccanismi che producono l’HTML per l’utente finale,

è realizzata mediante i Web Forms e i DynamicData. Un approccio migliore sarebbe stato

svolgendo con il pattern MVC (o uno dei suoi derivati), comunque, essendo incapsulata la

logica sulle Stored Procedures e sullo strato di Business Logic (DomainService per

l’esattezza) non si otterrebbe qualche vantaggio esaltante. Tra l’altro, sui Web Forms sono

stati aggiunti vari componenti AJAX-like per aumentare la cosiddetta UserExperience e

comunicare con il server in modo asincrono. In generale è stato scelto di proseguire con lo

sviluppo del tipo “1 caso d’uso – 1 pagina”.

E’ stato scelto di usare il Dynamic Data per le funzionalità semplici come la

visualizzazione di cataloghi (sostanze, reagenti, frasi di R/S) e le operazioni di manutenzione

13

ASP.NET Forms Authentication : http://msdn.microsoft.com/en-us/library/Aa302399

(add new, update, delete) da parte di un amministratore, mentre per i casi d’uso più

laboriosi è stato deciso di implementarli con i Web Forms.

In seguito saranno introdotte queste tecnologie (i paragrafi 4.4.1 e 4.4.2), nonché

verranno mostrati le funzionalità principali (il paragrafo 4.4.3).

4.4.1 Dynamic Data Control

Come si è già anticipato nella 3.4.4, il DDC viene all’aiuto del programmatore quando

si abbia a confronto un’applicazione molto orientata al livello di dati, o delle tabelle del

database. L'infrastruttura che gli sta dietro è molto interessante, perché consente di fare

tutto sfruttando l'object model, che d'altra parte è auto referenziante in quanto al tipo di

dato, alle regole che deve rispettare per la validazione e, dal punto di vista di Entity

Framework, anche della strategia di persistenza.

Sebbene i wizard14 siano comodi in certi scenari, siano anche la cosa peggiore che

uno sviluppatore può trovare, perché spesso gli fanno spegnere il cervello. Tutto ciò

premesso, DDC non è solo un insieme di griglie e controlli di dettaglio, ma anche e

soprattutto un'infrastruttura dedicata allo scopo di visualizzare informazioni e gestirne la

modifica in un'ottica di "mi stresso poco e ottengo il massimo perché ho già il mio modello

di dati pronto". Per esempio l'accoppiata DynamicControl e DynamicField fa egregiamente il

lavoro di consentire l'utilizzo in una normale GridView/DetailsView/FormView, demandando

ad una serie di template separati la possibilità di avere un solo template da visualizzare in

baso al tipo di informazioni, il che consente di risparmiare un bel po' di markup ripetitivo da

scrivere e con pieno supporto per il databinding15 bidirezionale.

Poi è ovvio che con l'URL Routing e DynamiDataManager siano già pronte gran parte

delle funzionalità per farsi un sistema di gestione delle entity con relativa persistenza, ma da

qui a fare di DDC un insieme di "cose" fatte con un wizard ce ne passa.

Instradamento delle richieste mediante Routing

In applicazioni dal contenuto dinamico è frequente l'uso di parametri inseriti in

querystring per caricare informazioni e generare pagine per ogni specifica richiesta. È il

metodo più semplice, per esempio, per indicare il prodotto da caricare in una pagina di

14

il wizard indica una procedura informatica(solitamente procedure predisposte per utenti inesperti), generalmente inglobata in un’applicazione più complessa, che permette all'utente di eseguire determinate operazioni (solitamente complesse) tramite una serie di passi successivi. deriva dall’inglese e significa mago 15

Il Data Binding consente di legare un controllo ad una sorgente dati, riducendo la quantità di codice richiesta.

51

dettaglio, perché tale parametro si può leggere tramite Request.QueryString o un

QueryStringParameter da associare ai controlli data source.

Per rendere però più comprensibile l'URL si tende a evitare l'uso di querystring,

sfruttando il percorso stesso dell'indirizzo per inserire parametri (come gli ID) e descrizioni o

titoli che permettono all'utente di capire cosa la pagina contiene, oltre a permettere una

migliore indicizzazione da parte dei motori di ricerca.

Per realizzare questa funzionalità con ASP.NET si usa una tecnica chiamata URL

rewriting, che consiste, solitamente tramite HttpModule, nel riscrivere l'indirizzo richiesto

dall'utente mappandolo su HttpHandler, dove normali pagine, estrapolando dall'indirizzo i

parametri e passandoli con varie tecniche, solitamente facendo sempre uso di querystring.

A partire da ASP.NET 2.0 è consentito mappare un indirizzo su un altro in modo molto

semplice, tramite la sezione system.web/urlMapping, come mostrato nell'esempio

seguente:

<urlMappings enabled="true">

<add url= "~/Sostanza1.aspx"

mappedUrl="~/ Sostanze.aspx? SostanzaID=1"/>

</urlMappings>

Questa sezione purtroppo è abbastanza limitata e non permette scenari più

complessi dove sono richieste la validazione dei valori predefiniti o l'uso di HttpHandler,

costringendo lo sviluppatore alla creazione di un HttpModule personalizzato che implementi

la logica specifica.

A partire da ASP.NET 3.5 SP1 è presente un nuovo assembly System.Web.Routing,

per facilitare questi scenari, che contiene principalmente un modulo per l'instradamento

delle richieste. Sebbene possa sembrare un rimpiazzamento del mapping degli URL, in realtà

è qualcosa di più evoluto che non si limita alla semplice riscrittura dell'indirizzo, ma

reimposta l'HttpHandler che prende in carico la richiesta. Tra URL rewritng e URL routing c'è

quindi molta differenza ed è bene tenerlo a mente, sebbene il risultato sia spesso simile.

Innanzitutto per sfruttare questa nuova caratteristica è necessario referenziare il

nuovo assembly e configurare nel web.config il modulo, come mostrato nell'esempio

seguente:

<httpModules>

<add name="UrlRoutingModule"

type="System.Web.Routing.UrlRoutingModule,

System.Web.Routing, Version=4.0.0, Culture=neutral,

PublicKeyToken=31BF3856AD364E35"/>

</httpModules>

Il modulo appena aggiunto intercetta tutte le richieste e utilizza una tabella,

accessibile tramite la proprietà statica RouteTable.Routes, per ottenere la RouteData per

ognuna di esse. La definizione di tale tabella può essere creata o modificata in qualsiasi

momento, ma quello migliore è tipicamente l'avvio dell'applicazione, così da rendere

operativi fin da subito gli instradamenti. La tabella da definire consiste in una coppia

formata dal nome e dalla classe astratta RouteBase, la cui unica implementazione, Route,

ammette un URL e un oggetto di tipo IRouteHandler. Nell'esempio riportato di seguito viene

mostrata una semplice definizione sull'indirizzo Sostanze/{ SostanzaID} così da consentire,

nonostante il percorso sul web server non esista, di poter richiamare uno specifico gestore

per tutti gli indirizzi che seguono il percorso Sostanze seguito dall'ID della Sostanza (per

esempio http://miosito.it/Sostanze/1).

Mediante l'uso delle graffe si ha la possibilità di definire dei segnaposti nominali che

vengono poi passati al gestore come parametri così da poter essere consumati per ogni

specifica esigenza. Ogni segnaposto deve essere separato l'uno dall'altro da una costante,

cioè da un qualsiasi carattere valido per le Uri, così da permettere all'interprete di

individuare i valori. Non è valido quindi un percorso come Sostanze/{action}{SostanzaID},

ma lo è invece uno come Sostanze/{actions}-{SostanzaID}.

void Application_Start(object sender, EventArgs e)

{

RouteTable.Routes.Add("SostanzeRoute",

new Route("Sostanze/{SostanzaID}",

new SostanzeRouteHandler()));

}

Per poter attivare il meccanismo di generazione automatica delle pagine occorre

disporre di un modello di dati sottostante. A tale scopo va creato un DataContext a partire

dallo schema contenente i dati da visualizzare e gestire nel sito.

Nel file Global.asax, nell'event-handler dell'evento OnStart dell'applicazione web,

occorre associare il DataContext all'engine Dynamic Data, impostando il parametro

ScaffoldAllTables al valore true se si desidera che le pagine di visualizzazione e gestione dei

dati vengano generate automaticamente per ciascuna tabella mappata nel DataContext.

Nell'event-handler vanno infine definite le eventuali regole aggiuntive di routing valide per

gli URL.

public static void RegisterRoutes(RouteCollection routes)

{

MetaModel model = new MetaModel();

model.RegisterContext(typeof(DB_DipartimentoDataContext), new

ContextConfiguration() { ScaffoldAllTables = true });

routes.Add(new DynamicDataRoute("{table}/ListDetails.aspx") {

Action = PageAction.List,

ViewName = "ListDetails",

Model = model

});

routes.Add(new DynamicDataRoute("{table}/ListDetails.aspx") {

Action = PageAction.Details,

ViewName = "ListDetails",

Model = model

53

});

}

void Application_Start(object sender, EventArgs e)

{

ContextConfiguration cc = new ContextConfiguration();

// Rendo disponibili tutte le tabelle del DataContext

cc.ScaffoldAllTables = true;

// Registro il DataContext di DB_Dipartimento da utilizzare

model.RegisterContext(typeof(DB_DipartimentoDataContext), cc);

// Registro la tabella di route RegisterRoutes(RouteTable.Routes);

}

A questo punto il gioco è fatto! Nei paragrafi successivi verrà spiegato più in dettaglio la

personalizzazione delle pagine.

Gestione dei dati con dynamic data control

ASP.NET mette a disposizione un buon numero di strumenti e tecnologie per

interrogare, mostrare e modificare i dati. I meccanismi di Databinding consentono di

automatizzare queste operazioni e con il medesimo approccio si possono sfruttare i controlli

data source per popolare controlli come DetailsView o GridView.

Sebbene molto potente come approccio, possa non bastare in certi scenari: occorre

per ogni entità o tabella specificare quali campi mostrare, con quale formato, quali

validazioni compiere, e questa, se l'applicativo è di grosse dimensioni, può diventare

un'operazione molto ripetitiva.

Per semplificare questo scenario, ASP.NET contiene un nuovo assembly di nome

System.Web.DynamicData, che ha lo scopo di rendere più immediate queste operazioni,

automatizzandole in conformità a meta informazioni che si riferiscono a un modello di dati,

che sono mantenuti tramite la classe MetaModel del namespace System.Web.DynamicData.

Questo tipo consente di mantenere una lista di MetaTable, che a loro a volta

contengono una lista di MetaColumn e permettono di conoscere per ogni tabella (da non

considerare solo come tabelle di database, ma anche entità) di quali colonne dispone, se si

possono mostrare, la loro tipologia, se sono obbligatorie, se sono chiavi primarie, la

rispettiva formattazione e la lunghezza massima.

Queste informazioni vengono raccolte a runtime, solitamente all'avvio

dell'applicazione, richiamando il metodo RegisterContext della classe MetaModel e

specificando la tipologia di contesto da analizzare, che può essere un DataContext di LINQ to

SQL piuttosto che un ObjectContext di LINQ to Entities. È comunque possibile passare anche

un oggetto che erediti da DataModelProvider, per supportare qualsiasi tipologia di dato.

La proprietà ScaffoldAllTables permette di indicare se tutte le tabelle individuate

devono essere visibili (letteralmente vuol dire scaffalate), fatta eccezione per le classi

marcate con l'attributo ScaffoldTableAttribute e avente la proprietà Scaffold impostata su

false.

E’ possibile impostare quest’attributo su un file esterno, mediante le classi parziali.

Tale attributo è contenuto nell'assembly System.ComponentModel.DataAnnotations, perciò

è da considerarsi non strettamente legato ai dynamic data control e utilizzabile anche in

altre circostanze, poiché non impatta sulla pulizia del modello a oggetti.

Nel medesimo namespace, inoltre, l'attributo MetadataTypeAttribute consente di

specificare il tipo da utilizzare per la ricerca delle colonne e dei relativi metadati per una

specifica entità. Poiché queste solitamente definiscono delle proprietà e da esse, è possibile

solo dedurne il tipo occorre ampliare queste informazioni definendo una nuova classe che

presenti campi o proprietà con il medesimo nome dell'entità di riferimento (non importa

quale sia il tipo), le quali sono poi marcati con i vari attributi di annotazioni messe a

disposizioni:

ScaffoldColumnAttribute: permette di includere o meno una colonna tra quelle che

vengono generate automaticamente;

DisplayNameAttribute: definisce il nome della colonna o della tabella da usare per le

intestazioni;

DescriptionAttribute: definisce la descrizione della colonna;

DisplayFormatAttribute: definisce la stringa di formattazione del valore per la lettura

e la scrittura;

DataTypeAttribute: definisce il tipo logico per la colonna. Differisce dal tipo .NET

perché più specifico: ad esempio String può essere un normale testo o un testo

multilinea;

UIHintAttribute: definisce il template grafico da adottare per la riproduzione della

colonna.

Con questa tecnica si possono anche definire i criteri di validazione e variare questi

metadati in funzione del front-end che si utilizza, non intaccando il domain model.

[MetadataTypeAttribute(typeof(ProductMetadata))]

public partial class Product { }

[ScaffoldTable(true)]

public class ProductMetadata

{

[ScaffoldColumn(false)]

public object ProductID;

[DisplayFormat(ApplyFormatInEditMode = false,

DataFormatString = "{0:C}",

NullDisplayText = "vuoto")]

public object UnitPrice;

55

[DataType(DataType.Currency)]

public object ReorderLevel;

[UIHint("Slider")]

public object UnitsOnOrder;

}

Campi dinamici con DynamicControl e DynamicField

La dichiarazione dei metadati descritta nei paragrafi precedenti ha lo scopo di automatizzare le operazioni di visualizzazione e modifica dei dati: è a questo punto, infatti, che se ne traggono i benefici.

Il controllo DynamicControl permette di mostrare, in fase di Databinding, una

colonna riguardante il contesto dei dati, creando automaticamente l'interfaccia corretta per

il tipo di colonna e per la modalità di visualizzazione.

Il contesto viene ottenuto tramite l'interfaccia IDynamicDataSource, implementata

dalle classi LinqDataSource ed EntityDataSource. Da questo punto in poi il motore recupera i

relativi MetaModel e MetaTable, in base alla tabella che viene impostata.

Sul DynamicControl quindi non resta altro che specificare con la proprietà DataField

la colonna da utilizzare, mentre con quella Mode la modalità di visualizzazione tra quelle

disponibili: ReadOnly (predefinita), Edit, Insert.

DynamicControl utilizza le informazioni contenute su MetaColumn (ottenute dagli

attributi sulle proprietà) per variare le proprie caratteristiche e applicare automaticamente

la codifica HTML (per evitare XSS), la formattazione, le stringhe da utilizzare per i valori nulli

e l'UIHint, dedotta dal tipo di proprietà, dall'attributo DataType o impostato in maniera

specifica tramite l'attributo UIHint.

Generazione automatica delle maschere

Quanto visto nei paragrafi precedenti è il preludio a tutto ciò che serve per ottenere

il risultato finale: generare automaticamente le maschere.

I metadati, infatti, hanno tutte le informazioni per farlo, dato che contengono

informazioni su quali colonne sono visibili, la loro tipologia e formattazione e le intestazioni

da utilizzare. Ciò che si può fare avendo questi dati è omettere la definizione dei campi,

lasciare attiva la normale auto generazione per i controlli GridView o DetailsView e

omettere i DataKeyNames.

Infine, occorre aggiungere un controllo particolare, di nome DynamicDataManager,

che non emette HTML, ma semplicemente gestisce i controlli di tipo databound, fornendo le

informazioni mancanti.

È, infatti, importante ricordarsi di chiamare il metodo RegisterControl (solitamente

nel Page_Load) passando la griglia o il dettaglio in questione. Questo metodo è in grado di

riconoscere in base all'IDynamicDataSource quale tabella sta caricando, popolando

automaticamente in sua funzione la collezione DataKeyNames con le chiavi primarie e

impostando la proprietà ColumnsGenerator o RowsGenerator, a seconda che sia una

GridView o una DetailsView, con un oggetto IAutoFieldGenerator specifico per i dynamic

data control, che crea le colonne in base ai MetaColumn appartenenti alla MetaTable.

Filtrare le liste dinamiche con i dynamic data control

Nella gestione di database è comune dover ricorrere a filtri da applicare per ricercare

e sfogliare più comodamente le righe. Dato che i controlli LinqDataSource ed

EntityDataSource dispongono della proprietà WhereParameters è teoricamente possibile

eseguire operazioni di filtro. Con tabelle dinamiche, però, non è possibile stabilire a priori

quali colonne filtrare, perciò è stata introdotta una nuova tipologia di Parameter, di nome

DynamicControlParameter, che di fatto non valuta e restituisce i valori ma delega al

DynamicDataManager il compito di sfogliare la collezione WhereParameters degli

IDynamicDataSource, alla ricerca di parametri che implementano l'interfaccia

IWhereParametersProvider, richiamando il metodo GetWhereParameters, ottenendo così

uno o più ControlParameter verso gli effettivi controlli di filtro e rimuovendo il parametro

originale dalla collezione.

La classe DynamicControlParameter ha un'unica proprietà di nome ControlID, che

permette di impostare l'ID del controllo che implementa a sua volta l'interfaccia

IWhereParametersProvider o IControlParameterTarget. La prima è implementata da una

nuova classe chiamata FilterRepeater, una specializzazione di Repeater che carica come lista

di elementi le MetaColumn di tipo ForeignKey o Boolean della MetaTable oggetto della

richiesta. Questo comportamento, peraltro personalizzabile sovrascrivendo il metodo

GetFilteredColumns, permette di definire una zona di filtri, da popolare automaticamente in

funzione della tabella che si sta mostrando. La seconda interfaccia d'altro canto restituisce

l'espressione da utilizzare per recuperare il valore dal controllo di filtro (ad esempio

SelectedValue sulla DropDownList), così da impostarla sui ControlParameter generati in

automatico.

Ogni riga infatti deve contenere un controllo con ID DynamicFilter (o quello

impostato con la proprietà DynamicFilterContainerId sul controllo FilterRepeater), che a sua

volta deve implementare l'interfaccia IControlParameterTarget, la cui unica

57

implementazione è rappresentata dal tipo FilterUserControlBase, un UserControl da

personalizzare che rappresenta il filtro di ogni MetaColumn.

Conclusioni

Il routing è uno strumento semplice, ma che permetta al tempo stesso nuovi scenari

di dinamicità delle pagine, mentre i dynamic data control consentono di generare

facilmente maschere di visualizzazione e modifica orientate alle tabelle, ma allo stesso

tempo concedono di personalizzare molti i loro aspetti.

Inoltre, viene facilitato ancor di più il compito con due tipologie di applicazioni web

basate sui dynamic data control che preparano automaticamente le cartelle con i predefiniti

FieldTemplate e PageTemplate.

4.4.2 ASP.NET AJAX

Il mondo dell'IT è dominato dalle regole del mercato. Seguendo questa legge, è facile

immaginare che ci siano momenti in cui alcune tecniche vanno per la maggiore. Questo è

notevolmente il momento in cui AJAX va per la maggiore.

Uno dei pilastri dell'era del Web 2.0 è AJAX: il mix di tecnologie che ha dato nuova

linfa alle applicazioni online. Naturalmente anche il mondo ASP.NET ne è influenzato, lo

dimostrano i diversi framework nati per supportare questa filosofia di sviluppo; in prima fila

la libreria JQuery16 con la filosofia “Write less, do more”.

Microsoft, dal canto suo, non poteva esimersi dall'implementare uno strumento

"ufficiale" e, a inizio 2006, inizia il progetto di un framework AJAX da poter interfacciare con

ASP.NET. Il nome in codice ATLAS ha accompagnato tutte le release di sviluppo, ma dalla

prima versione stabile il framework prende il nome di ASP.NET AJAX17.

Perché AJAX

Prima di passare al discorso tecnico, è bene spendere un po’ di tempo per capire

perché si ha bisogno di AJAX nelle applicazioni web di oggi e in quelle del futuro. Quando si

deve sviluppare una nuova applicazione, ci si trova davanti ad una scelta: crearne una

Desktop o una Web.

16

http://jquery.com/ 17

http://www.asp.net/ajax

Le applicazioni desktop sono le classiche applicazioni Windows, mentre quelle web

sono quelle a cui si può accedere tramite browser. Le prime hanno il pregio di essere

performanti, siccome girano sulla macchina che le esegue, di offrire un gran livello di

interazione e di essere tendenzialmente più semplici da realizzare. Per contro, queste

applicazioni devono essere installate su ogni macchina con conseguenti problemi di

aggiornamento e manutenzione.

Le applicazioni web superano gli svantaggi di distribuzione da cui sono affette quelle

stand alone(aka desktop) perché devono essere distribuite solo sul server che le esegue, ma

per contro hanno una maggior difficoltà di realizzazione e, soprattutto, un livello di

interazione inferiore rispetto alla controparte. Mentre per le applicazioni desktop il

problema della distribuzione è invalicabile (eccetto che non si tratta di RIA), per quelle web

il problema della lentezza e della bassa interattività può essere risolto. Infatti, al classico

modello richiesta del browser => risposta del server, si può passare a un meccanismo di

richiesta => risposta con il trasporto dei soli dati. Il tutto senza eseguire il refresh completo

della pagina e il conseguente miglioramento dell'usabilità e delle performance. Tutto questo

può accadere grazie all'approccio AJAX.

La logica di funzionamento

La logica comune a tutti i Framework realizzati per AJAX prevede che non vi sia più la

necessità di eseguire dei PostBack della pagina per inviare le richieste al server. Basta inviare

o richiedere le informazioni tramite JavaScript, quindi dai Client.

Le diverse soluzioni sono in grado di realizzare a run-time, quindi durante

l'esecuzione e la creazione della pagina stessa, una sorta di "Proxy", in altre parole un

interprete nascosto che riceve la richiesta dal client, la elabora, attende il risultato e lo

reinvia alla pagina, senza bloccarla durante la fase di attesa.

Figura 18: La struttura di un'applicazione AJAX-enabled

La figura accanto mostra come

avviene una richiesta Server-Side da parte

di un’applicazione basata su AJAX. Viene

effettuata una richiesta al server, che la

elabora prelevando i dati da un database.

I dati risultanti vengono restituiti sotto

forma di file XML che può essere

interpretato e letto direttamente dal

client con opportune routine JavaScript

presenti nella pagina. Come effetto finale

evitiamo il ricaricamento della pagina

stessa.

59

E’ facile immaginare i campi dove AJAX può tornare utile. Ad esempio, si può

paginare e ordinare una griglia, lanciare operazioni sul server a intervalli regolari (Polling),

creare funzioni di Master-Detail, ecc.

A base di tutta la tecnica AJAX rimane sempre la possibilità di colloquiare in

asincrono e senza postback con il server. Il resto non è altro che codice javascript che

interpreta dati inviati dal server, quindi niente di realmente nuovo o rivoluzionario.

4.4.3 Le funzionalità principali

La pagina principale, chiamata Default.aspx (ovvero l’home page del sito), racchiude

in sé il menu nella sua sinistra e un frame per visualizzare tutte le altre pagine che un’utente

vuole aprire nella sua destra. I link mostrati dal menù cambiano dinamicamente in relazione

all'autorizzazione del singolo utente.

Ci sono quattro tipi di utenti previsti: l’utente sconosciuto o “chiunque”, l’operatore

di laboratorio, l’operatore della gestione degli ordini e l’amministratore (ovviamente, si

potrebbero aggiungere altri tipi di utenza per ogni successiva necessità richiesta). Ogni

utente ha accesso all'archivio delle frasi di rischio e sicurezza.

All'apertura dell'applicazione l'utente ha a disposizione il link di consultazione delle

frasi di rischio e sicurezza e il link di reindirizzamento nella sezione di Login/Register.

Figura 19: Home Page

L’elenco delle sostanze chimiche

Questa pagina è dunque accessibile a chiunque nella quale c'è l'elenco di tutte le

sostanze chimiche inserite nel database. Per ogni sostanza sono associate varie informazioni

aggiuntive. Inoltre è possibile filtrare la ricerca inserendo negli appositi posti di ricerca vari

criteri.

Figura 20: Elenco delle sostanze chimiche con le relative frasi di R/S

Figura 21: Un esempio di una pagina con i dettagli concernenti una particolare frase di rischio

Per ogni sostanza vengono

elencate tutte le frasi di rischio e

sicurezza. Come si vede, sono hyperlink

che puntano a una pagina di una frase

specifica. Come esempio è mostrato la

frase rischio R21.

Login / Registrazione

Per identificare e differenziare gli utenti, si rende necessario un meccanismo di

autenticazione e autorizzazione. L'autenticazione è il processo mediante il quale si

ottengono le credenziali dell'utente collegato, quali nome e password; credenziali che

verranno poi validate per il riconoscimento dell'utente e associarlo i ruoli appartenenti.

Inoltre, è stato sviluppato un modulo di registrazione per i nuovi utenti. Dopo la fase

di registrazione si deve aspettare l’attivazione dei ruoli da parte dell’amministratore.

Prelievo / Restituzione

Pagina Prelievo

Descrizione: La pagina contiene l'elenco di tutti i reagenti attualmente disponibili al

prelievo.

61

Precondizione: utente autorizzato (operatore di laboratorio o amministratore)

Funzionalità accessibili:

visualizzazione di tutti i reagenti disponibili al prestito, divisi per sostanza chimica

prelievo di un reagente:

1. (opzionale) filtrare la lista delle sostanze chimiche in base ad una stringa

2. selezionare la sostanza chimica desiderata dalla lista delle sostanze chimiche

3. selezionare il reagente (contenitore) desiderato dalla lista dei reagenti

attualmente disponibili

4. l'utente deve specificare (negli appositi spazi) la quantità che desidera

prelevare e dove riporrà il contenitore scelto

Figura 22: La pagina del prelievo di un reagente

Pagina Restituzione

Descrizione: La pagina contiene una tabella di tutti i reagenti attualmente in prestito

dall'utente. In essa l'utente può restituire un reagente (contenitore).

Precondizione: utente autorizzato (operatore del laboratorio o amministratore)


• visualizzazione di tutti i reagenti in prestito dell'utente, divisi per sostanza chimica

• restituzione reagente:

1. selezionare il reagente (contenitore) desiderato dalla tabella dei reagenti

attualmente in prestito dall'utente

2. l'utente deve specificare dove riporrà o l’ha già riposto il contenitore scelto

Figura 23: La pagina della restituzione di un reagente

Nuovo Ordine / Archivio Ordini

Nuovo Ordine

Descrizione: La pagina contiene un wizard per portare a termine un nuovo ordine.

Precondizione: utente autorizzato (operatore di gestione ordini o amministratore)


Lo scopo di questo modulo è di fornire un’interfaccia user-friendly per facilitare

l’elaborazione del documento dell’ordine e in particolar modo utilizzando una base di dati

per l’archiviazione degli ordinativi. Mediante una procedura inglobata in un’applicazione più

complessa, che permette all'utente di eseguire determinate operazioni tramite una serie di

passi successivi, si prepara il documento riguardante l’ordine. Il documento da elaborare

consisterà in un riepilogo dei dati dell’ordine, in particolar modo l’intestazione del fornitore,

l’elenco dei prodotti da ordinare e altri dati come ad esempio le date di ordine e offerta ecc.

Il primo passo consiste nel riempire i campi che si riferiscono al numero ordine (che

viene suggerito in automatico, che però è modificabile), la data dell’ordine data e/o numero

di offerta (se c’è stata un’offerta), la fattura se richiesta e l’anno dell’esercizio. Quest’ultimo

rappresenta l’anno finanziario corrente, utile per inserire l’ordine all’interno del bilancio

63

annuale. È un campo automatico, anche se potrà essere modificato al momento

dell’inserimento dell’ordine con valori a piacere. In caso di attività commerciali va posto a

fianco del numero dell’ordine (calcolato in automatico ma con possibilità di modifica) la sigla

“LE”, per l’identificazione all’interno del SAP. Per le attività istituzionali é omessa la sigla

“DE” che viene sottointesa.

Figura 24: Nuovo ordine, primo passo

Nel secondo passo sono scelte le estremità: il dipendente in automatico (l’utente

autenticato nel sistema) mentre il fornitore da una lista.

Figura 25: Nuovo ordine, secondo passo

Nel terzo passo bisogna scegliere tra il CDC e Commessa. La commessa è un codice

alfanumerico di otto cifre, scelto arbitrariamente dall’utente per descrivere il tipo di

commessa (utilizzato soprattutto per acquisti per dei fondi di ricerca). Il campo relativo al

centro di costo è alternativo alla commessa e si utilizza in caso di acquisti che interessano

l’intero dipartimento. Vi saranno vari codici per mappare i vari centri di costo (ad esempio

120110 rappresenta un ordine per il dipartimento in generale).

Figura 26: Nuovo ordine, terzo passo

Andando avanti, si compila la lista dei prodotti, scegliendo l’opportuna IVA relativa al

tipo d’acquisto: devono comparire le quantità e le descrizioni delle merci, nonché i prezzi

unitari e l’IVA da applicare all’ordine. Non risulta necessario avere una tabella relativa ai

prodotti, in quanto questi non si ripetono così frequentemente. Particolare attenzione va

prestata all’IVA. Vi sono tre casi possibili: il più frequente è quello in cui il preventivo è

inteso senza IVA. Nell’ordine andrà aggiunta quindi il 20% di IVA. Vi è il caso poi in cui i

preventivi sono già ivati, quindi non è necessario aggiungerla al prezzo del preventivo e

infine si può presentare il caso in cui i preventivi sono senza IVA poiché i prodotti richiesti ne

sono esenti. Proprio in quest’ultimo caso sarà necessario prevedere la possibilità di

escludere dal resoconto dell’ordine sia il codice fiscale sia la partita IVA del dipartimento, in

modo da far capire al fornitore che l’IVA è a suo carico.

65

Figura 27: Nuovo ordine, quarto passo

Il quinto (e l’ultimo) passo offre la possibilità di mandare una coppia dell’ordine al

fornitore tramite mail (il documento preparato sarà spedito come allegato) e stampare

(anteprima stampa) dall’operatore degli ordini.

Figura 28: Nuovo ordine, quinto e l'ultimo passo

Premendo il bottone ‘Esegui Ordine’ viene salvata una coppia del documento in pdf e

una in excel nella cartella prespecificata, oltre al salvataggio sul database.

Archivio Ordini

Descrizione: La pagina contiene una griglia con l’elenco di tutti gli ordini effettuati

con i relativi dettagli, offrendo anche la possibilità di modificare ognuno.

Precondizione: utente autorizzato (operatore di gestione ordini o amministratore.)


Una volta compilato l’ordine questo va salvato in archivio con possibilità di essere

ripreso per visualizzarlo o per modificarlo. E’ possibile interrogare l’archivio sotto vari

parametri. Inoltre è previsto anche un flag per ogni ordine relativo al ricevimento della

relativa fattura.

Figura 29: Archivio degli ordini

Gestione e configurazione

Descrizione: Una raccolta delle pagine di amministrazione del sito

Precondizione: l’utente dev’essere amministratore.


67

Questa sezione contiene una lista delle pagine che offrono la possibilità delle

operazioni di creare, modificare o cancellare le sostanze, i reagenti, gli ordini, gli utenti, i

fornitori e gli scarti. Infine, nella pagina di Scaffolding c’è l’elenco di tutte le tabelle di

database offrendo la possibilità di intervenire direttamente sul database da parte

dell’amministratore (un valore aggiunto del sito, tutto realizzato con l’aiuto di Dynamic Data

Controls analizzato più sopra).

Figura 30: Lo spazio dedicato all'amministratore del sistema.

La tabella più importante nella pagina Scaffolding è sicuramente ‘tblMaster’. È stata

creata per contenere informazioni riguardanti l’applicativo e permettere il corretto

funzionamento. Essa è costituita da un unico record contenente numerosi campi

eterogenei. Sarà cura dell’amministratore compilare correttamente i campi per un

funzionamento corretto del sito.

Conclusioni

llo stato attuale è possibile affermare che gli obiettivi prefissati sono stati

raggiunti. Sono stati soddisfatti i requisiti focali che erano stati individuati

attraverso l’analisi, ovvero la realizzazione di un sistema informativo per

integrare tutte le soluzioni informatiche alle problematiche delle attività indispensabili che

riguardano un dipartimento universitario che:

Sia accessibile a chiunque semplicemente collegandosi a internet e utilizzando il

browser.

Permetta agli operatori dei laboratori di prelevare e restituire le sostanze chimiche

senza la necessità di compilare moduli cartacei.

Classifichi i dati su database in modo che essi siano gestibili per operazioni eventuali

su di essi (ad esempio consultazione del catalogo delle sostanze e le relative frasi di

rischio e/o sicurezza, statistiche che riguardano gli ordini, etc.).

Permetta alla segreteria (o all’operatore di ordini) la gestione e la consultazione

dell’archivio degli ordini e la compilazione in modo più semplice e rapido del

documento necessario alla richiesta delle merci o dei servizi tramite un modulo

apposito.

Manca ancora l’installazione dell'applicazione nel web server e lo spostamento della

base di dati nel DBMS del dipartimento. Dopo una fase di test e collaudo assieme

all’importazione dei dati reali del magazzino, ci sia la possibilità di un immediato utilizzo del

sistema.

Ovviamente il progetto non può considerarsi terminato poiché, come sempre accade

nell’informatica, le possibilità di perfezionamento ed evoluzione sono pressoché infinite.

Oltre a questo, le necessità del dipartimento possono cambiare e/o incrementare con il

passare del tempo. Per questo motivo la progettazione è stata pensata a un sistema

facilmente scalabile e suddiviso in moduli, ognuno dei quali svolge precise funzioni e

distribuiti in maniera tale di intervenire velocemente nella fase di manutenzione.

Sviluppi futuri potranno tenere conto di parametri non considerati in questa tesi, per

migliorare le prestazioni e altri ambiti desiderati. Le possibili evoluzioni del progetto sono

numerose e riguardano vari aspetti. Per citarne qualcuna:

Account utenti

Se questo applicativo dovesse essere utilizzato solo nell’ambito dell’ateneo, sarebbe

opportuno poterlo interfacciare al sistema di gestione degli utenti, che è basato su Active

A

69

Directory; per l’integrazione si utilizzano le API del modello ADSI (Active Directory Service

Interfaces). Nel prototipo non si è ritenuto opportuno farlo per non appesantire

eccessivamente il sistema in fase di test, durante la quale tutte le parti del progetto sono in

esecuzione sullo stesso calcolatore.

In alternativa, l’uso dei protocolli crittografici (SSL o TLS) nella fase di autenticazione

è consigliabile permettendo una comunicazione sicura e un’integrità dei dati. In questo

momento il sistema supporta il protocollo SSL, però bisogna specificare esplicitamente

[Requires SSL] nella logica applicativa.

Firma Digitale

Per rendere il modulo della gestione degli ordini veramente efficiente sarebbe

auspicabile implementare l’algoritmo di firma digitale ai documenti d’ordine inviati ai

fornitori, in modo da dare al documento elettronico ottenuto la validità legale. Pur essendo

presente nell’ateneo un’infrastruttura adatta a questo scopo, non è stato previsto

nell’inserirlo questo dettaglio.

Appendice 1 - Come aggiungere un’altra funzionalità

uest’appendice contiene i passi da seguire per aggiungere altre funzionalità

nel sistema. I requisiti software sono: .NET Framework 4.0, Visual Studio

2010, WCF RIA Services Toolkit, Ajax Extentions e AjaxControlToolkit (le ultime due

non sono obbligatorie, ma consigliabile per aumentare l’User eXperience). Innanzitutto si deve

aggiornare prima la struttura fisica dei dati mettendo nel database del sito le nuove tabelle,

viste, stored procedures, triggers e tutto il resto che riguarda i dati. Dopodiché possiamo

iniziare il lavoro aprendo il progetto con il Visual Studio.

1. Si aggiorna il modello dei dati. Doppio click sul file Model.edmx Viene aperto il

diagramma con tutte le classi che sono mappate con le tabelle del database.

Cliccando con il destro del mouse dentro il diagramma si apre un menù con vari

comandi. Scegliamo ‘Update Model From Database’.

Nella finestra successiva che viene aperta,

possiamo scegliere se aggiungere,

aggiornare o cancellare tabelle, viste o

stored procedure.

Q

71

2. Creare una cartella nuova. Creiamo una cartella nuova (a.e. _MyNewFolder). In essa

saranno piazzate le pagine della nuova funzionalità desiderata. Per il momento ci

limitiamo solo sulla creazione di una pagina di default.

Click con il destro del mouse sopra

la cartella appena creata -> Add ->

New Item. Nella finestra scegliamo

fra i modelli il ‘Web Form Using

MasterPage’, assegniamo il nome

Default.aspx, poi premiamo il

pulsante Add. Nella finestra

successiva scegliamo il master

page (quella che esiste

‘Site.master’ o un’altra) e poi ->OK.

Il risultato è mostrato nella figura

accanto.

Apriamo la pagina appena creata nella modalità design e trasciniamo dentro il controllo

‘SectionLevelListing.ascx’ che si trova in ‘DynamicData- EntityTemplates’.

Questo controllo servirà come un menù basata nella mappa del sito(lo vedremo in

avanti come crearla) per le pagine che saranno messe dentro questa cartella.

3. Proteggere la cartella dagli utenti non autorizzati. Apriamo il file ‘web.config’ e

dentro la voce <configuration> inseriamo la configurazione per la nostra cartella:

<location path="_MyNewFolder">

<system.web>

<authorization>

<allow roles="Admin,Utente,Dipendente" />

<allow users="ledio"/>

<deny users="*" />

</authorization>

</system.web>

</location>

Dal server web questa configurazione viene tradotta come: proteggi questo realm

che si trova nella cartella ‘_MyNewFolder’. Sono autorizzati a vedere i contenuti di

questa cartella i seguenti gruppi "Admin,Utente,Dipendente" e utenti "ledio", tutti

gli altri (deny users="*") non hanno accesso. (ovviamente i gruppi e gli utenti sono

modificabili alla necessità)

4. Routing. Nel caso che volessimo usare i DynamicData possiamo configurare

l’instradamento delle richieste con il controllo di routing che si trova nel file

Global.asax dentro la funzione

public static void RegisterRoutes(RouteCollection routes) { }

Un semplice esempio è il seguente codice per tblSostanzaChimica:

routes.Add(new DynamicDataRoute("Admin/SostanzaChimica/{action}.aspx")

{

Constraints = new RouteValueDictionary(new { action =

"List|Details|Edit|Insert" }),

Model = DefaultModel,

Table = "tblSostanzaChimica"

});

L’URL creato è ovviamente virtuale e, come si vede che esiste sotto la cartella Admin,

viene protetta grazie alla procedura spiegata al punto 3.

5. Sitemap. La mappa del sito è uno strumento molto utile nel caso di un sito web con

numerose pagine. Inoltre, essendo un file XML formattata in modo particolare, può

essere sfruttato come DataSource per creare menù di navigazione di stile treeview,

breadcrumb o custom. Un semplice esempio è mostrato in seguito:

<?xml version="1.0" encoding="utf-8" ?>

<siteMap xmlns="http://schemas.microsoft.com/AspNet/SiteMap-File-1.0" >

<siteMapNode url="~/Default.aspx" title="Home" description="Home" roles="*">

<siteMapNode url="~/_MyNewFolder/Default.aspx" title="La nuova funzionalità"

description=" La nuova funzionalità " roles=" Admin,Utente,Dipendente" >

<siteMapNode url="~/_MyNewFolder/UnaPagina.aspx" title=" UnaPagina"

description=" UnaPagina" roles="Admin,Dipendente" />

<siteMapNode url="~/_MyNewFolder/ UnaPagina2.aspx" title=" UnaPagina2"

description=" UnaPagina2" roles="Admin, Utente" />

</siteMapNode>

</siteMapNode>

</siteMap>

Quindi si conserva la gerarchia del tipo :

73

<siteMapNode url="" title="" description="" />

6. DomainService La logica dell’applicazione viene piazzata dentro questo pattern. Per

creare una nuova logica per la nostra funzionalità si seguono questi passi: Click con la

destra sopra la cartella ‘DomainServices’-> Add ->New Item. Scegliamo dall’elenco

‘Domain Service Class’; attribuiamo un nome (a.e. MyNewFeatureDS.cs). Nella

finestra successiva scegliamo la fonte di dati (in questo caso

‘DB_DipartimentoEntities’), selezioniamo gli oggetti che faranno parte nella logica e

se vogliamo anche la scelta di modifica di essi.

Premendo ‘OK’ sarà generato lo scheletro della nuova classe di BusinessLogic della

nostra funzionalità ed è pronta per usarla o modificarla. In essa possiamo piazzare

oltre alle operazioni di CRUD e logica funzionale, anche validazione, autenticazione

autorizzazione, richiesta di SSL gestione degli errori, etc. Il punto di forza di questa

pattern è l’indipendenza dalla fonte e UI, quindi è facilmente testabile con moduli

UnitTest!

7. Services. Nel caso della necessità di servizi web (consumare o esporre), è stata creata

la cartella ‘Service’ come contenitore, fornendo anche di un semplice esempio di

autocomplete sia nella versione standard POX (Plain Old XML) sia nella versione

WCF.

8. Pages. Questo rappresenterà lo stato d’arte del web designer. Le pagine della

funzionalità dovranno stare dentro la cartella creata nel punto 2. possono utilizzare

dati provenienti dai fonti descritti nei punti 6. & 7. e la logica del DomainService (6.).

Opzionale potrebbe essere l’uso di AJAX, MVC e perfino Silverlight (essendo la logica

incapsulata nella DomainService, questo pattern non distingue tra le applicazioni

web asp.net e quelle RIA Silverlight).

Happy Programming!

75

Ringraziamenti

e non avessi avuto un debito da onorare, e una promessa da mantenere, in

assoluto le singole persone che più di ogni altre avrebbero meritato che

questo lavoro fosse loro dedicato sono certamente i miei genitori e il mio

fratello, cui pure lo dedico per aver aspettato e sopportato così a lungo. Ad essi vanno tutta

la mia stima, il mio rispetto e la mia riconoscenza per il sostegno ed il grande aiuto che mi

hanno dato.

*** *** *** ***

Desidero innanzitutto ringraziare il Professor Maurizio Fermeglia per i preziosi

insegnamenti, per avermi accolto come tesista e indirizzato sempre verso la strada giusta da

intraprendere, e per le numerose ore dedicate alla mia tesi. Inoltre, ringrazio sentitamente il

Professore Alberto Bartoli, un professore ed un amico contemporaneamente. Un saluto va

anche agli altri professori. Non elenco tutti uno per uno perché la lista sarebbe un po’ lunga.

Vorrei ringraziare i miei più stretti amici (scusatemi per l’ordine ed eventuali

involontarie omissioni): Ermal, Deinis ‘Rreku’ & Denis ‘Penis’, Genti ‘Geçe’ , Sai ‘Ricky’, Klajdi

‘KlaKla’, Herald ‘Pislleku’, Ani i Lames, Flor çami, Edjon ‘xhaxhi Edi’; Tati, Mikel, Zak, Eris

Mashtruesi, Jonka, i cugini Hasa, chef Kristi.

S

Bibliografia

J.D. Meier, A. H. (2008) - Web Application Architecture Pocket Guide. Microsoft Corporation.

Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (1995) - Design Patterns:

Elements of Reusable Object-Oriented Software

Martin Fowler (2002) - Patterns of Enterprise Application Architecture

Samo Ziberna - Progetto e sviluppo di un’applicazione per la gestione di un reagentario

Daniele De Gan - Sviluppo di un’applicativo in .NET per la gestione degli ordini ai fornitori di

un dipartimento universitario.

Giovanni Puliti (2010) - Dalle applicazioni web alle RIA, Evoluzione dal modello a pagine alla

Single Page Interface

M. Piraccini, S. Rossini (2006) - Architetture d’Integrazione

Cristian Civera (2008) – Routing e Dynamic Data Control

The Microsoft Developer Network (MSDN)

Progetto e realizzazione di un software in ambiente Web per l’integrazione di applicazioni basato...

Technology

Transcript of Progetto e realizzazione di un software in ambiente Web per l’integrazione di applicazioni basato...