Universit` a degli Studi di Padova
Facolt` a di Scienze MM.FF.NN
Corso di informatica
Tesi di Laurea
Disegnatore
di organigrammi aziendali
Candidato: Deborah Rizzi
Relatore: Dott.sa Ombretta Gaggi
A.A. 2010/2011
Indice
1 Introduzione 9
1.1 Azienda ospitante . . . 9
1.1.1 Informazioni generali . . . 9
1.1.2 Gruppo Zucchetti . . . 10
1.2 Premesse . . . 10
1.2.1 Mindslide . . . 10
1.2.2 Cos’`e un organigramma . . . 13
1.2.3 SitePainter Infinity . . . 16
1.3 Obiettivi dello stage . . . 20
1.3.1 Step 1 . . . 20
1.3.2 Step 2 . . . 21
1.3.3 Step 3 . . . 21
1.3.4 Step 4 . . . 21
1.4 Limitazioni . . . 22
2 Analisi dei requisiti 23 2.1 Lista requisiti . . . 25
2.2 Descrizione Requisiti . . . 27
2.2.1 Disegno oggetti “liberi” . . . 27
2.2.2 Spostamento figure geometriche . . . 27
2.2.3 Disegno livelli . . . 27
2.2.4 Disegno organi temporanei . . . 28
2.2.5 Disegno organi di staff . . . 28
2.2.6 Disegno relazioni . . . 28
2.2.7 Inserimento testo . . . 28
2.2.8 Inserimento immagine . . . 29
2.2.9 Disegno organigramma . . . 29
2.2.10 Visualizzazione parte di organigramma . . . 29
2.2.11 Visualizzazione globale . . . 29
2.2.12 Miglioramento visibilit`a . . . 30
2.2.13 Disegno organigramma . . . 30
2.2.14 Visualizzazione parte di organigramma . . . 30
2.2.15 Visualizzazione globale . . . 30
2.2.16 Miglioramento visibilit`a . . . 31
2.2.17 Spostamento organi . . . 31
2.2.18 Evidenziazione ente . . . 31
2.2.19 Visualizzazione informazioni aggiuntive . . . 31
2.2.20 Documentazione . . . 31
2.2.21 Standard HTML5 . . . 32
2.3 Diagrammi use case . . . 32
2.3.1 Use case step 1: disegnatore di oggetti “liberi” . . . 32
2.3.2 Use case step 2: disegnatore di organigrammi . . . 34
2.3.3 Use case step 3: disegnatore automatico di organigrammi . . . 37
2.3.4 Use case step 4: disegnatore automatico di organigrammi avanzato . . . 39
3 Progettazione 42 3.1 Architettura in SitePainter Infinity . . . 42
3.2 Struttura di una componente di Portal Studio . . . 43
3.3 Analisi delle librerie utilizzate . . . 44
3.4 Pattern . . . 48
3.5 Specifica delle Componenti . . . 50
3.5.1 Organigramma . . . 51
3.5.2 Organo . . . 53
3.5.3 Menu . . . 53
3.5.4 GraphicInterface . . . 54
3.5.5 RaphaelAdapter . . . 54
3.5.6 ZpdInterface . . . 55
3.5.7 RaphaelZPDAdapter . . . 56
4 Prodotto ottenuto 57 4.1 Realizzazione database . . . 57
4.2 Disegno organigramma . . . 58
4.3 Funzionalit`a disponibili . . . 59
4.3.1 Modifica informazioni . . . 59
4.3.2 Visualizzazione delle informazioni aggiuntive . . . 60
4.3.3 Aggiungi subordinato . . . 60
4.3.4 Aggiungi staff . . . 61
4.3.5 Compattamento . . . 61
4.3.6 Ridisegnamento . . . 62
4.3.7 Eliminazione . . . 64
4.3.8 Spostamento . . . 64
4.3.9 Trova organo . . . 65
5 Test effettuati 66 5.1 Metodi di verifica utilizzati . . . 66
5.1.1 Test . . . 66
5.1.2 Metriche . . . 67
5.2 Descrizione dei test effettuati . . . 68
5.2.1 Test di unit`a . . . 68
5.2.2 Test di sistema . . . 71
5.3 Risultati delle metriche . . . 73
5.3.1 Copertura dei test di unit`a . . . 73
5.3.2 Risultati delle metriche dimensionali . . . 73
5.3.3 Risultati delle metriche di complessit`a . . . 74
6 Conclusioni 75 6.1 Consuntivo . . . 75
Glossario 78
Bibliografia 80
Elenco delle tabelle
5.1 Risultati delle metriche dimensionali . . . 73 5.2 Risultati delle metriche di complessit`a . . . 74
Elenco delle figure
1.1 logo Zucchetti . . . 10
1.2 esempio di collegamento sibling . . . 11
1.3 esempio di collegamento parent/child . . . 11
1.4 interfaccia Slide View . . . 11
1.5 interfaccia Mindmap View . . . 12
1.6 interfaccia Presentation View . . . 12
1.7 esempio di organigramma con rappresentazione piramidale . . . 13
1.8 esempio di organigramma con rappresentazione a bandiera . . . 14
1.9 esempio di organigramma con rappresentazione ad albero . . . 14
1.10 esempio di un organigramma con rappresentazione mista . . . 15
1.11 front-end di SitePainter Infinity . . . 16
1.12 front-end di Portal Studio . . . 17
1.13 Portlet editor . . . 18
1.14 Action’s Code . . . 19
1.15 esempio di Design Painter . . . 19
1.16 esempio di Master File Painter . . . 20
1.17 esempio di organigramma creato con orgplus . . . 22
2.1 D UC 1 disegno e spostamento di oggetti liberi . . . 32
2.2 D UC 2 disegno di un organigramma . . . 34
2.3 D UC 3 disegno automatico di un organigramma . . . 37
2.4 D UC 4 disegno automatico di un organigramma con funzionalit`a avanzate . . . 39
3.1 archittettura di SitePainter . . . 43
3.2 esempi di Rapha¨el . . . 44
3.3 struttura del pattern Adapter . . . 48
3.4 diagramma di utilizzo del pattern Adapter . . . 49
3.5 diagramma rappresentante la divisione delle classi . . . 50
4.1 esempio di organigramma realizzato con la componente . . . 58
4.2 subordinato con rappresentazione a bandiera e piramidale . . . 58
4.3 esempio di men`u esteso . . . 59
4.4 esempio di dialog per l’aggiunta delle informazioni . . . 59
4.5 esempio di dialog per la visualizzazione delle informazioni aggiuntive . . . 60
4.6 organigramma visibile prima dell’operazione di compattamento . . . 61
4.7 organigramma visibile dopo l’operazione di compattamento . . . 62
4.8 organigramma visibile prima dell’operazione di ridisegnamento . . . 63
4.9 organigramma visibile dopo l’operazione di ridisegnamento . . . 63
4.10 organigramma visibile dopo l’operazione di ridisegnamento . . . 65
6.1 consuntivo finale . . . 76
Capitolo 1
Introduzione
Il presente documento intende descrivere l’attivit`a di stage svolta dalla laureanda Deborah Rizzi presso l’azienda Zucchetti S.p.A.
Il progetto proposto dall’azienda consiste nella realizzazione di una componente, utilizzabile nell’am- biente di sviluppo SitePainter Portal Studio, che permetta agli utenti di disegnare organigrammi aziendali.
La realizzazione del progetto user`a come punto di partenza il software MindSlide, realizzato durante il corso di Ingegneria del Software A.A. 2010/2011.
All’interno del documento sono state adottate le seguenti convenzioni tipografiche:
• i termini presenti nel Glossario sono scritti con stile sans serif
• le porzioni di codice sono scritte con stile macchina da scrivere
1.1 Azienda ospitante
Il progetto di stage, che comprende le attivit`a di analisi, progettazione, realizzazione e documenta- zione di una componente `e stata svolta presso l’azienda Zucchetti S.p.A. con sede a Padova.
Il periodo svolto in tale azienda va dal 21/04/2011 al 22/06/2011 per un totale di 300 ore effettive.
La Zucchetti S.p.A., sede dello stage, fa parte del gruppo Zucchetti.
1.1.1 Informazioni generali
Nome: Zucchetti
Sede del Tirocinio: Via Cittadella 7 CAP: 35137
Citt`a: Padova Provincia: PD Telefono: 049659831 Fax: 049659831
Partita IVA: 05006900962 Mail: gregorio.piccoli@zucchetti.it
1.1.2 Gruppo Zucchetti
Il gruppo Zucchetti conta oltre 1800 addetti e grazie a una rete distributiva di oltre
800 Partner e 73.000 clienti, risulta essere una delle aziende italiane pi`u importanti nel settore dell’ICT (Information and Communication Technology).
Il gruppo Zucchetti si occupa prinicipalmente di fornire soluzioni software, hardware e servizi inno- vativi ad aziende di ogni dimensione e settore, professionisti (commercialisti, avvocati, notai ecc.), associazioni di categoria, CAF e alla pubblica amministrazione.
Da pi`u di trent’anni il gruppo fornisce soluzioni di qualit`a per migliorare l’efficienza dei propri processi di gestione delle Direzioni del Personale, soluzioni che vengono utilizzate da oltre 10.000 aziende italiane.
Nella figura 1.1 `e illustrato il simbolo del gruppo Zucchetti.
Figura 1.1: logo Zucchetti
1.2 Premesse
1.2.1 Mindslide
MindSlide `e il software realizzato dal gruppo IronMad Project, per il progetto di Ingegneria del Software A.A. 2010/2011.
Il gruppo IronMad Project `e composto dalle seguenti persone: Deborah Rizzi, Mattia Cerantola, Riccardo Cucco, Francesca Pastorello, Melania Miazzo, Elisa Canella e Marco Castaldini.
Alcune parti di questo software sono state utilizzate come base di partenza per lo sviluppo del progetto obiettivo dello stage. In particolare `e stata rielaborata l’interfaccia graphicInterface che inizialmente definiva i metodi per il disegno della mindmap, e la classe RaphaelAdapter che ne implementava tutti i metodi.
MindSlide `e un software utilizzabile da browser che permette all’utente la creazione, lo sviluppo, la visualizzazione ed il salvataggio locale di presentazioni di slide con il supporto di una mindmap.
Oltre alla normale visualizzazione delle slide questo programma permette di definire particolari serie di slide per approfondire i concetti espressi nella singola slide. I collegamenti tra le varie slide possono essere quindi di due tipi:
• sibling: identifica una serie di slide correlate tra loro.
• parent/child: collegamento di tipo padre/figlio che identifica un approfondimento.
Nelle figure 1.2 e 1.3 `e possibile visualizzare rispettivamente un esempio di collegamento sibling e di collegamento parent/child.
Figura 1.2: esempio di collegamento sibling
Figura 1.3: esempio di collegamento parent/child
MindSlide fornisce inoltre tre interfacce che identificano un diverso livello di dettaglio per la visua- lizzazione delle slide:
• Slide View: dove `e possibile modificare il contenuto di una singola slide (vedi figura 1.4);
Figura 1.4: interfaccia Slide View
• MindMap View: dove `e possibile visualizzare tutte le slide e i collegamenti esistenti tra di loro. In questa modalit`a `e inoltre possibile creare nuove slide o eliminare quelle gi`a esistenti.
Infine `e possibile inserire informazioni relative all’intera mindmap come ad esempio il titolo della presentazione, la descrizione e la data dell’evento (vedi figura 1.5);
Figura 1.5: interfaccia Mindmap View
• Presentation View: dove `e possibile scorrere la lista di slide del primo livello o esplorare l’intera mindmap a seconda delle esigenze (vedi figura 1.6);
Figura 1.6: interfaccia Presentation View
Il software MindSlide [7] fa uso dei linguaggi HTML5, JavaScript, JSON e CSS.
Grazie alle componenti manifest e local storage di HTML5 `e inoltre possibile utilizzare il software anche in modalit`a offline dopo una prima visita al sito.
1.2.2 Cos’` e un organigramma
Un organigramma `e la rappresentazione grafica della struttura organizzativa di un azienda e per- mette di identificare i vari ruoli, le responsabilit`a e le linee di dipendenza gerarchica o funzionale.
La struttura di un tipico organigramma `e composta da:
• caselle rettangolari, che rappresentano enti o gruppi. All’interno di essi viene indicata la denominazione dell’ente, la sigla, il responsabile e altre informazioni ritenute utili. Esistono due tipi di ente:
– organi di line: hanno autorit`a gerarchica sugli enti sottoposti;
– organi di staff: non hanno autorit`a, ma sono di supporto agli altri enti.
• ellissi, che rappresentano degli organi temporanei, ovvero organi che lavorano in modo discon- tinuo all’interno dell’azienda;
• linee, che rappresentano le relazioni tra gli enti. Ci sono due tipi di linee:
– continue: rappresentano le relazioni d’autorit`a tra le diverse posizioni e possono essere sia orizzontali che verticali;
– tratteggiate: rappresentano un legame funzionale tra due posizioni dove non esiste alcuna autorit`a gerarchica ma indica solamente il contributo di un ente o gruppo ad un altro.
La rappresentazione grafica di un organigramma pu`o essere di pi`u tipi:
• piramidale: si estende in larghezza (vedi figura 1.7);
Figura 1.7: esempio di organigramma con rappresentazione piramidale
• a bandiera: si estende in altezza (vedi figura 1.8);
Figura 1.8: esempio di organigramma con rappresentazione a bandiera
• ad albero: simile alla rappresentazione delle directory (vedi figura 1.9);
Figura 1.9: esempio di organigramma con rappresentazione ad albero
• mista: si rappresentano alcuni livelli in modo piramidale ed altri a bandiera. Questa rappre- sentazione viene usata generalmente per questioni di spazio (vedi figura 1.10).
Figura 1.10: esempio di un organigramma con rappresentazione mista
1.2.3 SitePainter Infinity
SitePainter Inifinity `e un insieme di vari tool che permettono la gestione integrale di un progetto di Web Application, dalla manutenzione del database, alla generazione dei programmi Java (servlet) e pagine HTML e alla relativa pubblicazione sul web server.
Nella figura 1.11 `e rappresentato il front-end di SitePainter Infinity.
Figura 1.11: front-end di SitePainter Infinity
Dal front-end di SitePainter `e possibile accedere a Portal Studio, che verr`a utilizzato per lo sviluppo del progetto.
Portal Studo `e un ambiente di sviluppo WEB-RAD (Web Rapid Application Development), realiz- zato dalla Zucchetti S.p.A., che permette di realizzare applicazioni per la pubblicazione di dati utili nella realizzazione di sofisticati portali aziendali o complessi siti Internet basati su database.
Nella figura 1.12 `e rappresentato il front-end di Portal Studio.
Figura 1.12: front-end di Portal Studio
Dalla toolbar di Portal Studio `e possibile accedere a vari tool:
Portlet editor: permette di disegnare i singoli portlet che compongono il portale;
Pagelet editor: permette di aggregare i singoli portlet secondo il layout desiderato per la realiz- zazione del portale;
Plan editor: permette, attraverso l’uso dei template, di creare pagine JSP dinamiche.
Visual Query: permette, utilizzando SQL, di definire query multifile che possono essere utilizzate all’interno delle applicazioni;
Page editor: permette di disegnare le pagine JSP da utilizzare all’interno del portale o di integrare la struttura precedentemente creata;
Report editor: permette di realizzare complessi report di stampa basandosi su interrogazioni del database. Questo tool genera documenti in formato PDF;
Chart editor: permette di realizzare dei modelli di grafici per rappresentare i dati contenuti nel database;
Css editor: permette di definire in modo semplice i fogli di stile che definiscono le propriet`a grafiche degli elementi che compongono l’applicativo.
Durante lo sviluppo del progetto verr`a fatto largo uso di Portlet Editor (vedi figura 1.13) che verr`a ora analizzato pi`u in dettaglio.
Figura 1.13: Portlet editor
Come detto prima, Portlet Editor permette di disegnare i singoli portlet, ovvero i singoli componenti che andranno a comporre il portale.
Al momento del salvataggio del portale realizzato viene generata una pagina JSP (attiva lato server).
Questa pagina contiene una parte HTML e una parte Javascript: la parte HTML contiene la rap- presentazione grafica del portlet, mentre la parte JavaScript controlla e guida la parte di interazione con l’utente.
Il codice HTML e JavaScript generato viene scaricato nel browser e interamente eseguito lato client.
All’interno di Portlet editor ci sono due toolbar molto utili: la Toolbar Align e la Toolbar Objects.
La Toolbar Align consente di posizionare e ridimensionare le componenti selezionate, mentre la Toolbar Objects consente di inserire gli oggetti che andranno a comporre il portlet. Alcuni degli oggetti disponibili all’inserimento sono: TextBox, ComboBox, CheckBox e Label, ma oltre a questi oggetti standard `e possibile crearne di nuovi: questo `e proprio l’obiettivo principale dello stage.
Con il doppio click, su una delle componenti inserite, si apre una nuova finestra, denominata Action’s Code (vedi figura 1.14), grazie alla quale `e possibile completare le funzionalit`a del portlet. Questa finestra permette all’utente di creare funzioni JavaScript con lo scopo di lanciare eventi, eseguire calcoli o modificare il comportamento standard di un elemento.
Infine `e possibile assegnare delle propriet`a alle componenti inserite, che saranno visibili nella pagina JSP generata. Alcuni esempi di propriet`a sono: altezza, larghezza, colore di sfondo e bordo della componente.
Figura 1.14: Action’s Code
Altri due tool che verranno utilizzati durante lo sviluppo del progetto sono: Design Painter e Master File Painter.
La funzione principale di Design Painter `e quella di costruire e mantenere le strutture di tutti i database; inoltre guida l’analista durante la fase di analisi a stendere il piano del programma.
In figura 1.15 viene illustrato un esempio di entit`a Design Painter.
Figura 1.15: esempio di Design Painter
Le entit`a di tipo Master File Painter, invece, sono composte da una tabella di database e da due programmi servlet: il primo gestisce il Business Object e il secondo genera la pagina HTML che funge da interfaccia per l’utente, e dalla quale `e possibile inserire, modificare ed eliminare i record
del database.
In figura 1.16 viene illustrato un esempio di entit`a Master File Painter.
Figura 1.16: esempio di Master File Painter
1.3 Obiettivi dello stage
L’attivit`a di stage ha come obiettivo quello di modificare e aggiungere nuovi algoritmi di layout al graphicInterface del software MindSlide, realizzato dal gruppo IronMad Project per il corso di Ingegneria del Software A.A. 2010/2011.
Questi algoritmi serviranno a realizzare una componente, utilizzabile da Portal Studio SitePainter, che permetta agli utenti di disegnare organigrammi aziendali.
Il progetto `e stato suddiviso in quattro step dove ogni step aggiunge valore a quello precedente.
1.3.1 Step 1
L’obiettivo del primo step `e quello di realizzare una componente utilizzabile da SitePainter Portal Studio.
Questa componente avr`a una serie di API che permettono all’utente di disegnare oggetti di vario tipo in modo “libero”, come ad esempio cerchi, rettangoli, linee, testo e immagini e dovr`a essere strutturata in modo tale da poter essere una base di partenza per progetti futuri.
1.3.2 Step 2
Lo step 2 ha come obiettivo quello di modificare la componente dello step 1 in modo tale da poter disegnare organigrammi.
In questo step le API non permetteranno pi`u quindi di disegnare oggetti “liberi” ma i vari livelli che andranno a comporre l’organigramma. In particolare dovr`a permettere di disegnare organi sovraordinati, sottoposti, di staff e temporanei e le relazioni esistenti tra di loro.
Inoltre dovr`a essere possibile l’inserimento di testo e di un’immagine all’interno degli organi disegnati.
1.3.3 Step 3
Lo step 3 si pone l’obiettivo di modificare lo step 2 in modo da poter disegnare l’organigramma di un’azienda in pochi e semplici passi.
La componente dovr`a recuperare i dati da un database contenente le informazioni del personale e disegnare in modo automatico l’organigramma corrispondente. In particolare dovr`a recuperare il nome, cognome, il ruolo e, se presente, l’immagine dell’ente in questione.
L’algoritmo che disegner`a l’organigramma dovr`a essere intelligente e dovr`a considerare vari fattori come il numero totale di organi da disegnare, il numero di organi che compongono ogni livello e lo spazio a disposizione. Dati questi elementi dovr`a trovare la rappresentazione migliore per rappresentare l’organigramma: i primi livelli avranno generalmente una rappresentazione piramidale, mentre gli ultimi a bandiera.
Altro obiettivo di questo step `e quello di permettere all’utente di selezionare un certo organo per ridisegnare l’organigramma considerando l’ente selezionato come massimo autoritario. Questa fun- zionalit`a sar`a possibile solo per gli organi autoritari e non per gli organi di staff o temporanei. Data questa opzione, dovr`a anche essere possibile ritornare alla visione originale dell’organigramma.
Infine per migliorare ulteriormente la visibilit`a dovr`a essere possibile compattare l’organigramma nascondendo alcuni organi sottoposti di un dato organo sovraposto.
1.3.4 Step 4
Il quarto ed ultimo step implementa alcune funzionalit`a aggiuntive rispetto alla componente dello step 3.
La prima di queste funzionalit`a dovr`a permettere all’utente di spostare gli organi dell’organigramma in una nuova posizione: questa operazione comporta l’aggiornamento dei dati dell’ente spostato sul database e risulta essere utile quando un ente cambia ruolo.
Un’altra funzionalit`a aggiuntiva che verr`a implementata dovr`a permettere di individuare, in modo semplice, la posizione di un dato ente all’interno dell’organigramma: selezionato il nome di un ente da una lista dovr`a essere evidenziato l’organo corrispondente all’interno dell’organigramma.
L’ultima funzionalit`a dovr`a permettere la visualizzazione di informazioni aggiuntive di un certo ente selezionato.
Alcune delle funzionalit`a descritte sono state ideate prendendo spunto da siti web che offrono la possibilit`a di disegnare organigrammi.
Cogmap [8], ad esempio, consente all’utente che ne fa uso di spostare un organo in una nuova posizione, visualizzare informazioni aggiuntive a quelle visibili, e di trovare la posizione di un certo ente, all’interno della struttura grafica, semplicemente cercandone il nome da una lista.
Da Orgplus [9], invece, `e stata presa l’idea di aggiungere la possibilit`a di inserire un’immagine all’interno degli organi.
Nella figura 1.17 `e possibile visualizzare un esempio di organigramma preso dal sito di Orgplus [9].
Figura 1.17: esempio di organigramma creato con orgplus
1.4 Limitazioni
I principali linguaggi utilizzati per la realizzazione della componente sono HTML5 e JavaScript. Per un corretto funzionamento si richiede quindi l’utilizzo di un browser compatibile con la tecnologia HTML5 e l’attivazione del JavaScript nel browser che si sta utilizzando.
Per testare la compatibilit`a del proprio browser con HTML5 `e possibile visitare il sito di HTML5 test [10]. In particolare il browser utilizzato deve supportare la tecnologia SVG (Scalable Vector Graphics), la quale permette di visualizzare immagini di grafica vettoriale.
Nel caso in cui tale tecnologia non fosse compatibile (come ad esempio Internet Explorer 8.0), la libreria utilizzata per la realizzazione della componente genera codice VML (Vector Markup Langua- ge) al posto di SVG ma alcune funzionalit`a messe a disposizione normalmente non saranno disponibili in modo completo, o saranno completamente inutilizzabili.
Per maggiori dettagli sulla compatibilit`a dei browser e sulle librerie utilizzate si veda la sezione 3.3.
Capitolo 2
Analisi dei requisiti
Durante la fase di analisi sono stati definiti i requisiti funzionali, di qualit`a e ambiente che defini- scono il progetto.
Dati questi requisiti sono stati poi disegnati i diagrammi Use Case, i quali servono a descrivere le funzioni o i servizi offerti dal sistema.
Come detto nella sezione 1.3 l’attivit`a di stage `e stata divisa in quattro step e per questo, durante la fase di analisi, si `e deciso di dividere i requisiti funzionali a seconda dello step in questione.
La stessa suddivisione `e stata fatta con i diagrammi Use Case, al fine di rappresentare al meglio le interazioni del sistema con gli attori coinvolti e descrivere tutti i casi d’uso possibili.
Al contrario di quest’ultimi, i requisiti di qualit`a e ambiente non sono stati divisi in quanto risultano essere comuni a tutti gli step.
I requisiti sono stati quindi divisi in tre categorie:
• requisiti funzionali
• requisiti di qualit`a
• requisiti di ambiente
I requisiti sono organizzati in forma gerarchica ad albero nella quale la radice (padre) rappresenta un macro-requisito di alto livello che si sviluppa su sotto-requisiti (figli).
La scrittura dei requisiti funzionali sar`a la seguente:
RF.< N > < X.Y.Z >
dove:
RF: indica che si tratta di un requisito funzionale.
N: indica a quale step il requisito fa riferimento (1, 2, 3 o 4).
X: indica la radice dell’albero.
Y: indica il sotto-requisito, se presente.
Z: indica il sotto-sotto-requisito, se presente.
La scrittura dei requisiti di qualit`a e ambiente, invece, sar`a la seguente:
R < Q | A > < X.Y >
dove:
R: indica che si tratta di un requisito.
Q: rappresenta il requisito di qualit`a.
A: rappresenta il requisito di ambiente.
X: indica la radice dell’albero.
Y: indica il sotto-requisito, se presente.
Ogni caso d’uso appartiene ad un diagramma dei casi d’uso, quindi la sua numerazione inizia con la numerazione del diagramma a cui fa riferimento:
UC X.Y dove:
UC: indica che si tratta di un caso d’uso.
X: indica la numerazione del diagramma al quale il caso d’uso `e associato.
Y: indica la numerazione del caso d’uso all’interno del diagramma.
I diagrammi dei casi d’uso sono stati classificati nel seguente modo:
D UC X dove:
D UC: indica che si tratta di un diagramma dei casi d’uso.
X: indica il numero del diagramma e corrisponde al numero di step in questione.
2.1 Lista requisiti
RF.1 1 Disegno oggetti “liberi”.
RF.1 1.1 Disegno rettangoli.
RF.1 1.2 Disegno cerchi.
RF.1 1.3 Disegno ellissi.
RF.1 1.4 Disegno linee continue.
RF.1 1.5 Disegno immagini.
RF.1 1.6 Disegno testo.
RF.1 2 Spostamento figure geometriche.
RF.1 2.1 Spostamento rettangoli.
RF.1 2.2 Spostamento cerchi.
RF.1 2.3 Spostamento ellissi.
RF.1 2.4 Spostamento linee.
RF.2 1 Disegno livelli.
RF.2 1.1 Disegno livelli sovraordinati.
RF.2 1.1.1 Organi sovraordinati rettangolari.
RF.2 1.2 Disegno livelli sottoposti.
RF.2 1.2.1 Organi sottoposti rettangolari.
RF.2 2 Disegno organi temporanei.
RF.2 2.1 Organi temporanei ellittici.
RF.2 3 Disegno organi di staff.
RF.2 3.1 Organi di staff rettangolari.
RF.2 4 Disegno relazioni.
RF.2 4.1 Disegno relazioni di autorit`a.
RF.2 4.1.1 Relazioni di autorit`a rappresentate da linee continue.
RF.2 4.2 Disegno relazioni di collaborazione.
RF.2 4.2.1 Relazioni di collaborazione rappresentate da linee tratteggiate.
RF.2 5 Inserimento testo.
RF.2 5.1 Inserimento testo all’interno dei rettangoli.
RF.2 5.1.1 Inserimento nome e cognome.
RF.2 5.1.2 Inserimento ruolo.
RF.2 5.2 Inserimento testo all’interno degli ellissi.
RF.2 5.2.1 Inserimento nome e cognome.
RF.2 5.2.2 Inserimento ruolo.
RF.2 6 Inserimento immagine.
RF.2 6.1 Inserimento immagine all’interno dei rettangoli.
RF.2 6.2 Inserimento immagine all’interno degli ellissi.
RF.3 1 Disegno organigramma.
RF.3 1.1 Rilevamento informazioni da database.
RF.3 1.1.1 Rilevamento nome.
RF.3 1.1.2 Rilevamento cognome.
RF.3 1.1.3 Rilevamento ruolo.
RF.3 1.1.4 Rilevamento immagine.
RF.3 1.2 Disegno livelli.
RF.3 1.2.1 Disegno livelli sovraordinati.
RF.3 1.2.2 Disegno livelli sottoposti.
RF.3 1.3 Disegno organi temporanei.
RF.3 1.4 Disegno organi di staff.
RF.3 1.5 Disegno relazioni.
RF.3 1.6 Disegno misto.
RF.3 1.6.1 Primi livelli piramidali.
RF.3 1.6.2 Ultimi lievlli a bandiera.
RF.3 2 Visualizzazione parte di organigramma.
RF.3 2.1 Selezione organo.
RF.3 2.1.1 Ridisegnamento.
RF.3 3 Visualizzazione globale.
RF.3 4 Miglioramento visibilit`a.
RF.3 4.1 Compattamento.
RF.4 1 Disegno organigramma.
RF.4 2 Visualizzazione parte di organigramma.
RF.4 3 Visualizzazione globale.
RF.4 4 Miglioramento visibilit`a.
RF.4 5 Spostamento organi.
RF.4 5.1 Scrittura modifiche su database.
RF.4 6.1 Evidenziazione ente.
RF.4 7 Visualizzazione informazioni aggiuntive.
RQ 1 Documentazione.
RA 1 Standard HTML5.
RA 1.1 SVG o VML.
2.2 Descrizione Requisiti
2.2.1 Disegno oggetti “liberi”
Codice requisito: RF.1 1 Tipo: Funzionale
Step: 1
Descrizione: La componente dello step 1 dovr`a permettere all’utente di disegnare oggetti “liberi”
all’interno dell’area di lavoro. Gli oggetti da disegnare verranno aggiunti tramite istruzioni inserite nella Action’s Code. Gli oggetti possono essere figure geometriche come rettangoli, cerchi, ellissi e linee continue o, in alternativa, testo e immagini. Per disegnare le figure geometriche sar`a necessario inserire le coordinate di disegnamento e le dimensioni della figura stessa. Per quanto riguarda il testo e le immagini dovranno essere inseriti oltre alle coordinate di posizionamento, anche il testo da scrivere o l’URI dell’immagine.
2.2.2 Spostamento figure geometriche
Codice requisito: RF.1 2 Tipo: Funzionale
Step: 1
Descrizione: La componente dello step 1 dovr`a permettere all’utente di spostare le figure geome- triche disegnate (rettangoli, cerchi ellissi e linee) all’interno dell’area di lavoro.
2.2.3 Disegno livelli
Codice requisito: RF.2 1 Tipo: Funzionale
Step: 2
Descrizione: La componente dello step 2 dovr`a permettere all’utente di disegnare i vari livelli che compongono l’organigramma. I livelli possono essere di due tipi: sovraordinati e sottoposti, e gli organi che li compongono dovranno avere una forma rettangolare.
2.2.4 Disegno organi temporanei
Codice requisito: RF.2 2 Tipo: Funzionale
Step: 2
Descrizione: Dovr`a essere possibile disegnare organi temporanei, i quali dovranno avere una forma ellittica.
2.2.5 Disegno organi di staff
Codice requisito: RF.2 3 Tipo: Funzionale
Step: 2
Descrizione: Dovr`a essere possibile disegnare organi di staff, i quali dovranno avere una forma rettangolare.
2.2.6 Disegno relazioni
Codice requisito: RF.2 4 Tipo: Funzionale
Step: 2
Descrizione: La componente dello step 2 dovr`a permettere all’utente di disegnare le relazioni esi- stenti tra i vari organi. Le relazioni possono essere di due tipi: autoritarie (tra organi autoritari e subordinati o tra organi autoritari e di staff), che dovranno essere rappresentate tramite linee continue, e funzionali (rappresentano una collaborazione), che dovranno essere rappresentate tramite linee tratteggiate.
2.2.7 Inserimento testo
Codice requisito: RF.2 5 Tipo: Funzionale
Step: 2
Descrizione: La componente dovr`a permettere all’utente di inserire del testo come nome, cognome e ruolo all’interno degli organi disegnati, ovvero all’interno degli organi autoritari, subordinati, di staff e temporanei. In particolare dovr`a quindi essere possibile inserire del testo all’interno dei rettangoli e degli ellissi disegnati.
2.2.8 Inserimento immagine
Codice requisito: RF.2 6 Tipo: Funzionale
Step: 2
Descrizione: La componente dovr`a permettere all’utente di inserire un’immagine raffigurante l’ente all’interno degli organi disegnati, ovvero all’interno degli organi autoritari, subordinati, di staff e temporanei. In particolare dovr`a quindi essere possibile inserire un’immagine all’interno dei rettangoli e degli ellissi disegnati.
2.2.9 Disegno organigramma
Codice requisito: RF.3 1 Tipo: Funzionale
Step: 3
Descrizione: La componente dovr`a disegnare in modo automatico l’organigramma rilevando i dati utili da un database. Le informazioni minime che dovranno essere rilevate sono: nome, cognome e ruolo per ogni ente che dovr`a essere disegnato. Inoltre dovranno essere rilevate, se presenti, le immagini raffiguranti gli enti. Queste informazioni serviranno quindi a disegnare i vari livelli (sovraordinati e sottoposti), gli organi temporanei e di staff che compongono l’organigramma.
La componente dovr`a inoltre disegnare le relazioni di autorit`a (tramite linee continue) e di collaborazione (tramite linee tratteggiate). La struttura dell’organigramma dovr`a avere una rappresentazione mista: i primi livelli dovranno essere disegnati con una struttura piramidale, mentre gli ultimi dovranno avere una rappresentazione a bandiera.
2.2.10 Visualizzazione parte di organigramma
Codice requisito: RF.3 2 Tipo: Funzionale
Step: 3
Descrizione: L’utente dovr`a poter selezionare un organo e ridisegnare l’organigramma conside- rando l’organo selezionato come massimo autoritario. In altre parole con questa operazione verranno nascosti gli organi di livello superiore di quello selezionato e quelli che non hanno nessuna relazione con esso.
2.2.11 Visualizzazione globale
Codice requisito: RF.3 3 Tipo: Funzionale
Step: 3
Descrizione: L’utente dovr`a poter ritornare alla visione globale dell’organigramma. Questa fun- zionalit`a dovr`a essere disponibile dopo un’operazione di ridisegnamento.
2.2.12 Miglioramento visibilit` a
Codice requisito: RF.3 4 Tipo: Funzionale
Step: 3
Descrizione: La componente dovr`a permettere all’utente di migliorare la visibilit`a dell’organigram- ma nascondendone una parte. Dopo un’operazione di compattamento su un certo organo dovranno essere nascosti tutti i suoi organi subordinati o di staff. Ovviamente dovr`a essere possibile “scompattare” l’organigramma, tornando alla visione originale. Questa funzionalit`a pu`o essere considerata come funzione “inversa” della funzionalit`a “Visualizzazione parte di or- ganigramma” in quanto nella prima vengono nascosti tutti gli organi che stanno ad un livello inferiore dell’organo selezionato, mentre nella seconda sono visibili solo sudetti organi e quello selezionato.
2.2.13 Disegno organigramma
Codice requisito: RF.4 1 Tipo: Funzionale
Step: 4
Descrizione: La componente dovr`a disegnare in maniera automatica l’organigramma in modo analogo a quanto descritto nella sezione 2.2.9.
2.2.14 Visualizzazione parte di organigramma
Codice requisito: RF.4 2 Tipo: Funzionale
Step: 4
Descrizione: L’utente dovr`a poter visualizzare una parte dell’organigramma. Questa funzionalit`a
`e analoga a quella descritta nella sezione 2.2.10.
2.2.15 Visualizzazione globale
Codice requisito: RF.4 3 Tipo: Funzionale
Step: 4
Descrizione: L’utente dovr`a poter visualizzare in modo globale l’organigramma. Questa funziona- lit`a `e analoga a quella descritta nella sezione 2.2.11.
2.2.16 Miglioramento visibilit` a
Codice requisito: RF.4 4 Tipo: Funzionale
Step: 4
Descrizione: L’utente dovr`a poter migliorare la visibilit`a dell’organigramma, compattandone una parte. Questa funzionalit`a `e analoga a quella descritta nella sezione 2.2.12.
2.2.17 Spostamento organi
Codice requisito: RF.4 5 Tipo: Funzionale
Step: 4
Descrizione: L’utente dovr`a poter spostare gli organi che compongono l’organigramma in una nuova posizione. Dopo un operazione di salvataggio la nuova posizione dell’organo dovr`a essere memorizzata nel database dal quale sono stati recuperati i dati.
2.2.18 Evidenziazione ente
Codice requisito: RF.4 6 Tipo: Funzionale
Step: 4
Descrizione: L’utente dovr`a poter trovare facilmente un certo ente. Dopo aver selezionato il nome di un ente da una lista dovr`a evidenziarsi l’organo corrispondente nella struttura grafica.
2.2.19 Visualizzazione informazioni aggiuntive
Codice requisito: RF.4 7 Tipo: Funzionale
Step: 4
Descrizione: Dovr`a essere disponibile una funzionalit`a che permetta all’utente di visualizzare le informazioni di un certo ente che non sono direttamente visibili nella struttura grafica. Alcune informazioni aggiuntive potrebbero essere: indirizzo e-mail, numero di telefono, indirizzo e data di nascita.
2.2.20 Documentazione
Codice requisito: RQ 1 Tipo: Qualit`a
Descrizione: Il progetto dovr`a essere fornito di documentazione, in modo da permettere a futuri sviluppatori di avere una guida di partenza per l’evoluzione o la modifica della componente.
2.2.21 Standard HTML5
Codice requisito: RA 1 Tipo: Ambiente
Step: 4
Descrizione: La componente dovr`a utilizzare lo standard HTML5. In particolare dovr`a utilizza- re, per il disegno dell’organigramma, la tecnologia SVG con i browser che la supportano, la tecnologia VML altrimenti.
2.3 Diagrammi use case
2.3.1 Use case step 1: disegnatore di oggetti “liberi”
Figura 2.1: D UC 1 disegno e spostamento di oggetti liberi
Attori coinvolti: utente.
Scopo del diagramma: il diagramma rappresentato in figura 2.1 illustra le funzionalit`a disponibili nella componente realizzata nello step 1.
Descrizione: la componente consente all’utente di disegnare oggetti “liberi”, come ad esempio figure geometriche (rettangoli, cerchi, ellissi e linee), testo e immagini. I comandi per il disegno degli oggetti devono essere scritti nella Action’s Code e il risultato sar`a poi visibile nella pagina JSP generata automaticamente da Portal Studio. Da questa pagina `e inoltre possibile spostare e zoomare gli oggetti disegnati.
UC 1.1 Disegno di un oggetto
Descrizione: l’utente pu`o disegnare un oggetto in posizione libera. Per il disegno `e necessario inserire un comando nella Action’s Code passando vari parametri. Per ogni tipo di oggetto sono necessarie le coordinate x e y per il posizionamento all’interno dell’area di lavoro (UC 1.2).
Altri parametri dipendono dal tipo di oggetto che si vuole disegnare; gli oggetti disegnabili sono quindi di pi`u tipi:
• figure geometriche (UC 1.3), le quali richiedono le dimensioni della figura (UC 1.4) come altezza, larghezza o raggio;
• testo (UC 1.5), che richiede il testo da scrivere (UC 1.6);
• immagine (UC 1.7), che richiede l’inserimento dell’URI dell’immagine (UC 1.8).
Precondizione: l’utente ha inserito la componente nell’area di lavoro di Portal Studio.
Postcondizione: l’utente pu`o visualizzare gli oggetti disegnati all’interno della pagina JSP generata automaticamente.
UC 1.9 Spostamento di una figura geometrica
Descrizione: dalla pagina JSP, l’utente pu`o selezionare una figura (UC 1.10) e spostarla in una nuova posizione.
Precondizione: l’utente sta visualizzando gli oggetti creati nella pagina JSP generata.
Postcondizione: la figura spostata `e visibile nella nuova posizione.
2.3.2 Use case step 2: disegnatore di organigrammi
Figura 2.2: D UC 2 disegno di un organigramma
Attori coinvolti: utente.
Scopo del diagramma: il diagramma rappresentato in figura 2.2 illustra le funzionalit`a messe a disposizione dalla componente realizzata nello step 2.
Descrizione: la componente consente all’utente di disegnare i vari livelli (sovraordinati e sottopo- sti) che compongono l’organigramma. Oltre agli organi autoritari e subordinati `e possibile disegnare organi temporanei e di staff, che verranno poi collegati tra di loro tramite relazioni di autorit`a e collaborative. Infine per concretizzare un organo, ovvero per associare un organo grafico ad un ente reale, `e possibile inserire delle informazioni ed, eventualmente, un’immagine raffigurante l’ente all’interno degli organi disegnati.
UC 2.1 Disegno livello dell’organigramma
Descrizione: l’utente pu`o disegnare vari livelli per comporre l’organigramma, i quali possono essere di due tipi: sovraordinati (UC 2.3) e sottoposti (UC 2.4). Al disegno di un nuovo livello viene automaticamente disegnato un rettangolo, il quale rappresenta un organo autoritario o subordinato (UC 2.2).
Precondizione: l’utente ha inserito la componente nell’area di lavoro di Portal Studio.
Postcondizione: l’utente pu`o visualizzare il livello disegnato all’interno della pagina JSP generata automaticamente.
UC 2.5 Disegno organo temporaneo
Descrizione: l’utente pu`o disegnare un organo temporaneo, ovvero un ente che lavora in mo- do discontinuo all’interno dell’azienda. Questo tipo di organi `e rappresentato da un ellisse (UC 2.6).
Precondizione: l’utente ha inserito la componente nell’area di lavoro di Portal Studio.
Postcondizione: l’utente pu`o visualizzare l’organo temporaneo disegnato all’interno della pagina JSP generata automaticamente.
UC 2.7 Disegno organo di staff
Descrizione: l’utente pu`o disegnare un organo di staff, ovvero un ente che non ha autorit`a, ma `e co- munque di supporto agli altri enti. Gli organi di staff, come gli organi autoritari o subordinati, sono rappresentati da un rettangolo (UC 2.8).
Precondizione: l’utente ha inserito la componente nell’area di lavoro di Portal Studio.
Postcondizione: l’utente pu`o visualizzare l’organo di staff disegnato all’interno della pagina JSP generata automaticamente.
UC 2.9 Disegno relazioni tra organi
Descrizione: l’utente pu`o collegare gli organi disegnati tramite linee continue (UC 2.11), le quali rappresentano una relazione di autorit`a (UC 2.10), o linee tratteggiate (UC 2.13), le quali rappresentano una relazione di collaborazione (UC 2.12).
Precondizione: l’utente ha caricato la componente nell’area di lavoro di Portal Studio e ha gi`a disegnato almeno due organi.
Postcondizione: l’utente pu`o visualizzare le relazioni tra gli organi all’interno della pagina JSP generata automaticamente.
UC 2.14 Inserimento testo all’interno di un organo
Descrizione: dato che la funzione dell’organo `e quella di rappresentare graficamente un ente, `e possibile inserire del testo all’interno dell’organo per avere un’associazione ente-organo pi`u evidente. Generalmente il testo che viene scritto all’interno dell’organo `e il nome e cognome dell’ente (UC 2.15) e il suo ruolo all’interno dell’azienda (UC 2.16).
Precondizione: l’utente ha caricato la componente nell’area di lavoro di Portal Studio e ha gi`a disegnato almeno un organo.
Postcondizione: l’utente pu`o visualizzare il testo inserito nell’organo all’interno della pagina JSP generata automaticamente.
UC 2.17 Inserimento di un immagine all’interno di un organo
Descrizione: oltre alle informazioni dell’ente, `e possibile inserire un’immagine che lo raffigura all’interno dell’organo che lo rappresenta.
Precondizione: l’utente ha caricato la componente nell’area di lavoro di Portal Studio e ha gi`a disegnato almeno un organo.
Postcondizione: l’utente pu`o visualizzare l’immagine inserita nell’organo all’interno della pagina JSP generata automaticamente.
2.3.3 Use case step 3: disegnatore automatico di organigrammi
Figura 2.3: D UC 3 disegno automatico di un organigramma
Attori coinvolti: utente.
Scopo del diagramma: il diagramma rappresentato in figura 2.3 illustra le funzionalit`a messe a disposizione dalla componente realizzata nello step 3.
Descrizione: la componente disegna in modo automatico un organigramma recuperando le infor- mazioni necessarie da un database. Dopo il disegno dell’organigramma l’utente pu`o compiere varie azioni per migliorarne la visibilit`a: ridisegnare l’organigramma considerando un certo or- gano come nuova “radice”, tornare alla visualizzazione globale (disponibile dopo un operazione di ridisegnamento) o nascondere organi sottoposti.
UC 3.1 Disegno di un organigramma
Descrizione: il disegno dell’organigramma viene fatto in modo automatico dalla componente, la quale recupera le informazioni necessarie da un database (UC 3.7). A seconda dei dati recu- perati, vengono quindi disegnati i vari livelli che compongono l’organigramma (UC 3.2), gli organi temporanei (UC 3.3) e gli organi di staff (UC 3.4). Infine in ogni organo viene inse- rito del testo (UC 3.5) che rappresenta l’ente ed eventualmente un’immagine che lo raffigura (UC 3.6).
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 3.8 Visione di una parte di organigramma
Descrizione: per migliorare la visibilit`a dell’organigramma l’utente pu`o selezionare un organo (UC 3.10) e considerarlo come organo con massima autorit`a. La componente dovr`a quindi recuperare nuovamente le informazioni necessarie (UC 3.9) e ridisegnare l’organigramma.
Precondizione: l’utente sta visualizzando l’organigramma creato.
Postcondizione: l’utente pu`o visualizzare il dettaglio dell’organigramma desiderato.
UC 3.11 Visione globale dell’organigramma
Descrizione: dopo un’operazione di ridisegnamento `e possibile ritornare alla visualizzazione glo- bale dell’organigramma. La componente dovr`a quindi recuperare nuovamente le informazioni (UC 3.12) per tornare alla visualizzazione originale.
Precondizione: l’utente sta visualizzando un dettaglio dell’organigramma.
Postcondizione: l’utente pu`o visualizzare l’organigramma completo.
UC 3.13 Nascondimento di organi sottoposti
Descrizione: per migliorare la visibilit`a dell’organigramma l’utente pu`o selezionare un certo organo (UC 3.14) e nascondere tutti i suoi organi subordinati e di staff.
Precondizione: l’utente sta visualizzando l’organigramma.
2.3.4 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 funzioni 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 operazione 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
3.2 Struttura di una componente di Portal Studio
La struttura di una componente (il Control) integrabile con Portal Studio `e formata generalmente da tre parti.
Il file JavaScript, che deve chiamarsi nomeComponenteObj.js, rappresenta il nucleo, o control, della componente stessa. In tale file `e necessario definire il costruttore per inizializzare il control e le varie funzioni che permettono di manipolare l’oggetto stesso. `E possibile che vengano integrati altri file .js di supporto a questo.
Il file con estensione .edtdef, che deve chiamarsi nomeComponente.edtdef descrive le propriet`a perso- nalizzabili della componente, i metodi che saranno disponibili nella Action’s Code, l’inizializzazione dell’oggetto e le propriet`a CSS che appariranno nella Form Properties.
Il file Java, che deve chiamarsi nomeComponenteControl.java, associa ogni propriet`a del form con il corrispondente parametro del costruttore. Queste propriet`a risultano utili al momento della generazione della pagina JSP.
La pagina JSP viene generata al momento della creazione di una nuova pagina con Portal Studio e sostanzialmente rappresenta il Server Application.
Il Presentation Tier invece `e formato dal codice HTML e CSS per la parte di struttura e layout, mentre le funzionalit`a disponibili sono descritte nei file .js. Questo strato `e quello che permette all’utente di interagire con la componente e fornisce le funzionalit`a descritte nel capitolo 2.
Infine il recupero dei dati per la costruzione dell’organigramma avviene grazie alla comunicazione tra il Business Tier e il Data Tier (rappresentato da un database) attraverso delle query scritte in linguaggio SQL.
3.3 Analisi delle librerie utilizzate
Durante le fasi di analisi e progettazione sono state prese in considerazione varie librerie Javascript che permettano di creare immagini di grafica vettoriale in maniera semplificata.
In particolare sono state analizzate le librerie: Rapha¨el, Easel Js, SVGWeb e Gury, descritte qui di seguito.
Rapha¨el:
Rapha¨el [11] `e una piccola, ma potente, libreria JavaScript creata da Dmitry Baranovskiy che permette di creare immagini di grafica vettoriale in modo semplice e veloce.
Rapha¨el utilizza le SVG W3C Recommendation ed il VML come base per la creazione degli oggetti grafici. In questo modo ogni oggetto, entrando a far parte del DOM, pu`o essere associato ad eventi e pu`o essere modificato.
Una delle caratteristiche pi`u interessanti `e la possibilit`a di far ruotare le immagini: ci`o permette notevoli effetti web senza l’utilizzo di Flash.
Al momento Rapha¨el supporta vari browser, tra cui Firefox 3.0+, Safari 3.0+, Chrome 5.0+, Opera 9.5+ e Internet Explorer 6.0+.
In particolare Raph¨el genera codice SVG per i browser che lo supportano e codice VML altrimenti.
Alcuni esempi di immagini realizzati con questa libreria sono visibili nella figura 3.2.
Figura 3.2: esempi di Rapha¨el
Easel Js:
Easel Js [12] `e una libreria JavaScript, realizzata da gskinner [13] e rilasciata con licenza MIT, che permette di creare elementi Canvas.
Tale libreria fornisce un elenco completo e gerarchico di visualizzazione, un modello di interazione con il core e le classi di supporto per lavorare facilmente con il Canvas.
Easel Js per`o `e ancora in versione alpha e quindi in fase di sviluppo; per questo motivo potrebbe subire sostanziali modifiche.
SVGWeb:
SVGWeb [14] `e una libreria JavaScript, realizzata con la partecipazione di Google, che permette di includere file SVG all’interno delle pagine HTML: solitamente viene prima realizzata un’immagine SVG con un software di disegno e poi viene caricata nel browser.
SVGWeb percepisce se il browser utilizzato supporta la tecnologia SVG e, se non viene supportata, renderizza l’immagine SVG in Flash: questo permette una completa compatibilit`a anche con i browser pi`u vecchi ma obbliga l’utente ad installare il plugin di Flash nel proprio browser.
Attualmente questa libreria `e in fase di sviluppo Beta e quindi non sono disponibili tutte le funzio- nalit`a.
Gury:
Gury [15] `e una libreria JavaScript, che permette di creare elementi Canvas di HTML5.
La libreria oltre a permettere la semplice creazione di elementi Canvas, permette di ridimensionare gli oggetti disegnati e aggiungere oggetti renderizzabili, assengnandogli delle animazioni. La sintassi di questa libreria `e simile a quella di jQuery, permette infatti di costruire oggetti e animazioni tramite concatenazioni di metodi.
La libreria `e ancora in versione alpha e, al momento, non supporta Internet Explorer.
Dopo l’analisi di queste librerie `e stato deciso di utilizzare Rapha¨el e di scartare le altre librerie per i seguenti motivi:
• Easel Js `e in versione alpha e quindi pu`o subire sostanziali modifiche;
• SVGWeb `e in versione beta e quindi pu`o subire modifiche;
• SVGWeb permette di includere immagini SVG gi`a create e tale funzionalit`a non risulta utile per la soluzione del problema;
• Gury `e in versione alpha e quindi pu`o subire sostanziali modifiche;
• Gury al momento non supporta Internet Explorer.
Oltre a queste, sono state analizzate altre librerie Javascript utili per l’implementazione delle fun- zionalit`a di zoom e pan.
Per prima `e stata analizzata RaphaelZPD [16], la quale `e un estensione della gi`a nota libreria Ra- pha¨el. Come spiegato Rapha¨el genera immagini SVG con i browser che supportano questa tecnologia, altrimenti genera immagini in formato VML. La libreria RaphaelZPD per`o funziona solo con gli ele- menti SVG e quindi non risulta essere compatibile con i browser pi`u vecchi che supportano solo VML.
Per cercare di avere una completa compatibilit`a con i browser sono state quindi cercate altre librerie che forniscano le funzionalit`a di zoom e pan anche per gli elementi VML. La ricerca per`o non ha dato ottimi risultati ed `e stata effettivamente presa in considerazione solo un’altra libreria, ovvero la libreria utilizzata da Google Maps.
Come Rapha¨el, anche Google Maps genera codice SVG con i browser che lo supportano e codice VML per quelli che non lo supportano.
La libreria per`o `e risultata molto complessa, difficile da analizzare e quindi impossibile da modificare secondo le esigenze con il poco tempo a disposizione.
Per questi motivi `e stato deciso di abbandonare l’idea di avere una libreria che implementi funzio- nalit`a di zoom e pan su elementi VML, ed `e stata presa in considerazione un’altra alternativa che consiste nell’avere una compatibilit`a con gli elementi SVG anche con i browser che non lo supportano nativamente. `E stato trovato, e provato, il plugin SVG Viewer fornito da Adobe [17] che permette di visualizzare in modo abbastanza corretto le componenti SVG e di fare effetti di zoom e pan sugli elementi creati.
Questo plugin per`o non permette di aprire direttamente un file con estensione SVG, ma risulta necessario importarlo in un file HTML con uno dei comandi
< embed src=’rect.svg’ width=’300’ height=’100’ type=’image/svg+xml’
pluginspage=’http://www.adobe.com/svg/viewer/install/’ / >
< iframe src=’rect.svg’ width=’300’ height=’100’ > </iframe>
descritti nel sito di W3C School [18].
Si `e notato per`o che non tutti questi comandi funzionano in modo corretto e inoltre `e necessario specificare nel comando stesso che si vuole utilizzare il plugin.
Altro problema si presenta con Rapha¨el, la quale nella sua forma nativa genererebbe in modo auto- matico codice VML. Forzare la libreria a generare codice SVG non `e una cosa semplice: bisognerebbe modificare la libreria stessa, ma risulta un lavoro troppo oneroso per il tempo a disposizione.
Per questi motivi `e stato deciso di non utilizzare il plugin di Adobe e visualizzare le immagini create con VML nei browser che non supportano SVG. Questa scelta comporta per`o una limitazione su alcuni browser, come Internet Explorer 8.0: le funzionalit`a di zoom e pan sull’organigramma non saranno disponibili.
Dopo aver scelto di utilizzare le librerie Rapha¨el e RaphaelZPD sono stati effettuati alcuni test per verificarne il corretto funzionamento. Da questi test `e risultato che RaphaelZPD non si comporta correttamente con alcuni browser: in Opera e Internet Explorer 9.0 non risultava disponibile la funzionalit`a di zoom (attivata con lo scorrimento della rotellina del mouse).
Analizzando la libreria stessa `e risultato che per i browser in questione non viene intercettato in modo corretto l’evento che farebbe attivare lo zoom. In particolare la libreria esegue il seguente controllo:
if (navigator.userAgent.toLowerCase().indexOf(’webkit’) > = 0) // Chrome/Safari
me.root.addEventListener(’mousewheel’, me.handleMouseWheel, false);
else
// Others
me.root.addEventListener(’DOMMouseScroll’, me.handleMouseWheel, false);
Questa porzione di codice assegna l’evento “mousewheel” ai browser con motore WebKit (Chrome e Safari) e l’evento “DOMMouseScroll” a tutti gli altri (Firefox, Internet Explorer e Opera). Facendo una ricerca in Internet `e risultato che solamente Firefox supporta l’evento “DOMMouseScroll”, mentre Internet Explorer e Opera, come Chrome e Safari, supportano l’evento “mousewheel”.
Date queste considerazioni `e stata modificata la libreria RaphaelZPD per aumentarne la compati- bilit`a. La porzione di codice descritta sopra `e quindi diventata:
// Chrome/Safari/Opera/IE
me.root.addEventListener(’mousewheel’, me.handleMouseWheel, false);
// Firefox
me.root.addEventListener(’DOMMouseScroll’, me.handleMouseWheel, false);
Togliendo il controllo sul tipo di browser che si sta utilizzando, viene associato ad ogni browser sia l’evento “mousewheel”, sia l’evento “DOMMouseScroll”: un evento associato ad un browser che non lo supporta non genera alcun errore ed in questo modo lo zoom funziona correttamente in tutti i browser.
3.4 Pattern
Durante la fase di progettazione `e stato deciso di utilizzare il pattern strutturale Adapter.
L’uso di questo pattern diventa utile quando interfacce di classi differenti devono poter comunicare tra loro.
Figura 3.3: struttura del pattern Adapter
La struttura rappresentata in figura 3.3 rappresenta un Object Adapter ovvero utilizza la composi- zione tra oggetti e non l’ereditariet`a.
I Partecipanti del pattern Adapter sono:
Adaptee: definisce l’interfaccia che ha bisogno di essere adattata;
Target: definisce l’interfaccia che usa il Client;
Client: collabora con gli oggetti in conformit`a con l’interfaccia Target;
Adapter: adatta l’interfaccia Adaptee all’interfaccia Target.
Nel contesto di questo progetto il pattern Adapter viene usato due volte e serve sostanzialmente a nascondere le librerie grafiche utilizzate: Raphael e RaphaelZPD. In questo modo sar`a possibile cambiare la libreria grafica senza dover modificare l’interfaccia che utilizza il Client.
Nella figura 3.4 vengono evidenziate le classi che fungono da Adapter: le classi colorate di blu rap- presentano i target, le classi colorate di rosso rappresentano gli adapter e infine le classi colorate di verde rappresentano gli adaptee.
Figura 3.4: diagramma di utilizzo del pattern Adapter
L’utilizzo di RaphaelAdapter `e necessario per racchiudere la libreria grafica Raphael, che funge da adaptee, e isolarla dal resto dell’applicazione; graphicInterface invece funge da target e definisce un’interfaccia comune per gli adapter che nascondono la libreria grafica. Grazie a questa struttura risulta pi`u facile sostituire la libreria grafica: basta creare un nuovo adapter con i metodi definiti dall’interfaccia.
In modo analogo, il ruolo dell’adapter RaphaelZPDAdapter `e quello di nascondere la libreria Ra- phaelZPD, ovvero dell’adaptee. ZPDInterface ha il ruolo del target e definisce le operazioni che devono essere implementate da RaphaelZPDAdapter.
3.5 Specifica delle Componenti
Contrariamente a quanto fatto per l’analisi dei requisiti, la progettazione `e stata fatta solamente per la componente obiettivo dello step 4 in quanto le componenti degli step precedenti utilizzano parte dell’architettura dell’ultimo step.
Figura 3.5: diagramma rappresentante la divisione delle classi
Nella figura 3.5 viene illustrato il diagramma delle classi; le classi evidenziate in verde rappresentano librerie esterne, ovvero Raphael e RaphaelZPD.
3.5.1 Organigramma
Tipo, obiettivo e funzione del componente
La classe Organigramma ha l’obiettivo di recuperare i dati dal database e costruire un array di ogget- ti Organo per poi far disegnare alla classe RaphaelAdapter l’organigramma corrispondente; la classe gestisce inoltre gli eventi generati dall’utente, come l’over sopra ad un organo o il click su un pulsante.
Relazioni d’uso di altre componenti
Possiede un attributo di RaphaelAdapter, RaphaelZPDAdapter, Menu e un array di oggetti Organo.
Interfacce e relazioni d’uso da altre componenti Nessuna.
Metodi
1. + inserisciOrgano (nome: string, cognome: string , ruolo: string, id: number, padre: number):
void
Metodo che crea un nuovo Organo in base alle informazioni ricevute come parametro e lo memorizza nell’array di Organi della classe Organigramma.
2. + FillData (datasource: object): void
Metodo che recupera i dati memorizzati nel database per poi richiamare, per ogni record, il metodo inserisciOrgano().
3. - aggiungiInfo (shape: object): void
Il metodo crea una dialog con un form per l’inserimento di dati relativi ad un ente come nome, cognome e ruolo. Al click del bottone “Conferma”, rileva i parametri scritti per poi memorizzarli e chiude la dialog. Al click del bottone “Annulla” invece chiude semplicemente la dialog.
4. - visualizzaInfo (shape: object): void
Metodo che crea una dialog per far visualizzare all’utente informazioni aggiuntive riguardanti l’ente selezionato.
5. - aggiungiSubordinato (shape: object): void
Il metodo crea un nuovo subordinato dell’organo passato come parametro. In realt`a il parame- tro passato `e l’organo grafico e non logico; il metodo inizialmente dovr`a quindi trovare l’organo logico corrispondente a quello passato. Dopo aver aggiunto un nuovo subordinato richiama le funzioni refresh() e drawOrganigramma() della classe RaphaelAdapter per cancellare l’area di disegno e ridisegnare l’organigramma.
6. - aggiungiStaff (shape: object): void
Il metodo crea un nuovo organo di staff. Come per il metodo aggiungiSubordinato(), deve prima trovare l’organo logico corrispondente a quello grafico passato per parametro. Creato il nuovo organo cancella l’area di lavoro e ridisegna l’organigramma richiamando le funzioni opportune della classe RaphaelAdapter.
7. - compatta (shape: object): void
Tale metodo imposta l’attributo “compact” dell’organo logico corrispondente all’oggetto pas- sato come parametro e ridisegna l’organigramma secondo le nuove direttive richiamando la funzione drawOrganigramma() della classe RaphaelAdapter.
8. - ridisegna (shape: object): void
Tale metodo imposta l’attributo “autoritario” dell’organo logico corrispondente all’oggetto passato come parametro e ridisegna l’organigramma secondo le nuove direttive richiamando la funzione drawOrganigramma() della classe RaphaelAdapter.
9. - elimina (shape: object): void
Tale metodo elimina l’organo passato come parametro e tutti i suoi subordinati.
10. - isDiscendente (organo1: Organo, organo2: Organo): boolean
Questo metodo restituisce true nel caso il primo organo sia discendente del secondo passato come parametro, false altrimenti. Questa funzione `e utile per le funzioni di eliminazione e di spostamento di un organo.
11. - avvisa (shape: object): void
Questo metodo assegna all’evento “mouseover” di ogni elemento dell’organigramma la ge- nerazione del menu. Inoltre assegna ad ogni “click” di un bottone del men`u la funzione corrispondente da avviare.
12. - cercaPersone (nome: string): void
Il metodo riceve come parametro una stringa e cerca l’organo logico con tale nome, per poi evidenziarlo nella struttura grafica richiamando la funzione opportuna della classe RaphaelA- dapter.
13. - aggiungiPersone (): void
Questo metodo aggiunge ad una select box i nomi di tutti gli enti. Selezionando un nome da questa select box viene richiamato il metodo cercaPersone() per evidenziarne l’organo corrispondente.
14. - sposta (shape: object): void
Questo metodo, richiamato quando si vuole spostare un organo, genera un alert chiedendo la nuova posizione su cui spostare l’organo. Rilevata la nuova posizione richiama il metodo spostaOrgano().
15. - spostaOrgano (shape1: object, shape2: object): void
Il metodo inizialmente fa un controllo sulla nuova posizione che dovr`a assumere l’organo da spostare. Se la nuova posizione risulta essere sottoposta ad un organo di staff o ad un organo su- bordinato dell’organo che si vuole spostare, genera un messaggio di errore. Altrimenti assegna all’organo da spostare il riferimento al nuovo padre e ridisegna l’organigramma richiamando la funzione della classe RaphaelAdapter opportuna.
16. - Init (): void
Questo metodo inizializza gli attributi della classe e viene richiamato dal metodo FillData().
