Leggendo il documento dei requisiti individuiamo le seguenti classi candidate:

Cittadino, Evento culturale, Comunale, Provinciale, Regionale, Utente,Servizio, Portale web, Criterio di ricerca, Informazione, Zona, Comune, Provincia,Regione, Tipologia di evento, Data, Periodo, Newsletter, e-mail,Preferenza, Iscrizione, Cadenza, Giornaliera, Settimanale, Mensile ,Amministratore, Ente culturale, Società, Abilitazione, Registrazione, Form, Richiesta, Parametro di connessione,Indirizzo ,Account, Login, Password, Esito, Motivo di rifiuto

Prima di iniziare la selezione delle classi cerchiamo di individuare alcune regole che ci permettono di catalogare le entità in gioco e ci permettono di operare la selezione:
 

1. Classi ridondanti: Se due classi esprimono la stessa informazione dovrebbe essere scelto il sostantivo più descrittivo ES: Sebbene il cliente potrebbe descrivere una persona che prende un volo aereo, passeggero è più descrittivo.
2. Classi irrilevanti: Se una classe ha poco o niente a che fare con il problema dovrebbe essere eliminata.
3. Attributi: I nomi che descrivono oggetti essenzialmente singoli dovrebbero essere modellati come attributi. Per esempio nome, età, peso, indirizzo di solito sono attributi. Se però l’esistenza indipendente di una proprietà è importante, allora se ne farà una classe e non un attributo.
4. Operazioni:Se un nome descrive un’operazione applicata a degli oggetti e non viene esso stesso manipolato, allora non è una classe. Es:Una chiamata telefonica è una sequenza di azioni che coinvolge un chiamante e una rete telefonica. Questo in un sistema che gestisce una rete telefonica. Mentre in un sistema di fatturazione di chiamate si avrà un classe con gli attributi come la data, l’orario e la destinazione.
5. Ruoli: Il nome di una classe dovrebbe riflettere la sua reale natura e non il ruolo che ricopre in un’associazione. Es: Proprietario in una base di dati di un rivenditore di automobili è poco significativo mentre Cliente o Persona è più adatto e può assumere il ruolo di proprietario, guidatore, rivenditore.
6. Costrutti di implementazione: I costrutti estranei al mondo reale dovrebbero essere eliminati dal modello di analisi. Es: processo, algoritmo, alberi, array, tabelle.

In base alle suddette regole operiamo la nostra selezione delle classi

Cittadino e Utente esprimono lo stesso concetto, diciamo che entrambi sono abbastanza attinenti al dominio anche se Utente sembra più appropriato essendo appunto la  persona che utilizza il sistema.

Comunale, Provinciale, Regionale definiscono una proprietà di Evento culturale quindi sicuramente è più appropriato modellarli come attributi o valori possibili di un attributo. Lo stesso vale per Tipologia di evento, Data, Periodo

 Comune, Provincia, Regione sono possibili Zone. Probabilmente, in seconda analisi, questi concetti si unificheranno con quelli espressi nel punto precedente, ma per adesso consideriamoli separatamente.

Login e Password in questo contesto rappresentano attributi di Utente

Motivo di rifiuto è sicuramente un attributo di Esito della richiesta di adesione. Lo stesso discorso si può fare per Parametro di connessione, Indirizzo

Giornaliera, Settimanale, Mensile sono possibili valori di Cadenza, a sua volta espressa nelle Preferenze associate all’iscrizione alla newsletter

Portale web, Form sono costrutti di implementazione e quindi, a livello di analisi del dominio, sono poco attinenti

Iscrizione, Abilitazione, Registrazione  sono tutte operazioni, di quale oggetto, lo vedremo in seguito.

Criterio di ricerca, Informazione direi che sono classi troppo vaghe e poco attinenti col dominio

Ente culturale, Società, Richiesta, sembrerebbero adatte per essere selezionate come classi.

Alla fine di questa selezione avremo un elenco di quelle che potrebbero essere le classi adatte alla costruzione del modello di dominio (v. figura sotto)

L’avere selezionato le classi non ci permette ancora di realizzare il diagramma : occorre individuare le relazioni che legano le classi tra loro.
Rileggiamo allora il documento dei requisiti, ma questa volta andiamo a cercare i verbi o le frasi verbali che, normalmente, esprimono una relazione tra due classi.
Per semplificare mostriamo di seguito direttamente il diagramma delle classi dove si possono vedere le relazioni che abbiamo individuato:


 
Fig 1- Diagramma delle classi

Il modello a oggetti del dominio non è l’applicazione da realizzare, si tratta di un modello che ci dà un altro punto di vista sul sistema da realizzare, mettendo in evidenza ancora di più le regole di business.

   Tra le classi del diagramma ne notiamo due con la notazione <<enumeration>>: Questo tipo di notazione si chiama stereotipo e serve a dare una descrizione aggiuntiva alla classe. Nel nostro caso specifico indichiamo che la classe fornisce una enumerazione di valori ammissibili.

I diagrammi che abbiamo visto finora ci hanno dato una visione più chiara di quello che il sistema dovrà fare, probabilmente andranno affinati in una seconda analisi  attraverso altri modelli, nelle fasi successive.
Altri modelli ci possono venire in aiuto ad una migliore comprensione del dominio d’applicazione e la progettazione del sistema. E’ compito del progettista individuare i diagrammi più adatti al caso.

Passiamo adesso alla fase di progettazione, dove verranno visti esempi d’uso di altri diagrammi ma in un contesto diverso e cioè quello relativo alle scelte architetturali per la nostra applicazione.
La scelta che facciamo è quella di creare una applicazione web basta sull’ormai assodato pattern MVC (Model-View-Controlller) e utilizzando J2EE per l’implementazione (Naturalmente! : ) Utilizziamo un diagramma delle componenti per descrivere la nostra architettura:
 

 

 

Ma vediamo più in dettaglio i vari componenti:

ControllerServlet : Come si può intuire dal nome, implementiamo il Controller con una Servlet. Questo componente si occupa della ricezione delle richieste da parte degli utenti, dell’esecuzione delle operazioni necessarie per soddisfare la request mediante il Model e dell’invio della vista opportuna all’utente utilizzando il ViewManager.

ViewManager : Questo componente si occupa di selezionare la vista opportuna che dipende dalla richiesta dell’utente e dalle elaborazioni eseguite nel Model

View : Questo componente rappresenta la vista vera e propria, l’interfaccia utente (GUI) che noi implementeremo con delle pagine JSP e che vengono opportunamente selezionate per poi essere inviate all’utente, dal ViewManager.

Model : Questo componente implementa la logica del sistema e contiene le classi di business del nostro dominio. E’ il Controller che, in base alla richiesta dell’utente, utilizza la classe opportuna per  eseguire l’operazione richiesta.

Ma vediamo di analizzare anche un aspetto dinamico del nostro sistema utilizzando ad esempio un sequence diagram per descrivere uno scenario tipico della nostra applicazione.
Consideriamo l’esempio dell’operazione di login di un utente che accede al sistema fornendo le sue credenziali:

 
Fig 3- Sequence diagram

 

Nel diagramma sono evidenziate le ipotetiche classi che comunicano per poter realizzare l’operazione di login: L’utente invia una richiesta al Controller (ControllerServlet) che utilizza il LoginManager (Classe del Model) per autenticare l’utente. Una volta conosciuto l’esito dell’autenticazione, il Controller usa la classe ViewSelector  per selezionare la vista opportuna ( cioè la pagina JSP che indica che l’utente è stato “riconosciuto” dal sistema) e la invia all’utente.

 

Abbiamo visto la descrizione di uno scenario della nostra applicazione, naturalmente in un progetto reale si dovrebbe procedere alla descrizione di tutti gli altri scenari e all’utilizzo di altri diagrammi per descrivere al meglio il sistema come ad esempio un class diagram delle classi del Model; ma noi ci fermiamo qui …. Magari, provateci voi…