Use case step 4: disegnatore automatico di organigrammi avanzato

Figura 2.4: D UC 4 disegno automatico di un organigramma con funzionalit`a avanzate

Attori coinvolti: utente.

Scopo del diagramma: il diagramma rappresentato in figura 2.4 illustra le funzionalit`a messe a disposizione dalla componente realizzata nello step 4.

Descrizione: la componente disegna in modo automatico un organigramma recuperando le informa-zioni necessarie da un database. Oltre alle funinforma-zioni per migliorare la visibilit`a (ridisegnamento, visualizzazione globale e compattamento) disponibili anche nella componente dello step 3, que-sta componente offre delle funzionalit`a aggiuntive. Nel dettaglio `e possibile spostare un organo per cambiarne il ruolo, visualizzare la posizione di un ente all’interno della struttura grafica in maniera facilitata e visualizzare informazioni aggiuntive a quelle visibili normalmente.

UC 4.1 Disegno di un organigramma

Descrizione: la componente disegna in modo automatico l’organigramma. Questa operazione avviene in modo analogo a quanto descritto nello Use Case UC 3.1.

Precondizione: l’utente ha caricato la componente necessaria all’interno dell’area di lavoro di Portal Studio.

Postcondizione: l’utente pu`o visualizzare l’organigramma disegnato all’interno della pagina JSP generata automaticamente.

UC 4.2 Visione di una parte di organigramma

Descrizione: l’utente pu`o visualizzare una parte di organigramma considerando un certo organo se-lezionato come nuova “radice”. Questa operazione avviene in modo analogo a quanto descritto nello Use Case UC 3.8.

Precondizione: l’utente sta visualizzando l’organigramma creato.

Postcondizione: l’utente pu`o visualizzare il dettaglio dell’organigramma desiderato.

UC 4.3 Visione globale dell’organigramma

Descrizione: l’utente pu`o tornare alla visualizzazione originale dell’organigramma dopo un opera-zione di ridisegnamento. Questa operaopera-zione avviene in modo analogo a quanto descritto nello Use Case UC 3.11.

Precondizione: l’utente sta visualizzando un dettaglio dell’organigramma.

Postcondizione: l’utente pu`o visualizzare l’organigramma completo.

UC 4.4 Nascondimento di organi sottoposti

Descrizione: l’utente pu`o nascondere alcuni organi per migliorare la visibilit`a dell’organigramma.

Questa operazione avviene in modo analogo a quanto descritto nello Use Case UC 3.13.

Precondizione: l’utente sta visualizzando l’organigramma.

Postcondizione: l’utente pu`o visualizzare l’organigramma compattato.

UC 4.5 Cambio ruolo di un organo

Descrizione: l’utente pu`o selezionare un organo e spostarlo (UC 4.7). Questa funzione serve quindi a cambiare il ruolo dell’organo spostato. Dopo un operazione di salvataggio la nuova posizione dell’ente spostato verr`a memorizzata nel database (UC 4.6).

Precondizione: l’utente sta visualizzando l’organigramma.

Postcondizione: l’utente pu`o visualizzare l’organo che ha cambiato ruolo nella nuova posizione.

UC 4.8 Visualizzazione di un ente

Descrizione: l’utente pu`o trovare la posizione di un certo ente nella struttura grafica in maniera facilitata. Dopo aver selezionato il nome dell’ente (UC 4.10) di cui si vuole visualizzarne la posizione, l’organo corrispondente verr`a evidenziato (UC 4.9) nella struttura grafica.

Precondizione: l’utente sta visualizzando l’organigramma.

UC 4.11 Visualizzazione di informazioni aggiuntive

Descrizione: dalla struttura grafica sono visibili solo alcune informazioni relative agli enti. Grazie a questa funzione l’utente potr`a selezionare un organo (UC 4.12) e visualizzare informazioni aggiuntive relative all’ente corrispondente.

Precondizione: l’utente sta visualizzando l’organigramma.

Postcondizione: l’utente pu`o visualizzare le informazioni aggiuntive dell’ente selezionato.

Capitolo 3

Progettazione

3.1 Architettura in SitePainter Infinity

L’architettura Three Tier viene spesso considerata come un evoluzione del modello Client-Server in quanto viene considerato un nuovo modulo che gestisce il trasferimento dei dati dal livello client al livello dell’archivio dei dati. Questo modulo aggiuntivo rende indipendente il livello client dai problemi di accesso al livello server. Il pattern architetturale Three Tier divide quindi il sistema in tre diversi moduli, dedicati all’interfaccia utente, alla logica funzionale (business logic) e alla gestione dei dati persistenti. Il modulo di presentazione, ovvero quello dedicato all’interfaccia utente, ha l’obiettivo di acquisire i dati e trasmettere i relativi risultati. Il livello intermedio, ovvero il business logic, si occupa di inoltrare le richieste dell’utente al livello di archivio dati e di trasmettere i relativi risultati. Il livello archivio dati, infine, rappresenta l’insieme dei servizi offerti.

Nel caso di applicazioni Web basate su Web Service i tre moduli sono pi`u specifici:

• l’interfaccia utente `e rappresentata da un Web Server e da eventuali contenuti statici;

• la business logic `e sostanzialmente una serie di moduli integrati in un application server per la generazione di contenuti dinamici;

• i dati sono contenuti in un RDBMS.

L’ambiente di sviluppo aziendale, SitePainter Infinity, si basa proprio su questa struttura e si compone quindi di tre strati:

• Presentation Tier

• Server Application

• Database

Per capire meglio come funzionano i tre strati verr`a ora analizzato il percorso con cui vengono processate le richieste dell’utente. Inizialmente l’utente digita sulla barra degli indirizzi del proprio browser un URL: la richiesta viene quindi trasformata in una operazione di POST o GET, indirizzata al Web Server. A questo punto le richieste statiche vengono fornite dal server stesso, mentre quelle dinamiche vengono inoltrate all’Application Server che saranno processate da un Business Object (secondo strato) che, in caso di necessit`a di lettura dei dati, invia la richiesta al Database Server,

Object, che li formatta e prepara la pagina HTML di risposta. Tale pagina viene passata al Web Server e infine torna indietro fino al browser dell’utente.

Solitamente Web Server e Application Server risiedono nella stessa macchina, in quanto hanno un gran volume di dati da scambiare, mentre il Business Logic pu`o risiedere sulla stessa macchina del Web Server, in caso di piccole applicazioni, o, in alternativa, su un cluster composto da molti computer nel caso di applicazioni utilizzate da migliaia di utenti: in questo caso il Web Server inoltra i parametri necessari verso la macchina destinata a rispondere all’utente in questione.

Le relazioni tra i vari strati sono visibili in figura 3.1.

Figura 3.1: archittettura di SitePainter