Operazioni implementate:

- segreteria didattica:
    - inserimento dei dati di un docente
    - inserimento dei dati generici di un corso
    - assegnamento di un corso ad un docente
- docente:
    - aggiornamento del proprio orario ricevimento e del proprio indirizzo di posta elettronica
    - inserimento/cancellazione di una dispensa del proprio corso
    - inserimento di un avviso del proprio corso
- studente (utente generico):
    - visualizzazione elenco dei corsi
    - visualizzazione elenco docenti
    - visualizzazione informazioni dettagliate di un corso


 Bug e malfunzionamenti noti ma non risolti:

- la cancellazione delle dispense non cancella fisicamente il file, ma solo la sua rispettiva tupla nel db

- provvisoriamente è stata implementata solo la possibilità di dare 1 sola utenza per ogni personale. Il ruolo dell'utenza dipende dal ruolo del personale.

- sempre per quanto riguarda la gestione delle utenze, non è stato progettato un controllo per sapere se lo username è già usato, mentre nel db tale attributo è definito come unique. Quindi se si prova ad immettere l momento della creazione uno username già usato si riceve un opportuno messaggio di errore.



Descrizione della architettura della applicazione:

modello: contiene le interfacce che definiscono i servizi offerti dai diversi elementi del modello dell'applicazione.
modello.impl: contiene le classi che implementano le interfacce e offrono i servizi.

persistenza: contiene le interfacce che definiscono le modalità di gestione della persistenza e le classi proxy che implementano un meccanismo di Lazy Load.
persistenza.impl: contiene le classi che implementano le interfacce e offrono i servizi.
facade: contiene classi che definiscono i servizi offerti dal sistema

action: include le classi "action" e le classi "helper" per la validazione dei dati immessi dall'utente
tiles: contiene le pagine jsp che definiscono la struttura dei tiles di Struts.
pages: contiene le pagine jsp che definiscono il body della definizione dei tiles.

util: contiene classi che offrono servizi di utilità generica.


Scelte progettuali e implementative:

Persistenza:

- allo scopo di ridurre l'accoppiamento tra la sorgente dati e le classi del modello la responsabilità di interagire con il database è stata affidata ad opportune classi (pattern Data Access Object);

- per le classi corrispondenti ad entità per le quali è stata scelta la strategia Lazy Load si è applicato il pattern Proxy; in particolare, in relazione ai casi d'uso si è scelto di implementare le classi CorsoProxy (che effettua il caricamento pigro delle dispense, degli avvisi e del docente associati ad un corso) e PersonaleProxy  (che effettua il caricamento pigro del corso associato ad un docente) mentre, coerentemente con il caso d'uso di autenticazione, si è scelto invece di non effettuare il caricamento pigro dell'oggetto Personale associato all'oggetto Utente.

Facade:

-le  operazioni per accedere alle funzionalità del sistema sono offerte da un insieme di facade controller che aggiungono un livello di indirezione  tra le classi client e l'implementazione della logica applicativa (pattern Facade).

 

Osservazioni, suggerimenti, commenti, critiche:

Abbiamo usato in questo progetto del framework Struts. Il quale non ha ridotto il tempo di sviluppo del progetto dato che abbiamo impiegato molto tempo per studiarlo. Ma si è continuato su questa strada perché in questo modo abbiamo avuto la possibilità di conoscere tecnologie nuove e richieste nell'ambito professionale, e quindi per arricchire il nostro bagaglio di conoscenze.