UNIVERSITÀ CA’ FOSCARI DI VENEZIA

DIPARTIMENTO DI INFORMATICA
AA 2008-2009

Documento di
Analisi del Problema
Corso di Ingegneria del Software
Docente Responsabile : Agostino Cortesi
Task 1
03/11/2008

Gruppo:
Our-Chan Team

Gasparetto Andrea (Team Leader) Matr. 812882

Milan Luca Matr. 810648
Schiavinato Michele Matr. 810649
Caputi Salvatore Matr. 813103
Furegon Andrea Matr. 812693
Task 1 Documento di Analisi del Problema

INDICE ARGOMENTI
1 INTRODUZIONE ................................................................................................................................. 3
2 OGGETTI DEL SISTEMA ...................................................................................................................... 5
3 ANALISI DI UNA SESSIONE TIPO CON IL SISTEMA ............................................................................. 8
4 ANALISI DI UNA PARTITA A CARTE .................................................................................................... 9
5 RAPPORTO TRA SVILUPPATORE E SISTEMA .................................................................................... 11
6 GLOSSARIO ...................................................................................................................................... 12

INDICE FIGURE
Capitolo 1
Figura 1.1……………………………………………………………………………………………………………………………3
Capitolo 2
Figura 2.1……………………………………………………………………………………………………………………………5
Capitolo 3
Figura 3.1……………………………………………………………………………………………………………………………8
Capitolo 4
Figura 4.1……………………………………………………………………………………………………………………………9
Figura 4.2………………………………………………………………………………………………………………………….10
Capitolo 5
Figura 5.1………………………………………………………………………………………………………………………….11

DOCUMENTO RILASCIATO IL 03 NOVEMBRE 2008

VERSIONE 1.0

PAGINE TOTALI 12

2/12
Task 1 Documento di Analisi del Problema

1 INTRODUZIONE

Il problema presentato dal committente consiste nella creazione di un sistema che permetta di
giocare ad un gioco di carte. I vincoli che sono stati imposti a riguardo di tale sistema riguardano:
 Il numero minimo di giocatori: almeno 2, quindi vengono esclusi dalla compatibilità giochi
come il solitario.
 Giochi che non utilizzano carte francesi o trevigiane.
Cercando di analizzare un buon “parco giochi” e come essi si svolgono si è cercato di individuare le
operazioni che il nostro sistema deve prendere in considerazione e quali sono gli oggetti che il si-
stema dovrà essere in grado di gestire.
Lo schema qui sotto rappresenta una possibile situazione di gioco e viene utilizzata per mostrare
genericamente a quali oggetti possiamo trovarci a contatto. Il codice dei vari oggetti sulla rappre-
sentazione grafica sono dotati di link alla definizione degli stessi.

G.1

T.1

T.3

T.2

Figura 1.1

Gli elementi rappresentati sullo schema soprastante verranno esplicitati qui sotto seguendo il se-
guente template:

Oggetto Il nome dell’oggetto preso in esame

Codice X.Y, dove X sta per:
• T (=tavolo) oppure
• G (=giocatore)
e Y è un numero progressivo.
Descrizione L’oggetto viene preso in esame e viene data una sua descrizione
in linguaggio naturale.

3/12
Task 1 Documento di Analisi del Problema

Descrizione degli oggetti in “campo”:

Oggetto Mazzo
Codice T.1
Descrizione E’ praticamente una lista non ordinata di carte. Può essere inoltre formato
dal mescolamento di più mazzi, dipendentemente dalle regole del gioco.

Oggetto Tuple sul tavolo

Codice T.2
Descrizione Sul tavolo sono state messe delle tuple valide dai giocatori. Dal sistema esse
vengono viste come una lista di tuple, un oggetto ben definito all’interno
della parte logica.

Oggetto Carte scartate dalla mano del giocatore

Codice T.3
Descrizione In molti giochi di carte, alla fine di ogni turno, il giocatore che sta per passare
la mano deve scartare una carta che andrà a formare una pila (o una lista) di
carte sul tavolo. Le operazioni effettuabili con tali carte dipendono dalle re-
gole di gioco.

Oggetto Mano del giocatore

Codice G.1
Descrizione La mano del giocatore è una lista di carte (o di tuple, si possono vedere allo
stesso modo) che il giocatore deve terminare, ponendo delle tuple valide sul
tavolo o scartandole. Nel momento in cui il giocatore finisce le carte che ha
in mano, la partita finisce.

Una descrizione maggiormente dettagliata degli oggetti qui introdotti e di tutti i sotto-oggetti che
li compongono verrà data nel modulo seguente.

4/12
Task 1 Documento di Analisi del Problema

2 OGGETTI DEL SISTEMA

Lo schema sottostante è una rappresentazione gerarchica di tutti gli oggetti individuati per risolve-
re il nostro problema. Un oggetto può essere scomposto in altri oggetti che saranno collocati ad
un livello inferiore e così via.
A seguire troviamo per ogni oggetto una piccola tabella dove descriviamo più dettagliatamente le
caratteristiche principali e i sotto-oggetti di primo livello ereditanti.

Gioco

Tavolo Giocatori
Lista<Giocatore>

Pila Scarti Mazzo Tuple sul Tavolo

Lista<Carte> Lista<Carte> Lista<Tuple> Lista Giocatore
Attribute: Owner

Mano
Lista<Tuple>

Lista Carte Lista Carte Lista Tuple

Lista Tuple

Figura 2.1

La descrizione dei vari oggetti seguirà il seguente template:

Nome dell’oggetto
Descrizione Descrizione esaustiva delle caratteristiche principali
dell’oggetto.
Sottoelementi Tutti i sotto-elementi dell’oggetto che stanno al pri-
mo livello.

Specifica degli oggetti:

Gioco
Descrizione Rappresenta la realtà principale dove tutti i nostri oggetti
dovranno far parte.
La funzionalità principale di questo oggetto è semplice-
mente risolvere tutti i vari tipi di requisiti del nostro pro-
blema.
Sottoelementi Tavolo, Giocatori

5/12
Task 1 Documento di Analisi del Problema

Tavolo
Descrizione Rappresenta il tavolo del gioco. Il concetto di tavolo si ri-
presenta nella maggior parte dei giochi di carte e permet-
te di tenere traccia del determinato stato del gioco cor-
rente oltre ad essere di necessaria utilità ai giocatori stes-
si.
Sottoelementi Pila Scarti, Mazzo, Tuple sul Tavolo

Giocatori
Descrizione Rappresenta l’insieme dei giocatori. Questo oggetto può
essere visto come una semplice lista omogenea di oggetti
Giocatore.
Sottoelementi Lista, Giocatore

Pila Scarti
Descrizione Rappresenta l’insieme di quelle carte scartate dal gioco.
Questo oggetto può essere visto come una semplice lista
omogenea di oggetti Carte.
Sottoelementi Lista, Carte

Mazzo
Descrizione Rappresenta l’insieme delle carte in gioco. Questo ogget-
to può essere visto come una semplice lista omogenea di
oggetti Carte.
Sottoelementi Lista, Carte

Tuple sul Tavolo

Descrizione Rappresenta l’insieme delle tuple nel tavolo. Questo og-
getto può essere visto come una semplice lista omogenea
di oggetti Tuple. Un'altra caratteristica dell'oggetto è la
presenza dell'attributo Owner, ossia il proprietario. Tale
attributo sta proprio ad indicare quale giocatore ha posto
sul tavolo quella determinata tupla. In alcuni giochi, infat-
ti, al giocatore è permessa la modifica delle sole tuple che
lui stesso ha scartato in tavola, mentre gli viene negata la
modifica di quelle scartate dagli altri.

Sottoelementi Lista, Tuple

Lista
Descrizione Rappresenta un’insieme o una collezione di elementi.
Questo oggetto si preoccuperà di gestire tutte le opera-
zione lettura/scrittura dei suoi elementi.

6/12
Task 1 Documento di Analisi del Problema

Sottoelementi --

Giocatore
Descrizione Rappresenta un qualsiasi giocatore al gioco di carte. Que-
sto oggetto ha il compito contenere svariate informazioni
del giocatore oltre ad offrirgli determinate operazioni.
Sottoelementi Mano

Carte
Descrizione Rappresenta una qualsiasi carta con cui poter giocare.
Questo oggetto ha il compito di rappresentare la carta
nelle sue caratteristiche principali.
Sottoelementi --

Mano
Descrizione Rappresenta semplicemente la mano del giocatore. Que-
sto oggetto è composto da un’insieme di tuple.
Sottoelementi Lista, Tuple

Tuple
Descrizione Rappresenta una combinazione specifica di carte. Questo
oggetto è composto da un’insieme di oggetti Carte.
Sottoelementi --

7/12
Task 1 Documento di Analisi del Problema

3 ANALISI DI UNA SESSIONE TIPO CON IL SISTEMA

In questa sezione viene presentato un’analisi schematica di come si svolge una sessione con
l’applicazione, mettendo in evidenza quali saranno le possibili operazioni effettuabili dall’utente in
base allo stato in cui si trova il sistema.

Inizio

Menù Opzioni

Esci Help Cambia Imp

Fine

Gioca

Vittoria / Sconfitta Pausa / Menu

Resume Termina Partita Help

Figura 3.1

8/12
Task 1 Documento di Analisi del Problema

4 ANALISI DI UNA PARTITA A CARTE

In questo modulo verrà data una descrizione di come una generica partita di carte si svolge. Nello
schema (flow chart) viene rappresentato l’ipotetico turno di un giocatore poiché il turno del gioca-
tore successivo è speculare nelle meccaniche.

Gioca

Pesca
Carta

Scarta Modifica
Tupla Tupla

Passa/Scarta
Carta

Figura 4.1

Una volta iniziata la partita, il giocatore si troverà di fronte a diverse possibili azioni. Esso potrà pe-
scare una carta, modificare una tupla o mettere in tavola una tupla. E può anche scartare una car-
ta (se il gioco lo prevede) e passare la mano al giocatore successivo. Uno dei vincoli che lo schema
vuole sottolineare riguardano la fase di pescaggio della carta. Essa può essere fatta solo all’inizio
del proprio turno, e deve essere la prima operazione. Nel caso in cui si decida di non pescare
(sempre che il gioco prevede tale opzione) e si procede con altre azioni (ad esempio scartare una
tupla), il giocatore non potrà tornare sui suoi passi e pescare in un secondo momento.
L’azione di scartare una tupla invece non preclude la possibilità di modificarne un’altra e viceversa.

9/12
Task 1 Documento di Analisi del Problema

Per chiarire meglio il concetto, si osservi lo schema sottostante:

Prima Fase Seconda Fase Terza Fase

Scarta Tupla
Inizio Turno Pesca Carta Scarta/Passa
Optional Fine Turno

Modifica
Tupla

Figura 4.2

La prima e l’ultima fase sono uniche per ogni turno. La seconda fase invece può essere iterata più
volte. Pesca Carta nella prima fase è opzionale (questo dipende dalle specifiche regole del gioco).

10/12
Task 1 Documento di Analisi del Problema

5 RAPPORTO TRA SVILUPPATORE E SISTEMA

La seguente sezione cerca di trattare il problema della relazione tra sviluppatore e applicazione,
tra logica di gioco e sistema, tra logica di gioco e sviluppatore e tra sistema e giocatore.

Applicazione

LOGICA Collaborano Sistema GUI

Sviluppatore

Giocatore

Figura 5.1

Lo sviluppatore è colui che progetta e realizza l’applicazione che ha come requisito quello di poter
collaborare con una logica di gioco. Questa logica viene creata da uno sviluppatore, che non deve
essere necessariamente quello che ha implementato l’applicazione. Questo comporta il porsi di
una relazione tra logica e applicazione, perché devono essere create in modo tale da poter coope-
rare senza il bisogno di modificare l’applicazione stessa. L’applicazione viene rappresentata nello
schema come una magic box, consistente (molto semplicisticamente) da un qualcosa chiamato
“Sistema” che permetterà appunto all’applicazione di collaborare con vari plugin di logica. Il Si-
stema si occuperà di tradurre le informazioni fornite dalla logica e passarle alla GUI (=graphics user
interface) che visualizzerà i cambiamenti avvenuti. In questo modo l’uso di un plugin di logica di
gioco diverso non causerebbe nessun problema e l’applicazione funzionerebbe correttamente co-
munque. Il giocatore interagirà con l’interfaccia utente che tramite il Sistema comunicherà alla lo-
gica di gioco le operazioni eseguite.

11/12
Task 1 Documento di Analisi del Problema

6 GLOSSARIO

Flow-chart
Modello di diagramma utilizzato principalmente per rappresentare il flusso e l’elaborazione delle
informazioni in un sistema.

Graphics user interface (GUI)

“Maschera” realizzata graficamente che permette l’interazione tra l’utente e il sistema. Si diffe-
renzia dall’interfaccia testuale per la presenza di elementi grafici che la rendono user-friendly.

Plugin
Estensione che aggiunge una o più funzionalità al software.

Template
Modello di documento formato da una parte fissa (ad esempio layout e schemi vari) ed una modi-
ficabile.

12/12