Caso di Studio: Avant Dernier Specifiche: Nel gioco si affrontano 4 giocatori, ciascuno individuato con un numero progressivo (da 1 a 4). Inizialmente, i giocatori ricevono 5 carte ciascuno, e una carta è depositata sul tavolo. I giocatori procedono a turno dal primo al quarto, effettuando una giocata ciascuno. Una giocata consiste nel deposito di una carta sul tavolo o nel prelievo di una carta dal mazzo. Se il giocatore non può depositare, deve prelevare. Le regole per il deposito sono le seguenti: 1. La carta depositata deve essere dello stesso seme di quella sul tavolo, oppure avere lo stesso numero (si ipotizzi che le carte siano numerate da 1 a 13, dove 11=fante, 12=regina, 13=re) 2. Alcune carte alterano le regole del gioco come segue: 1. Un re produce l'inversione della direzione delle giocate (dal giocatore 4 al giocatore 1, o viceversa, secondo il giro corrente) 2. Una donna fa saltare il giro al giocatore successivo 3. Un fante consente di cambiare il seme sul tavolo in un altro seme scelto dal giocatore. 4. Un asso provoca il prelievo di 2 carte da parte del giocatore successivo, oppure se questi deposita un secondo asso, il prelievo di 4 carte da parte del giocatore successivo a questo, e così via fintantoché qualche giocatore deposita un asso. Se un giocatore deposita una carta sbagliata (per seme o numero) pesca 2 carte. Vince il gioco chi termina per primo le carte. Per terminare le carte devono essere rispettate due ulteriori regole: 1. Il deposito della penultima carta deve essere preceduto da un opportuno segnale (denominato Avant Dernier). Se il giocatore non fa tale dichiarazione, deve pescare 2 carte. 2. Il deposito dell'ultima carta deve essere preceduto da un opportuno segnale (denominato Dernier). Se il giocatore non fa tale dichiarazione, deve pescare 2 carte. Si supponga il mazzo di carte infinito. L'applicazione deve consentire ai 4 giocatori di avviare una partita, deve disporre le carte iniziali dei giocatori e del tavolo, deve richiedere al prossimo giocatore la mossa (prelievo o deposito), controllare la validità della mossa del giocatore, e aggiornare le regole del gioco in base alla carta depositata. - 1 -
Analisi [ricapitolazione]: identificare le classi e gli oggetti OOA Classica (identificazione delle classi e degli oggetti): Elementi tangibili: [attori] - Giocatore - Tavolo - Banco (conosce il regolamento: coordina i giocatori e distribuisce le carte dal mazzo) [oggetti di contorno] - Mazzo - Mano - Carte sul tavolo - Carta Eventi: - Un giocatore gioca una carta - Un giocatore pesca una o più carte - Il banco dichiara terminata la partita e proclama un vincitore - Un giocatore gioca un fante e sceglie un nuovo colore Ruoli, interazioni, concetti: - Regolamento - Decisore della mossa - Mossa (pescare o carte da giocare) - Effetti (saltare, cambiare giro, scegliere il colore ) [oggetti di contorno] - Interfaccia utente - 2 -
Analisi [ricapitolazione]: Identificazione degli scenari di analisi Funzione: giocare una partita Scenari primari selezionati: 0. Normale passaggio di mano da un giocatore ad un altro 1. Un giocatore gioca una carta a caso nel proprio turno e vince 2. Un giocatore gioca un fante e sceglie quadri come nuovo colore Altri scenari primari: Un giocatore chiede di pescare Un giocatore gioca un asso Un giocatore gioca una donna Un giocatore gioca un re Un giocatore gioca una carta che non ha né seme né numero uguale a quella in testa alla pila delle carte sul tavolo Scenari secondari: (Violazione delle regole, es.: un giocatore pesca quando non è il suo turno!) [ ] Scenario 2: Un giocatore gioca un fante e sceglie quadri come nuovo colore Descrizione Il banco passa il turno al giocatore, il quale in base al decisore di mossa sceglie di giocare un fante, il banco chiede al giocatore il nuovo colore, il giocatore sceglie quadri (nuovamente in base al decisore di mossa). 1.) Inizio partita 1.1.) Il banco sceglie un giocatore 2.) Un giocatore gioca una carta 2.1.) Il giocatore esamina il tavolo 2.2.) Il giocatore consulta il decisore di mossa 2.3.) Il giocatore sceglie dalla mano un fante e lo deposita sul tavolo 3.) Il banco chiede il nuovo colore al giocatore 3.1.) Il banco esamina il tavolo - 3 -
3.2.) Il banco consulta il regolamento 3.3.) Sulla base del regolamento chiede il nuovo colore al giocatore 4.) Il Giocatore sceglie quadri 4.1.) Il giocatore consulta il decisore di mossa 4.2.) Il decisore di mossa sceglie quadri 4.3.) Il giocatore chiede quadri 5.) Il banco annuncia il nuovo colore e passa il turno 5.1.) Il banco cambia il colore in base alla richiesta 5.2.) Il banco avvisa il giocatore cui tocca giocare Diagramma 12: effetti della giocata regolamento banco 10: carta giocata 11: stato del tavolo tavolo 9: carta giocata carte sul tavolo 2: carte sul tavolo 15: colore scelto 1: turno 8: carta giocata 3: carte sul tavolo 7: carta da giocare 13: richiesta di un colore giocatore 1 4: carte in mano mano giocatore 2 16: turno 14: colore scelto 6: mossa suggerita decisore di mossa 5: stato del gioco Responsabilità individuate Nota: indichiamo solo le -nuove- responsabilità, evitando i citare nuovamente quelle già identificate. - 4 -
Giocatore Esaminare lo stato del gioco (mano+tavolo). Chiedere una mossa al decisore: informa il decisore dello stato del gioco e chiede di scegliere una possibile soluzione (pescare dal mazzo o scegliere una carta da giocare) Scegliere un colore: il giocatore deve fornire al banco un colore Chiedere al decisore un colore: il giocatore informa il decisore dello stato attuale del gioco e chiede di scegliere un colore. Decisore di mossa Esaminare lo stato del gioco (mano+tavolo) e indicare una carta da giocare oppure consigliare di pescare. Esaminare lo stato del gioco e scegliere un colore a cui passare Banco Chiedere al giocatore un nuovo colore e cambiare il colore attuale - 5 -
Analisi [ricapitolazione]: Identificazione delle associazioni tra classi Regolamento 1 consulta 1 1 1 1 Banco 1 controlla coordina 1 1 1 Tavolo 1 Gioca su 4 4 4 1 Giocatore 1 1 Decisore consulta Mazzo Carte sul Tavolo Mano Carta N 1 Contenitore di carte - 6 -
Parte II PROGETTAZIONE - 7 -
Progettazione: Revisione della struttura Formalizazione delle associazioni individuate: Regolamento Consulta Banco <<has-a>> Mazzo 1..1 Controlla <<is-a>> Coordina Tavolo <<has-a>> Carte sul Tavolo <<Interface>> Contenitore di Carte 4..4 1..1 Gioca su 4..4 1..1 <<has-a>> Decisore di mossa Giocatore <<has-a>> Mano 0..* Richiede mossa Carta Abbiamo rifatto il diagramma delle associazioni (analisi) in modo più formale, evidenziamo in particolare: - gli stereotipi - se presente: il verso d uso preferenziale dell associazione Nella figura compaiono le classi dell analisi, queste verranno poi tradotte in una o più classi di progetto (ma potrebbero anche sparire). Prima di questo dobbiamo però individuare una struttura per l applicazione vera e propria. - 8 -
Progettazione: Progettazione dei moduli Attori Memorizzazione dello Stato Interazione con l'utente L architettura dell applicazione prevede tre moduli: - Interfaccia utente - Attori - Componente di memorizzazione dello stato Sono poi evidenziate le dipendenza progettate fra questi tre moduli: - L interfaccia utente usa Attori e Memorizzazione dello Stato - Attori usa Memorizzazione dello Stato Le dipendenze devono rispecchiare le associazioni individuate durante l analisi, sia per quanto riguarda l esistenza che per quanto riguarda il verso (es.: sono coerenti con gli scenari d analisi studiati). - 9 -
Progettazione del modulo: Attori Banco Consulta Regolamento 1..1 Coordina 4..4 Giocatore Richiede mossa Decisore di mossa Prima di tutto evidenziamo i legami già trovati durante l analisi, poi cerchiamo di introdurre ulteriori raffinamenti negli oggetti nelle associazioni. Banco Consulta Regolamento Effetto 1..1 <<is-a>> Coordina Automatico Guidato dell'utente 4..4 Giocatore Richiede mossa Decisore di mossa Mossa <<is-a>> DecisoreUmano DecisoreAutomatico <<is-a>> DecisoreCasuale DecisoreIntelligente - 10 -
Progettazione del modulo: Memorizzazione dello stato Carta <<has-a>> 0..* 1..1 <<Interface>> Contenitore di Carte <<is-a>> Tavolo <<has-a>> Carte sul Tavolo Mano Mazzo Questo modulo non presenta ulteriori raffinamenti/aggiunte a questo livello di dettaglio, ciò è consistente con il ruolo prettamente di memorizzazione delle classi che lo compongono: vuol dire che durante l analisi abbiamo evidenziato tutti gli elementi necessari a descrivere lo stato d avanzamento del gioco. - 11 -
Progettazione del modulo: Interazione con l Utente Utente Interagisce con Framework <<Visualizza>> Contenitore di Carte (from Memorizzazione dello Stato) <<Visualizza>> Tavolo (from Memorizzazione dello Stato) <<Visualizza>> Giocatore (from Attori) <<Interface>> Interfaccia Utente I dettagli di questo modulo sono completamente nuovi (non essendo stata studiata nell analisi l interazione con l utente). Introduciamo due classi: - Framework: rappresenta il coordinatore dell interfaccia e dell interazione con l utente. - Utente: rappresenta l utente e potrebbe non esistere nell implementazione. Un interfaccia: - Interfaccia Utente: descrive le funzionalità necessarie a mostrarsi all utente (ed eventualmente ad interagire). Uno stereotipo: - Visualizza: l interazione esistente fra il Framework e gli oggetti dotati di Interfaccia Utente. - 12 -
Progettazione: Definire l implementazione: classi Devono venire individuati tutti gli attributi/eventi/metodi necessari a descrivere i comportamenti evidenziati durante la fase di analisi e durante la fase di progettazione. A tal fine è opportuno notare che, tranne rari casi, qui vengono evidenziati solo gli attributi/eventi/metodi pubblici, poiché quelli privati non contribuiscono a definire il comportamento della classe dal punto di vista della struttura (sono usati solo internamente e verranno definiti nelle prime fasi dell implementazione) Iniziamo con le classi del modulo Attori : Banco Consulta Regolamento 1..1 Coordina 4..4 Giocatore Richiede mossa Decisore di mossa class Giocatore Struttura: Informazioni per individuare tavolo e decisore Attributi di identificazione (Nome, tipo di decisore etc ) Attributi per rappresentare lo stato Comportamento: interazione con Banco: Metodo/Evento gioca(): serve a fare pescare o giocare una o più carte Metodo sceglicolore(): serve a scegliere il colore dopo avere deposto un fante - 13 -
interazione con Framework: Metodo/Evento visualizza(): serve affinché sia possibile dare una rappresentazione visuale dello stato del giocatore class Banco Struttura: Informazioni per individuare tavolo e regolamento Attributi di identificazione (tipo di regolamento etc ) Attributi per rappresentare lo stato del gioco (verso del giro, giocatore corrente, colore corrente, numero di passi da saltare, numero di carte da giocare) Altri attributi per rappresentare lo stato del Banco Comportamento: interazione con Framework: Metodo/Evento iniziapartita(): serve a fare ri/cominciare una partita interazione con Tavolo: Metodo/Evento cartagiocata(): il banco riceve notifica quando una carta viene giocata (e deve prendere gli opportuni provvedimenti) Metodo/Evento cartapescata(): il banco riceve notifica quando una carta viene pescata interazione con Giocatore: Metodo/Evento dichiarazionedernier(): il giocatore può dichiarare AvantDernier o Dernier class Regolamento Struttura: Attributi di identificazione (tipo umano/automatico etc ) Comportamento: interazione con Banco: Metodo analizzagioco(): per analizzare il tavolo/le carte giocate e identificare eventuali azioni da intraprendere. class Decisore di mossa Struttura: Informazioni sullo stato della partita (?) Attributi di identificazione (tipo di decisore etc ) - 14 -
Comportamento: interazione con Giocatore: Metodo/Evento sceglimossa(): il decisore riceve informazioni sulla mano e sullo stato della partita, in base a questo deve stabilire il modo più opportuno per giocare. Metodo sceglicolore(): per scegliere il colore quando si gioca un fante. class Mossa Struttura: Tipo di mossa da effettuare (pescare/giocare una carta) Dichiarazione (Dernier, Avant Dernier o nulla) Carta da giocare (nel caso in cui si voglia giocare una carta) Comportamento: questa classe non ha un comportamento in quanto serve come contenitore per veicolare informazioni class Effetto Struttura: Tipo di effetto di una mossa (nullo, cambia giro, salta, scegli colore, aumenta carte da giocare per il prossimo giocatore) Comportamento: anche questa classe non ha un comportamento in quanto anch essa serve come contenitore per veicolare informazioni Classi del modulo Memorizzazione dello Stato : Carta <<has-a>> 0..* 1..1 <<Interface>> Contenitore di Carte <<is-a>> Tavolo <<has-a>> Carte sul Tavolo Mano Mazzo [ ] - 15 -
Classi del modulo Interazione con l Utente : Utente Interagisce con Framework <<Visualizza>> Contenitore di Carte (from Memorizzazione dello Stato) <<Visualizza>> Tavolo (from Memorizzazione dello Stato) <<Visualizza>> Giocatore (from Attori) <<Interface>> Interfaccia Utente [ ] Progettazione: Definire l implementazione: associazioni Iniziamo con le associazioni che partono da classi del modulo Attori : Associazione Gioca su (Giocatore-Tavolo) Struttura: per riferimento, una variabile in giocatore che indica il tavolo a cui sta giocando Visibilità: privata Comportamento: - Creata durante la creazione del giocatore, è persistente. Associazione Richiede mossa (Giocatore-Decisore) Struttura: per riferimento, una variabile in giocatore che indica il decisore da utilizzare Visibilità: privata - 16 -
Comportamento: - Creata durante la creazione del giocatore, è persistente. Associazione Consulta (Banco-Regolamento) Struttura: per contenimento, il Regolamento sarà una variabile entro Banco Visibilità: privata Comportamento: - Creata durante la creazione del Banco, è persistente. Associazione Coordina (Banco-Giocatore) Struttura: per riferimento, il Banco possiederà una lista dei Giocatori che partecipano al gioco. Visibilità: privata Comportamento: - Creata durante la creazione del Banco, è persistente. Ereditarietà (Decisore/Decisore casuale/decisore utente) Visibilità: privata Comportamento: - Il decisore è polimorfico, in questo modo la classe giocatore non ha mai bisogno di sapere se a decidere è un automa o l utente Associazioni che partono da classi del modulo Memorizzazione dello Stato : [ ] Associazioni che partono da classi del modulo Interazione con l Utente : [ ] - 17 -
Una volta terminata la definizione delle classi e dei relativi metodi/attributi/eventi esaminiamo un sequence-diagram di riferimento per verificare che tutti i messaggi possano venire descritti tramite i metodi e gli eventi identificati. : Banco giocatore1 : Giocatore : Mano : Tavolo : Carte sul Tavolo : Decisore di mossa : Regolamento Gioca Esamina Esamina Esamina Consulta Preleva Gioca carta Aggiungi carta Notifica giocata Esamina Esamina Consulta Chiedi Colore - 18 -
Progettazione: Progettazione delle classi con dinamica Progettazione dello stato (classe Banco) Non in gioco Inizio partita In gioco Fine partita Pescata una carta In attesa di mossa Giocata una carta Reazione alla mossa Comunicazione al giocatore Eventi simbolici Non sono veri eventi simbolici in quanto corrispondono a transizioni dovute a chiamate di metodi e non a messaggi/eventi. Inizio partita Fine partita Comunicazione al giocatore Questi invece sono eventi veri e propri e richiedono dei servizi dinamici (cioè qualcuno che riceva e gestisca l evento). In questo caso possiamo creare un gestore unificato che chiameremo valutamossa Pescata una carta Giocata una carta - 19 -
Servizio dinamico valutamossa Condizioni di transizione: - la carta mossa (pescata/carta giocata) è valida Effetti della transizione: Esame dello stato e reazioni: - Se: giocata una donna Allora: fa saltare il giro al giocatore successivo - Se: giocato un fante Allora: richiede al giocatore il nuovo colore - Se: giocato un re Allora: inverte direzione di gioco - Se: giocato un asso Allora: - Se: doveva pescare 2^N carte Allora: passa al giocatore successivo che deve pescare 2^(N+1) carte - Altrimenti: il giocatore successivo deve pescare 2 carte Nota: agli effetti le condizioni sullo stato sono più complesse e per testarle esiste appunto la classe Regolamento - 20 -
Riepilogo dei principali passi del processo di sviluppo Analisi Mira a dare una descrizione completa e formale di un problema/processo esistente. In questa fase non si fanno ipotesi semplificative, ne si tiene conto di necessità implementative o altro: si sta descrivendo il problema, non la sua soluzione. Si parla di classi e oggetti reali, non delle controparti programmative. Identificare le classi e gli oggetti [class diagram] Dizionario delle classi (per ogni classe: definizione, responsabilità, vincoli) [class diagram] Identificazione degli scenari e ricerca delle responsabilità per le classi (Primari e secondari, scelta degli scenari da analizzare) [use case diagram/sequence diagram/collaboration diagram] Dizionario delle classi con specifica dei servizi [class diagram] Revisione classe per classe (si identificano classi e/o servizi mancanti/ridondanti, in generale si verifica la consistenza dell analisi) [class diagram] Analisi della dinamica delle classi [statechart (ma anche sequence diagram e collaboration diagram per aiutarsi nella definizione delle statechart)] Identificazione delle associazioni fra le classi [class diagram] Verifica di congruenza (fra le associazioni e i collegamenti fra gli oggetti, ma anche fra statechart e collaboration diagram/sequence diagram) Identificazione degli schemi ripetitivi di collaborazione e associazione Specifica finale delle classi (si raccoglie organicamente quanto fatto nell analisi) [class diagram] - 21 -
Progetto Mira a descrivere un architettura che implementi il modello/risolva il problema. In questa fase si parla di classi ed oggetti in un ottica di OOP, si fanno scelte strutturali, si decidono delle linee guida e degli obiettivi strutturali. In questa fase non si fanno semplificazioni implementative, il progetto deve avere una struttura per quanto possibile ottima. Le classi e le associazioni non sono necessariamente le stesse dell analisi (tuttavia una buona progettazione mira per quanto possibile a mentenerle) Formalizzazione dei risultati dell analisi (si applicano i concetti dell OOD al risultato finale dell analisi) [class diagram] Definizione delle classi (struttura e comportamento) [class diagram] Definizione delle associazioni (struttura, visibilità e comportamento) [class diagram] Progettazione delle associazioni (descrive le relazioni fra gli oggetti: non quelle fra le classi!) [object diagram] Progettazione della dinamica/1 (definizione di stati ed eventi) [statechart/activity diagram] Progettazione della dinamica/2 (definizione dei servizi e delle transizioni) [??? DFD] Progettazione della struttura finale [deployment diagram] I seguenti due passi vengono svolti durante la fase di progetto, il momento esatto dipende dal progettista: Definizione dell architettura [class diagram] Scelta di linguaggi/piattaforme [deployment diagram] - 22 -
Implementazione Si decidono le strutture interne delle classi e i dettagli delle loro interazioni Si dettaglia completamente la dinamica (anche quelle interna) si scelgono/creano eventuali algoritmi ancora non specificati. Si scrive il codice vero e proprio. L implementazione deve realizzare la struttura del progetto, qualora vi siano conflitti/ostacoli il progetto va rivisto. Se ciò non è possibile sono ammissibili alcune eccezioni che devono essere pochissime e dettagliatamente documentate (sia nel codice che nei documenti di progetto) - 23 -