SoftEngUniNA S.p.A.

______________________________ ENTE/I: Facolt di Scienze PROTOCOLLO N.: Uni-789-2011 DATA EMISSIONE: 01/11/2011 PAG. 1/51

PIANO ATTIVITA PIANO OPERATIVO REPORT ATTIVITA ( INTERMEDIO

DOCUMENTO DI DESIGN DOCUMENTO DI TESTING DEL SISTEMA INFORMATIVO Risiko2012 FINALE X)

OGGETTO:

Piano Attivit Fornitori Esterni

Specifica e progettazione del Sistema Informativo Risiko2012 SINTESI DEI CONTENUTI: Il Piano si riferisce alle attivit di progetto da effettuare nellambito del corso di Ingegneria del Software del servizio informativo Risiko2012 Il piano contiene le seguenti linee di attivit: Documenti di Design del Sistema Informativo Risiko2012: -Analisi dell'Architettura del Sistema -Class Diagram Ristrutturati -Sequence Diagram Ristrutturati -Statechart Diagram Ristrutturato -CRC Cards -Diagramma di Gantt Documenti di testing del Sistema Informativo Risiko2012: -Test case -Codice JUnit

1REVISIONI
Data 01/11/10 15/11/11 22/11/11 29/11/11 06/12/11 20/12/11 Versione 0.1 0.2 0.3 0.4 0.5 0.6 Autore Sangiovanni Peron/Sangiovanni Peron Peron Peron Peron Descrizione Nuova
Assegnazione Funzionalit del Sistema

Presentazione Mockup Revisione Mockup e presentazione Use Case Diagram Revisione Use Case Diagram Presentazione Class Diagram,Sequence Diagram,Activity Diagram e Statechart Diagram

DEFINIZIONE DELLARCHITETTURA
Individuazione componenti fondamentali: FUNZIONALI Utilizzo da browser :trattandosi di un applicazione BROWSER-BASED ,il fulcro dellarchitettura di questo progetto consiste nel servire allutente finale uninsieme di pagine web che gli permettono,attraverso il proprio web browser ,di interagire con le dinamiche di gioco,si rivela quindi indispensabile limpiego di un web server in grado di gestire pagine dinamiche. Persistenza: i meccanismi alla base di questo genere di giochi sfruttano scale temporali molto dilatate :levoluzione di singoli utenti e del mondo nel quale interagiscono si sviluppano nel corso di mesi .Queste modifiche e cambiamenti devono pertanto essere permanenti e non ristretti alla singola sessione di gioco;vista la grande mole di utenti impegnati contemporaneamente in questa attivit ,la soluzione pi adatta a mantenere lo stato globale dellapplicazione consiste nellutilizzo di un motore database. User experience : per garantire allutente finale un certo livello qualitativo nellinterazione con le pagine che compongono lapplicazione e per gestire le fasi di gioco troppo dinamiche per coinvolgere ROUND-TRIP con il server , opportuno basare parte delle componenti dellinterfaccia utente su tecnologie che agiscono lato client. NON FUNZIONALI Vi sono requisiti non funzionali che influiscono direttamente sulla struttura dellapplicazione ,i pi significativi da un punto di vista architetturale sono i seguenti: indipendenza tra i tier: per non ostacolare evoluzioni future del progetto in direzioni diverse da quelle iniziali, importante che vi sia un basso accoppiamento tra i vari strati che compongono lintera applicazione in particolare tra la business logic e il presentation layer non solo in termini di moduli software ma anche da un punto di vista fisico e tecnologico. Ad esempio non escluso che si desideri in seguito fornire agli utenti la possibilit di accedere al gioco attraverso altre piattaforme come mobile clients. scalabilit : RISIKO implica di per se una struttura di gioco che accoglie un numero sensibile di giocatori ,nellordine delle migliaia. Per far fronte a unimportante mole di accessi si richiede allarchitettura alla base del gioco stesso di essere molto scalabile,in grado cio di sopperire ad eventuali insufficienze prestazionali semplicemente aumentando il numero di server coinvolti. Con un buon livello di indipendenza tra i tiers,inoltre,linvestimento di nuove risorse risulta pi efficace perch maggiormente mirato sui punti deboli del sistema. Robustezza: larchitettura del sistema deve prevedere che intervengano

malfunzionamenti di vario genere ,dai problemi hardware ai bug software. A fronte di tali avvenimenti,il software deve essere strutturato in modo da minimizzare le ripercussioni sugli utenti finali, notificando lutente in modo chiaro e non allarmante mantenendo uno stato globale di gioco sempre consistente ed evitando grosse perdite di informazioni. Performance: in un contesto che prevede grosse moli di richieste al sever,anche il pi piccolo utilizzo di porzioni di memoria o cicli di cpu per il rendering di una pagina pu avere ripercussioni decisamente sensibili nel complesso;le varie componenti che agiscono lato server,pertanto,devono essere ottimizzate il pi possibile e utilizzare il minimo indispensabile delle risorse. Manutenibilit: ciascun modulo che compone lapplicazione devessere facilmente modificabile ,sia per la correzione di bug,sia per laggiunta di nuove funzionalit .Risulta quindi consigliabile che gli svariati elementi simili(pagine,stili,oggetti che espongono le informazioni dal database,etc.)siano strutturati in modo da fornire un punto condiviso per apportare le modifiche. Per definire un punto di abbozzo dellarchitettura si tenuto in maggior conto soprattutto il rispetto dei primi due vincoli non funzionali ,ovvero lindipendenza tra i tiers e la scalabilit. Gli elementi che compongono sono stati scomposti come segue: 1)Database: per la persistenza dei dati; 2)Data Access Layer:che funge da wrapper per le informazioni presenti nel database; 3) Business Logic Layer: si occupa della gestione dei meccanismi di gioco; 4)Un insieme di Web Services che espongono le interazioni e le informazioni elaborate dal livello responsabile delle business rules; 5)un Web Server per rendering delle pagine web inviate allutente,che compongono le fondamenta del Presentation Layer. Un ulteriore porzione di presentation layer realizzato con tecnologie che agiscono lato client. In figura rappresentato uno schema riassuntivo di come queste componenti sono distribuite e del modo in cui interagiscono tra loro

CLIENT

WS

BL

DAL

DB

lato client

WEB SERVER

lato server

Fig - Prima Soluzione Architetturale -

I Web Services costituiscono un passaggio obbligato tra il web server (responsabile delle pagine dinamiche ) e la logica dellapplicazione. Questo vincolo presenta alcuni indubbi vantaggi: permette di ottenere un elevatissimo grado di disaccoppiamento tra la logica di Business e la componente di presentazione ,rendendo possibile linterazione con le dinamiche di gioco da parte di qualsiasi client tramite web application. Tuttavia,introduce numerosi problemi,tra cui: pesante impatto sulle performance: per qualsiasi architettura anche la pi semplice,alla di business,il motore di rendering delle pagine dinamiche costretto a interagire il WEB-SERVICE relativo,se questo si trova addirittura su unaltra macchina,le prestazioni precipitano enormemente a causa delle comunicazioni via rete e dellhoverhead introdotto dal protocollo SOAP . necessit di authorization:dal momento che le richieste al Web Services possono provenire sia dal Web Server sia dagli script lato client ,oltre che da potenziali client alternativi, necessario discernere quali Web Methods richiedono particolari autorizzazioni per poter essere eseguiti. Risulta quindi pi ragionevole che il motore di rendering delle pagine dinamiche abbia accesso diretto alla logica di business , e sia affiancata da Web Services per alcune interazioni lato client e per le simulazioni pi dinamiche. Vi un altro insieme di considerazioni che riguardano linterazione tra le logiche di business e la base di dati. Collocazione delle besuness rules : innanzitutto , non facile tracciare una linea di demarcazione netta tra quali siano le regole di business che riguardano prevalentemente lintegrit e la coerenza dei dati e,quali invece agiscono in maniera pi astratta sulle dinamiche di funzionamento del gioco stesso .In altre parole, non sempre risulta semplice scegliere se una particolare regola trovi collocazione ottimale allinterno del database ,sotto forma di trigger o stored procedure ,oppure nel modello ad oggetti della logica di business. Molteplicit delle entit coinvolte : nella maggior parte dei casi un singolo avvertimento o interazione con la logica di funzionamento del gioco corrisponde alla modifica di numerosi record appartenenti a realt diverse .Se effettuata a livello di modello ad oggetti la propagazione di queste modifiche diviene molto complessa,soggetta ad errori e soprattutto molto poco performante. Decidendo di supportare parzialmente queste modifiche attraverso la programmazione interna al database ci si ritrova al problema precedente ovvero lo stabilire quale sia il limite ideale tra logica di business e integrit dei dati. Scarsa robustezza: pi le logiche di funzionamento sono distanti dalla base di dati,minore la robustezza dellapplicazione,se le informazioni vengono persistite su database solo alla fine dei processi di gestione della logica di business ,un malfunzionamento del server pu causare un rollback di dimensioni molto consistenti.

Transazioni: vi sono molte operazioni che richiedono atomicit nellessere eseguite ,garantire transazionalit operando a livello di database relativamente semplice,mentre nel caso di modello ad oggetti pu essere molto problematico. Concorrenza: come per la transazionalit ,anche la concorrenza un fattore molto pi semplice da gestire attraverso il motore database piuttosto che col modello ad oggetti,dove le operazioni multithreaded e multiutente possono compromettere rapidamente la consistenza delle informazioni. Risulta conveniente spostare la logica di business direttamente allinterno del database Programmare le dinamiche di gioco utilizzando triggers e stored procedure risulta sicuramente pi complesso rispetto al modello ad oggetti ma permette di allocare livelli di performance ,robustezza,coerenza,transazionalit e gestire degli accessi decisamente molto superiori. La prossima componente da definire ed analizzare il DATA ACCESS LAYER: infatti a questo modulo che spetta il compito di fare da parte tra il mondo relazionale,cio quello dei dati strutturati e gestiti dal DBMS e quello orientato agli oggetti ,ovvero linsieme di classi che compongono il presentation tier. Con lo spostamento della business logic allinterno della base di dati,cambia in parte il ruolo svolto dal DAL ,o perlomeno la sua connotazione. In un primo momento ,secondo labbozza iniziale di architettura dellapplicazione ,il DAL doveva svolgere il ruolo tramite tra BL e lo schema interno del DataBase. Da un punto di vista maggiormente diretto ,in sostanza i compiti del DAL sarebbero stati fondamentalmente due: Lettura : dei dati provenienti dal DB e conseguentemente istanzi azione e inizializzazione di oggetti che modellano in maniera astratta le dinamiche di gioco,contenenti numerosi metodi per il rispetto delle logiche di business. Persistenza: su database degli oggetti di business una volta completata lesecuzione delle business rules prendendosi carico direttamente dei problemi legati alla validazione dei dati alla consistenza ,alla transazionalit e aggiornando gli oggetti con i valori creati o modificati sulla base di dati in seguito agli ultimi aggiornamenti. A meno di complicare ulteriormente la parte di DB ,il DAL necessita di una lista di personalizzazione delle singole classi che lo compongono. Lo spostamento delle logiche di business allinterno del database permette invece di approcciarsi alla componente di accesso di dati in modo molto pi semplice e standardizzato.

Su di essa gravano sempre i compiti di lettura e scrittura sulla base di dati,ma assumono in questo caso una connotazione decisamente diversa: la lettura dei dati pu sintetizzare le informazioni provenienti dalla base di dati in semplici data-objects,oggetti che espongono pubblicamente e in maniera tipizzata i valori dei singoli record. Linterazione con le dinamiche di gioco pu avvenire mediante un ristretto numero di metodi pubblici che permettono di dialogare con il ben pi semplice schema esterno del database(chiamando ad esempio le relative stored procedures o modificando viste aggiornabili) Tale esterma semplificazione data dal fatto che non vi pi la necessit di incontrare lapplicazione dei meccanismi di gioco sui data-objects,appesantendoli con grossi vincoli ,validazione modifiche a catena e via dicendo il ruolo si trasforma in una sorta di wrapper per lo schema esterno del database ad uso e consumo del presentation layer. In questo modo , possibile la standardizzare naturalmente la struttura dei dataobjects,fino alla definizione attraverso code.generation,decisamente conveneiente in questo progetto. Adesso possiamo passare alla definizione dei requisiti per le due categorie principali che compongono il Data Access Layer : il data object che stabiliscono dei Mapping tra lo schema esterno del DB ed presentation layer,ed il gestore del dialogo col database ,che si occupa del dialogo vero e proprio con il DBMS,eseguendo query e comandi SQL. DATA OBJECT Meccanismi di security: importante limitare laccesso alle informazioni ed alle informazioni ai soli utenti autorizzati ,si desidera pertanto che i meccanismi di security siano implementati gi a questo livello piuttosto che a livello di interfaccia utente. Meccanismi di caching: date le altissime probabilit che svariate informazioni provenienti dal database sono riutilizzabili pi volte, indispensabile ai fini delle performance che i data object prevedano meccanismi di caching. Compatibilit con i controlli offerti dal presentation layer: senza dubbio la piattaforma scelta per il rendering delle pagine dinamiche offrir alcuni controlli per la rappresentazione dei dati, opportuno che i data object vengano progettati fin da subito in un ottica di compatibilit con tali strumenti. Interazione automatizzata con il database : almeno per le modifiche pi semplici ,come ad esempio il cambiamento di un valore ,si desidera che i dataobjects gestiscano in maniera automatica la propagazione di tali aggiornamenti sulla base di dati.

Gestione autonoma delle eccezioni : gli errori generati dalla logica di business ,che si tratti di problemi interni o rifiuti di operazioni non valide ,devono filtrare al layer successisottoforma di eccezioni ben tipizzate che espongano il problema in maniera user-friendly(e senza esporre dettagli interni). Estensibilit: deessere possibile laggiunta di nuovi behavier alle singole classi senza che questo interferisca con il loro normale funzionamento di data-objects. Utilizzabili da Java-Script: le informazioni cos strutturate devono essere fruibili nel modo pi semplice possibile anche da codice Java Script lato client. Autogenerazione : se possibile, lautogenerazione dei data-objects garantirebbe enormi risparmi di tempo in fase di generazione e manutenzione di queste classi.dal momento che lo spostamento della logica di business allinterno del DB semplifica e standardizza notevolmente la struttura dei data-object, fortemente indicato lo sviluppo di un tool per la code generation. Type-safe: le informazioni organizzate nei data-object devono essere fortemente tipizzate ed avvicinarsi il pi possibile al relativo SQL Type. Performance : vista la mole dei dati da trattare assolutamente prioritario che i data object progettati consumino il minimo indispensabile delle risorse. La connessione al database deve essere mantenuta aperta solo per lo stretto necessario affinch sia possibile leggere i dati ,eseguire comandi. La composizione dei data-object deve evitare lutilizzo di oggetti pesanti,e minimizzare loccupazione di RAM. GESTORE DATABASE Integrazione efficiente con i data-object: il gestore dellinterazione con il database devessere in grado di generare data-object senza che vi sia la necessit per gli utilizzatori di specificare informazioni relative a query da effettuare. MODULO SIMULAZIONE Rappresenta quasi una realt a se stante allinterno del progetto. Con questo termine,sintende la componente responsabile di gestire i meccanismi di gioco pi dinamici,che presentano tempistiche troppo rapide o aggiornamenti troppo frequenti per essere inglobati efficacemente nella BUSINESS LOGIC contenuta nella base di dati. Ne costituiscono un esempio calzante le simulazioni degli scontri tra armate,la loro gestione separata consigliabile per una serie di motivi: -sono soggette a moltissime trasformazioni anche computazionalmente impegnative ,nellarco di poco tempo .La loro gestione a livello di basi di dati risulta molto complicata e decisamente poco performante; -le simulazioni si svolgono a finestre temporali ridotte e non hanno un senso compiuto se non alla fine dellintero processo.

Persistere i dati intermedi ,oltre che molto oneroso in termini di performance,risulta inutile. -in caso di simulazioni a pi stadi, in cui previsto lintervento dellutente,il modulo si pu interfacciare direttamente con lesterno attraverso il Web server e non ha bisogno di compiere tutto il percorso attraverso DAL e presentation layer. -i modelli di simulazione sono soggetti a cambiamenti e aggiornamenti molto pi frequenti rispetto alla strutturazione dei dati ed il resto delle logiche di business. Innanzitutto i moduli di simulazione devono essere accessibili direttamente dal presentation layer ,sia lato server per il rendering delle pagine e le interazioni pi profonde sia lato client per le chiamate e aggiornamenti pi superficiali in modo pi versatile per ottenere questi risultati consiste nellutilizzo del WebServices. GESTORE SECURITY Laccesso ai metodi che compongono questi moduli deve essere ristretto ai soli utenti autorizzati in quel particolare contesto ; indispensabile quindi che questa componente implementi al suo interno dei meccanismi di security. Per ogni simulazione il modulo effettuer soltanto due comunicazioni con le basi di dati :una lettura allavvio per inizializzare le realt che intervegano nel modello,ed una alla fine per aggiornare le entit coinvolte con le modifiche derivanti dalla simulazione. Lunione delle fasi intermedie simulate,invece,dev essere propagato al client affinch possa presentare allutente una rappresentazione completa dello scontro. Quindi di seguito rappresentata la nuova configurazione architetturale del progetto:

CLIENT

WS

MODULO SIM BL

WEBSERVER Lato Client Lato Server

DAL DB

CLASS DIAGRAM E SEQUENCE DIAGRAM RISTRUTTURATI (CREAZIONE NUOVA PARTITA)

(PARTECIPAZIONE E CARICAMENTO PARTITA)

(DISPONI ARMATE)

(FASE DI ATTACCO)

(INVIA MESSAGGIO)

(PASSA TURNO)

(SALVA PARTITA)

STATECHART RISTRUTTURATO:

CRC CARDS CREAZIONE NUOVA PARTITA Component Creazione Partita SuperClasse: SottoClasse: Pulsante,Tabella Responsabilit
Esegue azione collaboratore richiesta da un

Collaboratori
Form Imposta Parametri Partita

Pulsante SuperClasse: Component Creazione Partita SottoClasse: Responsabilit

Aziona un comando richiesto

Collaboratori

Tabella SuperClasse: Component Creazione Partita SottoClasse: Responsabilit

Visualizza tabella

Collaboratori

Form Imposta Parametri Partita SuperClasse: SottoClasse: Responsabilit

Visualizza Form Insersce dati nel Form Mostra Campi del Form Aggiunge e rimuove nuove componenti al Form

Collaboratori
Controllo Creazione Nuova Partita Component Creazione Partita

Controllo Creazione Nuova Partita SuperClasse:

SottoClasse: Responsabilit
Effettua controlli sulla nuova partita

Collaboratori
Controllo Correttezza Dati Controllo Mappa Form Imposta Parametri Partita Modulo Persistenza Dati Form Partita Gi Presente

Controllo Correttezza dati SuperClasse: SottoClasse: Responsabilit

Verifica la validit dei dati

Collaboratori
Messaggio Errore Controllo Creazione Nuova Partita

Controllo Mappa SuperClasse: SottoClasse: Responsabilit

Verifica la disponibilit della Mappa

Collaboratori
Google Maps Server Form Mappa Non Disponibile Mappa Controllo Creazione Nuova Partita

Modulo Persistenza Dati SuperClasse: SottoClasse: Responsabilit

Gestione dei dati del Sistema

Collaboratori
Controllo Creazione Nuova Partita Mappa Partita Proprietario

Form Partita Gi Presente SuperClasse: SottoClasse: Responsabilit

Visualizza messaggio

Collaboratori
Controllo Creazione Nuova Partita

Messaggio Errore SuperClasse: SottoClasse:

Responsabilit
Visualizza messaggio errore

Collaboratori
Controllo Correttezza Dati

Google Maps Server SuperClasse: SottoClasse: Responsabilit

Mette eventualmente a disposizione la mappa di gioco

Collaboratori
Controllo Mappa

Form Mappa Non Disponibile SuperClasse: SottoClasse: Responsabilit

Visualizza Messaggio

Collaboratori
Controllo Mappa

Mappa SuperClasse: SottoClasse: Responsabilit

Contiene i dati relativi alla mappa di gioco

Collaboratori
Controllo Mappa Modulo Persistenza Dati Territorio Armata Partita

Partita SuperClasse: SottoClasse: Responsabilit

Contiene i dati relativi alla partita

Collaboratori
Proprietario Mappa Modulo Persistenza Dati

Armata SuperClasse: SottoClasse: Responsabilit

Contiene i dati relativi alle armate Proprietario Mappa

Collaboratori

Territorio SuperClasse: SottoClasse: Responsabilit

Contiene i dati relativi al territorio Proprietario Mappa

Collaboratori

Proprietario SuperClasse: SottoClasse: Responsabilit

Contiene i dati relativi al proprietario

Collaboratori
Component Creazione Partita Armata Territorio Modulo Persistenza Dati

CARICAMENTO E PARTECIPAZIONE PARTITA Component Partecipazione e Caricamento Partita SuperClasse: SottoClasse: Pulsante ,Tabella Responsabilit
Esegue azione collaboratore richiesta da un

Collaboratori
Elenco Partite Create Elenco Partite Salvate

Pulsante SuperClasse: Component Partecipazione e Caricamento Partita SottoClasse: Responsabilit Collaboratori

Aziona un comando richiesto

Tabella SuperClasse: Component Partecipazione e Caricamento Partita SottoClasse: Responsabilit Collaboratori

Visualizza tabella

Elenco Partite Create SuperClasse: SottoClasse: Responsabilit

Visualizza elenco partite create
Component Partita

Collaboratori
Partecipazione e Caricamento

Controllo Partecipazione Partita

Controllo Partecipazione Partita SuperClasse: SottoClasse: Responsabilit

Effettua controlli della partita sulla partecipazione

Collaboratori
Elenco Partite Create Controllo Mappa Messaggio massimo numero di giocatori raggiunto

Modulo Persistenza Dati Partita

Messaggio Numero Massimo Giocatori Raggiunto SuperClasse: SottoClasse: Responsabilit

Visualizza messaggio

Collaboratori
Controllo Partecipazione Partita

Modulo Persistenza Dati SuperClasse: SottoClasse: Responsabilit

Gestisce i dati del Sistema

Collaboratori
Controllo Caricamento Partita Controllo Partecipazione Partita Partita Mappa Giocatore

Controllo Caricamento Partita SuperClasse: SottoClasse: Responsabilit

Gestisce i controlli relativi al caricamento della partita

Collaboratori
Elenco Partite Salvate Controllo Mappa Modulo Persistenza Dati Form Visualizzazione Errore

Elenco Partite Salvate SuperClasse: SottoClasse: Responsabilit

Visualizza elenco partite salvate
Component Partita

Collaboratori
Controllo Caricamento Partita
Partecipazione e Caricamento

Form Visualizzazione Errore SuperClasse: SottoClasse: Responsabilit

Visualizza messaggio di errore

Collaboratori
Controllo Caricamento Partita

Google Maps Server

SuperClasse: SottoClasse: Responsabilit

Mette eventualmente a disposizione la mappa di gioco

Collaboratori
Controllo Mappa

Form Mappa Non Disponibile SuperClasse: SottoClasse: Responsabilit

Visualizza Messaggio

Collaboratori
Controllo Mappa

Mappa SuperClasse: SottoClasse: Responsabilit

Contiene i dati relativi alla mappa di gioco

Collaboratori
Controllo Mappa Modulo persistenza Dati Territorio Armata Partita

Controllo Mappa SuperClasse: SottoClasse: Responsabilit

Verifica la disponibilit della Mappa

Collaboratori
Google Maps Server Form Mappa Non Disponibile Mappa Controllo Partecipazione Partita

Partita SuperClasse: SottoClasse: Responsabilit

Contiene i dati relativi alla partita

Collaboratori
Giocatore Mappa Modulo Persistenza Dati Controllo Partecipazione Partita

Armata SuperClasse: SottoClasse:

Responsabilit
Contiene i dati relativi alle armate Giocatore Mappa

Collaboratori

Territorio SuperClasse: SottoClasse: Responsabilit

Contiene i dati relativi al territorio Giocatore Mappa

Collaboratori

Giocatore SuperClasse: SottoClasse: Responsabilit

Contiene i dati relativi al giocatore
Component Partita

Collaboratori
Partecipazione e Caricamento

Armata Territorio Modulo Persistenza Dati

DISPOSIZIONE INIZIALE ARMATE Component Disposizione Armate SuperClasse: SottoClasse: Pulsante,Tabella,Indicatore,Tasto pi,Tasto meno,Display Responsabilit Collaboratori
Esegue azione collaboratore richiesta da un Menu giocatore

Pulsante SuperClasse: Component Disposizione Armate

SottoClasse Responsabilit
Aziona un comando richiesto

Collaboratori

Tabella SuperClasse: Component Disposizione Armate SottoClasse Responsabilit

Visualizza tabella

Collaboratori

Indicatore SuperClasse: Component Disposizione Armate SottoClasse Responsabilit

Incrementa /decrementa le armate sulla mappa Tasto pi Tasto meno Display

Collaboratori

Tasto pi SuperClasse: Component Disposizione Armate SottoClasse Responsabilit

Incrementa le armate sulla mappa Indicatore

Collaboratori

Tasto meno SuperClasse: Component Disposizione Armate SottoClasse Responsabilit

Decrementa le armate sulla mappa Indicatore

Collaboratori

Display SuperClasse: Component Disposizione Armate SottoClasse Responsabilit

Display indicatore armate Indicatore

Collaboratori

Menu Giocatore SuperClasse: SottoClasse Responsabilit

Visualizza menu giocatore

Collaboratori
Component Disposizione Armate Controllo Disposizione Armate

Controllo Disposizione Armate

SuperClasse: SottoClasse Responsabilit

Effettua controlli sulla disposizione delle armate

Collaboratori
Menu Giocare Messaggio Disponi Armate Form numero armate insufficienti Modulo persistenza dati

Messaggio disponi armate SuperClasse: SottoClasse Responsabilit

Visualizza messaggio

Collaboratori
Controllo disposizione armate

Form numero armate insufficienti SuperClasse: SottoClasse Responsabilit

Visualizza messaggio

Collaboratori
Controllo disposizione armate

Mappa SuperClasse: SottoClasse: Responsabilit

Contiene i dati relativi alla mappa di gioco

Collaboratori
Modulo Persistenza Dati Territorio Armata Partita

Partita SuperClasse: SottoClasse: Responsabilit

Contiene i dati relativi alla partita

Collaboratori
Giocatore Mappa Modulo Persistenza Dati

Armata SuperClasse: SottoClasse: Responsabilit

Contiene i dati relativi alle armate Giocatore Mappa Territorio

Collaboratori

Territorio SuperClasse: SottoClasse: Responsabilit

Contiene i dati relativi al territorio Giocatore Mappa Armata

Collaboratori

Giocatore SuperClasse: SottoClasse: Responsabilit

Contiene i dati relativi al proprietario

Collaboratori
Component Disposizione Armate Armata Territorio Modulo Persistenza Dati Partita

Modulo Persistenza Dati SuperClasse: SottoClasse: Responsabilit

Gestione dei dati del Sistema

Collaboratori
Controllo Disposizione Armate Mappa Partita Giocatore

FASE DI ATTACCO Component Attacco SuperClasse: SottoClasse: Pulsante,tabella,display risultati,territorio origine,territorio Destinazione,selezionatore dado Responsabilit Collaboratori
richiesta da un Menu attacco Form lancia dadi

Esegue azione collaboratore

Pulsante SuperClasse: Component attacco SottoClasse: Responsabilit

Aziona un comando richiesto

Collaboratori

Tabella SuperClasse: Component attacco SottoClasse: Responsabilit

Visualizza tabella

Collaboratori

Display risultati SuperClasse: Component attacco SottoClasse: Responsabilit

Visualizza i risultati

Collaboratori

Territorio Origine SuperClasse: Component attacco SottoClasse: Responsabilit

Visualizza i territori origine

Collaboratori

Territorio Destinazione SuperClasse: Component attacco SottoClasse: Responsabilit Collaboratori

Visualizza territori destinazione

Selezionatore dado SuperClasse: Component attacco SottoClasse: Responsabilit

Seleziona un dado da lanciare

Collaboratori

Menu attacco SuperClasse: SottoClasse: Responsabilit

Visualizza menu attacco

Collaboratori
Component attacco Controllo Attacco

Form lancia Dadi SuperClasse: SottoClasse: Responsabilit Collaboratori

Visualizza form lancia dadi

Component attacco Controllo Attacco

Controllo attacco SuperClasse: SottoClasse: Responsabilit

Effettua controlli sulla fase di attacco

Collaboratori
Form lancia dadi Menu attacco Punteggio avversario Modulo persistenza dati

Punteggio Avversario SuperClasse: SottoClasse: Responsabilit

Contiene il dallavversario punteggio ottenuto

Collaboratori
Controllo Attacco

Mappa SuperClasse: SottoClasse: Responsabilit

Contiene i dati relativi alla mappa di gioco

Collaboratori
Modulo Persistenza Dati Territorio Armata Partita

Partita SuperClasse: SottoClasse: Responsabilit

Contiene i dati relativi alla partita

Collaboratori
Giocatore Mappa Modulo Persistenza Dati

Armata SuperClasse: SottoClasse:

Responsabilit
Contiene i dati relativi alle armate Giocatore Mappa Territorio

Collaboratori

Territorio SuperClasse: SottoClasse: Responsabilit

Contiene i dati relativi al territorio Giocatore Mappa Armata

Collaboratori

Giocatore SuperClasse: SottoClasse: Responsabilit

Contiene i dati relativi al proprietario

Collaboratori
Component Disposizione Armate Armata Territorio Modulo Persistenza Dati

Modulo Persistenza Dati SuperClasse: SottoClasse: Responsabilit

Gestione dei dati del Sistema

Collaboratori
Controllo Attacco Mappa Partita Giocatore

INVIA MESSAGGIO Component Invio Messaggio SuperClasse: SottoClasse: pulsante,tabella

Responsabilit
Esegue azione collaboratore richiesta da un

Collaboratori
Form conversazione

Pulsante SuperClasse: Component Invio messaggio SottoClasse: Responsabilit

Aziona un comando richiesto

Collaboratori

SuperClasse: SottoClasse: Responsabilit

Visualizza tabella

Tabella Component Invio messaggio Collaboratori Form di conversazione

SuperClasse: SottoClasse: Responsabilit

Visualizza form di conversazione

Collaboratori
Controllo Invio messaggio Component invio messaggio

Controllo Invio messaggio SuperClasse: SottoClasse: Responsabilit

Effettua controlli sullinvio dei messaggi

Collaboratori
Form di conversazione

Giocatore SuperClasse: SottoClasse: Responsabilit

Contiene i dati relativi al giocatore

Collaboratori
Component invio messaggio

PASSA TURNO Component Passa Turno SuperClasse: SottoClasse: pulsante,display turno,led turno Responsabilit Collaboratori

Esegue azione collaboratore

richiesta

da

un

Form continuare selzionata?

con

loperazione

Pulsante SuperClasse: Component passa Turno SottoClasse: Responsabilit

Aziona un comando richiesto

Collaboratori

Display Turno SuperClasse: Component Passa Turno SottoClasse: Responsabilit

Visulaizza il turno del giocatore

Collaboratori

Led turno SuperClasse: Component passa Turno SottoClasse: Responsabilit

Visualizza lo stato del turno

Collaboratori

Continuare con loperazione selezionata? SuperClasse: SottoClasse: Responsabilit

Visualizza messaggio

Collaboratori
Component Passa Turno Controllo passa Turno

Controllo Passa Turno SuperClasse: SottoClasse: Responsabilit

Effettua controlli sul turno del giocatore

Collaboratori
Continuare con loperazione selezionata?

Giocatore SuperClasse: SottoClasse: Responsabilit

Contien i dati relativi al giocatore

Collaboratori
Component passa turno

SALVA PARTITA Component Salva Partita

SuperClasse: SottoClasse: pulsante Responsabilit

Esegue azione collaboratore richiesta da un

Collaboratori
Sei sicuro di voler salvare la partita?

Pulsante SuperClasse: Component Salva Partita SottoClasse: Responsabilit

Aziona un comando richiesto

Collaboratori

Sei sicuro di voler salvare la partita? SuperClasse: SottoClasse: Responsabilit

Visualizza messaggio

Collaboratori
Controllo Salvataggio partita Component salva partita Controllo Salvataggio partita

SuperClasse: SottoClasse: Responsabilit

Effettua controlli sul salvataggio della partita

Collaboratori
Sei sicuro di voler salvare la partita? Modulo persistenza Dati

Modulo Persistenza Dati SuperClasse: SottoClasse: Responsabilit

Gestione dei dati del Sistema

Collaboratori
Controllo Salvataggio Partita

Proprietario SuperClasse: SottoClasse: Responsabilit

Contiene i dati relativi al proprietario

Collaboratori
Component Salva partita

Diagramma di Gantt

TestCase
TEST ID TEST NAME TEST DESCRIPTION 1 INCVALORE Si intende verificare il corretto funzionamento dell operazione di incremento del valore relativo alla classe Indicatore Armate INPUT RISULTATO RISULTATO DESIDERATO OTTENUTO Pressione del Lindicatore tasto + Armate visualizza Precondizioni: il suo valore di -il Sistema default 1 nella fase di disposizione iniziale -Indicatore Armate al suo valore di default Pressione del Il valore viene tasto + incrementato di Precondizioni: una unit -il Sistema nella fase di disposizione iniziale -Indicatore Armate non al valore default Non viene Il valore di premuto nessun rimane invariato altro tasto

N 1

Precondizioni: -il Sistema nella fase di disposizione iniziale -Indicatore Armate non al valore default NOTE: per il corretto funzionamento delloperazione di incremento sono stati effettuati ulteriori controlli sul tipo di valore che viene fornito in ingresso : valore deve essere di tipo intero

TEST ID TEST NAME TEST DESCRIPTION

N 1

2 DECVALORE Si intende verificare il corretto funzionamento dell operazione di decremento del valore relativo alla classe Indicatore Armate INPUT RISULTATO RISULTATO DESIDERATO OTTENUTO Pressione del Lindicatore tasto - Armate visualizza Precondizioni: il suo valore -il Sistema nella fase di disposizione iniziale -Indicatore Armate non al valore di default Pressione del Il valore viene tasto + decrementato di Precondizioni: una unit -il Sistema nella fase di disposizione iniziale -Indicatore Armate non al valore default Non viene Il valore di premuto nessun rimane invariato altro tasto

Precondizioni: -il Sistema nella fase di disposizione iniziale -Indicatore Armate non al valore default NOTE: per il corretto funzionamento delloperazione di decremento sono stati effettuati ulteriori controlli sul tipo di valore che viene fornito in ingresso : valore deve essere di tipo intero

TEST ID TEST NAME TEST DESCRIPTION

N 1

3 SETVALORE Si intende verificare il corretto funzionamento dell operazione di inizializzazione del valore relativo alla classe Indicatore Armate INPUT RISULTATO RISULTATO DESIDERATO OTTENUTO Pressione del Lindicatore Armate tasto +/- visualizza il suo valore Precondizioni: -il Sistema nella fase di disposizione iniziale -Indicatore Armate non al suo valore di default Pressione del Il valore viene tasto +/- incrementato/decrementat Precondizioni: o di una unit. -il Sistema nella fase di disposizione iniziale -Indicatore Armate non al valore default Non viene Il valore di rimane premuto nessun invariato altro tasto

Precondizioni: -il Sistema nella fase di disposizione iniziale -Indicatore Armate non al valore default NOTE: per il corretto funzionamento delloperazione di inizializzazione sono stati effettuati ulteriori controlli sul tipo di valore che viene fornito in ingresso : valore

deve essere not null. TEST ID TEST NAME TEST DESCRIPTION N 1 4 GETVALORE Si intende verificare il corretto funzionamento dell operazione di getValore() relativo alla classe Indicatore Armate INPUT RISULTATO RISULTATO DESIDERATO OTTENUTO Pressione del Lindicatore Armate tasto + visualizza il suo valore Precondizioni: -il Sistema nella fase di disposizione iniziale -Indicatore Armate non al valore di default Pressione del Il valore viene tasto +/- incrementato/decrementat Precondizioni: o di una unit -il Sistema nella fase di disposizione iniziale -Indicatore Armate non al valore default Non viene Il valore di rimane premuto nessun invariato altro tasto

Precondizioni: -il Sistema nella fase di disposizione iniziale -Indicatore Armate non al valore default NOTE: per il corretto funzionamento di getvalore sono stati effettuati ulteriori controlli sul tipo di valore che viene fornito in uscita : valore deve essere di tipo intero TEST ID 5

TEST NAME TEST DESCRIPTION N 1

VERIFICA PARTITA Si intende verificare il corretto funzionamento dell operazione di creazione di una nuova partita INPUT RISULTATO RISULTATO DESIDERATO OTTENUTO Pressione del Il Sistema tasto NUOVA visualizza il Precondizioni: pulsante nuova -il Sistema nella fase di creazione nuova partita Pressione del tasto NUOVA Precondizioni: -il Sistema apre il form relativo alla creazione della nuova partita Il Sistema visualizza il form CREAZIONE NUOVA PARTITA

Pressione del Il sistema salva tasto NUOVA: tutti i dati relativi Precondizioni: alla creazione della -Tutti i campi nuova partita relativi al form nuova partita vengono compilati correttamente Nessuna Il Sistema apre il pressione del tasto form PLAY NUOVA

CODICE JUNIT: //Classe partita package it.unina.dsf.knomelab; public class Partita { private String partitaName; //Costruttore public Partita(String name){ this.setPartitaName=name; } public void setPartitaName(String partitaName) { this.partitaName = partitaName; } public String getPartitaName() { return partitaName; } } //classe giocatore package it.unina.dsf.knomelab; import java.util.HashMap; import java.util.Map;

public class Giocatore { private String password; private String Username; public HashMap<String, Partita> nuova;

//costruttore public Giocatore(String password,String username){ this.setPassword(password); this.setUsername(username); this.nuova = new HashMap<String,Partita>(); } public HashMap<String, Partita> getNuova() { return nuova; } public void setPassword(String password) { this.password = password; } public String getPassword() { return password; } public void setUsername(String username) { Username = username; }

public String getUsername() { return Username; } } //Classe indicatore armate package it.unina.dsf.knomelab; public class MyClass { int valore; public int IncValore(int valore){ return ++valore; } public int DecValore(int valore){ return --valore; } public int getValore(int valore){ return valore ; } public int SetValore(int valore){ return this.valore=valore; }

//TESTING * */ package it.unina.dsf.knomelab; import static org.junit.Assert.*; import org.junit.Test; /** * * */ public class MyClassTest { @Test public void testIncValore(){ MyClass inc = new MyClass(); //il test passa il valore fornito in ingresso viene incrementato di una unit assertEquals("incr",1,inc.IncValore(0)); //il test non passa il valore non viene incrementato di una unit assertEquals("notincr",2,inc.IncValore(0)); //test sul tipo di dato fornito in ingresso:il dato in ingresso deve essere di tipo intero assertSame("Result",1,inc.IncValore(0)); //test passa il parametro fornito non valido assertNotSame("NotResult",2,inc.IncValore("stringa")); } @Test public void testDecValore(){ MyClass dec = new MyClass(); //il test passa il valore fornito in ingresso viene decrementato di una unit assertEquals("incr",0,dec.DecValore(1)); //il test non passa il valore non viene decrementato di una unit assertEquals("notincr",2,dec.DecValore(0)); //test sul tipo di dato fornito in ingresso:il dato in ingresso deve essere di tipo intero assertSame("Result",0,dec.DecValore(1)); //test passa il parametro fornito non valido assertNotSame("NotResult",1,dec.DecValore(5)); }

@Test public void TestgetValore(){ MyClass ritorna = new MyClass(); //il test passa il metodo restituisce il valore inserito assertEquals("ritorna",1,ritorna.getValore(1)); //il test fallisce assertEquals("notritorna",2,ritorna.getValore(3)); //test passa fa riferimento allo stesso oggetto assertSame("ok",3,ritorna.getValore(3)); }

@Test public void TestSetValore(){ MyClass set = new MyClass(); //test passa il valore inserito valido assertEquals("ritorna",1,set.SetValore(1)); //test non passa il valore inserito non valido assertEquals("ritorna",1,set.SetValore(2)); //test passa il valore inserito notnull assertNotNull("notnull",set.SetValore(1)); } @Test public void VerificaPartita() { Partita pr =new Partita("Oceano"); Giocatore gi= new Giocatore("luca","566/228"); //verifico che il DB interno contiene la partita creata dal giocatore assertFalse(pr.getPartitaName().keySet().contains(partitaName)); //verifico che la nuova partita stata aggiunta alla lista assertEquals(1,gi.getNuova().size()); } }