Thesis full text PDF - Politecnico di Milano

Politecnico di Milano
Polo Territoriale di Como
Scuola di Ingegneria dell’Informazione
Corso di Studi in Ingegneria Informatica
Dai requisiti alla progettazione di reti sociali
per il web
Tutor universitario: Prof. Marco Brambilla
Elaborato finale di:
Davide Maria Filippo Ripamonti matr. 702249
A.A. 2009-2010

Indice
1 Introduzione 5
2 Background 9
2.1 Goal diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.1 Framework basati su goal diagram . . . . . . . . . . . 10
2.1.2 KAOS . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.3 i*/Tropos . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3 OODBMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4 Apache Tomcat . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.5 Altre tecnologie . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3 Approccio 21
3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2 Requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3.1 Relazioni fra gli utenti . . . . . . . . . . . . . . . . . . 29
3.3.2 Interazione tra gli utenti . . . . . . . . . . . . . . . . . 32
3.3.3 Messaggi . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.3.4 Organizzazione . . . . . . . . . . . . . . . . . . . . . . 33
3.3.5 Azioni del sistema . . . . . . . . . . . . . . . . . . . . 36
3.3.6 Interazione sui contenuti . . . . . . . . . . . . . . . . . 37
3.3.7 Estensioni del sistema . . . . . . . . . . . . . . . . . . 38
3.4 Implementazione . . . . . . . . . . . . . . . . . . . . . . . . . 39
3

4 INDICE
4 Implementazione 41
4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2 Selezione delle features . . . . . . . . . . . . . . . . . . . . . . 42
4.3 Mappatura delle classi . . . . . . . . . . . . . . . . . . . . . . 43
4.4 Gestione UML . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5 PoliBook 47
5.1 Obiettivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.2 Architettura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.3 Realizzazione . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.3.1 Scelta dei requisiti . . . . . . . . . . . . . . . . . . . . 48
5.3.2 Design e rifinitura . . . . . . . . . . . . . . . . . . . . . 49
5.3.3 Implementazione e interfaccia grafica . . . . . . . . . . 49
5.4 Valutazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6 Conclusione 61
6.1 Sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Bibliografia 62

Capitolo 1
Introduzione
Nell’era del web 2.0, caratterizzata sempre più dall’interazione tra gli utenti e
dalla creazione e scambio di contenuti da parte di questi ultimi, i protagonisti
indiscussi di questa evoluzione digitale sono i social network.
Al giorno d’oggi chi naviga per la rete possiede almeno uno tra un profilo
su Facebook, un account di YouTube, una pagina personale su MySpace o,
continuando l’elenco tra i social network più popolari, si scambia link e mes-
saggi con Twitter, condivide le proprie foto su Flickr, cerca e consiglia libri
su Anobii, ascolta musica su Last.fm o, in campo professionale, è registrato
a LinkedIn.
Essenzialmente un social network è una applicazione web in cui è possibile
creare un profilo personale, costruire la propria lista di amici inserendo gli
utenti della comunità con i quali si vuole instaurare un rapporto ed esaminare
le amicizie degli utenti amici per ampliare la propria rete sociale.
Oltre a questi elementi base sono stati introdotti i gruppi e le raccoman-
dazioni per favorire la ricerca di persone, e nuovi e originali meccanismi per
aumentare il grado di interazione e utilità del sito web.
La forza e il successo delle reti sociali consistono nella condivisione del-
le esperienze e dei contenuti, nella possibilità di stringere nuove amicizie e
collaborazioni con utenti che hanno gli stessi interessi, nella velocità di dif-
fusione delle informazioni e delle conoscenze e, non ultimo, nel divertimento
e intrattenimento coi propri amici reali e virtuali.
5

6 CAPITOLO 1. INTRODUZIONE
Per diverse ragioni quali ad esempio la necessità di avere a disposizione un
sistema più flessibile per i propri scopi, un controllo maggiore sulla sicurezza
e sulla privacy dei contenuti, il bisogno di funzionalità aggiuntive o la libertà
di poter sviluppare componenti integrativi per dei sistemi già esistenti, può
nascere l’esigenza di dover creare un social network ad hoc.
L’obiettivo principale di questa tesi è quello di mostrare una possibile so-
luzione a questo problema la quale permetta la creazione di un social network
partendo dall’analisi dei requisiti, passando per il design e infine giungendo
all’implementazione nel modo più produttivo possibile.
L’idea è quella di selezionare i requisiti desiderati utilizzando un sem-
plice e intuitivo goal diagram, contenente le features tipiche e particolari
individuate tramite l’analisi di molti e diversi social network.
Dopo aver effettuato le proprie scelte, un tool creato appositamente si
occupa di mappare le features su dei modelli UML, nello specifico generan-
do dei class-diagrams, i quali modellizzano la logica di funzionamento del
sistema.
A questo punto è possibile raffinare il design, per poi generare gli scheletri
delle classi, o associare ad ogni classe nel modello la classe completa se già
esistente, e quindi procedere con l’implementazione.
La tesi è strutturata nei seguenti capitoli:
• Capitolo 2: viene presentato il background concettuale, le soluzioni
proposte in precedenza e le tecnologie utilizzate.
• Capitolo 3: viene descritto nei particolari l’approccio al problema con
le varie fasi per giungere alla soluzione.
• Capitolo 4: viene mostrato il framework utilizzato e in particolare l’im-
plementazione degli strumenti di selezione dei requisiti e di trasforma-
zione in diagrammi UML.

• Capitolo 5: viene illustrata la creazione di un social network col metodo
proposto e il suo sviluppo dalla selezione dei requisiti all’implementa-
zione finale funzionante.
• Capitolo 6: conclusione con considerazioni finali e idee per possibili
sviluppi futuri.
7

8 CAPITOLO 1. INTRODUZIONE

Capitolo 2
Background
In questo capitolo vengono presentate le tecnologie utilizzate sia nell’approc-
cio al problema affrontato da questa tesi, che nella scelta architetturale ese-
guita in fase di implementazione. Inoltre vengono descritti alcuni framework
preesistenti nell’ambito dell’analisi dei requisiti.
2.1 Goal diagram
Un goal diagram [1] è un modello usato nella specifica dei requisiti costituito
essenzialmente da una gerarchia di elementi, i goals, i quali rappresentano gli
obiettivi che il sistema in esame deve avere con un dettaglio crescente mano
a mano che si procede nella decomposizione. Al contrario, più si scende in
profondità e più diminuisce il livello di astrazione.
Pertanto si può affermare che un goal è raggiunto quando tutti i goals
che lo compongono sono stati raggiunti.
Il diagramma si sviluppa e cresce traducendo in obiettivi le richieste e
le necessità degli stakeholders, analizzando sistemi precedenti o simili, ed
elaborando e dettagliando sempre più i goals già inseriti.
La modellazione tramite goals permette di concentrarsi sull’identificazio-
ne dei problemi e sull’esplorazione delle soluzioni e delle alternative all’interno
del sistema.
Si possono individuare due principali tipi di goals: gli hard-goals e i soft-
goals. Gli hard-goals indicano i requisiti funzionali del sistema, ossia le fun-
9

10 CAPITOLO 2. BACKGROUND
zionalità che il sistema sarà in grado di fornire; i soft-goals, o fuzzy-goals, rap-
presentano invece i requisiti non funzionali, e quindi la qualità, le prestazioni
e l’usabilità in generale.
Oltre ai goals nel diagramma trovano spazio i link, le linee di collegamento,
che specificano se la dipendenza tra due goals è necessaria per il raggiungi-
mento dell’obiettivo (AND) o rappresenta una alternativa o una funzionalità
non obbligatoria (OR), e i tasks, ovvero le modalità per risolvere alcuni degli
obiettivi.
La modellazione dei requisiti tramite goals rientra quindi nella fase pre-
liminare di progettazione del sistema ed è quella che precede e introduce i
diagrammi UML.
I punti di forza di questo approccio sono la leggibilità e l’intuitività, non-
ché la possibilità di poter raffinare costantemente il modello e la visione
d’insieme sull’intero sistema.
2.1.1 Framework basati su goal diagram
Vengono ora descritti due framework usati in fase progettuale che utilizzano
il goal diagram come strumento principale per la specifica dei requisiti [2].
2.1.2 KAOS
KAOS [3], acronimo di Knowledge Acquisition in autOmated Specification
o Keep All Objects Satisfied, è un approccio goal oriented alla specifica dei
requisiti fornito di un ricco insieme di tecniche di analisi formali.
Questo framework permette un ragionamento su diversi livelli: semifor-
male per la modellazione e la strutturazione dei goals, qualitativo per la
selezione delle alternative possibili, e formale quando occorre una riflessione
più approfondita.
L’approccio KAOS prevede una struttura a due livelli: lo strato esterno,
costituito dalla parte grafica e semantica il cui scopo è quello di descrivere i
concetti e le relazioni che li collegano, e lo strato interno, il quale definisce
gli stessi concetti in modo formale.

2.1. GOAL DIAGRAM 11
Oltre ai goals, il linguaggio definito da KAOS comprende altre ontolo-
gie come reti semantiche, agenti, oggetti, linee temporali e operazioni da
compiere sul sistema.
Gli oggetti rappresentano entità, relazioni ed eventi e le loro istanze
possono evolversi cambiando più volte il loro stato.
Le operazioni sono relazioni di input e output fra gli oggetti, determinano
un cambio di stato e possiedono precondizioni, postcondizioni e triggers per
l’attivazione.
Un agente è un tipo particolare di oggetto che si propone come un com-
ponente attivo quale può essere una persona, un device o un software.
Gli agenti non possono compiere operazioni su tutti gli oggetti del sistema
ma solo su quelli appositamente definiti.
Un goal è definito come una dichiarazione di obiettivi di un sistema la
cui soddisfazione in genere richiede la cooperazione di alcuni degli agenti che
costituiscono tale sistema.
I goals in KAOS possono riferirsi a dei servizi, functional goals, o alla
qualità dei servizi, non-functional goals.
I goals sono organizzati gerarchicamente secondo relazioni AND/OR e il
raffinamento del diagramma ha termine quando ogni sottogoal è realizzabile
da parte dell’agente assegnatogli. Per questo motivo ogni goal deve essere
espresso in termini di condizioni visibili e controllabili dall’agente.
Riassumendo, il framework KAOS è costituito da questi elementi:
• goal model: rappresentazione dei goals e degli agenti assegnati;
• object model: un modello UML derivato dalle specifiche formali dei
goals;
• operation model: i servizi da fornire agli agenti software.
Una mancanza di KAOS è un metodo per determinare l’impatto delle
decisioni prese in fase di design sui requisiti non funzionali del sistema.

12 CAPITOLO 2. BACKGROUND
2.1.3 i*/Tropos
i* [4] è un framework di modellazione dei requisiti agent-oriented formato da
due componenti principali: lo Strategic Dependency model (SD) e lo Strategic
Rationale model (SR).
Questo approccio è stato studiato per essere usato durante la fase iniziale
della specifica dei requisiti e il rifinimento finale.
All’inizio infatti viene adoperato per descrivere quello che sarà il sistema
finale e l’ambiente in cui sarà inserito, un’analisi del dominio facilitata dal-
l’inserimento degli stakeholders, dei loro obbiettivi e delle loro relazioni. Ciò
permette di capire l’utilità e la necessità del sistema che si sta progettando.
Nella fase finale della specifica invece serve per proporre i nuovi processi
e le nuove configurazioni di sistema e la valutazioni di questi in relazione ai
requisiti funzionali e non funzionali degli utenti.
i* è basato su intentional actor e intentional dependency.
Un actor può essere un agente, un ruolo o una posizione.
Un agente è un attore concreto, quindi un umano o un sistema dalle
capacità specifiche.
Un ruolo è un attore astratto che incarna aspettative e responsabilità.
Una posizione è invece un insieme di ruoli socialmente riconosciuti tipi-
camente impersonati da un agente.
Questa suddivisione risulta particolarmente utile nell’analisi del contesto
sociale del sistema.
Le dipendenze tra gli attori sono definite intenzionali se appaiono a segui-
to del perseguimento degli obiettivi da parte di altri agenti. Una dipendenza
può essere un goal, un softgoal, un task o una resource.
Lo Strategic Dependency model è formato dalla rete di relazioni di dipen-
denza esistenti fra gli attori. Esso permette l’analisi delle dipendenze dirette
e indirette di ogni attore e l’esplorazione delle possibilità e delle vulnerabilità.
Lo Strategic Rationale model è usato per analizzare il fondamento logico
che sta dietro ai processi del sistema. Il modello SR descrive in maniera più

2.2. UML 13
approfondita le relazioni che compaiono nel SD model dichiarando per ogni
agente cosa necessita e come deve fare per soddisfare le proprie richieste.
In questo modello trovano spazio i link di decomposition e di means-ends,
i quali rispettivamente descrivono le relazioni di AND e OR tra le dipendenze
prima elencate.
Il framework i* è alla base della metodologia agent-oriented requirements-
driven Tropos [5].
L’approccio Tropos permette lo sviluppo di sistemi basati su agenti dall’a-
nalisi iniziale dei requisiti, passando per il design architetturale fino al design
dell’implementazione.
Tropos utilizza la modellazione i* per la rappresentazione delle scelte e
delle configurazioni fatte sul sistema.
Inoltre possiede un linguaggio formale di specifica chiamato Formal Tro-
pos che permette di aggiungere vincoli, invarianti, pre e post condizioni e che
consente di catturare più informazioni dai modelli rispetto a quanto fa i*.
Inoltre è presente uno strumento di validazione dei modelli.
2.2 UML
UML (Unified Modeling Language) [6] è il linguaggio di modellazione e di
specifica standard nell’ingegneria del software controllato dallo OMG (Object
Management Group) [7]. Esso è orientato alla programmazione ad oggetti e
si colloca perfettamente tra la specifica dei requisiti e l’implementazione del
sistema.
Tramite l’insieme delle notazioni grafiche fornite da UML è possibile de-
scrivere dei modelli che rappresentano tutti gli aspetti del ciclo produttivo
del sistema, astraendo dal linguaggio scelto per l’implementazione dei vari
componenti. Ciò avviene grazie alla varietà dei modelli disponibili, ognuno
specifico e indicato per un preciso passo all’interno della progettazione.
I principali modelli forniti da UML sono:
• use case diagram: mostra le funzionalità del sistema dalla prospettiva

14 CAPITOLO 2. BACKGROUND
di diversi attori quali ad esempio gli amministratori o gli utenti generici
(aspetto comportamentale);
• activity diagram: descrive il flusso di esecuzione delle varie operazioni
che portano al raggiungimento di un obiettivo (aspetto comportamen-
tale);
• class diagram: descrive la struttura intera del sistema tramite classi,
attributi, metodi e relazioni tra le classi (aspetto logico);
• sequence diagram: mostra come gli oggetti comunicano tra loro scam-
biandosi messaggi e il loro ciclo di vita (aspetto interattivo);
• deployment diagram: descrive la tipologia di hardware che verrà utiliz-
zata per implementare il sistema (aspetto fisico);
Nel contesto di questa tesi è stato fatto utilizzo principalmente dei class
diagrams e per questo motivo è giusto dettagliarne maggiormente le caratte-
ristiche.
Il class diagram rientra nella descrizione della struttura logica del sistema,
rappresenta le entità in esso contenute e il modo in cui esse si relazionano
tra loro. Nello specifico sono descritte le classi, coi loro attributi e metodi, e
le associazioni che intercorrono tra queste.
Una classe descrive un insieme di entità, chiamate oggetti o istanze della
classe, che condividono le stesse caratteristiche e proprietà. Graficamente è
rappresentata da un rettangolo contenente il nome della classe, autodescrit-
tivo e con iniziale maiuscola, gli attributi che la descrivono e i metodi che
possono essere invocati.
Un attributo è una caratteristica comune a ogni istanza della classe ed è
caratterizzato da:
• visibilità: indica se l’attributo è visibile da altre classi o meno. In
particolare l’attributo può essere pubblico (segno +) e quindi visibile a
tutte le classi; privato (segno -), visibile solo all’interno della classe in
cui è definito; protetto (segno #), visibile solo dalle classi ereditarie;

2.2. UML 15
• nome: nomi scritti in minuscolo e autodescrittivi;
• tipo: il tipo di riferimento dell’attributo, ad esempio può essere String,
Integer, Boolean o anche un’istanza di un’altra classe.
Un metodo è un’operazione eseguita sull’istanza di una classe ed è carat-
terizzato da nome e visibilità, come nel caso degli attributi, e da parametri,
l’input fornito, e tipi di ritorno, l’output restituito.
Altre entità importanti sono la classe astratta, la quale non può essere
istanziata direttamente poiché contiene solo attributi e alcune operazioni
soltanto dichiarate, e pertanto deve essere implementata nei suoi metodi da
un’altra classe, e l’interfaccia che presenta solo dichiarazioni di operazioni
da implementare nelle classi che la estendono.
Un’associazione è una relazione statica che lega tra di loro delle classi.
La caratteristica più importante di una associazione è la molteplicità che
indica il numero di istanze di una classe che sono coinvolte nella relazione.
In particolare si possono avere le seguenti molteplicità:
• 1 : nell’associazione è coinvolta una e una solo istanza della classe;
• 0..1 : nell’associazione può essere coinvolta o meno una istanza della
classe;
• 0..* /1..* : possono essere coinvolte molte istanze, con un minimo di
nessuna o una rispettivamente;
• 0..n/1..n: possono essere coinvolte al massimo n istanze;
• n: sono coinvolte esattamente n istanze.
Le associazioni possono essere descritte da un nome univoco ed essere
navigabili da sinistra a destra, viceversa o in entrambe le direzioni. Solita-
mente l’associazione è binaria, coinvolge cioè solamente due classi, ma può
essere anche n-aria o addirittura riflessiva quando è applicata tra istanze
della medesima classe.
Oltre alle semplici associazioni ne esistono alcune particolari:

16 CAPITOLO 2. BACKGROUND
• generalizzazione: indica che una classe è una specializzazione di un’al-
tra e che quindi ne possiede le caratteristiche di fondo;
• aggregazione: indica che una classe è vista come l’insieme delle istanze
di altre classi;
• composizione: indica un caso particolare dell’aggregazione in cui ogni
istanza delle classi componenti può appartenere a una sola istanza della
classe composta.
2.3 OODBMS
Con OODBMS (Object Oriented DataBase Management System) [8] si in-
tende una base di dati in cui l’informazione è rappresentata per mezzo di
oggetti come accade nei linguaggi di programmazione object-oriented.
I database ad oggetti sono una evoluzione dei tradizionali database rela-
zionali e permettono una migliore integrazione con il paradigma di progetta-
zione orientato agli oggetti. Infatti al giorno d’oggi le informazioni trattate
sono sempre più dei tipi di dato complessi, come ad esempio file video, au-
dio, immagini e grafici, i quali non sono supportati nativamente dai modelli
relazionali in cui verrebbero rappresentati tramite più relazioni.
Gli OODBMS invece garantiscono la consistenza di questi dati poiché sia
il database che il linguaggio di programmazione utilizzano lo stesso modello
di rappresentazione, evitando problemi di comunicazione. Inoltre non si deve
progettare a parte la struttura della base di dati.
Il vantaggio però più evidente dei database ad oggetti è la velocità perché
l’accesso agli oggetti avviene tramite puntatori. Ciò permette il più delle
volte di evitare il ricorso ad operazioni molto dispendiose come quella del
join che invece risulta fondamentale nei database relazionali.
Altre caratteristiche sono l’accesso ai dati navigazionale, invece che di-
chiarativo, e la possibilità di creare classi e tipi personalizzati dall’utente.

2.4. APACHE TOMCAT 17
In un OODB ogni oggetto è caratterizzato da:
• un identificatore (OID) che garantisce l’individuazione univoca all’in-
terno del database e consente di realizzare riferimenti tra i vari oggetti;
• uno stato, costituito dall’insieme dei valori assunti dagli attributi del-
l’oggetto;
• un comportamento, descritto dall’insieme dei metodi che possono essere
eseguiti sull’oggetto.
Gli oggetti sono associati ad un tipo, astrazione che descrive lo stato e il
comportamento, e ad una classe che descrive l’implementazione di un tipo.
Alla classe è associato un solo tipo e pertanto gli oggetti di una classe sono
tra loro omogenei.
Gli oggetti possono essere temporanei o persistenti. Poiché il modello è
quello object-oriented, sono implementati i meccanismi di incapsulamento e
di ereditarietà, quest’ultima anche multipla dove consentita.
Per quanto riguarda il linguaggio di interrogazione, oltre ai metodi speci-
fici di ogni OODB, viene usato lo standard OQL (Object Query Language).
2.4 Apache Tomcat
Tomcat [9] è un web container open-source che permette l’esecuzione di ap-
plicazioni sviluppate nel linguaggio Java. In particolare implementa le spe-
cifiche Servlets e JSP definite da Sun Microsystems.
Tomcat è composto dai seguenti tre componenti:
• Catalina: è il servlet container, ambiente d’esecuzione delle servlet e
delle jsp;
• Coyote: è il componente di interfacciamento col protocollo HTTP, ri-
mane in ascolto di richieste in entrata che inoltra all’engine di Tomcat
dal quale, dopo l’esecuzione dell’operazione, viene ritornata la risposta
da restituire al client.

18 CAPITOLO 2. BACKGROUND
• Jasper: è un parser che si occupa di tradurre le jsp in servlets in modo
tale che possano essere eseguite da Catalina. A runtime riconosce le
jsp modificate e le ricompila.
Una servlet è una classe Java conforme al protocollo Java Servlet Api
che permette di interagire direttamente col meccanismo request/response di
HTTP.
La Servlet estende la classe HttpServlet e implementa i due metodi do-
Get(request, response) e doPost(request, response) per gestire rispettivamente
le chiamate effettuate coi metodi get e post di HTTP.
Lo scopo principale di una servlet è quello di recuperare i parametri d’in-
gresso dalla request, eseguire l’operazione richiesta e scrivere l’html di rispo-
sta sulla response.
Una pagina JSP (Java Servlet Pages), detta template, è una pagina html
in cui sono innestati brani di codice Java, chiamati scriptlet.
Ciò agevola la leggibilità della struttura della pagina capovolgendo ciò
che succede nella servlet. Quando una pagina jsp viene richiesta, il server la
compila in una servlet e la esegue.
Il cuore di ogni web application in Tomcat è la cartella WEB-INF. Essa
contiene il file web.xml, il deployment descriptor, un file dal formato standard
che configura la web application stessa. In esso sono indicati i nomi e i
percorsi delle servlets.
Quando una servlet è invocata, il server ne crea una istanza in memoria
soltanto la prima volta; infatti le successive chiamate alla medesima servlet
vengono gestite tramite il meccanismo dei threads. Ne derivano prestazioni
migliori poiché vi è una minore occupazione della memoria, si evita la crea-
zione di più istanze e soprattutto si permette il riutilizzo degli oggetti creati
dalla servlet.
Poiché HTTP è un protocollo stateless, ossia non ha una memoria e non
permette di verificare se una serie di richieste provengono da uno stesso client,
le servlet e le jsp supportano il meccanismo della sessione e dei cookies per

2.5. ALTRE TECNOLOGIE 19
memorizzare variabili e informazioni utili durante la navigazione dell’utente.
Le servlet e le jsp implementano il pattern MVC (Model-View-Controller)
fondato sulla separazione dei compiti che i componenti software devono avere:
• model: rappresenta lo stato e le operazioni disponibili;
• view: definisce il modo attraverso il quale il modello deve essere pre-
sentato all’utente;
• controller: interpreta l’azione dell’utente e invoca le operazioni del
model opportune.
In una web application le servlet costituiscono il controller, le jsp la view e
i java bean il model. Il vantaggio di questa architettura è che nei componenti
di presentazione non avviene nessuna elaborazione e il loro unico scopo è
quello di inserire il contenuto dinamico all’interno della parte statica.
2.5 Altre tecnologie
Poiché un social network è a tutti gli effetti una web application, la sua
interfaccia utente non può che essere sviluppata utilizzando i linguaggi e i
framework tipici del web:
• HTML: è il linguaggio di mark-up che permette la visualizzazione delle
pagine web.
• CSS: i fogli di stile (Cascade Style Sheet) sono i componenti che si
occupano di gestire interamente la grafica degli elementi delle pagine
web; usando i fogli CSS si scinde il contenuto dalla visualizzazione.
• JavaScript: il linguaggio di scripting orientato agli oggetti che permette
di interagire con gli elementi della pagina web scaricata nel browser da
lato client.

20 CAPITOLO 2. BACKGROUND
• AJAX : il framework (Asynchronous JavaScript and XML) che per-
mette alle pagine caricate nel browser dell’utente di interagire in modo
asincrono col server; ciò vuol dire che la pagina può continuare a scam-
biare e ricevere informazioni senza che l’utente debba ricaricarla per
intero.

Capitolo 3
Approccio
In questo capitolo viene descritto nei particolari il metodo proposto per la
progettazione di una rete sociale, partendo da una visione d’insieme delle
operazioni da compiere per proseguire poi con i singoli passaggi affrontati
nei loro dettagli.
3.1 Overview
L’approccio adottato per la progettazione di un social network consiste di tre
passaggi: la specifica dei requisiti, il design del sistema e l’implementazione.
In Figura 3.1 è rappresentata la sequenza delle operazioni e per ognuna
di essa è evidenziato se si tratta di una procedura automatica o necessita di
compiere operazioni manuali.
La selezione dei requisiti avviene manualmente scegliendo tra quelli di-
sponibili nel goal diagram. Per agevolare la selezione si è fatto ricorso a
un tool in cui viene visualizzato il diagramma completo e da cui si possono
effettuare le selezioni eliminando dal grafo i requisiti non necessari.
Una volta ottenuto l’albero delle features si può procedere alla genera-
zione delle classi UML. Ciò avviene in modo automatico tramite l’utilizzo
di un piccolo software creato appositamente che mappa e associa le scelte
precedentemente effettuate ai relativi pattern UML.
21

22 CAPITOLO 3. APPROCCIO
Figura 3.1: Approccio al problema
I class diagram così generati sono visibili e raffinabili all’interno del soft-
ware scelto per la gestione dei diagrammi UML.
Se il design del sistema ottenuto risulta soddisfacente si può passare
all’implementazione generando il codice base delle classi.
3.2 Requisiti
Il primo passo che ha portato alla definizione dei requisiti propri di un social
network è stato quello dell’analisi di sistemi sociali esistenti.
E’ stata condotta un’indagine approfondita su varie decine di siti web
con l’intento di individuare e classificare le caratteristiche comuni a tutti e
segnalare le features uniche e particolari.
I primi social network presi in considerazione sono stati quelli attualmente
più blasonati, di carattere generale e che vantano un maggior numero di
iscritti.
Ciò ha permesso l’individuazione dei pattern tipici e ricorrenti, la distin-
zione logica delle aree all’interno dei siti web e una prima elicitazione dei
requisiti fondamentali.
L’attenzione si è poi spostata gradualmente verso i social network incen-
trati su di un argomento specifico e infine verso quelli minori.
Questo l’elenco dei social network analizzati divisi per argomento:
• a carattere generale: Facebook, Netlog, Google Buzz

3.2. REQUISITI 23
• blog e micro-blogging: Twitter, Live Spaces, Tumblr, Jaiku, Xanga
• business e mondo del lavoro: LinkedIn, Xing, Viadeo
• video e multimedia: YouTube, Flixster
• fotografia: Flickr, Fotolog, Faces, Sneppi
• dedicati alla musica: MySpace, Last.fm, Blip.fm, Trig
• libri e lettura: Anobii, weRead, Shelfari, GoodReads
• arte e immagini: DeviantArt
• viaggi: Wayn, TripAdvisor, Tripit
• bookmarks: Delicious, Bibsonomy, Citeyoulike
• basati su locazione: Foursquare, Gowalla, Brightkite
Nella Tabella 3.1 è riportata la distribuzione delle features più ricorrenti
su alcuni dei social network presi in considerazione.
Nella Tabella 3.2 sono visualizzate alcune features singolari e i social net-
work che le implementano.
I requisiti sono stati organizzati in aree logiche, raggruppandoli in base al
loro scopo e funzionalità. Di seguito è riportata la lista dei gruppi dei gruppi
e delle features, ognuna delle quali corredata da una breve descrizione:
• Users Relations: raggruppa i requisiti che interessano le relazioni tra
gli utenti all’interno del social network.
– profile: ogni utente ha un proprio profilo contenente informazioni
personali come ad esempio nome e cognome, età, sesso, e-mail,
avatar, contatti di instant messagging, stato, breve descrizione. Il
profilo è solitamente pubblico e visibile da tutti gli utenti registrati
al social network.

24 CAPITOLO 3. APPROCCIO
groups
friends
recommendations
chat
favorites
rating
Facebook * * * * * * * * * * *
MySpace * * * * * * * *
Netlog * * * * * * * * * * *
Google Buzz * * * * * * * * * *
Twitter * * * * * * * * * *
Jaiku * * * * * * * * * *
Live Spaces * * * * * * * *
Xanga * * * * * * * * * *
LinkedIn * * * * *
Xing * * * * * * * * *
Viadeo * * * * * *
Blip.fm * * * * * * * *
Last.fm * * * * * * * *
Anobii * * * * * * * * *
weRead * * * * * * * * * * *
Shelfari * * * * * * * * * *
Goodreads * * * * * * * * * * *
Flickr * * * * * * * * *
Fotolog * * * * * * * * * * *
Faces * * * * * * * * * * *
Sneppi * * * *
YouTube * * * * * * * * * * *
Flixster * * * * * * *
DevianArt * * * * * * * * * *
Wayn * * * * * * * * *
reputation
tags
contests
notifications
customizations
authorizations
plugins
Tabella 3.1: Features tipiche e ricorrenti dei social network
mobile
shop

3.2. REQUISITI 25
features
YouTube subscriptions
Twitter geolocation
Blip.fm props
badges
Anobii
Facebook
Foursquare
data exportation
wishlist
fan
poke
gifts
check-in
badges
geolocation
Tabella 3.2: Features particolari di alcuni social network
– friends: gli utenti possono richiedere l’amicizia di altri utenti
iscritti al social network. A fronte di una richiesta di amicizia
è possibile accettare o rifiutare tale richiesta. L’amicizia di un
utente permette il libero accesso ai contenuti dell’utente amico e
quindi la completa interazione.
– groups: i gruppi sono aggregazioni di utenti collegati tra loro
secondo un qualche criterio. Ogni utente può creare dei grup-
pi. I gruppi possono essere pubblici, e quindi ognuno è libero di
iscriversi, o privati, e quindi l’iscrizione avviene solo su invito.
– subscriptions: sottoscrizione che permette a un utente di seguire
altri utenti senza essere necessariamente amici.
• Users Interaction: raggruppa i requisiti che hanno a che fare con le
interazioni disponibili tra gli utenti.
– props: i props sono entità che gli utenti si scambiano in segno di
riconoscenza e rispetto.

26 CAPITOLO 3. APPROCCIO
– pokes: il poke consiste in una forma di saluto muto, un modo per
attirare l’attenzione di un altro utente.
– contests: concorsi a premi a cui possono partecipare tutti gli
utenti, o quiz che permettono di guadagnare crediti.
– badges: le badges sono simboli che denotano il raggiungimento
di precisi obiettivi e traguardi all’interno del social network come
ad esempio avere tante amicizie o aver creato un certo numero di
gruppi.
– credits: i crediti sono dei punti che vengono assegnati dal si-
stema come ricompensa per qualcosa. Possono essere utilizzati
all’interno del social network per avere dei benefici.
– reputation: la reputazione è relativa all’utente e può essere asse-
gnata dal sistema o dagli altri utenti.
• Messages: raggruppa i requisiti relativi alla creazione e scambio di
informazioni.
– posts: un post è un messaggio scritto da un utente per condividere
fatti personali, pensieri, opinioni o mostrare dei contenuti quali
link, fotografie o video agli altri utenti.
– guestbook: una bacheca relativa al profilo utente dove gli altri
utenti possono lasciare messaggi generici, come un saluto o un
invito a visualizzare i loro profili.
– comments: i commenti sono dei messaggi di risposta a un post da
parte di altri utenti.
– inbox: è il gestore dei messaggi privati (direct messages) e può
integrare anche una casella email.
– direct messages: messaggi privati diretti solitamente a uno speci-
fico utente. Vengono gestiti tramite l’inbox.
– chat: la chat permette agli utenti di scambiare tra loro messaggi
in tempo istantaneo. A differenza dei posts e dei commenti, i

3.2. REQUISITI 27
messaggi scritti via chat sono visibili solo agli utenti che se li
scambiano e non vengono in genere salvati.
• Organization: raggruppa i requisiti a carattere organizzativo.
– customizations: possibilità di modificare graficamente le proprie
pagine e organizzare la disposizione dei propri contenuti.
– authorizations: le autorizzazioni consentono un controllo sull’ac-
cessibilità dei contenuti.
– calendar: calendario condiviso con gli amici o col proprio gruppo
in cui pianificare eventi.
• System Actions: raggruppa i requisiti propri del sistema in generale.
– search: funzione di ricerca a più livelli in base a tag, utenti,
contenuti, zone, ecc.
– stats: grafici e statistiche come ad esempio il numero di visualiz-
zazioni del proprio profilo.
– recommendations: le raccomandazioni sono amicizie o contenuti
consigliati direttamente dal sistema in base ai gusti e al profilo del-
l’utente. Le raccomandazioni permettono di allargare la propria
cerchia di amicizie e l’approfondimento di argomenti.
– activities: un resoconto delle azioni salienti dell’utente, ad esempio
un elenco dei suoi contenuti preferiti o dei rating che ha assegnato
di recente.
– notifications: le notifiche sono effettuate dal sistema e ad esempio
avvertono gli utenti dei nuovi contenuti inseriti dagli amici.
– newsletters: le newsletters sono e-mail periodiche inviate dal siste-
ma per informare gli utenti di novità, modifiche, concorsi e altre
comunicazioni.
• Contents Interaction: raggruppa i requisiti che permettono l’interazio-
ne sui contenuti.

28 CAPITOLO 3. APPROCCIO
– rating: il rating consiste nel dare un voto a un certo contenuto
scegliendo tra una scala di valori.
– favorites: i preferiti sono i contenuti propri o di altri utenti dei
quali si vuole salvare un collegamento veloce in modo da poter
facilitare la loro visione in futuro.
– playlist: una playlist è un elenco, creato dall’utente, di video o
canzoni che vengono eseguiti in successione.
– tags: i tag sono parole chiave che vengono associate a un con-
tenuto rendendone possibile la classificazione e la ricerca. I tag
sono scelti dagli utenti in modo informale e costituiscono una
categorizzazione alternativa.
– upload: il servizio di upload permettere di caricare sul server i
propri file multimediali come ad esempio le proprie foto e video in
modo tale da condividerle con gli altri utenti.
• Extensions: raggruppa i requisiti che permettono l’estensione delle
funzionalità base del sistema.
– mobile: supporto per gli smartphone e palmari, realizzato con
interfacce web più leggere e con una visualizzazione studiata ap-
positamente per schermi più piccoli.
– check-in: il check-in è un modo per segnalare la propria posizione
fisica, il luogo da dove si sta accedendo al social network. Basato
su geolocazione.
– plugins: i plugins o widgets sono estensioni e applicazioni interne
o esterne al social network che ne arricchiscono le funzionalità.
– import: importazione di dati dal pc o da altri siti al social network,
ad esempio importazione dei contatti.
– export: esportazione e salvataggio di dati in locale in vari formati.
– shop: carrello per l’acquisto online di prodotti creati o trattati
all’interno del social network.

3.3. DESIGN 29
– gifts: regali che un utente può fare ad un altro. I gifts posso essere
gratuiti oppure comprati spendendo i propri crediti o con moneta
elettronica.
– wishlist: una lista pubblica delle cose che si vorrebbero possedere.
Utile per gli altri nel caso volessero fare un regalo all’utente.
– synchronization: sincronizzazione di contenuti da postazioni di-
verse.
Sulla base di questa suddivisione delle features, e l’introduzione di una
opportuna gerarchia tra le aree, è stato creato infine il goal diagram dei
requisiti (Figura 3.2).
In Figura 3.3 sono invece evidenziate le aree logiche.
3.3 Design
Dopo la selezione delle features e la mappatura automatica nei class diagrams,
la fase di design prevede la visualizzazione del sistema finale all’interno del
software di gestione UML scelto.
I diagrammi sono organizzati in packages corrispondenti alle aree con cui
sono state suddivise le features nel goal diagram.
Il punto di contatto tra tutti i pacchetti è la classe User che modella
l’utente, in quanto l’utente è l’attore chiave all’interno della rete sociale.
Nelle figure da Figura 3.4 a Figura 3.10 sono mostrati i diagrammi del
social network completo di tutte le features.
3.3.1 Relazioni fra gli utenti
In Figura 3.4 è riportato il class diagram relativo alle relazioni tra gli utenti
facenti parte di una rete sociale.
La classe User contiene le informazioni essenziali di identificazione di un
utente, quindi id ( assegnato dal sistema al momento della registrazione),
username (univoca), password ed email (univoca).

30 CAPITOLO 3. APPROCCIO
Figura 3.2: Goal diagram dei requisiti

3.3. DESIGN 31
Figura 3.3: Mapping delle aree

32 CAPITOLO 3. APPROCCIO
Figura 3.4: Users Relations class diagram
Il profilo con le informazioni secondarie è rappresentato a parte dalla
classe Profile in modo da poter essere ampliato con nuovi attributi in base
alle proprie esigenze.
La classe Friends contiene la lista degli amici e si occupa di gestire le
richieste di amicizia tramite i metodi di cui è fornita. E’ infatti possibile
richiedere l’amicizia ad un altro utente il quale potrà acconsentire o rifiutare
la proposta.
Groups è il gestore dei gruppi di cui l’utente è membro e permette l’i-
stanziazione di un nuovo gruppo di cui si diventa amministratori. Il singolo
gruppo è modellizzato dalla classe Group con le informazioni generali e la
lista dei membri partecipanti.
Completa il package la classe Subscriptions contenente la lista degli utenti
dei quali si vuole ricevere aggiornamenti e la lista dei propri sottoscrittori.
3.3.2 Interazione tra gli utenti
La Figura 3.5 mostra la modellizzazione delle interazioni possibili tra gli
utenti.
L’utente può inviare e ricevere dei Poke (come in Facebook) tramite il

3.3. DESIGN 33
gestore Pokes; può assegnare e ricevere Prop da altri utenti come segno di ap-
prezzamento per i contenuti da lui condivisi attraverso la classe Props(come
in Blip.fm); ha una lista delle Badge sbloccate e tramite la classe Contests
gestisce i concorsi proposti dal social network e a cui vuol partecipare.
La classe Credits si occupa di gestire i Credit che l’utente guadagna e spen-
de all’interno della rete sociale, tenendo in memoria le operazioni effettuate
e i crediti attualmente disponibili.
Infine vi è la classe Reputation, specializzata da ReputationByUsers la
quale permette agli altri utenti di assegnare un punteggio all’utente e da
ReputationBySystem dove invece la reputazione viene calcolata automatica-
mente dal sistema in base a dei criteri.
3.3.3 Messaggi
Nella Figura 3.6 è modellizzato lo scambio di messaggi e informazioni tra gli
utenti.
La classe Posts funziona come un blog personale dell’utente e contie-
ne l’elenco dei Post da lui pubblicati. Sia il singolo post che il Guestbook
permettono lo sviluppo di una discussione tramite i Comment.
La classe Inbox permette la ricezione e l’invio di messaggi privati verso
gli utenti del social network, messaggi rappresentati da DirectMessage.
E’ presente anche la Chat che mostra i contatti amici online con i quali è
possibile interagire.
Le classi Comment e DirectMessage specializzano la classe astratta Mes-
sage alla quale aggiungono attributi e metodi specifici.
3.3.4 Organizzazione
In Figura 3.7 sono mostrati elementi utili per controllare aspetti organizzativi
tra gli utenti e tra il rapporto degli utenti e il sistema.
In particolare la classe Authorizations permette di controllare per ogni
utente i contenuti a lui visibili e le aree a cui egli ha libero accesso.
La classe Customizations gestisce i Setting, ovvero singole impostazio-

34 CAPITOLO 3. APPROCCIO
Figura 3.5: Users Interaction class diagram

3.3. DESIGN 35
Figura 3.6: Messages class diagram

36 CAPITOLO 3. APPROCCIO
Figura 3.7: Organization class diagram
ni configurabili dall’utente che modificano il comportamento dell’interfaccia
grafica o dei diversi componenti del sistema.
Infine la classe Calendar rappresenta un calendario, che l’utente può
tenere privato o condiviso con gli amici, in cui segnalare degli Event.
3.3.5 Azioni del sistema
La Figura 3.8 mostra le entità che arricchiscono le funzionalità del sistema.
La classe Updates gestisce gli aggiornamenti da fornire all’utente divisi
tra Notification, per segnalare eventi che lo possono interessare, Activity, che
tengono traccia delle azioni da lui compiute, e Newsletter, che lo informano
di novità all’interno del social network o gli forniscono un resoconto della sua
esperienza all’interno della rete.
La classe Recommendations si occupa invece di proporre all’utente nuove
amicizie, gruppi o contenuti che possono piacergli.
Le classi Stats e Search a differenza delle altre sono uniche per tutti gli
utenti del sistema e permettono rispettivamente di calcolare statistiche di
vario genere e di effettuare ricerche secondo vari criteri quali ad esempio per
nome utente, per gruppo o per un certo Tag.

3.3. DESIGN 37
Figura 3.8: System Actions class diagram
3.3.6 Interazione sui contenuti
Nella Figura 3.9 sono descritte la gestione dei contenuti creati dall’utente e
l’interazione possibile con essi.
Tramite il gestore Contents l’utente può effettuare l’upload di video,
immagini, audio ai quali corrisponderà un oggetto di tipo Content.
Questi contenuti possono essere salvati in una lista di favoriti con la
classeFavorites o essere organizzati in diverse Playlist che possono essere
condivise anche con gli altri utenti.
Sia le Playlist che i singoli Content sono forniti di una classe Rating
attravero cui gli utenti possono esprimere il loro gradimento, e da una lista
di Tag, un insieme di parole chiave inserite dall’autore del contenuto che ne
permettono la ricerca e la classificazione.

38 CAPITOLO 3. APPROCCIO
Figura 3.9: Contents Interaction class diagram
3.3.7 Estensioni del sistema
La Figura 3.10 illustra le estensioni che possono arricchire il social network,
ampliarlo e renderlo maggiormente accessibile.
Il gestore Plugins detiene il controllo dei diversi Plugin installabili, atti-
vabili o disattivabili da parte dell’utente.
La classe Mobile permette la registrazione dei dispositivi mobili, Devi-
ce, attraverso i quali l’utente può accedere al sistema, e può integrare il
meccanismo del Checkin con geolocazione (tipico ad esempio di Foursquare).
La classe Shop realizza il meccanismo del carrello virtuale col quale è

3.4. IMPLEMENTAZIONE 39
possibile comprare degli Item online sia attraverso valuta elettronica che
attraverso i crediti guadagnati nel social network.
Le classi Gift e Wishlist completano lo shop permettendo agli utenti di
fare regali agli amici e di elencare i prodotti che si vorrebbe avere.
La classe Import e la classe Export consentono rispettivamente di impor-
tare ed esportare dati di vario genere e in vari formati dal social network,
mentre la classe Synchronization permette l’aggiornamento e la sincronizza-
zione delle informazioni nel caso in cui l’accesso alla rete sociale avvenga da
più postazioni.
3.4 Implementazione
L’implementazione ha inizio dal momento in cui si è soddisfatti del design
ottenuto e si è sicuri che esso sia completo e coerente con gli obiettivi preposti.
Come base di partenza si può procedere con la generazione automatica,
se disponibile nel tool di gestione UML, delle dichiarazioni delle classi e delle
associazioni che le legano, e partire quindi con l’implementazione dei metodi.
Per come è stata pensato, questo approccio prevede che le classi costitui-
scano sia la logica di controllo che il modello dei dati da salvare nel database.
Ciò è possibile avendo scelto di usare un database ad oggetti.
Poiché un social network è una web application, risulta necessario creare
altri componenti di controllo che andranno a costituire lo strato superiore
della logica di sistema, occupandosi di rispondere alle richieste http invocando
i metodi forniti dagli oggetti dello strato inferiore, e di restituire le pagine
jsp opportune.

40 CAPITOLO 3. APPROCCIO
Figura 3.10: Extensions class diagram

Capitolo 4
Implementazione
In questo capitolo vengono introdotti e descritti gli strumenti software che
costituiscono il framework della progettazione di una rete sociale proposto
da questa tesi.
4.1 Overview
In Figura 4.1 è mostrata l’interazione tra i diversi tool scelti per la proget-
tazione.
Figura 4.1: Framework usato
GR-Tool ed OpenOME sono due programmi usati nella progettazione
goal-oriented che consentono la creazione di goal diagram e la verifica delle
alternative possibili.
41

42 CAPITOLO 4. IMPLEMENTAZIONE
La fase iniziale di selezione viene quindi effettuata caricando il diagramma
dei goals in uno di questi strumenti e in esso viene eseguita la scelta delle
features.
Il controllo passa poi a Goals2UML, un tool di supporto scritto appo-
sitamente nell’ambito di questa tesi, il quale si occupa della mappatura
automatica delle features selezionate sui class diagrams.
Infine utilizzando ArgoUML, software di gestione UML, si procede alla
visione e alla rifinitura del design operando sui class diagrams.
4.2 Selezione delle features
Per la creazione del goal diagram dei requisiti e per agevolarne la successiva
selezione si è fatto uso dello strumento di goal reasoning GR-Tool [10].
Figura 4.2: GR-Tool: goal diagram
Il tool presenta una interfaccia semplice e intuitiva con cui è possibile
creare il goal diagram (Figura 4.2).

4.3. MAPPATURA DELLE CLASSI 43
La scelta delle features avviene tramite l’eliminazione dei goals non ne-
cessari dal modello semplicemente selezionandoli e cliccando sul tasto di
eliminazione dal modello.
Il diagramma risultante a questo punto può essere salvato e si può pro-
cedere alla fase di mappatura delle classi.
Come alternativa per la selezione dei goals viene supportato anche Ope-
nOME [11], un tool che rientra nella progettazione dei requisiti all’interno
del framework Tropos.
Per entrambi gli strumenti è disponibile il goal diagram completo delle
features da cui iniziare la progettazione del social network desiderato.
4.3 Mappatura delle classi
Allo scopo di effettuare automaticamente il mapping delle features selezionate
con GR-Tool o OpenOME sui class diagrams UML è stato creato apposita-
mente in linguaggio Java il tool Goals2UML.
Esso si frappone tra la selezione dei requisiti e il raffinamento UML dando
un senso di continuità all’azione di progettazione e velocizzando le operazioni.
Il compito di questo strumento è quello di analizzare le selezioni effettuate
sul goal diagram e associare a ogni scelta le classi UML coinvolte tramite
regole descritte in un file xml di configurazione.
Questo file di configurazione ha il ruolo chiave nella mappatura poiché
specifica per ogni feature le classi necessarie per soddisfarlo, garantendo l’a-
dempimento dei requisiti e la stabilità finale del sistema.
La logica d’azione del programma è stata divisa in due parti.
Nella prima parte vi è la lettura del goal diagram generato da GR-Tool
da cui viene estratta la lista delle scelte effettuate.
La lista viene quindi confrontata col file di configurazione e il risultato è
l’elenco dei nominativi delle classi di cui il sistema avrà bisogno.
La seconda parte ha il compito della vera e propria mappatura.

44 CAPITOLO 4. IMPLEMENTAZIONE
Figura 4.3: Goals2UML: lista delle features selezionate
Innanzitutto viene caricato il file contenente i class diagrams UML com-
pleti e successivamente da questo vengono rimosse le classi e le associazioni,
ad esse legate, che non compaiono nell’elenco e che quindi non risultano più
necessarie.
A livello di codice il programma si basa sulla creazione di alberi DOM a
partire dai file xml coinvolti: quello di configurazione e quello contenente i
class diagrams UML.
In sintesi il comportamento di Goals2UML è assimilabile a quello di un
parser xml.
Una volta che l’albero DOM dei class diagrams è caricato in memoria,
esso viene modificato togliendo i nodi non necessari e quindi salvato su un
nuovo file.
Nel caso si aggiungano nuove features al goal diagram, per poter usare
questo tool basta soltanto modificare il file xml di configurazione aggiungen-

4.4. GESTIONE UML 45
do le relazioni di dipendenza tra le nuove classi e fornire il nuovo file dei class
diagrams aggiornato.
A livello di interfaccia utente il funzionamento di Goals2UML è molto
semplice (Figura 4.3).
Una volta lanciato il tool si può caricare il goal diagram cliccando sul
bottone ’Load Goals’. Sono supportati sia i file generati con GR-Tool che
con OpenOME.
Scelto il file da analizzare, il programma esegue la prima scansione e
mostra in finestra le features che sono state selezionate.
Se si è soddisfatti si può procede con la mappatura su class diagrams
cliccando il tasto ’Generate UML’.
Dopo aver specificato dove salvare il nuovo file, esso può essere aperto
con ArgoUML e da lì continuare la progettazione.
4.4 Gestione UML
Per la progettazione del design, la creazione e la visualizzazione dei class
diagrams la scelta è ricaduta su ArgoUML [12], strumento di modellazione
UML conforme agli standard del linguaggio, multi-piattaforma e open-source.
Dopo aver caricato il file generato tramite Goals2UML sono visibili i class
diagrams che modellizzano il sistema (Figura 4.4).
Essi compaiono organizzati nei packages che rispettano la distinzione in
aree logiche effettuata in principio e mantenuta in tutti i passaggi precedenti.
Per ogni classe compaiono di default gli attributi e le dichiarazioni dei
metodi che descrivono il comportamento base del sistema, esattamente come
illustrati in precedenza nella presentazione del design nel capitolo dedicato
all’approccio.
Tramite ArgoUML si può raffinare il design aggiungendo, se occorre, nuo-
ve classi e associazioni o modificando e arricchendo quelle offerte.

46 CAPITOLO 4. IMPLEMENTAZIONE
Figura 4.4: ArgoUML: class diagram
Una utile funzionalità di ArgoUML permette infine la generazione auto-
matica del codice dell’intero progetto nel linguaggio Java.

Capitolo 5
PoliBook
In questo capitolo viene descritta la realizzazione di un social network secondo
l’approccio proposto da questa tesi seguendo tutte le fasi dalla selezione dei
requisiti, al design fino all’implementazione finale usando le tecnologie e gli
strumenti illustrati nei capitoli precedenti.
5.1 Obiettivo
L’obiettivo è quello di realizzare PoliBook, un ipotetico social network dedi-
cato agli studenti del Politecnico di Milano, dove gli utenti possano perso-
nalizzare il proprio profilo, estendere le proprie amicizie online, aggregarsi in
gruppi e scambiare informazioni.
Inoltre vogliamo che sia presente un sistema di aggiornamenti, notifiche
e rating.
5.2 Architettura
Trattandosi di una web application, come architettura si è scelto di usare
l’ambiente Java e in particolare il web container Tomcat con servlet e jsp.
Per il database la scelta è caduta su Db4object [13], un database ad oggetti
open-source dotato anche di interfaccia Java.
Db4o supporta il multi-threading e tre diversi metodi di query: Query-
By-Example (QBE), Native Queries (NQ) e SODA API.
47

48 CAPITOLO 5. POLIBOOK
5.3 Realizzazione
Figura 5.1: Architettura
Vengono ora descritte passo per passo le azioni che hanno portato alla rea-
lizzazione del social network PoliBook.
5.3.1 Scelta dei requisiti
Il primo passo da compiere è la definizione dei requisiti che il social network
dovrà avere.
Il primo strumento da utilizzare è quindi GR-Tool col quale viene caricato
il goal-diagram predefinito contenente tutte le features disponibili.
Come features di PoliBook sono state selezionate:
• Profile, Friends e Groups come interazione fra gli utenti;
• Posts, Guestbook, Comments, Inbox e DirectMessages dal ramo relativo
ai messaggi;

5.3. REALIZZAZIONE 49
• Authorizations dall’organizzazione;
• Updates, Activities e Notifications dalle azioni di sistema;
• Rating dall’interazione sui contenuti.
Una volta eliminati dal diagramma tutti i goals non necessari si salva il
goal diagram ottenuto.
La fase successiva consiste nel mappare le features sui class diagram.
Si lancia allora il tool Goals2UML, vi si carica il goal diagram, si verificano
le scelte fatte e infine si procede alla generazione dei modelli UML.
5.3.2 Design e rifinitura
Dopo aver aperto il progetto ArgoUML generato con Goals2UML si possono
visualizzare i class diagrams per la rifinitura del design.
Nel package ContentsInteraction si nota che la classe Rating è associata
alla classe Content che modellizza un generico contenuto creato o caricato
dall’utente.
Nel caso di PoliBook gli unici contenuti sono i post e i commenti e per
questa ragione si crea l’associazione tra Post e Rating e tra Comment e
Rating nel package Messages (Figura 5.2).
Nel package ContentsInteractions si possono invece eliminare le classi
Contents e Content.
Il design a questo punto risulta soddisfacente e si può procedere verso
l’implementazione.
Tramite la funzione fornita da ArgoUML vengono generate le dichiara-
zioni delle classi e associazioni coinvolte andando a costituire il progetto di
partenza dell’IDE preferito, ad esempio Eclipse.
5.3.3 Implementazione e interfaccia grafica
Nel corso dell’implementazione si è fatto riferimento al pattern MVC in cui
le servlet svolgono il ruolo di controller, le jsp quello di visualizzazione e le

50 CAPITOLO 5. POLIBOOK
Figura 5.2: Rifinitura del class diagram
classi progettate in fase di design il modello dei dati.
La logica di controllo è stata suddivisa in due strati.
Il primo strato ha il compito di interfacciarsi con le richieste http dell’u-
tente, invocare i metodi offerti dal secondo strato e restituire la visualizza-
zione corrispondente.
Essenzialmente questo livello è formato dalle due classi Loader e Up-
dater che estendono l’interfaccia HttpServlet e implementano i metodi do-
Get(request, response) e doPost(request, response) tramite i quali gestiscono
le requests.
In particolare la classe Loader si occupa di gestire le requests, interrogare
il database, caricare i dati e restituire la pagina jsp giusta.
La classe Updater si preoccupa di modificare i dati già presenti e di creare
nuovi oggetti, dopodiché cede il controllo al Loader.
Il secondo strato invece è formato dalle classi definite in fase di design e
si basa sui metodi da esse forniti.

5.3. REALIZZAZIONE 51
Figura 5.3: Homepage di PoliBook
Il compito della visualizzazione, come detto, è svolto dalle pagine jsp che
ricevono i contenuti salvati in sessione dalle servlet e li presentano all’utente
tramite html e i fogli di stile css.
Per quanto riguarda il modello dei dati che costituiscono il database, esso
coincide con la logica del secondo strato dal momento che i metodi delle clas-
si provvedono a interagire con la base di dati a seguito della loro invocazione.
Per interloquire col database ad oggetti è stata creata una classe appo-
sita, DBManager che implementa le query necessarie definite nell’interfaccia
DBMethods.
In questo modo risulta possibile sostituire il database con un altro ag-
giornando solamente i metodi implementati in DBManager senza andare a
modificare il codice di altre classi.

52 CAPITOLO 5. POLIBOOK
Figura 5.4: Menu principale
Altro compito importante della classe DBManager è quello di gestire l’ac-
cesso concorrente al database.
Per quanto riguarda la realizzazione dell’interfaccia grafica si è fatto uso
dei fogli di stile css, javascript e di ajax.
Collegandosi a PoliBook viene mostrata la pagina login.jsp, la quale per-
mette di registrare una nuova utenza o di effettuare il login se si è già membri
del social network.
Nei campi di registrazione viene effettuato un controllo di validità iniziale
con javascript mentre sfruttando la tecnologia ajax viene mostrata la dispo-
nibilità dell’username scelto.
Una volta autenticati dal sistema viene presentata la pagina principale,
home.jsp (Figura 5.3), dove sono presenti l’elenco degli ultimi post pubbli-
cati dagli amici, le notifiche, che informano l’utente di amicizie confermate o
rifiutate, nuovi messaggi privati o commenti, e la lista delle attività salienti
e delle azioni compiute all’interno della rete sociale.
Il menu principale (Figura 5.4) è fisso per ogni pagina e consente in ogni
momento di navigare tra le varie sezioni del social network, mentre il menu
secondario varia in base alla pagina visualizzata e consente di eseguire azioni

5.3. REALIZZAZIONE 53
Figura 5.5: Profilo dell’utente
più specifiche relative al contesto in cui ci si trova.
In particolare il menu principale permette di raggiungere la homepage,
i propri profilo, guestbook e blog, la pagina degli amici e quella dei propri
gruppi, la pagina di tutti gli utenti e di tutti i gruppi esistenti, l’inbox e la
possibilità di effettuare il logout.
Ogni utente ha il proprio profilo personale (Figura 5.5) in cui compaiono
l’avatar, le informazioni personali, le sue amicizie e i gruppi di cui è membro.
profili.
Cliccando su di un amico o un gruppo è possibile raggiungere i rispettivi
Nella pagina di profilo di un utente, tramite il menu secondario è possibile
chiedere o rimuovere l’amicizia, mandare un messaggio privato, visitare il
guestbook (Figura 5.8) e leggere il suo blog.
In quest’ultimo caso bisogna avere l’autorizzazione che viene concessa se

54 CAPITOLO 5. POLIBOOK
si è amici dell’utente.
Figura 5.6: Lista degli amici
La pagina myfriends.jsp (Figura 5.6) consente di visualizzare le proprie
amicizie e di gestire le richieste di amicizia in arrivo da parte di altri utenti,
accettandole o rifiutandole, e quelle da lui chieste e ancora in attesa di con-
ferma (Figura 5.7).
Sia nel guestbook che nei post (Figura 5.9) si possono lasciare dei com-
menti e partecipare alle discussioni che lì nascono e si sviluppano.
Per i commenti e i post è stato implementato un sistema di rating che
permette agli utenti di esprimere il proprio gradimento assegnando un voto
positivo o negativo.
La pagina posts.jsp corrisponde ad un blog in cui si possono scrivere e
pubblicare nuovi post o modificare e cancellare quelli già presenti se si è
autori.
Vi sono poi le pagine users.jsp e groups.jsp nelle quali sono elencati rispet-

5.3. REALIZZAZIONE 55
Figura 5.7: Gestione delle amicizie
tivamente tutti gli utenti e tutti i gruppi (Figura 5.10) presenti su PoliBook
e per ognuno di essi è possibile visitare il profilo dedicato.
Per ogni gruppo è mostrato il logo, la descrizione e gli utenti che ne
fanno parte e dal menu secondario si può scegliere di diventarne membri o di
lasciarlo.
Vi è poi la pagina dedicata ai propri gruppi, mygroups.jsp in cui è possibile
crearne uno nuovo diventandone amministratore.
L’inbox funziona come una casella email e permette di inviare, ricevere e
gestire i messaggi privati all’interno del social network.
I nuovi messaggi in arrivo vengono segnalati attraverso le notifiche nella
homepage ed evidenziati graficamente nella lista dei messaggi in arrivo nella
inbox.

56 CAPITOLO 5. POLIBOOK
5.4 Valutazioni
Figura 5.8: Guestbook
La creazione del social network sopra descritto ha messo in evidenza i van-
taggi e gli svantaggi dell’approccio proposto in questa tesi.
Poiché è necessario progettare a priori tutta la parte di design, appare
evidente che occorre un tempo iniziale di progettazione del sistema, il qua-
le può variare sensibilmente a seconda del livello di dettaglio che si vuole
ottenere.
In questo caso si è voluto approfondire maggiormente i meccanismi più
tipici riscontrati nelle reti sociali, lasciando un poco più astratti quelli meno
diffusi.
Una volta superata questa fase il meccanismo di selezione e rifinitura ri-
sulta immediato e veloce, grazie al mapping automatico, e anche abbastanza
flessibile nella modifica o aggiunta di ulteriori classi, metodi o attributi.
La parte di implementazione è quella che ha necessitato di maggior tempo
per essere portata a termine.
Avendo prestato la dovuta attenzione in fase di design, l’implementazione

5.4. VALUTAZIONI 57
Figura 5.9: Esempio di post
delle classi e dei metodi è risultata abbastanza veloce ed efficace.
Quello che maggiormente ha inciso sul tempo è stata invece la realizza-
zione dell’interfaccia web con la parte grafica, e il debugging.
In Tabella 5.1 sono mostrate le tempistiche qualitative relative allo svi-
luppo e all’implementazione di ogni feature di PoliBook.
I tempi nella colonna classes comprendono la rifinitura manuale del codice
generato con ArgoUML, l’implementazione dei metodi e la scrittura delle
query al database relative alla specifica classe.
Si tratta della logica di secondo livello costituita dalle classi mappate in
automatico ed esaminate in fase di design.

58 CAPITOLO 5. POLIBOOK
Figura 5.10: Profilo del gruppo
La colonna UI invece elenca i tempi dello sviluppo e della realizzazio-
ne dell’interfaccia grafica, quindi la logica del primo strato, costituita dalle
pagine jsp e dalle servlet coinvolte nel caricamento dei dati.
Questa parte è stata codificata tutta manualmente poiché non coperta
dall’approccio, dal momento che essa può variare sensibilmente sia in base alle
features scelte che in base all’obiettivo finale del social network desiderato.
Sono poi elencati i tempi totali dedicati ad ogni singola features e infine
le tempistiche globali.
Su un totale di circa 55 ore risulta che il 32% è stato dedicato all’imple-
mentazione delle classi mentre ben il 68% all’interfaccia web.
Nella Tabella 5.2 sono mostrate numericamente le righe di codice delle
classi implementate, distinguendo tra le righe generate in automatico e quelle
aggiunte manualmente.
Per ogni classe le righe di codice generate automaticamente sono quelle
nella colonna auto, derivanti da ArgoUML, alle quali si possono aggiungere
quelle dei metodi getters and setters generabili con Eclipse, o IDE equivalenti
che dispongano di tale funzione, rappresentate nella colonna get/set.
Le righe di codice scritte a mano per implementare i metodi sono elen-

5.4. VALUTAZIONI 59
feature classes UI total
user .30 .45 1.15
profile .40 2.30 3.10
friends 1.45 4.00 5.45
groups 1.45 4.00 5.45
posts 1.30 4.00 5.30
guestbook 1.30 4.00 5.30
comments .30 1.15 1.45
inbox 2.00 4.30 6.30
directmessages .30 1.15 1.45
authorizations 1.20 1.45 3.05
updates .45 1.45 2.30
activities 1.45 2.30 4.15
notifications 1.45 3.30 5.15
rating 1.20 2.00 3.20
total 17.35 37.45 55.20
Tabella 5.1: Tempistiche (espresse in ore e minuti)
cate nella colonna manual, mentre nella colonna total viene calcolata la
dimensione totale di ogni classe.
Ne risulta quindi che su 2244 righe di codice che costituiscono la logica
di secondo livello, circa il 66% viene generato in maniera automatica mentre
circa il 34% viene scritto successivamente a mano.
A questo punto bisogna considerare che l’aggiunta di codice manuale viene
effettuata soltanto la prima volta che si implementano tali classi.
Infatti le classi complete diventano dei templates riutilizzabili nelle pro-
gettazioni future a meno di piccole modifiche dipendenti dalle features sele-
zionate.
In questo caso, a livello qualitativo, il codice automatico raggiungerebbe
il 90% e in alcuni casi anche il 100%.
Sempre per questo stesso motivo, anche le tempistiche elencate nella Ta-
bella 5.1 calerebbero drasticamente per quanto riguarda l’implementazione
delle classi.

60 CAPITOLO 5. POLIBOOK
class auto manual get/set total
user 34 28 162 224
profile 25 16 96 137
friends 29 110 58 197
group 34 23 100 157
groups 37 80 30 147
post 32 51 100 183
posts 23 73 30 126
guestbook 29 38 30 97
comment 25 18 29 72
inbox 34 87 72 193
directmessage 19 19 53 91
message 18 0 51 69
authorizations 17 19 14 50
updates 25 142 48 215
activity 19 14 49 82
notification 19 13 49 81
rating 29 35 59 123
total 448 766 1030 2244
Tabella 5.2: Dimensione e sviluppo delle classi (espressi in righe di codice)
In conclusione, il grande vantaggio che emerge da questo approccio è
quello del riuso del codice e dei componenti che può risultare particolarmente
utile se si prevede di realizzare ad esempio un servizio di creazione di social
network.

Capitolo 6
Conclusione
In questo elaborato è stato illustrato un approccio per la progettazione di
una rete sociale che permetta in maniera veloce e funzionale di seleziona-
re le features e ottenere in modo automatico il design dal quale iniziale
l’implementazione.
Punto di partenza è un goal diagram contenente i requisiti tipici e parti-
colari dei social network esistenti dal quale selezionare le features desiderate.
La selezione avviene isolando i goals desiderati attraverso un software di
supporto dopodiché sfruttando un tool appositamente creato viene effettuato
in automatico il mapping su class diagrams UML.
Nella fase di design è possibile rifinire il sistema modificando le classi, i
metodi e gli attributi e quindi procedere con l’implementazione.
Infine è stato creato il social network PoliBook seguendo l’approccio
descritto.
6.1 Sviluppi futuri
I lavori futuri potrebbero concentrarsi sull’aumento dei meccanismi auto-
matici in fase di mappatura e sull’estensione degli stessi anche in fase di
implementazione.
Ad esempio si potrebbero creare in automatico le classi servlet e gli
scheletri delle pagine jsp in base alle features selezionate nel goal diagram.
61

62 CAPITOLO 6. CONCLUSIONE
Tutto ciò permetterebbe una ulteriore riduzione della scrittura manuale
del codice e un sostanziale risparmio di tempo.
Questa scelta però richiederebbe minore flessibilità nell’architettura, nel
senso che l’ambiente e l’architettura dovrebbero essere fissati e ben definiti
in partenza.
Proseguendo sempre sulla stessa linea si potrebbe pensare a componenti
grafici, come menu e aree, auto configurabili sempre in base ai goals da
raggiungere.
Un altro possibile sviluppo potrebbe essere quello di estendere il goal
diagram anche ai requisiti non funzionali e non solo a quelli funzionali.

Bibliografia
[1] Axel van Lamsweerde, Goal-Oriented Requirements Engineering: A
Guided Tour, http://courses.cs.ut.ee/2010/sem/uploads/Main/04RE-
reading-goals.pdf
[2] Alexei Lapouchnian, Goal-Oriented Requirements En-
gineering: An Overview of the Current Research,
http://www.cs.utoronto.ca/ alexei/pub/Lapouchnian-Depth.pdf
[3] KAOS, goal-oriented software requirements approach,
http://www.info.ucl.ac.be/ avl/ReqEng.html
[4] i*, modeling language, http://www.cs.toronto.edu/km/istar/
[5] Tropos, software development methodology,
http://www.troposproject.org/
[6] UML, Unified Modeling Language, http://www.uml.org/
[7] OMG, , Object Management Group, http://www.omg.org/
[8] ODBMS, Portale dedicato ai database ad oggetti,
http://www.odbms.org/
[9] Apache Tomcat, servlet container, http://tomcat.apache.org/
[10] GR-Tool, goal-reasoning tool, http://troposproject.org/tools/grtool/index.php
[11] OpenOME, an open-source requirements engineering tool,
http://www.cs.toronto.edu/km/openome/
63

64 BIBLIOGRAFIA
[12] ArgoUML, UML modeling tool, http://argouml.tigris.org/
[13] db4objects, object oriented database, http://www.db4o.com/