Laboratorio di Sistemi e Processi Organizzativi Progetto: Fantacalcio Gruppo: MaNaZ

Corso di Laurea in Scienze di Internet Universit di Bologna 6 giugno 2010

Indice
1 Introduzioone al Piano di Processo 1.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Sintesi del Progetto 2.1 Obiettivi e Destinatari . . . . . . . . . . . . . . . . . . . . . . 2.2 Vincoli (Consegne e Scadenze) . . . . . . . . . . . . . . . . . . 7 7 8 8 8

3 Glossario e riferimenti 10 3.1 Riferimenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2 Denizioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4 Organizzazione del Progetto 13 4.1 Struttura del Gruppo . . . . . . . . . . . . . . . . . . . . . . . 13 4.2 Ruoli e Responsabilit . . . . . . . . . . . . . . . . . . . . . . 13 5 Piani di Processo Gestionale 15 5.1 Piano di Lavoro . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.1.1 WBS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.1.2 Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6 Piano di Controllo 6.1 Stima dello Sforzo . . 6.2 Cocomo81 . . . . . . 6.3 Product Attributes . 6.4 Computer Attributes 6.5 Personal Attributes . 6.6 Project Attributes . 6.7 Risultati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 20 20 20 21 21 21 21

7 Analisi e Gestione dei Rischi 23 7.1 Inesperienza del Team . . . . . . . . . . . . . . . . . . . . . . 23 7.2 Inadeguatezza dei Requisiti . . . . . . . . . . . . . . . . . . . 23 3

7.3

Assenteismo dei componenti del gruppo . . . . . . . . . . . . . 23 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 24 24 24 25 25 25

8 Piano di Processo Tecnico 8.1 Modello di Processo . . . . . . . . . 8.2 Descrizione del Modello di Processo 8.3 Fase Iniziale . . . . . . . . . . . . . 8.4 Fase di Elaborazione . . . . . . . . 8.5 Fase di Costruzione . . . . . . . . . 8.6 Fase di Transizione . . . . . . . . .

9 Metodi Scartati 26 9.1 Il Processo con Ciclo a Cascata . . . . . . . . . . . . . . . . . 26 10 Tool utilizzati 27

11 Introduzioone al Documento dei Requisiti 29 11.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 11.2 Svolgimento del Gioco . . . . . . . . . . . . . . . . . . . . . . 29 12 Regole del Gioco 12.1 Le Fasi . . . . . . . . . . . . . 12.2 Denominazione Sociale . . . . 12.3 Capitale Sociale . . . . . . . . 12.4 Crediti bonus mercato gennaio 12.5 Asta dei Calciatori . . . . . . 12.6 Calciatore Deceduto . . . . . 12.7 Scambi . . . . . . . . . . . . . 12.8 In Campo . . . . . . . . . . . 12.9 Classica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 31 31 32 32 32 33 33 33 35

13 Requisiti 36 13.1 Requisiti Funzionali . . . . . . . . . . . . . . . . . . . . . . . . 36 13.2 Requisiti non Funzionali . . . . . . . . . . . . . . . . . . . . . 37 14 Introduzioone alla Relazione UML 38 14.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 15 Casi duso - Svolgimento 15.1 Descrizione . . . . . . . . . . . . . . . . 15.2 Il nostro diagramma . . . . . . . . . . . 15.2.1 Descrizione del nostro diagramma 15.3 Scenari dei casi duso . . . . . . . . . . . 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 40 40 40 43

16 Casi duso - Prima connessione 16.1 Descrizione . . . . . . . . . . . . . . . . 16.2 Il nostro Diagramma . . . . . . . . . . . 16.2.1 Descrizione del nostro diagramma 16.3 Scenari dei casi duso . . . . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

49 49 49 49 52 54 54 54 54 57 59 59 59 59

17 Diagramma delle classi 17.1 Descrizione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.2 Il nostro Diagramma . . . . . . . . . . . . . . . . . . . . . . . 17.2.1 Descrizione del nostro diagramma . . . . . . . . . . . . 18 I Pattern 19 Diagramma di sequenza - Svolgimento 19.1 Descrizione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19.2 Il nostro Diagramma . . . . . . . . . . . . . . . . . . . . . . . 19.2.1 Descrizione del nostro diagramma . . . . . . . . . . . .

20 Diagramma di sequenza - Prima connessione 62 20.1 Il nostro Diagramma . . . . . . . . . . . . . . . . . . . . . . . 62 20.1.1 Descrizione del nostro diagramma . . . . . . . . . . . . 62 21 Diagramma di sequenza - Asta 64 21.1 Il nostro Diagramma . . . . . . . . . . . . . . . . . . . . . . . 64 21.1.1 Descrizione del nostro diagramma . . . . . . . . . . . . 64 22 Diagramma degli stati - Server 22.1 Descrizione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.2 Il nostro Diagramma . . . . . . . . . . . . . . . . . . . . . . . 22.2.1 Descrizione del nostro diagramma . . . . . . . . . . . . 66 66 66 66

23 Diagramma degli stati - Client 68 23.1 Il nostro Diagramma . . . . . . . . . . . . . . . . . . . . . . . 68 23.1.1 Descrizione del nostro diagramma . . . . . . . . . . . . 68 24 Diagramma delle attivit - Svolgimento 24.1 Descrizione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.2 Il nostro Diagramma . . . . . . . . . . . . . . . . . . . . . . . 24.2.1 Descrizione del nostro diagramma . . . . . . . . . . . . 71 71 71 71

25 Diagramma delle attivit - Prima connessione 74 25.1 Il nostro Diagramma . . . . . . . . . . . . . . . . . . . . . . . 74 25.1.1 Descrizione del nostro diagramma . . . . . . . . . . . . 74 26 Diagramma delle attivit - Asta 77 26.1 Il nostro Diagramma . . . . . . . . . . . . . . . . . . . . . . . 77 26.1.1 Descrizione del nostro diagramma . . . . . . . . . . . . 77 27 Diagramma di deployment 27.1 Descrizione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27.2 Il nostro Diagramma . . . . . . . . . . . . . . . . . . . . . . . 27.2.1 Descrizione del nostro diagramma . . . . . . . . . . . . 28 Revisioni incrociate 28.1 Introduzione . . . . . . . . . . . . . . . . . . . 28.2 Valutazione gruppo 13 . . . . . . . . . . . . . 28.2.1 Leggibilit del processo: voto 8 . . . . 28.2.2 Correttezza: voto 6 . . . . . . . . . . . 28.2.3 Completezza: voto 7 . . . . . . . . . . 28.2.4 Organizzazione e presentazione: voto 7 28.2.5 Voto complessivo: voto 7 . . . . . . . . 28.3 Valutazione gruppo 14 . . . . . . . . . . . . . 28.3.1 Leggibilit del processo: voto 6 . . . . 28.3.2 Correttezza: voto 7 . . . . . . . . . . . 28.3.3 Completezza: voto 6 . . . . . . . . . . 28.3.4 Organizzazione e presentazione: voto 7 28.3.5 Voto complessivo: voto 7 . . . . . . . . 29 Valutazione gruppo 15 29.0.6 Leggibilit del processo: voto 8 . . . . 29.0.7 Correttezza: voto 8 . . . . . . . . . . . 29.0.8 Completezza: voto 8 . . . . . . . . . . 29.0.9 Organizzazione e presentazione: voto 8 29.0.10 Voto complessivo: voto 8 . . . . . . . . 30 Valutazione gruppo 16 30.0.11 Leggibilit del processo: voto 6 . . . . 30.0.12 Correttezza: voto 5 . . . . . . . . . . . 30.0.13 Completezza: voto 6 . . . . . . . . . . 30.0.14 Organizzazione e presentazione: voto 6 30.0.15 Voto complessivo: voto 5 . . . . . . . . 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 80 80 80 82 82 82 82 82 83 83 83 83 83 83 84 84 84 85 85 85 85 86 86 87 87 87 87 88 88

Capitolo 1 Introduzioone al Piano di Processo

1.1 Introduzione

Il seguente documento stato redatto e scritto seguendo lo standard IEEE10581998 per Software Project Management Plans. La scelta di questo standard dovuta principalmente alla sua versatilit e al suo largo utilizzo nei diversi campi del software. Del suddetto standard, non aronteremo alcuni punti,(come ad esempio Additional plans) e alcuni sotto paragra (come Budget Allocation),considerati superui al ne del progetto.

Capitolo 2 Sintesi del Progetto

2.1 Obiettivi e Destinatari

Obiettivo del progetto la creazione di un software di gestione delle partite di Fantacalcio. Il Software gestir dalla creazione di una nuova lega alla creazione di nuove squadra che la compongono e dalla gestione della formazione al punteggio nale ottenuto. Il destinatario del progetto il professore P. Ciancarini.

2.2

Vincoli (Consegne e Scadenze)

Lattivit si articola in due fasi. Consegne e scadenze obbligatorie della prima fase: 1. Il giorno 17/5/2010 i PM dovranno consegnare su wiki una bozza iniziale del Piano di Processo. 2. Il giorno 17/5/2010 i TS deniranno eventuali emendamenti ai requisiti descritti nella Sezione 3 di questo documento, consegnando sul wiki un documento dei requisiti scritto usando uno strumento qualsiasi di gestione dei requisiti. 3. Il giorno 31/5/2010 i Librarian dovranno consegnare sul wiki una bozza della relazione con la parte UML, in modo che possa essere fatta una revisione incrociata. 4. Il giorno 7/6/2010 i QE dovranno consegnare su wiki e per email le schede di valutazione dei progetti che saranno stati loro assegnati

La prima fase termina con una seduta riepilogativa in aula, da convocarsi tra 8 e 11 giugno 2010, cui deve partecipare almeno un membro di ciascun team. Scadenze obbligatorie della seconda fase: Il progetto completo dellimplementazione deve essere consegnato entro il 31 gennaio 2011.

Capitolo 3 Glossario e riferimenti

3.1 Riferimenti

Per la creazione del progetto abbiamo utilizzato,come materiale di riferimento: Applicare UML e i Pattern ,Craig Larman ,Pearson Hall,2005 IEEE Std 1058-1998,Software Engineering Standards Committeeof the IEEE Computer Society,8 December 1998 Using RUP/UP: 10 Easy Steps, Rushton Prince ,2005 Slide del corso di Laboratorio di Progettazione di Sistemi Software (a.a. 2009/2010) ,Professore Paolo Ciancarini, Piani di processi realizzati da Studenti degli anni passati,

3.2

Denizioni

Questa clausola fornisce la denizione di tutti i termini e le sigle necessarie per comprendere adeguatamente il documento: PM - Project Manager: Il project manager guida il processo di sviluppo. Decide il modello di processo, coordina i ruoli, assegna i compiti. QE - Quality Engineer: E il responsabile della qualit dei prodotti del team di progetto. Collabora con il Librarian nel gestire i documenti e lo sostituisce in caso di necessit.

10

 TS - Tool Specialist: E il responsabile degli strumenti utilizzati; funziona anche da Backup PM, redige il diario di gruppo, sostituisce il PM in caso di necessit. L - Librarian: E il responsabile della documentazione di progetto e del sito. IEEE - acronimo di Institute of Electrical and Electronic Engineers (in italiano: Istituto degli ingegneri elettrici ed elettronici).E unassociazione internazionale di scienziati professionisti.Lo scopo principale dello IEEE quello di cercare nuove applicazioni e teorie nella scienza elettrotecnica, elettronica, informatica, meccanica e biomedica; a questo scopo organizza conferenze e dibattiti tecnici in tutto il mondo, pubblica testi tecnici e sostiene programmi educativi. Si occupa inoltre di denire e pubblicare standard in tali campi. SPMP - acronimo di Software Project Management Plans, ovvero piano di gestione del progetto software. GANTT - Il diagramma di Gantt uno strumento di supporto alla gestione dei progetti, cos chaiamato in ricordo dellingegnere che lo ide nel 1917, Henry Laurence Gantt. Un diagramma di Gantt permette dunque la rappresentazione graca di un calendario di attivit, utile al ne di pianicare, coordinare e tracciare speciche attivit in un progetto dando una chiara illustrazione dello stato davanzamento del progetto rappresentato. WBS - acronimo di Work Breakdown Structure, ovvero Struttura Analitica di Progetto. Con il termine WBS si intende lelenco di tutte le attivit di un progetto. Le WBS sono usate nella pratica del Project manager e coadiuvano il Project manager nellorganizzazione delle attivit di cui responsabile. COCOMO - acronimo di COnstructive COst MOdel, uno dei modelli parametrici pi diusi per fare stime nei progetti software. Cost driver: In COCOMO, identica un insieme di attributi che inuenzano la stima nale. RUP - acronimo di Rational Unied Process, un modello di processo software iterativo sviluppato da Rational Software. Wiki - Si intende il Sito del corso. LOC - Line of Code, si intende la linea di codice. 11

 UML - Unied Modelling Language: In ingegneria del software, UML (Unied Modeling Language, linguaggio di modellazione unicato) un linguaggio di modellazione e specica basato sul paradigma Object Oriented. Il linguaggio nacque con lintento di unicare approcci precedenti (dovuti ai tre padri di UML e altri), raccogliendo le best practicies nel settore e denendo cos uno standard industriale unicato. UML svolge unimportantissima funzione di lingua franca nella comunit della progettazione e programmazione a oggetti. Gran parte della letteratura di settore usa UML per descrivere soluzioni analitiche e progettuali in modo sintetico e comprensibile a un vasto pubblico.

12

Capitolo 4 Organizzazione del Progetto

4.1 Struttura del Gruppo

In seguito a delle decisioni prese dal gruppo, lorganizzazione interna denita come nella seguente tabella. Lassegnazione dei ruoli dipesa dalle conoscenze dei singoli membri, per evitare di riscontrare problemi in futuro, che possano, in qualche modo, rallentare lo sviluppo del progetto. Nome e Cognome Marco Ardizzoni Federico Pisconti Marco Della Valle Nazareno De Luca Ruolo Project Manager Librarian Quality Engineering Tool Specialist

4.2

Ruoli e Responsabilit

Le responsabilit sono state denite nel documento Descrizione delle attivit e deadline e di seguito riportate.

13

Responsabilit Specica dei requisiti( Contiene la riformulazione del documento di descrizione dei requisiti prodotto dal cliente). Relazione UML(Contiene la specica UML di progetto in termini di diagrammi UML opportunamente commentati ). Piano di processo(Contiene la descrizione del processo di sviluppo prescelto e il piano di produzione preventivo, che deve includere almeno un diagramma GANTT e un diagramma WBS. Contiene anche una stima preventiva dello sforzo). Nella versione nale questo documento conterr lanalisi del piano eettivamente svolto, con il suo GANTT a consuntivo, e la misura nale dello sforzo totale. Descrizione degli strumenti di sviluppo utilizzati e ragioni della scelta. Piano di qualit e test del prodotto(Contiene il piano di qualit del gruppo. Contiene la descrizione del processo di testing). Manuale dutente(breve descrizione delle funzionalit dal punto di vista utente.) Analisi di qualit(alla ne della fase di progetto UML verranno assegnati da valutare progetti di altri gruppi. Occorrer compilare alcune schede di valutazione). Diario di gruppo( Occorre registrare ciascuna attivit e poi riassumere per ciascun componente le ore di sforzo.). Diario individuale(Ogni membro del team di progetto tiene il diario individuale delle sue attivit eettuate per il progetto). Costruire e tenere aggiornato il Sito Wiki di lavoro nellambito del wiki del corso.

Ruolo TS L PM

TS QE QE QE TS Tutti L

14

Capitolo 5 Piani di Processo Gestionale

5.1 Piano di Lavoro

Questo capitolo specica le attivit di lavoro e i dettagli di budget per il progetto software.

5.1.1

WBS

Con lespressione inglese Work Breakdown Structure (WBS, Struttura Analitica di Progetto) si intende lelenco di tutte le attivit di un progetto. La WBS usata nella pratica del Project management e aiuta il project manager nellorganizzazione delle attivit di cui responsabile. Da un lato essa specica nel dettaglio quello che deve essere eseguito, dallaltro delimita i conni del progetto escludendo dalla sua struttura tutto ci che non occorre al raggiungimento degli obiettivi. Il seguente diagramma stato suddiviso in sei parti (Creazione, Preparazione, Pianicazione, Elaborazione, Creazione e Documentazione) e si cercato di escludere possibili abiguit e sovrapposizioni tra le attivit,evitando un aumento consistente della durate del progetto. In oltre abbiamo anche tenuto un livello di dettaglio soddisfacente in modo da permettere al progetto di essere pi eciente e dinamico.

5.1.2

Gantt

Il diagramma di Gantt uno strumento che serve per pianicare i tempi di realizzazione di un progetto, dellattivit lavorativa quotidiana, di un anno di lavoro, ecc., e per vericare in itinere il rispetto degli stessi. Nel diagramma di Gantt le diverse attivit vengono, dunque, ordinate secondo una precisa progressione temporale. 15

Figura 5.1: Diagramma WBS

16

Il primo graco quello che chiameremo Gantt preventivo il secondo quello che chiameremo Gantt nale. Dal confronto dei due diagrammi possibile notare come si siano rispettati i termini e le scadenze ssate. Lunica piccola dierenza riguarda la fase di modellazione dei diagrammi Uml,in quanto,tale fase ha subito una diminuzione dei tempi a disposizione,dovuta agli impegni accademici dei vari componenti arontati prima di questa fase.

17

Figura 5.2: Diagramma di Gantt preventivo

18

Figura 5.3: Diagramma di Gantt nale

19

Capitolo 6 Piano di Controllo

6.1 Stima dello Sforzo

In questa valutazione preventiva abbiamo cercato di stimare lo sforzo necessario per la realizzazione del progetto,utilizzando come unit di misura i mesi/persona che rappresentano il tempo totale che serve ad una persona per terminare il progetto. Per la misurazione della dimensione del progetto abbiamo utilizzato la misurazione basata sui LOC. Questa tecnica quantica la dimensione del software basandosi sul conteggio delle linee di codice;

6.2

Cocomo81

Per la stima abbiamo utilizzato un tool interattivo chiamato Cocomo 81. Cocomo identica un insieme di attributi che inuenzano la stima nale. Questo tool si basa su cost drivers, che vengono considerati dei buoni indicatori della performance del processo di sviluppo del software. Come prima informazione da inserire,ci viene chiesto il numero di SLOC( equivalenti alle LOC ma senza i commenti),che indicativamente poniamo uguale a 2500. La seconda richiesta riguarda la tipologia di progetto scelto e la voce Organic quella che rispecchia di pi la natura del gruppo. Successivamente incontriamo le quattro tipologie di cost drivers:

6.3

Product Attributes

Questo cost drivers mira ad analizzare gli attributi del prodotto in particolare la sua ecienza e adabilit. E diviso in: Required Reliability Database Size Product Complexity 20

6.4

Computer Attributes

E il vincolo pi tecnico e riguarda le carateristiche principali dello sviluppo del software quali tempo di risposta della macchina,archiviazione e volatilit. Execution Time Constraint Main Storage Constraint Virtual Machine Volatility Computer Turnaround Time

6.5

Personal Attributes

Di questo campo,da come si deduce dal titolo riguarda il livello di esperienza dei componenti del gruppo con tutti gli strumenti(hardware e software) e con i rispettivi ruoli: Analyst Capability Applications Experience Programmer Capability Virtual Machine Experience Programming Language Experience

6.6

Project Attributes

Questo cost drivers viene misurato tramite i vari aspetti che misurano landamento del progetto: Use of Modern Programming Practices Use of Software Tools Schedule Constraint

6.7

Risultati

Dopo aver compilato i campi, secondo i parametri descritti nei precedenti paragra di questo capitolo, i risultati ottenuti sono i seguenti: Sforzo = 5.48 Persona/mesi Tempo totale = 4.77 Months

21

Figura 6.1: Cocomo81

22

Capitolo 7 Analisi e Gestione dei Rischi

Per lo svolgimento del progetto abbiamo adottato una strategia di sviluppo iterativa ed evolutiva,escludendo cos un approccio sequenziale (associato a una percentuale elevata di fallimenti,minore produttivit e maggiori percentuali di difetti). Di seguito elencher un insieme di rischi in cui ci siamo imbattuti in queste prime fasi di progetto:

7.1

Inesperienza del Team

Questo fattore pu causare un rallentamento del lavoro ed un abbassamento della qualit del progetto dovuto allo spreco di tempo.

7.2

Inadeguatezza dei Requisiti

Questo fattore,forse il pi importante, pu causare un totale fallimento del progetto. Cercheremo,nelle iterazioni successive, di eliminare lambiguit dei requisti per creare un prodotto che soddis pienamente il cliente.

7.3

Assenteismo dei componenti del gruppo

La presenza di assenteismo provoca un rallentamento generale del progetto e se continuo pu causa il fallimento del progetto stesso. In questa fase di analisi preliminare i fattori precedentemente analizzati possono essere controllati ed eliminati con un approccio preventivo.

23

Capitolo 8 Piano di Processo Tecnico

8.1 Modello di Processo

Come processo per lo sviluppo del software stato scelto il RUP (Rational Unied Process), un ranamento di UP (Unied Process). La scelta di utilizzare RUP dovuta principalmente alla sua essibilit, estendibilit e alla sua natura object-oriented. RUP consiste in una collezione di best practices di altri metodi agili, mirate allo sviluppo guidato al rischio e alla gestione dei processi.

8.2

Descrizione del Modello di Processo

Il ciclo di vita di RUP suddiviso in una serie di iterazioni. Ogni iterazione composta da una serie di fasi 1. Fase iniziale 2. Fase di elaborazione 3. Fase di costruzione 4. Fase di transizione

8.3

Fase Iniziale

Nella fase Iniziale , il modello caratterizzato dallidenticazione dei requisiti che serviranno in una fase successiva per la costruzione dellarchitettura, questo avviene di solito comunicando con il cliente e denendo attraverso dei casi duso iniziali le richieste fornite. Si svolge la prima pianicazione 24

della fase corrente, si analizzano i rischi, si fa unanalisi di fattibilit. Svolte queste attivit con successo si potr passare alla seconda fase del ciclo. Nel caso il progetto non dovesse superare questa attivit dovr essere ridenito o addirittura in alcuni casi abbandonato.

8.4

Fase di Elaborazione

Nella fase di elaborazione si inizia a progettare larchitettura facendo anche unanalisi del dominio. Si sviluppano in maniera pi dettagliata i casi duso attraverso una descrizione dellarchitettura del sistema. Viene rivista e completata la pianicazione della fase nella sua complessit, revisionate le analisi dei rischi e dei costi e viene aggiornata tutta la documentazione.

8.5

Fase di Costruzione

Questa la fase dove viene conclusa la maggior parte dello sviluppo creando i vari componenti e progettando i test per ognuno di essi. In questa fase vengono sviluppati anche dei test di accettabilit creati a partire dai casi duso.

8.6

Fase di Transizione

Questa fase l ultima fase e serve a fornire il software al cliente. Si completano le attivit di implementazione e si eettuano ulteriori test. Viene anche stesa una documentazione chiamata manuale utente.

25

Capitolo 9 Metodi Scartati

9.1 Il Processo con Ciclo a Cascata

Il processo con ciclo a cascata ,in cui c il tentativo di denire in dettaglio tutti i requisiti prima di iniziare la programmazione, stato scartato. Questo tipo di approccio,secondo una ricerca ([Larman03] e [LB03]) pu causare una minore produttivit e le stime iniziali a cascata dei tempi e dei costi variano no al 400% dei valori eettivi nali.

26

Capitolo 10 Tool utilizzati

In questo capitolo verranno esposte tutti le applicazioni utilizzate, elencandole insieme ad una breve descrizione che cercher di far chiarezza su come sono stati utilizzati dal gruppo e sui motivi per cui questi programmi sono stati scelti. XMind: un software open source per il brainstorming e la gestione delle mappe mentali o concettuali sviluppato da XMind Ltd. Questo strumento utile per acquisire idee, organizzarle sotto forma di graci di natura diversa. Scelto da MaNaZ durante le prime fasi di studio del progetto, per avere una chiara idea della situazione e non perdere di vista argomenti e particolari che potevano sfuggire. stato molto utile anche per gestire problemi nelle fasi successive. TeXMaker: Texmaker un editor LaTeX open source e multipiattaforma che integra al suo interno molti strumenti necessari nella fase di creazione di documenti LaTex. stato scelto per il suo aiuto nei primi passi e per la sua portabilit. WBS Chart Pro: WBS Chart Pro una applicazione che permette di creare e visualizzare progetti mostrando come questi sono organizzati usando una Work Breakdown Structure (WBS). ArgoUML: ArgoUml un case tool per progettare in UML. Include supporto per gli standard UML 1.4 Permette di disegnare diagrammi e genera codice Java per le classi denite. Il software stato utilizzato per creare le prime bozze, ma successivamente, stato deciso il passaggio ad un nuovo tool per la creazione di diagrammi UML, che permettesse una gestione migliore del lavoro.

27

 GanttProject: GanttProject un software per la pianicazione e la gestione di progetti. stato utilizzato da MaNaZ per pianicare ogni fase del progetto. Visual Paradigm: VisualParadigm un ottimo programma per la designazione e creazione dei diagrammi che permette in modo semplice e veloce di designare tutti i diagrammi UML. Il software in questione, stato scelto successivamente per rimpiazzare ArgoUML. Visual Paradigm si dimostrato il miglior software per UML provato dal Tool Specialist del gruppo MaNaZ. COCOMO: Il Constructive Cost Model (COCOMO) un algoritmo sviluppato da Barry Boehm che ha la funzione di calcolare alcuni tra i parametri fondamentali nella creazione di un software quali: il tempo di consegna e i mesi/uomo necessari per lo sviluppo di un software. Open Oce: Suite di Prodotti Oce open source sviluppata dalla Sun microsystems che ci ha aiutato principalmente insieme al writer nella stesura dei documenti. Photoshop: Photoshop il miglior software per lelaborazione graca. Software creato da Adobe Systems Incorporated. MaNaZ lo ha utilizzato per la creazione del logo presente sulla Wiki Page.

28

Capitolo 11 Introduzioone al Documento dei Requisiti

11.1 Introduzione

I requisiti costituiscono una parte fondamentale della progettazione software. quindi molto importante analizzarli attentamente, poich una loro analisi errata porta spesso al fallimento di un progetto, inteso sia come abbandono sia come allungamento dei tempi stimati per la sua realizzazione. Lo scopo di questanalisi quello di denire cosa il sistema deve fare e non come deve farlo, il tutto descritto usando il linguaggio dellutente del sistema, di facile comprensione anche per chi non ha conoscenze nel campo della progettazione. I requisiti sono di due tipi: Requisiti Funzionali: forniscono una descrizione dei servizi che il sistema deve fornire, del comportamento dello stesso a seguito di particolari inputs e situazioni; Requisiti Non Funzionali: esprimono vincoli e limitazioni dei servizi oerti dal sistema preso in analisi. Il committente richiede la costruzione di un simulatore di gioco del Fantacalcio.

11.2

Svolgimento del Gioco

La parte principale del gioco del fantacalcio consiste nella creazione e organizzazione di campionati e squadre in cui giocheranno calciatori reali. Sar gestita inoltre il mercato dasta dei giocatori e lassegnazione dei punti 29

per ogni giornata di campionato. Lo scopo del gioco consiste nel guidare una squadra decidendo quali giocatori utilizzare in ogni singola partita di campionato. Le fasi di gioco fondamentali sono due : Prima parte: Creazione delle squadre e compravendita dei giocatori attraverso il mercato dasta Seconda parte: Svolgimento di tutte le giornate di campionato.

30

Capitolo 12 Regole del Gioco

Il gioco basato sulle reali prestazioni dei calciatori del campionato italiano di Serie A.

12.1

Le Fasi

Le fasi di gioco sono : 1. Formare una societ di calcio , comprando attraverso unasta 25 calciatori scelti tra i veri calciatori delle squadre del campionato italiano di Serie A. 2. Mandare in campo, partita dopo partita, una formazione di 11 calciatori, scelti tra i 25 della rosa, per disputare le partite previste dal Calendario di Lega, secondo le modalit descritte nelle Regole.

12.2

Denominazione Sociale

La denominazione sociale, cio il nome di ciascuna societ calcistica o squadra, viene stabilita dal rispettivo allenatore e pu essere: - un nome di fantasia; il nome di una vera societ calcistica italiana o straniera, di qualunque serie o divisione. Un allenatore non pu adottare un nome gi scelto da un altro allenatore. Una volta scelto il nome della societ, non pi possibile modicarlo per il campionato in corso. 31

12.3

Capitale Sociale

Ciascuna societ dispone per lAsta iniziale di un capitale sociale di 500 FM, che dovr spendere per acquistare i calciatori. A questi saranno aggiunti, dopo lAsta, altri 50 FM che serviranno per il Mercato Libero durante la stagione. In nessun caso, nellarco di una stagione, una squadra potr spendere pi del capitale sociale assegnato (550 FM complessivi) per le operazioni di acquisto dei calciatori. Pu invece spendere di meno. I soldi che avanzeranno a ne stagione non saranno sommati al capitale sociale della squadra nella stagione successiva.

12.4

Crediti bonus mercato gennaio

Per il mercato di gennaio saranno sommati 50 crediti per ciascuna squadra La rosa di ciascuna squadra deve essere composta da 25 calciatori, scelti tra quelli appartenenti alle squadre del campionato italiano di Serie A. La rosa deve obbligatoriamente essere composta, in numero e ruoli, dai seguenti calciatori: 3 Portieri 8 Difensori 8 Centrocampisti 6 Attaccanti

12.5

Asta dei Calciatori

Il giocatore verr assegnato a chi far loerta pi alta per lo stesso dopo che il battitore dellasta avr contato no a 3. Una volta che un partecipante si ritira dallasta per un giocatore, non pu pi tornarne a far parte. (Per ritirarsi dallasta necessaria unespressa dichiarazione del partecipante) Il Mercato Libero (ML) si svolger la prima settimana di ogni mese (linvio delle oerte sar consentito dalle ore 24.00 della Domenica alle ore 20.00 del Mercoled) a partire dalla 6a giornata di campionato e no alla ne del campionato regolare, eccezion fatta per le settimane in cui sono previsti turni infrasettimanali del Campionato di Serie A e nelle settimane in cui gioca la Nazionale (riposo della Serie A). Il risultato del ML sar pubblicato sul forum e/o sul sito di lega dopo le ore 20.00 del Mercoled e comunque entro le 17.00 del Gioved. 32

12.6

Calciatore Deceduto

Se un calciatore facente parte della rosa di una fantasquadra dovesse decedere, la squadra che ne detiene il cartellino ricever come indennizzo il 100 La squadra che detiene il cartellino del calciatore deceduto dovr acquistare al ML un altro calciatore dello stesso ruolo.

12.7

Scambi

Gli scambi di giocatori tra gli allenatori, potranno avvenire tutte le settimane, dal luned al gioved (ore 24) (tranne nelle ultime 3 giornate). Lo scambio deve durare almeno 7 giornate, onde evitare scambi illeciti.

12.8

In Campo

Ogni partita viene disputata tra due squadre di 11 calciatori, scelti dallallenatore tra i 25 appartenenti alla rosa. La squadra che avr segnato il maggior numero di reti vincer la gara. Se non sar segnata alcuna rete o se le squadre avranno segnato eguale numero di reti, la gara risulter conclusa in parit. Il numero di reti segnate da ciascuna squadra, cio il Risultato Finale, viene calcolato, per mezzo della Tabella di Conversione, confrontando i Totali-Squadra di ciascuna squadra Ciascuna squadra dovr schierare i suoi 11 calciatori in base alle seguenti disposizioni: La formazione dovr essere composta da un minimo di 3 difensori, un minimo di 3 centrocampisti e da almeno un attaccante no a un massimo di 3; In base alle disposizioni di cui alla lettera precedente, le formazioni possono essere schierate nei seguenti moduli: 4-3-3; 5-3-2; 4-4-2; 5-4-1; 4-5-1; 3-4-3; 3-5-2; 33

Ogni squadra pu schierare in panchina sino a sette calciatori di riserva: un portiere e almeno un calciatore per ruolo (un difensore, un centrocampista e un attaccante). I restanti tre posti sono a discrezione del fantallenatore; Una squadra non pu eettuare pi di tre sostituzioni per gara. Le riserve, che verranno scelte tra i sette calciatori in panchina. Lesito, cio il Risultato Finale della gara, viene calcolato secondo le modalit qui descritte. +3 punti per ogni gol segnato -3 punti per un rigore sbagliato +3 punti per ogni rigore parato dal portiere +1 punto per ogni assist fornito (non sempre previsto) +1 punto per il portiere imbattuto (non sempre previsto) -2 punti per ogni autorete -1 punto per ogni gol subito dal portiere -1 punto per ogni espulsione -0,5 punti per ogni ammonizione La tabella di conversione in gol dei punteggi ottenuti dalla somma di voti e bonus/malus questa: Meno di 66 punti 0 Da 66 a 71,5 punti: 1 gol Da 72 a 77,5 punti: 2 gol Da 78 a 83,5 punti: 3 gol Da 84 a 89,5 punti: 4 gol Da 90 a 95,5 punti: 5 gol Da 96 a 101,5 punti: 6 gol E cos via (ogni 6 punti un gol).

34

12.9

Classica

La classica del campionato di Lega stabilita per punteggio, con attribuzione di 3 punti per la partita vinta, 1 punto per la partita pareggiata e zero punti per la partita persa. Il fantacampionato termina quando sono state giocate tutte le partite previste dal calendario. La squadra col maggior numero di punti dichiarata Campione di Lega.

35

Capitolo 13 Requisiti
13.1 Requisiti Funzionali

Il sistema assegna ai giocatori dei crediti utili per lacquisto dei calcia- tori e quindi per la formazione della squadra. Gli allenatori eseguono lasta Gli allenatori formano le squadre Vengono generate dal sistema tutte le giornate di campionato Il sistema assegna dei punteggi dopo ogni giornata rappresentati dai punti bonus/malus pubblicati dai quotidiani Vengono assegnati 3 punti al calciatore che eettua un gol 3 punti vengono scalati, qualora il calciatore sbagli un rigore 2 punti nel caso di gol su rigore 3 punti al portiere che para un rigore 1 punto allassist-man (colui che eettua lultimo passaggio al calciatore che va in gol) 1 punto al portiere imbattuto 2 punti scalati per un autogol (gol segnato nella porta errata) 1 punto scalato al portiere che subisce un gol 1 punto in meno per un espulsione (cartellino rosso) 36

 0.5 punti in meno per unammonizione (cartellino giallo) Il sistema dichiara vincitore, il giocatore che accumula pi punti (somma dei singoli voti) Vengono assegnati 3 punti alla squadra che vince 1 punto in caso di pareggio 0 punti in caso di scontta Il sistema sceglie come vincitore del gioco il giocatore che ha accumulato pi punti durante la stagione Nel caso in cui il giocatore non abbia pubblicato la propria formazione, il sistema utilizzer lultima disponibile

13.2

Requisiti non Funzionali

I calciatori possono essere acquistati solo allinizio e a met campionato (durante il mercato di riparazione) una lega deve essere costituita almeno da 4 persone si possono eettuare no a 15 trasferimenti durante tutta la stagione una squadra deve essere formata da al massimo 25 calciatori possono esserci al massimo 3 portieri 8 difensori 8 centrocampisti 6 attaccanti in ogni partita giocano 2 squadre in campo si schierano 11 giocatori per squadra nella panchina, durante una partita, ci sono 7 giocatori dai 66 a 71,5 punti, valgono un gol per ogni 6 punti, viene aggiunto un gol il campionato formato da almeno 4 squadre ed al massimo 20 37

Capitolo 14 Introduzioone alla Relazione UML

14.1 Introduzione

UML (Unied Modeling Language) un linguaggio visuale, il cui scopo la denizione di speciche e la costruzione di un software. Questo linguaggio, permette di eettuare il lavoro descritto, tramite lutilizzo di graci (e la loro descrizione tramite lutilizzo di testo) che ne determinano la chiarezza e la semplicit di lettura, cosa non poco importante. UML largamente utilizzato per la specica di software Object Oriented. In questo progetto, i diagrammi scelti per la rappresentazione delle speciche e per la descrizione di tutte le fasi e della struttura sono: Diagramma dei Casi dUso: in questo tipo di diagramma, si descrivono i casi duso svolti dagli attori del sistema. Per attori si intende un soggetto con responsabilit, che ha capacit di scelta. I casi duso, sono semplicemente appunto tutte le situazioni che si dovranno gestire e con cui gli attori avranno a che fare. Diagramma delle Classi: questo diagramma ci dar una visione pi strutturale del sistema richiesto, descrivendoci le classi che comporranno il software (Object Oriented). Ogni classe contiene dei fattori (quali possono essere nome, cognome per una persona ad esempio) e dei metodi. Le classi, tra loro connesse, descrivono completamente la struttura del sistema. Diagramma di Sequenza: con il diagramma di sequenza, si descrivono le interazioni tra due o pi attori o classi in un determinato caso. il miglior diagramma per quanto riguarda la specica temporale, poich 38

implementa una notazione studiata appositamente per la descrizione di eventi temporali. Diagramma delle Attivit: questo diagramma, invece, rappresenta il usso di attivit, appunto, che avvengono in determinati casi. Ogni attivit, rappresenta un azione che il sistema o un attore svolge durante il suo impiego. molto utile per rappresentare scelte e possibili casi opzionali che avvengono durante lo svolgimento di un passo. Diagramma degli Stati: il seguente diagramma descrive tutti i singoli stati del sistema in questione. Per stati si intende la situazione in cui si trova il sistema in un determinato punto. Ad esempio, un computer pu essere acceso, spento, attivo o in stand by, questi sono i principali stati di un normale computer. Di seguito verranno presentati tutti i diagrammi creati dal gruppo Manaz con una breve introduzione alla tipologia presentata e una descrizione su come sono stati studiati e creati.

39

Capitolo 15 Casi duso - Svolgimento

15.1 Descrizione

Il diagramma dei casi duso rappresenta tutte le azioni svolte allinterno del sistema. il primo diagramma creato, dato che la sua stesura, crea unimmagine di tutto quello che il sistema dovr gestire. Questo diagramma vede al suo interno: Attori: per attore si intende una parte dotata di comportamento che interagisce con il sistema. Nel nostro caso troviamo gli utenti, gli allenatori ed il sistema (inteso come amministratore). Casi duso: i casi duso rappresentano le azioni, le funzioni e le attivit che verranno svolte dagli attori rappresentati allinterno dei casi duso Conni del sistema: si denisce come conne del sistema, linsieme degli attori e dei casi duso che deniscono un livello che li comprende nelle loro funzioni e nelle loro attivit. Nel nostro caso, i conni del sistema sono rappresentati dal fantacalcio.

15.2
15.2.1

Il nostro diagramma
Descrizione del nostro diagramma

Nel diagramma sopra rappresentato sono stati descritti i principali componenti del sistema richiesto. Il diagramma composto da tre attori principali e da una serie di casi duso che descrivono le fasi e le azioni che avvengono dalla creazione di un nuovo utente, con la creazione di una nuova squadra e la relativa partecipazione allasta per denerla, no allo svolgimento di una 40

Figura 15.1: Diagramma dei casi duso dello svolgimento

41

normale giornata di campionato, comprendendo la scelta di una rosa e la generazione dei punteggi da parte del sistema. Pi in particolare, elencheremo di seguito tutti i punti principali del diagramma in oggetto. Attori: gli attori in questo sistema sono i seguenti Utente: che rappresenta qualsiasi persona che utilizzi il sistema. Rappresenta quindi una generalizzazione dellattore allenatore, che svolge le prime azioni da fare nel sistema (registrazione di un nuovo account, creazione della squadra e partecipazione alla prima asta per formare la squadra) Allenatore: lallenatore il vero e proprio giocatore, colui che gestisce la squadra sin dal primo istante. Lallenatore il diretto responsabile della creazione della propria squadra, della scelta della formazione da utilizzare in campo e dellacquisto o la vendita di altri calciatori nel mercato di riparazione. Sistema: il sistema lattore principale del sistema. Rappresenta colui che gestisce e controlla ogni fase. Dallautenticazione allaggiornamento della classica, il sistema tiene il controllo tramite le sue funzioni. Casi duso: visualizza classica: permette allallenatore di visualizzare la classica ogni volta che lo richiede; genera classica: il sistema calcola i punteggi ottenuti dalle squadre e genera la classica dopo ogni partita; visualizza punteggio partite: permette allallenatore di visualizzare i punteggi di tutte le partite; elabora punteggi: il sistema calcola tutti i punteggi delle squadre e dei relativi calciatori; importa dati da quotidiano: il sistema importa i voti dei calciatori dai quotidiani sportivi; gestione squadra: il caso duso che permette allallenatore di gestire la formazione e le scelte inerenti il gioco; scegli rosa: lallenatore seleziona la rosa per ogni partita; scegli modulo: lallenatore scegli il modulo per ogni partita (tra quelli permessi nei requisiti)

42

 richiedi formazione: il sistema prima di ogni partita, richiede la consegna della formazione agli allenatori. La formazione deve essere consegnata prima del schio di inizio delle partite; controlla formazione: il sistema controlla che nella formazione consegnata dagli allenatori, non siano presenti giocatori non disponibili (infortunati, squalicati, ecc.); gestione partita: il sistema gestisce la partita (punteggi, classica e formazione); mercato di riparazione: il sistema a gennaio apre il mercato di riparazione, e tramite questo caso duso, lallenatore pu acquistare o vendere un giocatore tramite asta; autenticazione: lutente si autentica; creazione nuovo utente: lutente si registra; esegui asta: lallenatore esegue lasta se deve creare la squadra (solo prima dellinizio del campionato) e durante il mercato di riparazione (solo a gennaio); crea squadra: lalleanatore crea la squadra, solo una per lega; registra squadra: il sistema aggiunge ad una lega determinata dallutente in fase di registrazione, la squadra da lui creata; genera calendario: una volta raggiunto il numero necessario di squadre per poter aprire il campionato (prima che inizi il campionato reale), il sistema apre il campionato e il gioco ha ucialmente inizio; crea nuova lega: il sistema crea una nuova lega a cui assegnare un solo campionato. pubblica le squadre: il sistema pubblica sul forum o sul sito uciale del gioco, le squadre iscritte e le relative rose al completo.

15.3

Scenari dei casi duso

In questa sezione verranno presentati tutti gli scenari dei casi duso relativi al diagramma sopra presentato. Uno Scenario R una sequenza di eventi che si verica in una particolare esecuzione del caso duso che rappresenta. Esso si compone di: Scenario Base, che rappresenta il corso principale degli eventi; 43

 Una serie di Scenari Alternativi: rappresentano varianti al corso principale degli eventi o sequenze eccezionali per il trattamento di errori o di situazioni anomale. Non obbligatoria la loro presenza.

44

[1]

[2]

[3]

45

[4]

[5]

[6]

46

[7]

[8]

[9]

47

[10]

48

Capitolo 16 Casi duso - Prima connessione

16.1 Descrizione

Nel diagramma dei casi duso oggetto di questo capitolo, si rappresenta la fase dellhandshaking tra il client ed il server ed i primi passi svolti dallutente. Viene quindi descritta questa fase descrivendo le richieste di connessione e le prime azioni che il client fa eseguire allutente.

16.2
16.2.1

Il nostro Diagramma
Descrizione del nostro diagramma

Il diagramma di questo capitolo formato da: Attori: Client: il lato dellapplicazione che si connette al server e fa uso dei servizi che ore il sistema; Server: rappresenta il lato dellapplicazione che ore i servizi e da possibilit agli utenti di connettersi a lui per utilizzare tali servizi; Casi duso: si connette: il client richiede la connessione al server e la eettua; registra nuovo utente: lutente, eettua la registrazione sul sistema e pu quindi decidere se creare una squadra e partecipare al gioco o meno; crea squadra: in questo caso duso lutente decide di creare una propria squadra, tenendo conto che pu crearne una per lega; 49

Figura 16.1: Diagramma dei casi duso della prima connessione

50

 Disconnetti: i client avvisa che si disconnetter a breve; disconnetti utente: il server riceve la richiesta di disconnessione ed attende un quanto di tempo per vericare che la connessione sia chiusa, dopo di che, chiuder la connessione aperta con quel client;

51

[1]

[2]

16.3

Scenari dei casi duso

Nei graci presentati di seguito, saranno specicati i casi duso presenti in questo capitolo, cercando di chiarire tutti i casi descritti, specicando gli attori, le precondizioni, le sequenze di eventi e le post condizioni.

52

[3]

[4]

[5]

53

Capitolo 17 Diagramma delle classi

17.1 Descrizione

Il diagramma delle classi da un idea pi strutturale del sistema, visualizzando le classi che comporranno il software e descrivendo le informazioni che conterranno tali classi ed i loro metodi. Questo tipo di diagramma rappresenta al meglio lutilizzo dei pattern e vengono utilizzati per gestire problemi ricorrenti che verranno risolti tramite lutilizzo di determinati pattern. Pi in particolare, nei diagrammi delle classi vengono denite delle entit e delle relazioni tra queste ultime.

17.2
17.2.1

Il nostro Diagramma
Descrizione del nostro diagramma

In questo diagramma sono visibili le principali entit che rappresentano il notro sistema. Il diagramma composto da: Persona: in questa classe, vengono inseriti i dati comuni di ogni utente o calciatore che fa parte del sistema; Calciatore: lentit che rappresenta i calciatori reali, contenente il nome ed il cognome ed il relativo valore. I calciatori, non possono appartenere a due o pi squadre dierenti della stessa lega. Allenatore: lutente del sistema che ha una propria squadra ed il responsabile di tale squadra; Squadra: rappresenta la squadra, composta al massimo da venticinque calciatori; 54

Figura 17.1: Diagramma delle classi

55

 Partita: la classe che rappresenta una singola partita, avente come dati: data, risultato, le due squadre che partecipano e lo stato della partita (in corso, nita, annullata o sospesa); Lega: una entit lega , contiene i dati riguardanti un particolare campionato, composto da minimo quattro e massimo venti squadre, e contenente il nome della lega ed il numero di squadre che la compongono; Campionato: questa entit, stata creata per adottare pi pattern. un contenitore di informazioni ed ha al suo interno: calendario dei singoli campionati, i nomi delle squadre che partecipano ad ogni campionato ed il relativo nome della lega con la classica; Form: anche questa entit stata inserita per ladozione di pi pattern e rappresenta unastrazione del sistema per la registrazione dei dati degli utenti. Pannello di controlo: lentit per la gestione di tutti i dati e di tutti i metodi che possono essere svolti dagli amministratori del sistema.

56

Capitolo 18 I Pattern
Nella creazione dei diagrammi, sono stati risolti alcuni problemi tramite lutilizzo di pi pattern. I pattern, sono una descrizione di un problema ricorrente e una soluzione. Lutilizzo dei pattern da un aiuto nella generazione ottimale dei diagrammi e della struttura del software, senza incorrere in problemi conosciuti e inoltre, da un grande aiuto nellindividuazione delle responsabilit. Nel nostro caso, sono stati adottati pattern GRASP. Nel nostro progetto, sono state analizzate alcune situazioni e si sono raggiunte alcune soluzioni grazie allutilizzo dei pattern. Durante lelaborazione, sono stati riscontrati dei problemi riguardanti laccoppiamento delle classi. Si voluto evitare un accoppiamento troppo forte tra le classi, per evitare che una successiva modica o un qualsiasi aggiornamento potesse in qualche modo scatenare una reazione a catena di modiche sulle restanti classi. Per risolvere questo problema, stato pensato di utilizzare il pattern GRASP, Information Expert. Questo pattern risolve i problemi legati alla conoscenza di informazioni delle classi e come conseguenza ci allontana dallalto accoppiamento e dalla bassa coesione. Grazie ad Information Expert, sono state aggiunte le classi Persona e Campionato, visibili nel diagramma delle classi. Queste classi, sono semplicemente dei contenitori di informazioni. Si analizzato inoltre un problema legato allimmagazzinamento dei dati durante la registrazione. I dati devono essere innanzitutto privati e comunque gestiti dal server. A questo ne, stato pensato ladattamento del pattern Controller, che favorisce la creazione di una classe che faccia da intermediario tra il server ed il client, gestendo i dati che vengono richiesti al client. Nel nostro progetto, la classe Controller stata denita con il nome Form ed visibile nel diagramma delle classi. Nel progetto stata evitata la creazione di classi principali, classi, cio, che avessero troppa responsabilit e quindi costrette ad eettuare operazioni 57

che potrebbero essere gestite da altre classi. La soluzione a questa situazione data dal pattern High Cohesion. Questo pattern ci ha portato una coesione elevata tra le classi, facendole lavorare tra loro, condividendo i contenuti, ma lavorando su aree proprie e non dipendendo dalle altre. Pi semplicemente, ogni classe ha una propria area tematica da gestire e con le altre classi collabora con le altri per arrivare al suo scopo. La conseguenza di questo pattern il basso accoppiamento, favorendo quindi unaltro nostro ne.

58

Capitolo 19 Diagramma di sequenza Svolgimento

19.1 Descrizione

Il diagramma di sequenza rappresenta al meglio le interazione tra un attore e laltro tenendo conto del tempo. Si possono quindi descrivere al meglio delle sequenze di azioni che determinano una situazione e da unidea chiara delle operazioni svolte nel tempo dagli attori.

19.2
19.2.1

Il nostro Diagramma
Descrizione del nostro diagramma

Nel diagramma abbiamo voluto rappresentare le azioni tra lallenatore ed il sistema in una tipica giornata di campionato, cominciando dalla richiesta della formazione no ad arrivare alla chiusura del campionato. Le parti che descrivono il nostro diagramma sono: Allenatore: durante lo svolgimento del campionato, lallenatore pu consegnare la formazione prima di ogni partita (deve farlo almeno una volta e comunque ogni volta che la formazione contiene uno o pi giocatori non disponibili) controllare i punteggi e partecipare alle aste di riparazione; Sistema: durante lo svolgimento del campionato, il sistema richiede la formazione agli allenatori e nel caso in cui la formazione non sia disponibile, utilizzare lultima formazione disponibile o richiedere nuovamente

59

Figura 19.1: Diagramma di sequenza dello svolgimento

60

la formazione al client, inoltre il sistema aggiorna i punteggi (i punteggi dei calciatori vengono presi dai quotidiani sportivi) e determina i vincitori;

61

Capitolo 20 Diagramma di sequenza - Prima connessione

20.1
20.1.1

Il nostro Diagramma
Descrizione del nostro diagramma

In questo diagramma sono state descritte le interazioni tra il client ed il server durante la prima connessione. I componenti del diagramma in oggetto sono: Client: il client rappresenta lutente e le sue scelte durante questa fase. Il client si connette al server e richiede uniscrizione di un nuovo utente, vengono quindi gestite le azioni che determinano questo punto e successivamente ha inizio la creazione di una nuova squadra, con la scelta del nome da utilizzare e della lega in cui iscriversi. Come ultimo passo, viene descritto come avviene la disconnessione tra le due parti; Server: il server gestisce la registrazione di un nuovo utente ed lui a controllare che tutto venga fatto rispettando i vincoli imposti. Il server, inoltre, gestisce le connessioni dei client e deve quindi tener conto di chi non pi connesso.

62

Figura 20.1: Diagramma di sequenza della prima connessione

63

Capitolo 21 Diagramma di sequenza - Asta

21.1
21.1.1

Il nostro Diagramma
Descrizione del nostro diagramma

Nel diagramma si voluto rappresentare una sequenza di azioni tipica di unasta. Nel diagramma viene quindi rappresentata unasta generica, in cui un utente ricerca un calciatore e decide se fare unoerta o meno e valutare quindi successivamente se continuare con lacquisto o uscire dallasta. Gli oggetti che compongono il diagramma sono: Allenatore: lallenatore pu decidere se entrare nellasta solo in due periodi dellanno: prima dellinizio del campionato e durante il mese di gennaio, quando il mercato di riparazione viene aperto dal sistema. In questi due periodi vengono aperte una serie di aste riguardanti pi giocatori. Prima dellinizio del campionato, posso essere eseguite aste su ogni calciatore (che non sia gi stato acquisito da una squadra), mentre durante il mercato di riparazione (o mercato libero) i calciatori che diventano oggetto dasta, sono presi tra quelli disponibili (non acquistati ancora da nessuno) e tra quelli messi in vendita dagli allenatori stessi; Sistema: il sistema, in questo diagramma, gestisce le aste e tiene conto degli spostamenti eettuati e delle nuove rose.

64

Figura 21.1: Diagramma di sequenza di unasta

65

Capitolo 22 Diagramma degli stati - Server

22.1 Descrizione

Il diagramma degli stati rappresenta gli stati che vengono assunti da un componente del sistema. Per stati si intende una condizione di un oggetto in un determinato istante. Un oggetto pu assumere pi stati attraverso delle mutazioni tra uno e laltro. Ad esempio, un telefono pu passare dallo stato di occupato allo stato libero.

22.2
22.2.1

Il nostro Diagramma
Descrizione del nostro diagramma

In questo capitolo viene descritto il diagramma degli stati dellapplicazione lato server. Verranno di seguito descritti i passi che compongono il diagramma: 1. Il server, una volta avviato, si mette subito in ascolto 2. arriva una richiesta di connessione 3. il server passa allo stato attivo 4. il client attende che la sua connessione venga gestita 5. il server gestisce questa connessione 6. il server ritorna allo stato in ascolto

66

Figura 22.1: Diagramma degli stati del server

67

Capitolo 23 Diagramma degli stati - Client

23.1
23.1.1

Il nostro Diagramma
Descrizione del nostro diagramma

In questo capitolo viene descritto il diagramma degli stati dellapplicazione lato client. Verranno di seguito descritti i passi che compongono il diagramma: 1. il software in mano allutente viene avviato e passa quindi allo stato inattivo, in cui attende che venga avviato il vero e proprio client che lo connetter al server in ascolto; 2. il client richiede una connessione; 3. il client passa allo stato in connessione; 4. il client non ha problemi a connettersi al server (il server in ascolto ed raggiungibile) 5. il client passa quindi allo stato connesso; 6. a questo punto, lutente connesso al server e pu quindi eettuare le sue scelte e gestire la sua squadra; 7. il client, passa allo stato in uso, in cui lutente gestisce la sua squadra; 8. il client, una volta che lutente ha nito di svolgere le sue azioni, avvisa il server che sta per disconettersi; 9. passa quindi allo stato disattivazione; 68

Figura 23.1: Diagramma degli stati del client

69

10. inne, dopo un quanto di tempo determinato in fase di implementazione, il client si disconnette; 11. passa quindi allo stato disconnesso; 12. lapplicazione viene chiusa.

70

Capitolo 24 Diagramma delle attivit Svolgimento

24.1 Descrizione

Nei diagrammi di attivit vengono inserite tutte le azioni che vengono eseguite da uno o pi attori e le loro interazioni. Vengono quindi rappresentati dei ussi temporali che indicano la sequenza di azioni e attivit che determinano lo svolgimento di una situazione e la gestione di casi opzionali e condizionali. Questo diagramma, infatti, mostra molto bene le condizioni ed i controlli che vengono eettuati durante le attivit.

24.2
24.2.1

Il nostro Diagramma
Descrizione del nostro diagramma

Nel nostro diagramma abbiamo voluto rappresentare lo svolgimento del gioco allinterno del campionato. Come abbiamo inteso nei precedenti diagrammi, anche in questo, inseriamo le fasi che vanno dalla richiesta di una formazione allassegnazione dei punteggi, descrivendo le fasi interne, quali i controlli delle formazioni e il download dei dati dai quotidiani sportivi. Nel diagramma, si presentano le attivit dellallenatore e del sistema e le interazioni tra questi due attori. Di seguito verrano descritte tutte le parti che lo compongono, cercando di eliminare qualsiasi tipo di dubbio. 71

Figura 24.1: Diagramma di attivit dello svolgimento

72

1. come descritto negli altri punti, il sistema, autonomamente, richiede settimanalmente la formazione allallenatore, che a sua volta deve aver provveduto a preparare, o provveder entro il schio di inizio delle partite; 2. la formazione pu quindi essere gi pronta al schio di inizio o pu invece non essere consegnata; 3. nel caso in cui la formazione venga consegnata, il sistema provvede a controllare che la rosa sia formata solo da calciatori disponibili e non da calciatori che non possono giocare (squalicati, sospeso, infortunato ecc.) 4. pu accadere altrimenti, che la formazione non sia stata consegnata entro il schio di inizio, ed in questo caso, verr presa come buona lultima formazione disponibile (che non presenta calciatori indisponibili); 5. passato il controllo della formazione, bisogna attendere che le partite niscano e quindi non viene eseguita alcuna operazione; 6. nite le partite, il sistema scarica automaticamente i voti dei calciatori assegnati dal quotidiano sportivo preso come riferimento; 7. vengono quindi elaborati i dati; 8. ed inne vengono generate le nuove classiche;

73

Capitolo 25 Diagramma delle attivit Prima connessione

25.1
25.1.1

Il nostro Diagramma
Descrizione del nostro diagramma

In questo caso, sono state elencate le attivit che compongono la prima connessione ed anche in questo caso, vengono visti i passi che racchiudono la registrazione di un nuovo account e la creazione di una nuova squadra. Nel diagramma preso in considerazione, sono state inserite le attivit del client e del server, mostrando come questi due elementi gestiscono questo scenario. I passi che compongono il diagramma sono i seguenti: 1. innanzitutto il client, dopo essere stato avviato, richiede la connessione al server; 2. il server pu essere in linea e quindi non avere problemi per accettare la connessione e gestirla; 3. il server pu altrimenti essere non in linea per un qualsiasi problema costringendo il client a chiudere la richiesta di connessione; 4. a questo punto, il client consapevole di potersi connettere e si connette al server; 5. essendo la prima connessione, si assume che lutente voglia registrarsi sul sistema;

74

Figura 25.1: Diagramma di sequenza della prima connessione

75

6. a questo punto, lutente seleziona la lega in cui vorr inserire la propria squadra; 7. lutente inserisce un nome utente 8. lusername inserito potrebbe essere gi utilizzato e quindi il sistema noticher il problema allutente, riportandolo allinserimento un nuovo nome utente; 9. passato il punto precedente, il nome utente, accettato, viene accettato; 10. lutente ora pu inserire un nome per la sua squadra; 11. il nome della squadra, come per lusername, viene controllato in modo tale da evitare che il nome sia stato utilizzato da un altro utente; 12. nel caso in cui lutente abbia scelto un nome disponibile, il sistema accetta la registrazione ed aggiunge alla lista delle squadre della lega selezionata dallutente, la squadra da lui creata; 13. viene ora il momento in cui lutente un utente registrato del sistema e pu quindi partecipare ad unasta o aggiornare i suoi dati personali e gestire altre scelte, quali possono ad esempio essere: visione dei risultati degli anni precedenti, dei vincitori passati, dei partecipanti ed altri dati visionabili; 14. lutente pu quindi decidere se eettuare una o pi azioni aggiuntive o uscire dallapplicazione; 15. nel caso in cui scelga di continuare, pu iniziare la gestione della squadra; 16. nel caso in cui non voglia continuare, lapplicazione verr chiusa;

76

Capitolo 26 Diagramma delle attivit Asta

26.1
26.1.1

Il nostro Diagramma
Descrizione del nostro diagramma

Nel diagramma presentato in questo capitolo, viene presentato un usso tipico di attivit componenti unasta generica. Per generica si intende unasta qualsiasi tra quella di creazione della squadra e lasta del mercato libero (o di riparazione). Inoltre si assume che le regole dellasta siano quelle denite nel documento dei requisiti. Il diagramma presenta il seguente usso di attivit: 1. lutente come primo passo, entra nellasta; 2. successivamente decide di cercare un calciatore, inserendone il nome nel campo di ricerca; 3. il nome potrebbe non essere nella lista dei calciatori in vendita o potrebbe anche non essere connesso a nessun calciatore esistente; 4. nel caso in cui il calciatore esista e sia in vendita, lallenatore pu quindi visualizzare il valore del calciatore scelto; 5. a questo punto, lallenatore pu decidere se acquistare o meno il calciatore selezionato; 6. nel caso voglia fare unoerta sul calciatore, pu partecipare allasta; 7. pu altrimenti decidere di uscire o di cercare un nuovo calciatore; 77

Figura 26.1: Diagramma delle attivit di unasta

78

8. scegliendo di cercare un nuovo calciatore, il diagramma lo riporta su entra nellasta; 9. altrimenti, scegliendo di fare un oerta, lutente la eettua; 10. ora lasta proseguir e possono presentarsi due casi, vincere oppure potrebbe accadere che loerta venga superata; 11. nel caso in cui loerta venga superata, lallenatore pu visualizzare nuovamente il valore e controllare che il suo budget disponibile gli permetta di fare una nuova oerta; 12. pu quindi, lallenatore, scegliere se rifare unoerta; 13. al termine dellasta, lallenatore, potrebbe aver vinto e quindi lasta nisce qui.

79

Capitolo 27 Diagramma di deployment

27.1 Descrizione

Il Diagramma di Deployment ha la funzione di descrivere la struttura software e lorganizzazione hardware utilizzata nellimplementazione del sistema e di individuare i collegamenti tra tutti i pezzi hardware; in questo tipo di diagramma si possono disporre i componenti cosi da individuare la loro collocazione nei vari elaboratori. I diagrammi di questo tipo, possono, inoltre, specicare le architetture utilizzate e quindi possono chiarire anche alcuni punti riguardanti eventuali connessioni utilizzate.

27.2
27.2.1

Il nostro Diagramma
Descrizione del nostro diagramma

In questo diagramma, viene descritta la struttura del software che verr adottata per lutilizzo dello stesso e la connessione tra i suoi componenti. Si assume che il progetto venga implementato in java e quindi stato inserito nel diagramma la Java Virtual Machine, su cui poi si baser lapplicazione. Le connessioni verranno implementate sul protocollo TCP/IP per assicurare una sicurezza elevata nello scambio dei dati.

80

Figura 27.1: Diagramma di deployment

81

Capitolo 28 Revisioni incrociate

28.1 Introduzione

Questo capitolo contiene le valutazioni dei progetti dei gruppi a noi assegnati quali 13, 14, 15, 16.

28.2
28.2.1

Valutazione gruppo 13
Leggibilit del processo: voto 8

La sequenza di esposizione molto chiara e scorrevole e anche la struttura del piano di processo buona. Il modello RUP per lo sviluppo di questo progetto stato compreso e spiegato. presente un glossario dove vengono citati e deniti i termini pi usati. Sono presenti molti diagrammi chiari e ricchi di commenti, il diagramma WBS, il Diagramma di Gant e il graco Cocomo per la stima degli sforzi

28.2.2

Correttezza: voto 6

Il livello di denizione dei diagrammi UML e la semantica UML buona. I diagrammi presentano alcune imprecisioni, in particolare, quello dei casi duso risulta corretto ma la visione troppo generalizzata e i casi duso presenti sono troppo pochi. I Diagrammi delle Classi molto adeguato, forse anche troppo. sono presenti 6 diagrammi delle classi ricchi di commenti. 82

28.2.3

Completezza: voto 7

La specica dei requisiti copre il documento dei requisiti informali. La descrizione degli scenari completa e esaustiva. I diagrammi sono tutti completi tranne quello dei casi duso che risulta essere un po troppo stilizzato.

28.2.4

Organizzazione e presentazione: voto 7

In tutti e 3 i documenti sono presenti gli indici generali che aiutano nella navigazione dei documenti . non presente la bibliograa e neanche la lista dei tools utilizzati. Le immagini sono adeguate e comprensibili. La versione sul web presenta:diario di gruppo e personale , artefatti.

28.2.5

Voto complessivo: voto 7

Voto complessivo buono:Il piano di processo ottimo, i diagrammi sono corretti ma potevano essere sviluppati in modo pi adeguato.

28.3
28.3.1

Valutazione gruppo 14
Leggibilit del processo: voto 6

La sequenza di esposizione abbastanza chiara . il modello di processo usato stato il Rup che stato descritto. Sono presenti Il diagramma WBS il diagramma di Gannt il Stima degli sforzi con Cocomo, tutti questi diagrammi hanno poca descrizione che rendono la Comprensione del piano di processo un p rallentata. presente la lista dei tools utilizzati.

28.3.2

Correttezza: voto 7

Buon livello di denizione dei diagrammi e della semantica UML. Il diagramma dei casi duso chiaro e completo ma stata usata la cardinalit che non consigliabile nella stesura dei casi duso. Anche il diagramma delle classi completo, ricco di metodi e attributi. In via di massima i diagrammi sono buoni ma presente poca descrizione che rendono il documento dei diagrammi un p scarno. 83

28.3.3

Completezza: voto 6

La specica dei requisiti di sistema suciente copre il documento dei requisiti informali. Manca una descrizione dettagliata delle regole del gioco ed e solo presente la distinzione tra requisiti funzionali e non. La descrizione degli scenari adeguata. I diagrammi sono corretti .

28.3.4

Organizzazione e presentazione: voto 7

Sono presenti gli indici in tutti i documenti, ma non presente la Bibliograa. Le immagini presenti sono quasi tutte leggibili. La presentazione sul Wiki buona e sono presenti i diari di gruppo personali e non, gli artefatti e i tools utilizzati.

28.3.5

Voto complessivo: voto 7

In linea di massimo non ci sono gravi mancanze ma stato scritto troppo poco testo in tutti e 3 i documenti, i diagrammi sono corretti ma con una descrizione maggiore potevano essere ottimi.

84

Capitolo 29 Valutazione gruppo 15

29.0.6 Leggibilit del processo: voto 8

La sequenza espositiva del piano di processo molto accurata e scorrevole. La struttura e la suddivisione in capitoli del documento molto buona. Il modello di processo Rup stato compreso e descritto a fondo. Sono presenti Il WBS, il diagramma di Gannt e la stima dello sforzo (Cocomo). Presente anche la lista di tutti i Tools utilizzati.

29.0.7

Correttezza: voto 8

Buon livello di denizione dei diagrammi e della semantica di UML. Tutti i graci richiesti sono presenti. Il diagramma dei casi duso semplice ma contiene tutti gli elementi Importanti, e di facile lettura avendo una buona descrizione. Il diagramma delle classi ha una struttura ottima e presenta per ogni classe una descrizione esaustiva. Anche gli altri diagrammi sono scritti molto bene e presentano tutti una buona descrizione.

29.0.8

Completezza: voto 8

La specica dei requisiti di sistema copre a pieno il documento dei requisiti informali. La descrizione degli scenari, degli attori e la distinzione dei requisiti funzionali e non veramente ottima. I diagrammi sono completi e di facile lettura.

85

29.0.9

Organizzazione e presentazione: voto 8

I documenti hanno una buona graca e presentano tutti un indice. Limpaginazione ben fatta e le foto sono molto grandi e chiare. La versione sul web completa e presenta una buona graca, sono presenti tutti i diari personali e di gruppo, gli strumenti utilizzati, gli artefatti.

29.0.10

Voto complessivo: voto 8

Documento in linea di massimo ottimo. Con diagrammi ottimi e esaustivi. La descrizione dei requisiti dettagliata. E il piano di processo stato realizzato in modo approfondito.

86

Capitolo 30 Valutazione gruppo 16

30.0.11 Leggibilit del processo: voto 6

Il Documento del piano di processo chiaro ma risulta essere un p poco dettagliato. La descrizione Del modello di processo Rup non presente, Sono presenti Il diagramma Wbs , il diagramma di Gantt e la stima dello sforzo con Cocomo; tutti e 3 sprovvisti di adeguati commenti che rendono tali diagrammi di dicile comprensione. Manca la lista dei tools utilizzati.

30.0.12

Correttezza: voto 5

Mediocre livello di denizione dei diagrammi UML e della consistenza semantica. Tutti i diagrammi sono presenti. Il Diagramma dei casi Duso non molto chiaro e mancano alcune funzioni molto importanti , in alcuni casi duso si sono usati dei sostantivi invece che dei verbi , e si fatto uso della cardinalit non consigliabile con i casi duso. Il diagramma delle classi corretto e ben strutturato. In linea di massima tranne il diagramma dei casi duso i diagrammi sono buoni.

30.0.13

Completezza: voto 6

La specica dei requisiti di sistema suciente e copre il documento dei requisiti informali. Gli Scenari sono in descritti in modo corretto ,La descrizione degli attori completa e sono presenti solo i requisiti funzionali Non tutti i Diagrammi sono semanticamente corretti. 87

30.0.14

Organizzazione e presentazione: voto 6

In tutti i documenti sono presenti Gli indici ma non la Bibliograa. Le immagini presenti nei documenti sono di chiara lettura, Linterfaccia del sito minimalista: non presenta i diari di gruppo personale.

30.0.15

Voto complessivo: voto 5

Voto complessivo suciente. I diagrammi contengono alcuni errori .e il piano di processo poteva essere arontato in modo pi approfondito.

88