UML e la progettazione di e-learning Perché UML? UML (Unified Modeling Language, letteralmente: Linguaggio Unificato di Modellazione) viene spesso confuso come una metodologia per analizzare e progettare sistemi informatici. In realtà non è una vera e propria metodologia, bensì una raccolta di notazioni grafiche (traducibili anche testualmente, diventando una specie di "linguaggio formale") con le quali è possibile descrivere e "modellizzare" qualunque tipo di sistema informativo, non necessariamente quindi informatico. La mamma che sveglia i figli per andare a scuola e nel frattempo prepara la colazione e indica al marito dove sono conservati i calzini, è un sistema informativo, la cui struttura statica e dinamica può essere rappresentata da uno o più modelli descrivibile usando le notazioni UML. Quando si vuole costruire un sistema informativo, è necessario passare per tre fasi: analisi, progettazione, realizzazione (detta anche: implementazione). Ciascuna di queste fasi viene condotta secondo un metodo (la metodologia, appunto, che dipende dalla natura del sistema informativo) con lo scopo di documentare i risultati e i comportamenti attesi dal sistema e alimentare le fasi successive. UML viene usato come formalismo grafico con cui rappresentare questi documenti e modelli.uml, dunque, può essere usato con qualunque metodologia. Insomma, piuttosto che lasciare alla libera improvvisazione e iniziativa la scelta del modo con cui rappresentare le decisioni di analisi, di progetto e implementazione, UML propone uno standard unico e facilmente comprensibile sia dagli addetti ai lavori, sia agli eventuali committenti del sistema. In questo corso siete chiamati a documentare un progetto di e-learning o di contenuto per l'e-learning. Si tratta di un sistema informativo, abbastanza complesso e ricco di elementi, vincoli, connessioni, oggetti, attori, scenari, comportamenti, contenuti, etc. 1
Fino ad ora avete documentato il vostro progetto in modo libero: chi narrando il funzionamento del sistema in un documento word, chi provando ad esemplificarlo tramite videate su powerpoint, chi tramite mappe concettuali, chi attraverso schemi e fogli excel, e così via. Non sarebbe male, invece, che usassimo una notazione condivisa e standard: UML, appunto. Le cose da dire e da descrivere sono sempre quelle, beninteso, solo che le diciamo e descriviamo con una notazione comune, più rigorosa e possibilmente più oggettiva di quelle che venivano lasciate alla libera iniziativa. Costringersi a descrivere il modello del sistema attraverso una notazione formale e oggettiva, produce come effetto collaterale un obbligo ad avere le idee chiare senza lasciare nulla al vago o all'ambiguo. In pratica UML sta alla progettazione così come le mappe concettuali alla metacognizione. Grazie alla mappa concettuale possiamo renderci conto se una cosa l'abbiamo davvero capita. Se infatti non sono in grado di mettere in relazione due concetti o se nella mappa mi accorgo di aver trascurato un concetto che invece è cruciale per rappresentare la realtà in analisi, ovvero se faccio vedere la mappa concettuale ad un'altra persona e mi faccio dire da lui cosa ne capisce e viene fuori tutt'altra realtà di quella che io avevo analizzato, allora vuol dire che la mappa è sbagliata o io non ho capito la realtà. La stessa funzione di documentazione/validazione ha UML nei confronti del progetto di un sistema informativo. Se ad esempio modellizzo in UML un sistema per la distribuzione automatica di caffè, e un'altra persona guarda il modello e dice: "ah, bello, un juke box!", allora vuol dire che c'è qualcosa che non va. Solo una notazione formale e univoca è capace di mettere in risalto le cose che non vanno, oltre, ovviamente, a quelle che vanno, illustrandole e spiegandone il funzionamento dinamico e statico. 2
Insomma, studiamolo un poco, questo UML, ci potrà essere utile. Siete curiosi di come si possa descrivere in UML la quotidianità di un mattino in famiglia, che possiamo pensare come il sistema: "famiglia la mattina"? Ecco alcuni diagrammi di esempio, ciascuno realizzato con tre notazioni UML diverse. Diagramma di Caso d'uso Nel diagramma dei casi d'uso vengono mostrate le azioni principali svolte dal sistema e gli attori che le svolgono e/o su cui queste agiscono. 3
Diagramma delle classi Il diagramma delle classi rappresenta la struttura statica del sistema, le parti che lo compongono e le relazioni tra esse (è simile ad una mappa concettuale). Notate che questo non è l'unico modo con cui si poteva modellizzare la struttura di una famiglia, ma ho scelto questo perché credo che meglio di altri rende il punto di vista del sistema oggetto di studio. 4
Diagramma di Sequenza Il diagramma di sequenza descrive i comportamenti dinamici del sistema, gli attori che li svolgono e le eventuali contemporaneità di azioni e attivazione delle stesse. Vediamo di seguito alcuni esempi di utilizzo del formalismo UML per modellizzare invece oggetti e sistemi tipici dell'e-learning. Per ogni esempio, si dimostra un tipo di diagramma UML e la corrispondente descrizione discorsiva. 5
Esempio: Diagramma caso d'uso di un sistema di e-learning generico Descrizione discorsiva Lo "Studente" accede al corso, previa autenticazione. Nel corso esegue le attività pianificate e rese disponibili in base ai "triggers" attivati sia dall'esito delle azioni dell'utente (esecuzione di quiz, completamento attività, eccetera), sia in base ad eventi predefiniti del corso (inizio, trascorso una settimana, giunti ad una particolare data, fine, eccetera). L'esecuzione delle attività alimentano un report statistico che agevola l'azione di monitoraggio e controllo da parte del tutor, il quale a sua volta è in grado di fornire feedback e supporto agli studenti. 6
Notazione sintattica: Gli ovali rappresentano le procedure/azioni svolte dall'attore. Alcune procedure possono necessariamente prevedere l'esecuzione di altre procedure. Questa relazione è etichettata dalla parola "include". Nell'esempio, la procedura: "Accede al corso", prevede necessariamente (include) la procedura: "Autenticazione" (gli utenti non possono accedere al corso se non sono autenticati). Altre procedure possono opzionalmente prevedere l'esecuzione di un'altra procedura. In questo caso si dice che l'altra procedura (quella opzionale) "estende" (extend) la procedura principale. Nell'esempio, la procedura "esegue attività", può opzionalmente eseguire la procedura "attiva triggers" (un utente che esegue un quiz, può attivare il trigger "quiz completato"). 7
Esempio: Diagramma di classi di un sistema di e-learning generico Descrizione discorsiva Il "corso", progettato in base a determinati "obiettivi formativi", è formato da una serie di "argomenti", ciascuno a sua volta costituito da una serie di "attività" e "risorse". Le "attività" possono essere: moduli "SCORM", "Quiz" di verifica, "forum", "chat" e "videoconferenza". Le attività sono rese disponibili in base alle "condizioni" definite dal "corso", tenendo cioè conto sia di eventi generali (date, inizio, fine, eccetera), sia delle "proprietà" associate a ciascun "utente" i cui valori sono attribuiti dal "ruolo" che questi hanno nelle "attività" del corso (completamento di un modulo SCORM, valore ottenuto in un quiz, eccetera). Il "ruolo" definibile nel corso per ogni utente è "studente", "tutor" o altri eventualmente modulati secondo esigenze specifiche. Ad esempio, è possibile definire ruolo: "esperto", "docente", "visitatore", eccetera, componendo per ciascun ruolo una griglia di permessi e privilegi sulle attività e risorse del corso. Le "risorse" sono rappresentate da materiali di 8
studio, riferimento e supporto all'apprendimento degli argomenti del corso, e possono essere in forma di semplici pagine web, organizzati in ebook (visualizzabili direttamente dal visore di ebook integrato alla piattaforma) o file scaricabili (.pdf,.ppt, eccetera). Notazione sintattica: Il simbolo "rombo pieno" denota una relazione di composizione tra la classe su cui il rombo poggia e la classe collegata. Nell'esempio, classe "corso" è composta da più classi "argomenti", per indicare che il corso è costituito da più argomenti. Il numero vicino agli estremi del legame indica la cardinalità della relazione. Nell'esempio di prima, 1 0.. significa che ad un corso possono corrispondere da 0 a n argomenti. Il simbolo "triangolo", indica una relazione di generalizzazione tra due classi. Nell'esempio, la classe "attività" è una generalizzazione delle classi: "SCORM", "Quiz", eccetera. Ovvero "SCORM", "Quiz", eccetera sono delle classi di tipo "attività". Questo significa che tutte le proprietà attribuite alla classe "attività" vengono automaticamente ereditate dalle sue sottoclassi. Le sottoclassi possono poi avere delle specifiche proprietà. 9
Esempio: Diagramma di stati di un learning object che combina pagine di contenuto con pagine di valutazione (quiz) 10
Descrizione discorsiva Il learning object presenta la videata corrispondente allo stato "Home". In base al link cliccato dall'utente sulla videata, viene presentata la videata rispettivamente corrispondente allo stato "Pagina1" o allo stato "Pagina2". Lo stato "Pagina1" presenta un contenuto da cui è possibile passare alla videata corrispondente allo stato "Pagina3" a seguito del clic su un rispettivo link. Lo stato "Pagina2" presenta un quiz di valutazione. In base all'esito (giusto, sbagliato) viene presentata la videata corrispondente rispettivamente allo stato "Pagina2a" e "Pagina2b". Da questi stati, è possibile passare allo stato "Pagina3" a seguito del clic sul rispettivo link. Dallo stato "Pagina3" si passa allo stato finale cliccando sul link di uscita. Il diagramma di stati è particolarmente indicato per modellizzare comportamenti e aspetti dinamici di un learning object, di cui poi si descriveranno in un documento a parte i contenuti di dettaglio e di progetto dell'interfaccia delle singole videate (storyboard). Notazioni sintattiche: Il cerchio pieno indica lo stato iniziale del sistema. Ogni riquadro rappresenta lo stato in cui il sistema si trova in quel particolare momento. La freccia indica la transizione da uno stato all'altro. L'etichetta sulla freccia indica l'evento o la condizione che fa scattare la transizione, cioè il passaggio da quello stato all'altro. Il cerchio pieno con un bordo attorno, indica lo stato finale del sistema. Per la progettazione di un learning object, il diagramma di stati può servire per rappresentare le videate che compongono il LO e gli eventi che provocano il passaggio da una videata all'altra. 11