Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
" Definizione di linee guida per l'utilizzo e la gestione del sistema distribuito
collaborativo del Progetto S.F.I.N.G.E."
Relatore: A cura
1
Un sentito ringraziamento va al Prof. Marcello Castellano e al suo team di esperti che mi
hanno permesso di scrivere il seguente lavoro, sostenendomi quotidianamente nell’
apprendere nuove conoscenze professionali e umane che entreranno a far parte del mio
bagaglio culturale…
2
Introduzione
.................................................................................................................................
4
CAPITOLO
1
...................................................................................................................................
4
E-‐LEARNING
STORIA
E
DEFINIZIONE
.............................................................................................
5
1.1
COS’E’
L’E-‐LEARNING
....................................................................................................................
8
1.2
Migliorare
la
qualità
in
e-‐Learning
per
il
supporto
IT
basata
sulla
conoscenza
....
12
Capitolo
2
....................................................................................................................................
14
Elementi
e
funzionamento
di
un
portale
....................................................................................
14
2.1
Definizioni
generali
....................................................................................................................
14
2.2
Esempio
di
una
sequenza
di
eventi
.......................................................................................
16
2.3
Limiti
della
specifica
JSR-‐168
..................................................................................................
17
Capitolo
3
....................................................................................................................................
19
3.1
Introduzione
a
Liferay
Portal
..................................................................................................
19
3.2
Panoramica
delle
caratteristiche
del
portale
....................................................................
21
3.3
Funzioni
di
collaborazione
.......................................................................................................
23
3.4
Gestione
degli
utenti
e
gruppi
.................................................................................................
24
3.4.1
Utenti
..........................................................................................................................................................
26
3.4.2
Gruppi
di
utenti
......................................................................................................................................
26
3.4.3
Organizzazioni
........................................................................................................................................
26
3.4.4
Comunità
...................................................................................................................................................
27
3.4.5
Ruoli
............................................................................................................................................................
28
3.5
Scope
................................................................................................................................................
28
3.6
Architettura
e
framework
........................................................................................................
29
3.6.1
Service
Oriented
Architecture
.........................................................................................................
30
3.6.2
Enterprise
Service
Bus
........................................................................................................................
31
3.6.3
Spring
.........................................................................................................................................................
32
3.7
Strategie
di
sviluppo
del
portale
............................................................................................
33
3.7.1
Ambiente
Plugins
SDK
.........................................................................................................................
34
3.7.2
Ambiente
Extension
.............................................................................................................................
35
CAPITOLO
4
................................................................................................................................
37
S.F.I.N.G.E.
..............................................................................................................................................
37
CONCLUSIONE
............................................................................................................................
49
BIBLIOGRAFIA
E
SITOGRAFIA
DI
RIFERIMENTO
...........................................................
50
3
Introduzione
Il lavoro svolto all’ interno del Laboratorio di Sistemi Distribuiti, Dipartimento di
Ingegneria Elettrica e dell’Informazione del Politecnico di Bari, ha prodotto, nelle seguenti
pagine, un’ attenta e approfondita analisi dell’ e-learning concentrandosi in un’ ampio
resoconto storico del concetto di apprendimento a distanza, passando per un riscontro
tecnico degli strumenti utilizzati per implementare un, sempre più incalzante, tipo di
apprendimento che si può definire “at any time anywhere you want”. Infatti si cerca di far
comprendere l’ elevata importanza di piattaforme e-learning che consentono a chiunque di
implementare la propria formazione ovunque si voglia e con l’ ausilio di qualsiasi tipo di
dispositivo elettronico pc, tablet e smartphone capace di garantire una connessione e la
portabilità della propria formazione è assicurata. Successivamente si è passati a parlare di
concetti più tecnici soffermando l’ attenzione su quelli che sono gli strumenti che
permettono lo sviluppo del servizio, ossia le portlet e i portali che danno la possibilità di
sviluppare il servizio di e-learning infine ci si è soffermati sul lavoro svolto all’ interno del
progetto S.F.I.N.G.E.
4
CAPITOLO
1
E-‐LEARNING
STORIA
E
DEFINIZIONE
5
1. utilizzo di una connessione ad internet e di un dispositivo tecnologico
(computer, tablet, smartphone);
2. indipendenza da vincoli di presenza fisica e orari specifici (anywhere, anytime);
3. monitoraggio continuo del livello di apprendimento, tramite valutazione e
autovalutazione;
4. valorizzazione della multimedialità;
5. interattività con i materiali didattici, i docenti, i tutor, e con gli altri studenti;
6. valorizzazione della dimensione sociale e collaborativa dell’apprendimento.
L’evoluzione dell’e-learning nella storia della didattica vede tre principali generazioni di FAD
(formazione a distanza). La prima, denominata per corrispondenza, risale alla metà
dell’Ottocento, ed era basata sul supporto del servizio postale e sullo sviluppo delle reti dei
trasporti; consisteva essenzialmente nell’utilizzo di materiale didattico cartaceo corredato di
istruzioni per lo studio autonomo e di test di verifica da rispedire al mittente. Si ha traccia di un
primo corso a distanza realizzato a Londra nel 1840 (Eletti, 2002, p.18) e, successivamente, in
altre località dell’Inghilterra e in Svezia. I corsi proposti erano prevalentemente di tipo tecnico-
commerciale, erogati da privati ed indirizzati a coloro che potevano permettersi un’istruzione al
di fuori del contesto scolastico. Le potenzialità di questa modalità didattica vengono rafforzate
dall’introduzione della radio nella prima metà del Novecento, che sancisce il passaggio dalla
modalità one-to-one alla one-to-many. I primi corsi universitari via radio vengono organizzati
negli Stati Uniti dal 1921; in Europa è la BBC inglese ad introdurli, a partire dal 1927 (Ganino,
2009, p. 59).
La seconda generazione si sviluppa negli anni sessanta, con
l’introduzione della televisione. Subito le sue potenzialità educative risultano evidenti: in
particolare l’impatto e la fascinazione molto forte delle immagini, il raggiungimento delle fasce
sociali a basso reddito, la facile comprensione anche da parte di un pubblico analfabeta.
L’impatto sulla società di massa viene poi amplificato con la diffusione dello standard VHS,
che ha aumentato l’uso domestico di materiale educativo in modalità asincrona.
La terza generazione, relativa all’attuale fase di FAD, è invece legata
6
alla diffusione del digitale a partire dagli anni ottanta. L’introduzione del computer sancisce una
svolta epocale nel paradigma didattico-educativo, attraverso il rafforzamento del ruolo
dell’utente grazie ai principi di interattività, multimedialità e crossmedialità. Due sono le fasi
principali che la caratterizzano:
- fase off-line, basata sull'uso di strumenti che non si avvalgono
del supporto delle reti (floppy disk, videodischi, cd-rom);
- fase on-line, caratterizzata dalla diffusione dell'uso di Internet.
Con l'avvento della formazione on-line, l'apprendimento diventa un
processo sociale dinamico che prevede il ruolo attivo dell’utente che entra a far parte di una
comunità in cui regna una condivisione di tipo orizzontale della conoscenza. Tutto ciò favorito
dal passaggio dal Web 1.0 al Web 2.0 e la nascita di strumenti che facilitano le attività autoriali,
di condivisione, collaborazione, partecipazione. La rete utilizzata non più soltanto come
strumento per accedere alle informazioni ma contraddistinta da caratteristiche social (wiki, blog,
youtube, social software ecc.) favorisce il consolidamento del concetto di e-learning e la sua
applicazione in contesti diversi: formazione universitaria, aziendale, formazione continua.
Questo tipo di formazione risponde alle esigenze della società contemporanea di tenere
continuamente aggiornati i saperi e le competenze dei propri membri, per non trovarsi in
condizioni di inferiorità sullo scenario dell’economia globalizzata. Come esempio
dell’importanza di questo tipo di formazione, si può dire che nel bilancio USA il totale della
spesa destinata alla formazione universitaria è uguale al totale della spesa investita nella
formazione continua dei cittadini [Banzato, 2003]. In Europa, ed in Italia, si riscontra un certo
ritardo nell’adeguamento dell’offerta formativa alle esigenze della formazione continua e
dell’Information Communication Technology (ICT). Tra le cause, si può annoverare una
percezione diffusa dell’e-learning come un semplice trasferimento in rete del modello di
lezione in presenza [Calvani, 2005]. In realtà la formazione on-line assume varie sfaccettature, e
accanto a modalità erogative dei corsi, che si basano sul modello tradizionale di didattica
incentrato sullo studio individuale e sui test di valutazione, si assiste all’affermazione di modelli
innovativi, nei quali la conoscenza individuale viene considerata come il risultato di una
costruzione collaborativa, frutto delle interazioni sociali instaurate fra i partecipanti al processo
formativo.
7
1.1
COS’E’
L’E-‐LEARNING
8
alcune forme di e-learning come "soluzioni di insegnamento centrato sullo studente".
I Learning Object
Come si avrà avuto modo di capire, l'e-learning è un processo di
formazione continua che implica l'utilizzo delle tecnologie di rete per progettare, distribuire,
scegliere, gestire e ampliare l'apprendimento. In quest'ottica gli elementi principali nella
progettazione di contenuti erogabili via rete, i quali rendono la Formazione a distanza
(abbreviata in FAD) non più assimilabile ai monolitici corsi tradizionali da distribuire
indistintamente a tutti gli studenti, sono tre:
- l'interattività, vale a dire la necessità di coinvolgere il discente, generalmente
avvalendosi del learning by doing;
- la dinamicità, ovvero il bisogno da parte del discente di acquisire nuove
competenze mirate just in time;
- la modularità, ossia la possibilità di organizzare i contenuti di un corso secondo
gli obiettivi formativi e le necessità dell'utenza.
Spendiamo altre due parole su questo terzo e ultimo elemento. Ogni
blocco formativo (detto nel linguaggio tecnico learning object) può essere sfilato e da un corso
e assemblato con altri blocchi formativi per formare un corso nuovo: per tanto il learning
object può esser definito come un qualsiasi oggetto che entra a far parte del processo di
formazione e che può essere (ri)utilizzato in tempi e luoghi diversi. La grandezza di un learning
object varia a secondo la metodologia adottata dal progettista. Ma quali sono le caratteristiche
necessarie ai learning objects per poter essere riutilizzati?
I. Sono facilmente reperibili e trasportabili;
II. possibilità di gestire gli archivi dei contenuti;
III. assegnare ai singoli learning objects dei set di metadata.
Oggigiorno esistono solo due certificazioni di trasparenza e
riutilizzabilità dell'e-learning: l'AICC (acronimo di Aviation Industry CBT Committee) e la
SCORM (Sharable Courseware Objects Reference Model). Esistono poi altri gruppi impegnati
nella definizione di una specifica internazionale dei lerning object, definita e condivisa,
menzioniamo ARIADNE (Allience of Remote Instructional Authoring and Distribution
Network for Europe) e PROMETEUS (PROmoting Multimedia access to Education and
9
Training in EUropean Society). Da segnalare l'utilizzo del linguaggio XML (Extensible Markup
Language) che consente infatti una migliore atomizzazione dei contenuti e una più efficace
esportabilità sui diversi supporti (p.e. palmeri, periferiche indossabili ecc.).
I contenuti dell'e-learning
I contenuti dei corsi didattici possono essere progettati in diversi
formati: pagine HTML, animazioni 2D o 3D, contributi audio, contributi video, simulazioni,
esercitazioni interattive, test,… In qualsiasi caso, si tratta di contenuti realizzati in modalità
multimediale e possono essere costruiti ad hoc (attraverso software di authoring) o essere stati
modificati da materiale già esistente in formato elettronico come ad esempio gli eBook (anche
in modo molto semplice, salvando - ad esempio - una presentazione in formato HTML).
Gli esperti di e-learning sostengono che i materiali didattici
dovrebbero essere costruiti ad hoc in modo da garantire le quattro principali caratteristiche
10
della formazione online:
- modularità
il materiale didattico deve essere composto da moduli didattici,
chiamati anche Learning object (LO) in modo che l'utente possa
dedicare alla formazione brevi lassi di tempo (indicativamente
15/20 minuti di tempo), personalizzando così tempi e modalità di
approccio ai contenuti.
- interattività
l'utente deve interagire con il materiale didattico, che deve
rispondere efficacemente alle necessità motivazionali
dell'interazione uomo-macchina
- esaustività
ogni LO deve rispondere a un obiettivo formativo e portare l'utente
al completamento di tale obiettivo.
- interoperabilità
i materiali didattici devono essere predisposti per poter essere
distribuiti su qualsiasi piattaforma tecnologica e per garantire la
tracciabilità dell'azione formativa. A tal fine sono stati individuati
quindi degli standard (AICC, SCORM, IMS,…) che devono essere
implementati per garantire la comunicazione fra diversi sistemi e
fare in modo che un Learning Object concepito su una piattaforma
possa essere integrato in un'altra. Attualmente lo standard più
diffuso è SCORM.
L'evoluzione tecnologica ha portato alla realizzazione di sistemi
Learning Content Management System (LCMS) che si occupano della gestione dei contenuti
sia nella fase di creazione che nella fase di erogazione. Tali strumenti, associati al LMS,
completano una piattaforma di e-learning.
Da un punto di vista tecnico, i Learning Object sono oggetti descritti
tramite specifiche XML e/o, appunto, dialetti specializzati di XML come EML ed altri, che
vengono interpretati dal browser nella sua interazione con il LCMS server per costruire
l'oggetto documentale, multimediale, il test con le sue caratteristiche e, in SCORM e successivi,
11
anche la corretta sequenza di contenuti del percorso formativo. Un oggetto di apprendimento
(LO) può contenere inoltre specifiche del livello di ingresso, dei prerequisiti, del contesto di
applicazione.
1.2 Migliorare la qualità in e-‐Learning per il supporto IT basata sulla conoscenza
QUALITA’ IN E-LEARNING
Al fine di aumentare l'efficacia nel processo di apprendimento, diversi
approcci sono stati sviluppati oltre l’ istruzione tradizionale. Efficacia del sistema di istruzione
dipende dal grado di qualità che esibisce. Il potere di imparare attraverso Information
Technology (IT), in una certa misura garantisce l'apprendimento di alta qualità, fornendo le
informazioni necessarie, passo assistenza saggio, e consiglia per il processo decisionale in modo
costo-efficacia. La tecnologia e-Learning è un'infrastruttura che privilegia la distribuzione
online di informazioni e, quindi, accelera l'apprendimento. Le principali figure di un sistema di
e-learning sono: esperti della materia, sviluppatori multimediali, istruttori, editori, progettisti, e
tecnici (Kanedran, Johnny & Durga 2004). I vantaggi, come la disponibilità di informazioni di
alta qualità sulle punte delle dita, consulenza tempestiva, e la rappresentazione efficace di
informazioni possono essere raggiunti con la tecnica e-Learning. Obiettivi primari della
struttura tecnica di e-Learning sono i seguenti (Unwin 2003):
12
disposizione del corso;
13
Capitolo
2
- portale;
- portlet;
- portlet container.
14
Il contenuto generato da una portlet è denominato anche frammento. Quest’ultimo è del
markup (ad esempio HTML, XHTML, WML) che aderisce a certe regole e che può essere
aggregato ad altri frammenti per costituire un documento completo. Il frammento di una stessa
portlet può variare da un utente all’altro a seconda della configurazione apportata ad essa.
Diverse portlet, integrate insieme, concorrono a creare una singola pagina del portale. Inoltre,
una stessa portlet può essere utilizzata in più pagine.
15
risultato finale una pagina web configurabile ed adattabile alle sue volontà.
Tecnicamente, la rappresentazione finale è affidata per gran parte al portlet container che
gestisce il loro ciclo di vita. Infatti, il suo compito è di seguire le azioni dell’utente (link, form,
javascript, ecc.), eseguire la logica di business di tutte le portlet presenti nella pagina ed infine
passare al portale i frammenti generati dalle stesse. In seguito il portale aggrega il risultato
proveniente da ognuna di esse in un pannello tipo quello in figura 2.1.
Per consentire la portabilità tra i vari portlet container commerciali, è stata fatta
richiesta al Java Community Process (JCP) di formalizzare uno standard apposito per le portlet, lo
standard JSR-168 (Java Portlet Specification 1.0 [3]).
Quest’ultimo è stato rilasciato nel 2003 e al gruppo di lavoro hanno partecipato diverse
importanti aziende tra le quali Apache Software Foundation, IBM, Sun Microsystems, Oracle.
La specifica ha definito un insieme di interfacce applicative (API) per l’interoperabilità
fra un portlet container e le portlet. In particolare, ha fissato i seguenti punti:
che definisce un protocollo standard per il dialogo tra il container e le portlet. Il portlet
container, dunque, contiene le portlet e gestisce il loro ciclo di vita. Si occupa di immagazzinare
le preferenze e le configurazioni di ogni portlet.
Inoltre, riceve le request dal portale e le indirizza alle portlet che gestisce. Un portlet
container non è però responsabile dell’aggregazione dei contenuti generati dalle diverse portlet.
Questo è, infatti, compito del portale.
Portale e container possono essere integrati insieme come un componente singolo di
una suite di applicazioni oppure come due parti separate di una portal application.
16
utente accede alla pagina del portale:
- un client (ad esempio un browser web), dopo essersi autenticato, esegue una richiesta
HTTP al portale;
- la richiesta viene ricevuta dal portale;
- il portale determina se la richiesta contiene un’azione mirata su un qualsiasi delle portlet
associate alla pagina;
- se c’è un’azione indirizzata ad una portlet, il portale richiede al portlet container di
invocare la portlet per processare l’azione;
- attraverso il container, il portale invoca le portlet per ottenere i frammenti generati da
esse che possono essere inclusi nella pagina risultante;
- il portale aggrega gli output delle diverse portlet nella pagina e rimanda quest’ultima al
client.
17
di arrivare alla specifica. Le novità introdotte riguardano principalmente i seguenti punti:
- ogni portlet può lanciare e ricevere determinati eventi;
- possibilità per le portlet di condividere parametri tra loro, attraverso i public
render parameter;
- capacità di una portlet di restituire una risorsa;
- supporto migliore alla tecnologia AJAX.
Il nuovo standard è stato progettato per essere retrocompatibile con la prima specifica.
Dunque, tutte le operazioni descritte in precedenza (ciclo di vita, caricamento pagina del
portale, gestione delle richieste) sono valide, così come mantiene la compatibilità con tutti i
metodi delle vecchie API.
Per via delle nuove funzionalità introdotte, oltre a nuovi metodi, sono state aggiunte
diverse entry nel nuovo deployment descriptor.
18
Capitolo
3
19
Esistono due versioni per questo progetto:
- Community Edition (CE), completamente gratuita (è distribuita sotto licenza
GNU LGPL), destinata a sviluppatori, community e a coloro che vogliono
valutare le potenzialità di questa applicazione;
- Enterprise Edition (EE), versione più stabile della precedente e che, come dice la
parola stessa, è destinata ad usi professionali da parte delle imprese, e
comprensibilmente a pagamento.
L’applicazione fornisce un’interfaccia web unificata per le varie informazioni e gli
strumenti che provengono da diverse sorgenti. All’interno del portale, come si è visto, questa
interfaccia è composta da un certo numero di portlet. Dal momento che queste ultime sono
sviluppate indipendentemente dal portale e che quindi sono scarsamente accoppiate con esso,
si può parlare di una piattaforma basata su un’architettura SOA.
Liferay presenta una vasta gamma di portlet liberamente disponibili per blog, forum,
sondaggi, calendario, raccolta documenti, galleria immagini, feed RSS, wiki, contenuti web e
così via.
Liferay presenta anche le soluzioni di CMS e Web Content Management (WCM).
Liferay CMS è dotato delle funzionalità di base di Enterprise Content Management System
(ECMS), molto utili per la collaborazione in team. Le informazioni, infatti, possono essere
specifiche per un piccolo gruppo all’interno di un’azienda, ad esempio alcune saranno rilevanti
a livello di team, mentre altre in tutta l’organizzazione. Il portale in questione supporta molto
bene questo tipo di situazioni.
Riassumendo, Liferay ha quindi tre principali funzionalità:
- portale;
- CMS e WCM: sistema di gestione dei contenuti aderente allo standard JSR-170
e gestione dei contenuti web;
- software sociali per la collaborazione tra utenti, come blog, forum, wiki,
annunci, bacheca delle attività, ecc..
In generale, dunque, un sito web costruito usando Liferay può essere costituito dagli
elementi sopra elencati dei quali, qui di seguito, si illustreranno le varie peculiarità e i vantaggi
offerti.
20
3.2
Panoramica
delle
caratteristiche
del
portale
Dal momento che Liferay è il leader nel campo dei portali aziendali open source,
fornisce soluzioni sia per il settore privato che per quello pubblico. A tale scopo, presenta
queste caratteristiche e funzionalità:
- gira su tutti i principali application server, come ad esempio Tomcat, Glassfish,
JBoss, Geronimo, Jetty, JOnAS, Resin, Weblogic, WebSphere;
- supporta numerosi database, tra i quali si possono citare MySQL, Oracle, SQL
Server, PostgresSQL, JDataStore, Sybase, SAP, Apache Derby, Firebird,
Hypersonic;
- è multipiattaforma, in quanto è eseguibile su diverse famiglie di sistemi
operativi quali Linux, Unix, Windows e Mac OS X;
- utilizza l’ultima versione di Java J2EE e le moderne tecnologie Web 2.0; è
compatibile con le specifiche JSR-168 e JSR-286 per le portlet; interfaccia
utente basata su AJAX;
- oltre 60 portlet pronte all’uso: forte di un’estesa community, Liferay fornisce il
numero maggiore di portlet già integrate di qualsiasi altro portale sul mercato;
- drag and drop dinamico: gli utenti possono spostare gli elementi nel portale
semplicemente trascinando e rilasciando il mouse;
- tagging e ricerca di risorse: possibilità di etichettare i documenti, i contenuti web,
i messaggi dei forum ed altri elementi in modo dinamico e condividendo questi
tag con gli altri utenti del portale. Gli utenti possono quindi ricercare tramite le
etichette assegnate alle informazioni o gruppi di informazioni comuni;
- pagine personali: tutti gli utenti abilitati possono avere uno spazio personale
dove immettere proprie informazioni e decidere se renderle pubbliche o tenerle
private. È possibile personalizzare lo spazio messo a disposizione tramite il drag
& drop delle portlet;
- supporto multilingua;
- sincronizzazione LDAP;
- supporto all’autenticazione unica Single Sign On (SSO): il portale consente agli
utenti di accedere ai contenuti e applicazioni da un unico punto di accesso.
Liferay può infatti aggregare diversi sistemi applicativi rendendoli disponibili
21
accedendo una volta sola con il massimo della riservatezza;
- sistema di autorizzazioni granulare basato sul ruolo di un utente: per garantire
che le persone accedano con diritto alle sole informazioni/dati per le quali sono
autorizzate, gli amministratori del portale possono assegnare ai singoli utenti o
gruppi di utenti diversi ‘‘ruoli’’ per attribuire loro differenti livelli di accesso e
differenti diritti di modifica;
- gestione centralizzata di tutti i contenuti, risorse, utenti, comunità, ruoli
attraverso un pannello di controllo completamente personalizzabile con la
possibilità di aggiungere o togliere alcune sue parti;
- facile configurazione: una veloce ed intuitiva interfaccia rende Liferay
estremamente semplice da utilizzare da tutti i membri di un’organizzazione. Il
tempo per modificare un layout di pagina, l’aggiunta di nuove applicazioni e
contenuti, cambiando anche l’aspetto della grafica può essere fatto in un paio di
click, anche dall’utente finale stesso;
- sistema di gestione dei contenuti: il CMS incluso all’interno di Liferay fornisce
un insieme esteso di funzionalità fortemente integrate con le funzioni di
collaborazione e fornisce un repository centralizzato per conservare e gestire
contenuti da visualizzare sul web. Ciascuna community e ciascuna organization
hanno a disposizione una propria separata document library e image gallery. Il CMS
è implementato tramite Liferay Journal, un contenuto intrinseco (‘‘built-in’’) del
portale che abilita una serie di funzionalità di gestione contenuti;
- Web Publishing, sistema che può essere usato per creare pagine web in modo
veloce usando dei contenuti riusabili, dei modelli (template) per layout flessibili;
- Flexibile Template Mechanism (XSL/VM): i modelli creati per i Journal articles (così
vengono chiamati i contenuti web) possono essere realizzati in XSL o Velocity (VM)
offrendo così agli sviluppatori la flessibilità di disegnare le pagine web;
- Document Library, che provvede un deposito centralizzato per i servizi della
libreria, basato sulla specifica Java Content Repository (standard JSR-170 ) per
trattare diversi tipi di documenti (PDF, DOC, ecc.) che possono essere salvati
sotto un unico URL;
- Image Gallery, che fornisce un deposito centralizzato per le immagini;
22
- Portal Publishing & Staging: la funzione di publishing permette di modificare pagine
web in tempo reale senza però pubblicare subito il cambiamento ma solo
quando si decide di farlo. Lo staging, invece, consente di creare varie copie di
modifica della stessa pagina e testarle senza toccare le pagine correnti sul
portale.
23
amici vengono automaticamente visualizzati i nomi degli amici collegati.
L’accesso al servizio è inserito in una barra in fondo alla videata e segue l’utente
lungo la navigazione all’interno del portale rimanendo sempre disponibile;
- calendari: è possibile impostare ed utilizzare calendari di gruppo (basati sulle
community). Gli eventi possono essere condivisi ‘‘intragruppi’’, gli alert sugli
eventi possono essere impostati per un avviso via email, instant messaging o
SMS;
- avvisi: è possibile inviare messaggi di tipo broadcast a gruppi di utenti. Ogni
utente può settare le modalità di ricezione degli avvisi tramite web alert via
portale, SMS, email o altre modalità di delivery impostate dall’amministratore;
- sondaggi: sono disponibili delle portlet per l’impostazione, la presentazione e la
raccolta dati di sondaggi. Possono essere configurati e pubblicati più sondaggi
in contemporanea con visibilità differenziate rispetto ai gruppi;
- tracking delle attività: la portlet ‘‘Attività Recenti’’ tiene traccia delle attività più
recenti effettuate sul portale (contributi o commenti su blog, bacheche, wiki e
altri strumenti). L’approccio e la presentazione sono simili a quelli di Facebook;
- RSS: Liferay consente di condividere, opzionalmente, tutte le tipologie di
contenuto tramite feeding RSS.
24
Questo vuol dire, ad esempio, che le organizzazioni possono essere parte di comunità, queste
ultime possono essere parte di ruoli, gli utenti possono essere parte di qualsiasi cosa, e così via.
Anche se ciò sembra molto complesso, fornisce un potente meccanismo per configurare le
risorse del portale in un modo consistente e robusto. È importante notare che il diagramma
riporta solo gli utenti e i loro possibili raggruppamenti. I permessi non hanno influenza sui
gruppi, ma possono essere assegnati solamente ai ruoli.
Al portale possono avere accesso diverse categorie di utenti. La prima distinzione da
fare è tra utente autenticato e visitatore anonimo. Anche questi ultimi possono utilizzare le
portlet, purché esse siano configurate opportunamente, dipende dall’obiettivo del portale. Se si
tratta di un portale aperto al
Figura 3.1: Organizzazione delle risorse umane e loro gruppi nel portale.
pubblico, e che magari all’utente autenticato riserva più funzionalità personalizzate, saranno
apportate opportune configurazioni alle portlet; se, invece, il portale è totalmente privato, ad
esempio un’intranet, saranno fatte le diverse configurazioni del caso.
In generale si può parlare di ruoli all’interno di Liferay: avere un ruolo significa
sostanzialmente possedere un insieme di permessi di esecuzione di alcune azioni. Nel sistema
sono presenti dei ruoli predefiniti: amministratore, ospite, ecc..
Tuttavia è possibile definire e personalizzare i ruoli, creando così profili molto
particolari, che possono ad esempio avere accesso solo su determinate portlet e/o che possono
svolgere su di esse solamente alcune azioni.
25
3.4.1
Utenti
Gli utenti possono essere raggruppati in diverse maniere. Possono essere infatti
membri di gerarchie di un’organizzazione oppure far parte di gruppi arbitrari (ad esempio il
gruppo ‘‘Bloggers’’ che permetterebbe loro, ad esempio, di creare pagine di blog nei loro spazi
personali). Possono anche essere raggruppati da comunità che condividono un interesse
comune. Possono infine avere uno o più ruoli che descrivono le loro funzioni nel sistema e tali
ruoli possono essere nell’ambito dell’organizzazione, della comunità o dell’intero portale.
Ogni utente autenticato, inoltre, può possedere un numero a piacere di pagine private,
ovvero accessibili solo da lui, e di pagine pubbliche, cioè accessibili a tutti gli utenti della
comunità o organizzazione.
3.4.3
Organizzazioni
Le organizzazioni sono insiemi gerarchici di utenti. Sono utili per poter suddividere gli
utenti nello stesso modo in cui sono suddivisi all’interno delle imprese cui appartengono. In
sostanza ciò che si può fare è creare delle gerarchie aziendali. Ad esempio, se con Liferay si
vuole gestire una grande azienda, può essere utile definire un determinato utente attraverso la
sua posizione nell’organigramma aziendale. Se, ad esempio, quell’utente è un responsabile
commerciale che lavora sia per la sede di Padova che per quella di Bologna, potrebbe essere
membro delle organizzazioni ‘‘Vendite’’, ‘‘Sede di Padova’’ e ‘‘Sede di Bologna’’. Le
organizzazioni possono essere parte di comunità e, come queste ultime, dispongono di pagine
personalizzabili al loro interno.
26
3.4.4
Comunità
Le comunità sono gruppi di utenti che condividono un particolare obiettivo/interesse
comune. Esse, infatti, sono molto simili alle organizzazioni ad eccezione di non essere
gerarchiche e sono pensate per essere dei luoghi a se stanti ai quali chiunque, da ogni
organizzazione (o anche da nessuna), può unirsi. Le comunità si possono poi utilizzare in ogni
situazione in cui si ha la necessità di tralasciare la struttura organizzativa e raggruppare gli
utenti in modo trasversale.
Le comunità sono i luoghi di lavoro ideali dei team per collaborare su progetti comuni.
Forniscono infatti un’area isolata dove un gruppo di persone possono inserire tutte le loro
informazioni relative ad un particolare argomento. Molte aziende le usano proprio per tale
scopo, in quanto questo si rivela essere un sistema di gran lunga migliore di condividere i dati
rispetto all’uso di mail e semplici cartelle condivise in rete.
Come visto in precedenza, infatti, la document library consente agli utenti di accedere ai
documenti presenti in essa, ed usufruire anche di un apposito sistema di versionamento. La
portlet del calendario permette di tenere traccia di tutti gli appuntamenti e le riunioni del team
di lavoro, mentre il forum è un ottimo strumento per mantenere in un solo posto tutte le
discussioni dei membri.
La home page di default di Liferay è una comunità chiamata ‘‘Guest’’ e su questa
andrebbe inserito il sito web pubblico accessibile da tutti.
Le comunità possono essere create e gestite in due modi. Il primo è attraverso il
pannello di controllo, proprio come ogni altra risorsa del portale. L’altro è tramite la portlet
‘‘Le mie comunità’’ che può essere aggiunta in ogni pagina.
Tale portlet permette agli utenti di scorrere la lista delle comunità e per ognuna di esse
scegliere se unirsi o meno. Ciò permette all’amministratore del portale di fornire questa
funzionalità agli utenti senza dare accesso loro al pannello di controllo.
In Liferay si individuano tre tipi di comunità:
- pubbliche;
- private;
- nascoste.
Una comunità pubblica permette agli utenti del portale di unirsi od uscire da essa ogni
qualvolta lo vogliono. Questo lo possono fare utilizzando il pannello di controllo o la portlet
dedicata a tale scopo (che deve essere aggiunta ad una pagina a cui gli utenti hanno accesso).
27
Una comunità privata, invece, necessita che gli utenti siano aggiunti ad essa
dall’amministratore della comunità. Gli utenti, anche in questo caso, possono usare il pannello
di controllo o la portlet dedicata per richiedere l’adesione.
Infine, una comunità nascosta è come una privata, con l’aggiunta del fatto che essa non
è visibile nella portlet delle comunità o come entry del pannello di controllo.
3.4.5
Ruoli
I ruoli sono raggruppamenti di utenti che condividono una funzione particolare
all’interno del portale, secondo un determinato ambito. Quindi, avendo definito i possibili ruoli
che gli utenti possono ricoprire, la loro suddivisione secondo questo parametro viene di
conseguenza. I ruoli possono concedere dei permessi alle varie funzionalità presenti e in tal
senso si può pensare ad un ruolo come ad una descrizione di una funzione. Ad esempio, un
ruolo con il nome ‘‘Amministratore forum’’ molto probabilmente avrà i permessi per far
funzionare opportunamente la portlet del forum. Gli utenti che si collocano in quel ruolo
erediteranno tutte le varie autorizzazioni stabilite. I ruoli possono essere legati all’intero portale,
ad un’organizzazione o ad una comunità. Anche in questo caso il pannello di controllo è
fondamentale, in quanto consente di assegnare gli utenti a dei ruoli ed attribuire particolari
permessi a questi ultimi.
3.5
Scope
Nella versione 5.2 di Liferay è stato introdotto il concetto di scope. In italiano questo
termine può essere tradotto come ‘‘ambito’’ o meglio ancora come ‘’raggio d’azione’’. Più in
dettaglio, si può dire che uno scope identifica un insieme di dati che è isolato da un altro insieme
di dati memorizzato nel database del portale. Ad esempio, se si aggiunge una portlet del forum
in due comunità diverse, ognuna ha il proprio insieme di dati.
Come citato in precedenza, un ruolo può essere in ambito del portale, di
un’organizzazione o di una comunità. Ciò significa che ha effetto solo nell’ambito in cui risiede.
Ritornando all’esempio fatto nella sezione 3.4.5, si può dire che un ruolo ‘‘Amministratore
forum’’ con completo accesso alla relativa portlet presenta dei permessi differenti a seconda
dello scope del ruolo. Infatti se è un ruolo normale, i membri hanno il permesso di gestire i
forum dell’intero portale.
28
Se, invece, è un community role i membri hanno il permesso di gestire i forum solo
all’interno delle comunità in cui sono membri del ruolo. Se, infine, è un organization role i
membri hanno l’autorizzazione di amministrare il forum solamente nelle organizzazioni in cui
sono membri del ruolo.
Similmente a ciò, anche alcune portlet presenti in Liferay possono ora avere degli scope
che vanno oltre le specifiche comunità o organizzazioni su cui sono inserite. Infatti, è possibile
fare in modo che lo scope sia per pagina. Questo permette di aggiungere ad una
comunità/organizzazione un numero qualsiasi di tali portlet e, fino a quando queste ultime
verranno inserite in pagine diverse, avranno insiemi di dati differenti. Ciò permette di avere più
di un’istanza di una certa portlet in una comunità o organizzazione.
Tutte le principali portlet ‘‘out of the box’’ (forum, blog, calendario, ecc.) di Liferay
supportano il concetto di scope e questo offre molta più flessibilità nel modo in cui si desidera
impostare il portale. Tuttavia, per default, lo scope è impostato che sia per comunità o
organizzazione.
Se lo scope di una determinata portlet è per pagina, quindi, si possono inserire diverse
istanze della stessa in una certa comunità/organizzazione, purché siano piazzate in pagine
differenti.
29
Figura
3.2:
Architettura
di
Liferay
Portal.
30
servizi;
- essere definito da un’interfaccia ed indipendente dall’implementazione; essere
debolmente accoppiato con altri servizi;
- essere reso disponibile sulla rete tramite la pubblicazione della sua interfaccia ed
accessibile in modo trasparente rispetto alla sua allocazione;
- fornire un’interfaccia possibilmente a ‘‘grana grossa’’, con poche funzionalità in
modo tale da non dover avere un programma di controllo complesso;
- essere realizzato in modo tale da permetterne la composizione con altri.
In poche parole, si può dire che le caratteristiche chiave di Liferay comprendono,tra gli
altri aspetti, l’utilizzo massiccio dei principi SOA, affidabili sotto il profilo della sicurezza ed
integrati con SSO e LDAP. La piattaforma, inoltre, fornisce particolari strumenti e framework
per estendere il concetto di SOA ad altre applicazioni enterprise. L’architettura permette inoltre
agli utenti di accedere al portale non solo con i dispositivi tradizionali e wireless, ma gli
sviluppatori possono effettuare l’accesso grazie a specifiche API per mezzo di protocolli quali
REST, SOAP, XML-RPC ed altri.
31
In breve, si può dire che un portale basato su Liferay generalmente utilizza l’ESB per
dotarsi di un layer di astrazione sopra l’implementazione di un Enterprise Messaging System
(EMS), che consente di inviare semanticamente dei precisi messaggi tra sistemi di computer.
Ciò permette di utilizzare il contenuto della comunicazione senza scrivere codice.
3.6.3
Spring
Liferay usa il framework Spring per gli strati dei dati di business e dei servizi. Inoltre, lo
utilizza anche per la gestione delle transazioni. Tale framework, infatti, ha come obiettivo
principale quello di gestire la complessità nello sviluppo di applicazioni enterprise in ambiente
Java. Un’importante sua caratteristica è quella di non essere intrusivo, in quanto gli oggetti
sviluppati non dipendono dalle classi del framework.
Due sono gli aspetti principali di Spring i quali vengono spiegati qui di seguito. Il primo
è il pattern Inversion of Control (IoC) che serve a minimizzare le dipendenze fra gli oggetti
rendendo un’applicazione più robusta, facilitando anche il riutilizzo dei componenti e
rendendo più semplice lo sviluppo. Il concetto alla base dell’IoC è che le dipendenze degli
oggetti devono essere risolte da una qualche infrastruttura esterna che ha la responsabilità di
istanziare gli oggetti e di fornire loro le relative dipendenze. Quindi, il ciclo di vita degli oggetti
è gestito da un’entità esterna (container) come anche la loro configurazione che usa file XML.
Una delle tecniche con cui si può attuare l’IoC è la Dependency Injection (DI), cioè il
container si fa carico di ‘‘iniettare’’ le dipendenze nell’istanza di un oggetto automaticamente e
a runtime. Per fare questo utilizza costruttori e metodi setter. Attraverso la DI, quindi, si riesce a
separare il comportamento di una componente dalla risoluzione delle sue dipendenze,
minimizzando, allo stesso tempo, il livello di accoppiamento.
La seconda nozione è quella dell’Aspect Oriented Programming (AOP), un paradigma di
programmazione che mira a disaccoppiare tutte quelle caratteristiche di un sistema che sono
logicamente indipendenti da esso stesso ma lo ‘‘invadono’’ in maniera capillare (ad esempio la
security e gli aspetti transazionali).
In Liferay, l’interfaccia che espone i vari servizi della piattaforma è basata appunto sul
framework Spring. Basato su tale interfaccia è Portal-Impl, una libreria di Liferay il cui utilizzo è
rivolto principalmente per usi interni alla piattaforma, come ad esempio per l’ambiente di
estensione Ext. Altre librerie, come Portal-Kernel e Portal-Service, sono invece previste per usi
32
esterni (e anche interni). Forniscono infatti delle API che possono venir sfruttate da plugin
esterni, come avviene nell’ambiente Plugins SDK (descritto anche questo in seguito) per lo
sviluppo di temi e portlet.
33
3.7.1
Ambiente
Plugins
SDK
Plugins SDK è un semplice ambiente per lo sviluppo di plugin e, quindi, serve per
realizzare portlet, temi, layout, hooks1 come software indipendente dal portale. Tutte queste
componenti sono hot-deployable.
In particolare, le portlet create in Plugins SDK possono importare classi solamente dalle
librerie Portal-Kernel e Portal-Service (e dagli altri file JAR presenti nella cartella /WEB-
INF/lib della portlet), ma non da Portal-Impl.
Ciò forza le portlet ad affidarsi completamente alle API del portale e a non dipendere
dalle classi implementative definite in Portal-Impl. Per gestire le proprietà del portale, lingua e
JSP relative a Portal-Impl si devono usare gli hook.
L’ambiente SDK consente quindi di creare plugin hot-deployable per il portale Liferay
attraverso l’invocazione di task di Ant forniti insieme all’SDK, che permettono di
automatizzare attività (come ad esempio la generazione automatica della struttura del progetto
o il deploy a caldo sul server) senza dover riavviare l’application server. Dunque, dapprima
vengono sviluppati i plugin e poi vengono usati tali task per costituire dei file WAR che
vengono direttamente copiati in un’apposita cartella di Auto Deploy. In seguito, il portale,
assieme all’application server, individua ogni archivio WAR presente nella directory di hot-deploy ed
estrae automaticamente i file al loro interno nella cartella di deployment del server.
Il funzionamento dell’ambiente Plugins SDK è riportato nella seguente figura.
Le portlet vanno a finire nella cartella /portlets, i temi in /themes, i template di layout
nella cartella /layouttpl, le applicazioni web in /webs e gli hooks nella directory /hooks.
34
3.7.2
Ambiente
Extension
L’ambiente Extension (Ext) permette di personalizzare completamente Liferay Portal.
Infatti, estende l’ambiente di sviluppo del portale, avendo la possibilità di agire sui file di
configurazione del portale e sul codice Java e JSP relativo a Portal-Impl. È quindi un wrapper
per i sorgenti del core di Liferay (per questo motivo la struttura delle cartelle in Ext rispecchia la
gerarchia delle directory dei sorgenti, cioè ext-impl/, ext-service/ e ext-web/). Si possono
configurare layout, temi, deployment, Hibernate, cache, impostazioni varie su utenti, gruppi,
lingua, sessione, autenticazione, eventi e così via, attraverso file di properties con desinenza ‘‘ext’’.
In particolare, le opzioni generali qui citate vengono settate tramite il file portal-ext.properties.
Il file system-ext.properties, invece, è modo conveniente per fornire ed estendere le Java
System Properties usate dal portale.
In Ext si possono creare anche delle classi personalizzate per estendere il portale,
configurandole tramite il file portal.properties.
In tutti questi casi, comunque, il codice sorgente di Liferay non viene modificato in
alcun modo, in quanto tutte le personalizzazioni sono organizzate in un progetto separato con
l’obiettivo di agevolare l’upgrade a nuove versioni di Liferay in cui inserire le personalizzazioni
realizzate per le precedenti versioni.
Come illustrato nella seguente figura, il funzionamento dell’ambiente di estensione
può essere riassunto in pochi punti:
il custom code sovrascrive (‘‘override’’) il codice sorgente del portale nell’ambiente Ext;
prima del processo di deploy il custom code viene fuso (‘‘merge’’) con il codice sorgente
del portale sempre nell’ambiente Ext; il risultato è una versione custom del portale Liferay
(‘‘Customized Liferay Portal’’) costruita in ambiente Ext;
il portale Liferay così personalizzato viene quindi ‘‘deployato’’ da Ext sull’application
server.
35
Figura 3.5: Funzionamento dell’ambiente Extension.
36
CAPITOLO
4
S.F.I.N.G.E.
In generale, il Mercato della formazione scaturisce dalla risposta imprenditoriale alla
crescente domanda (proveniente da Aziende o comunque Organizzazioni) di allineamento
delle competenze delle risorse umane alla revisione dei processi di produzione che ha spinto
allo studio del prototipo infrastrutturale realizzato con cui sono state definite le specifiche della
piattaforma software per l’e-learning e delle funzionalità applicati e del sistema.
L'applicazione prototipale è stata progettata e descritta a livello concettuale e logico,
mettendo in evidenza livelli di design tra loro ortogonali: design della struttura informativa,
design dell’interfaccia, design della struttura di aggregazione e presentazione delle informazioni,
design delle operazioni che possono essere compiute sui dati.
Qualità e Rapidità di risposta rimangono i temi su cui lavorare per essere Competitivi.
La Flessibilità nei Processi di Produzione sostiene il requisito di competitività. Un Sistema
Produttivo Distribuito è uno scenario flessibile.
In questo quadro generale il progetto ha come fine ultimo quello di creare un portale
capace di interfacciarsi con i dipendenti di un’ azienda rendendo loro un servizio di formazione
capace di fornire mobilità e qualità dei corsi che i dipendenti sono tenuti a sostenere per la
formazione continua.
Il prodotto del progetto SFINGE è rappresentato dai seguenti elementi:
" piattaforma SOFTWARE per la progettazione, realizzazione, produzione ed
erogazione di corsi e-learning;
" linee guida per la conversione di attività di formazione tradizionale in attività di
formazione a distanza;
" middleware per griglie computazionali in grado di supportare l'interoperabilità
fra i partner;
" hardware per l'implementazione del prototipo.
L'obiettivo finale ha come oggetto una proposta di innovazione riguardante l'azienda
proponente in termini di trasferimento tecnologico da processo\prodotto di formazione
tradizionale a processo\prodotto di formazione in modalità e-learning.
37
Per far ciò si sono individuate varie piattaforme e tra queste ci si è soffermati su quali
offrissero una facile gestione dei contenuti e che fossero di semplice utilizzo da parte
dell’utente e che potessero essere interfacciabili con una griglia computazionale.
Nella prima fase dello studio si è cercato di capire quale fosse la soluzione migliore per
creare diversi profili utenti che accederebbero alla piattaforma ad ognuno dei quali associare
dei permessi specifici nell’utilizzo della stessa.
Le piattaforme analizzate sono state Moodle, WordPress, Elgg e Liferay, che è stata
scelta rispetto alle altre in quanto offre un buon livello di libertà e personalizzazione all’interno
del portale, inoltre ha un elevato grado di interfacciabilità con i sistemi di grid computing.
Si è scelta la formattazione del portale tramite delle portlet che nella schermata iniziale
sono presenti in un numero pari a 3, inoltre S.F.I.N.G.E., come si è accennato in precedenza,
adotta la tecnologia della grid information poiché fondamentale per l’ inserimento sul portale
di nozioni da parte di chiunque aumentando così qualità e quantità del servizio, in quanto si
verifica un aumento della capacità di storage e computing.
38
" ID = Instructional Designer
" SME= Subject Matter Expert (o Esperto di contenuti)
" EP = Esperto di Piattaforme (Sviluppatore e Amministratore della
piattaforma/Responsabile LMS)
" EV = Esperto di Valutazione
In questa fase il PM definisce e perfeziona gli obiettivi generali, dettagliandoli e pianificando lo
svolgimento delle azioni necessarie per il raggiungimento degli obiettivi stabiliti, descrivendo in
dettaglio “quello che deve essere fatto”, i deliverables (azioni sottoposte e approvate dal team
di project management) e il lavoro necessario per la realizzazione:
• viene generata la WBS (Work Breakdown Structure), cioè la segmentazione gerarchica
strutturata del lavoro da svolgere in singole azioni (pacchetti di lavoro, “Work
Package”) per migliorare la gestione e il controllo del progetto
• viene costruita la schedulazione dei tempi, a partire dalle attività previste, dalle stime di
durata, dai mezzi disponibili, dal budget
Il Project Management Plan è il documento che descrive in che modo il processo è eseguito,
monitorato e controllato.
Esso deve anche contenere:
• il Quality Plan (Piano di Gestione della Qualità) che identifica gli standard di qualità per
il progetto e le modalità di attuazione delle politiche di gestione della Qualità
• il Registro dei Rischi, che contiene l’elenco dei rischi identificati, delle potenziali
risposte, le principali cause di rischio
• il Piano di Comunicazione, che definisce le esigenze informative e di comunicazione
degli stakeholders.
Una volta loggati come admin all’ interno del portale non ci sono limiti di operazioni nello
stesso, potendo sceglie la sezione relativa all’ amministrazione web con cui si può operare e
gestire i template, i content dove si procede con l’ analisi (project character), planning (più
detagliato del project plan), implementazione (creazione del corso tutti i learning object),
erogazione (piattaforma collegata con moodle o altre piattaforme).
Nello specifico una volta dentro loggati come admin si possono avere, come detto in
precedenza, tutti i permessi che nel nostro caso cominciano con l’ aggiunta di uno o più
39
progetti. Lo stesso può dirsi per il PM che a differenza dell’ admin nel portale può gestire
solo un progetto ovviamente previa autorizzazione.
40
Figura 4.4: set up PAGE nuovo progetto
Queste sono strutture per settare gli elementi, i template usati sono dei linguaggi xml che
servono a creare i template che effettivamente il documento/progetto segue e che
vengono fatti secondo le disposizioni date dall’ azienda che ha collaborato al progetto. Per
seguire un corretto flusso di lavoro si fa ricorso al workflow Kaleo 6.2 e vi si accede
tramite la sequenza:
my account > my workflow Tasks > action
41
strutturato liferay per poter assegnare un workflow ad un’ organizzazione, nel nostro caso a
Genesis, il documento deve essere creato sul portale dell’ organizzazione a quel punto il
workflow potrà essere assegnato solo agli utenti iscritti a quella data organizzazione ed è
importante perché così possiamo tenere varie organizzazioni e vari gruppi separati, senza
che tutti vedano le notifiche di tutti.
Nello specifico si è optato per Kaleo 6.2 che ha le seguenti caratteristiche:
La creazione di nuove definizioni del flusso di lavoro
Un flusso di lavoro Kaleo, chiamato una definizione di processo, è definita in un file XML
e viene eseguito dagli utenti del portale. È possibile creare tante definizioni del flusso di
lavoro diversi, se necessario per gestire il lavoro fatto sul vostro portale. I flussi di lavoro
possono definire nuovi ruoli utente per gestire il processo di approvazione o utilizzare ruoli
che già esistono nel portale. Il file XML ha diverse parti che definiscono il flusso di lavoro.
Per avere un'idea di come funziona, esamineremo il singolo file-validatore-definition.xml
predefinita che è incluso nel plugin Liferay Kaleo.
Le parti principali della definizione del flusso di lavoro sono il bene o l'azione di workflow-
enabled che sta correndo attraverso il flusso di lavoro, i nodi del flusso di lavoro, e le
transizioni tra i nodi. Le attività sono ogni tipo di attività registrato in Liferay: contenuti
web, articoli wiki, discussioni message board, blog le voci, e anche i commenti, sono
workflow-enabled. Azioni workflow-enabled nel portale includono Pagina Revisione e
aggiunta utente o la modifica. Gli sviluppatori possono inoltre creare i propri beni da
utilizzare con i flussi di lavoro (vedi Liferay in azione o Guida Liferay Developer per
ulteriori informazioni). I nodi rappresentano le fasi del flusso di lavoro e ci sono diversi tipi.
Transizioni si verificano tra i nodi e dovrebbe indicare il nodo successivo. Pensate al flusso
di lavoro come una macchina a stati costituita da nodi. Un nodo può essere uno stato, un
compito, una condizione, una forchetta, un join o un timer. Transizioni sono utilizzati per
passare da un nodo all'altro. Ogni tipo di nodo ha proprietà diverse. Ad esempio, afferma
di eseguire azioni in modo automatico e non richiedono l'input dell'utente. Compiti blocco
finché l'ingresso utente completa una transizione a un altro stato. Il passaggio poi sposta il
flusso di lavoro per il prossimo compito o lo stato. Questo ciclo continua fino al
42
raggiungimento dello stato finale approvato. Ad esempio, è possibile creare un flusso di
lavoro che passa attraverso due approvazioni. Avvio il flusso di lavoro mette in stato In
Review e poi passa a un compito che richiede l'input dell'utente. Gli utenti approvano o
respingono l'attività come parte del compito. Quando il primo utente approva l'attività del
flusso di lavoro, una condizione verifica se ci sono due approvazioni. Poiché vi è un solo,
la transizione workflow torna al compito. Quando il secondo utente approva il bene, la
condizione trova ci sono due approvazioni e innesca una transizione diversa allo stato
Approvato. Impariamo su componenti del flusso di lavoro del validatore unico e guardare
in dettaglio come si sarebbe creato un flusso di lavoro utilizzando un unico responsabile
dell'approvazione.
Figura 11.1: Il flusso di lavoro responsabile dell'approvazione singolo difetto. Frecce rappresentano
transizioni e scatole rappresentano gli stati e le attività.
In primo luogo è necessario definire lo schema. Per Liferay flussi di lavoro utilizzando
Kaleo, Liferay-worklow-definizione-6_2_0.xsd dovrebbe essere lo schema. Ecco come si
definisce nel file XML di vostra definizione del flusso di lavoro:
43
Quindi, si definisce un nome e una descrizione per il flusso di lavoro. Questa viene
visualizzata nel pannello di controllo quando gli utenti scelgono e configurare i flussi di
lavoro.
In questo caso, lo stato è semplicemente che l'attività è stata creata. Uniti possono
contenere azioni e transizioni. Le azioni possono contenere script. È possibile specificare la
lingua dello script con il <script language> tag. Gli script possono essere scritti in Groovy,
JavaScript, Ruby o Python. Per uno Stato, l'azione viene attivata automaticamente e quindi
esegue una transizione. Transitions si trasferiscono in un nuovo stato o attività.
Dallo stato iniziale, la transizione a una nuova attività, in cui l'ulteriore elaborazione è
bloccato in modo che il bene può essere riesaminato.
44
Il passo successivo è quello di creare un'attività.
Creazione di attività
Il compito ha più parti ed è la parte più complessa della definizione. Le attività sono legate
a ruoli per scegliere chi deve completare il compito. I ruoli vengono informati che ci sono
nuovi contenuti in bisogno di revisione. Se si definisce un ruolo che non esiste, viene
creato automaticamente. Il primo compito di cui la definizione del flusso di lavoro single-
validatore-definition.xml è il UPDATEtask. Anche se appare per prima nel file, in realtà
non è la prima attività nel flusso di lavoro. L'attività di aggiornamento è il compito che è
assegnato dal flusso di lavoro, se l'attività è respinta da un responsabile. E 'nominata per
prima perché è il compito di default: quando questa attività viene attivato, il processo di
workflow viene azzerato di nuovo all'inizio. In questo compito, l'attività è assegnato di
nuovo al creatore di contenuti, che riceve una notifica via email ed è necessario per
ripresentare l'attività. Una volta che il compito è ripresentato, risale alla fase di revisione. È
anche possibile vedere il compito è assegnato a <utente />. Questo tag assegna sempre il
compito indietro per l'utente che ha creato il bene.
45
Il compito recensione rappresenta il primo compito nel flusso di lavoro. Questo è dove gli
utenti del portale con il ruolo proprio rivedono il contenuto e decidono di rifiutarlo
(spostarlo indietro all'inizio) o accettarlo (passaggio alla fase successiva). Una volta che la
transizione è stata fatta a questo compito, viene inviata una notifica a coloro che sono
assegnati al compito. È possibile modificare il nome o il contenuto della notifica nel file
XML. Una volta che il recensore ha completato la loro revisione ed esce il compito di
workflow, un'altra e-mail viene inviata al mittente originario indicando che la revisione è
stata completata.
È inoltre necessario assegnare il compito di un ruolo o ruoli specifici. Questo ruolo non
deve essere il ruolo che la notifica. Ad esempio, si potrebbe desiderare di notificare tutti i
46
creatori di contenuti ogni volta che un nuovo elemento è presentato. Indipendentemente
da chi si sta notificando, e sicuramente desidera inviare una notifica a chi è competente per
l'approvazione dei contenuti.
Per poter parlare del Control Panel bisogna dare una definizione di quello che è per noi la
Virtual Organization in quanto tramite questo comando si gestiscono Users, Siti, Apps e
configurazioni del workflow.
V.O.: unione di uomini, macchine, know how gestite dal portale usati per migliorare il processo di
produzione di corsi di e-learning
A tal proposito è molto importante la Sfinge grid information perché saranno visibili le
info della griglia computazionale.
Selezionando dal Control Panel gli Users si possono gestire utenti e organizzazioni e
spostando il cursore su Actions si possono dare vari tipi di permessi ai vari attori presenti
nell’ elenco, inoltre selezionando Organization si può notare che c’è Genesis.org , che
rappresenta l’ azienda che collabora e che si occupa di produzione di e-learning.
47
Figura 4.7: vari roles (ruoli) presenti nel portale
L’ attenzione è rivolta tutta su Project Manager che nel nostro caso è la figura più
importante in quanto gestisce tutto nel nostro portale perché ha i seguenti ruoli:
" da compiti e altri ruoli agli utenti;
" edita quello che c’è in griglia (griglia dei ruoli);
" definisce i permessi che fanno interagire con il portale;
" assegna i membri;
" vede utenti che appartengono a una categoria;
" può cancellare tutto.
48
CONCLUSIONE
49
BIBLIOGRAFIA
E
SITOGRAFIA
DI
RIFERIMENTO
Banzato M., Apprendere in rete. Modelli e strumenti per l’e-learning, Utet, 2006
Eletti V. (a cura di), Che cos’è l’e-learning, Carocci, 2002
Ganino G., Immagini per la didattica. Metodologie e Tecnologie dell’audiovisivo
digitale, Anicia, 2009
Liscia R. (a cura di), E-learning. Stato dell’arte e prospettive di sviluppo, Apogeo, 2004
Alsultanny, Y. (2006), “e-Learning system overview based on semantic web”, The
Electronic Journal of e-Learning, vol.4, no.2, pp.111-118.
Ambjörn, N., Mikael, N., Matthias, P. & Fredrik, P. (2005), “Contributions to a public
e-learning platform: infrastructure; architecture; frameworks; tools”, International Journal of
Learning Technology, vol. 1, no.3, pp.352-381.
Dolog, P., Henze, N., Nejdl, W. & Sintek, M. (2004), “Personalisation in distributed
eLearning environments”, Proceedings of WWW2004 - The Thirteenth International World Wide Web
Conference, New York, USA.
Ehlers, U. (2004), “Quality in e-learning from a learner's perspective”, European Journal
of Open Distance and E-Learning. May. Retrieved on 2 May 2007 from
http://www.eurodl.org/materials/contrib/2004/Online_Master_COPs.html
Gotschall, M. (2000), “E-learning strategies for executive education and corporate
training”, Fortune, vol. 141, no.10, pp.S5-S59.
Hall, B. (2000), “How to embark on your e-Learning adventure: Making sense of the
environment”, e-Learning, January-March.
Kanendran, T.A., Johnny, S. & Durga, B.V. (2004), “Technical report: Issues and
strategies of e-Learning”, Sunway College Journal, vol.1, pp.99-107.
Moreale, E. & Vargas, M. (2004), “Semantic services in e-Learning: an argumentation
case study”, Educational Technology & Society, vol.7, no.4, pp.112-128.
Noy, N. & Klein, M. (2004), “Ontology Evolution: Not the same as schema evolution”,
Knowledge and Information Systems, vol.6, no.4, pp.428-440.
50
Shreiber, D.A. & Berge, Z.L. (1998), “Distance training: How innovative organisations
are using technology to maximise learning and business objectives”, Jossey-Bass, San Francisco,
CA.
Stojanovic, L. (2004), “Methods and tools for ontology evolution”, PhD thesis,
Universitat Karlsruhe.
Tony, G., Anne, J.G., & Mary, S.W. (2005), “Introduction to metadata: Pathways to
digital information”, Online Edition, Version 2.1, Retrieved 9 September 2007 from
http://www.getty.edu/research/institute/standards/intrometadata/
Unwin, D. (2003), “Information support for e-Learning: principles and practice”, UK
eUniversities Worldwide Summer.
Urdan, T.A. & Weggen, C.C. (2000), “Corporate e-Learning: Exploring a new frontier”,
WR Hambrecht + Co. Retrieved 3 August 2001 from
http://www.wrhambrecht.com/research/coverage/elearning/ir/ir_explore.html
Zahm, S. (2000), “No question about it - e-Learning is here to stay: A quick history of
the e-Learning evolution”, e-Learning, vol.1, no.1, pp.44-47.
http://www.liferay.com/it/documentation/liferay-portal/6.2/user-guide/-
/ai/creating-new-workflow-definitions-liferay-portal-6-2-user-guide-11-en
" Definizione di linee guida per l'utilizzo e la gestione del sistema distribuito
collaborativo del Progetto S.F.I.N.G.E."
51