Corso di Laurea in Ingegneria Informatica anno accademico ...andman83.altervista.org/DocMonIngSW-FaseAnalisi.pdf · Adobe Photoshop 7 Scopo: ... Note positive: Applicazione professionale

Corso di Laurea in Ingegneria Informatica

anno accademico 2006-07

Progetto di ingegneria del software

Sito di anteprima del gioco:

http://andman83.altervista.org

Sito della documentazione del gioco: http://andman83.altervista.org/DocMonIngSW-FaseAnalisi.pdf

http://andman83.altervista.org/DocMonIngSW-Progettazione.pdf http://andman83.altervista.org/DocMonIngSW-Implementazione.pdf

http://andman83.altervista.org/DocMonIngSW-FaseTest.pdf http://andman83.altervista.org/DocMonIngSW-FoglioDiRilascio.pdf

Membri del gruppo: Andrea Mancini Claudio Pulerà Vincenzo ManzellaDaniele Ranaldi

Indice 2 Applicazioni utilizzate 7 Fase di analisi 10 1 Requisiti utente 10 1.1 Specifiche di portata 10 1.2 Specifiche di dettaglio 10 1.3 Specifiche consegnate 10 2 Modellazione del dominio 11 2.1 Analisi del testo 11 2.1.1 Actors 11 2.1.2 Dominio dei dati 11 2.1.3 Requisiti funzionali 11 2.2 Class Diagram di dominio 12 2.3 State Diagram 13 2.4 Use Case Diagram a basso livello 14 2.5 Descrizione Use Case Diagram 15 2.6 Use Case Diagram ad alto livello 15 Pianificazione (Progettazione) 84 1 Pianificazione del progetto 84 1.1 Function point 84 1.1.1 La metodologia 84 1.1.2 Il calcolo 85 1.1.2.1 Dati 86 1.2 COCOMO 88 1.2.1 COCOMO 2 88 1.2.2 Main di COCOMO 2 90 1.2.3 Phases di COCOMO 2 94 1.3 Pert 96 1.3.1 Fase di analisi 96

1.3.2 Fase di progetto 97 1.3.3 Fase di implementazione 97 1.3.4 Fase di test 98 1.3.5 Cammino critico 98 1.3.6 Attività svolte con relativo sforzo 98

1.4 Gantt 100 1.4.1 Diagramma 100 1.4.2 Vincoli del diagramma 101

1.5 Pianificazione individuale 104 1.5.1 Andrea Mancini 104 1.5.2 Claudio Pulerà 104 1.5.3 Vincenzo Manzella 104 Disegno del sistema 105 1 Architettura Hardware 105 1.1 Server 105 1.2 Client 105 1.3 Piattaforma di sviluppo 105 2 Architettura Software 106 3 Progetto della base di dati 107 3.1 Progettazione concettuale 107 3.1.1 Schema ER 107 3.1.2 Scelte critiche effettuate nella fase di progettazione 108 3.2 Progettazione logica 108 3.2.1 Ristrutturazione schema ER 108 3.2.2 Schema ER ristrutturato 109 3.2.3 Schema logico 110 3.2.4 Vincoli esterni 111 3.2.5 Politiche di cancellazione 111 3.2.6 Viste 111 3.3 Glossario 112 3.3.1 Entità 112 3.3.2 Relazioni 113

3.3.3 Attributi 114 3.4 Sorgenti SQL per la creazione del database 114 3.4.1 Creazione del database, tabelle e prepopolamento 115 3.4.2 Vincoli implementati tramite check 126 3.4.3 Vincoli implementati tramite trigger 126 3.4.4 Package diagram 129 4 Prototipazione 139 4.1 Prototipo freddo 139 4.2 Schema di navigazione del sito 140 4.3 Diagramma ADM 141 5 Design model 142 5.1 Implementation model 142 5.1.1 Component diagram 142 5.1.2 Deployment diagram 143 5.2 Domain model 144

5.2.1 Controller – Dao 145 5.2.2 Controller – Dcs 145

5.2.3 Controller – Domain 146 5.2.4 DB 146 5.2.5 Dcs – Domain 147 5.2.6 Jsp – Utility 147 5.2.7 Dao – Domain 148 5.2.8 Jsp – Controller 149 5.2.9 Jsp – Domain 149 5.2.10 Save – Controller 150 5.2.11 Servlet – Controller 151 5.2.12 Servlet – Domain 152 5.2.13 Servlet – Save 152 5.2.14 Servlet – Utility 153 5.2.15 Utility – Domain 153 5.2.16 Utility – Controller 154

5.3 Sequence diagram di dettaglio 155

5.3.1 Regitsrazione 155 5.3.2 Salvataggio 156 5.3.3 Log-in 158

Implementazione 159 1 Introduzione 159 2 Pagine web 159 2.1 Template grafico 159 3 Implementazione 160 3.1 Motivazioni delle scelte generali 160 3.2 Stile 160

3.3 Sfondo 160 3.4 Immagini varie 160 3.5 Scelte implementative 160

4 Problemi riscontrati 161 4.1 HTML e JAVASCRIPT 161 4.2 Eclipse 161 Manuale d’installazione 161 1 Operazioni preliminari 161 1.1 Installazione Java Virtual Machine: JDK 1.6 161 1.2 Installazione DBMS: MySQL 5 161 1.3 Installazione Web Server: Apache TomCat 5.5 163 2 Installazione 163 2.1 Avvio del DBMS 163

2.2 Creazione e popolamento del database 164 2.3 Copia dei contenuti web 165

2.4 Avvio del Web Server 165 2.5 Lanciare applicazione 165 2.6 Primo accesso (Registrazione) 165

3 Utilizzo dell’applicazione 166 Test e validazione 167 1 La fase di test 167 1.1 Tecniche 167 1.2 Strategie 168 1.3 Tool 169 2 Pianificazione ed esecuzione dei test 169 2.1 Piano dei test 170 2.2  Test black box 171 

2.3  Test white box 174 2.4  Note Cactus 181

Foglio di rilascio 183 1 Assessment sul progetto 183 2 Assessment individuale 184

2.1 Andrea Mancini 184 2.2 Claudio Pulerà 185 2.3 Vincenzo Manzella 186

3 Confronto dei risultati 186 Commenti e ringraziamenti 187 1 Fase di analisi 187 2 Fase di pianificazione 187 3 Fase di progetto 187 4 Fase di implementazione 187 5 Fase di test 187 6 Commenti generali 188 7 Ringraziamenti 189

Applicazioni utilizzate Visual Paradigm for UML 6.0

Scopo: Modellazione UML. Note positive: Ottimo ambiente di lavoro completo di ogni tipo di diagramma UML. Offre tool di generazione automatica di codice sorgente e di traduzione automatica da codice al diagramma. Note negative: Richiede un uso spropositato di risorse e con la licenza universitaria si è legati ad avere una connessione internet. Manca nei diagrammi l’implementazione di subset tra relazione, disguinzione tra generalizzazioni

Visual Paradigm SDE 4.0 for Eclipse

Scopo: Modellazione UML integrata all’ambiente di sviluppo. Note positive: Offre completo accesso a tutte le funzionalità di Visual Paradigm e permette di aggiornare immediatamente modifiche emerse dallo sviluppo sul diagramma Note negative: L’elevatissima richiesta di risorse di Visual, aggiunta alle dimensioni di Eclipse, rende il lavoro estremamente lento e quindi spesso evitato.

Microsoft Office 2003 Word Exel PowerPoint

Scopo: Stesura documentazione, diagrammi non previsti da Visual Paradigm (schema ER), fogli elettronici per tabelle.

In aggiunta

Visio 2003 Scopo: Schema di navigazione del sito ADM

Note positive: Suite di programmi semplici da usare completamente integrabili tra di loro, compatibili nei formati e nelle formattazioni. Note negative: Visio rimane inutile perché il diagramma potrebbe essere implementato con PowerPoint che ha più funzionalità

Eclipse 3.2.1

Scopo: Ambiente di sviluppo JAVA e non solo. Note positive: Programmazione assistita con strumenti di segnalazione e correzione di errore, import automatico di librerie, controllo sintattico su tutto il progetto, integrabile con molti plug-in. (Junit, Cactus) e programmi (TomCat, MySQL). Note negative: Ambiente di sviluppo molto pesante per le macchine, difficile portabilità del progetto da una macchina ad un’altra, soprattutto sono stati

riscontrati molti problemi nel associazione con TomCat 5.5/6.0 ed a volte avvisa errori inesistenti sul codice HTML (ad esempio per i tag form).

PlanBee 2.0e

Scopo: Disegno del diagramma Pert. Note positive: Il programma è estremamente intuitivo, veloce e il diagramma che si ottiene è completo di tutte le informazioni ed esportabile come immagini JPG Note negative: Il posizionamento delle attività è obbligato.

GanttProject 2.0.3

Scopo: Disegno dei diagrammi Gantt. Note positive: Semplice da usare, copre aspetti legati anche alla gestione delle risorse, e dei vincoli. Note negative: Non è possibile rappresentare la durata ideale di un progetto, as es: Se il sabato e la domenica vengono impostati come giorni non lavorativi vengono selezionati comunque nella durata del progetto

Paint

Scopo: Aspetti grafici dell’applicazione. Note positive: Facile ed immediato, e molto leggero come applicazione. Note negative: Non adatto per fotoritocchi complessi.

Adobe Photoshop 7

Scopo: Grafica generale del sistema. Note positive: Applicazione professionale di ritocco fotografico.

Adobe Acrobat 7.0

Scopo: Creazione di formati pdf. Note positive: File di piccole dimensioni e con la versione gratuita di Adobe Reader leggibile da tutti i sistemi operativi.

MySQL 5 Scopo: Gestione della base di dati

Note positive: Avviabile a comando (rispetto ad Oracle e MySQL server). Note negative: la relise 5.0.45 ha un bug che non permette di avviare il DB col comando “mysqld –user root”. In Linux (Ubuntu 7.10) è caseSensitive.

MySQL Query Browser

Scopo: Visualizzazione grafica del database Note positive: Utilissimo nel visualizzare modifiche nel database. Note negative: Le cancellazioni effettuate non risultano nel database, sono fittizie.

Macromedia Dreamweaver 8

Scopo: Sviluppo pagine web Note positive: Doppia visualizzazione (grafica + codice) completo di tutto quello che serve per la creazione di un sito web. Note negative: Con tabelle molto grandi è difficile ritrovare errori di tag HTML

Apache Tomcat 5.5 / 6.0

Scopo: Simulazione di web server Note positive: Permette di testare la propria applicazione web senza inviare i file al server Note negative: Incompatibilità con Window Vista

Fase di analisi 1 Requisiti utente 1.1 Specifiche di portata

Il progetto consiste nel permettere di giocare al famoso gioco da tavola “Monopoli” via Web, permettendo ad amici o sconosciuti, lontani e vicini di giocare comodamente ognuno a casa propria o ovunque si abbia una connessione ad internet.

1.2 Specifiche di dettaglio

L’architettura del sistema prevede un Web Server centrale che unisca le connessioni dei vari Clients in partite di Monopoli, mantenendo i dati di ogni partita salvata e i vincitori di ogni partita conclusa nel proprio database. 1.3 Specifiche consegnate Si vuole realizzare un sito internet per giocare a Monopoli on-line. Ogni utente interessato a giocare a monopoli è tenuto ad registrarsi inserendo: Nome, cognome,data di nascita, e-mail, nick e password. Tali utenti per giocare dovranno entrare in una partita. Il giocatore entrato in partita dovrà scegliere una pedina. Il primo giocatore decide l’inizio della partita, e dovrà attendere almeno l’ingresso di un secondo giocatore. Il gioco si svolge su un tabellone composto da 40 caselle che sono percorribili tirando i dadi, in ogni casella il giocatore può o deve effettuare determinate azioni, compra-vendita di contratti ed edifici, pagamento tasse, ecc. Un giocatore per acquistare un contratto inerente ad un territorio dovrà, col tirare i dadi, sostare sopra la casella del territorio stesso, dove questa opzione è possibile, e per edificarci dovrà aver acquistato tutti i contratti(territori) dello stesso colore. Quando un giocatore arriva su una casella imprevisti o probabilità dovrà pescare una carta ed attenersi alle istruzioni scritte su di essa. Ogni giocatore riceverà ad inizio partita dalla banca una somma di denaro (soldi monopoli o euro) che dovrà gestirsi in tutta la partita per non andare in fallimento. Se un giocatore si ferma su una casella territorio che è già in possesso di un altro giocatore, dovrà pagare a quest’ultimo una somma di pedaggio che, in presenza di edifici(case o albergo), sarà moltiplicata a seconda di quanti ne sono costruiti sul territorio. Un contratto può essere scambiato tra due giocatori tramite una trattativa.

Un giocatore in carenza di denaro può vendere i propri edifici, oppure ipotecare un territorio ma solo dopo aver già venduto tutti gli edifici sullo stesso. Un giocatore può uscire dalla partita in qualsiasi momento e tutti contratti in suo possesso verranno riconsegnati direttamente alla banca rendendoli nuovamente disponibili. Un giocatore perde se non ha più la possibilità di pagare.

2 Modellazione del dominio L’analisi del dominio è stata articolata in due livelli secondo ordini diversi di granularità. Lo scopo è quello di individuare nel primo approccio le funzionalità di base del sistema in modo tale da dare all’utente un’idea chiara sui servizi che gli vengono messi a disposizione, e nel passo successivo, entrare nel dettaglio nella descrizione di funzioni e dati. 2.1 Analisi del testo

L’analisi del testo è un lavoro di ispezione, condotto sulla specifica di portata, per individuare gli attori e le funzionalità di riferimento del sistema. Con queste informazioni inizia l’attività di modellazione del dominio

2.1.1 Actors

Utente: L’utente è quel cliente che accede al sito web. Può solo registrarsi, loggarsi, visualizzare le partite in attesa e salvate e visualizzare la classifica generale. Giocatore: Il giocatore è quell’utente che è entrato in una partita e utilizzare a pieno le funzionalità del sito.

2.1.2 Dominio dei dati

Le principali strutture dati emerse dall’analisi che caratterizzano il dominio di applicazione sono:

Partita: La partita è la struttura principale dell’applicazione e comprende il 90% dell’utilizzo del sito Sala d’attesa: Mantiene traccia delle partite in attesa e delle partite salvate

2.1.3 Requisiti funzionali Le principali funzionalità esportate dal sistema sono:

Crea/Partecipa/Ripristina partita: E’ la prima funzione importante che si incontra nell’applicazione, ti permette di creare, partecipare e ripristinare una partita

Tira dadi: E’ la funzione che ti permette di muovere la tua pedina sul tabellone

Trattativa: E’ la funzione che ti permette di scambiare territori con gl avversari Territori: E’ la funzione che ti permette di visualizzare i territori di una pedina

Salva: E’ la funzione che ti permette di salvare la partita in corso per poi finirla in un secondo tempo

Ritirati: E’ la funzione che ti permette di ritirarti ed abbandonare la partita

Classifica generale: E’ la funzione che ti permette di visualizzare i punteggi più alti ottenuti dai vincitori delle partite già concluse

2.2 Class Diagram di dominio

Il Class Diagram è un diagramma strutturale della famiglia dei diagrammi UML, che modella la rappresentazione e l’organizzazione degli elementi del dominio di analisi in termini di oggetti. Il diagramma si concentra non tanto sulle singole istanze, quanto sulle classi di dominio, che rappresentano insiemi di oggetti omogenei e sulle quali è possibile esprimere proprietà locali attraverso gli attributi. Le proprietà che coinvolgono più di una classe sono invece modellate dalle associazioni o relazioni che, a livello formale, rappresentano delle relazioni matematiche e sono quindi sottoinsiemi del prodotto cartesiano tra le classi su cui insistono. Di seguito viene presentato il class diagram di dominio:

2.3 State Diagram

Il diagramma degli stati e delle transizioni viene definito per una classe, ed intende descrivere l’evoluzione di un generico oggetto di quella classe. Il diagramma rappresenta le sequenze di stati, le risposte e le azioni, che un oggetto attraversa durante la sua vita in risposta agli stimoli ricevuti. Uno stato rappresenta una situazione in cui un oggetto ha un insieme di proprietà considerate stabili. Una transizione modella un cambiamento di stato. Di seguito descriviamo lo state diagram della classe Contratto come esempio essendo l’unica classe che subisce il cambiamento di stato

2.4 Use Case Diagram a basso livello Il diagramma degli use case illustra le funzionalità fondamentali che il sistema deve realizzare, in termini dei suoi scenari di utilizzo. Uno use case rappresenta tipicamente una interazione tra l’utente ed il sistema. Ogni use case è collegato agli utenti (actor) addetti all’utilizzo e ad eventuali altri casi d’uso con cui è relazionato (generalization, extend, include). Il diagramma in sé è un ottimo strumento di raccordo tra l’analista e il committente, ma di fatto non ci dice molto sulle caratteristiche del sistema, se non un’idea di massima sui suoi servizi offerti e da chi sono fruibili. Il punto chiave del diagramma sono le descrizioni degli use case. In queste vengono spiegate cosa fanno le operazioni previste, come deve avvenire l’interazione tra l’utente e il sistema e quali sono le principali eccezioni allo scenario principale.

2.5 Descrizione Use Case Diagram Le descrizioni dei casi d’uso devono necessariamente restare in questa fase su un livello abbastanza generico. Questo significa descrizioni corpose nel campo “brief description”, un “main success scenario” fitto di botta-risposta tra utente e sistema ma con degli input e degli output che ancora con riflettono lo schema preciso di presentazione dei dati. Si è cercato poi di lavorare molto sul campo “extensions” per cogliere almeno le più importanti tra le molte eccezioni allo scenario principale. Lo scopo delle prossime fasi sarà proprio quello di entrare nel dettaglio delle descrizioni, snellire lo scenario di successo e specializzare le interazioni tra utente e sistema.

2.6 Use Case Diagram ad alto livello Siamo arrivati al massimo livello di granularità in cui tutti i casi d’uso sono completamente spacchettati. Il diagramma si ramifica andando da un livello astratto ad uno sempre più preciso fino ad avere sulle foglie le funzionalità più elementari. L’obiettivo è quello di impostare l’architettura del sistema con un approccio button-up, in cui le funzionalità complesse vengono viste e trattate come una composizione di funzioni elementari in modo da avere un basso accoppiamento ed una buona modularità. La struttura aiuta poi la pianificazione del progetto ed il calcolo dei function point perché si evita di avere a che fare con operazioni troppo corpose in cui è spesso difficile cogliere tutte le microfunzionalità.