Tesi Corona

Università degli Studi di Trieste
L'INFLUENZA DEL WEB 2.0 IN AMBITO AZIENDALE:

PROGETTAZIONE E SVILUPPO DI UN SISTEMA WIKI
PER LA FORMAZIONE DI UN KNOWLEDGE BASE
Roberto Corona Prof. Maurizio Fermeglia

Indice
Indice...................................................................................................................................................3
1. Introduzione....................................................................................................................................5
1.1 Cenni dell'evoluzione del Web...................................................................................................8
Web 1.0.....................................................................................................................................8
Web 1.5.....................................................................................................................................9
Web 2.0...................................................................................................................................10
I sistemi Wiki.................................................................................................................................12
Wiki in ambito aziendale........................................................................................................12
2. Progettazione dell'applicativo.....................................................................................................13
2.1 Analisi dei Progetti OpenSource..............................................................................................13
2.2 Descrizione dell'applicativo.....................................................................................................16
Tipizzazione delle Pagine.......................................................................................................16
2.3 Progettazione dell'applicativo..................................................................................................19
Architettura Three-Tier..........................................................................................................19
2.4 Progettazione del DB: diagramma Entity-Relationship...........................................................22
Entità e Relazioni...................................................................................................................22
Campi.....................................................................................................................................22
2.5 Progettazione del Data Layer...................................................................................................26
ADO.NET..............................................................................................................................27
2.6 Progettazione della Businness Logic.......................................................................................29
Progettazione delle classi.......................................................................................................30
2.7 Progettazione del Presentation Layer......................................................................................32
Diagramma degli stati applicativi..........................................................................................32
Indirizzi web delle pagine (URL)...........................................................................................34
3. Implementazione logica dell'applicativo....................................................................................35
3.1 Stack dei livelli logici di astrazione.........................................................................................35
3.2 Implementazione logica della base di dati...............................................................................37
Trasformazione del diagramma Entity-Relationship.............................................................37
Tabelle....................................................................................................................................37
Capitolo Indice
Viste........................................................................................................................................40
Indici e Trigger.......................................................................................................................41
3.2 Implementazione del Data Layer.............................................................................................42
Stored Procedures...................................................................................................................42
Struttura delle classi...............................................................................................................45
3.3 Implementazione della Business Logic...................................................................................50
Struttura delle classi...............................................................................................................50
Testo Wiki..............................................................................................................................55
3.4 Implementazione del Presentation Layer.................................................................................66
4. Cenni di porting su un framework aziendale.............................................................................69
4.1 Il framework aziendale............................................................................................................69
Architettura del framework....................................................................................................69
Riusabilità del codice.............................................................................................................72
4.2 Cenni di porting.......................................................................................................................74
5. Conclusione...................................................................................................................................79
Bibliografia........................................................................................................................................83
4
Capitolo 1. Introduzione
1. Introduzione
In questo capitolo introduttivo presenteremo il progetto che si andrà a sviluppare e realizzare in

questa tesi di laurea in modo da darne un punto di vista complessivo. Ci concentreremo sugli obiettivi
che ci si è prefisso di raggiungere mediante questo lavoro, sui vincoli di progetto che lo hanno
influenzato e sullo stato dell'arte in cui andrà a collocarsi.
I sistemi wiki fanno parte del così detto Web 2.0: un nuovo modo di concepire e utilizzare i servizi
Internet sviluppatosi negli ultimi anni che ha portato all'esplosione di fenomeni quali blog, forum,
condivisioni di file, ecc. Questo sviluppo tuttavia non si è limitato al solo ambito ricreativo, ma si è
esteso anche a quello lavorativo aziendale, influenzandolo.
Questa tesi di laurea presenta la progettazione e lo sviluppo di un'applicazione web che, per le
sue caratteristiche, si colloca in questa tematica.
L'esigenza concreta che ha motivato questo lavoro è quella di immigazzinare le informazioni e la

conoscenza in possesso dei dipendenti di un'azienda per evitare che esse vadano perse nel tempo o
con il cambio generazionale degli stessi.
L'obiettivo finale di questa tesi quindi è la realizzazione di un sistema che permetta la formazione
di un data base che contenga tali informazioni (knowledge base), e la possibilità di modificarle e
consultarle.
Tuttavia solitamente queste informazioni sono così frammentate tra i dipendenti da rendere poco
efficente un sistema di gestione delle informazioni centralizzato, ad esempio attraverso i knowledge
leader che lo amministrano. Per questo motivo si è optato per un sistema wiki, che permette di fornire
un sistema di raccolta, gestione e autocorrezione delle informazioni decentralizzato in mano agli stessi
dipendenti.
Come è possibile constatare nella check list delle attività da svolgere riportata di seguito, parte
del lavoro sarà dedicato ad una fase di analisi dello stato dell'arte: soluzioni simili già presenti sul
mercato alle quali quest'applicazione potrà fare riferimento.
Vista la volontà di sviluppare l'applicativo internamente all'azienda committente, si sono presi in
5
considerazione solo i prodotti open source, in modo tale da poterne prendere libero spunto.
La differenza fondamentale tra l'applicazione web che verrà realizzata e le soluzioni già presenti
sul web, consiste nel fatto che queste non forniscono la possibilità di tipizzare le pagine wiki in modo
tale da rispondere a una precisa necessità: far sì che l'inserimento di alcune informazioni siano
necessarie.
Il testo wiki infatti concede agli utenti una libertà totale, che non permette all'azienda di fare in
modo che le informazioni inserite rispondano a dei criteri o a delle norme che possano renderle
esaustive.
L'aggiunta di questa possibilità è ciò che differenzierà questo lavoro da quelli già presenti sul
mercato, e che quindi da ad essa un valore aggiunto.
Per raggiungere l'obiettivo principale si è deciso di proseguire suddividendo la realizzazione del

lavoro in opportuni obiettivi di percorso da perseguire in itinere. Essi sono:
 Analisi del problema con riferimento alla soluzione wiki
 Studio dei sistemi wiki
 Ricerca dei sistemi wiki open source disponibili sul web (stato dell'arte)
 Analisi dei sistemi wiki open source e isolamento delle features principali
 Progettazione del sistema di tipizzazione delle pagine wiki
 Studio delle tecnologie Microsoft ASP.NET
 Progettazione dell'architettura dell'applicazione web (three-tier)
 Progettazione della base di dati (modello Entity-Relationship)
 Progettazione della struttura del sito web
 Implementazione logica della base di dati
 Programmazione del data layer (stored procedures e classi)
 Implementazione di un parser wiki
 Programmazione della logica di inserimento, modifica e cancellazione dati
 Implementazione della logica di tipizzazione delle pagine wiki
 Test dell'applicativo
 Integrazione dell'applicativo con un framework aziendale
6
I vincoli di progetto che sono stati imposti fanno riferimento principalmente alle tecnologie da
utilizzare per la sua realizzazione.
L'implementazione del progetto può essere suddivisa in due parti: il database e il sito web.
Entrambi dovranno essere realizzati mediante l'utilizzo di tecnologie Microsoft, in particolare con la
tecnologia MS Sql Server e con la tecnologia MS ASP.NET.
Per quanto riguarda il database esso verrà realizzato utilizzando Sql Server nella sua versione
Express, mentre la parte realizzata in ASP.NET sarà codificata con Microsoft Visual Studio 2008.
Il linguaggio di programmazione da utilizzare non è stato imposto, e in proposito si è scelto di

utilizzare il linguaggio C#.
Per dare una breve panoramica dei capitoli successivi li presentiamo riassunti qui di seguito, così
da poter avere una guida alla consultazione di questo testo che si presenta anche nella sua funzione di
documentazione dell'applicazione presentata.
Capitolo 1: Questo capitolo introduttivo proseguirà con la descrizione di alcuni cenni

dell'evoluzione del Web, per introdurre con maggior dettaglio il concetto di Web 2.0 e i sistemi wiki
considerati in ambito aziendale.
Capitolo 2: Il secondo capitolo si concentrerà sugli aspetti legati all'analisi e alla

progettazione concettuale dell'applicazione (schemi concettuali, ecc).
Capitolo 3: Il terzo capitolo verterà sull'implementazione vera e propria di quanto è stato

descritto nel capitolo precedente, entrando nei dettagli tecnici di programmazione e codifica.
Capitolo 4: Il capitolo quattro descrive un'esempio di come l'applicativo sia stato

parzialmente integrato in un framework aziendale.
Capitolo 5: L'ultimo capitolo è il capitolo conclusivo della tesi che riporta i risultati ottenuti, la
quantificazione del lavoro svolto, e le ultime considerazioni soggettive.
7
1.1 Cenni dell'evoluzione del Web
Il termine web 2.0 è stato introdotto con lo scopo di descrivere l'evoluzione del world wide web
mediante una terminologia conforme a quella già adottata per il software versioning. Da questo punto di
vista internet, inteso come l'insieme di servizi offerti dalla rete, viene considerato come un'applicazione
a sé stante, che permette all'utente comune un'esperienza d'utilizzo determinata dall'insieme delle sue
features.
Per descrivere l'evoluzione del web in funzione di queste caratteristiche, tra loro molto
eterogenee, le suddivideremo nelle seguenti categorie:
• Reperibilità delle informazioni
• Possibilità di produzione dei contenuti (authoring)
• Possibilità di condivisione dei contenuti (sharing)
• Mezzi di comunicazione
• Sviluppo del social networking, fondazione di community
Web 1.0
Inizialmente le informazioni erano reperibili, da parte dei motori di ricerca, mediante le meta-
informazioni presenti all'interno dei meta tag delle pagine html.
Tali meta-informazioni venivano inserite direttamente dagli sviluppatori web che, essendo
interessati ad aumentare la visibilità delle pagine da parte dei motori di ricerca, inserivano meta-
informazioni generiche e ambigue.
Questo portò a una situazione in cui i motori di ricerca erano imprecisi, e fornivano in risposta
pagine che non esaudivano concretamente le richieste degli utenti.
Per quanto riguarda l'aspetto dell'authoring, l'utente medio non aveva la possibilità di produrre
direttamente contenuti: doveva affidarsi alla mediazione di persone dotate di competenze tecniche, e
quindi anche essere disposto economicamente.
Inoltre, essendo tali contenuti statici, erano anche difficilmente mantenibili soprattutto nel caso in
cui le informazioni erano molte e organizzate su un vasto numero di pagine.
8
La produzione di contenuti, annessa a una prima forma di community, si trovava in germe

nell'uso dei news group che tuttavia potevano vantare una scarsa visibilità, in particolare da parte degli
utenti meno esperti.
Per quanto riguarda i mezzi di comunicazione, l'introduzione della posta elettronica costituì una
vera e propria rivoluzione nella rivoluzione, accompagnata dalle prime forme di chat e servizi di Istant
Messaging.
Web 1.5
Alcune fonti parlano di web 1.5 riferendosi al passaggio dalla creazione di contenuti ipertestuali
statici a contenuti generati dinamicamente. Questo cambiamento non ha avuto delle conseguenze solo
dal punto di vista degli sviluppatori, bensì anche da parte degli utenti stessi i quali hanno ampliato le
loro potenzialità espressive dal punto di vista dell'authoring.
Se prima la mediazione di un professionista era necessaria allora l'utente poteva, disponendo

degli adeguati strumenti offerti dagli sviluppatori, generare contenuti e pubblicarli in tempo reale sul
web, con un conseguente abbattimento dei costi di aggiornamento delle pagine.
Anche dal punto di vista della formazione di community ci furono delle conseguenze importanti.
Tra le maggiori spicca la nascita dei primi forum, che permisero alla già collaudata filosofia dei news
group di uscire dal "ghetto" di usenet e di crescere in popolarità.
E' importante sottolineare che in questo periodo di transizione dal web 1.0 al web 2.0, che durerà
dalla fine degli anni '90 ai primi anni del 2000, si assiste a due fenomeni importanti: il crescente
aumento della banda a disposizione da parte degli utenti (in particolare con l'espansione dei servizi
9
ADSL) e la diminuzione dei costi dei servizi internet in genere.
Nello stesso periodo si moltiplicano i software che permettono il file sharing: a IRC e Usenet si
aggiungono i celebri software peer2peer come Napster, Kazaa, Winmx e eMule.
Web 2.0
Si inizia a parlare di Web 2.0 durante la prima metà degli anni 2000, periodo di tempo in cui
l'espansione della banda larga permette alla maggior parte degli utenti di accedere rapidamente a
contenuti multimediali.
In particolare il fatto che sempre più utenti possano disporre di una connessione "veloce" e
dell'accesso costante a Internet favorisce la trasformazione del modo in cui le applicazioni web
vengono utilizzate e considerate.
Da semplici servizi online, diventano applicazioni complesse in grado, in alcuni casi, di sostituire
persino le loro controparti desktop. Tra gli esempi più ecclatanti spicca Google Docs: un pacchetto
Office online completamente gratuito, in costante sviluppo e miglioramento.
Internet diventa il naturale prolungamento del personal computer.
Per quanto riguarda la reperibilità delle informazioni assistiamo in questo periodo alla crescente
popolarità di Google, mediante il quale vengono effettuate oltre il 70% delle ricerche totali sulla rete.
10
L'efficenza di questo servizio, basata su una forma di page ranking in funzione di quante pagine linkano
la pagina da valutare, ha cambiato radicalmente l'esperienza degli utenti della reperibilità delle
informazioni.
Con la nascita dei blog (da Web Log) l'aspetto dell'authoring raggiunge la maturità: in pochi
secondi è possibile diventare produttori di contenuti sul web. Questo genere di siti internet è diventato
così popolare che alcuni blog possono vantare migliaia di visite a settimana, veri e propri concorrenti di
testate giornalistiche online professionali.
Per quanto riguarda lo sharing in genere, la disponibilità della banda larga ha incoraggiato sia la
condivisione di file che di contenuti pubblicati su siti web specializzati, in funzione del tipo di
documento.
Tra i servizi più famosi troviamo: YouTube, che permette di condividere filmati amatoriali; Flikr,
che permette di pubblicare le proprie fotografie; Delicious, in cui gli utenti possono condividere i loro
URL preferiti; MySpace, una pagina personale dove scrivere in maniera molto semplice i propri
interessi e indicare i propri amici online; Digg, un sito web giornalistico che presenta notizie e
collegamenti su temi di scienza e tecnologia, Internet ed informatica.
Grazie a servizi quali blog, MySpace e FaceBook il social networking cresce a dismisura, e grazie
alla possibilità di fondare in pochi minuti un forum le sue potenzialità crescono esponenzialmente.
L'aspetto della condivisione delle informazioni, con il Web 2.0, si è sostanzialmente esaurito: si
potrà solamente rendere i servizi più efficienti, visto che non esiste un medium che non possa già
attualmente essere condiviso.
11
I sistemi Wiki
La parola wiki deriva da un termine in lingua hawaiiana che significa "rapido" oppure "molto
veloce", ed è stato scelto nel 1985 da Ward Cunningham per indicare la prima implementazione di un
motore wiki: il Portland Pattern Repository (o PPR), un progetto di documentazione online per i design
pattern.
Sostanzialmente un wiki è un sito web (o in genere un'insieme strutturato di documenti

ipertestuali) che può essere modificato dai suoi visitatori con lo scopo di condividere, scambiare,
immagazzinare e ottimizzare la conoscenza in modo collaborativo: la modifica dei contenuti infatti è
aperta e libera a chiunque.
Essendo un sistema aperto, la salvaguardia delle informazioni raccolte viene tutelata mediante
una cronologia (history) che immagazzina le modifiche fatte, permettendo in caso di necessità di
riportare la parte alterata a una qualsiasi versione precedente.
Da questo punto di vista i sistemi wiki possono essere considerati come l'evoluzione dei Content
Management System (CMS) dal momento che, alla possibilità di gestire la produzione di contenuti,
aggiungono un sistema di correzione auto-gestita dagli utenti in grado di mantenere la qualità e
l'attendibilità delle informazioni pubblicate.
I campi di applicazione di questa tecnologia sono principalmente orientati alla creazione di

documentazioni, soprattutto per quanto riguarda lo sviluppo di progetti collaborativi. L'esempio più
famoso è Wikipedia, uno dei dieci siti più visitati al mondo che riceve circa 60 milioni di accessi al
giorno.
Wiki in ambito aziendale
La conoscenza nelle aziende è una preziosa risorsa, e il fatto che essa possa andare persa
costituisce un costo. Non solo il cambio generazionale dei dipententi, ma anche la mancanza di uno
strumento che renda possibile lo scambio delle informazioni, comporta questo rischio.
I sistemi wiki possono essere un valido strumento per la creazione di un knowledge base, dal
momento che permettono a ognuno dei dipendenti di fornire un personale contributo alla sua creazione.
In questo modo non solo le informazioni frammentarie non vanno perse, ma il sistema può
autocorreggersi grazie alla mutua collaborazione tra utenti.
12
Capitolo 2. Progettazione dell'applicativo
2. Progettazione dell'applicativo
Nel presente capitolo verranno esposti la progettazione e lo sviluppo dell'applicazione web

WikiClienti. Questo nome deriva dal fatto che inizialmente essa era stata concepita esclusivamente per
l'immagazzinamento dei dati relativi ai clienti di un'azienda, per poi espandere la sua funzionalità a
qualsiasi categoria di dati.
2.1 Analisi dei Progetti OpenSource
Questa fase delle realizzazione del progetto ha diversi obiettivi. In primo luogo si è sentita la
necessità di esaminare lo stato dell'arte tecnologico dei motori wiki opensource in modo tale da chiarire
il campo di lavoro in cui si sarebbe operato.
In seguito ciò ha permesso di identificare le funzionalità di maggiore interesse offerte dalla

tecnologia wiki in genere, che corrispondono alle funzionalità base che la maggior parte di questa
tipologia di prodotti offre.
Esse sono:
• Visualizzazione dei contenuti
• Editing dei contenuti in stile wiki
• Gestione della cronologia dei contenuti (versioni di una stessa pagina)
• Visualizzazione delle differenze tra le versioni della stessa pagina
• Strumenti di amministrazione
La scelta dei motori da prendere in esame è stata influenzata principalmente dai vincoli di
progetto legati alle tecnologie da utilizzare: la ricerca ha quindi riguardato progetti ASP.NET scritti in
linguaggio C#.
13
Fra di essi si è deciso di privilegiare progetti semplici e di modeste dimensioni, per poter isolare
facilmente l'implementazione delle loro funzionalità a livello di codice; progetti grandi e complessi infatti
sviluppano eccessivamente funzionalità avanzate che non sono di nostro interesse.
La ricerca è stata realizzata tramite Internet e ha permesso di individuare i seguenti progetti

opensource:
• ScrewTurn Wiki: Progetto realizzato dalla ScrewTurn Software. Tra le caratteristiche più
evidenti troviamo lo storage delle pagine che avviene su file, permettendo di fare a meno di un
database. Il supporto alle basi di dati è comunque fornito tramite un sistema a plugins che
consente di definire dei custom providers (SQL Server e MySQL sono supportati di default).
• ProntoWiki: Progetto realizzato da Clay Alberty. Si presenta immediatamente come un

progetto completo nelle sue parti essenziali e di modeste dimensioni, molto semplice e user
friendly.
• Deki Wiki Multitouch: Progetto realizzato dalla Multitouch. Sebbene già dal nome si
presenti come un'applicazione web incentrata sul concetto di wiki lo stile è quello di un Content
Management System, e offre delle funzionalità avanzate che vanno in questa direzione.
• Perspective: Questo motore è pensato per avere una gestione in stile wiki di contenuti
generici, che vanno da documenti a file multimediali. Sembra quindi orientato su una convisione
di contenuti in senso lato (file sharing).
• FlexWiki: Come ProntoWiki questo motore è leggero, e si presenta in un layout molto

semplice.
Per completezza si riporta una tabella che indic se e quali, tra le funzionalità aggiuntive più
comuni, sono state implementate da ogni singolo progetto (vedi tabella).
14
ScrewTurn Deki Wiki

ProntoWiki Perspective FlexWiki
Wiki Multitouch
Sì Sì Sì Sì Sì
File uploading
Spam Sì Sì No No Sì
prevention
Page accesso Sì Sì Sì Sì Sì
control
No opzionale No Sì Sì (plugin)
Inline HTML
User-
CSS, Themes Sì CSS XSLT, CSS CSS, templates
customizable
interface
Document No Sì No Sì, con alias Sì
renaming
WYSIWYG No Sì No Sì No
Editor
RSS, XML,
RSS No RSS RSS
Web Feeds JSON
API, HTML
.NET
Architettura includes
plugins No reflection,
Extensibility Service (contenuti URL
plugins
Oriented esterni)
Tra i progetti esposti i più idonei, in funzione dei criteri di valutazione precedentemente esposti,
sono stati ScrewTurn e ProntoWiki. Tra i due ProntoWiki è il più semplice, mentre ScrewTurn fornisce
un buon compromesso tra dimensioni e complessità. Nel corso della realizzazione dell'applicativo
quello che, a livello di codice, è stato maggiormente consultato è stato ProntoWiki.
15
2.2 Descrizione dell'applicativo
L'applicazione web che si vuole realizzare consiste in un sistema wiki che implementi tutte le
funzionalità di base di questo genere di applicativi: visualizzazione di pagine web, la modifica delle
stesse da parte di più utenti, la consultazione di uno storico, e la comparazione delle diverse versioni di
una pagina.
Tipizzazione delle Pagine
A queste funzionalità di base se ne aggiunge una, di particolare interesse in quanto non compare
nello stato dell'arte presente in rete tra i prodotti open source messi a disposizione dalle communities di
sviluppatori.
Campo 1
Inserimento determinato
Campo 2
... Inserimento Libero
Campo N
Testo Wiki
Si tratta della possibilità di specializzare le pagine, conferendo loro una categoria di

appartenenza, in modo tale da poterle descrivere in modo più specifico rispetto a quella che permette
un generico testo wiki.
Questo infatti lascia all'utente totale libertà per quanto riguarda la compilazione delle informazioni
relativa a una singola pagina. La tipizzazione che è stata realizzata invece aggiunge alla pagina una
serie di campi specializzati da compilare.
Gli amministratori sono in qualsiasi momento in grado di definire una nuova categoria e i suoi
campi (attributi). Ad esempio la categoria “Cliente” può richiedere una serie di informazioni standard tra
cui “Nome”, “Cognome”, “Età”, “Codice Fiscale”, ecc. che la compilazione del testo wiki potrebbe
16
omettere, anche riportando una biografia dettagliata.
In questo modo si raggiunge un soddisfacente compromesso tra la libertà espressiva degli utenti,
tipica dei sistemi wiki, e le informazioni necessarie all'azienda per la formazione di un knowledge base.
Gli amministratori hanno inoltre la possibilità di specificare il tipo degli attributi di ogni categoria,
in modo tale da proteggere l'integrità dei dati. I tipi che si è deciso di scegliere in fase di analisi sono:
• DateTime
• Double
• Integer
• Money
• String (che è il tipo di default)
Un sistema di generazione automatica dei controlli di interfaccia e di validatori specializzati

impedirà l'inserimento di informazioni incoerenti.
Costruzione degli URL
Nei sistemi wiki per convenzione il titolo della pagina corrisponde all'ultima componente dell'URL,
in modo tale che il suo accesso sia più facile da ricordare. Ad esempio una pagina relativa a un cliente
dal titolo “Mario Rossi” presenta molto spesso un URL di questo tipo: http://miosito.it/wiki/MarioRossi.
Questa funzionalità viene implementata con un sistema di URL rewriting di cui ci occuperemo nel
capitolo seguente.
Omologazione dei titoli di pagina
Avendo introdotto una tipizzazione delle pagine, si è sentita l'esigenza di conferire alle pagine
appartenenti alla stessa categoria dei titoli omologati secondo una certa norma che, nel nostro caso, è
rappresentata da un'espressione.
Utilizzando un banale linguaggio di scripting sarà possibile definire per ogni categoria un titolo
parametrico, costruito in fuzione degli attributi della pagina. Prendendo ad esempio il caso precedente
l'espressione che descrive il titolo di ogni pagina appartenente alla categoria clienti sarebbe “$Nome
$Cognome”, dove ogni parola preceduta dal carattere dollaro indica un attributo.
Relazioni Ipertestuali
Uno degli aspetti più interessanti dei sistemi wiki, o più in generale di tutti quei sistemi che
17
raccolgono e catalogano informazioni, sta nella loro autoreferenzialità. A differenza di un normale sito
web, le pagine di un sistema wiki contengono moltissimi collegamenti ipertestuali a pagine dello stesso
sistema.
Quando si vuole realizzare un knowledge base avere la possibilità di collegare tra loro diverse
informazioni è un punto di forza da non sottovalutare, in quanto questo permette di creare relazioni
semantiche tra una pagina e l'altra.
Il vantaggio di un sistema wiki è che queste relazioni ipertestuali, dotate quindi di significato,
vengono create dal basso (cioè dagli utenti) facendo sì che potenzialmente chiunque sia in grado di
arricchire la pagine con sempre nuove relazioni.
Ad esempio la pagina di un cliente potrebbe essere collegata con le pagine dei suoi prodotti o
con le pagine dei suoi fornitori: le relazioni di “Produzione” e di “Fornitura” verrebbero così a crearsi
spontaneamente.
18
2.3 Progettazione dell'applicativo
La progettazione dell'applicativo è stata effettuata seguendo l'architettura three-tier, che suddivide

il software secondo tre canonici livelli di astrazione riconosciuti ormai come uno standard: data layer,
businness logic, e presentation layer.
Per ora ci limiteremo a considerare il tutto dal punto di vista puramente concettuale, per poi
descrivere l'implementazione effettiva dal punto di vista logico in funzione delle specifiche di progetto
indicateci.
Inizieremo con la descrizione dei dati mediante una schema Entity Relationship, scelta obbligata
dal fatto che i dati saranno depositati su un database relazionale, per poi descrivere la struttura del
codice secondo il già citato modello three-tier; infine descriveremo il funzionamento ideale
dell'applicativo mediante un diagramma di workflow che permetterà di identificare gli attori in gioco.
Architettura Three-Tier
Come accennato nei paragrafi precedenti l'architettura utilizzata per strutturare il codice
dell'applicativo è quella three-tier.
Questa scelta è giustificata dalle specifiche di progetto che prevedono l'utilizzo della tecnologia
Microsoft ASP.NET; infatti quest'ultima ha già delle caratteristiche tali da orientare lo sviluppo delle web
application secondo questo paradigma.
Ci si riferisce in particolare alla gestione delle pagine mediante il meccanismo del code-behind,
che esorta il programmatore e disgiungere il presentation layer, rappresentato dalle pagine aspx
contenenti il codice HTML e ASP, dalla logica vera e propria (businness logic) codificata in uno dei
linguaggi di programmazione offerti dal framework (C#, visual basic).
Senza entrare ulteriormente nel merito dell'implementazione logica, che riprendermo in seguito,
verranno ora esposti i livelli di astrazione del paradigma relativamente alla progettazione
dell'applicativo.
19
DB
Data Layer
Businness Logic
Presentation Layer
Base di Dati
La base di dati è, per specifiche di progetto, di tipo relazionale. Utilizzeremo per descriverla dal
punto di vista concettuale un diagramma di tipo entity-relationship, mentre per quanto riguarda la sua
implementazione logica le specifiche di progetto esigono l'utilizzo della tecnologia Microsoft SQL
Server, da noi adottata nella sua versione Express.
Data Layer
Il data layer realizza l'effettivo accesso ai dati. Questo sarà suddiviso essenzialmente in due parti:
una appartentente al database management system (DBMS), che effettuerà un accesso maggiormente
centralizzato e sicuro tramite l'utilizzo di stored procedures; l'altra legata alla tecnologia ASP.NET,
fungendo da ponte tra la business logic e il database vero e proprio.
La prima parte verrà implementata in linguaggio T-SQL direttamente all'interno del DBMS, la
seconda in linguaggio C# mediante la realizzazione di classi specializzate in tal senso.
Businness Logic
Tutta la logica effettiva dell'applicazione, che non ha come scopo l'accesso ai dati, ricade sotto il
nome di business logic. Dal momento che l'applicazione web presentata è principalmente
un'interfaccia volta all'alimentazione del database, la businness logic consisterà principalmente nella
realizzazione di quei vincoli che ne consentiranno il corretto inserimento delle informazioni e il loro
20
accesso.
Presentation Layer
Come già accennato il presentation layer riguarda la realizzazione delle pagine aspx in
linguaggio ASP.NET e HTML, quindi anche la progettazione della navigabilità e della struttura del sito
verrà effettuata in questo contesto.
Per quanto riguarda il design delle pagine si è scelto di utilizzare un CSS (cascade style sheet),
specificando delle classi di stile.
21
2.4 Progettazione del DB: diagramma Entity-Relationship
Trattandosi di un database relazionale utilizzeremo, come schema per la progettazione

concettuale del database, il diagramma entity-relationship.
Esso consente, mediante una rappresentazione a blocchi, di descrivere le entità che

compongono i dati, i campi che contengono, le relazioni che attraverso le quali sono legati, e la
cardinalità che intercorre tra essi.
Entità e Relazioni
Dalla descrizione precedente dei dati da gestire sono state identificate le seguenti entità, che
indicheremo in lingua inglese:
• Page Cotntiene i dati di una singola pagina
• PageHistory Contiene i dati di una pagina dello storico
• Category Categoria di cui fa parte la pagina
• AttributeValue Valore effettivo dell'attributo di una pagina
• AttributeHistory Valore di un attributo di una pagina dello storico
• Type Tipo dei dati di un attributo
• Attribute Descrizione dell'attributo di una pagina
Per quanto riguarda la le loro relazioni esse sono tutte delle semplici relazioni di appartenenza,
facilmente integrabili dal punto di vista logico mediante l'utilizzo di campi specifici.
Campi
Segue una descrizione schematica dei campi identificati per ognuna delle entità precedenti:
Page
22
Id Chiave primaria
Name Nome della pagina
Title Titolo della pagina
Text Testo Wiki della pagina
PageHistory
Id Chiave primaria
VersionVersione della pagina
Category
Name Nome della categoria (chiave primaria)
TitleExpression Espressione per la generazione automatica del titolo
AttributeValue
Id Chiave primaria
Value Valore dell'attributo nella pagina
Name Nome dell'attributo nella pagina
AttributeHistory
Id Chiave primaria
Value Valore dell'attributo nello storico
Name Nome dell'attributo nello storico
Type
Name Nome del tipo (chiave primaria)
Attribute
Name Nome dell'attributo da descrivere
Required Campo che indica se l'attributo è obbligatorio
23
Diagramma Entity Relationship
24
Legenda
Per agevolare il lettore che non abbia familiarità con la simbologia dei diagrammi entity-
relationship riportiamo una breve legenda:
Entità
Relatione
0–1 Nessuno o un elemento associato a un elemento
0–N Nessuno o un elemento associato a uno o più elementi
1–1 Un elmento associato ad un elemento
1–N Un elemento associato a uno o più elementi
N–N Più elementi associati a uno o più elementi
Cardinalità
La cardinalità delle relazioni viene indicata con i simboli 0, 1 e N che stanno rispettaviamente per:
zero o più, almeno uno, e molti.
Dalle cardinalità indicate nel diagramma, indicate ai lati delle relazioni, è possibile notare che non
esistono relazioni di tipo molti-a-molti, che sono le più complesse da trattare nella trasformazione del
diagramma concettuale in quello logico.
Questo ci permetterà di trasformare l'uno nell'altro in modo molto semplice.
25
2.5 Progettazione del Data Layer
La progettazione del data layer è stata effettuata basandosi il più possibile sul principio di
centralizzazione delle operazioni di accesso ai dati.
Per questo motivo si è scelto innanzi tutto di interfacciarsi al database mediante l'utilizzo di stored
procedures, anziché mediante codice T-SQL scritto all'interno dell'applicazione stessa. Queste infatti,
oltre a costituire un meccanismo più sicuro, permettono di accentrare maggiormente il codice in un
unico punto: il database stesso.
Lo stesso principio è stato applicato durante la progettazione del livello sottostante. Il modulo
dell'applicazione web che farà parte del data layer sarà dotato delle seguenti funzionalità:
• Realizzare la connessione alla base di dati
• Effettuare la chiamata alle stored procedures
• Formattare le informazioni ottenute in particolari strutture dati
Per ora non definiremo queste strutture dati (ce ne occuperemo in fase di implementazione),
bensì ci limiteremo a descrivere le loro caratteristiche. Esse saranno costituite da dei moduli privi di
comportamento (metodi) che terranno traccia dello stato dei record presenti nel database,
rispecchiando i dati in modo disconnesso.
Modulo con Modulo con

soli dati solo comportamento
Data Entity Data Layer
(messaggio) (logica)
Sostanzialmente queste strutture dati fungeranno da messaggi tra il data layer e la business
logic, limitandosi esclusivamente a questa funzione.
Per la loro natura le chiameremo data entities.
26
E' importante sottolineare che in questa fase di progettazione si è scelto di scindere

completamente in due tipologie di classi distinte i dati dal comportamento.
Perciò mentre le data entities sono dei moduli che presentano puramente dei dati, il modulo che
realizza le funzionalità precedentemente descritte è costituito da puro comportamento (metodi).
In particolare essi hanno come finalità la lettura, scrittura e cancellazione delle seguenti tipologie
di dati:
• Pagine wiki
• Struttura (schema) degli attributi
• Valore degli attributi
• Categorie
• Pagine della cronologia (history)
Da quanto detto finora il data layer risulta suddiviso in due parti: una definita all'interno della base
di dati e una all'interno dell'applicazione web. Le stored procedures vengono qui considerate facenti
parte del data layer perchè contengono parte della logica volta all'accesso dei dati.
ADO.NET
Per progettare correttamente il data layer si è compiuto uno studio di ADO.NET, che fornisce a
differenza delle versioni precedenti un migliorato modello disconnesso di accesso ai dati.
Dallo studio si è scelto di procedere principalmente con la filosofia di accesso ai dati

disconnessa, sfruttando le possibilità offerte dalle classi appositamente adibite.
In particolare le classi di cui ci è fatto ampio utilizzo sono quelle del Sql Managed Provider :
• SqlConnection: realizza la connessione al database
• SqlCommand: realizza un comando al database (es: stored procedure)
• SqlParameter: tipo che rappresenta un parametro di una stored procedure
• SqlDataReader: rappresenta un cursore read-only, forward-only, estremamente rapido e

leggero
• SqlDataAdapter: classe ponte tra l'oggetto SqlConnection e una struttura dati disconnessa
(DataSet o DataTable)
27
Possiamo fornire un primo risultato di quello che sarà lo schema logico che andremo a realizzare,
mostrando quali livelli software attraverseranno i dati, così da avere come output del data layer una
delle data entity descritte. Rappresenteremo il tutto mediante il seguente schema:
Tabelle
Viste
Stored Procedures
ADO.NET
Data Layer
Data Entities
In questo schema abbiamo dato una breve anteprima di quello che sarà lo schema logico
dell'applicativo, in modo tale da poter orientare la parte restante dello sviluppo dell'applicazione avendo
presente la base di partenza per quanto riguarda i dati. Infatti se da un punto di vista astratto è
possibile scindere lo sviluppo in parti distinte, il modo di procedere in fase implementativa non può mai
seguire uno schema così rigido a causa degli errori e delle correzioni che si trovano lungo lo sviluppo.
28
2.6 Progettazione della Businness Logic
In questo paragrafo verrà descritta la logica di business dell'applicativo. In particolare

descriveremo le funzionalità che l'applicativo dovrà implementare, facendo riferimento a ciò che è stato
evinto durante la fase di analisi.
Dopo aver ricapitolato le funzionalità da implementare vedremo come distribuirle all'interno dei
diversi moduli che andranno a formare l'applicazione web.
Features
L'applicazione dovrà integrare le seguenti funzionalità:
• Visualizzazione delle pagine wiki
• Parser del testo wiki in testo HTML
• Visualizzazione dell'elenco delle pagine wiki in ordine alfabetico
• Visualizzazione dell'elenco delle pagine wiki suddivise per categoria
• Editing delle pagine wiki
• Inserimento del testo wiki agevolato per mezzo di un editor dedicato
• Creazione di una nuova pagina wiki
• Creazione automatica di uno storico (history)
• Visualizzazione dello storico
• Visualizzazione delle differenze tra due versioni di pagina dello storico
• Funzioni di amministrazione delle categorie
• Funzioni di amministrazione degli schema degli attributi delle categorie
• Gestione degli URL secondo la filosofia wiki (URL rewriting)
• Gestione delle ambiguità (casi di omonimia) tramite reindirizzamento
29
Progettazione delle classi
Le pagine aspx sono pensate per suddividere già di base il presentation layer dalla business
logic tramite il meccanismo del codebehind. Esso consiste nella separazione del codice .NET puro (ad
esempio scritto in C#) da quello ASP.NET, che realizza la descrizione della struttura delle pagine.
Ad ogni pagina aspx è associato un sorgente chiamato con lo stesso nome, con l'aggiunta
dell'estensione della tipologia del sorgente stesso (cs per C#, vb per visual basic, ecc) che permette di
gestire la logica e la struttura della pagina “da dietro” (behind).
Page
Pagina.aspx (presentation)
Pagina.aspx.cs (codebehind)
Una buona parte della business logic quindi verrà implementata all'interno di questo tipo di classi,
che ereditano tutte da una classe madre chiamata Page: il tipo che rappresenta dal punto di vista della
programmazione orientata agli oggetti la pagina aspx.
Ad ogni modo si cercherà di centralizzare il più possibile la logica dell'applicativo per cercare di
evitare inutili ridondanze. Per questo motivo, analogamamente a quanto visto per il data layer, verrà
creato un modulo appositamento adibito per contenere la logica più complessa in modo anche da
separare quest'ultima dai sorgenti aspx.cs.
Modulo con (messaggio) Modulo con

solo comportamento solo comportamento
Data Entity
Businness Log. Data Layer
30
Questi infatti contengono usualmente la logica necessaria alla costruzione delle pagine stesse, in
primo luogo i meccanismi di databinding e di reindirizzamento per il controllo del flusso applicativo (che
nel caso di un'applicazione web coincide spesso con la navigabilità all'interno del sito).
In questa fase si è inoltre deciso di implementare le funzionalità più importanti in modo tale da
isolarle dalle singole pagine aspx, realizzandole con dei controlli ascx: i controlli custom di ASP.NET.
Questo permetterà a queste funzionalità di essere maggiormente slegate dalle singole pagine. Esse
sono:
• Visualizzazione delle pagine wiki (dello storico e non)
• Editing delle pagine wiki
• Creazione di nuove pagina wiki
• Funzioni di amministrazione
I controlli sono poi integrati all'interno delle pagine con degli appositi tag ASP.NET, analogamente
a come avviene per qualsiasi altro controllo web, con la differenza che questi vengono definiti dal
programmatore.
31
2.7 Progettazione del Presentation Layer
Il presentation layer rappresenta il livello in cui avviene la visualizzazione dei dati e delle
funzionalità dell'applicativo da parte dell'utente: il livello che appunto li “presenta” allo stesso.
Come abbiamo già visto descrivendo la business logic ASP.NET ci fornisce già, dal punto di vista
della programmazione, un livello di astrazione logica in cui poter inserire questa parte di codice.
Si tratta delle pagine aspx che, programmate in linguaggio asp, descrivono in modo strutturato il
template della pagina e gli elementi che la compongono, come i controlli web che andranno a costituire
l'interfaccia grafica.
Diagramma degli stati applicativi
Per la progettazione di questo livello partiremo in generale da come si presenterà l'applicazione

web dal punto di vista degli stati applicativi che rappresentano le diversi funzionalità, mentre
descriveremo in dettaglio la realizzazione del presentation layer delle singole pagine nel capitolo
dell'implementazione.
X x1/0
y1/1
z1/1
y0/1
Y Z
Visto che ci troviamo in fase concettuale utilizzeremo per rappresentare la transazione degli stati
applicativi un diagramma di stato. Gli stati che sono stati individuati ricalcano le funzionalità descritte in
precedenza. A questi aggiungiamo uno stato astratto di partenza, che potrà in futuro essere sostituito
da uno qualsiasi degli altri stati concreti.
Ad ogni stato assoceremo un nome che verrà riportato nel diagramma:
• Start: Stato di partenza
• NewPage: Stato di creazione di una nuova pagina
• EditPage: Stato di editing di una pagina
32
• ViewPage: Stato di visualizzazione di una pagina
• Admin: Stato di amministrazione
• Pages: Stato di visualizzazione pagine per categorie
• PagesAZ: Stato di visualizzazione pagine in ordine alfabetico
• History: Stato di visualizzazione elenco versioni di una pagina (storico)
• ViewHistory: Stato di visualizzazione di una pagina di storico
• Differences: Stato di confronto tra due diverse versioni di una pagina
Il diagramma di stato ci permetterà di stabilire da quali stati è possibile accedere agli altri. Per quanto
riguarda l'ingresso e l'uscita di questi stati considereremo il tutto solo dal punto di vista della
navigabilità, specificando quindi che la transizione da uno stato all'altro viene scatenata da un
reindirizzamento URL a seguito di un evento scatenato dall'utente.
33
Indirizzi web delle pagine (URL)
Abbiamo già accennato che una delle caratteristiche da implementare faccia riferimento alla
convenzione utilizzata dai motori wiki in merito alla costruzione degli URL.
In particolare adotteremo questa filosofia, utile soprattutto per accedere alle pagine in modo
mnemonico con più facilità, per quanto riguarda tre funzionalità: quella di visualizzazione di una singola
pagina, quella di editing, e quella di visualizzazione dello storico.
Ci sembra superfluo utilizzare un meccanismo di URL rewriting anche per quanto riguarda gli altri
stati applicativi, quindi ci limiteremo a quelli indicati.
Gli indirizzi web che vorremo ottenere saranno di questo tipo:
• Visualizzazione: ~/wiki/NomePagina
• Editing: ~/edit/IdPagina
• History: ~/history/IdPagina
La visualizzazione può avvenire digitando il nome della pagina scritto in sintassi CamelCase. Nel
caso di omonimia lo stato di visualizzazione risolve l'ambiguità per mezzo di un apposito dialogo,
mentre gli altri stati no in quanto il loro ingresso avviene per id. Per questo motivo esso deve essere
indicato direttamente nell'URL.
34
Capitolo 3. Implementazione logica dell'applicativo
3. Implementazione logica dell'applicativo
In questo capitolo verrà illustrato il passaggio dallo schema concettuale dell'applicazione web,
descritto nel capitolo precedente, alla sua effettiva implementazione logica. Abbiamo già indicato nel
capitolo introduttivo quali tecnologie sono state imposte dai vincoli di progetto, ora andremo a
descrivere come queste sono state impiegato per realizzare l'applicazione web.
In particolare suddivideremo questa descrizione in quattro parti, coerentemente al modello three-

tier già illustrato:
• Implementazione logica della base di dati
• Implementazione del data layer
• Implementazione della businnes logic
• Implementazione del presentation layer
3.1 Stack dei livelli logici di astrazione
In fase di progettazione è stato riportato lo stack dei livelli di astrazione del modello three-tier.
Prima di proseguire nella descrizione della loro implementazione, esamineremo come appare lo stack
completo dei livelli dal punto di vista logico.
I dati immagazzinati nel database vengono presentati all'esterno mediante l'utilizzo delle viste,
sulle quali operano le stored procedures. Queste vengono chiamate attraverso le classi fornite da
ADO.NET che sono riportate in tabella, le quali vengono utilizzate dalla classe che realizza il datalayer:
WikiClientiDL.
35
Tabelle
Viste Database Management System

(MS SQL Server)
Stored Procedures
SqlConnection, DataReader, DataAdapater,

SqlCommand, DataTable Classi fornite da ADO.NET
WikiClientiDL, WikiData, AttributeProperties
Classi scritte in C#
WikiCLientiBL, WikiParser
Codebehind controlli (ascx.cs)
Classi scritte in C# (Codebehind)

Codebehind pagine (aspx.cs)
Controlli ascx
Elementi scritti in linguaggio ASP.NET

Pagine aspx, CSS
Questa viene chiamata dai livelli sottostanti, sia dalla classe principale che contiene la
businesslogic dell'applicativo (WikiClientiBL) che da quelle che realizzano il codebehind delle pagina
aspx e dei controlli ascx.
A loro volta questi elementi sono richiamati dalla simulazione della gestione a eventi tipica dei
controlli ASP.NET, definiti e collocati all'interno delle pagine aspx e dei controlli ascx che costituiscono il
presentation layer.
La logica dell'applicativo è interamente lato server, fatta eccezione per alcune pagine che
presentano degli script lato client scritti in Javascript.
36
3.2 Implementazione logica della base di dati
Trasformazione del diagramma Entity-Relationship
In questo paragrafo esamineremo la trasformazione del diagramma entity-relationship descritto

nel capitolo 3 nello schema logico implementato in un database relazionale in MS SQL Server.
Questa trasformazione comprende i passi seguenti:
• Risoluzione delle generalizzazioni (nel nostro caso assenti)
• Trasformazione delle entità in tabelle (con chiave primarie e vincoli quali indici)
• Accorpamento delle relazioni semplici (1-N, 0-N) nelle tabelle sottoforma di chiavi esterne
• Trasformazione delle relazioni N-N in tabelle di sponda (incroci)
Oltre a questi step per la trasformazione del diagramma E-R si aggiungono:
• Creazione delle viste
• Aggiunta di eventuali trigger
Tabelle
Come si può evincere dallo schemo logico riportato in figura (vedi immagine seguente), le
tabelle della base di dati sono state ricavate direttamente dalle relazioni presenti nello schema
concettuale. In particolare sono stati utilizzati gli stessi nomi, quindi le corrispondenze sono
immediatamente identificabili.
Dal momento che nessuna relazione individuata nello schema concettuale è del tipo molti a molti
non è stata introdotta nessuna tabella aggiuntiva (tabella di sponda) per risolverla, rendendo il processo
di adattamento molto semplice.
Tutte le relazioni di appartenenza sono state risolte utilizzando un accorpamento delle stesse
all'interno delle tabelle sotto forma di singoli campi, utilizzati come chiavi esterne.
Riportiamo lo schema logico delle tabelle completo di campi, chiavi primarie (Id) e chiavi esterne
(in corsivo).
37
Schema logico implementato in MS SQL Server
38
Page
Id Chiave primaria
Category Chiave esterna alla tabella Category
PageHistory
Id Chiave primaria
Page Chiave esterna alla tabella Page
Version Versione della pagina
Category
Name Nome della categoria (chiave primaria)
TitleExpression Espressione per la generazione automatica del titolo
AttributeValue
Id Chiave primaria
Value Valore dell'attributo nella pagina
Name Nome dell'attributo nella pagina
AttributeHistory
Id Chiave primaria
Value Valore dell'attributo nello storico
Name Nome dell'attributo nello storico
39
Type
Name Nome del tipo (chiave primaria)
Attribute
Name Nome dell'attributo da descrivere
Required Campo che indica se l'attributo è obbligatorio
Type Chiave esterna alla tabella Type
Viste
Buona norma nella progettazione e accesso a un database è quella di evitare di operare delle
richieste direttamente sulle tabelle, dal momento che queste sono potenzialmente soggette a
cambiamenti strutturali futuri.
Tabelle
Viste
Stored Procedures
Questi cambiamenti costringerebbero i livelli sottostanti al database, che potrebbero coinvolgere

anche più applicativi, ad adattamenti forzati che porterebbero a una perdita di tempo e risorse.
Per questo motivo si utilizzano le viste, che forniscono un livello di astrazione aggiuntivo tra i dati
veri e propri e le funzioni di accesso agli stessi, come ad esempio le stored procedures.
In particolare quindi si è deciso di procedere con la formazione di una vista per tabella,
40
assicurando una maggiore flessibilità per le eventuali modifiche future. Infatti a fronte di una variazione
strutturale la vista può continuare, salvo modifiche importanti, a interfacciare i dati con la struttura
precedente in modo trasparente.
Per quanto riguarda la stored procedures, che verranno descritte nei paragrafi successivi, esse
effettuano le query sulle viste e non sulle tabelle.
Indici e Trigger
Non si sono rese necessarie, in fase di implementazione del database, particolari accorgimenti
per evitare la duplicazione di alcuni campi all'interno di una stessa tabella. Per questo motivo non sono
stati aggiunti indici a quelli già implicitamente presupposti nell'utilizzo delle chiavi primarie.
Analogamente per quanto riguarda i trigger.
41
3.2 Implementazione del Data Layer
Stored Procedures
Si è deciso di parlare delle stored procedures nell'implementazione del datalayer, anziché nella
descrizione dello schema logico, perchè queste sono in stretta relazione con la parte relativa
all'accesso ai dati.
L'utilizzo delle stored procedures fornisce, a differenza dell'utilizzo di query descritte all'interno
del codice dell'applicativo, una modalità centralizzata di accesso ai dati, costituendo a rigore una vera e
propria interfaccia al database.
Le stored procedures realizzate forniscono sostanzialmente le operazioni di insert, update e

delete, operando come accennato in predecenza sulle viste.
Esse sono:
AttributeNameEdited Update sul nome di un attributo
DeleteAttribute Delete su un attributo
DeleteHistoryAttributes Delete sugli attributi di una pagina history
DeletePage Delete su una pagina
DeletePageAttributes Delete sugli attributi di una pagina
DeletePageHistory Delete su una pagina history
GetAttributes Select sugli attributi di una categoria
GetCategories Select sulle categorie esistenti
GetDistinctPagesInCategory Select della pagina di una categoria
GetHistory Select su ana pagina history
GetHistoryAttributes Select sugli attributi di una pagina history
GetIndex Select delle pagine che iniziano con una lettera
GetIndexNA Select delle pagine che iniziano con una cifra
42
GetPage Select su una pagina
GetPageAttributes Select sugli attributi di una pagina
GetPageHistory Select sulle pagine history di una pagina
GetPagesByName Select paramatrica di una pagina per nome
GetPagesInCategory Select parametrica sulle pagine di una categoria
GetTypes Select sui tipi
GetVersionNumber Select sulla versione di una pagina history
InsertAttribute Insert della definizione di un attributo
InsertAttributeHistory Insert della definizione di un attributo history
InsertAttributeValue Insert del valore di un attributo
InsertCategory Insert di una nuova categoria
InsertHistory Insert di una nuova pagina history
InsertPage Insert di una nuova pagina
UpdateAttribute Update di un attributo
UpdateAttributeValue Update del valore di un attributo
UpdateCategory Update di una categoria
UpdatePage Update di una pagina
UpdatePageText Update sul testo di una pagina
A titolo di esempio riportiamo il codice di quattro stored procedures, una per ogni operazione SQL
sulle tabelle (select, insert, update, delete)
Select
set ANSI_NULLS ON
set QUOTED_IDENTIFIER ON
GO
CREATE PROCEDURE [dbo].[GetPageAttributes]
(
@Id int
)
AS
SELECT viwAttributeValue.Name, Value
FROM viwAttributeValue
WHERE Id = @Id
RETURN
43
Insert
set ANSI_NULLS ON
GO
CREATE PROCEDURE [dbo].[InsertAttributeValue]
(
@Id int,
@Name nvarchar(50),
@Value nvarchar(50)
)
AS
INSERT INTO dbo.viwAttributeValue(Id, dbo.viwAttributeValue.Name, Value)
VALUES (@Id, @Name, @Value)
RETURN
Update
set ANSI_NULLS ON
GO
ALTER PROCEDURE [dbo].[UpdateAttributeValue]
(
@Id int,
@Name nvarchar(50),
@NewValue nvarchar(50)
)
AS
UPDATE dbo.viwAttributeValue
SET Value = @NewValue
WHERE dbo.viwAttributeValue.Name = @Name AND Id = @Id
RETURN
Delete
set ANSI_NULLS ON
GO
ALTER PROCEDURE [dbo].[DeletePageAttributes]
(
@Id int
)
AS
DELETE FROM dbo.viwAttributeValue
WHERE dbo.viwAttributeValue.Id = @Id
RETURN
44
Struttura delle classi
Come abbiamo anticipato nella fase di progettazione, per quanto riguarda l'accesso ai dati dal
lato dell'applicativo si è fatto un largo utilizzo di ADO.NET, la struttura di accesso ai dati fornita dalla
Microsoft.
In questo paragrafo daremo per acquisite le conoscenze del lettore per quanto riguarda questa
architettura Microsoft, concentrandoci sulla parte che è stata sviluppata per l'applicazione in questione.
In particolare esamineremo ora le classi che sono state sviluppate per implementare il data layer.
WikiClientiDL
Questa classe rappresenta il datalayer vero e proprio. Essa contiene una serie di metodi per
l'accesso ai dati che realizzano un wrapper per la chiamata, mediante l'utilizzo delle classi ADO.NET,
alle stored procedures.
I dati che vengono recuperati mediante la loro esecuzione vengono poi ritornati o sottoforma di
tipi semplici o di tipi strutturati.
Per quanto riguarda questi ultimi i tipi che sono stati utilizzati sono le DataTable, fornite da
ADO.NET, e alcune classi create ad hoc, che abbiamo chiamato data entities (si vedano in proposito le
classi WikiData e AttributeProperties).
45
La scelta delle DataTables è stata giustificata dal fatto che esse permettono di realizzare
rapidamente il databinding con i controlli web ASP.NET, rendendo la visualizzazione dei dati a
interfaccia molto rapida.
La classe WikiClientiDL fornisce i metodi che in fase di progettazione erano stati suddivisi per
tipologia, aggiungendo a questi quelli necessari per la connessione al database.
Per completezza si riportano le firme dei metodi implementati che, per il loro nome analogo a
quello delle stored procedures che vanno a chiamare, si commentano chiaramente da sole:
• Connessione al database
◦ protected void OpenDatabaseConnection();
◦ protected void CloseDatabaseConnection();
• Accesso ai dati delle pagine
◦ public WikiData SelectPage(int id)
◦ public DataTable SelectPagesInCategory(string category)
◦ public DataTable SelectIndex(char i)
◦ public WikiData SelectEmptyPage(string category)
◦ public DataTable SelectPageList(string name)
◦ public void InsertPage(WikiData wd)
◦ public void UpdatePage(WikiData wd)
◦ public void UpdatePageText(int id, string text)
◦ public void DeletePage(int id)
• Accesso alla struttura degli attributi
◦ public Dictionary<string, AttributeProperties> SelectAttributeProperties(string category)
◦ public void DeleteAttributeProperty(string category, string name)
◦ public void UpdateAttributeProperty(AttributeProperties oldAP, AttributeProperties newAP)
◦ public void InsertAttributeProperty(AttributeProperties ap)
◦ public DataTable SelectCategoryAttributes(string category)
• Accesso al valore degli attributi
46
◦ public DataTable SelectAttributes(int id)
◦ public bool UpdateAttribute(int id, string name, string value)
◦ public void InsertAttribute(int id, string name, string value)
◦ public void DeleteAttribute(string category, string name)
• Accesso ai dati delle categorie
◦ public DataTable SelectCategories()
◦ public void UpdateCategory(string name, string newName, string newTitle)
◦ public void InsertCategory(string name, string title)
◦ public string SelectTitleExpression(string category)
• Accesso ai dati delle history
◦ public WikiData SelectHistory(int id)
◦ public DataTable SelectHistoryAttributes(int id)
◦ public void InsertHistory(int pageId, WikiData wd)
◦ public void InsertAttributeHistory(int hId, string name, string value)
◦ public void DeleteHistory(int id)
◦ public WikiData[] SelectPageHistoryEntities(int id)
◦ public DataTable SelectPageHistory(int id)
◦ public int GetVersionNumber(int id)
Alcuni metodi non ritornano l'entità recuperata sotto forma di una struttura, bensì un
singolo campo interessato. E' ad esempio il caso del metodo SelectTitleExpression che
recupera, relativamente ad una categoria, l'espressione mediante la quale viene costruito
il titolo della pagina di una categoria (si veda in proposito il paragrafo 2.1, Omologazione
dei titoli di pagina).
47
WikiData
La classe WikiData è pensata come una data entity, intendendo con questo termine
nien'altro che una classe priva di metodi che realizza una struttura per lo scambio di dati
tra un livello di astrazione e l'altro (in questo caso datalayer e businesslogic).
Essa è formata da una serie di field protected ai quali è possibile accedere mediante
delle proprietà .NET omonime:
• protected int id;
• protected string category;
• protected string name;
• protected string title;
• protected string text;
• protected int version;
• protected Hashtable attributes;
Come si può vedere le variabili membro della classe rispecchiano i campi della
48
tabella Page, oltre a fornire mediante un Hashtable (struttura dati formata da una serie di
coppie chiave-valore) la serie degli attributi ad essa associata.
AttributeProperties
Analogamente alla classe WikiData la classe AttributeProperties descrive mediante

un tipo un'entità del database: Attribute. Questa contiene le proprietà dello schema di un
attributo, a differenza della classe AttributeValue che ne contiene il valore.
Queste proprietà sono:
• private string name;
• private string category;
• private string type;
• private bool required;
49
3.3 Implementazione della Business Logic
In questo paragrafo descriveremo com'è stata implementata la logica di business che è stata
descritta nel capitolo precedente.
Le varie funzionalità che sono state presentate saranno ora considerate dal punto di vista del
codice, descrivendo brevemente come sono state realizzate, mediante quali strumenti e classi offerte
dal .NET framework.
Struttura delle classi
In generale possiamo dire che la business logic è situata principalmente in due locazioni: le classi
in C# corrispondenti alle pagine aspx, che vengono automaticamente generate per realizzare il
codebehind, e una classe specifica che è stata realizzata per centralizzare il codice in un unico modulo.
WikiClientiBL
Classi C#
Controlli (ascx.cs)
Classi C#
Pagine (aspx.cs) (Codebehind)
In particolare non tutte le features dell'applicativo sono state implementate direttamente in pagine
aspx. Alcune sono state rese mediante controlli ascx in modo tale da poterle riutilizzare
indipendentemente dalla singola pagina, slegandole dal contesto.
Alcune pagine aspx quindi presenteranno una logica scarna, volta a includere i controlli asp.net
che realizzano le funzioni del software sopracitati.
Controlli ascx
I controlli creati per realizzare la business logic sono sei, mentre un altro controllo è stato
aggiunto per creare il menù laterale di navigazione nel sito web (lo vedremo nella descrizione del
50
presentation layer).
Veranno presentati suddivisi in funzione della funzionalità che implementano:
• Visualizzazione delle pagine
◦ AttributeViewerControl.ascx: la visualizzazione del testo wiki è slegata dalla visualizzazione

gli attributi statici di una pagina. Questo controllo permette, data l'ID di una pagina, di
recuperare gli attributi ad essi associata e di visualizzarli.
◦ HistoryAttributeViewerControl.ascx: analogamente all'AttributeViewerControl, recupera e

visualizza gli attributi di una pagina dello storico.
• Editing delle pagine
◦ PageEditorControl.ascx: dato l'ID di una pagina costruisce dinamicamente una serie di

editor in funzione del tipo degli attributi della pagina (DateTime, Integer, Money, Double, e
String), e un editor relativo al testo wiki. In particolare per l'editing del testo wiki sono state
inserite delle parti di codice javascript che lavorando lato client facilitano la corretta
formattazione del testo secondo il linguaggio wiki utilizzato.
• Creazione di una nuova pagina
◦ NewPageControl.ascx: analogamente al controllo di editing viene generata la serie dei

campi che costituisce la form di inserimento di una nuova pagina. Anche qui vengono fatti i
medesimi controlli sul tipo e sull'obligatorietà (o meno) di un attributo.
• Funzioni di amministrazione
◦ AttributeManagerControl.ascx: questo controllo consente di amministrare lo schema degli

attributi. Prendendo una categoria in ingresso visualizza gli attributi ad essa associati,
permettendo di cancellarli, modificarli, crearne di nuovi, cambiarne il tipo e renderli
obbligatori o meno.
◦ CategoryManagerControl.ascx: analogamente a quanto descritto per

l'AttributeManagerControl questo controllo gestisce le funzioni di amministrazione sulle
categorie. Per la sua realizzazione, come quella dell'attributo precedente, è stato utilizzato
un controllo ASP.NET GridView.
I controlli descritti sono stati inseriti all'interno di pagine aspx, che come precedentemente
51
accennato hanno una funzione di puri wrapper dei controlli, senza cioè implementare nessuna
particolare logica aggiuntiva.
Le pagine in questione, riportate con i relativi controlli, sono:
• Admin.aspx
◦ AttributeManagerControl.ascx
◦ CategoryManagerControl.ascx
• Edit.aspx
◦ PageEditorControl.ascx
• PageHistory.aspx
◦ HistoryAttributeViewerControl.ascx
• New.aspx
◦ NewPageControl.ascx
• Page.aspx
◦ AttributeViewerControl.ascx
Pagine Aspx
Descriveremo ora le pagine aspx che realizzano le altre funzionalità, che non fanno utilizzo dei
controlli ascx appena descritti. Esse sono:
• Diff.aspx: questa pagina permette di confrontare due diverse versioni di una pagina presenti
nello storico, evidenziandone le differenze. La selezione delle pagine wiki su cui effettuare il
confronto viene fatto dalla pagina History.aspx.
• History.aspx: dato l'ID di una pagina mostra l'elenco delle sue diverse versioni, dando la
possibilità di visualizzarle o di confrontarne le differenze.
• Pages.aspx: è una delle due pagine aspx che permettono di visualizzare l'elenco delle pagine
wiki presenti nel database. Questa fornisce un elenco delle pagine suddivise in ordine
alfabetico.
• PageCategory.aspx: analogamente alla pagina precedente visualizza l'elenco delle pagine wiki,
suddividendole per categoria, la quale viene selezionata da una dropdown list.
52
WikiClientiBL
Questa classe contiene della logica che per la sua complessità è stata separata dalle classi che
la utilizzano, in modo tale da conferire al codice una struttura più ordinata. In particolare contiene dei
metodi che vengono utilizzati per implementare le seguenti funzionalità:
• Costruzione dinamica degli editor
◦ public Table CreateEditorTable(Table et, WikiData wd, Dictionary<string,AttributeProperties> ap)
◦ public TableRow CreateEditorRow(string aName, string aValue, string aType, bool required)
◦ protected TableCell WrapInCell(Control c)
◦ protected void IntegerType_ServerValidate(Object objSource, ServerValidateEventArgs objArgs)
◦ protected void DoubleType_ServerValidate(Object objSource, ServerValidateEventArgs objArgs)
◦ protected void DateType_ServerValidate(Object objSource, ServerValidateEventArgs objArgs)
◦ protected void cal_SelectionChanged(Object objSource, EventArgs evtArgs)
◦ protected void calTextBox_SelectionChanged(Object objSource, EventArgs evtArgs)
◦ protected void attrValue_TextChanged(Object objSource, EventArgs evtArgs)
53
◦ public Control FindChildControl(Control container, string name)
Gli editor generati dinamicamente di cui si è parlato nella descrizione dei controlli ascx vengono
creati dal metodo CreateEditorTable, che restituisce un oggetto Table a partire dai dati della pagina wiki
(WikiData) e dallo schema degli attributi che contiene.
Questa generazione dinamica è complessa, dal momento che non solo vengono costruiti in
codebehind i controlli di inserimento (TextBox, Calendar) ma anche dei controlli di validazione dei dati
(ASP.NET validators, metodi del tipo _ServerValidate) in funzione dello schema dell'attributo (il tipo, se è
un campo obbligatorio o meno).
Inoltre per ogni controllo vengono aggiunti anche i metodi che si occupano della gestione degli
eventi dei controlli di inserimento, da cui la necessità di definire direttamente gli event handlers da
aggiungere al controllo (metodi del tipo _SelectionChanged e _TextChanged).
• Evidenziamento delle differenze
◦ public string GetTextDifferences(string t1, string t2)
◦ public DataTable GetAttributesDifferences(Hashtable h1, Hashtable h2)
Nella pagina Diff.aspx vengono evidentiate le differenze tra due versioni della stessa pagina wiki
presente nello storico. La logica che effettua questo evidenziamento è contenuta nei due metodi
soprastanti.
GetTextDifferences prende in ingresso due testi wiki da confrontare, tornando come risultato il
primo testo in cui però vengono evidenziate le differenze rispetto al secondo. E' quindi importante
l'ordine dei due parametri.
GetAttributesDifferences costruisce e ritorna una DataTable dal momento che, implementando

l'interfaccia DataSource, è poi possibile utilizzarla direttamente per effettuare il databinding dal lato di
interfaccia grafica. Ovviamente la DataTable costruita è tale da presentare le differenze tra i valori degli
attributi contenuti nell'hashtable del primo parametro, rispetto a quelli contenuti nel secondo.
• Gestione titoli di una pagina
◦ public string PageName(string title)
◦ public string PageTitle(WikiData wd, string titleExpression)
Nella descrizione dell'applicativo si era fatto cenno alla omologazione dei titoli delle pagine wiki
appartenenti alla stessa categoria. L'omologazione viene regolata da un'espressione, contenuta nella
tabella Category all'interno del database.
Il metodo PageTitle prende in ingresso tale espressione, in cui è possibile indicare in modo
54
parametrico gli attributi che vi si vogliono includere nel titolo utilizzando il carattere dollaro. Se ad
esempio una categoria presenta tre attributi come il codice cliente, il nome e il cognome dello stesso,
allora l'espressione “Cliente $Codice - $Nome $Cognome” genererà dei titoli del tipo:
Cliente XYZ123 – Mario Rossi
Cliente HJK456 – Stefano Bianchi
Il metodo PageName invece serve per generare il nome della pagina a partire dal titolo. Esso
viene creato secondo la sintassi CamelCase: una stringa formata dall'insieme delle parole che la
compongono disposte una di seguito all'altra, con il primo carattere di ogni parola maiuscolo e il resto in
minuscolo (ad esempio la parola CamelCase è scritta in CamelCase).
Testo Wiki
Entreremo ora nel merito del testo wiki, il quale segue una sintassi specifica. Dal momento che
esistono varie forme di dialetti di questa tipologia di linguaggio, è doveroso specificare la sintassi che è
stata utilizzata.
Nella lista sottostante viene riportata, sotto forma di esempio, la sintassi wiki e la corrispondente
formattazione del testo.
• ''Italics'' Testo in corsivo
• __Underline__ Testo sottolineato
• **Bold** Testo in grassetto
• =Center= Testo centrato
• !Heading1 Testo formattato in intestazione1 (tag HTML h1)
• !!Heading2 Testo formattato in intestazione2 (tag HTML h2)
• !!!Heading3 Testo formattato in intestazione3 (tag HTML h3)
• ---Line Linea di separazione
• +Bullet List Elemento di un elenco puntato
• #Number List Elemento di un elenco numerato
55
• {Named Link} Link HTML
• [Wiki Link] Link wiki (autoreferenziale all'applicazione)
• <<custom>> Tag custom HTML
Il testo viene salvato nel data base secondo questa sintassi, e viene trasformato in testo HTML
da un parser wiki. Questo è stato implementato all'interno della classe WikiParser; nell metodo statico
string WikiMarkupToHtml(string wiki). Il parser è stato costruito mediante l'utilizzo di espressioni regolari.
Per facilitare l'inserimento del testo wiki da parte degli utenti è stato creato un editor di testo wiki
mediante l'utilizzo di javascript, dal momento che il tutto avviene lato client. Questo è stato realizzato
tramite un sistema di sostituzione del testo selezionato nella casella di testo wiki, che viene richiamato
da opportuni pulsanti-link in testata.
56
57
58
59
60
61
62
63
64
65
3.4 Implementazione del Presentation Layer
In questo paragrafo ci occuperemo dell'implementazione del presentation layer, in particolare sia

per quanto riguarda la realizzazione delle singole pagine che per la struttura del sito web.
Nel paragrafo di progettazione abbiamo avuto modo di considerare il diagramma di stato che
descrive come l'utente possa passare da uno stato applicativo ad un altro. Dal punto di vista
realizzativo gli stati precedentemente illustrati corrisponderanno a delle pagine, che abbiamo già avuto
modo di esaminare nei paragrafi precedenti.
Dalla trasposizione del diagramma di stato in pagine aspx otteniamo immediatamente la così
detta mappa del sito web, che offre uno schema della navigabilità all'interno dello stesso.
Navigabilità
Per quanto riguardo lo stato di partenza astratto (Start) si è deciso di associarlo allo stato di
visualizzazione dell'elenco delle pagine in ordine alfabetico, che costituirà quindi il punto di partenza.
La navigabilità a partire da questo stato è realizzata attraverso un apposito menù laterale che
consente di spostarsi in tutti e quattro gli stati applicativi indicati nel diagramma, e da lì a quelli
successivi.
Il menù è stato fatto tramite un controllo ascx che viene incluso in tutte le pagine; in questo modo
è possibile modificarlo in qualsiasi momento estendendo immediatamente le modifiche a tutto il sito.
Menù
Nei paragrafi precedenti abbiamo già descritto le diverse pagine dal punto di vista della business
logic; ora invece le descriveremo dal punto di vista dell'interfaccia grafica e della navigabilità.
Sotto vengono indicate le pagine aspx (tra parentesi il nome dello stato applicativo che
realizzano). Per un'immediata descrizione dell'interfaccia grafica si vedano in proposito gli screenshots
a fine capitolo.
66
• New.aspx (NewPage)
• Edit.aspx (EditPage)
• Page.aspx (ViewPage)
• Admin.aspx (Admin)
• PageCategory.aspx (Pages)
• Pages.aspx (PagesAZ)
• History.aspx (History)
• HistoryPage.aspx (ViewHistory)
La mappa del sito risultante è la seguente:
URL Rewriting
Il meccanismo dell'URL rewriting descritto nei paragrafi precedenti è stato realizzato grazie a un
componente open source gratuito, che è possibile utilizzare anche per finalità commerciali.
67
Si tratta di URLRewritingnet, realizzato da Albert Weinert e Thomas Bandt, basato sul modulo
HTTP per il reindirizzamento di Fabrice Marguerie.
Una volta installato il suo utilizzo è molto semplice. E' sufficiente definire all'interno dell'XML di
configurazione dell'applicazione (il file web.config) le regole di sovrascrittura degli URL mediante la
compilazione di appositi tag xml.
<urlrewritingnet rewriteOnlyVirtualUrls="true" … >

<rewrites>
<add name="WikiRule" virtualUrl="^~/wiki/(.*)"
destinationUrl="~/Page.aspx?pageName=$1" … />
<add name="HistoryRule" virtualUrl="^~/history/(.*)"
destinationUrl="~/PageHistory.aspx?pageID=$1" … />
<add name="EditRule" virtualUrl="^~/edit/(.*)"
destinationUrl="~/Edit.aspx?pageid=$1" ignoreCase="true"/>
</rewrites>
</urlrewritingnet>
Ogni regola definisce da un lato tutti gli URL virtuali che verranno visualizzati dal browser,
attraverso l'utilizzo di espressioni regolari (ad esempio ~/wiki/(.*)), e dall'altro lato la tipologia degli
URL che dovranno essere sovrascritti (come ad esempio ~/Page.aspx?pageName=$1).
In questo caso quindi, come previsto, tutti gli indirizzi del tipo ~/Page.aspx?
pageName=NomePagina si trasformeranno in questo modo: ~/wiki/NomePagina.
CSS
La parte degli stili grafici è stata realizzata mediante un foglio di stile CSS, che definisce in modo
separato dal resto del codice le classi di stile, che sono state poi applicate ai vari controlli ASP.NET.
68
Capitolo 4. Cenni di porting su un framework aziendale
4. Cenni di porting su un framework aziendale
In questo capitolo verranno dati dei cenni, a titolo di esempio, di un porting dell'applicazione web
su un framework aziendale realmente esistente, appartenente a un cliente dell'azienda committente.
Come sarà possibile constatare anche nel capitolo conclusivo di questo lavoro questa fase non è
stata pienamente realizzata, principalmente per questioni legate al tempo a disposizione e alla
complessità del framework che andremo a descrivere di seguito.
Ad ogni modo la parte di lavoro descritta in questo capitolo permette di avere a disposizione un
esempio di come l'applicazione web presentata possa giungere in produzione, in uno dei tanti possibili
ambienti lavorativi su cui potrà essere adattata.
4.1 Il framework aziendale
Gran parte del lavoro svolto in questa fase è stato dedicato all'analisi del framework aziendale,
che per la sua complessità ha impegnato diverso tempo. Esso infatti consta di una solution .NET
formata da diversi progetti, ognuno adibito a una specifica funzione.
Descriveremo tuttavia il framework aziendale schematicamente, riducendolo alle funzionalità di

interesse per comprendere la fase di porting e tralasciando quelle più specifiche.
Architettura del framework
A livello architetturale il framework si presenta nella classica tripartizione di data layer, business
logic e presentation layer (architettura three-tier), utilizzata anche nel lavoro presentato in questa tesi.
69
Per quanto riguarda la comunicazione tra i diversi livelli di astrazione (messaggi) il framework
utilizza dei moduli appositamente adibiti (data entitities) che essendo privi di comportamento constano
in semplici strutture dati.
La somiglianza tra l'architettura dell'applicazione che è stata presentate e quella del framework
che stiamo illustrando è dovuta a due ragioni principali: la prima è che l'architettura three-tier è di per sè
uno standard nello sviluppo di applicazione strutturate; la seconda è che entrambi i lavori risentono
dello stile di programmazione dell'azienda committente.
Sostanzialmente possiamo descrivere il framework come l'implementazione logica di un

diagramma di stato. Due sono quindi i moduli che principalmente ci interessano al fine di comprenderne
il funzionamento: quello adibito alla funzione di stato applicativo, e quello invece che determina il
comportamento del flusso dello stesso.
I primi prendono il nome di State (stato) e i secondi di Flow Controllers (controllori di flusso).
70
Ogni State quindi ha il suo Flow Controller che gli permette, a fronte di un determinato ingresso
(quindi di un evento scatenato da un comando da parte dell'utente) , di eseguire un'operazione (uscita)
e di cambiare stato.
Lo state invece ha il compito di descrivere lo stato applicativo dal punto di vista dell'interfaccia
grafica. Un aspetto interessante di questo framework è che l'interfaccia grafica è stata scissa in due
livelli: uno astratto, che chiameremo interfaccia astratta, e uno concreto, che è quello vero e proprio.
L'aver scisso l'interfaccia in questi due livelli permette di separare completamente l'applicazione
dal modo in cui essa si presenta, pur tuttavia lasciando la possibilità al programmatore di descrivere
l'interfaccia concreta.
Essa infatti, a partire dall'interfaccia astratta, viene costruita mediante l'utilizzo di particolari
moduli chiamati builders (costruttori). In funzione della tipologia di interfaccia concreta (che può essere
un'interfaccia web, un'interfaccia da applicazione desktop, ecc) i builders costruiscono interamente il
presentation layer.
71
Dal punto di vista della riusabilità del codice questo meccanismo è molto utile, soprattutto per
un'eventuale trasformazione di un'applicazione da un ambiente come quello desktop a quello web (o
viceversa).
Il cambiamento infatti consisterebbe nella sostituzione del livello dei builder adibiti alla creazione
dell'interfaccia tipica di un'applicazione desktop con quelli specializzati nella costruzione di
un'interfaccia web.
L'interfaccia astratta infatti è formata da elementi tipici delle interfacce grafiche che ricorrono sia
nella parte desktop che in quella web: pulsanti, campi di testo, etichette, panelli, tab, menù, ecc.
Riusabilità del codice
In questo paragrafo descriveremo quali parti dell'applicativo si prestano a essere riutilizzate

all'interno del framework e quali invece richiedono un intervento o una modifica. Dal punto di vista
concettuale l'intero lavoro preserva infatti tutto il suo valore, ma ciò non vale dal punto di vista
dell'implementazione effettiva.
Prenderemo come riferimento per queste considerazioni lo stack dei livelli di astrazione
presentato nel capitolo dell'implementazione logica.
72
Tabelle
Viste Database Management System

(MS SQL Server)
Stored Procedures
SqlConnection, DataReader, DataAdapater,

SqlCommand, DataTable Classi fornite da ADO.NET
WikiClientiDL, WikiData, AttributeProperties
Classi scritte in C#
WikiCLientiBL, WikiParser
Codebehind controlli (ascx.cs)
Classi scritte in C# (Codebehind)

Codebehind pagine (aspx.cs)
Controlli ascx
Elementi scritti in linguaggio ASP.NET

Pagine aspx, CSS
Logica portabile
Logica da modificare
Facendo riferimento allo schema risulta immediatamente chiaro che la parte relativa alla base di
dati potrà essere riutilizzata: tabella, viste e stored procedures sono già pronte così come sono per
essere integrate all'interno di un DBSM Microsoft SQL Server, che è lo stesso utilizzato dal framework
aziendale.
Anche per quanto riguarda il data layer vale questo discorso; inoltre le classi che si sono
utilizzate per contenere i dati delle pagine Wiki e delle proprietà degli attributi possono fungere da
dataentities.
Per quanto riguarda la logica di businness invece, se il parser wiki può essere comunque
73
riutilizzato come modulo a sé stante per le funzioni di conversione, la stessa cosa non si può dire per la
parte che realizza la costruzione dinamica dell'interfaccia (editors) in funzione degli schema degli
attributi di una pagina.
Infatti il framework utilizza come abbiamo visto un particolare meccanismo per la creazione della
stessa; la businness logic che si preoccupa di effettuare questo processo dovrebbe quindi essere
riscritta per permettere la creazione (sempre dinamica) dell'interfaccia astratta.
In particolare possiamo dire che questa è definita mediante l'utilizzo di un modulo che realizza
uno schema ad albero, struttura tipica delle GUI. Ogni elemento grafico viene rappresentato come un
nodo contenitore che può includere a sua volta altri nodi (ad esempio panel, containers, ecc) o foglie
dell'albero (pulsanti, combobox, editor, ecc). Ad ogni elemento sono poi associati i comandi che
permetteranno a livello di controllore di flusso di ridirigere l'applicazione su determinati stati.
4.2 Cenni di porting
Volendo elencare le modifiche necessarie per portare la logica del nostro applicativo a questo
particolare framework, che presenta una struttura piuttosto rigida alla quale doversi adeguare,
otteniamo i seguenti punti:
• Installazione del database dell'applicazione
• Creazione dei moduli State che rispecchiano gli stati applicativi
• Creazione per ogni State di un Flow Controller per la gestione del flusso
• Riscrittura della logica di costruzione dinamica dell'interfaccia grafica
Per quanto riguarda il primo punto si effettuerà semplicemente un porting del database,
riproponendolo (salvo future esigenze) essenzialmente inalterato.
La creazione degli stati applicativi è stata già effettuata in fase di progettazione concettuale, per
questo motivo riproporremo il diagramma di stato già utilizzato precedententemente (lo riportiamo nella
figura sottostante).
74
Il porting completo quindi dovrà includere la realizzazione di nove State e di altrettanti Flow
Controllers (omettiamo lo stato di partenza); i primi dovranno riproporre la costruzione dell'interfaccia
grafica illustrata nei capitoli precedenti, mentre i secondi dovranno ridirigerne il flusso.
Dei punti illustrati per la realizzazione effettiva del porting sono stati realizzati in una prima
versione tre stati applicativi, considerati quelli di maggiore importanza:
• Visualizzazione delle pagine (ViewPage)
• Editing delle pagine (EditPage)
• Creazione di una nuova pagina (NewPage)
Per quanto riguarda la riscrittura della logica di creazione dinamica degli editor si è ricorso al fatto
che una volta definita dinamicamente l'interfaccia astratta il framework si occupa della realizzazione
effettiva dei controlli tramite i builder, anche per quanto riguarda i vincoli di validità sugli stessi.
Possiamo dire che sfruttando questa generazione automatica del framework l'implementazione
75
di questa parte è stata molto meno onerosa di quanto lo è stata per l'applicazione web costruita da
zero.
Per concludere seguono nelle pagine successive alcuni screenshots d'esempio.
76
77
78
Capitolo 5. Conclusione
5. Conclusione
L'obiettivo principale, cioè la creazione di un sistema che permetta la formazione di un knowledge

base, di consultarlo e modificarlo è stata pienamente raggiunta.
A questo obiettivo si affiancano quelli espressi dalle caratteristiche aggiuntive dell'applicazione,

come la possibilità di amministrare la tipizzazione delle pagine wiki e la gestione dello storico e del
versioning delle stesse.
L'obiettivo che non è stato pienamente raggiunto è l'implementazione dell'applicazione su un

framework aziendale. Le cause del mancanto adempimento di questo obiettivo sono dovute
principalmente a due fattori: la complessità del framework aziendale su cui effettuare il porting, e il
tempo a disposizione.
Diverso tempo infatti è stato richiesto dallo studio del framework parzialmente descritto nel
capitolo precedente, che ha portato alla sola implementazione delle funzionalità di inserimento e di
editing di una nuova pagina.
L'applicazione web presentata in questa tesi realizza un sistema wiki volto alla formazione di un
database che immagazzini i dati relativi alle informazioni aziendali in possesso dei dipendenti.
Questi hanno la possibilità di consultare le pagine esistenti tramite un duplice indice, che
presenta le pagine o in funzione della categoria o tramite una suddivisione alfabetica delle stesse.
Soprattutto gli utenti hanno modo di modificare una pagina già esistente o di inserirne una nuova.
Le pagine inoltre sono tipizzate: accanto al testo wiki, spazio totalmente libero in cui gli utenti possono
inserire le informazioni senza costrizioni, compaiono dei campi (obbligatori e non) da compilare, in
modo tale che vi siano sempre delle informazioni di categoria esplicitamente richieste.
L'applicazione da la possibilità di creare nuove categorie, e di creare i campi associati che le

descrivono. I campi sono tipizzati (stringhe, interi, campi data, valuta, double) e possono essere
obbligatori o non obbligatori.
In funzione delle caratteristiche degli attributi l'applicazione genera dinamicamente dei controlli
volti a preservare l'integrità dei dati. Nel caso la descrizione di un attributo sia assento l'applicazione
79
tratterà il dato come se fosse un attributo di tipo stringa.
Per uniformare gli URL alla filosofia wiki, secondo cui la parte finale dello stesso rappresenta il
nome della pagina, è stato utilizzato un sistema di URL rewriting. Viene gestito anche il problema delle
ambiguità dovute a omonimia tramite un sistema di reindirizzamento.
Oltre a queste caratteristiche esiste una cronologia che immagazzina le diverse versione di una
pagina, in modo che a causa delle future modifiche i dati passati non vengano compromessi. Oltre a
questo, vi è la possibilità di confrontare tra loro le diverse versioni di una pagina per evidenziarne le
differenze, che compariranno evidenziate.
Forniremo ora un breve resoconto dal punto di vista quantitativo del lavoro svolto. La
realizzazione dell'applicativo, dal punto di vista della realizzazione tecnica, comprende (esclusa la parte
relativa al porting in produzione):
• 7 Tabelle
• 7 Viste
• 32 Stored Procedures
• 15 Classi
• 10 Pagine aspx
• 8 Controlli web ascx
• 600 Linee di codice aspx
• 435 Linee di codice SQL
• 2300 Linee di codice C#
Nel capitolo introduttivo era stata riportata una lista delle attività da svolgere in itinere per
raggiungere l'obiettivo principale della tesi. Per concludere la riportiamo, smarcando le attività che sono
state portate a termine e quelle ancora in sospeso:
 Analisi del problema con riferimento alla soluzione wiki
 Studio dei sistemi wiki
 Ricerca dei sistemi wiki open source disponibili sul web (stato dell'arte)
 Analisi dei sistemi wiki open source e isolamento delle features principali
 Progettazione del sistema di tipizzazione delle pagine wiki
80
 Studio delle tecnologie Microsoft ASP.NET
 Progettazione dell'architettura dell'applicazione web (three-tier)
 Progettazione della base di dati (modello Entity-Relationship)
 Progettazione della struttura del sito web
 Implementazione logica della base di dati
 Programmazione del data layer (stored procedures e classi)
 Implementazione di un parser wiki
 Programmazione della logica di inserimento, modifica e cancellazione dati
 Implementazione della logica di tipizzazione delle pagine wiki
 Test dell'applicativo
 Studio e analisi di un framework aziendale
 Integrazione dell'applicativo con un framework aziendale
I lavori futuri che potranno interessare questo progetto sono in primo luogo l'ultimazione
dell'integrazione dell'applicazione web con il framework aziendale (porting in produzione), per poi avere
futuri sviluppi per quanto riguarda il sistema di ricerca delle informazioni contenute nel database.
Di particolare interesse è anche l'idea di normalizzare le relazioni tra pagine wiki create tramite
link ipertestuali. Infatti essi costituiscono una vera e propria relazione semantica descritta liberamente
dall'utente che, al momento, rimane contenuta (e isolata) all'interno del testo wiki.
La possibilità di estrarla con un modulo ad hoc per strutturare questa preziosa informazione
direttamente nel database è senz'altro una prospettiva interessante, perchè realizza un sistema di
meta-relazioni create in modo dinamico dagli utenti, che possono essere utilizzate in modo efficiente
dal sistema di ricerca.
Un sistema di ricerca in grado di tenere conto di questa tipologia di relazioni può essere utilizzato
in modo molto efficiente per generare non solo delle ricerche estemporanee, ma anche come motore
per la creazione di report su indagini statistiche che coingono una particolare tipologia di oggetti,
relazionati tra loro in un dato modo (per esempio si può fare una ricerca mirata su tutte le persone, che
hanno un padre con un determinato lavoro, laddove padre e figlio sono relazionati mediante le relazioni
dinamiche di cui sopra, e così via).
Le ultime considerazioni le vorrei dedicare a delle conclusioni soggettive.
81
Questo lavoro è stato un'esperienza formativa molto utile che mi ha permesso in primo luogo di
entrare in contatto con il mondo del lavoro, con le sue esigenze e le metodologie di approccio alle
problematiche reali.
Inoltre ciò mi ha permesso non solo di integrare le conoscenze tecniche che l'Università di Trieste
ha saputo fornirmi con quelle derivate da questo lavoro, ma anche di avere un primo sbocco lavorativo
presso l'azienda committente.
In conclusione reputo questa esperienza un ponte soddisfacente tra quella che è stata la mia
esperienza formativa universitaria e una prima occupazione in ambito lavorativo.
82
Capitolo Bibliografia
Bibliografia
Libri
Jim Keogh, “ASP.NET 2.0 tecniche e soluzioni“, McGrawHill, Maggio 2006
Daniele Bochicchio, “ASP.NET 2.0 per tutti”, Scardovi, Marzo 2007
Derfler Frank J. "Introduzione a Microsoft SQL Server 2005 per sviluppatori", 2005
Adrian Turtschi, "C# .NET - Programmazione Web", McGrawHill, ottobre 2002
Siti web
http://msdn.microsoft.com/ (.NET Framework development center)
http://www.aspitalia.com/ (ASP Italia)
http://it.wikipedia.org/wiki/Wikipedia/ (WikiPedia)
http://prontowiki.sourceforge.net/ (Pronto wiki)
http://www.screwturn.eu/ (ScrewTurn Wiki)
http://wiki.developer.mindtouch.com/Deki_Wiki (DekiWiki Multitouch)
http://www.high-beyond.com/ (Perspective wiki engine)
http://www.flexwiki.com/ (Flex Wiki)
www.dynamick.it (Web 2.0 – una definizione in 10 punti)
http://www.microsoft.com/ (Web 2.0: Internet volta pagina)
http://www.web-20.it/ (Web 2.0 - Internet è cambiato)
http://www.paulgraham.com/web20.html (Web 2.0)
http://www.oneweb20.it (Web 2.0 & Aziende)
http://www.pmi.it (Il Web 2.0 nelle aziende)
http://www.w3schools.com/ (W3C Tutorials)
83
Capitolo Bibliografia
Ringraziamenti
Ringrazio i miei familiari e i miei amici per il supporto che hanno saputo darmi in questo
periodo che porta alla conclusione dei miei studi, a Marco Del Rosso e lo Studio Delta per
avermi dato l'opportunità di trovare un impiego prima ancora di averli conclusi, e al mio
relatore Maurizio Fermeglia per il piacevole rapporto di collaborazione che è riuscito a
creare durante la realizzazione di questa tesi.
84

Tesi Corona

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Tesi Corona

Transféré par

Droits d'auteur :

Formats disponibles

Università degli Studi di Trieste

L'INFLUENZA DEL WEB 2.0 IN AMBITO AZIENDALE:

Roberto Corona Prof. Maurizio Fermeglia

In questo capitolo introduttivo presenteremo il progetto che si andrà a sviluppare e realizzare in

L'esigenza concreta che ha motivato questo lavoro è quella di immigazzinare le informazioni e la

Vista la volontà di sviluppare l'applicativo internamente all'azienda committente, si sono presi in

Per raggiungere l'obiettivo principale si è deciso di proseguire suddividendo la realizzazione del

 Analisi del problema con riferimento alla soluzione wiki

 Studio dei sistemi wiki

 Progettazione del sistema di tipizzazione delle pagine wiki

 Studio delle tecnologie Microsoft ASP.NET

 Progettazione dell'architettura dell'applicazione web (three-tier)

 Progettazione della base di dati (modello Entity-Relationship)

 Progettazione della struttura del sito web

 Implementazione logica della base di dati

 Programmazione del data layer (stored procedures e classi)

 Implementazione di un parser wiki

 Programmazione della logica di inserimento, modifica e cancellazione dati

 Implementazione della logica di tipizzazione delle pagine wiki

 Integrazione dell'applicativo con un framework aziendale

Il linguaggio di programmazione da utilizzare non è stato imposto, e in proposito si è scelto di

Capitolo 1: Questo capitolo introduttivo proseguirà con la descrizione di alcuni cenni

Capitolo 2: Il secondo capitolo si concentrerà sugli aspetti legati all'analisi e alla

Capitolo 3: Il terzo capitolo verterà sull'implementazione vera e propria di quanto è stato

Capitolo 4: Il capitolo quattro descrive un'esempio di come l'applicativo sia stato

1.1 Cenni dell'evoluzione del Web

• Reperibilità delle informazioni

• Possibilità di produzione dei contenuti (authoring)

• Possibilità di condivisione dei contenuti (sharing)

• Sviluppo del social networking, fondazione di community

La produzione di contenuti, annessa a una prima forma di community, si trovava in germe

Se prima la mediazione di un professionista era necessaria allora l'utente poteva, disponendo

ADSL) e la diminuzione dei costi dei servizi internet in genere.

Internet diventa il naturale prolungamento del personal computer.

Sostanzialmente un wiki è un sito web (o in genere un'insieme strutturato di documenti

I campi di applicazione di questa tecnologia sono principalmente orientati alla creazione di

Wiki in ambito aziendale

Nel presente capitolo verranno esposti la progettazione e lo sviluppo dell'applicazione web

2.1 Analisi dei Progetti OpenSource

In seguito ciò ha permesso di identificare le funzionalità di maggiore interesse offerte dalla

• Visualizzazione dei contenuti

• Editing dei contenuti in stile wiki

• Gestione della cronologia dei contenuti (versioni di una stessa pagina)

• Visualizzazione delle differenze tra le versioni della stessa pagina

La ricerca è stata realizzata tramite Internet e ha permesso di individuare i seguenti progetti

• ProntoWiki: Progetto realizzato da Clay Alberty. Si presenta immediatamente come un

• FlexWiki: Come ProntoWiki questo motore è leggero, e si presenta in un layout molto

ScrewTurn Deki Wiki

2.2 Descrizione dell'applicativo

Tipizzazione delle Pagine

Si tratta della possibilità di specializzare le pagine, conferendo loro una categoria di

omettere, anche riportando una biografia dettagliata.

• String (che è il tipo di default)

Un sistema di generazione automatica dei controlli di interfaccia e di validatori specializzati

Costruzione degli URL

Omologazione dei titoli di pagina

2.3 Progettazione dell'applicativo

La progettazione dell'applicativo è stata effettuata seguendo l'architettura three-tier, che suddivide

2.4 Progettazione del DB: diagramma Entity-Relationship

Trattandosi di un database relazionale utilizzeremo, come schema per la progettazione

Esso consente, mediante una rappresentazione a blocchi, di descrivere le entità che

• Page Cotntiene i dati di una singola pagina

• PageHistory Contiene i dati di una pagina dello storico