mronca.it

Uno dei maggiori problemi nella creazione di un sito web, e probabilmente quello di cui si è parlato e scritto di meno, è come decidere, specificare e comunicare con esattezza che cosa andremo a creare e il perché. Che problemi stiamo cercando di risolvere? Chi ne avrà bisogno? A che cosa servirà il sito web?

Una comprensione deficitaria dei bisogni degli utenti finali o delle aspettative del nostro cliente porta all’uso inefficace delle risorse limitate, all’enfasi male indirizzata verso priorità di design sbagliate, o esageratamente rivolta a tecnologie superflue (ossia quelle che contribuiscono alla creazione di un sito sbagliato, fuori tempo, inappropriato o troppo caro).

L’esperienza ci può insegnare ad evitare scivoloni, ma un’ottima lezione può essere appresa anche dai meno esperti: prima gli scopi e gli obbiettivi vengono definiti e registrati, più facilmente i problemi possono essere identificati e risolti, più facilmente si riesce a mantenere l’attenzione e migliore saranno il risultati per tutti.

Sorprendentemente, gli sviluppatori sembrano riluttanti ad adottare metodi e approcci interdisciplinari che possano semplificare i loro problemi. In particolare, durante la cruciale fase iniziale dei progetti, si potrebbe trarre beneficio dall’emulazione di certe pratiche proprie della programmazione.

Introduzione ai casi d’uso

Una tecnica particolarmente utile che deve essere considerata è quella dei casi d’uso. Essi forniscono un metodo semplice e veloce per decidere e definire lo scopo di un progetto. Vengono efficacemente impiegati da molti programmatori come mezzo per individuare gli obbiettivi di alto livello di un applicativo durante la fase di sviluppo. Non c’è ragione per cui uno sviluppatore di siti non debba trarre simili benefici dal loro impiego. Anche un progetto che sembra ben definito fin dall’inizio può diventare molto problematico se gli scopi non vengono costantemente tenuti presenti.

Allora, cosa si intende per caso d’uso?

Per definirlo dobbiamo considerare 2 concetti e le loro relazioni:

• gli attori
• gli scopi

Gli attori sono tutti coloro - e tutto ciò -che utilizzeranno (o che verranno utilizzati) dal nuovo sito. Gli scopi sono ciò che uno, o alcuni, o tutti gli attori vogliono perseguire. Per completezza ogni caso d’uso deve descrivere uno scopo specifico e gli attori che compieranno certe azioni per raggiungere quello scopo.

Gli attori sono esterni al nostro sito – non possiamo crearli o controllarli direttamente – ma essi compiono determinate azioni per raggiungere i loro scopi. L’attore più ovvio di un sito web è il visitatore. Il suo scopo potrebbe essere quello di comprare uno dei nostri beni o di controllare un conto bancario, prenotare un appuntamento, scaricare un programma, o semplicemente recepire dei contenuti di loro interesse. Gli attori non sono necessariamente umani; ad esempio si possono sviluppare sistemi di syndacation che trasferiscono informazioni a siti web abbonati. In quest’ultimo caso i server remoto dei clienti sono gli attori.

Qualunque sia il nostro intento, i casi d’uso ci permetteranno di descrivere gli scopi perseguiti dagli attori nelle loro azioni.

Come si applicano i casi d’uso

Un blog permette ai suoi proprietari di comunicare pensieri su determinati argomenti e ad altri di leggerli e qualche volta di rispondere. Gli attori di un blog sono gli autori e I visitatori del sito. L’autore ha il ruolo di generare i contenuti mentre il visitatore ha quello di leggere ed eventualmente rispondere. Gli scopi sono di informare ed essere informati.

Dopo un breve brainstorming, potremmo decidere che tra le azioni di alcuni di questi attori debbano essere incluse la lettura di un articolo, la creazione, la modifica, e la cancellazione dei contenuti del blog, l’introduzione di commenti, la gestione della syndacation e altre azioni da amministratori, come ad esempio controllare gli accessi, i permessi e gli account. Alcune di queste azioni sono comuni a tutti gli attori, altre sono attribuite a un solo singolo attore. Tutte possono essere incluse in un caso d’uso che descrive la nostra idea iniziale: “Pubblicare un blog”.

Il seguente diagramma del caso d’uso descrive la relazione tra gli attori e gli scopi:

I diagrammi dei casi d’uso rendono più semplice l’ideazione delle relazioni, o dipendenze, tra i casi d’uso e gli attori. I visitatori e gli autori potrebbero avere la necessità di cercare determinati contenuti pubblicati nel blog:

Entrambi i visitatori e gli autori vogliono poter effettuare la ricerca. In aggiunta, potrebbe non esser concesso ricercare contenuti tra il materiale non ancora pubblicato. Di conseguenza il caso d’uso “Ricerca dei contenuti” dipende da “Pubblicare un blog”.

Abbiamo deciso di utilizzare Google per la nostra funzione di ricerca. Google diventa un attore e il caso d’uso “Ricerca dei contenuti” si basa su Google. L’azione di Google come attore è di restituire i risultati della ricerca.

Finora abbiamo analizzato alcuni degli attori coinvolti nel nostro blog, i loro scopi e alcune delle dipendenze. Possiamo considerare questa come una architettura concettuale ad alto livello del nostro sito, che ci tornerà utile quando prenderemo delle decisioni di design più tardi.

Tutto va bene

Il beneficio fondamentale apportato dai casi d’uso è il modo in cui incoraggiano un metodo diretto nell’individuazione dei requisiti di progetto. Fin dall’inizio noi progettiamo un prodotto concentrandoci sui bisogni e le esigenze di coloro che lo useranno.

Quando migliore è la nostra comprensione dei casi d’uso, più facile, più efficace e più appropriato sarà il lavoro conseguente. I casi d’uso sono in contesto che ci permette con facilità di immaginarci, all’interno della vita di un progetto, quando un particolare elemento combacerà, di conseguenza faciliterà l’attività decisionale tra il design e lo sviluppo.

Lo scopo di descrivere i casi d’uso naturalmente non è quello di specificare in maniera completa l’esatta natura di ciò che il sito conterrà e di come verrà costruito. Diversamente, i casi d’uso definiscono gli scopi e gli obbiettivi: i problemi che intendiamo risolvere. Stabilire questi obbiettivi definisce lo scopo che perseguiamo. In aggiunta:

• Se consideriamo semplicemente i ruoli ricoperti dagli attori e i loro scopi, il modello del caso d’uso è definito velocemente
• Un diagramma di caso d’uso può ridurre un progetto complesso in una figura più facilmente comprensibile
• Un caso d’uso ben congeniato può essere facilmente compreso da tutti gli operatori di un progetto: gli sviluppatori, i menager e i clienti. E’ un aiuto efficace allo sviluppo collaborativo.
• I casi d’uso assicurano che lo scopo sia costantemente sotto controllo. L’identificazione dei casi d’uso e le loro dipendenze facilita la distinzione tra gli scopi fondamentali che devono essere perseguiti e quelli secondari che dipendono da essi. Individuare gli scopi secondo questa logica permette di progettare e dare le priorità in maniera più efficiente.
• E’ l’immagine di un’implementazione neutrale di un progetto. Niente viene detto riguardo agli strumenti tecnologici.
• E’ trasportabile. Nessuno strumento particolare è richiesto per la sua fruizione – post-it, lavagna, matite e carta o il vostro programma di grafica preferito possono essere ugualmente utilizzati per documentare la vostra idea.

Lo sviluppo per casi d’uso è una mentalità piuttosto che una semplice tecnica. Mettendo in evidenza gli attori e i loro scopi, i gruppi di lavoro possono lavorare con maggiore confidenza e chiarezza. Una valida conoscenza fin da subito su tutto ciò che verrà coinvolto permette una più facile attività decisionale in seguito, e spinge ad un’attenzione continua verso quelli che sono i veri fini di un progetto.

Molto è stato scritto riguardo ai casi d’uso, Alistair Cockburn probabilmente è il migliore .

Per vedere più casi d’uso in azione visitate guibot.com, che presenta casi d’uso alternativi di molte pagine.

Norm Carr è uno sviluppatore di software e un analista/sviluppatore di interfacce utente alla Nuvotec Inc.. E’ stato co-inventore dell’ eXtended Activity Semantics (XAS), un’implementazione neutrale del modello di interazione utente utilizzato dal programma Guibot per la raccolta rapida dei requisiti.